简介：RAG系统中chunk size的设定往往被简化为“256、512、1024加overlap”的调参经验，但真实业务数据通常并非均匀信息流。本文从信息论与数据结构视角出发，重新定义chunk size问题，剖析为什么“按长度切分”在大量场景下失效，并给出可落地的切分策略选择方法，帮助开发者跳出参数调优误区，从数据特征出发设计更可靠的检索链路。
在讨论“RAG的chunk size应该怎么选”之前，有必要先把这个问题的本质拆开。RAG，即检索增强生成，其核心链路可以概括为三步：将文档集合切分为若干可检索单元，将用户查询与这些单元进行相似度匹配，再把匹配到的单元交给大模型生成回答。所谓chunk size，就是指第一步中每个检索单元所包含的文本长度。
从信息论的角度看，chunk size的设定本质上是在做一个假设：切分后的每一个文本片段，应当携带足够且相对独立的信息量，使得向量检索能够在该粒度上完成“查询意图”与“文本片段”之间的互信息最大化。换句话说，一个理想的chunk，应该是一个语义自足的信息单元——它既不能太小，以至于丢失了回答查询所需要的上下文；也不能太大，以至于混入了过多无关信息，稀释了关键语义信号。
当开发者把chunk size设成256、512或1024时，背后的隐含前提是：文本是一条连续、均匀的语义流，任意等长截取都能得到语义相对完整的片段。这个前提在新闻稿、学术论文或百科条目等行文规整的语料上大致成立。但一旦进入真实业务场景，尤其是结构化文档、表格化知识库、FAQ集合或多类型混合语料时，这个前提迅速崩塌。
因此，严格来说，“chunk size选多少”并不是一个具有普适答案的参数问题。它首先是一个数据建模问题：你的知识库中，最小的、不可再分且语义自足的信息单元到底是什么。只有回答了这个问题，chunk size才从“拍脑袋调参”变成“有依据的工程决策”。
信息论中，信息熵用来衡量一个信源的不确定性或信息含量。对于一个文本片段，单位长度内携带的信息量往往不是均匀分布的。一段FAQ可能用50个字就完整表达了一个问题及其答案；而一段产品说明可能需要800字才能把规格、条件、例外情况说清楚。前者的信息密度高，后者的信息密度低，但二者都各自构成一个不可切分的语义整体。
固定长度切分的根本问题在于，它假设文本的信息熵在空间上是均匀的。这个假设在真实业务语料上几乎从不成立。举一个典型的电商客服知识库例子：语料中包含“话术规则”“违禁词列表”“品牌介绍”“店铺常见问答”等多种类型。最短的条目可能只有十几个字，最长的条目接近四千字，且长条目内部还包含数十个天然独立的问答对。如果用固定500字切分，短条目永远落在一个chunk内，切分参数对它完全无意义；长条目则被拦腰截断，某个问题被切开、某个答案被分到两个chunk里，向量化之后每个片段都失去了独立回答能力。
更隐蔽的问题在于，这种错误切分不一定在离线评估中立刻显现。向量相似度检索的模糊性使得即便chunk语义不完整，召回结果有时仍能“撞对”。但上线之后，面对表述方式稍有不同的用户查询，错误切分带来的噪声会持续拉低召回精度，表现为“偶尔答非所问”“同一类问题有时能答有时不能答”，而这些问题极难通过调整embedding模型或重排序算法来根本解决。
所以，从信息论视角切入可以得到一个反直觉但重要的结论：chunk size的调整空间，仅在数据的信息熵分布近似均匀时存在。如果知识库本身由长度差异悬殊、结构差异悬殊的语义单元组成，那么调chunk size只是在错误的搜索空间里做优化，收益极其有限。
如果长度不是最关键的变量，那什么才是？答案是语义边界。语义边界是指文档中天然存在的、标记信息单元起止的结构信号。它可能是FAQ中的一问一答，可能是JSON结构中的一个字段，可能是Markdown中的一个标题段落，也可能是合同中的一个条款编号。
当一个chunk恰好覆盖一个完整语义边界时，它的语义自足性最好，向量化后与该语义相关的查询相似度最高。反之，如果切分点落在语义边界内部，无论是从中间切开一个问答对，还是把两个无关条目合并进同一段文本，都会造成信息污染。对于向量检索而言，这种污染的直接后果是：片段的核心语义被稀释，匹配分数下降，召回排序不稳定。
不同数据形态的语义边界并不相同：
这意味着，在真实工程中，切分策略不应当由统一的chunk size参数来主导，而应当由数据自身的结构元数据来定义。开发者需要先回答的问题是：“我的知识库中，哪一个层级的信息单元能够独立回答用户的一个问题？”这个单元，就是最优的chunk粒度。
在业务实践中，面对结构化或半结构化知识库，有三条路线可以替代固定长度切分。
路线一：结构化字段切分。 如果知识库本身就是结构化数据，例如JSON对象数组，每个对象包含类型、标题、正文、关键词等字段，那么切分单位不应是字符数，而应是对象。每个对象作为一个最小知识单元整体入库，chunk的大小自然由数据本身决定，而不是由人工参数决定。这种做法的好处是语义边界清晰，与知识库的维护方式天然一致。缺点是当某个对象内部信息量过大时，仍然需要进一步拆分。
路线二：层级式父文档切分。 对于长篇幅但结构良好的文档，可以按照标题层级构建父子结构：父文档是完整章节，子文档是其中的若干段落或要点。检索时先匹配子文档，再将对应的父文档或邻近兄弟片段一并送入大模型。这种方式兼顾了检索精度与上下文完整性，同时避免了固定长度切分对文档结构的破坏。具体做法包括：先解析标题树，再根据标题节点归并文本块，最后生成检索单元和上下文单元两个层级。
路线三：语义聚类与动态聚合。 当文档既无清晰结构、又存在信息密度不均时，可以先按一定步长做初始切片，再通过嵌入相似度或主题模型对切片进行聚类，把语义连贯的切片重新聚合为更大的块。这种做法不依赖先验结构标签，适合处理格式混乱的语料。但它对嵌入质量较敏感，通常需要对聚合结果做人工校准。
这三条路线并不是互斥的。在很多真实场景中，合理的做法是：优先判断知识库是否存在稳定的结构元数据；如果有，使用结构化字段切分或层级式切分；如果没有，再考虑基于语义的动态聚合。无论哪种路线，目标都是在检索启动之前，先把“什么是一个完整信息单元”这件事定义清楚。
固定长度切分并非完全无用。对于行文流畅、主题连续的长文本，例如行业报告、技术白皮书、新闻综述，等长切分配合适当的overlap，仍然是一种成本低、实施快的方案。此时，chunk size主要影响两个指标：召回率和精确率。较小的chunk更容易精确匹配查询中的局部信息，但可能丢失必要上下文；较大的chunk上下文丰富，但容易引入不相关信息，使向量表示偏向泛化。
这种场景下，chunk size的优化才是有意义的。通常的做法是构造一份评估集，固定查询集合，对不同chunk size下的召回命中率和答案完整度进行对比，选择效果相对稳定且成本可控的区间。这里的“成本”包括向量化成本、检索延迟以及大模型token消耗。值得注意的是，chunk size的增大并不总是提升端到端效果，反而可能因为上下文噪声导致大模型答案偏离。
因此，把两块场景分开看很重要：
混用这两类场景，是大多数RAG项目在切分环节陷入低效的根本原因。一个项目如果花大量时间在固定长度切分上做参数扫描，却忽视数据本身的语义结构，本质上是在用错误模型去逼近一个已经被数据特征否定的假设。
为了更准确地理解chunk size问题，有必要厘清它与几个近邻概念的关系。
chunk size与overlap。 Overlap是在固定长度切分中为了避免边界信息丢失而设置的片段重叠。它只能在连续文本中缓解边界切分带来的问题，无法修复结构化数据中被切断的语义单元。换句话说，overlap是固定长度切分的补偿机制，而不是语义边界问题的解决方案。
chunk与embedding。 切分决定了什么文本被向量化，因此chunk的质量直接决定向量空间中的表示质量。如果chunk本身语义不自足，再强的嵌入模型也难以生成高质量向量。chunk是上游，embedding是下游，上游错了，下游无法挽回。
chunk与retrieval unit和context unit。 在更精细的RAG设计中，检索单元和送入大模型的上下文单元可以是不同的。检索单元通常更小，以提升匹配精度；上下文单元更大，以保证生成质量。chunk是进入向量库的最小单元，但并不一定是最终提供给模型的全部内容。理解这种分层关系，有助于避免把所有责任都压在一个chunk size参数上。
chunk size与信息熵分布。 信息熵分布刻画文本中信息密度的变化。chunk size作为一种长度参数，只有在信息熵分布近似恒定时才能稳定发挥作用。若信息熵分布不均，则切分决策应从长度维度转移到结构维度。这也是本文的核心视角。
在实际项目中，针对RAG切分环节，有以下几点工程建议值得关注：
先做数据分析，再定切分方案。 在设置任何切分参数之前，先对知识库做长度分布、结构类型、字段构成统计。如果发现长度方差极大或存在大量结构化标记，就应当优先选择结构化或层级式切分。
把切分逻辑视为可版本化代码，而非配置项。 切分策略会随着语料演进而调整。将切分规则写为独立模块，保留版本记录，便于回溯和对比不同切分策略的效果。
建立面向切分效果的评估集。 评估集应覆盖短查询、长查询、结构化查询和模糊查询等多种类型。评估指标除向量召回命中率外，还应包含端到端答案正确率，因为有些切分方案可能召回不差，但上下文不足导致生成质量下降。
关注切分后token预算。 即使采用结构化切分，也要对极端长度的片段做上限处理。对于过长的字段，可以引入二次切分或摘要压缩；对于过短的字段，可以聚合同类条目。目标不是追求等长，而是保持每个片段在语义自足前提下的token规模可控。
对多语言和混合格式保持警惕。 如果知识库同时包含中英文、图片、表格等元素，切分策略需要单独设计。表格类数据适合按行列结构切分，而文本中的图片说明应与其上下文绑定，避免因切分导致图文关系丢失。
RAG中的chunk size问题，表面上是一个参数选择问题，本质上是一个数据信息结构建模问题。它能否被当作参数来调，取决于知识库的信息熵分布是否均匀。对于新闻、论文这类接近均匀信息流的语料，固定长度切分结合overlap和效果评估是可接受的方案；对于FAQ、JSON、客服知识库等结构化或异构语料，强行使用统一chunk size等于无视数据中天然存在的语义边界。
更稳健的做法是：先定义“什么是一个语义自足的最小知识单元”，再选择结构化切分、层级式父文档切分或语义聚合等策略，将chunk size从“全局参数”转变为“数据驱动的结果”。这个转变带来的收益通常远超在固定切分框架内继续调参。
对技术团队而言，真正值得投入的精力，不是反复尝试512还是768，而是花时间把知识库的语义结构和检索模式分析清楚。切分策略一旦与数据的信息结构对齐，后续的向量化、检索和生成环节都会因此受益。