除了基础的向量检索，你还知道哪些可以提升 RAG 检索质量的技术
P1 · rag
🏷 标签：rag, retrieval, hybrid-search, reranking, query-expansion
1️⃣ 考察意图
面试官想看你是否只停留在“向量检索是 RAG 标配”的浅层认知，而是真正理解检索质量瓶颈（如查询歧义、语义鸿沟、噪声干扰）并掌握系统级优化手段。考察类型是工程取舍 + 系统设计，刁钻点在于：不要求你背全所有技术，而是能针对不同场景（如长尾查询、高精度需求）给出有 trade-off 的解法。答好了能展示你对 RAG 整条链路的掌控力，以及从“能用”到“好用”的工程思维。
2️⃣ 标准答
提升 RAG 检索质量，核心是解决查询与文档的语义对齐和噪声过滤问题。以下是我在实践中验证有效的技术栈，按实施顺序组织：
查询端优化：让问题更精准
- 查询改写（Query Rewriting）：用 LLM 对原始查询进行重写，消除歧义。例如用户问“苹果的财报”，LLM 可扩展为“苹果公司 2024 年 Q3 财报营收和利润”。坑：改写可能引入幻觉，需设置置信度阈值（如 < 0.7 时保留原查询），或使用小模型（如 7B）控制成本。
- 查询分解（Query Decomposition）：对复杂多跳问题（如“特斯拉的电池供应商是谁？它的股价最近如何？”），拆成子查询分别检索后合并。取舍：分解增加延迟（约 200-500ms），但能提升多跳场景的 Recall@5 约 15-20%。
检索策略：混合与多路召回
- 混合检索（Hybrid Search）：结合稀疏检索（BM25，默认 k1=1.5, b=0.75）和稠密检索（如 text-embedding-3-small 的 1536 维向量），通过 RRF（Reciprocal Rank Fusion，公式
1/(k + rank)，k=60）融合结果。为什么这么做：BM25 擅长精确匹配（如“2024 年财报”），向量擅长语义相似（如“公司盈利情况”），互补后 Recall@10 通常提升 10-20%。 - 多路召回（Multi-Route Retrieval）：从不同索引（标题、正文、摘要）或不同嵌入模型（如 BGE 和 E5）分别召回 Top-K，合并去重。落地坑：不同路召回结果可能高度重叠，需设置去重策略（如按文档 ID 合并，保留最高分），否则浪费 rerank 预算。
后处理：精排与过滤
- 重排序（Reranking）：使用交叉编码器（如 Cohere rerank-v3 或 BGE-Reranker-v2）对初筛 Top-50 结果精排。交叉编码器能捕捉查询-文档的细粒度交互，比双编码器（向量检索）的 NDCG@10 高 5-10%。取舍：rerank 延迟高（约 100-300ms/对），所以只对 Top-50 做，而非全量。
- 自适应检索（Adaptive Retrieval）：根据查询复杂度动态调整策略。例如，对简单事实查询（“巴黎是哪个国家的首都？”）只用 BM25；对复杂推理查询（“为什么特斯拉的股价在 2024 年 Q3 下跌？”）先向量检索，若置信度 < 0.6 则触发二次检索（如查询改写后重试）。坑：复杂度判断需预定义规则（如查询长度 > 10 词或含“为什么”），否则可能误判。
索引优化：结构化与分块
- 分块策略（Chunking）：按语义边界（如段落、句子）而非固定 token 数分块，避免切断关键信息。使用
langchain的RecursiveCharacterTextSplitter，chunk_size=512，overlap=128。为什么：固定分块（如 256 token）可能导致“苹果的财报”被切到不同块，召回率下降 5-10%。 - 元数据过滤（Metadata Filtering）：在索引中嵌入时间、来源等元数据，检索时先过滤（如“只返回 2024 年后的文档”），减少无关噪声。落地：用 Elasticsearch 的
filter子句，比后过滤快 2-3 倍。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从查询端、检索策略、后处理三个层面回答。查询端用 LLM 改写和分解消除歧义；检索策略用 BM25+向量的混合检索和 RRF 融合，以及多路召回互补；后处理用交叉编码器 rerank 和自适应检索动态调整。总结一句：RAG 检索质量提升不是单点优化，而是从查询到索引的整条链路工程取舍。”
4️⃣ 高频追问 & 应对
追问 1：你提到混合检索用 RRF，为什么不用加权平均？具体怎么调参？
应对策略：RRF 的优势是无需归一化分数，因为 BM25 和向量分数尺度不同（BM25 通常 0-10，向量余弦相似度 0-1），直接加权平均会偏向 BM25。RRF 公式
1/(k + rank)只依赖排名，k 控制平滑度，默认 k=60 在 MS MARCO 上效果稳定。调参时，用 500 个查询做网格搜索（k 从 10 到 100，步长 10），观察 Recall@10 峰值。取舍：RRF 对排名敏感，若某路检索质量差（如向量模型未微调），会拖累整体；此时可改用加权 RRF（给不同路不同权重，如 BM25 权重 0.6，向量 0.4）。
追问 2：重排序时，交叉编码器延迟高，怎么优化？
应对策略：三个方向：1）减少候选集：初筛只保留 Top-50，而非 Top-100，因为 rerank 提升主要在 Top-50 内（NDCG@10 提升 5% vs 1%）。2）模型蒸馏：用 6 层小交叉编码器（如 MiniLM）替代 12 层大模型，延迟从 300ms 降到 100ms，NDCG 只降 1-2%。3）异步批处理：将 rerank 请求合并成 batch（如一次处理 10 个查询），利用 GPU 并行，吞吐量提升 3-5 倍。坑：batch 太大（> 50）会导致显存溢出，需根据模型大小动态调整。
追问 3：自适应检索中，怎么判断查询复杂度？有没有具体指标？
应对策略：用规则 + 模型双保险。规则：查询长度 > 15 词、含“为什么/如何/对比”等词、或包含多个实体（用 NER 提取），判为复杂。模型：用小分类器（如 BERT-base 微调，输入查询，输出 0/1 标签），准确率约 85%。取舍：规则简单但召回低（约 70%），模型准确但需标注数据（至少 1000 条）。实践中先用规则兜底，再逐步用模型替换。落地坑：复杂查询可能误判为简单（如“巴黎是首都吗？”），导致只做 BM25 而漏掉语义匹配，需设置 fallback（如若 BM25 结果 < 3 条，自动触发向量检索）。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提“用更好的 embedding 模型” → ✅ 强调 embedding 只是基础，更关键的是查询改写、混合检索和 rerank 等工程优化，因为 embedding 模型提升有限（如从 text-embedding-3-small 到 ada-002 只提升 2-3% Recall），而混合检索可提升 10-20%。
- ❌ 说“用 LLM 改写查询就行” → ✅ 必须说明改写可能引入幻觉，需要设置置信度阈值或保留原查询作为 fallback，否则会降低精度。
- ❌ 堆砌技术名词（如“用 ColBERT、HNSW、DPR”）但不讲取舍 → ✅ 每个技术都要给出 trade-off，如“HNSW 索引速度快但内存占用高，适合小规模场景；对 1 亿级文档，需用 IVF+PQ 压缩”。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中实现了混合检索（BM25+向量）和 rerank，Recall@10 提升 15%”切入，强调你如何调参（如 RRF 的 k 值）和解决延迟问题（如用异步批处理）。
- 如果你只做过传统 NLP：用“传统信息检索中的 BM25 和查询扩展（如伪相关反馈）可以迁移到 RAG”类比，展示你对检索基础的理解，并补充你如何用 LLM 替代传统方法（如用 GPT 改写代替伪相关反馈）。
- 如果你是校招无项目：聚焦“我复现了 MS MARCO 上的混合检索实验，对比了 RRF 和加权平均的 Recall@10 差异”，展示你对论文（如《Hybrid Search for RAG》）的动手能力，并提到你如何用开源工具（如 LangChain、Elasticsearch）实现。
- 《Hybrid Search for RAG: A Comparative Study of BM25 and Dense Retrieval》
- 《Query Rewriting in Retrieval-Augmented Generation: A Survey》
- 《Cross-Encoder vs Bi-Encoder: Trade-offs in Reranking for RAG》
- 《Adaptive Retrieval: Dynamic Strategies for Complex Queries》
- 《Chunking Strategies for RAG: Semantic vs Fixed-Size Splitting》