做 RAG 这一年多我最大的感受是很多人把精力放在调向量模型、换 rerank却忽略了“喂给检索的每一块文本是否成块得当”这件事。文本分块质量不好后面接再多高级索引召回率和答案准确率依然很难看。今天这篇是“文本分块实现与高级索引”系列的第 5 篇聊透四种 Splitter 的原理、父子块的设计思路以及层级索引怎么落地。我见过太多项目接入阶段表现挺好到了真实语料就“断崖式下跌”。原因往往不是模型不行而是分块出了问题上下文被切太碎关键信息被拦腰截断或者块粒度太大导致向量检索维度被噪声稀释。这篇文章不会有任何保留四种 Splitter、父子块组合策略、层级索引的实现细节会一次性说清楚。适合正在做知识库问答、智能客服、文档问答系统的工程师也适合刚开始接触 RAG 的新手——只要你会跑 Python 脚本就能照着把整条链路搭出来。1. 为什么说分块是检索质量的第一道关卡1.1 分块粒度直接影响召回率与准确率分块的本质是把一篇长文档切成若干个“检索单元”。这些检索单元会被 embedding 成向量、写入向量库检索时用 query 向量去比对每个块的质量直接决定最终能召回什么内容。如果把一个完整的技术方案说明切成了半句话向量里全是“关于这个问题我们…”这种没有信息量的文本再强的 embedding 模型也无法匹配上用户的提问。这里有个经常被忽略的逻辑向量检索的匹配粒度本质上等于文本分块的粒度。你按 200 字一块切那 query 匹配到的就是一段 200 字的上下文你按一个句子切匹配到的就是一个句子的上下文。前者上下文更完整但噪声更多后者语义更聚焦但不一定能承载完整答案。这就是分块粒度与检索质量之间最直接的矛盾。从实际项目的数据看同一份语料、同一个 embedding 模型仅仅改变分块大小检索命中率可能相差 10~20 个百分点。这不是理论推导是很多项目在做评测时真实遇到的波动。分块不是“随便设一个 chunk_size 就完事”它是整个检索系统最重要的入口参数之一。很多人总觉得后续的 rerank 能把损失找回来但检索源头如果丢了信息后面任何环节都救不回来。1.2 分块不当的三种典型失败模式先说我在项目里反复踩过的三种坑你可以对着自查看看自己的管道是不是也有类似隐患。第一种是切太碎的语义断裂。比如技术文档里“调用该接口时需要先获取 access_token否则会返回 401 错误”这句话如果分块恰好从“需要先”和“获取”之间切开整个因果链就断了。用户问“为什么返回 401”匹配到的块里根本没有 access_token 这个词哪怕向量模型再厉害也只能靠运气碰到正确答案。第二种是块内容“空心化”。有些文档大量出现目录、页眉、表格边框等结构噪声分块之后块的内容几乎全是这些无意义文本。这一来浪费向量库空间二来会因为这些块彼此之间高相似度把真正有用的块挤出 TopK 列表。类似的问题我在扫描版 PDF 转出文档里遇到最多清洗步骤一旦偷懒后面全要买单。第三种是块与块之间的信息重复。重叠 overlap 设得太大比如超过 50%同一个知识点出现在多个块里检索时召回一堆重复内容占满上下文窗口关键信息反而没有位置放。有些团队为了“防止上下文断裂”把重叠调到很不合理的数值结果上下文窗口里一半都是复制粘贴的内容生成质量自然上不去。针对这三种失败模式最好的应对并不是靠某一个“万能”的分块参数而是根据文档类型选对 Splitter再配合父子块和层级索引兜底。这也是接下来三节要展开的内容。2. 四种 Splitter 的原理、参数和选型2.1 CharacterTextSplitter最简单的字符切分CharacterTextSplitter 是所有 Splitter 里最“直白”的一种在字符级别上做滑动窗口切分每 chunk_size 个字符串成一个块chunk_overlap 表示块与块之间的重叠字符数。它的优点是简单、可控、执行快缺点是完全忽略语言边界。英文里可能从单词中间切过去比如把 compression 切成 compressi 和 on中文虽然字符和词的边界相对清晰但也会从句子中间无征兆断开。这种 Splitter 比较适合文本本身很短、格式非常统一、对语义完整性要求不高的数据比如日志文件、纯字符串列表、按行组织的配置文件。在 LangChain 里调用它很简单但说实话在 RAG 场景我不会把它作为首选。它更适合用来理解字符切分的概念或者处理非常规整的数据。如果你真的要用记得至少把 chunk_size 和 chunk_overlap 调到一个肉眼看着合理的值别让块的边界落在明显不该断的位置否则后面检索阶段迟早要还债。2.2 RecursiveCharacterTextSplitter工程默认方案RecursiveCharacterTextSplitter 是工程实践里最常用的方案也是 LangChain 官方文档默认推荐的 Splitter。它支持“递归切分”先按一系列分隔符默认从 \n\n、\n、空格到空字符逐级尝试如果切出来的块还是超过最大长度就继续用更小的分隔符切直到所有块都满足长度约束。这个设计的精妙之处在于它天然地保留了语义的完整边界。对于一份从 PDF 转换来的长文本如果某段文字超过 chunk_size它会先尝试按段落切不行再按换行再不行按空格最后实在不行才从字符位置硬切。这种“尽力保留语义边界”的策略让它在绝大多数文档上表现稳定也正因如此它成了很多团队默认的第一步切分方式。有一个关键参数容易忽略chunk_overlap。它控制相邻两个块之间的重叠字符数。为什么要重叠因为在滑动窗口切分时如果两句之间被切开后一句的开头部分就失去了前一句的上下文。重叠可以让两边块都保留这段过渡信息减少上下文断裂。经验值是 chunk_size 的 10%~20%太大容易信息重复太小起不到防止断裂的效果。另一个容易被忽视的点是 separators 列表的顺序。顺序直接影响切分行为你可以为特定文档自定义。处理 Markdown 文档时如果能在默认分隔符前插入 “## ” 或 “### ”切出来的块会明显更贴合文档实际结构。这种自定义看起来不起眼但往往比换一个更贵的 embedding 模型更有效。2.3 TokenTextSplitter面向模型上限的切分方式TokenTextSplitter 按 token 数切分而不是按字符或单词。为什么需要它因为 LLM 的输入上下文限制以 token 为单位而不是字符数或单词数。如果你按字符切同一个块在 token 数上可能相差好几倍中文一个字符大概等于一个 token英文一个单词约等于 1.3 个 token更不用说混合代码的场景。为了保证每个块都能塞进 prompt 的上下文窗口按 token 切是最稳妥的做法。不过 TokenTextSplitter 也有明显短板按 token 切容易从任意 token 边界断开完全不管一句话或一个段落是否完整。所以它更适合和“递归式”分块思路结合。常见做法是分块主体仍用 RecursiveCharacterTextSplitter再另做一个按 token 的兜底校验或者在已经明确块内容后用 tokenizer 精确计算实际 token 数确保不会超出模型上限。这里有一个坑很典型不同的 tokenizer 对同一段文本的 token 数统计不一样。你用 tiktoken 统计出来的数值跟模型真正处理时的数量可能并不完全一致。所以不要只依赖某一个 tokenizer 的硬性结果要留一点余量。比如设 chunk_size500实际 token 数尽量控制在 450~500 之间避免跑到上限被截断导致输出不完整。2.4 MarkdownHeaderTextSplitter利用文档结构完成分块如果你的文档是 Markdown 格式很多知识库、README、技术文档都是MarkdownHeaderTextSplitter 就是很贴合场景的 Splitter。它不按字符长度硬切而是按标题层级划分块一个 H1 下的所有内容会归到同一个块H2、H3 继续往下细分每个标题下的内容自动成为独立的检索单元。这个思路非常符合人的阅读习惯也符合大模型回答问题时对信息组织的方式用户问某个子主题命中的块就是这个子主题的完整内容而不是从其他章节里拼凑出来的碎片。对结构清晰的技术文档来说这种 Splitter 的检索效果通常比 RecursiveCharacterTextSplitter 更好。我做过不少内部知识库项目切分后的块是否跟章节一一对应直接影响引用来源的准确率。它也有两个问题。一是 Markdown 的层级可能很乱有的文档 H2 下面 4000 字没有其他标题切出来的块可能过长需要二次切分。二是标题本身描述性不强时块的语义会偏弱。比如一个块整个都在 “H2: 设置” 下面用户 query 是“怎么配置超时时间”如果标题没有体现“超时”这个关键语义就只能靠正文里的关键词兜底。所以实际使用建议是先用 MarkdownHeaderTextSplitter 按结构切一遍再对超长块用 RecursiveCharacterTextSplitter 二次切分这个组合在我做过的知识库场景里几乎算黄金搭档。回到这一节的标题上来四种 Splitter 并不是零和关系它们解决的是不同维度的切分需求。我把关键维度整理成一张表方便对照Splitter切分依据最大优点最大短板最适合场景CharacterTextSplitter固定字符长度简单快速零依赖忽略语义边界格式统一的短文本RecursiveCharacterTextSplitter分隔符递归尽量保留语义边界对超长块仍需二次处理通用文档默认选择TokenTextSplittertoken 数精确控制上下文占用容易从句子中间断开代码、混排长文本MarkdownHeaderTextSplitter标题层级块与章节一一对应依赖文档结构完整性Markdown 知识库3. 父子块解决“粒度冲突”的关键设计3.1 父子块的基本思路和索引结构前面讲了分块粒度的矛盾块太小语义精准但上下文不完整块太大上下文完整但检索不够精准。父子块parent-child chunks是为了同时兼顾这两点而提出的设计。这个思路在很多 RAG 项目里被反复验证过它并不是什么花哨技巧而是针对“检索精度”和“生成上下文”这对天然矛盾给出的工程解。具体来说它把文档切出两种粒度父块和子块。子块很小比如 200 个 token 左右负责精确定位和召回父块很大比如 1200~1500 个 token 左右负责给大模型提供完整上下文。索引时子块做 embedding 并写入向量库但每个子块向量的元数据里保存对应的父块 ID。检索时query 向量只和子块向量比对命中某个子块后再根据元数据里的 ID 把父块内容取出来和 query 一起交给 LLM。这个“检索用子块生成用父块”的模式是父子块设计的核心。可以理解成查地图子块是街区级别的精确坐标父块是整个区域范围的背景信息。光有坐标你知道在哪但不知道周边环境光有区域图你不知道具体是哪栋楼。两者配合才能既快又准地定位。3.2 三种常见的父子块组合方式实际工程里父子块的实现可以分三种我按复杂度从低到高排一下固定长度父子块。父块和子块都用 RecursiveCharacterTextSplitter 生成父块 chunk_size 大、子块 chunk_size 小子块从父块内容中继续切分。实现最简单适用面最广适合语料格式不统一的情况。结构父子块。父块是每个标题下的整块内容子块是父块里按段落或句子继续切的小块。这种方式保留文档结构信息适合 Markdown 文档知识库引用来源可以精确到章节。窗口式父子块。不提前把父块切死而是用“窗口滑动”的方式动态标记上下文。比如对每个子块记录它在原始文档里的起止 offset检索命中时按预设窗口宽度向外扩展临时组装上下文。适合文档上下文关联很强的场景比如论文、技术手册缺点是组装逻辑更复杂。这三种方式我实测下来的体会是如果语料是结构明确的文档结构父子块效果最好如果对实现成本敏感固定长度最稳如果文档上下文关联很强窗口式的召回内容质量更高但组合逻辑要花更多时间调。3.3 父子块在向量库里的落法落地层面我通常给子块集合单独建向量索引每条记录包含子块文本、子块 embedding、父块 ID、子块 ID、子块在父块里的偏移位置。查询时先查子块集合再按父块 ID 取父块内容。父块集合可以只存内容不建向量索引省一层算力。这个设计的好处是子块集合可以做到很小检索速度更快而父块内容只在最后拼接 prompt 时用到不会占用索引查询带宽。框架层面LlamaIndex 里的 SentenceWindowNodeParser 这类组件本质就是父子块思想的工程化实现。你不一定需要从零手写但一定要理解底层的索引逻辑否则出了问题很难排查。我在项目里见过直接拿开源框架的默认参数跑结果父块 ID 没有持久化后面想按父块拼接上下文时才发现数据缺失只能重新跑一遍分块流程。写代码时有一段常用的父子块生成逻辑我贴个参考from langchain_text_splitters import RecursiveCharacterTextSplitter parent_splitter RecursiveCharacterTextSplitter(chunk_size1200, chunk_overlap100) child_splitter RecursiveCharacterTextSplitter(chunk_size200, chunk_overlap30) parent_docs parent_splitter.create_documents([doc_text]) for parent_id, parent in enumerate(parent_docs): children child_splitter.create_documents([parent.page_content]) for child in children: child.metadata[parent_id] parent_id # child 这里可以继续做 embedding并连同元数据写入向量库这种写法的好处是父子关系简单清楚后续做层级路由和上下文拼接都方便。我建议至少把 parent_id、章节路径、子块偏移这三项塞进元数据它们会在后面做引用溯源和结果排序时排上用场。很多人在这一步省事只存文本和向量等要定位来源时才发现所有块都成了“孤儿”那要返工的就不只是索引了。4. 层级索引从扁平向量库走向多粒度检索4.1 层级索引的整体设计层级索引Hierarchical Indexing在父子块之上再加一层“全局视野”的索引结构。它把文档库分成两个层级顶层是文档或章节的摘要向量索引底层是具体分块的向量索引。检索时先用 query 的向量去顶层索引里找出最相关的文档或章节再把 query 限定在该文档内部继续检索具体块。为什么需要这一层当文档数量很大、每篇文档又很长时扁平索引有两个致命问题一是向量检索的比对成本随块数量线性增长响应变慢二是用户 query 里的模糊概念可能同时命中多个文档的碎片造成上下文混乱。层级索引通过先“定域”再“检索”把大范围模糊匹配变成小范围精确匹配准确率提升非常明显。拿图书馆查书做类比找一本关于“文本分块”的书最直接的做法不是把所有书一页一页翻一遍而是先通过分类号或摘要索引定位到某一排书架再在书架里找对应的页码。层级索引做的就是“先定区域再查细节”这件事它天然契合多文档知识库的检索路径。4.2 层级索引的落地方案和关键参数实现层级索引核心是顶层摘要怎么生成。我一般有两种做法一是用 embedding 模型直接对文档前 N 个 token 或标题列表做嵌入速度快适合海量文档的批量处理二是让 LLM 对文档生成一句话摘要再对摘要做嵌入质量更高但有额外延迟适合对召回准确性要求高、文档量可控的场景。选择哪种取决于你的文档数量和响应时间预期。落地时有三个参数和设计点值得注意。第一顶层索引的粒度要与业务匹配全局知识库问答按文档建单文档深度问答按章节建统一粒度反而会两头不讨好。第二顶层命中的 TopK 不要太小我一般取 Top3~Top5 作为候选集合再在候选集内部做细粒度检索。这样能避免“一步错步步错”的级联误差。第三顶层与底层的 embedding 模型可以不同顶层用更强、更贵的模型负责跨文档区分底层用轻量模型负责文档内部的相似度比对。这种异构组合在精度与成本之间往往更划算。把父子块和层级索引结合是目前性价比最高的落地路径顶层文档摘要负责“定域”底层子块向量负责“定位”命中后取父块负责“补全上下文”。这个组合我在多个项目里验证过召回稳定性明显好于单层扁平索引。需要注意的是层级索引会引入第二轮查询的额外延迟如果对响应时间敏感可以考虑把顶层召回 TopK 和底层检索上限列成缓存或者做轻量级的内存索引。这个优化做不做得成取决于你们的业务量级但对大部分知识库问答场景来说值得一试。5. 实战效果对比与常见问题排查5.1 四套方案在同一份语料上的实测对比我某次做企业内部知识库问答语料是 300 篇左右的 Markdown 技术文档。我分别跑了四种配置只用 RecursiveCharacterTextSplitter、加 MarkdownHeaderTextSplitter 优先分块、再加父子块策略、最后加层级索引。评测用的是 40 条人工构造的问题集评估维度是召回命中率和答案完整性。整个过程花了两天主要是构造问题集和人工判定答案质量比较耗时。结果大致如下配置召回命中率答案完整性平均延迟只用 RecursiveCharacterTextSplitter72%中0.4s加 MarkdownHeaderTextSplitter 优先分块79%中0.4s再加父子块策略84%高0.6s最后加层级索引88%高0.8s这个对比不是绝对标准不同语料和评测集可能得出不同数值但趋势很明显从单一 Splitter 到“结构化分块 父子块 层级索引”每加一层都能带来可观的提升。分块和索引是一个组合问题没有哪个参数或工具能独立包打天下必须结合语料特征组合使用。5.2 几个常见问题速查我把实际操作中踩过和排查过的坑整理成一张速查表你可以直接对照现象可能原因排查方法检索召回一堆“废话”块分块时未过滤页眉/目录/导航检查块内容前 50 字符先做清洗再分块答案内容正确但来源归属错误块与块缺少元数据上下文把章节路径、标题写入块元数据同一问题召回结果不稳定父子块映射关系未持久化确认子块元数据中的 parent_id 是否唯一延迟随文档量线性增长扁平索引 块数量过大加层级索引顶层先召回候选集token 数频繁超上限按字符切但未按 token 约束改用 TokenTextSplitter 或事后校验这里我最想强调的还是元数据。parent_id、标题路径、章节偏移这些信息一定要在 embedding 和写向量库时一并保存。它们是后续做层级路由、上下文拼接、引用溯源的基础。不要为了省存储把这些字段丢掉后面补的成本永远比一开始就存高得多。这个问题我栽过一次三千多篇文档重新跑索引整整跑了一个晚上教训非常深刻。5.3 一套可以复制的标准化流程经过几个项目的打磨我现在做分块和索引基本遵循一套固定流程直接写出来给你参考先做文档清洗去页眉页脚、目录、脚注、重复空行统一编码。这一步没人爱做但不做后面全是问题。根据文档格式选主 SplitterMarkdown 用 MarkdownHeaderTextSplitter其他用 RecursiveCharacterTextSplitter。对超长块做二次切分用 RecursiveCharacterTextSplitter 把超限块切成子块。生成父子块映射子块记录父块 ID、章节路径、偏移位置。嵌入子块并写入向量库父块只存内容不嵌入或单独建索引。检索时先顶层召回候选文档再底层子块检索最后用父块拼接上下文。定期用典型 query 回归评测观察召回命中率和答案完整性变化。这 7 步看起来繁琐但它是目前我认为性价比最高、最不容易出 bug 的落地模式。折腾几次之后你会发现检索效果提升的关键往往不是换一个更贵的 embedding 模型而是把分块和索引这些基础环节做扎实。工具迭代很快但分块和索引的基本功不会过时。6. 最后聊点我的体会写这一篇的时候我一直在想为什么很多人宁愿调半天 prompt 也不愿意多花一小时检查分块设置可能因为分块看起来太基础、太无聊了远不如调模型参数来得有“快感”。但恰恰是这些基础环节决定了整个 RAG 系统的上限。模型选错了可以换分块策略乱了整个索引都要重来。我现在拿到一个检索项目第一件事永远是搞清楚两个问题语料是什么格式用户问什么类型的问题这两个问题想明白了Splitter 选型、父子块怎么配、要不要上层级索引答案基本就出来了。如果你正在做类似的项目我建议你也先别急着上最强模型花点时间重新审视一下你的文本分块和索引策略大概率会发现新的优化空间。这个系列到目前为止已经聊完了分块和索引的核心内容后面如果有机会我会再写一写关于 rerank、评估集构建和缓存策略的实战经验。到时候咱们继续一个个坑踩过去。