RAG系统的命脉是索引而不是检索：六种索引策略详解

RAG 系统中，开发者往往过度关注"检索"环节，而忽视了更基础的"索引"设计。索引决定知识的表征方式，检索只是决定模型能看到哪些部分。索引设计不当，再强的 LLM 也弥补不了输入端的数据缺陷。

这篇文章详解六种在生产环境中验证有效的 RAG 索引策略。

索引与检索的区别

索引（Indexing）是将非结构化的原始知识转化为可供计算的 Embedding 数据的过程。如果检索是"在这个语义空间中寻找答案"，索引就是"如何构建这个语义空间地图"。

许多开发者把文档扔进向量数据库就觉得检索优化完成了。但切分粒度过大会引入噪声，切分过细会导致语义割裂，生成的 Embedding 就无法准确捕捉用户意图。

最通用的策略。将长文档拆分为语义连贯的小块，对每个块向量化存储。通常设定固定的 chunk_size，并设置重叠窗口（Overlap）保持上下文连续性。

实践要点：

块过大→包含无关噪声，降低精度；块过小→上下文碎片化，增加模型推理难度。

也叫父文档检索（Parent Document Retriever）。索引阶段将文档切分为极小的子块进行向量化，以提高与用户查询的语义匹配度。检索命中后，返回的不是子块，而是包含该子块的完整父块。

适用场景：高密度知识库（学术论文、教科书）。比如一个具体的公式解释只占一小段（子块），能被精准检索，但模型理解需要整章背景（父块）。

代价是增加了预处理计算量和存储空间，但上下文完整性和答案准确率显著提升。

用户的问题（Query）与文档陈述（Statement）在语义空间上往往有距离。查询索引不对原始文本直接索引，而是用 LLM 预生成该文本块可能回答的若干"假设性问题"，对这些问题的向量化索引。

用户提问时，实际上是在匹配最相似的问题，间接定位到原文。

适用场景：FAQ 问答系统，用户意图多为"是什么""为什么""如何做"。引入了额外 LLM 生成成本，但相关性提升明显。

对原始文档先做摘要处理，只存储和检索摘要的 Embedding。检索命中后再关联到详细原文。相当于为知识库建立了一个"目录"层。

比如原文是"2020年至2025年温度读数在22到42摄氏度之间波动，异常归因于厄尔尼诺……"，摘要索引只存"2020-2025年温度趋势及厄尔尼诺异常分析"。

适用场景：结构化数据（CSV、日志）、表格数据、内容冗长的非结构化文档。

企业级大规模知识库用单一索引不够。分层索引采用树状结构——"文档→章节→段落/分块"。

第一级检索通过文档摘要或元数据筛选出相关文档集合，第二级检索在筛选出的文档内部检索具体段落。

优势：大幅减少无关文档干扰，能处理海量数据同时保持高精度，且答案来源可追溯。

处理包含文本、图像、代码等多模态数据。用专用编码器分别处理不同类型（CLIP 处理图像，CodeBERT 处理代码），检索阶段通过加权融合或 Reranking 整合结果。

适用场景：包含图表的技术手册、电商产品库、设计素材库等。

设计合理的索引机制，是消除大模型幻觉、构建可信赖 RAG 系统的关键一步。