RAG切片策略固定长度、递归字符、语义切分、结构感知四种方式对比为什么Chunking这么重要假如你正在准备一场考试有一本500页的教材。你的复习策略是把书撕成很多小卡片每张小卡片写一个知识点考试前根据题目去抽卡片如果你的卡片切的太细—每张只有一句话那每张卡片的上下文不完整如果你的卡片切的太粗—每张抄一整章—那么信息虽然完整但是你要看的内容太多真正需要的那句话藏在一大堆无关文字里面RAG里面的Chunking面对的就是这个核心矛盾chunk太小单个片段语义不完整chunk太大检索出来的内容信噪比太低四种主流切分策略策略一固定长度切分最简单粗暴的方式按照字符或者token数固定切分每个chunk固定512个token切完拉倒优点是实现极简不需要理解文档结构。缺点同样明显它完全不管语义边界可能把一句话从中间切断把一个完整的论述拆成两半实际工程中这种方式通常只用于原型阶段的快速验证不适合生产环境策略二递归字符切分这是目前工程实践中最常用的基础策略Langchain的RecursiveCharacterTextSplitter就是这个思路核心思路是按照优先级尝试不同的分隔符切分。先尝试用段落分隔符切分如果切出来的chunk还是太大再用换行符切分还是太大就用句话切分以此递归直到每个chunk都在目标大小以内相比固定长度切分这种方式更倾向于在自然语言的语义边界处断开同时还能控制chunk的上限大小在大多数普通文本场景下这是一个不错的默认选择策略三语义切分更进一步的方式不依赖固定分隔符而是真正理解文本语义在“话题转变”的地方切分具体做法是把文档按照句子分割然后计算相邻句子之间的语义相似度当相似度出现明显跌落时就认为这里发生了话题转移在此处切开优点是切分结果的语义完整性最好每个chunk内部讨论的主题相对聚焦。缺点是需要对全完做Embedding计算处理速度慢成本更高而且切出来的chunk大小很不规则结构感知切分当文档有明确的层级结构时比如md文档有标题层级、法律文件有条款号、代码有函数边界按照结构切分往往是最优选择比如一篇技术文档每个二级标题下的内容作为一个chunk。这样每个chunk天然对应一个有意义的主题检索精准度往往最高对于代码文件按照函数或者类的边界切分对于PDF报告识别出页码和章节标题再切分—这些都属于结构感知切分Overlap被低估的关键参数讲Chunking绕不开一个关键参数overlap重叠设想一段文字中间某句话恰好落在两个chunk的边界前半句在chunk1后半句在chunk2当用户提问这句话相关的内容时单独检索到chunk1或者chunk2拿到的都是一半信息不完整生成的答案就会出错Overlap的解决思路是相邻chunk之间保留一段重叠的内容。比如chunk大小设为512tokenoverlap设为64token那么chunk2的前64个token和chunk1的后64个token是完全相同的这样边界附近的信息在两个chunk里面都有备份不管检索命中哪个都能拿到完整的上下文overlap的代价索引体积增大检索结果可能出现重复一般推荐overlap大小为chunk的大小的10%-20%Chunk过大、过小各有什么问题Chunk过小单个chunk的语义不完整孤立一句话往往没有足够的上下文让模型理解。比如检索结果里出现是的这种做法符合规范符合什么规范完全不知道。同时chunk太小意味着要切出大量chunk索引规模膨胀检索速度也会变慢Chunk过大每个chunk里面包含的话题太多和用户问题的相关性被稀释。假设chunk是2000token的长段落用户只关心其中50个token的内容但是这2000个token都会被塞进Context占用宝贵的上下文窗口同时让模型的注意力难以聚焦。另外chunk越大它的向量表示就越平均化语义越模糊检索精确度越低关于chunk大小的经验值没有通用的最优大小但实践中一些常用的参考范围是对话型问答场景通常在256-2000token这些都是估计需要根据实际业务效果调整实际项目里面怎么选策略决策框架文档有清晰的结构章节、标题、条款优先考虑结构感知切分按照自然的结构边界切分语义完整性最好文档是普通散文、没有明确结构用递归字符切分配合合适的chunk size和overlap文档质量要求极高话题切换频繁考虑语义切分代价是需要更多计算资源和时间快速验证原型固定长度切分够用记得上线前换掉