先在文档里翻了半天那一版没发出去的复盘记录想想还是把“父子索引”这个方案单独拎出来聊透。我们上一轮交付的RAG项目检索准确率从62%干到81%背后最大的一次架构调整就是它整个过程基本发在内部周会里今天整理成文给还在一块块试chunk_size的团队一个可抄的作业。先说一个很多文章会含糊带过、但真正决定成败的点父子索引不是简单的“大块套小块”而是一套把“检索精度”和“生成上下文”解耦的工程策略。它解决了RAG落地中最拧巴的一个矛盾——块大了召回噪音高块小了上下文残缺模型根本没法回答。下面我把设计思路、完整代码、调参经验和踩过的坑一次性写清楚。1. 先理解痛为什么块大小怎么调都不对劲很多团队第一次接触RAG时最先调的就是chunk_size。200、400、800、1200这么一轮试下来大概率发现一个魔咒召回的上限和答案质量互相打架。块调小比如切到200个token向量化后的语义非常聚焦相似度计算时命中率确实好看但取回的上下文经常是某个段落中间被拦腰切断的内容缺少前后交代模型推理时信息不够。比如一个关于“合同违约金计算方式”的问题子块只命中了“乙方需支付违约金”这几个字而违约金比例、起算日期全在父段落里模型只能硬答或者直接答错。块调大比如切到1000个token上下文倒是完整了可一个块里往往混着多主题信息向量化后的语义被稀释。你在知识库里检索“数据备份策略”vector相似度有可能把某个同时包含“备份”和“恢复演练”的大段落排到前面但真正的关键句淹没在无关叙述里召回精度直线下降。走投无路的时候我也试过各种“折中方案”重叠切块、动态切分、加粗标题加权……本质上都是在同一个粒度上修修补补。直到我把“检索单元”和“上下文单元”这两个概念拆开整个问题才豁然开朗。父子索引的思路就一句话用小块去匹配用大块去生成。小块负责精确命中语义大块负责提供完整上下文。检索时匹配的是子块真正送给大语言模型的是子块对应的父块。两个矛盾的目标各分配一个结构互不拖累。2. 核心设计与方案选型父子索引到底怎么组织数据2.1 父块和子块的分工与切分参数父子索引里有两种切分粒度别看都是“切块”定位完全不同。父块是整个检索体系的信息容器它的任务是“别丢上下文”。根据业务知识库的文档类型我通常把父块控制在600到1500个token之间。偏向操作手册、问答对这类结构化强的文档时取小值文档段落长、叙事性强的时候取大值。父块不需要严格统一可以按文档结构边界来切比如按二级标题或章节切这样语义完整性天然有保障。子块是匹配单元任务是把“别再带入噪声”。推荐控制在80到200个token之间。太小的子块没有足够的语义信息用于向量化太大又退回到传统大块的精度问题。实际项目中我常用150个token左右按句子边界切保证子块自身语义相对完整。两者通过一个映射关系关联核心字段就是一个parent_id。每个子块能且只能归属一个父块这个结构在关系型数据库比如SQLite或文档数据库里都非常好维护。2.2 为什么有效从语义检索的两个阶段看本质要理解这个方案为什么在数据上表现得这么好得从向量检索的两个阶段往下拆。第一阶段查询向量和所有块向量做相似度排序这个阶段真正决定“命中的块是不是真正相关的”。第二阶段被命中的块拼进提示词输入给语言模型生成答案这个阶段决定“上下文够不够模型做推理”。传统单块策略把这两个阶段绑定在同一份数据上要么牺牲精度保上下文要么牺牲上下文保精度。父子索引直接拆开——子块只解决“哪个位置信息相关”父块只解决“该把什么内容给模型”。牵一发动全身的耦合消失了两边各自调到最优解整体效果自然上一个台阶。还有一个常被忽略的点子块的向量化质量普遍比大块高。向量模型对文本中“主题一致性”的敏感度很高一个语义混杂的大段文本映射到向量空间后往往被拉到多个语义方向的中间地带和查询向量的距离体现不出真实相关度。而一个聚焦单一语义的子块生成的向量方差更小检索时的区分度明显更好。2.3 为什么不用多向量或上下文压缩方案决定用父子索引前我对比过两条别的路各有优劣确实值得说清楚。一种是用多向量方案比如一个父块放进多个子块向量检索时任何一个子块命中都能拉回父块。精神和父子索引相近但工程上要做多次向量化一份数据的embedding数量直接翻几倍存储和计算成本高不少而且管理和清除失效向量的复杂度也上去了。好处是匹配更细坏处是需要更重的资源来扛。另一种是上下文压缩/重排序路线先生成大块上下文再压缩或者检索完多路召回再让模型重排。对最终答案质量帮助很明显但每次查询都多一轮模型调用延迟通常增加1到2秒在高并发线上场景压力不小。上下文压缩类方案对实时性敏感的产品并不友好。父子索引胜在“轻量、可预测、好解释”。不需要额外模型调用索引构建和普通向量库构建基本同量级唯一多出来的是子块到父块的映射表。线上出问题还好排查——要么子块匹配错了要么父块映射错了定位链路很短。3. 工程落地从文本切分到检索链路的完整实现这一节把可直接抄的代码和配置摆出来。为了让代码更有通用性我没有绑定特定的大语言模型框架用的都是偏底层的开源组件便于你们迁移到自己的技术栈。3.1 数据切分先父后子两步走切分顺序上有个至关重要的技巧先切父块再从父块内部切子块。反着来会导致子块越界挂在两个父块之间映射关系维护成本高逻辑还很别扭大概率引发“一个子块对应多个父块”的脏数据。import re from dataclasses import dataclass, field from typing import List, Optional dataclass class TextNode: block_id: str text: str meta: dict parent_id: Optional[str] None children: list field(default_factorylist) def split_by_sentences(text: str, max_tokens: int 150): # 简化版分句逻辑按中文句号/感叹号/问号切分 sentences re.split(r(?[。!?]), text) chunks, current [], [] current_len 0 for sent in sentences: sent_len len(sent) if current_len sent_len max_tokens and current: chunks.append(.join(current).strip()) current, current_len [], 0 current.append(sent) current_len sent_len if current: chunks.append(.join(current).strip()) return [c for c in chunks if c] def build_parent_child_tree(doc_id: str, full_text: str, parent_tokens: int 1000, child_tokens: int 150): # 第一步切父块按段落边界优先 parent_segments [] # 生产环境建议换成真实段落切分这里用简单逻辑演示 paragraphs [p for p in full_text.split(\n) if p.strip()] buf for para in paragraphs: if len(buf) len(para) parent_tokens and buf: parent_segments.append(buf.strip()) buf para else: buf \n para if buf.strip(): parent_segments.append(buf.strip()) # 第二步每个父块内部切子块 parents [] for idx, p_text in enumerate(parent_segments): parent_id f{doc_id}_p{idx} parent_node TextNode( block_idparent_id, textp_text, meta{doc_id: doc_id, block_type: parent, seq: idx} ) sub_texts split_by_sentences(p_text, max_tokenschild_tokens) for jdx, s_text in enumerate(sub_texts): child_id f{parent_id}_c{jdx} child_node TextNode( block_idchild_id, texts_text, meta{doc_id: doc_id, block_type: child}, parent_idparent_id ) parent_node.children.append(child_node) parents.append(parent_node) return parents生产系统里父块的切分请务必先依赖文档自带的层级结构标题、章节、列表项没有结构再按长度切。这样父块的语义边界最自然子块命中的内容在父块里找得到的概率更高。3.2 索引构建向量库之外的映射表设计索引结构上不要只盯着向量库映射表同样是核心资产。向量库里存两种数据父块向量、子块向量。映射表可以放SQLite或MySQL里最简单的表结构就三列child_id、parent_id、doc_id子块到父块靠它做一次join。这里有一个工程决策需要你们根据预算权衡父块向量到底存不存存的好处是支持“父块级直接检索”某些宽泛问题上大块匹配反而更稳比如用户问“公司考勤制度包含哪几方面”坏处是embedding数量和存储都增加一倍。我的做法是存因为构建成本一次性的线上查询多一个可选的召回通道带来的灵活性值得额外存储。class ParentChildIndexBuilder: def __init__(self, embedder, vector_store, map_db): self.embedder embedder self.vector_store vector_store self.map_db map_db def add_document(self, doc_id: str, content: str): parents build_parent_child_tree(doc_id, content) for p in parents: # 父块向量如果走全量方案就存只做子块检索可不存 p_vec self.embedder.embed(p.text) self.vector_store.upsert( vector_idp.block_id, vectorp_vec, metadata{doc_id: doc_id, block_type: parent} ) for c in p.children: c_vec self.embedder.embed(c.text) self.vector_store.upsert( vector_idc.block_id, vectorc_vec, metadata{doc_id: doc_id, block_type: child} ) # 映射关系落库 self.map_db.add_mapping( child_idc.block_id, parent_idp.block_id, doc_iddoc_id ) self.map_db.commit()3.3 检索链路先召回子块再映射父块检索阶段是这套方案的精髓所在。我不建议一上来就只取子块top1工程上我会同时跑两个召回流程再做融合——子块召回为主父块召回兜底。class ParentChildRetriever: def __init__(self, embedder, vector_store, map_db, top_k_children6, top_k_parents3): self.embedder embedder self.vector_store vector_store self.map_db map_db self.top_k_children top_k_children self.top_k_parents top_k_parents def retrieve(self, query: str): q_vec self.embedder.embed(query) # 通道1子块检索召回精排的依据 child_hits self.vector_store.search( q_vec, top_kself.top_k_children, filter{block_type: child} ) # 子块映射到父块聚合去重 parent_ids set() for hit in child_hits: parent_ids.add(hit[metadata].get(parent_id)) # 注意如果向量store里没冗余存parent_id需要回查map_db # 这里演示回查map_db的写法 # parent_id self.map_db.get_parent(hit[vector_id]) # 通道2父块检索兜底宽泛主题 parent_hits self.vector_store.search( q_vec, top_kself.top_k_parents, filter{block_type: parent} ) for hit in parent_hits: parent_ids.add(hit[vector_id]) # 去重并取出全部父块内容 final_blocks [] seen set() for pid in parent_ids: if pid in seen: continue seen.add(pid) block_text self.map_db.get_block_text(pid) final_blocks.append({ parent_id: pid, text: block_text, score: self._aggregate_score(pid, child_hits) }) final_blocks.sort(keylambda x: x[score], reverseTrue) return final_blocks def _aggregate_score(self, parent_id, child_hits): # 简单策略父块分数 命中的子块最高分 related [h for h in child_hits if h[metadata].get(parent_id) parent_id] if not related: return 0.0 return max(h[score] for h in related)聚合分数时我用的是“最高分子块策略”因为实际效果比“平均分策略”好。一个父块下可能只有一个子块命中了核心事实但平均分会把那些陪跑子块的相似度拉下来导致这个本来不错的父块排名靠后。如果你们的业务问题跨度大、上下文广“加和策略”也可以试但注意它会偏向长父块需要另外加长度惩罚。生成阶段把最终父块按得分排序拼接进大语言模型的prompt。父块之间用清晰的分隔符隔开我在业务系统里用“ ”便于模型识别边界。4. 参数调优与实际效果这些配置直接决定成败4.1 父块子块的token配比调参阶段我系统性跑过几组token配比这里给出实验结论供你们少走一个多月弯路。父块token子块token召回命中率上下文完整度推荐场景6008068%低高频问答对、短会话知识100015081%高通用企业知识库150020077%高长文档、叙述性强内容200025071%极高政策法规、合同条款上面命中率数据来自内部测试集不同文档结构会有波动但趋势非常明显子块太小虽然语义精确但父块经常有多处子块不相关导致模型被无关内容干扰子块太大则退回单块机制。1000/150这组搭配平衡性最好也是我线上生产环境的默认配置。4.2 召回数量的权衡不是越多越好子块top_k取多少、最终父块取多少个我踩过一段时间“越多越稳”的坑。调了一场过后发现父块给到3到4个就已经覆盖绝大多数正确答案的上下文需求继续往上加模型在长上下文中的注意力会被稀释答案反而偏离。子块top_k建议取最终父块数量的2到3倍。比如最终送3个父块子块召回6到8个即可。父块去重后如果凑不满3个再用父块检索通道补齐。这个比例在延迟和覆盖之间比较经济。注意查询里加“父块检索兜底”通道后一定要在生成prompt里标记来源方便排查和后续引用。父块检索召回的内容如果和子块召回的父块存在部分重叠按文本去重后再入prompt。4.3 检索和生成的延迟分解线上系统对延迟极其敏感。父子索引因为要额外做一次“子块-父块”映射和聚合整体延迟比普通单块多20到30毫秒。这主要是多一次映射表查询造成的。如果是小规模知识库映射表可以直接缓存到本地内存内存够大连查询都省了。我生产环境用的是SQLite加一层字典缓存命中key为parent_idvalue为block_text实测下来映射耗时稳定在5毫秒以下。向量检索本身才是大头所以千万不要为了省映射时间牺牲了向量索引结构。4.4 评估方法离线先定标线上看反馈参数到底怎么调不能只靠“感觉答案变好了”。我的做法是定一个三层评估流程。第一层检索命中率。准备100个真实问题每道题标注“答案出在哪份文档的哪个父块中”跑检索看top3是否命中标注父块。第二层答案忠实度。让大模型生成的答案和标注父块内容做事实一致性核对可以用另一个强模型打分减少人工成本。第三层线上A/B指标。观察回答采纳率、用户追问率、返回“找不到答案”的兜底率。离线命中率和线上表现一般正相关但如果你们的知识库更新频繁、用户问题风格变化快就一定要在线上持续跟踪兜底率。有一次我们离线命中率到了88%上线后兜底率反而升了查到最后是线上用户问法口语化严重和测试集里的书面问题差别太大。所以测试集要刻意覆盖口语变体和偏门表达。5. 实战中遇到的坑与排查实录5.1 子块命中但对应父块缺失核心信息这是最容易出现而又最隐蔽的问题。子块精准命中了用户问题对应的句子但它的父块整体内容并不足以支撑完整回答。典型场景某个表格说明被切成了多行文本每行是一个子块但表格前面的表头说明和末尾的备注被切去了别的父块。排查方法随机抽取检索样本检查每个命中的子块在父块中所处的相对位置。如果大量样本的命中子块集中在父块后段说明父块的切分边界没有覆盖信息的前置依赖。解决办法是父块切分时引入“跨段合并”逻辑检测到某段是列表项、表格行或代码段时强制向上合并到邻近主段落而不是按长度硬切。说到底切分算法本身要尊重文本的体裁结构而不是只做长度切分。5.2 映射关系和向量库数据不一致增量更新做多了最容易出现的脏数据是向量库里还留着旧子块向量映射表里对应parent_id却已经指向新父块或反过来父块已删除子块成了孤儿。我有一段时间线上经常出现“检索到内容却拼不进父块”的错误后台日志一查全是孤儿子块。后来专门写了一个一致性巡检任务向量库的子块向量和映射表做每日全量对账发现就行程中必然有漏。实践层面的解法是给所有块记录一个版本号重建父块时把旧版本下的子块向量和映射记录全部标注为过期。查询时只取最新版本过期数据定时清理。不要用物理删除先逻辑失效再后台批量清理可以避免删除瞬间的查询不一致。5.3 多轮对话场景下父子索引失效父子索引在单轮知识问答中表现很好但遇到多轮对话会发现另一个问题第二轮问题的query可能没有指代消解比如第一轮问过“服务器配置标准”第二轮问“那CPU要几核”如果不带前文检索阶段根本不知道“CPU核数”和“服务器配置标准”的关联。这个问题我建议用两条腿走路。第一对话时做查询改写用一个轻量级的大模型把多轮对话历史压缩成一个独立query再做父子索引检索第二不改写的话就把检索会话历史里的关键实体和最新问题拼接成“扩展query”送进检索的同时保留原query做一遍检索两路结果融合。父子索引的数据结构不用变变的只是入口侧的query构造。很多人一开始怀疑父子索引在多轮场景是不是不行其实问题不在索引结构在查询构造。5.4 大规模知识库的资源与成本把控一个容易被忽视的工程现实是父子索引实际上产生了“一份数据、两套向量”的存储成本。假设单一子块向量大小为768维float32存储下每个向量占用约3KB10万个子块差不多0.3GB向量还好。可父块向量也、父块文本缓存、映射表、倒排索引元数据全加起来实际存储会是预估的三倍左右。成本敏感的团队建议分阶段部署第一阶段子块检索映射表不建父块向量第二阶段等业务确认有“宽泛主题”检索需求再补父块向量。这个顺序能避免一次性投入过大而且不会影响核心链路。我记得第一次全量构建时花了整整两天才把全部文档切分、向量化、映射落库。后来优化了切分算法和embedding批处理才把全量构建压缩到几小时内。但这不是说第一天构建慢就不可接受增量更新稳才是常态全量构建的一次性成本可以接受。6. 更适合你们业务形态的变体搭配6.1 小知识库纯子块检索懒加载父块如果你的团队维护的是十几个人的内部知识库文档量在几百份以内根本不需要跑两路检索。链路简化成只检索子块命中后按parent_id拉父块。父块不做向量化和检索只做文本存储。这个轻量版我在几个小项目里验证过效果完全不输全量方案部署成本却低一个数量级。6.2 大规模知识库父子索引混合关键字检索知识库大到几十万份文档时纯向量检索的局限性会逐渐暴露专有名词、编号、型号、代码关键词向量匹配远不如BM25这类稀疏检索准确。我建议在父子索引之上接入混合检索——向量跑子块召回BM25跑关键词召回两路结果各取前若干名统一进父子映射和分数融合。融合分数时我给BM25那路加了个0.2的权重系数不然后者频繁碾压向量结果覆盖是上去了但语义相关性反而下降。这不是固定的得按各自业务的语料特点自己标定。6.3 超长文档场景三级结构来救场有一类文档特别长比如技术白皮书或年报一个父块可能切到2000到3000个token子块召回后映射到一个信息密度很高的父块但整个父块尾巴塞满了和问题无关的内容。这时“父子两层”就不够优雅了。可以考虑三级结构再加一层“中块”子块映射到中块中块再映射到父块组。检索子块返回一个中块但如果中块的分量大再看它的上下文父组。这种设计在专业资料库里意义很大但对大多数业务知识库来说父子两层已经足够三层会让映射维护成本明显上升。7. 线上稳定运行之后回头看父子索引真正上线到现在最直观的变化不是指标而是整个项目的调试方式变了。过去调chunk_size调完上线看效果效果不好再调再上线每一轮全量索引构建和线上灰度都是不小的成本。现在检索效果的问题被分到了两个明确的位置子块匹配准不准父块映射全不全。排查链路短了人也不用靠猜。我再讲一个细节别忽略切分器里的子块重叠问题。子块之间如果重叠了句子那么一个查询可能命中两个相邻子块各自映射同一个父块虽然父块最后去重了但检索计分时同一父块被不同子块各加了一次分。这个重复加分会轻微歪曲父块之间的排序。处理方式很简单子块切分时严格不重叠或者聚合计分时按父块去重后再计分。我建议你们上线后一定要做一遍“查询-子块-父块”链路的可视化日志。我们内部做了一个小工具每次检索都记录query、命中的子块文本片段、映射了哪些父块、父块内容在prompt中的实际顺序。排查线上用户反馈时这条日志可以直接回看当时的完整决策链效率比黑盒调参高太多。这个方案看起来简单但值得投入时间打磨细节。如果你们团队正在被RAG的召回质量折腾从父子索引入手大概率会很快感觉“诶这套路对了”。后续想深入的话可以把重排序环节也接上来配合父子结构再往上提提精度。先做扎实再谈更多。