RAG 检索增强技术有哪些？
除向量检索外,HyDE、重排序、查询改写等增强技术详解
原题：在RAG（Retrieval-Augmented Generation）系统中，有哪些方法可以提升检索阶段的质量？除标准向量检索外，还可以采用哪些增强技术？
RAG基础 · 字节真题
回答与解析
一、查询侧优化（让问题更清晰）
查询重写/扩展
- HyDE（Hypothetical Document Embedding）：让LLM先生成假设答案，用答案去检索而非原始问题
- Query2Doc：类似思路，用少量生成内容扩展查询语义
- 多查询扩展：一个query改写成多个不同表述，分别检索后合并
查询分解
- 复杂问题拆成子问题，如"比较A和B的优缺点"→分别检索A、B再综合
二、检索策略增强（多路召回）
| 方法 | 核心思想 | 适用场景 |
|---|---|---|
| 混合检索 | 向量相似度 + BM25关键词匹配，加权融合 | 专业术语、专有名词多的场景 |
| 稀疏-密集结合 | SPLADE等学习式稀疏向量，弥补纯向量盲区 | 长尾实体、ID类查询 |
| 图检索 | 基于知识图谱的实体关系扩展 | 需要推理关联的复杂问题 |
三、精排优化（重排序）
- Cross-Encoder重排：用交互式模型（如bge-reranker）对召回Top-K精细打分，精度高但慢
- 多阶段级联：向量召回→BM25过滤→Cross-Encoder精排，平衡效率与效果
四、索引层面优化
- 分块策略：按语义切分（而非固定长度），保证chunk内语义完整
- 元数据过滤：先按时间、类别等标签过滤，缩小检索范围
- 摘要索引：存储chunk摘要+原文，用摘要做向量检索减少噪声
一句话总结：检索质量 = 查询理解（改写）× 召回广度（混合检索）× 排序精度（重排），三环节缺一不可。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 本质是让检索更精准地命中回答所需信息
- 查询侧动手脚：改写和分解
- 召回策略：混合检索弥补各自盲区
- 排序与索引：精排和分块不能省
- 落地取舍：别贪多，平衡成本和效果
这道题问的是怎么提升RAG里检索阶段的质量，本质上就是怎么让检索更精准地命中回答真正需要的信息。我会从查询、召回、排序、索引几个环节来说，但重点不是列全所有方法，而是讲清楚在什么场景下该选什么，以及实际落地时容易踩的坑。
先说查询侧。标准做法是直接拿用户问题去做向量检索，但问题往往又短又模糊，比如用户问“这个能退吗”，在电商客服场景里，你得知道他说的是哪个商品、什么原因。所以我会做查询改写，最常用的是 HyDE，就是让LLM先生成一个假设的回答，然后用这个答案去检索。这么做的好处是语义更丰富，但前提是LLM生成的假设不能太离谱，如果领域很专业、模型没训练过，反而会引入噪声。另一个是查询分解，比如“对比A和B的退款政策”，我会拆成“A的退款政策”和“B的退款政策”分别检索再合并。这里有个边界：如果问题本身很简单，改写反而画蛇添足，我只会对意图模糊或复杂推理的问题做。
再讲召回策略。纯向量检索对专业术语、商品ID这类精确匹配很弱，所以我会用 混合检索，把向量相似度和 BM25 关键词匹配结合起来。比如在退款场景，用户说“订单号12345”，关键词匹配能直接命中，向量反而可能因为语义偏移而漏掉。具体落地时，我会把两个分数加权融合，权重根据业务调，比如客服对话场景语义更重要，向量权重大一些；而查订单号或错误码，关键词权重大一些。还有一种增强是稀疏检索，像SPLADE这种学习式稀疏向量，能弥补纯向量的盲区，但实现成本高，我一般只在长尾实体查询时才考虑。
然后是排序和索引。召回阶段一般拿到Top-K，但精度不够，需要精排。我会用 Cross-Encoder 对Top-50做重排，因为它做交互打分，精度高很多。但慢，所以我会做多阶段级联：先用向量快速召回Top-200，再用BM25过滤掉明显不相关的，最后用Cross-Encoder精排Top-20。这里有个坑：如果第一步召回就漏了关键文档，后面再怎么精排也救不回来，所以召回阶段Recall要优先。索引层面，分块策略很关键。固定长度切分会把语义割裂，比如一个退款政策条款被切到两个块里，检索时哪个都不完整。我会按语义切分，用句子边界或段落边界，保证每个块语义独立。另外，我会建摘要索引，对每个块生成一句话摘要，检索时先匹配摘要，减少噪声。但摘要本身也有精度损失，所以我会保留原文，在精排阶段用原文打分。
最后说说落地时的取舍。我不会把所有方法都堆上去，因为每加一层都意味着延迟和成本。我更倾向先分析业务场景：如果是FAQ类问题，查询改写和混合检索就够了，重排可以不要；如果是复杂推理，比如企业SOP合规文档，我会加上查询分解和重排。上线前我会特别关注两个风险：一是改写引入的幻觉，二是混合检索的融合权重不合理导致召回偏科。我会用一批历史query做回放，对比Recall@K和最终回答质量，调好再上线。
这里有个延伸点：最近GraphRAG在检索阶段引入知识图谱做实体关系扩展，能处理多跳推理问题，但构建和维护图谱成本很高。我其实很好奇，在什么业务场景下，GraphRAG的收益能覆盖它的成本？
所以我的核心观点是：检索质量不是堆方法，而是理解业务场景后做精准的取舍。
关键一句:GraphRAG引入知识图谱能处理多跳推理，但构建和维护成本高，值得探讨收益覆盖成本的场景。
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服系统，用户问“这款手机和那款比哪个好？”，你直接用问题去向量库搜，结果可能不理想。你一般会怎么优化这个检索？
- 问法 2 · 层层追问
RAG系统里检索质量怎么提升？……除了向量检索，还有哪些增强手段？……比如查询侧可以做什么？索引层面呢？
- 问法 3 · 直球架构
在RAG系统中，除了标准向量检索，还有哪些方法能提升检索阶段的质量？请从查询优化、检索策略、精排、索引等多个层面列举具体技术。