RAG检索优化四层框架：索引层、查询层、召回层、重排序层

目录

一、先立框架：RAG检索优化的四个层次

你这句话非常标准，也最适合面试和工程沟通：

RAG 的检索优化可以从四个层次来看：索引层决定知识怎么存，查询层决定问题怎么转换，召回层决定从哪些路径去找，重排序层决定最终哪些内容进入 prompt。

很多RAG项目在Demo阶段表现不错，但线上常出现：

  • ❌ 延迟高，用户体验差
  • ❌ 召回不稳，答案质量波动大

核心原因是“只优化某一个点”，没有按层次系统优化。

完整检索链路可以表示为：

1
索引层(Index) -> 查询层(Query Transform) -> 召回层(Recall Paths) -> 重排序层(Rerank) -> Prompt

四层分别回答四个不同问题：

  1. 索引层：知识如何组织存储，能否高效搜索
  2. 查询层：用户问题如何改写成更可检索的表达
  3. 召回层：从单路还是多路去召回证据
  4. 重排序层：哪些候选最值得进Prompt

小结：四层框架解决的是“系统性优化”，不是“局部调参”。

二、索引层：决定知识怎么存

2.1 索引层目标

索引层核心是三角权衡：召回、延迟、成本。

1
2
3
召回越高 -> 往往搜索更广 -> 延迟和成本上升
延迟越低 -> 往往搜索更窄 -> 可能漏召回
成本越低 -> 往往需要压缩 -> 可能影响精度

2.2 主流索引类型

  1. HNSW（图索引）
  • ✅ 召回高，稳定性好
  • ❌ 内存占用高，构建成本高
  1. IVF（倒排聚类）
  • ✅ 大规模场景延迟低
  • ❌ 参数不当容易漏召回
  1. IVF + PQ（压缩索引）
  • ✅ 成本低，适合超大规模
  • ❌ 存在量化误差，上限受影响

2.3 索引选型表

方案 召回潜力 延迟 内存成本 适用场景
HNSW 高 中低 高 对效果敏感的知识问答
IVF 中高 低 中 大规模通用检索
IVF + PQ 中 低 低 超大规模、成本敏感

2.4 索引层关键参数

  • HNSW: M、efConstruction、efSearch
  • IVF: nlist、nprobe

调参顺序建议：

1
先定索引结构 -> 再定构建参数 -> 最后调查询参数

小结：索引层决定“能不能在预算内找到候选”。

三、查询层：决定问题怎么转换

很多检索失败，不是索引差，而是问题表达不适合检索。

3.1 查询层的核心任务

把用户自然语言问题，转换成“更可检索”的查询表示。

3.2 常见查询优化策略

  1. Query Rewrite（重写）
  • 把口语问题改成结构化表达
  1. Query Expansion（扩展）
  • 补充同义词、别名、缩写全称
  1. Query Decomposition（拆解）
  • 复杂问题拆成多个子问题分别检索
  1. HyDE（假设文档）
  • 先生成假想答案，再以其向量做检索

3.3 典型例子

1
2
原问题: Java里怎么做事务传播?
重写后: Spring Transaction Propagation REQUIRED REQUIRES_NEW 差异

小结：查询层决定“问法是否能被检索系统正确理解”。

四、召回层：决定从哪些路径去找

召回层的核心不是“单路最强”，而是“多路互补”。

4.1 单路召回的局限

  • 纯向量召回：语义强，但对术语精确命中可能不足
  • 纯关键词召回：术语命中强，但语义泛化差

4.2 多路召回策略

常见组合：

  1. Vector Recall（向量语义召回）
  2. BM25 Recall（关键词召回）
  3. Metadata Filter（时间、权限、业务域过滤）
  4. Multi-Query Recall（多查询并行召回）

4.3 召回层融合链路

1
Query -> Vector Recall + BM25 Recall + Filter Recall -> Merge Candidate Pool

4.4 召回层关键点

  • 候选池规模要受控（避免后续重排成本爆炸）
  • 不同路径结果要去重
  • 对高价值查询可配置更高召回宽度

小结：召回层决定“候选是否全面且干净”。

五、重排序层：决定哪些内容进入Prompt

重排序层是“从可用到好用”的关键一跳。

5.1 为什么需要重排序

多路召回会带来冗余和噪声，直接拼Prompt会导致：

  • ❌ 上下文膨胀
  • ❌ 证据冲突
  • ❌ 模型注意力被稀释

5.2 常见重排序策略

  1. Cross-Encoder Rerank
  • 精度高，成本也高
  1. Rule-based Rerank
  • 结合业务规则（时效性、可信度、权限）
  1. Diversity-aware Rerank
  • 避免TopK语义重复，提升信息覆盖度

5.3 Prompt前最后一道门

1
Candidate Pool -> Rerank -> TopN Evidence -> Prompt Packing

控制原则：

  • 进Prompt的不是“最像问题”的内容，而是“最能支撑回答”的证据组合。

小结：重排序层决定“最终喂给模型的信息质量”。

六、Spring AI + Milvus落地：四层如何串起来

6.1 目标链路

