完整题目
在检索增强生成（RAG）系统中，除基本的向量相似度检索外，还有哪些方法可以有效提升检索结果的相关性与准确性？例如重排序、查询扩展、混合检索等。
本文目录
RAG检索优化可以从检索前、检索中、检索后三个阶段系统提升：
一、检索前：查询优化
- 查询扩展：用LLM生成伪文档（HyDE）或扩展查询词，弥补用户query语义不完整的问题
- 查询改写：识别用户真实意图，消解歧义（如"苹果"→区分水果/公司）
- 多跳查询分解：复杂问题拆成子查询，分别检索后聚合
二、检索中：混合检索
单一向量检索有局限，典型组合：
- 稠密+稀疏：向量语义匹配 + BM25关键词匹配，互补召回
- 分数融合：线性加权或 learned sparse retrieval（如SPLADE）统一打分
- 多向量表示：ColBERT的late interaction，细粒度token级匹配
三、检索后：精排与过滤
- 重排序(Rerank)：用Cross-Encoder（如bge-reranker）对Top-K精排，捕捉细粒度交互
- 去噪过滤：基于置信度阈值、来源可信度过滤低质量片段
- 上下文压缩：用LLM提取关键句，解决上下文窗口冗余
四、工程权衡
线上部署需平衡效果与延迟，常见做法：
- 重排序模型蒸馏为轻量版，或异步离线预计算
- 分层检索：先快速粗排，再精排Top-K
- 缓存热门查询的检索结果
核心思路是多路召回+精排过滤，不要依赖单一向量相似度。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
我看你做过电商智能客服，用户搜‘红色连衣裙’，但库里只有‘酒红色长裙’，向量检索可能匹配不到，你怎么让系统还能把这个结果捞出来？除了调相似度阈值，还有别的招吗？
层层追问
RAG系统里，你一般怎么从知识库捞相关文档的？……那如果用户问得特别模糊怎么办？……再进一步，假设第一次召回的结果里混了很多不相关的，你后续怎么处理才能提升最终答案的质量？
直球架构
除了向量检索，RAG还有哪些手段能提升召回结果的准确率？从查询优化到检索后精排，你系统地说一下有哪些方法，各自解决什么问题，线上怎么权衡延迟？
练习口述回答 · 约4分钟
- 本质是召回与排序的工程问题
- 检索前：查询改写和扩展
- 检索中：混合检索互补
- 检索后：重排序与过滤
- 落地取舍：分层与缓存
这道题问的是[[RAG]]系统里怎么提升检索质量，我觉得本质上是在问怎么在召回率和精确率之间做工程取舍。因为单纯靠向量相似度，说白了就是一个语义匹配，但用户query往往不完整、有歧义，而且知识库里可能既有长文档又有短片段，单一路径很难覆盖全。所以我会从检索前、检索中、检索后三个阶段来考虑，具体说一下。
先说检索前，也就是查询优化。用户输入经常很随意，比如“苹果最新政策”，你根本不知道他问的是水果还是公司。这时候我会先做查询改写，用LLM把query补全成更清晰的表达，比如“苹果公司2024年秋季产品发布政策”。或者用查询扩展，比如 HyDE 的思路，先生成一个伪文档再检索，相当于把query映射到文档空间。这个阶段的核心是 减少语义鸿沟，让检索入口更准。但前提是得有足够的算力，而且query改写不能过度，否则会引入噪声，常见失败场景是改写后偏离了用户原意。
再一个，检索阶段。我基本不会只用向量检索，而是走[[混合检索]]。你可以这么理解：向量擅长语义相似，但关键词匹配在专有名词、编号、精确短语上更靠谱。所以我会把 [[Dense Retrieval]] 和 [[Sparse Retrieval]] 结合起来，比如向量加 [[BM25]]，用线性加权或者 Hybrid Search 统一打分。举个例子，在电商客服场景里，用户问“退款后多久到账”，向量能抓到语义相似的“退款周期”，但BM25能精准命中“退款到账”这个短语。两者互补，召回率能提不少。但这里的坑是分数融合的权重怎么调，如果向量权重太高，关键词匹配的精准片段可能排不上去；反过来又可能丢了语义。我一般会先离线跑一批query，根据 Recall@K 和 Precision@K 调参，或者用 SPLADE 这种可学习的稀疏检索自动学权重。
检索完之后，最关键的一步是[[重排序]]。因为初召回的Top-K里可能有噪声，比如语义相似但上下文不对。我会用 [[Cross-Encoder]] 做精排，比如 bge-reranker，它能看query和文档的完整交互，比向量余弦相似度准很多。这个阶段 能显著提升最终结果的相关性，但代价是计算量大，尤其Top-K设到100以上时延迟会炸。所以落地时我会做分层：先快速粗排拿到Top-50，再用重排模型精排Top-10。另外还会加去噪过滤，比如置信度阈值、来源可信度，或者用LLM做 上下文压缩，把冗余片段剪掉。
说到这里，其实还有一个更前沿的方向我没展开，就是基于图的检索增强，比如 [[GraphRAG]]，它在处理多跳、关系密集的问答时比纯向量检索强很多。比如企业合规文档里，一个条款可能引用另一个条款，图结构能显式建模这种依赖关系。但它的构建和维护成本也更高，不是所有场景都适用。
所以整体上，我更倾向把RAG检索看成 多路召回加精排过滤 的管线，而不是依赖单一技术。上线前我会特别注意分层检索的延迟预算，以及重排序模型的大小和[[蒸馏]]。如果离线评估时 [[Faithfulness]] 指标不达标，我会优先调重排序和过滤的阈值，而不是盲目加召回路数。