★ FEATURED ARTICLE 做RAG项目做到后面大家普遍会发现一个规律检索质量上不去问题不一定在Embedding模型也不一定在向量库的召回算法很多时候卡在文本分片这一环。我之前在一个知识库问答项目里调了整整一周的相似度阈值和重排策略效果始终不理想后来把分片方式从固定长度改成结构感知切分检索召回率直接涨了十几个百分点。文本分片Chunking就是这么个位置它藏在RAG流水线的最前端最容易被忽略但对最终效果的影响几乎贯穿全链路。这篇文章我会把自己在多个RAG项目里关于分片的实操心得拆开讲内容包括分片的核心逻辑、主流方案的适用场景、参数调优的实验方法以及我在生产环境里踩过的几个典型坑。适合正在做RAG落地的工程师、算法同学也适合刚接触检索增强生成、想知道分片这一步到底在解决什么问题的入门者。1. 文本分片为什么是RAG的命门很多人刚开始搭RAG会把精力放在向量库选型、Embedding模型调优上这本身没错但分片这一层如果处理不好后面所有环节都是空中楼阁。分片的本质是在回答一个问题什么粒度的文本单元最适合被检索、又能完整表达语义。1.1 检索质量与分片的关系RAG的工作链路可以简化成索引-检索-生成三步。嵌入Embedding模型负责把文本变成向量向量数据库负责召回大模型负责生成回答但这一切都建立在已经切好的文本块之上。如果文本块本身语义残缺向量表达就会失真检索召回的自然是不相关内容生成端再怎么优化也无济于事。我在实际项目中观察到一个规律当检索结果出现相关但答非所问时往往不是Embedding模型不够强而是文本块里混入了太多干扰信息。比如把一篇产品文档的多个功能模块切到同一个块里查询时向量匹配会把整个块召回大模型被迫在冗长文本里自己找答案准确性自然下降。反过来如果分片切得太碎单个块只包含一句话向量匹配精度会提升但语义信息严重不足大模型拿到的上下文太单薄生成的回答会缺乏依据甚至出现幻觉。这个矛盾就是分片设计的核心张力粒度小了检得准但上下文不够粒度大了上下文够但检不准。1.2 分片逻辑面对的核心问题分片这件事看起来简单实际要平衡的因素很多。首先是语义完整性一个段落、一个小节、一个表格应该在合理的边界处断开而不是在句子中间被腰斩。其次是信息密度不同文档的内容密度差别很大技术手册一句话可能包含多个关键实体小说一个段落可能只有环境描写用固定字数去套显然不合理。还有一个容易被忽视的维度是查询预期。分片策略要反过来想用户会怎么问这个问题如果用户的问题是这个API的请求参数有哪些那么合适的块应该恰好覆盖该API的完整参数说明如果用户问的是这个项目的整体架构是什么那就需要块能包含架构概述的完整段落。分片粒度本质上是对查询模式的一种预判和适配。我在项目中会把这几个问题在笔记里列清楚再决定用什么分片方案而不是上来就直接调参。这个前置思考会省掉后面大量的调优时间。2. 主流分片方案与选型分片的实现方案很多从最简单的固定窗口到基于语义的切分各有各的适用场景。我在生产环境里用过四类方案横向对比之后它们在信息保留度、实现难度、边界处理上差异很大。2.1 固定长度分片快速但粗糙固定长度分片是最朴素的方式设定一个chunk_size比如512个token按固定长度切分文本。它的优势是简单、可控、可预测索引速度快非常适合作基线方案。我早期搭RAG时就是先跑固定长度把整条链路跑通再逐步优化分片策略。但固定长度的问题也很明显它完全无视文本的语义边界一个段落可能在中间被截断一个完整的列表项可能被拆成两半。更麻烦的是固定窗口的分片位置是固定的同样的内容如果从不同起点切得到的分块完全不同这在处理重复文本时会造成向量分布偏移。实际使用时固定长度分片适合内容结构比较雷同、文本本身比较规整的场景比如新闻稿、短评论、公告类文本。如果是技术文档、合同、论文这些结构复杂的内容直接用它做生产环境的分片策略检索质量会很挣扎。2.2 递归字符分片通用性与可控性的平衡递归字符分片是目前RAG实践里比较稳妥的默认选择。它的思路是先用分隔符层级切分文本比如段落分隔符、换行符、句号、逗号按优先级逐层尝试直到切出的块大小满足要求。这种方案的优势在于它能尽量在语义自然边界处断开同时保留精确控制块大小的能力。我实际用下来只要目标文本是正常书写的中英文内容递归分片的效果都还不错。常用的开源框架比如做文档加载和切分的库里大多内置了这类实现默认分隔符列表和递归逻辑都已经过大量项目验证拿来直接可用。递归分片有两个参数需要关注一是分隔符的优先级顺序如果文本里有结构化标记需要优先识别比如Markdown的标题符号或者代码块标记需要把对应分隔符提到前面二是块大小的定义是按字符数、词数还是token数不同定义会影响实际效果。2.3 基于语义结构的分片适合内容结构强的文档如果文档本身带有明确的结构比如Markdown的层级标题、PDF的章节段落、HTML的dom节点就可以做结构感知的分片。我在处理长文档比如几十页的手册、规范、教程时强烈建议走这条路。做法是先把文档按结构解析成树状节点然后从叶子节点向上合并让每个块尽量包含完整的小节或段落。一个常见的策略是把每个二级标题下的内容作为一个候选块如果块太大再按段落或句子拆分。这样切出来的块天然具备语义内聚的特点检索时命中率会明显优于盲目切分。这种方案的主要成本是解析器的维护。不同格式的文档解析结果不一致比如PDF转出来的结构可能丢失原有的标题层级需要额外处理。另外如果文档结构本身就不清晰结构感知分片的效果也会打折扣。所以我会把方案定位成内容结构强时的增益项而不是默认项。我自己的选型经验可以做成一张速查表方便快速判断该用哪种方案文档类型推荐方案原因新闻、公告、短文本固定长度内容规整结构简单快速可用通用长文、网页正文递归字符分片兼顾语义边界与块大小控制Markdown/HTML/PDF章节结构感知分片保留文档层级语义块内聚性强代码、日志、CSV等结构化数据自定义正则/解析器通用分片对这类内容的边界识别很差3. 分片参数怎么定核心参数与评估实验确定了分片方案接下来就是参数调优。这个过程最容易走两个极端要么拍脑袋定一个块大小就再没动过要么一个参数反复试错但缺乏系统方法。我在实践中摸索出了一套相对完整的调优流程核心是让参数调整有依据、有效果反馈。3.1 chunk_size与chunk_overlap如何取舍chunk_size块大小和chunk_overlap块重叠是分片最核心的两个参数。chunk_size决定每个块的容量chunk_overlap决定相邻块之间的重合程度。chunk_size的选择需要考虑两个量一是Embedding模型的有效输入长度一般模型会把输入截断到一定token数常见的如512、1024或更长超过的部分实际是被截掉的所以块大小超过模型有效长度没意义二是大模型生成时对上下文的要求——块太小则信息不足块太大则检索召回的噪声变大。从工程角度我一般会把chunk_size设置成Embedding模型最大输入长度的60%-80%留出一些余量应对特殊字符、URL等导致的token膨胀。比如模型的接受长度是512个token我会先设成400左右作为起点。对于长上下文支持较好的模型可以适当放大但务必做效果验证而不是盲目追大。chunk_overlap的作用是缓解切分带来的语义断裂。当一个完整段落被切到两个块里两个块都因为缺失上下文而语义不完全。设置合理的overlap可以让边界处的信息在相邻块里重复出现降低信息丢失。但overlap不是越大越好过大的overlap会引入大量重复token一方面增加索引体积另一方面让检索的结果出现大量近似重复的候选块反而干扰排序。我常用的起点是overlap占chunk_size的10%-20%。具体场景里如果文本语义连续性很强长段落密集出现可以适度上调如果文本本来就短而零散overlap设小甚至不设都是合理的。3.2 评估维度检索召回与生成质量判断分片参数好不好最终要看两个层面的效果一是检索质量二是生成质量。检索质量可以量化查准率和召回率。我会构造一组查询-文档对每条查询对应一份应该被召回的相关文档然后跑检索流程看top-k结果里是否包含了目标文档。这一指标能反映检索系统能不能找对东西。生成质量则更难量化因为它是主观的。我通常采用两种办法一是人工阅读回答判断答案是否忠实于检索到的内容、是否完整、是否有多余信息二是用一组标准参考答案做对比看回答证词是否一致。这个环节很费人力但又是不可跳过的——因为检索质量好并不代表生成质量好有时检索返回了正确的块但大模型依然从别的块里汲取了错误信息。在实际项目中我会先保住检索质量把top-k召回率做到80%以上再去看生成质量。检索质量不合格时优先调分片参数和查询改写策略而不是急着换大模型。3.3 实验流程变量控制与结论沉淀参数调优不是单点试错而是有控制的对比实验。我把流程分成几步第一步固定Embedding模型、向量库、查询流程只允许分片参数变化保证每次对比的差异都来自分片本身。第二步每次实验只改一个变量。比如先固定overlap遍历chunk_size的候选值再固定最优chunk_size遍历overlap。避免同时改两个参数导致结果无法归因。第三步记录每次实验的完整结果包括召回率、回答质量评分、检索耗时、索引量。这些数据会成为后续决策的依据比如是否要引入结构感知分片、是否需要针对某些文档单独处理。我还会习惯性地把实验记录维护成表格每周回顾一次。时间长了会发现很多文档集的规律比如某个领域的文档更适合大块加少重叠某个类型的文档则相反。这些沉淀下来的经验比任何现成的配置模板都更有价值。4. 实操中踩过的坑与排查技巧分片的坑隐蔽且难排查因为问题往往不会直接暴露在报错信息里而是表现为检索结果不对劲的间接症状。我在这里整理几个自己踩过的典型坑以及对应的排查方式。4.1 语义断层一句话被拦腰切断这是我早期用固定长度分片常遇到的问题。一段论述的逻辑链条被切到两个块里结果查询时召回了后半段缺少了前半段的限定条件大模型回答时给出了过于绝对的错误结论。排查方法是把切分结果可视化打印出每个块的首尾部分看是否存在不完整的句子或逻辑断裂。如果切出来的块经常以然而因此此外这类关联词开头基本可以断定切分点破坏了语义连贯性。解决方案并不复杂一是在递归分片时把句子边界作为优先分隔符保证块边界尽量落在句号、问号之后二是设置合理的overlap让关联词和上下文能在相邻块里重现三是对确实需要精确处理的文档走结构感知分片。这个坑的难点在于发现——很多项目直到上线才因为回答质量被用户投诉回头排查才发现根因在分片。4.2 表格和代码块被拆散技术文档里表格和代码块是分片的高危区域。固定长度分片会把表格的行切断让列对应关系丢失代码块如果被切到不同的块检索到的只是一段残缺代码完全无法理解上下文。我在处理这类内容时会做专门的预处理在分片之前先识别出表格区域和代码块区域把完整的表格或代码块作为一个不可分割的单元单独成块。如果表格太大超过chunk_size再按行拆分并给每一块加上表头信息代码块则尽量按函数或类的边界切或者在块前加上注释描述它的功能。这个思路很重要分片策略不能一刀切要针对文档里的特殊元素设计保护机制。我自己写过一个简单的检测器先标记出表格和代码块的范围再交给递归分片绕过这些区域实测下来效果比直接套通用切分稳定得多。4.3 检索召回分布的失衡另一个隐蔽的问题是块长的分布不均。如果文档里有大段空白、重复的模板内容、无意义的签名信息固定窗口切分会产生大量噪音块挤占了有限的检索候选名额真正有信息量的块反而被淹没。排查时可以统计一下检索召回的来源如果top-20结果里有大量内容来自同一个位置或同一类模板文本说明块的信息密度出了问题。处理方法是对文档做清洗和去重把模板、页眉页脚、重复声明等噪音去掉再进入分片流程。另外可以给每个块写入元数据比如来源章节、文档类型检索时通过元数据过滤掉低价值块的干扰。5. 进阶面向业务的分片策略设计当分片的基本功扎实之后可以进一步根据业务场景精细化设计分片策略。这部分的重点已经不只是怎么切而是怎么切才更贴合业务需要。5.1 不同文档类型的分片策略差异不同类型的文档分片策略应该主动调整而不是用同一套参数硬套所有内容。对于产品文档和操作手册我倾向于用结构感知分片以功能模块为基本块保证一个问题对应一个完整功能的说明。用户问如何设置告警阈值时召回的是告警功能的完整操作段落大模型可以直接从这里提取步骤回答准确率很高。对于论文和长报告我会把摘要、图表、结论分开存储因为它们的目标查询完全不同。论文摘要适合作为独立的概述块结论部分则需要连同前文的证据链一起切不能只看孤立结论。对于对话记录和聊天日志分片时要格外注意对话者的交替尽量把一组对话回合作为一个块不要把一个用户问题和他的上下文答复拆开。这类文本的语义往往在跨轮的引用中才能完整理解。5.2 从小块到大块的扩展思路很多高级RAG实践里会提到从小块检索、从大块阅读的思路。简单说就是检索阶段使用较细粒度的分片保证精度生成阶段则把命中块附近的更大范围上下文一并交给大模型。这个方案在实践中非常有价值。比如我把文档切成小段落作为检索单元命中某个段落后自动向上找到它所属的章节把整个章节作为大模型的上下文输入。这样既保留了检索精度又给生成端提供了充足的背景信息。实现时需要维护好块之间的父子关系。我通常在文档索引阶段记录每个块的父节点ID和章节路径检索时先找子块再通过关系表拉取父块内容。这样的设计能让RAG在精确和丰富之间找到更好的平衡点。5.3 分片与元数据的配合分片本身是纯文本操作但和元数据结合之后能做很多增强检索效果的事情。常见做法是给每个块附加来源、标题层级、页码、章节名等元数据存入向量库时把它纳入过滤条件。比如用户的问题限定在某个章节范围内时可以先通过元数据过滤缩小候选集再做向量检索这样一来既提升了准确率也减少了向量检索的负担。还有一个技巧是把块的摘要存成特殊元数据检索时用摘要向量做粗筛用原文向量做精排。这种方式在一些项目里能显著提升检索效率尤其处理超长文档时收益明显。元数据的维护会增加索引构建的成本但如果想在生产环境把RAG做扎实这一步值得投入。6. 结合项目经验的分片调优实录讲完理论和方法我再用一个模拟项目把整个过程串起来展示分片调优的完整思路。这个项目是给一套内部知识库系统做RAG升级文档集包括操作手册、FAQ、产品说明共几千篇文档目标是让员工可以自然语言查询系统功能。项目初期我用固定长度分片chunk_size设为500overlap为50检索效果一般top-5召回率只有60%左右。后来我把方案切换到递归字符分片优先用章节标题和段落分隔符把结束标记放在句子边界上。只做了这个改动召回率就提升到了75%以上。接着我开始调chunk_size按300、400、500、600、800几组候选依次跑实验固定overlap为50。结果显示chunk_size在400时召回率最高800时因为块太碎片化反而下降。然后我固定chunk_size为400验证overlap在0、40、60、80时的效果发现overlap40时既保证了边界语义不漏又没有引入过多冗余是这组数据上的最优值。调完参数后我又针对操作手册类文档做了结构感知分片把每个章节作为独立的块。这一步让相关查询的准确率又往上走了一截。最后给FAQ文本增加了问题-答案配对关系检索到问题时把标准答案全文作为上下文保证了回答的一致性。这套流程前后花了两周其中大部分时间其实花在评估数据的准备上真正调参的时间反而紧凑。我这里想到一个很重要的心得分片调优不能只依赖自动评估工具好的评估数据集来自对实际用户查询的拆解。花时间把真实查询收集起来、分类、标注关联文档这个工作量值得做。7. 常见问题速查表与避坑清单最后整理一份速查表方便大家在遇到分片问题时快速定位方向。这里面的内容都是我实践过程中反复用到、验证过有效的方法。症状可能原因处理建议检索结果相关但过于宽泛块太大混入过多干扰信息减小chunk_size增加句子边界优先检索结果碎片化没有完整依据块太小上下文不足增大chunk_size增加overlap召回的块之间高度重复overlap过大降低overlap回答出现断章取义的结论语义被切分边界切断引入结构感知分片优化分隔符优先级表格/代码内容无法理解固定分片拆散了结构化内容单独预处理表格和代码块检索被低价值文本干扰模板、签名、页眉等噪音多分片前清洗文档配合元数据过滤同一文档的不同块响应不一致块内缺少上下文关联记录父子块关系检索后用大块扩展上下文关于避坑我更想强调几点不要盲目追求块大小与Embedding模型最大长度一致那通常不是最优解不要忽视overlap的存在感它是稳定性的重要来源不要在没有评估数据时凭感觉调参至少要准备几十条覆盖典型查询的测试集不要忽略对文档本身的清洗分片再合理输入源脏也没用。从我个人的项目经历看分片投入产出的性价比很高。它不需要更换模型不需要增加算力只靠策略调整就能带来明显的检索质量提升。这也是为什么我会建议每个RAG项目启动时先把分片方案和评估流程做好再去追求更复杂的重排序或微调。基础不牢后续优化都是在沙地上盖楼。这个领域后续还可以扩展的方向包括基于向量相似度做动态分片、结合意图识别做查询驱动的切分、在分片阶段引入语义去重等。但先把常规分片方案吃透积累出自己的评估方法论那些进阶方向才有意义。
阅读完成 · 觉得有帮助？
