RAG检索质量提升5法

回答与解析

RAG 检索优化应按检索前、检索中和检索后三个阶段设计，并用独立评测判断每一步是否真的带来增益。

1. 检索前：查询理解与扩展

• 查询改写：消除指代、纠错或补全约束，使 query 自包含。
• 多查询/子问题分解：从不同表述或子任务召回候选，再去重融合。
• HyDE：先生成假设文档表示再检索，适合原查询与目标文档表述差异较大的场景，但假设内容偏差也可能带来噪声。
• 伪相关反馈：利用首轮结果扩展词项，需防止错误结果造成 query drift。

2. 检索中：多路召回与排序

BM25 擅长字面、实体和编号匹配，稠密向量擅长语义近似，可用 RRF、归一化加权或学习排序融合。随后只对有限候选使用 Cross-Encoder 等重排模型。具体候选数由 Recall、nDCG、吞吐和延迟预算决定，不使用固定通用值。

3. 检索后：上下文选择

对候选做权限和元数据过滤、去重、证据片段抽取、上下文压缩与排序，保留引用关系。块大小和压缩策略取决于文档结构、查询类型与模型窗口，不能用统一的 256/1024 token 规则。压缩还可能丢失限定条件，需单独评测证据保留率。

4. 动态与迭代检索

复杂多跳任务可根据当前证据缺口生成新查询继续检索；简单请求则可跳过昂贵步骤。路由条件、最大轮数、停止规则和失败降级都应显式配置。

选型时先建立查询分桶与黄金证据集，分别报告召回、排序、引用正确率、忠实度、端到端成功率和成本。不存在对所有项目都必选的单一组合。

口语版讲法(约2分钟)

• 一句话定位：RAG检索优化本质是让模型找到更准的上下文
• 检索前：查询改写和HyDE，解决用户问得模糊的问题
• 检索中：混合检索加重排序，兼顾召回率和精度
• 检索后：上下文压缩和动态分块，减少噪声
• 选型判断：先上混合检索+重排，复杂场景再加迭代

我会把 RAG 检索优化分成检索前、检索中和检索后三个阶段，并为每一步做独立评测。

检索前可以做指代消解、纠错、查询改写、多查询和子问题分解。HyDE 用假设文档帮助匹配表述差异较大的资料，但生成内容偏移也可能带来噪声，所以要和原查询基线比较，不能默认更好。

检索中通常并行使用 BM25 与稠密向量召回。两路分数尺度不同时，RRF 是稳健的无监督基线；有可靠标注时，也可以使用分数归一化、线性融合或学习排序。随后只对有限候选使用 Cross-Encoder 重排。候选数没有通用的 Top-100 安全线，要由 Recall、nDCG、吞吐和延迟预算确定。

检索后要做权限与元数据过滤、去重、证据片段抽取、上下文压缩和引用保留。分块大小与压缩策略依文档结构、查询类型和模型窗口决定，不能为不同查询类型指定通用固定块长。压缩还可能丢掉限定条件，需要单独测证据保留率。

复杂多跳任务可以在当前证据不足时生成新查询迭代检索；简单请求则应跳过昂贵步骤。路由条件、最大轮数、停止规则和降级路径都要显式配置。

上线前要特别防止优化链路彼此叠加后只在离线指标变好，却让端到端答案退化。我会做逐步消融，回放包含长尾实体、否定条件、权限过滤和无答案请求的样本，并核对最终引用是否仍指向原始证据。

最后用黄金证据集分别报告 Recall@K、nDCG、引用正确率、忠实度、端到端成功率、延迟和成本。每种组合都要以同一数据集上的质量、延迟和成本增益决定是否采用。

关键一句:迭代检索虽然强，但延迟和成本高，需要评估业务场景再决定是否上

面试官还可能这样问

1. 问法 1 · 场景切入

   我注意到你项目里用了RAG。假设用户问了个模糊问题，比如‘这个怎么退’，直接去向量库搜可能不准，你会怎么优化检索？除了调embedding模型，还有别的招吗？

2. 问法 2 · 层层追问

   RAG系统里，检索结果质量怎么保证？……光靠向量相似度够吗？……如果不够，你会在检索前、检索中还是检索后做文章？举个例子说说具体方法？

3. 问法 3 · 直球架构

   除了向量检索，RAG还有哪些关键技术能提升检索质量？从查询扩展、混合检索、重排序、上下文压缩这些方法里挑几个，讲讲原理和适用场景，不考虑成本的话你优先用哪个？