面试题 · 检索
搜索「医疗」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在检索增强生成（RAG）系统中，为何不能仅依赖向量相似度进行召回，而通常需要大模型对候选内容进一步重排序或生成？请分析其必要性。
1. 相似度≠相关性
2. Embedding模型的能力边界
3. 两阶段架构的设计逻辑
| 阶段 | 职责 | 特点 |
|---|---|---|
| 向量检索（粗排） |
按学习路线查看教程、项目和面试题。
| 快速缩小候选范围 |
| 速度快、召回率高、精确率低 |
| LLM重排/生成（精排） | 深度判断+综合决策 | 理解深、可结合上下文、成本高 |
4. LLM的独特优势
一句话总结：向量检索解决"找得快"，LLM解决"找得准"，两者互补构成完整RAG链路。
场景切入
假设你做一个电商客服的RAG系统，用户问“这款手机拍照怎么样”，向量检索召回了标题为“手机摄像头参数对比”的文章，但内容全是参数列表，没有实际拍照效果。你觉得光靠向量相似度够吗？为什么还需要大模型再处理一遍？
层层追问
RAG系统里召回这一步，你一般用什么方式？……那向量相似度能保证召回的内容和问题真正相关吗？……如果用户问“如何防止过拟合”，召回了“过拟合的危害”，你觉得这个结果行不行？……那接下来你通常会怎么做来提升质量？
直球架构
在RAG系统中，为什么不能只靠向量相似度做召回，还需要大模型重排序或生成？请从向量检索的局限性、两阶段架构的必要性以及大模型的独特能力几个角度来分析。
这道题其实在问一个很本质的问题：[[RAG]]系统里，向量检索和LLM[[重排序]]之间到底是什么关系？很多人以为向量搜到最相似的文档就完事了，但真正落过地就会知道，相似度和相关性是两回事。
先说向量检索的边界在哪里。[[Embedding]]模型做的是把文本映射到高维空间，距离近的语义上相似，但相似不等于能回答用户问题。举个例子，用户问“退款政策是什么”，向量检索可能召回一篇讲“退货流程”的文章，因为词向量接近，但文章里根本没提退款金额和时间限制，这种文档对LLM来说就是噪声。所以向量检索适合做粗筛，快速把候选从几百万缩小到几十条，保证召回率，但精确率不够。
那LLM重排序或者直接生成的价值在哪？它能做深层语义理解和上下文感知。比如同样搜“退款”，如果对话历史显示用户已经退货了，LLM能判断出用户现在需要的是“退款到账时间”，而不是“如何申请退款”。这种多维度判断，向量模型做不到。
具体到业务场景，比如电商客服的退款政策问答。用户问“我退货了，钱什么时候退？”，向量检索可能召回“退货流程”和“退款时效”两篇文档。如果只靠向量相似度，可能把“退货流程”排前面，但实际用户需要的是“退款时效”。这时候就需要Rerank模型或者LLM来重新排序，把真正相关的文档提上来。
但这里有个坑：LLM重排序不是万能的。前提是你的候选文档质量不能太差，如果向量检索召回的全是无关文档，LLM也救不回来。常见失败场景是Embedding模型领域适配不够，比如通用模型做医疗问答，专业术语向量化后语义偏移。上线我会特别关注候选集合的Recall@K，如果前20个里面没有正确答案，重排序再强也没用。
所以落地时我会采用混合策略：先用[[BM25]]和向量检索做[[Hybrid Search]]，保证召回覆盖，再用LLM做重排序或生成。说白了，向量检索解决“找得快”，LLM解决“找得准”，两者互补。
还有个延伸点：如果业务对实时性要求很高，比如金融实时风控，LLM重排序的延迟可能成为瓶颈。这时候我会考虑用[[Cross-Encoder]]做轻量级重排，或者干脆把重排序和生成合并，用[[Self-RAG]]让模型自己决定要不要搜外部知识。
总的来说，我不会把RAG看成简单的“搜+读”，而是看作一个资源分配问题。向量检索做第一轮过滤，LLM做最终决策，中间用重排序或者生成来弥合相似度和相关性的鸿沟。