面试题 · 检索
搜索「Embedding 模型」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，当检索环节未能从知识库中找到相关文档时，应该采取哪些策略来保证系统的鲁棒性和回答质量？
原始Query → 同义词扩展/Query分解 → 多轮改写 → 重新检索按学习路线查看教程、项目和面试题。
关键权衡：业务容忍度决定策略——客服场景宁可不答不能错答；通用问答可适当放宽。
场景切入
假设你在做一个电商客服机器人，用户问“这个订单什么时候发货”，结果知识库里没有这个商品的信息。这时候你该怎么处理，才能既不让用户失望，又避免瞎编乱造？
层层追问
RAG系统检索不到相关文档时，你会怎么兜底？……那如果检索到的文档质量很差呢？……怎么让模型知道它该用自身知识还是拒绝回答？
直球架构
设计RAG系统的检索失败兜底策略，要求处理零结果和低质量结果两种情况，给出查询改写、多路召回、模型侧兜底和用户反馈闭环的具体方案。
这道题其实是在问，当检索这个环节失灵了，系统怎么还能给出一个靠谱的答案。本质上是[[RAG]]系统的边界问题，就是知识库覆盖不到、或者检索质量差的时候，怎么保证不崩。
先说清楚，检索失败不只是没结果。我一般会先区分两种：一种是零结果，[[向量库]]什么都没返回，这可能是[[embedding]]或者索引有问题；另一种是低质量结果，有东西但相似度不够，或者Top-K之间得分差距太大，这种其实更常见更麻烦。
对零结果，我第一反应不是直接放弃，而是查一下是不是Query本身有问题。比如说用户问「退款多久到账」，可能知识库里存的表述是「退款到账周期」，那同义词扩展就很有用。我会先用LLM做一次查询改写，比如把Query拆成子问题，或者用HyDE的方式，让LLM先基于Query生成一段假设的文档，再用这个文档的embedding去检索，往往能捞到东西。
如果改写还不行，那就得靠多路召回兜底了。我会把向量检索和[[BM25]]关键词检索结合起来，再叠加[[知识图谱]]。举个例子，电商客服场景，用户问「满200减30和满300减50能叠加吗」，向量检索可能因为术语不匹配没找到，但BM25能通过「满减」「叠加」这些关键词命中，知识图谱也能给出规则关系。一路不行其他路补上，这是最稳健的架构。
再一个就是降维检索，把相似度阈值调低，先扩大召回范围，让[[重排]]模型去过滤。但这个有前提，就是你的重排模型得够强，不然噪音太多反而影响质量。
如果检索侧怎么都救不回来，那就得靠模型侧兜底了。我会在Prompt里显式告诉LLM：当前没有检索到相关知识，请基于自己的知识谨慎回答，并明确标识这是推测。高风险场景，比如金融合同或者医疗问答，我倾向于直接拒绝，返回「知识库未覆盖该问题」，宁可不答不能错答。这其实是业务容忍度的取舍，客服场景容错率低，就得保守；通用闲聊可以宽松一些。
最后是用户侧闭环。我会把失败的Query记录下来，触发离线分析，看看是不是知识库缺失，然后补充。同时在界面给个「未找到答案，提交人工反馈」的入口，让用户能参与进来。
但说实话，这些策略里有一个隐性前提，就是你的LLM自身知识得有一定可信度。如果模型本身就很弱，那让它基于自身知识回答反而会加重[[Hallucination]]。所以我会更倾向于，在模型侧兜底之前，先评估模型的领域能力，如果不行就干脆拒绝回答，而不是让它猜。
所以整体上，我会把检索失败看成系统设计的一部分，而不是异常。分层兜底，从查询改写、多路召回，到模型侧显式声明，再到用户反馈闭环，每一层都做减法，能救就救，救不了就诚实告诉用户。