父子检索如何工作，为什么在 RAG 中使用？
未标记
考查重点：小块匹配与父段扩展。小子块用于精准匹配，命中后按 parent_id 取完整父段，去重并限制扩展预算，兼顾定位与完整上下文
本题目录
参考答案
核心回答
父子检索把用于匹配的小块与用于阅读的较大上下文分开。入库时保存父段或章节，并把其中的子块写入检索索引，记录子块到父对象的关联；查询先命中子块，再按关联取回相应父段，去重后组织成生成上下文。
这样做是为缓解粒度矛盾：小块主题集中，便于定位具体内容，但可能缺少标题、前置条件或相邻说明；父段能补足这些背景。它适合答案经常跨段、上下文依赖强的文档，但父块过大会增加噪声与成本，因此仍要控制范围、版本、权限和总预算。
怎样建立并使用关联
先根据标题、章节或业务记录形成有意义的父对象，再在父对象内切出子块。父对象保存正文、版本与原文位置，子块保留 parent_id、自己的位置及检索所需内容；向量索引主要负责找到子块，文档存储负责取回父内容。
查询命中多个子块后，收集父标识并合并重复父段，同时保留命中位置。四个子块可能只对应两个父段，返回量不能简单沿用子块 TopK；父段总长度也要受上下文预算约束。
例如文档某节前面规定适用型号，后面给出故障处理步骤。用户问其中一个具体操作时，子块可定位步骤，返回这一节父段则能补回适用条件，避免把别的型号流程混用。父对象可以是一个段落组或章节，不必整份文件。
与相邻块扩展有什么区别
相邻块扩展沿同一文档中的顺序位置补前后内容；父子检索沿预先建立的层次关系取上一级对象。一个窗口可能跨主题边界，而一个父段由结构定义范围。两者可以组合，但不是所有“多取一些上下文”都属于父子检索。
也有按命中的子节点比例决定是否向上合并的变体，例如 LlamaIndex 的 Auto Merging Retriever。它不是每命中一个子块就无条件返回整篇原文，采用时需要理解具体合并规则。
什么条件下会适得其反
父段过大或主题混杂，会把大量无关内容一并带入。此时可以重划父段、只取命中区域的必要背景，或比较先重排子块再扩展与先扩展再筛选的成本和质量。
父子关联还需随文档更新保持一致。新子块引用旧父段，可能补回过期条件；父段删除后子索引残留，会出现悬空关联。查询和更新应按文档版本维护关系，并保留定位信息。
子块能访问不等于父文档全部可访问。父对象取回后检查实际可见范围，必要时只返回授权部分。相关性分数也不会因为扩展就自动变成整个父段的可信分数。
怎样验证值得引入
使用相同文档与问题，比较仅返回子块、相邻扩展和父子返回，观察跨段证据是否完整、答案限定条件是否正确、引用能否定位，以及上下文 Token、读取延迟和重复率。小块并非天然更准，父段也并非越大越好，优势要落在当前问题集上。
参考资料
国内：JavaGuide：RAG文档处理与切分：小块与父段的分工，解释为什么检索粒度和生成上下文可以分别设计。
国内：RAG与检索：候选已多仍答差、重排取舍：依据父子关联、子块索引和父段去重的组织，说明正文中命中子块后回取父内容及控制返回数量的过程。
国内：RAG与混合检索工程：分阶段预算和评估：参考父子检索与邻块扩展的区别，说明正文中范围由结构关联定义且仍要保持版本和权限的要求。
国外：LangChain：Docugami中的Small-to-Big检索：依据 Small-to-Big 的子块索引与父对象存储，说明正文中分工存储并通过关联标识读取上下文的实现。
国外：LlamaIndex：Auto Merging Retriever：依据层次节点按命中比例自动合并的机制，说明正文中 Auto Merging Retriever 是可选返回策略的边界。
WeKnoraGo
基于 WeKnora核心回答
父子检索把用于匹配的小块与补充完整语义的父段分开。WeKnora 在入库时保存文本父子关系，检索服务按 ParentChunkID 补取上下文，聊天合并阶段再把命中结果展开为父正文；图片的 OCR、描述子块也能沿关系找到正文和更大的父段。这样可以在命中具体文字或图意后，补回解释它所需的条件。
父块按层次关联补取，邻块按文档顺序补取，关联块按已保存的关系补取，三者共同服务上下文组装。服务层返回结果和完整聊天链路还经过不同处理，不能把其中一处补取或过滤等同于最终交给模型的内容。
上下文扩展前，混合检索分别收集向量与关键词列表，通过可配置权重的 RRF 按名次融合，并按 ChunkID 合并候选；两路结果都为空时返回空，存储检索出错时返回错误。只剩一路时走该路的去重和分数处理，不能当作两路仍在融合。后续父子补取负责扩展阅读上下文，不因此产生父段独立参与检索的相关性评分。候选融合入口、单路处理与加权 RRF、按块融合。
入库时怎样建立父子关系？
开启 EnableParentChild 后，文档先分成较大父块，再分成较小文本块。父块以 parent_text 类型保存到数据库，子块以 text 类型保存，通过 ParentChunkID 指向父块；进入文本检索索引的是子块，父块用于后续扩展。父子都保留原文范围和来源定位，便于回到原文。父子切分、父块保存和子块关联。
图片还会产生另一层子块：非空识别文字保存为 image_ocr，描述保存为 image_caption，它们的 ParentChunkID 指向所在的文本块，同时保存 ImageInfo 和 SourceLocators。因此可能形成“图片子块 → 文本块 → 大父段”的两级关系。图片子块写入。
命中后怎样补齐并避免重复？
processSearchResults() 先批量读取原始命中块，并保存其分数、匹配类型和原始命中内容。未设置 SkipContextEnrichment 时，再由 collectEnrichmentChunkIDs() 收集三类 ID：
- 当前块的
ParentChunkID。 RelationChunks中保存的关联块。- 有前后链接的
text块对应的PreChunkID、NextChunkID。
processedIDs 同时记录原始命中与已经安排补取的 ID，避免多个命中重复拉取同一块。若原始结果包含图片子块，第一轮可以找到其文本父块，随后再用 collectParentChunkIDs() 补取文本块的大父段；第二轮只沿父关系继续，不重复扩展所有邻块和关联块。批量补取与图片第二轮、关联收集与去重。
聊天链路怎样真正展开父正文？
聊天的 PluginMerge.OnEvent() 会在选取检索或重排结果、初步去重后调用 resolveParentChunks()。它直接按父 ID 批量读取块，不经过检索服务的结果类型过滤：
text → parent_text：将大父段正文与命中子块内容合并到结果的Content，标记ContentRewritten，并保留子块标识。image_ocr、image_caption等图片命中：先找文本父块，有大父段时再向上一层读取，将父正文、文本正文和原识别内容合并。图片信息按命中的文本子块限定，父正文中的图片引用也据此清理，避免把同一大父段中其他位置的图片一并带入。
随后聊天层继续合并连续或重叠正文、补短上下文、做最终去重，并建立引用来源。例如用户问接线图中某个端子的含义，图片识别结果负责定位，父正文补充接线条件，原识别文字仍被保留，不会因替换成父正文而丢失。聊天合并顺序、父关系批量解析、文本与图片展开。
补充块的分数和顺序怎样理解？
在检索服务的补取记录中，新补取的父块沿用触发它的子块分数，并标记为 MatchTypeParentChunk；关联块和邻块若没有分数，组装时使用 0。这个父块分数是关联传递的记录，不是父段独立参与原始检索得到的相关性分数。 多个子块指向同一父块，也不是在这里重新计算父段的相关性。聊天层展开正文同样不会因此产生一次新的父段相关性评分。
检索服务组装结果时，原始命中按输入顺序加入，补充块随后追加；这里没有对所有新增上下文做一次统一重排。显式重排入口则先对未扩展的候选进行重排，再补上下文并保留原始命中项的重排结果，扩展本身仍是另一阶段。分数传递、结果组装、重排后扩展。
当前实现有哪些取舍与缺口？
共享检索服务有一个需要注意的边界：processSearchResults() 补取大父块后，组装调用的 isSearchableChunk() 没有允许 parent_text，所以该父块不会作为独立结果返回。聊天链路仍能通过上述 resolveParentChunks() 直接取父块并展开正文，不能据此说整个项目无法返回父上下文。 如果调用方只消费共享检索接口，就要单独验证父段是否已进入返回内容；完善该接口时，应区分可直接检索的块与可用于上下文扩展的块。大父块类型、组装阶段的类型过滤、允许类型。
扩展还会增加数据库读取和上下文长度。使用时应比较关闭扩展、仅补父关系、补父关系加邻块等方案，在相同文档与问题集上观察证据完整性、重复内容、上下文用量和回答条件是否正确。服务层的 processedIDs 只按块 ID 去重，聊天层还另做内容签名和部分重叠去重；即使去重完成，也不能把“大量补回正文”直接当成准确率提升。
参考资料
- 国内：腾讯云智能体开发平台：文档切分设置：采用先切父片段、再切子片段，以及子片段用于匹配、父片段用于生成上下文的解释；具体 WeKnora 行为按上述源码展开。
- 国内：JavaGuide：RAG文档处理与切分：采用检索粒度和阅读上下文分开设计的思路，解释小块匹配与父段补全的用途。
- 国内：zero2Agent：RAG与检索：采用子块记录父标识、回取后去重的组织方式，解释重复命中同一父段为何需要合并处理。
- 国内：WeThinkIn：父子检索与相邻块扩展：采用结构关系、线性邻接和上下文预算的区分，说明补充证据不等于新的高相关命中。
- 国外：LangChain：Docugami Small-to-Big 检索：采用子块向量索引、父对象存储和父标识关联的职责划分，解释两类内容可以分别存取。
- 国外：LlamaIndex：Auto Merging Retriever：参考按叶节点命中比例递归合并父节点的变体，说明父子检索并非只有一种返回策略；WeKnora 这里采用显式关联补取。