1
2
Document -> Embedding -> Index(HNSW/IVF)
Query -> Rewrite/Expand -> Multi-path Recall -> Rerank -> Prompt

6.2 代码示例：四层串联（简化版）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Service
public class LayeredRetrievalService {

    private final VectorStore vectorStore;

    public LayeredRetrievalService(VectorStore vectorStore) {
        this.vectorStore = vectorStore;
    }

    public List<Document> retrieve(String rawQuery, int topK) {
        // 查询层: query rewrite
        String rewritten = rewriteQuery(rawQuery);

        // 召回层: 多路召回（这里用简化示意）
        List<Document> vectorHits = vectorStore.similaritySearch(
                SearchRequest.query(rewritten).withTopK(topK * 3)
        );

        // 重排序层: 规则+相关性重排（简化）
        return rerankAndCut(vectorHits, topK);
    }

    private String rewriteQuery(String q) {
        return q.replace("怎么", "如何");
    }

    private List<Document> rerankAndCut(List<Document> docs, int topK) {
        return docs.stream().limit(topK).toList();
    }
}

6.3 Milvus落地注意点

  • 索引层：索引类型、度量方式、向量维度与Embedding严格对齐
  • 查询层：重写逻辑可观测，避免过度改写语义漂移
  • 召回层：多路候选池需去重并控制规模
  • 重排序层：引入业务规则（时效、可信度、权限）

小结：工程落地的关键是把四层解耦并可观测，而不是把检索逻辑写成黑盒。

七、评估体系：分层指标与联合验收

7.1 索引层指标

  • Recall@K
  • Index Build Time
  • Memory Footprint

7.2 查询层指标

  • Query Rewrite 成功率
  • 改写后召回提升率
  • 语义偏移率（Rewrite Drift）

7.3 召回层指标

  • Candidate Coverage（候选覆盖度）
  • Multi-path Contribution（各路径贡献度）
  • 去重后有效候选数

7.4 重排序层指标

  • NDCG@K
  • TopN Evidence Precision
  • Prompt Token Efficiency

7.5 线上性能指标

  • P50/P95/P99 Latency
  • QPS
  • Timeout/Error Rate

7.6 联合验收门禁

1
2
检索质量门禁: Recall@10 >= 阈值 且 NDCG@10 >= 阈值
性能门禁: P99 <= SLA 且 ErrorRate <= 阈值

小结：分层指标可定位问题，联合门禁可防止“优化一端、退化另一端”。

八、线上排障：按四层定位问题

8.1 索引层问题

症状：召回突然下降、内存持续走高

常见原因：

  • 索引未刷新或损坏
  • HNSW参数过大或重复向量堆积

修复建议：

  • 校验索引任务与刷新状态
  • 去重+重建+参数回滚

8.2 查询层问题

症状：同义问法表现差异大

常见原因：

  • 重写策略覆盖不足
  • 改写过度导致语义漂移

修复建议：

  • 建立问法词典与模板
  • 对改写输出做质量约束

8.3 召回层问题

症状：命中率不低但答案仍空泛

常见原因：

  • 单路召回信息单一
  • 候选池冗余导致有效信息被淹没

修复建议：

  • 引入多路召回并统计贡献
  • 候选去重与分配策略优化

8.4 重排序层问题

症状：进入Prompt的内容重复或不关键

常见原因：

  • 重排模型弱或规则缺失
  • 未考虑多样性与业务约束

修复建议：

  • 引入交叉编码重排或规则重排
  • 加入多样性约束与权限规则

8.5 一条排障路径

1
2
先看索引层(召回底盘) -> 再看查询层(问法转换)
-> 再看召回层(候选覆盖) -> 最后看重排序层(证据质量)

小结：分层排障比“全链路盲调参数”更快、更稳。

九、面试速答版（60秒+扩展版）

9.1 60秒版（可直接背）

RAG检索优化我会按四层做：索引层决定知识怎么存，重点是HNSW/IVF/PQ选型和参数；查询层决定问题怎么转，常用Rewrite/Expansion；召回层决定从哪些路径找，通常用向量+关键词+过滤的多路召回；重排序层决定最终进Prompt的证据，确保高相关和高覆盖。评估时不只看Recall@K，还要看P99延迟和线上SLA，做到效果、性能、成本三者平衡。

9.2 扩展版（面试加分）

我会把RAG检索优化拆成四层来做系统化治理。

第一层是索引层，解决存储与搜索结构问题，常见方案是HNSW、IVF、PQ，核心是召回、延迟和成本的平衡。

第二层是查询层，通过重写、扩展和拆解把用户问题变成更可检索表达。

第三层是召回层，用多路召回保证候选覆盖；第四层是重排序层，从候选池里筛出最值得进入Prompt的证据组合。

最后用分层指标做治理：索引层看Recall和资源，查询层看改写收益，召回层看覆盖，重排序层看NDCG，再用P99和错误率做线上门禁。

总结

1
2
3
4
5
RAG检索优化 = 四层协同优化：
索引层(怎么存) -> 查询层(怎么转) -> 召回层(怎么找) -> 重排序层(怎么选)。

落地顺序建议：
先搭四层框架，再做分层指标治理。