大文档检索效果差时，推荐采用父子索引（Parent-Child Indexing）结构，通过小切片检索定位、大切片上下文生成的方式优化。该方案适用于法律合同、技术手册等长文档场景，主要风险在于父块粒度设置不当可能导致上下文冗余或模型超限。

快速处理思路

核心逻辑是将“检索单元”和“生成单元”解耦，不再直接索引用来给大模型阅读的大文档。存储父文档保持较大粒度包含完整逻辑，生成子文档将父文档进一步切分为细小片段，子文档只负责被检索，一旦命中通过 ID 索引召回其所属的父文档。

为什么会这样

传统分块策略导致检索命中片段丢失上下文，造成大模型理解偏差。若切片太小，上下文信息容易丢失，导致大模型在生成回答时出现逻辑断层；若切片设置太大，文本块中夹杂的无关信息增多，向量检索的匹配精准度便会随之下降。父子索引的核心思路在于将检索与生成两个环节解耦处理，即利用小切片执行精确检索，再依托大切片提供完整上下文用于生成回答。

分步处理

实施父子索引通常分为分层切分、索引构建、检索回溯与答案生成四个步骤。

1. 分层切分：将文档按语义完整性划分为较大的父块（例如 1000 至 2000 词元），并在每个父块内部细分为更小的子块（例如 100 至 200 词元），为每个子块赋予父块标识 parent_id。
2. 索引构建：系统仅对子块进行向量化处理并存入向量数据库，父块的原始文本存放于文档数据库中，无需参与向量计算。
3. 检索与回溯：用户查询时，首先在向量库中检索出最相关的若干子块，依据子块携带的 parent_id 从文档库中调取对应的完整父块内容，若多个子块同属一个父块则自动去重。
4. 答案生成：将合并后的完整父块文本提供给模型用于答案生成，确保上下文连贯。

怎么验证是否生效

验证重点在于检查回答是否包含父块中的关键背景信息且指代清晰。对比传统分块方式，观察检索结果是否仍存在“孤儿切片”现象，即命中片段是否知道“自己是谁”。部分实战案例声称，采用父子分段后长文档问答准确率有显著提升，特定场景下用户反复追问获取完整信息的情况减少。

常见坑

• 父块粒度过大：父块长度超过模型上下文窗口会导致截断，技术手册建议 2500-3500 字符，学术论文建议 4000-5000 字符，需根据文档类型调整。
• 关联映射丢失：子块与父块的 ID 映射关系若在索引构建阶段出错，会导致检索后无法回溯父块，系统需确保 parent_id 绑定准确。
• 非结构化文档处理：缺乏清晰结构的文档难以划分逻辑父块，可能影响分层切分效果，需预先进行结构化处理。

常见问题

父子索引适合所有文档类型吗？

不适合所有类型，主要适用于法律合同、学术研究、技术手册等长文档场景。短文档或结构松散的文本可能无需此复杂策略，直接分块即可。

父块和子块的长度怎么设置？

子块通常控制在 50-200 字用于精准检索，父块通常控制在 500-1000 字或更大用于提供上下文。具体数值需根据模型上下文窗口和内容密度权衡，例如技术文档信息密度高可适当减小父块长度。

参考来源

• 技术文章《RAG 工程化实践方法论 - 父子索引》
• 技术文章《父子索引技术：提升大模型检索效果的实用指南》
• 技术文章《收藏！父子文档索引 (Parent-Child Indexing):让 RAG 同时兼顾检索精度与上下文完整性的高阶策略》
• 技术文章《【Dify 技术应用】- 父子分段模式实战：提升长文档检索质量的关键策略》
• 技术文章《父子文档检索：解决长文档中“丢失上下文”的生产级方案》
• 技术文章《Dify 知识库实战：用父子分段策略优化法律合同检索效果 (附 ChatFlow 对接指南)》
• 技术文章《告别 RAG 两难困境！父子切分技术让长文本检索精度与完整性双突破》
• 技术文章《优化 RAG 索引策略：多向量索引与父文档检索技术，大模型入门到精通，收藏这篇就足够了!》
• 技术文章《Dify 知识库优化实践：父子分段与多模态召回工程详解》