RAG 政策问答系统｜文档切分中父子块关联如何设计与落地

前言

在传统 RAG 方案中，大多采用单一粒度文本块进行检索与推理。这种方案存在明显短板：块尺寸过小，检索信息碎片化；块尺寸过大，向量相似度匹配精度下降、Embedding 成本升高。 针对政策文档这类逻辑层级强、章节连续的文本，我们采用父子双层分块架构，分离「检索单元」与「推理上下文单元」，而父子块之间的关联设计，正是整套方案能否正常运行的核心。本文结合政务政策 RAG 系统开发实践，讲解完整设计方案。

1. 什么是父块、子块？

• 父块（Parent Chunk） 更大窗口的文本块，通常以完整章节为边界，保留完整上下文。不直接参与向量检索，专门作为大模型 LLM 回答问题的上下文素材。
• 子块（Child Chunk） 较小窗口文本块，由父块二次切分得到。子块生成向量存入 Milvus，作为相似度检索的最小单元。

核心分工：子块负责召回，父块负责作答。

2. 为什么需要父子关联？

假设不设计关联关系： 向量库召回多条零散子块，文本相互割裂，缺少完整章节语义，LLM 容易断章取义，产生政策幻觉。 引入关联机制后： Milvus 检索命中子块 → 通过关联 ID 找到对应的完整父块 → 将连贯、完整的章节文本送入 LLM，大幅提升答案准确性。

3. 父子块关联完整设计方案

3.1 内存阶段临时关联（切分阶段）

文档解析完成后，在内存中生成草稿对象ChunkDraft。 切分逻辑顺序：

此时仅为内存临时标记，还没有数据库真实 ID，不能直接持久化。

3.2 数据库持久化关联（MySQL）

数据表 document_chunks 核心字段：

• id：分块自增主键（唯一标识）
• document_id：归属文档 ID
• content：文本内容
• is_parent：布尔标记，区分父块 / 子块
• parent_id：关联核心字段
• page_no、chapter：章节、页码元信息

入库流程：

约束规则

• 父块：parent_id = NULL，is_parent=true
• 子块：parent_id 等于对应父块 id，is_parent=false
• 外键约束：支持级联删除，删除文档时自动清理全部父子块

3.3 Milvus 向量库配套设计

Milvus 仅存储子块向量，每条向量必须携带元数据： chunk_id（子块主键）、document_id、parent_id 检索流程：

重点：多条子块可能来自同一个父块，必须对 parent_id 去重，避免重复投喂相同文本浪费 token。

4. 方案优势

5. 踩坑总结

结语

父子块分块架构是解决长文档 RAG 碎片化问题成熟有效的方案，整套机制能否跑通，关键点不在于切分算法本身，而在于父子之间关联 ID 的流转设计：从内存草稿临时标记，到数据库持久绑定，再到向量检索时利用关联 ID 找回完整上下文。在政务政策问答这类对准确性要求极高的场景下，该方案能够有效缓解大模型幻觉，提升问答质量。