先说一个结论RAG 系统里的“分块”从来不是为了把文本切碎而是为了让“找回”这一步更接近“命中”。我见过太多团队在 Embedding 模型、向量库选型上反复折腾最后发现检索效果差问题根源居然出在分块上——不是切太碎导致上下文不完整就是块太大导致向量语义被“稀释”。这个系列写到第五篇前面聊过的向量化、索引结构、召回策略都已经铺垫到位所以这一篇专门把“文本分块 高级索引”组合拳一次性说透覆盖四种 Splitter 的选型逻辑、父子块的经典玩法、以及层级索引的落地方式。这篇文章适合正在搭建知识库问答、本地文档检索、或者做 RAG 优化的人尤其是那些已经发现“文档明明切了embedding 也算了但检索结果就是不对味”的朋友。全文不会贴大段听上去很厉害但实际上没法复现的架构图只讲我在真实项目中用过的方案、调过的参数、踩过的坑尽量做到看完就能直接对着代码实操。1. 四种 Splitter不是选一个“最好的”而是选一个“最不坏的”市面上的文本分块工具很多但真正常见的无外乎四种固定字符切分、递归字符切分、分词器感知切分、语义切分。这四种各有明确的适用边界选型的关键不在工具本身而在于你的语料形态和下游任务对“语义完整性”的容忍度。1.1 固定长度字符切分简单但容易“拦腰斩”固定长度字符切分是最朴素的方式——直接按字符数硬切比如每 500 个字符切一块块与块之间可以重叠。很多自研脚本第一版都会这么干因为逻辑一句话讲完循环、截断、存数组。但问题也恰恰出在“硬切”上。中文不像英文有天然的空格边界硬切很容易把一句话从中间劈开甚至把完整的“因为……所以……”切进两个块里。Embedding 模型对不完整的语句非常敏感一个被拦腰斩断的句子在向量空间中往往既不像前文又不像后文检索时就会出现“关键词命中了但上下文完全对不上”的尴尬结果。所以我的观点是固定长度字符切分只能作为 baseline或者用在那些语义依赖不强、按行组织的非结构化文本比如日志、参数说明上。一旦你的语料是文章、报告、产品文档这类连续叙述型文本这个方案基本可以提前排除。1.2 递归字符切分最务实的默认选择递归字符切分是目前综合性价比最高、应用最广的方案LangChain 里的RecursiveCharacterTextSplitter就是典型代表。它的核心思路是维护一个分隔符列表比如[\n\n, \n, 。, , , , ]按照优先级从高到低尝试切分——先尝试用段落切段落太长再用句号切句子还太长再用逗号切直到满足 chunk size 约束。这种“先粗后细”的策略最聪明的点在于它保证了切分结果在可能的情况下优先保留大粒度语义边界。段落是完整的语义单元其次是句子最后才是短语。如果一段话长 800 个字符、目标 chunk 是 500那递归切分切出来的大概率是两个语义相对完整的句子而不是从句子中间断开。我实测下来对中文技术文档用[\n\n, \n, 。, , , , , , ]这个分隔符序列配合 chunk_size500、overlap80召回效果明显优于固定长度切分。原理解释也很简单中文的句号、感叹号、问号是天然语义边界优先在这些位置切分Embedding 得到的向量会更集中地表达完整意图。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 目标块大小按字符计 chunk_overlap80, # 块间重叠保留上下文衔接 separators[\n\n, \n, 。, , , , , , ], ) chunks text_splitter.split_text(document)需要特别注意的一点是递归切分不感知语义它只感知符号边界。如果文档里出现了连续几页没有标点的代码块递归切分照样会把代码从中间切断。这在后面“常见问题”里我会专门说怎么处理。1.3 分词器感知切分面向 LLM 上下文的“精确制导”第三种 Splitter 是分词器感知切分核心思路是把文本按 token 数切分而不是按字符数。这背后有一个很实际的原因LLM 的上下文窗口是按 token 计的不是按字符计的。你切出来的一个块在字符数上可能是均等的但转成 token 以后长度差异可能非常大——中文尤其明显一个汉字可能对应 1–2 个 token一段英文可能 4–5 个字母才 1 个 token。LangChain 里有TokenTextSplitter或者搭配 tiktoken 一起用的方式底层就是调用了 OpenAI 的分词器精确计算每个块的 token 数量确保不会超出一个块能嵌入的最大 token 数。实际上很多 embedding 模型比如 text-embedding-3-small都有最大输入 token 限制通常 8191 token如果分块按字符数切而不检查 token 数很容易出现部分 chunk 被模型截断的情况——这部分文档等于白切了。分词器感知切分比较适合两类场景一是你的下游模型对 token 上限非常敏感二是你的语料本身就包含大量中英混排内容。但它的缺点也很明显慢非常慢。对一个几万字的文档做 tiktoken 编码耗时能到固定字符切分的几十倍。而且分词器感知切分同样存在语义边界问题——它只是精确控制了长度并没有真正理解在哪里断句最合理。1.4 语义切分最“聪明”但也最贵语义切分是近几年开始流行的一种思路它不像前面几种那样根据符号或 token 数来切而是根据 embedding 的向量差异判断“哪里语义发生了明显变化哪里就该切开”。具体实现有很多种常见的做法是把文本切成小的候选段然后对相邻候选段的 embedding 计算余弦相似度当相似度低于某个阈值时认为发生了主题切换把这个位置标记为分割点。LangChain 的SemanticChunker就是基于这个思路通过计算句子级别的 embedding 相似度分布来决定断点位置。我在一个产品 FAQ 检索项目里试过语义切分效果确实比固定长度切分好特别是处理问答对这种天然语义边界清晰的语料时几乎能做到“一个问题一个块”检索命中率有明显提升。但代价也很直接计算成本高每个候选段都要过一遍 embedding 模型阈值难调相似度阈值偏高会切得过碎偏低又会把两个不同主题硬粘在一起首轮耗时长不适合做大规模文档的一次性批处理。所以我对语义切分的判断是它适合处理高质量、中低规模的核心语料比如产品手册的核心章节、FAQ不适合一上来就对整个资料库无脑上用。实际的工程里很多团队把它用作“二级精修”——先用递归切分打底再用语义切分对某些还不够好的块做二次分割。1.5 四种分块器的对比总结一览分块方式核心依据优点缺点适合场景固定长度字符字符数简单、快、零依赖语义边界被破坏日志、结构化短行文本递归字符切分层级分隔符速度快、语义边界优先不感知真实语义中文/英文文章、报告的默认首选分词器感知token 计数精确控制 token 长度规避截断速度较慢、无语义边界判断对上下文窗口敏感的 RAG 场景语义切分向量相似度切分点贴合语义转折计算成本高、阈值难调FAQ、产品手册、精品语料这四种 Splitter 不是互斥关系我在正式项目里最常见的组合是递归字符切分 小 chunk 做父子块 语义切分做核心语料的精修。下面进入正题。2. 核心难点为什么推荐“父子块”模式而不是单一大分块聊完成熟的 Splitter接下来必须要解决一个几乎所有 RAG 系统都会遇到的两难问题——也就是我标题里说的父子块Parent-Child Chunk。这个问题不解决你前面分块分得再漂亮检索质量也上不去。2.1 矛盾的本质小块保召回大块保上下文假设你要处理一份 3000 字的说明文档。如果全切成 200 字的小块检索精度会很高——用户问“如何配置超时时间”小块的 embedding 和用户 query 的 embedding 往往相似度很高能精准定位到那一段。但问题在于小块被召回之后给 LLM 的上下文只有 200 字根本不够推理出完整答案。比如文档里描述了某个配置项的限制条件、默认值、注意事项这些内容分散在不同位置LLM 只看到一小块很可能给出片面的回答。反过来如果全切成 1000 字的大块上下文是完整了但检索精度又会下降——大块的 embedding 是整段内容的“平均语义”用户的问题对应的只是其中一小部分语义平均之后和大块向量的相似度就被稀释了。这也是很多团队做完向量检索后觉得“召回了但不够准”的根本原因之一。父子块模式就是专门来解这个死结的用小块去做检索、用大块去做生成上下文让检索精度和上下文完整性同时达到要求。2.2 父子块模式的实现逻辑父块是大块比如 1500–2000 字符或 300–500 token子块是小块比如 300–500 字符或 100–200 token。子块都是从父块里切出来的每个子块记录自己的父块标识。流程拆解下来是这样先把文档用递归字符切分器切出大块作为父块对每个父块再切成小块作为子块每个子块连同父块的引用信息parent_id一起写入向量库查询时用 query 去匹配子块的向量找到 top-k 子块根据上报的子块 parent_id关联到对应的父块把父块的完整文本注入 LLM。# 伪代码示意 parent_splitter RecursiveCharacterTextSplitter(chunk_size1500, chunk_overlap200) child_splitter RecursiveCharacterTextSplitter(chunk_size400, chunk_overlap50) for doc in documents: parents parent_splitter.split_documents([doc]) for parent in parents: children child_splitter.split_documents([parent]) for child in children: child.metadata[parent_id] parent.metadata[chunk_id] vectorstore.add_document(child)实际检索的时候就变成了“小步快跑、大了再取”的流程query 先进子块向量里找精确命中的内容再顺着链条拉出完整的父子上下文。这样 LLM 拿到的输入既包含精确命中的片段也拥有了完整的前因后果。我在一个几十万字的中文产品手册 RAG 项目里对比过单一大分块和父子块的回答质量效果差距很明显父子块模式下回答的“引用来源”更加精准幻觉率明显下降。因为注入 LLM 的上下文确实覆盖到了多个相关约束条件模型不再需要靠猜测来补全信息。2.3 父子块的大小怎么定有没有经验值大小设定没有一个放之四海皆准的值但有几个基于实操经验的锚点可以参考。对中文场景我通常建议子块控制在 300–500 字符之间父块控制在 1200–2000 字符之间。这个区间的依据是子块低于 200 字符语义单元常常被切得七零八落embedding 表达不完整子块高于 700 字符检索精度优势会被削弱又滑回大块的老问题父块建议上限是“LLM 平均可正常解析的长度”——不需要塞满全文而是刚好覆盖问题相关的 2–4 段内容即可太长反而稀释了对核心片段的注意力。实际调整时还要结合一个指标你的平均 query 长度。如果用户的问题普遍很短10 个中文字以内子块可以偏小如果 query 通常是带描述的长问句子块可以适当放大。没有二测数据前先从子块 400 字符、父块 1500 字符起步然后用测试集评估召回率上下浮动 20% 左右调整通常都能找到可接受的点。2.4 父子块实现时的三个关键陷阱第一个陷阱是父块和子块的切割边界不一致。如果你没有先切父块再切子块而是先把全文切成小块、再反向合并成父块就可能出现“子块的内容跨了两个父块”的错位问题。所以顺序一定不能反先切父块再从父块里面切子块。第二个陷阱是 parent_id 的存储类型设计。很多人用自增数字当 ID看起来没问题但换库或增量更新时很容易重号。建议直接用内容 hash 或者文档 ID 组合来生成保证可追溯、可去重。第三个陷阱是向量库里没有把父块文本一起存进去。子块只存了向量和 parent_id等检索到了之后如果再去原始文档里现找父块全文成本会非常高而且容易找到错的位置。正确做法是写库时直接把父块全文作为元数据或者独立文本字段一起写入检索时直接就能取用不需要二次读文件。3. 层级索引把“查什么”分成不同的检索粒度分块和子母块解决的是“一块一段文本怎么存”但真实业务里知识库往往不是单一层级的——它有文档级信息、有章节级信息、有段落级信息甚至还有关键词级别的重要信息。一个 query 进来如果只在一个粒度上检索经常会遇到“粒度太大匹配不准、粒度太细碎片化严重”的问题。这就是层级索引Hierarchical Index发挥价值的地方。3.1 层级索引的核心架构三层渐进式检索我落地过的层级索引方案对知识类文档通常分三层从粗到细逐级收敛文档层L1以整篇文档为单位做 embedding存文档摘要、文档标题、文档类别等粗粒度元数据。这一层用来快速圈定“用户的问题属于哪几篇文档”也是做过滤和路由的第一道闸门。块层L2以子块为单位做 embedding这是召回的主力负责精确定位到段落级别。实际检索时绝大多数 query 的召回主力都是这一层。片段层/句子层L3把小块进一步拆到关键短语或核心句子建立倒排索引或轻量向量索引用来做更细粒度的“原文引用定位”和“证据抽取”。三层之间的关系是query 先经 L1 做文档范围的硬过滤再进 L2 做向量召回最后根据命中结果到 L3 里抽取具体的证据文本。整个过程像一个漏斗越往下越精细也越接近最终给模型和用户展示的答案依据。3.2 不同层级适合的索引类型不只是向量说到层级索引很多人第一反应就是“都上向量库”但实际工程里层级之间往往需要形态各异的索引方式并非只有向量一条路。L1 文档层最适合的是倒排索引 摘要向量的组合。文档数量通常不多几千到几万篇这种规模用 BM25 跑文档级过滤是很快的而且关键词命中往往比向量更精确。L2 块层适合用向量索引 metadata 过滤。一方面向量可以衡量语义相似度另一方面通过 metadata比如所属文档 ID、章节路径可以快速过滤到 L1 圈定的范围内。L3 片段层适合用BM25/全文检索倒排索引因为到了句子和关键短语这个粒度用户真正关心的往往是精确的术语名、配置参数、错误码这些恰恰是关键词检索最擅长的。完全没有必要让三个层级都用向量库。相反混合检索向量 关键词配合层级结构比单一层级只靠向量投票要稳得多。3.3 实现一张可落地的层级索引表具体落地时我用过一种很直观的存储结构把层级关系直接体现在一张表里。每一行是一个索引单元除了向量字段外还包含字段含义示例doc_id文档级唯一 IDdoc_0001chunk_id块级唯一 IDchunk_0001_003parent_id父块 ID父子块用chunk_0001 (父块级 ID)level层级标识1 / 2 / 3content当前层级的文本内容子块原文metadata文档标题、章节路径、标签{title: 配置手册, chapter: 3.2}有了这张表之后一个典型 query 的检索流程就变成了这样先拿 query 在 L1 文档层里跑一次 BM25 或摘要向量检索拿到候选文档集合和它们的 doc_id 列表在候选文档集合内用 query 在 L2 块层跑向量检索按相似度取 top 20 的子块对召回的 20 个子块做重排比如用 Cohere Rerank 或简单的交叉编码器筛选出 top 5 的最相关块根据 top 5 子块的 parent_id 映射到父块同时到 L3 片段层做一次精确匹配抽取关键证据句子把证据句子、父块文本、来源元数据一起拼接成 Prompt 上下文交给 LLM 生成。这个流程跑下来既保证了召回宽度又通过层级逐级收敛压低了最终上下文里的噪声。在多轮对话场景下尤其好用因为每一轮用户的追问都带有前文的指代层级索引天然能定位到同一个文档范围内的更精确段落。3.4 构建层级索引的成本与耗时控制层级索引的构建成本是三个索引层累加的处理大规模文档时需要考虑执行顺序和耗时控制。我的建议是先构建 L1 文档层再做 L2 块层最后做 L3 片段层。这样在做 L3 时可以直接利用 doc_id 和 chunk_id 的已有映射关系减少重复计算。同时如果文档是增量更新的不需要全量重建三套索引——只要把变更文档的 doc_id 找出来删除所有关联 chunk 后代数据、重新执行三层切分即可。另外一个明显的耗时点是 embedding 计算尤其是 L2 层涉及子块数量较大时一次性调用接口容易被限流。实务上可以按优先级把高频核心语料先建索引低频冷门文档排队把构建过程做成异步任务而不是在主服务的启动流程里同步全部完成。综合来看层级索引不是“多建了几套索引那么简简单单”它改变了检索的路径——从“一次向量召回到文本”变成了“先定位文档再定位内容再抽取证据”对回答质量和检索效率都是结构性提升。4. 如何做技术选型不同数据体量下的组合方案从上面的内容不难看出Splitter、父子块、层级索引在实际项目中是层层套在一起的。但也不是一个项目就必须把这一整套都上齐具体方案还要看你的数据规模和应用场景。这一节专门把选型逻辑理清楚。4.1 小体量场景文档总数 1000单篇 5000 字这种规模下构建三层索引显然没有必要属于杀鸡用牛刀。我建议直接走最薄的可行路线Splitter 用递归字符切分chunk_size 按 500 来不启用父子块因为单篇文档不长500 字一个块基本足够 LLM 理解上下文索引层面直接用向量库存一层子块关键词工具完全不需要。这种简单方案的好处是代码量小、构建速度快、排错也直观。一个小团队半天时间就能把链路搭通。这个体量下真正值得花时间的不是索引方案而是选一个对中文理解好的 embedding 模型——这往往是决定检索效果上限最关键的一环。4.2 中等体量场景文档总数 1万–10万单篇 5000 字以上这个规模是最适合“父子块 两层索引”的场景。建议组合是Splitter 采用“递归字符切分 分词器感知”双轨制先按段落粗切再用 tiktoken 把超长段落拆成均匀的 token 块启用父子块子块 300 字符、父块 1500 字符层级索引用 L1 文档摘要层 L2 子块层两级就够了L3 片段索引可以不做为什么不是三层全上因为中等规模下 L3 带来的精度提升并不足以抵消它增加的建设复杂度和查询耗时。大部分 query 到 L2 子块层就已经能召回足够好的证据段落L3 是锦上添花但如果团队人力紧张最优先省掉的就是这一层。4.3 大体量/高并发场景文档总数 50万或多租户到了这个量级就不是“把方案做复杂”的问题而是“怎么把资源用在刀刃上”。三层索引大概率是要上的但会有更多工程化的考虑文档层 L1 必须用倒排索引 metadata 过滤来快速收窄范围不然每次 query 都要在几十万条向量里做暴力检索延迟和成本都不可控L2 层重点优化向量库的索引类型使用 HNSW 或 IVF 这类 ANN 索引并合理配置 ef_search 和 nprobe 参数L3 层用于精确证据定位避免生成时再度检索带来的“上下文漂移”父子块在这个量级下不再是可选项而是控制上下文的必需品它会显著降低每次注入 LLM 的 token 数也直接影响到成本。如果业务是面向多租户的比如每个企业一个独立知识库还要额外加一层租户隔离的 doc_id 前缀设计确保检索时不可能跨租户查询到内容。这些在中等规模场景往往考虑不到但一旦用户量和数据量上来就变成非常现实的稳定性问题。4.4 缓存与增量更新层级索引的“维护账”最后提醒一个容易忽略的点索引建完不是一劳永逸。文档更新时如果旧的父块/子块索引没删除干净检索结果里就会出现两个互相矛盾的旧文本严重干扰 LLM 对答案的把握。我推荐的增量更新方案是每次文档变更时先根据 doc_id 删除该文档的全部旧索引记录再重新切分构建新的子块和父块。这样操作虽然会多删一点点无关数据但换来的是数据一致性上的绝对安全。尤其要注意的是切分器的 separator 列表如果有调整必须全量重建所有块的索引——因为旧的块是按旧分隔符切的新旧块之间的父子关系会彻底错位绝不能只做增量补丁。踩过这种坑之后我学乖了凡是改过切分参数一律全量重灌向量库不要心疼那点重算时间。5. 常见问题与排查技巧实录实操过程中有一些问题几乎每轮都会踩我把记得住的、踩得深的集中整理出来当速查表用。5.1 文本总被从“半句话”切断这是最典型的问题多半是分隔符列表里没有把标点符号放在句号、问号前面或者干脆用的固定长度切分。排查方法很简单抽样打印 50 个 chunk逐个看有没有明显的“句子断尾”。修复方式是换用递归字符切分并确保分隔符优先级按段落 句子 逗号 单词 字符来排列。如果还是被切断优先检查是不是语料里的标点是全角/半角混用的情况——全角句号“。”和半角句点“.”在分隔符列表里要同时出现。5.2 chunk_size 调得很大但召回结果仍然很碎这个问题往往不是分块问题是 embedding 模型对长文本不敏感。超过一定 token 长度后模型的 attention 分布会逐渐扁平化向量表达的信息越来越像“平均词袋”。解决方案就是把 chunk_size 降下来比如从 1000 降到 400或者启用父子块模式让检索在子块上完成而不是直接在大块上检索。我实测下来对大多数开源 embedding 模型chunk 超过 512 个 token 后检索质量会明显下降。如果你在对长文档做段落级别召回别迷信“塞得越多越好”该用小块的场景就要用小块的方案。5.3 父子块映射失败LLM 拿到的是不完整的父块出现这种情况几乎都是因为建块顺序颠倒或者父块与子块切分器参数不一致。比如父块用了 chunk_size1500、overlap200但子块是从父块文本的原始位置重新切的切分边界就会对不上。解决办法是子块拆分必须基于父块的原文内容而不是原始文档的全局位置并且在写入向量库时用父块的 chunk_id 作为 parent_id 的主键不要自己拼接字符串。建议你在本地提前跑一个单元测试专测“父块是否包含全部子块”的映射关系再上生产。5.4 同义词/近义词召回偏弱如果你的知识库里回答用的是“过期时间”而用户 query 用的是“超时时间”向量召回经常匹配不到。这不是分块能解决的而是没有做同义词扩展或混合检索的问题。对这种情况我建议在 L2 块层之外增加一级 BM25 检索通过倒排索引先把包含“超时时间”这个关键词的候选块找出来再和向量召回的结果做融合比如用 RRF 或按分数归一化加权。层级索引的 L1 层此时也能帮上忙——如果文档摘要层里包含了同义词映射表能提前把候选文档范围扩大。5.5 构建索引太慢API 被限流这个坑基本出现在大规模文档构建时。解决办法一是把嵌入调用改成异步批量比如用 OpenAI SDK 的批处理接口二是做并发度控制找到对端 API 的限流阈值把并发数压到阈值以内仍能保持较快速度。另外一个容易被忽略的点是重复计算。如果文档里有大量重复段落比如模板文档的公共章节建议先对段落文本做 hash 去重相同内容只算一次 embedding能省下不少调用量。我在处理重复率较高的产品文档时这一步经常能省掉三成左右的计算时间。6. 最后的实践经验总结这几套方案我从第一阶段就踩过不少坑最后真正沉淀下来可复用的经验大概可以归纳成三句话。第一分块不是“文本处理问题”而是“检索精度与上下文完整性的权衡问题”。所有选型、参数调整都要落回到这个权衡上思考不要简单地比哪个切得更快、哪个块数更少。第二父子块和层级索引不是花哨的架构而是工程实用主义。它们解决的都是具体问题——上下文被打断、召回碎片化、多粒度检索方向不明确。如果你的项目对回答的“证据来源强度”有要求哪怕数据量不大也值得考虑先上父子块再按需做层级索引。第三任何参数设置都别拍脑袋。chunk_size 到底用 300 还是 800不取决哪个听上去更合理而是取决于你的测试集上召回率与回答质量的评测曲线。建议从线上一开始就保存每个 chunk 的切分参数和检索得分留痕数据每周复盘一次对比评估后慢慢形成你自己知识库的“最优参数记忆”。最后再分享一个小技巧把一个小的基准测试集固定下来里面放 20–30 条有代表性的问题每次改动分块策略或索引结构以后都拿这组问题跑一遍对比召回文档和最终回答答案。这套评估集比什么花哨的指标都管用能帮你在微调参数时快速判断改动到底有没有效果。文本分块和索引这层做到位RAG 系统的整体表现大概率不会差——因为这一层才是真正决定“检索上限”的地方。