1. 检索结构这件事为什么值得单独写一篇做 RAG 做到第三个项目的时候我终于明白了一件事大部分 RAG 效果不好不是模型不行不是 Embedding 模型不行而是检索出来的上下文本身就不对。你用一个再强的 LLM喂进去的是一堆残缺、割裂、粒度错乱的文本块它也只能一本正经地胡说八道。我最早做知识库问答时跟大多数人一样走的是最朴素的路子把 PDF 按固定 token 切块比如 512 或者 1024overlap 设个 50然后全部丢进向量库。当时觉得挺省事模型回答看起来也有模有样。可真到了线上用户问一个稍微复杂的业务问题时问题就藏不住了。比如用户问的是“去年三季度华东区退货率异常上升具体是哪个品类、哪个仓库、哪一批订单导致的”我那个固定切块的索引根本找不到完整证据链。它可能分别从三个不同的 block 里召回了退货率、华东区、某个 SKU 的关键词但这些信息散落在不同块里LLM 拼都拼不完整。后来我开始认真研究父子索引这套做法也就是Parent-Child Index / Parent Document Retriever。它的核心思路其实就一句话用小文本块做精确召回用大文本块做上下文供给。听起来简单但真正工程化落地时里面的门道远比一句话多得多。这篇文章没有打算讲概念层面的 PPT 内容我会把它当成一篇工程实践笔记来写父子索引解决的是 RAG 哪个环节的什么问题、它和传统固定分块的根本差异在哪里、落地时有哪些坑、以及如果要上生产环境你该用什么样的检索流程和评估方式来验证它真的有效。如果你正在做知识库问答、智能客服、企业内部搜索这类项目这篇文章应该能帮你少走不少弯路。2. 固定切块的粒度困境和父子索引给出的解法2.1 块粒度为什么是 RAG 最隐蔽的玄学几乎每个 RAG 项目都逃不开一个灵魂拷问到底应该切多长。这个问题的背后其实是两组需求的直接冲突。第一组宿主的是检索命中率。Embedding 模型对文本的理解是基于语义向量的理论上块越短向量里包含的噪声越少召回精度越高。一条 200 token 的文本块通常比一条 2000 token 的文本块更容易在语义上聚焦。你去问退货率短块里如果正好有一句华东区退货率 2.8%它跟 query 的余弦相似度一定比一大篇文章高得多。第二组宿主的是生成质量。LLM 回答问题时需要的是完整的逻辑上下文。你只给它一句话华东区退货率 2.8%它并不知道这句话来自哪个时间段、哪个统计口径、是跟环比还是跟同比对比。没有上下文的话再强的模型也只能基于碎片信息瞎猜。固定切块的最大问题就是试图用同一个粒度同时满足这两个互相矛盾的需求。你切短了召回确实准了但喂给 LLM 的上下文太单薄你切长了上下文完整了但召回时整个块被无关段落稀释相似度被拉平命中的准确率又开始掉。很多人调 chunk_size 调了很久从 256 调到 1024 再调回 512最后发现只是把问题从答不对换成了找不到本质原因就是没有跳出一个粒度打天下的思路。2.2 父子索引是怎么拆解这个矛盾的父子索引的做法不是去选一个最佳块大小而是干脆把两个需求分开处理。整个结构分三层父块Parent通常按语义完整的单元划分比如一个章节、一个完整段落、一组关联紧密的句子。父块的 token 数一般比较大比如 1000 到 2000它的职责是给 LLM 提供尽可能完整的背景信息。子块Child从父块里继续切出来的更小单元可以是 200 到 500 token 的小段它的职责是参与向量检索用来跟用户 query 做精细的语义匹配。索引关系Parent-Child Link每个子块在入库时都必须记录一个 parent_id指向它所属的父块。这样检索命中的是子块但最终取出来喂给 LLM 的是子块对应的整个父块。用一句话总结工作原理拿子块去碰 query拿父块去喂 LLM。这样做的好处非常直接。用户问华东区退货率异常最匹配的可能是某个 300 token 的子块里面正好有统计口径和数字检索系统命中这个子块后通过 parent_id 找到包含它的那个 1800 token 的父块把这个父块作为上下文传给 LLM。此时 LLM 手里拿到的就不仅仅是一句孤零零的数字而是包括时间、范围、分析结论在内的完整材料。2.3 一个顺手又真实的例子我之前做过一个设备运维知识库文档是设备手册加故障排查记录混合体。设备手册很适合按章节切父块因为一个章节通常在讲一个独立的子系统故障记录适合按每一条记录切父块因为每条记录本身是一则完整事件。一开始我用固定 800 token 切块实测下来很稳定召回率也还行但用户反馈说答案是找着了可它没有上下文我看不懂它在回答哪个故障代码对应的操作。后来我改成父子索引父块按章节和故障事件切子块按 200 token 滑动窗口切。检索时用子块去匹配开机自检报错 0x1103这种具体 query命中率比我预想的高因为子块足够聚焦取回上下文时则整章整条地给回答质量立刻上了一个台阶。这个案例里还藏着一个容易忽略的点父块的切分不应该只依赖 token 数更要依赖文档本身的结构边界。能按章、按节、按条目切就优先按这些边界切而不是盲目地数 token 切。同样的道理如果你做的是企业合同问答父块按条款切就是比按 1000 token 固定切合理得多。3. 落地父子索引时最常踩的坑以及我的排查过程我并不想让你觉得父子索引是什么万能银弹。事实上它引入了一套新的关联逻辑和元数据管理如果处理不好坑比固定切块还要隐蔽。下面这五个问题我在真实项目里至少踩过四个。3.1 命中子块却返回整个父块导致上下文超限这是父子索引里最容易被低估的问题。父块设得太大比如一条文档章节有 3000 token检索系统一次性取回 5 个父块加起来 15000 token。如果选用的 LLM 上下文窗口只有 8K程序直接报错如果你硬截断又回到了上下文不完整的困境。我当时第一次遇到时第一反应是减小父块大小。后来仔细排查才知道问题不在父块本身而在于我检索的 top_k 没有针对父块做修正。子块检索因为粒度小、命中率高top_k 取 5 时命中的子块往往分散在多个父块里。你在子块层面可能取 5 个就能回答好但到了父块层面取 5 个父块就是 15000 token 的巨量上下文。解决方案有三个方向调整父块的最大 token 上限控制在 1500 左右这是比较通用的安全线检索时先取子块 top_k 更大一些比如 20 到 30然后做去重合并再按父块只取前 3 个对父块做一个粗筛比如先算一遍父块向量相似度或者用子块命中的父块按相关度排序后再截断。我实测最顺手的组合是子块取 top 20按父块去重后取 top 3父块限制在 1200 token 左右这样每次喂给 LLM 的上下文稳定在 3600 token 上下既能保证信息完整又不会撑爆窗口。3.2 父子关系断裂更新文档后子块的 parent_id 找不到这个坑在文档增量更新场景里非常致命。你有一个知识库每周都会更新文档整套索引流程是删掉旧的向量记录重新切块重新灌入。如果删除逻辑只删了子块向量没有同步删除父块的引用关系或者父块 ID 生成规则不稳定就会造成一类诡异的 bug检索命中了某个子块但通过 parent_id 找不到父块内容系统只能把子块自己丢给 LLM效果一夜之间退化回固定小块模式。我排查这个问题时发现根因在于我把父仓库和子仓库的 ID 用文档路径加序号生成而每次重新处理文档时文档章节序号可能因为增删内容而整体偏移。比如旧文档第三章是A 设备维护新文档插入了一章以后原来在第四章的内容变成了第五章父块 ID 全都变了但旧向量库里还残留着旧的子块记录。后来我把 ID 策略改成内容哈希。具体来说父块用摘要式哈希生成一个稳定 ID对父块文本做标准化计算 SHA-256取前十六位子块同样用自己的文本生成 ID同时记录 parent_content_hash。这样只要内容没变重新入库也能保住关系内容变了旧记录自然会被清理掉不会发生找不到父块的情况。3.3 元数据没有随父子关系一起传递这个坑在业务场景里比前两个更隐蔽。父子索引不只是把文本分成两段就完事父块往往带有大量业务元数据来源文档、章节号、页码、所属产品线、发布时间。子块是从父块切出来的按常理应该把父块的元数据一并继承。但很多人的入库代码是分开跑的父块入库时写元数据子块入库时只写了文本和向量没写业务字段。结果就出现了这样的问题检索命中了子块但无法告诉用户这条内容来自哪份文档、哪一页回答时也无法按产品线做过滤。我当时在一个制造企业的知识库里遇到就是这种状况用户问焊接工艺规范里对预热温度的要求检索命中了相关子块但返回的引用信息是空的无法溯源到具体标准文件。处理方式很简单入库时写一个统一入口子块的 metadata 从父块直接继承或者子块只存 parent_id查询时再 join 父块的元数据表。两种方案我都试过如果文档量在百万以下直接复制元数据简单粗暴超过百万条建议在子块表里只保留必要字段加 parent_id元数据查询走父块存储否则索引膨胀会很厉害。3.4 子块检索和父块召回之间缺少重排环节这是效果层面最影响体验的坑也是最难通过日志抓住的。子块检索返回的 20 条记录里真正跟用户 query 强相关的可能只有 3 条。如果你直接把 20 个子块对应的父块全部塞进上下文里面大半都是干扰内容。LLM 被大量弱相关文本干扰后轻则回答含糊重则把不同章节里的矛盾信息混合在一起输出看起来一本正经但全是拼接错误。我一开始也没加重排环节想着反正用的是向量相似度排序靠前的应该不差。但实际测试里发现子块因为粒度小语义上擦边的文本很容易混进 top 20。比如用户问退货率异常原因某个子块里讲退货流程操作指引居然也能排进前 20因为词面重叠度高但语义完全不相关。解决这个问题的常规做法是引入一个Cross-Encoder 重排模型比如 bge-reranker 这一类的模型。具体路径是子块向量召回 top 50再用重排模型逐条打分取 top 5 的命中子块然后去重映射到父块再按父块分数排序取 top 3。不要小看这一步它往往能把最终答案的准确率拉高 15% 以上。模型推理速度也不用担心因为重排只是在小集合上跑50 条的耗时通常在几百毫秒以内。3.5 混合检索时BM25 和向量的分数没有统一量纲到了真实业务里几乎不可能只靠向量检索。专用名词、编号、型号这类 query向量召回效果经常不如 BM25 精确匹配。所以成熟的 RAG 系统都会做混合检索向量检索 稀疏检索BM25一起上分数融合后排序。但父子索引做混合检索时有个特别容易翻车的地方父块和子块如果用了不同的分词索引会导致同一个 query 在两条链路上的命中和打分逻辑完全不一致。比如 BM25 主要跑在子块上向量检索也跑在子块上这一层还好可如果你把 BM25 跑在父块上向量检索跑在子块上那命中的粒度都不一样融合排序出来的结果一定是乱的。我的建议是父子索引的检索链路只作用于子块层也就是所有召回、融合、重排都在子块粒度完成最终取上下文时再通过 parent_id 上升到父块。这样整个流程是子块召回 → 子块融合 → 子块重排 → 映射父块 → 父块截取 → 构建上下文。如果真要在父块层也做检索比如针对长 query 的粗召回也应该把它作为一个独立的信号通道而不是跟子块的分数直接拼在一起。4. 从索引结构到检索链路一份可以直接套用的工程实现讲完了坑该说说怎么做了。下面这套流程是我在多个项目里跑通过的组合你可以根据自己的场景调整参数但整体链路结构基本可以照搬。4.1 索引构建的代码骨架大致分四步解析文档、切父块、切子块、写库。先按文档结构解析。PDF、Word、Markdown 都有对应的解析库这一步的重点是保留标题层级和段落边界因为父块的切分依赖这些结构信息。我一般会把文档转成统一的 JSON 格式每个节点带一个level字段表示标题层级。切父块时尽量按结构边界切。比如一个 Markdown 文档里有## 2.1和### 2.1.1优先把到下一个同级标题之前的整块内容作为一个父块候选然后判断 token 数。如果超过上限再按段落往下拆分如果不足下限可以考虑跟下一个段落合并。切子块时我的经验是用滑动窗口加 overlap窗口大小 300 tokenoverlap 50。也可以按句子边界切成 2 到 4 个句子一组这个要根据具体文档来试。子块不需要承担完整语义的责任它只要能精准命中 query 就行所以切碎一点没关系。写库时父块和子块各写一个 collection父块里存parent_id、文本、元数据子块里存child_id、parent_id、文本、向量、元数据。如果你用的是向量数据库可以只用一张表加一个parent_id字段来存子块父块内容单独再落一份查询时通过parent_id去取父块文本。# 伪代码示例描述父子索引构建过程 from typing import List, Dict def build_parent_child_index(document: Dict): parent_chunks chunk_by_structure(document) records [] for parent in parent_chunks: parent_id hash_text(parent[text]) child_chunks chunk_by_sliding_window(parent[text], size300, overlap50) for child in child_chunks: child_id hash_text(child[text]) records.append({ child_id: child_id, parent_id: parent_id, child_text: child[text], parent_text: parent[text], metadata: parent[metadata] }) return records4.2 检索链路的工程实现检索阶段分四步用小模型对用户 query 生成向量在子块集合里做 ANN 召回取 top 50在子块集合里跑 BM25 召回同样取 top 50对两路结果做分数归一化合并排序取 top 20用重排模型对这 20 条子块打精排分取 top 5通过 parent_id 找到对应的父块按父块的精排分数去重排序取 top 3把 3 个父块的完整文本拼成上下文配合 query 和 system prompt 一起交给 LLM。def retrieve_with_parent_child(query, vector_store, bm25_index, reranker, top_k20): # 1. 向量召回 vector_hits vector_store.similarity_search(query, k50) # 2. BM25 召回 bm25_hits bm25_index.search(query, k50) # 3. 分数融合示例为加权平均权重可按业务调 fused fuse_scores(vector_hits, bm25_hits, weight_vector0.6, weight_bm250.4) # 4. 重排 reranked reranker.rerank(query, fused[:20])[:5] # 5. 映射父块并去重 parent_hits expand_to_parent(reranked, max_parents3) return parent_hits这个流程里有几个值得注意的细节。分数融合时不要用绝对值。向量相似度是余弦距离的变体BM25 的分数是词频统计结果两者量纲完全不同。我的做法是把两路分数各自转成百分位排名然后加权求和。比如一条结果在向量召回里排第 5在 BM25 里排第 30那它的融合分就是 0.6 乘 5 的名次分加 0.4 乘 30 的名次分而不是直接把原始距离相加。还有一点重排模型的输入不要用原始 query 加整个子块原文。子块如果是 300 token20 条就是 6000 token重排模型一次推理的耗时和显存都扛不太住。实际工程里我会把 query 加子块的头和尾各截一段比如各 128 token拼起来作为重排输入。实测效果损失很小但推理速度能快近一倍。4.3 缓存与增量更新父子索引做增量更新时我强烈建议加一层内容哈希缓存。处理每篇文档之前先计算整篇文档的哈希如果跟上次处理时的一致直接跳过如果不一致就只重新处理这一篇文档及其关联的父子块并按 parent_id 删除旧记录。不要每次全量重建否则文档量上来以后整套流程的时间会从分钟级恶化到小时级。这个缓存层还可以帮你定位问题。排查为什么这条内容检索不到时我第一件事就是去看索引库里有没有这条父块的记录、子块的 parent_id 是否有效。把缓存命中日志和检索日志对齐了看问题出在写入阶段还是查询阶段一目了然。5. 别只看检索成功率怎么评估父子索引真的有效我见过太多人做 RAG 项目评估只停留在检索成功没成功也就是看召回的结果里有没有包含正确答案。这个指标当然重要但对 RAG 来说检索只是中间环节LLM 最终回答的质量才是用户感知到的一切。5.1 三层评估指标体系我建议把 RAG 评估拆成三层层级指标含义检索层RecallK正确答案是否出现在前 K 条检索结果里上下文层Context Precision喂给 LLM 的上下文中有效信息占比生成层Answer AccuracyLLM 最终回答与标准答案的匹配程度我需要特别强调 Context Precision。这是父子索引能否发挥作用的分水岭级指标。如果你的父子索引把父块设得过大检索倒是全都命中了但每个父块里只有 20% 的内容跟问题相关LLM 就会在大量无关信息里找答案准确率照样上不去。如果你的知识库有标注数据可以直接算 Context Precision对每一个 query人工标注出上下文中哪些句子是回答问题必需的然后算必需句子数除以总上下文句子数。这个指标跟最终 Answer Accuracy 的相关性通常比检索层的 RecallK 更高。5.2 我做 A/B 测试时的一个实用方法评估不只是离线指标最好的方式是做线上 A/B 或者至少做离线对比实验。我常用的做法是准备一份 100 到 200 条真实 query 的测试集每条 query 配一个标准答案。然后跑三组对比固定 800 token 切块 向量检索固定 200 token 切块 向量检索 重排父子索引父块按结构切子块 300 token 混合检索 重排。每组都走完检索 → 构建上下文 → LLM 生成回答全链路用同一个 LLM 参数只改检索链路然后分别算三层指标。我实际跑下来父子索引方案不一定在 RecallK 上碾压固定切块因为固定小块的召回也可能不错。但 Context Precision 和 Answer Accuracy 往往会明显领先原因就是父块提供了更完整的逻辑上下文。这也验证了做 RAG 不能只看检索仪表盘最终要盯的是生成质量。5.3 评估里面的坑离线评估最大的坑是测试集太少或者太偏。你拿 10 条 query 测出来的提升 20%没有任何统计意义。如果有预算我建议至少 200 条最好覆盖不同难度层次简单事实型问法、跨段落推理型问法、需要多步证据链的问法。父子索引对跨段落推理型问题的提升通常最明显如果你的测试集里全是简单事实型可能测不出这套方案的优势。另一个坑是不控制变量。你以为在测父子索引但实际上同时改了块大小、检索方式、重排模型、甚至底层 LLM最后效果变好了你根本说不清是哪个环节贡献的。做实验时每次只变一个变量记录下每个环节的变化值这样你才能知道自己这套 RAG 的瓶颈到底在哪一层。6. 把父子索引放进更大的 RAG 图景里一起看父子索引并不是孤立的技巧它其实是 RAG 检索结构中粒度分层这个思路的一个具体实现。顺着这个思路往后走你会发现还有不少值得尝试的优化方向。6.1 从父子到多层结构有些场景下父块本身还是太大或者父块之间的关系没有被利用起来。比如你做的是一套企业级多级制度文档章节下面还有小节、条款、附件两层结构就不够用。这时可以扩展成多层结构章节是祖宗块小节是父块段落是子块。检索时用最细的子块去精准匹配取回父块之后如果上下文还不够还可以继续向上回溯到章节块把更宏观的背景一起给 LLM。代价是索引量和查询复杂度的上升但收益也很直接LLM 面对跨章节问题时能拿到一个完整的制度体系而不是孤立条款。6.2 和图结构索引、Agentic RAG 的边界与配合GraphRAG 最近热度非常高它的思路不是把文档切块打成向量而是从文档里抽取实体和关系构建知识图谱回答问题时通过图遍历来聚合信息。父子索引和图谱索引的目标完全不同父子索引解决的是找到哪一段上下文最合适图谱解决的是这些实体之间是怎么关联的。两者其实可以共存。我做过的一个项目就有这个体会如果一个 query 涉及多篇文档间的关联比如用户问A 产品的技术规格变更会不会影响 B 产品的接口兼容性纯父子索引即使找回了多段相关文本LLM 也要靠自己推断它们的关系容易出错。但如果前置一个图谱层把 A、B 两个产品的关联边先找出来再把关联边两端的文档块通过父子索引完整召回问答准确率明显更高。这就是非常朴素的图谱粗筛 父子索引精取的组合。Agentic RAG 的思路则更进一步不满足于一次检索。先让 LLM 拆解问题第一次检索父子索引拿回上下文如果不够再触发第二轮检索。父子索引在这里扮演的是高质量上下文供给器的角色正因为它能稳定提供粒度合适的文本块Agent 才有底气决定再搜一次而不是怀疑当前的检索链路有问题。6.3 还有哪些容易忽略的细节最后我想提几个决定上限的细节。第一个是 Embedding 模型的选择。父子索引的两个层对 Embedding 的要求不太一样子块层更看重对短文本的区分度父块层更看重对长文本的语义概括能力。如果条件允许可以子块用短文本优化过的模型、父块用长文本模型各算各的向量。如果只用一个模型实测下来大部分通用模型都能用但要在测试集上确认它对 300 token 左右子块的效果没有明显衰减。第二个是 system prompt 的设计。当你把父块作为上下文后原本散落在多个子块里的信息出现在同一段上下文里LLM 有时会误以为这些内容是连续的。你需要在 prompt 里明确提示它上下文由多个独立文本块组成每个块可能来自不同章节回答时要区分不同块之间的边界关系。不加这句模型很容易把不同章节的内容合并推理出错误结论。第三个是索引更新的观测。父子索引比固定切块多了一层关系数据也就多了更多环节可能出现不一致。我建议做一个每日巡检任务扫描数据库中是否存在 child_id 有记录但 parent_id 查不到父块的孤儿数据以及是否存在同一个 parent_id 下子块数量异常少的情况。这两个信号能帮你提前发现数据清洗、文档更新过程中的隐性故障。我现在维护的 RAG 系统里父子索引已经不是可选项而是默认项。它没有带来什么戏剧性的效果翻倍但它让我在排查问题时思路清晰了很多召回不好我先查子块上下文不对我先查父块回答不对我再查重排和 prompt。这种可拆解的排查路径对于一个要长期演进的工程系统来说也许才是它真正最大的价值。