文章目录
- 前言
- 一、面试现场还原：为什么这道题能筛掉八成候选人
- 1. 大多数候选人踩的第一个坑
- 2. "检索不到"不等于"没有答案"
- 3. 这道题真正在筛什么
- 二、检索层抢救：查询改写与混合召回的三个方向
- 1. 查询改写：让模型先翻译用户的真实意图
- 2. 混合检索：不要只靠向量
- 3. 放宽阈值前先多召回候选
- 三、生成层底线：模型内部知识兜底的边界判断
- 1. 核心原则：宁可说不知道，也不要瞎编
- 2. 模型内部知识兜底：分场景判断
- 3. 边界必须在设计阶段就想清楚
- 四、交互层设计：把"没找到"变成一次挽回体验
- 1. 引导用户换个问法
- 2. 给出相关但非精确匹配的候选
- 3. 转人工或创建工单
- 五、系统层闭环：检索失败日志反哺知识库迭代
- 1. 定期分析检索失败的query日志
- 2. 针对高频未命中补充知识库
- 3. 建立兜底FAQ库
- 六、一个典型的四层兜底逻辑链
- 七、不同业务场景下的兜底策略差异对比
- 1. 企业内部知识库助手 vs 对外客服机器人
- 2. 法律/医疗/金融 vs 通用聊天
- 3. 高频标准问题 vs 长尾个性化问题
- 八、从架构师视角看RAG兜底的六个工程取舍
- 1. 查询改写次数：一次还是两次
- 2. 混合检索的融合权重：固定还是动态
- 3. 模型兜底标注：显式还是隐式
- 4. 候选内容提供阈值：给还是不给
- 5. 转人工触发条件：自动还是手动
- 6. 失败query分析周期：实时还是离线
- 九、面试话术：考官想听的是什么
- 1. 两个常见错误回答
- 2. 高分答题模板：三层结构
- 3. 60分 vs 90分对比
- 4. 加分项提示
- 总结
前言
做过智能客服系统的人，或者搭过企业知识库助手的技术同学，大概率都撞上过这么一个场景：用户兴致勃勃地提了一个问题，系统在知识库里检索了一圈，什么相关内容都没搜到。那一刻系统该怎么办？
很多人第一反应是让大模型自由发挥——结果就是一本正经地胡说八道，也就是大家常说的"幻觉"问题。在依赖真实知识的业务里（比如企业制度、产品参数、法务条款），一句编造的答案，代价远比直接说"我不知道"大得多。
一位前同事去面某里RAG相关岗位，三轮技术面里都被追问到了这个话题。面试官的原话很直白：“知识库检索不到的时候，你系统怎么兜底？”同期面试的候选人里，能给出完整方案的不到两成。
本文把"检索不到怎么办"这个问题从工程视角拆透。读完这篇文章你能搞明白：
- 检索层还能抢救的三个方向：查询改写、混合召回、候选放宽
- 生成层的底线原则：何时用模型内部知识兜底，何时坚决不编造
- 交互层怎么把"没找到"设计成挽回体验
- 系统层如何把失败日志变成知识库迭代的养料
- 架构师视角的六个工程取舍点
- 面试话术的三层答题模板
不管你是正在做RAG系统的工程师，还是准备大厂面试的候选人，这套四层兜底框架都值得收藏。开整！
