在实际的 RAG 系统中，单纯依赖“一段文本一个向量”的扁平索引，往往会遇到检索精度与覆盖范围的矛盾。分层索引（又称二级检索）通过引入摘要层与详情层的结构，将“快速定位主题”和“精确提取细节”两个任务解耦，从而在保证召回率的同时，显著提升检索结果的相关性。
1. 为什么需要分层索引
扁平索引的典型做法是将原始文档按固定大小切分成块（chunk），每块生成一个向量。这种“一刀切”的策略在以下场景中容易失效：
- 问题抽象度高：用户问“公司对远程办公的总体态度是什么？”时，匹配到的可能是某次具体会议的记录片段，而非概括性的政策摘要。真正需要的是高层语义，却被细节淹没。
- 关键信息分散：一个问题的答案可能跨越多个部分，例如某产品的所有安全警告分布在不同章节。扁平检索容易只召回一个片段，漏掉其他必要信息。
- 检索噪声大：长文档中的大部分内容都与当前问题无关，直接将原始长段落作为检索单元，会导致相似度匹配时引入大量噪声，降低 top‑k 结果的质量。
分层索引的解决思路是：先找对方向，再深入细节。
2. 分层索引的架构设计
典型的分层索引包含两层：
- 摘要层（粗检索）
为每份文档或每个预定义主题生成一段独立摘要。摘要只包含文档的核心主题、关键观点和适用范围，不涉及具体数据或操作步骤。这些摘要被单独向量化并存入摘要索引库。
- 详情层（细检索）
原始文档被切分为较细粒度的片段（如 200–500 字的 chunk），每个片段保留完整的技术细节、参数、步骤等。详情层可以组织成“文档→分段”的树状映射，或者为每个片段关联其所属的文档/主题 ID。
检索时采用两阶段流水线：
- 用户问题先与摘要层匹配
用问题向量在摘要索引中检索，得到最相关的若干文档或主题（例如 top‑3 篇文档）。这一步是粗粒度的主题锁定，速度很快。
- 在锁定范围内进行详情检索
将问题与第一阶段筛选出的文档所关联的所有详情片段进行细粒度匹配，选出最终用于生成回答的 top‑k 个片段。
3. 一个真实的实现示例
某制造企业内部维护着数百份设备操作手册和故障排除指南。当工程师提问“X 型机床出现 E07 报警如何复位？”时：
- 摘要层先检索到三篇相关文档：《X 型机床报警代码手册》《常见故障快速处理指南》和《Y 型机床说明》（后者实际不相关，但因术语相似被误召回）。
- 详情层在已锁定的前三篇文档范围内，用问题向量进行二次匹配，从《X 型机床报警代码手册》中精确命中“E07：主轴过载报警，复位步骤为……”的段落，同时排除了《Y 型机床说明》中的无关细节。
最终，回答只使用了来自正确文档的高精度片段，既未遗漏步骤，也未引入其他型号的干扰信息。
4. 分层索引的核心优势
- 提升检索精度
摘要层排除了大量无关文档，缩小了详情检索的范围，使最终结果更聚焦于真正相关的材料。
- 兼顾宏观与微观
对于需要概述类答案的问题，摘要层本身就可能直接提供可用的回答素材；对于细节性操作问题，则可以透过详情层精准提取步骤。
- 降低计算与存储压力
摘要向量维度与详情相同，但数量远少于详情片段（通常一个文档只有一个或几个摘要），摘要检索成本极低。详情检索只在小范围内进行，相比全量扫描大幅减少计算量，尤其在百万级文档库中效益明显。
- 便于维护和扩展
新增一份文档时，只需生成其摘要并添加到摘要索引，同时将其详情片段存入详情库并建立关联。整体架构无需变动，扩展非常自然。
5. 实用建议与注意事项
- 摘要的质量是关键
摘要应由懂业务的人撰写或由 LLM 按规范生成，确保准确反映文档主旨。糟糕的摘要会直接导致整个检索路径跑偏。可以规定摘要模板，例如“本文档涵盖……，适用于……，主要说明……”。
- 保持映射关系的完整性
摘要与详情片段之间必须有清晰、可查询的关联，比如每个详情 chunk 记录所属的文档 ID。推荐使用元数据字段（如 doc_id）链接。
- 处理跨文档场景
某些问题可能需要多份文档的信息。可在第一阶段适当扩大锁定范围（如取 top‑5 篇），在第二阶段通过重排序（rerank）进行精选，避免因过早截断而漏掉相关内容。
- 与重排序模型结合
在详情检索后，若结果较多，可引入一个轻量的重排序模型（如 cross‑encoder）做最终精排，进一步提升顶端结果的相关性，弥补纯向量检索的不足。
分层索引并非越复杂越好，其核心价值在于让系统像人类查阅资料一样：先找对书架，再翻到具体页码。对于文档数量多、主题复杂、需要高精度回答的企业知识库场景，这种二级架构经常能带来立竿见影的质量提升。