RAG 文档切分实战：chunk_size、chunk_overlap、递归分块与语义分块怎么选？

RAG 文档切分实战chunk_size、chunk_overlap、递归分块与语义分块怎么选RAG 回答不准确不一定是 Embedding 模型或向量库的问题。很多时候真正的错误发生在入库之前一条因果关系被从中间切断标题和正文分开表格被拆成无法理解的碎片。本文从“一个 Chunk 能否独立回答一个子问题”出发给出中文文档可运行代码、策略选择、参数扫描和评估方法。一、切分为什么会决定 RAG 的上限RAG 的检索单元不是整份文档而是切分后写入索引的 Chunk。查询只能召回已经存在的单元如果答案横跨两个互不相邻的 Chunk后面的向量检索、重排和大模型都只能设法补救无法恢复从未被一起检索到的上下文。图 1硬切分可能让原因与结果分离适量重叠可以缓解边界信息丢失。原创教学图Image2 生成。因此切分要同时满足三个目标语义完整一个 Chunk 尽量围绕一个主题或可回答单元检索可区分不要塞入太多无关主题避免向量表达被平均成本可控制Chunk 数量、重复内容、Embedding 次数和送入 LLM 的 Token 都不能无限增长。调整参数原始 PDF / Markdown / HTML解析标题、段落、表格与代码块按文档结构划分语义单元递归限制 Chunk 大小并增加重叠写入来源、标题和位置元数据向量化并建立索引查询检索 Top-K评估 Hit Rate、上下文覆盖与成本二、固定长度、递归分块、语义分块有什么区别图 2固定长度、递归分块与语义分块的工作方式和适用场景。原创教学图Image2 生成。1. 固定长度快但不认识文档结构每隔固定字符或 Token 切一刀实现简单、吞吐高适合结构弱的日志、聊天记录和短文本。缺点是边界可能落在句子、代码块或表格中间。它适合作为基线不适合作为所有知识库的默认答案。2. 递归分块通用文本的可靠起点递归分块先尝试用段落分隔符切块仍过大时再依次尝试换行、空格、标点最后才退化到字符级。LangChain 当前文档将RecursiveCharacterTextSplitter作为通用文本的推荐起点默认分隔顺序为双换行、换行、空格和空字符串。图 3LangChain 官方说明递归分块会尽可能保留段落、句子和单词。来源https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter3. 语义分块边界更自然但成本更高典型语义分块先把文本切成句子对句子或句子窗口生成向量再计算相邻位置的语义距离当距离突然升高时把它视为主题切换点。优点是边界更符合内容缺点是需要额外 Embedding、阈值依赖数据分布并可能生成过大或过小的块。因此仍要设置最大长度兜底。三、中文递归分块的可运行写法安装独立文本切分包pipinstall-Ulangchain-text-splitters中文没有稳定的空格边界应把中文句号、问号、感叹号、分号、逗号等加入分隔符列表并保留最后的空字符串作为兜底。fromlangchain_text_splittersimportRecursiveCharacterTextSplitter separators[, ,。,,,,,、, ,]splitterRecursiveCharacterTextSplitter(separatorsseparators,chunk_size600,chunk_overlap100,length_functionlen,add_start_indexTrue,is_separator_regexFalse,)documentssplitter.create_documents([text])fordocindocuments:print(doc.metadata[start_index],doc.page_content)这里的 600 和 100 按字符数计算因为length_functionlen。如果 Embedding 模型或生成模型按 Token 限制应使用与模型匹配的 tokenizer 计数不能把“600 个中文字符”误认为“600 Token”。另外chunk_overlap是目标重叠量不应假设所有输出块都精确重叠同样长度自然分隔符和章节边界会影响实际结果。四、结构优先不要把所有文档先压成纯文本Markdown、HTML、代码和解析良好的 PDF 本身就有标题、段落、列表、表格、函数和类。更稳健的流程是先按标题、标签或语法块切成有意义的结构单元把标题路径写进 metadata仅对超长结构单元再次做递归分块表格、代码块和图片说明尽量保持整体。图 4LangChain 展示先用 Markdown 标题保留 metadata再用递归切分器限制长度。来源https://docs.langchain.com/oss/python/integrations/splitters/markdown_header_metadata_splitter需要注意标题切分后overlap 通常只在某个章节内部再次拆分时出现不会跨越文档或章节边界。跨章节强行重叠反而可能把两个主题混在一起。Unstructured 的by_title策略也遵循相同思想遇到 Title 元素就关闭当前 Chunk让一个 Chunk 不同时包含两个章节的正文并可通过参数合并过小章节。图 5Unstructured 官方说明 by_title 会保留章节边界。来源https://docs.unstructured.io/open-source/core-functionality/chunking五、chunk_size 和 overlap 该设置多大图 6块大小和重叠都存在收益递减目标是形成可独立回答子问题的检索单元。原创教学图Image2 生成。chunk_size 太小句子间关系容易被拆散同一答案需要召回更多 Chunk索引条目和 metadata 数量上升但每个 Chunk 主题更集中精确问题可能更容易命中。chunk_size 太大上下文更完整但可能混入多个主题Embedding 向量表达被“平均”查询与块的相似度下降Top-K 中携带更多无关 Token挤占生成上下文重排成本也会增加。overlap 太小或太大重叠太小会增加边界丢失过大则会产生大量重复向量检索结果可能返回同一段内容的多个副本既浪费 Token也降低结果多样性。可用于第一轮实验而非直接上线的字符级起点文档类型chunk_sizechunk_overlap首选策略中文 FAQ、短知识点300–600 字符10%–15%标题/问答对优先技术文档、教程600–1000 字符10%–20%结构切分 递归兜底长报告、论文800–1500 字符10%–15%章节优先必要时试语义分块源代码按函数/类少量或不重叠语法结构切分这些范围只是建立实验网格。真正的单位应该由模型 tokenizer、文档语言和“一个证据片段需要多长”共同决定。有标题/章节代码文件没有明显结构否是能不能文档有可靠结构吗先按标题或 HTML 标签切分按函数、类或语法块切分使用递归字符分块对超长章节再次递归分块主题切换频繁且质量要求很高扫描 chunk_size 与 overlap能接受额外嵌入成本吗试验语义分块并设置最大长度用真实问答集评估六、怎样评估而不是凭感觉看几个例子准备一组真实问题并为每个问题标出能回答它的原文位置。对多组参数批量测试至少记录检索命中率 Hit RateKTop-K 中是否出现包含答案证据的 Chunk上下文覆盖率证据是否完整是否缺少限定条件、主语或因果链上下文精度召回内容中无关部分的比例答案正确性与忠实度LLM 是否依据检索证据作答成本指标Chunk 总数、重复率、Embedding Token、查询 Token、P95 延迟。实验时一次只改变一个维度。例如先固定策略扫描chunk_size400/600/800/1000找到合理区间后再扫描 10%、15%、20% 的 overlap。否则无法判断提升来自哪里。七、六个高频错误所有文件先转成纯文本标题、表格和代码结构全部丢失。把字符数当 Token 数不同语言和 tokenizer 的比例并不固定。overlap 越大越好重复结果会占满 Top-K。只评估最终回答无法区分切分、检索、重排还是生成环节出错。语义分块不设最大长度主题长期不变时可能生成超大 Chunk。更改切分后不重建索引Chunk 内容和标识已改变必须重新向量化并写入索引。总结RAG 切分没有万能数字但有可靠顺序保留文档结构与 metadata通用文本从递归分块开始用自然标点适配中文扫描 chunk_size 与 overlap而不是凭经验拍一个值只有主题边界复杂且收益能覆盖成本时再试语义分块用真实问答集同时评估命中、上下文质量和成本。最终标准不是“每块有多少字”而是召回任意一个 Chunk 时它能否携带足够、聚焦且可追溯的证据独立回答一个子问题。