文档切分（Chunking）
文档切分是 RAG 系统的第一步——把长文档切成合适大小的"块"，每个块会被单独检索。切分策略直接决定检索质量的上限。
① 一句话定义
文档切分（Chunking）是将长文档拆分成小块（Chunk）的过程。每个 Chunk 是 RAG 系统检索的最小单元——用户提问时，系统不是返回整篇文档，而是返回最相关的几个 Chunk。切分的好坏直接决定了"检索到的内容是否相关"——切太碎丢失上下文，切太大则检索不精确。
② 为什么重要
Chunking 是 RAG 系统中最被低估但影响巨大的环节。Embedding 模型通常有输入长度限制（如 512 Token），而且一个 Chunk 太大，里面混入太多无关信息会"稀释"检索精度；太小则缺少上下文，LLM 看到碎片化的信息很难生成好回答。Chunk 大小的选择是 RAG 系统的第一个也是最重要的超参数——改一下 Chunk 大小可能比换一个 Embedding 模型效果提升更大。
③ 核心机制
三种主流切分策略：固定大小切分（最简单，每 N 个 Token 切一刀）——快但可能在句子中间切断；基于语义的切分（按段落、句子、语义边界切）——保留语义完整性但计算开销更大；递归切分（先用大分隔符如段落，不行再用小分隔符如句号）——LangChain 的默认策略，在效率和语义之间折中。
关键参数：Chunk Size（每个块多大，通常256-1024 Token）、Chunk Overlap（相邻块之间重叠多少，通常10-20%——保证边界处的信息不丢失）。一个常见的最佳实践是：小 Chunk（256）+大 Overlap（20%）用于检索，检索到的小 Chunk 再扩展上下文（加前后文）发送给 LLM。这叫"小块检索，大块生成"。
④ 典型应用场景
技术文档问答用 512 Token 的 Chunk + 按代码块/标题切分；法律合同用较小的 Chunk（256）因为条款往往很精炼，每条都重要；客服FAQ可以直接把每个问答对作为一个独立Chunk。
⑤ 常见误区
误区：有一种"最佳 Chunk 大小"——没有。512 是常用起点，但最佳值取决于你的文档类型、Embedding 模型和下游任务。需要通过实验（A/B测试不同Chunk大小下的检索命中率）来确定。
更多
2024年出现了 Semantic Chunking（语义切分——用 Embedding 相似度的突变点作为切分边界）和 Agentic Chunking（让 LLM 自己决定怎么切）。支持者认为这些"智能切分"能大幅提升检索质量，批评者认为增加的复杂度和成本不值得——固定大小+Overlap 在大多数场景下够用。目前实践趋势是：简单场景用固定切分，高精度场景才投入语义/Agentic切分。
「文档切分是 RAG 系统的根基——切分策略决定了检索质量的天花板。没有银弹，但"小块检索、大块生成"是经过大量实践验证的黄金法则。
」