RAG 文档怎么切分？Chunking 策略与常见踩坑

把一份 100 页手册直接塞给 AI，既慢又不可靠；把它切得太碎，回答又会丢掉上下文。RAG 里的文档切分（Chunking），就是在“检索要精准”和“阅读要完整”之间找平衡。

它常常决定知识库能不能回答对，甚至比换一个更大模型更重要。

为什么必须切分

RAG 的基本流程是：把资料拆成片段、转成向量、提问时找最相关的几段，再交给模型回答。若整篇文档作为一个片段，检索粒度太粗；若一句话一个片段，模型又看不懂前因后果。

好的 chunk 应满足两点：内部信息完整，和其他 chunk 的主题足够不同。

常见切分方式

固定长度切分

按字符或 token 数每隔一段切一次，并保留少量重叠。实现简单、适合作为基线，但可能把一句话、表格或标题与正文切开。

按结构切分

按 Markdown 标题、HTML 段落、PDF 章节、表格或代码块切。它更符合人类阅读方式，特别适合制度、文档和技术手册；前提是源文件结构干净。

语义切分

当主题明显变化时再切开，而不是死盯长度。它的片段更自然，但实现和调参更复杂，处理速度也更慢。

实践里常用“先按标题/段落，再按长度兜底”的混合方式。

chunk 大小和重叠怎么设

没有一个通用数字。可以先从中等长度、少量重叠开始，用真实问题测试：

• 问题通常只需一个事实 → 片段可小一些
• 答案依赖前后条件、表格或步骤 → 片段要更完整
• 文本含大量重复页眉页脚 → 清洗比加重叠更重要
• 代码、合同等结构化内容 → 不要从函数或条款中间硬切

重叠能避免关键信息恰好落在边界，但过多会造成检索结果重复、浪费 token。若回答总缺少前提，先尝试增加结构完整性，再考虑扩大重叠。

别忘了 metadata

每个片段除了正文，还应保存来源文件、章节标题、日期、权限、产品版本等 metadata。检索时可以先过滤“只看当前版本”“只看这个客户可见的资料”，回答时也能提供清楚引用。

没有 metadata 的向量库就像没有书架编号的图书馆：能找到相似句子，却难以判断它是否最新、是否有权查看。

如何验证切得好不好

准备真实问题，逐个检查正确片段是否出现在前几条检索结果中。若没有，先看切分是否把答案拆散；若有但答案仍错，再检查提示词和生成模型。完整方法见RAG 评测指南。

总结

文档切分不是机械的预处理，而是 RAG 的知识组织设计。优先尊重文档结构，让每段携带必要上下文和 metadata，再用真实问题调节大小与重叠。切得对，模型才能在恰当的资料上作答；切得乱，再大的上下文窗口也救不了。