考察点
这道题出自千问主 Chat 产品经理实习面,是诊断类问题,考察的是你在幻觉这个被聊烂的话题上有没有真正的工程化思维。大多数人会答「加强 RAG」「优化 prompt」这种正确的废话。面试官想看的是一套可操作的归因流程:拿到一条幻觉 bad case,你怎么一步步判断病灶在哪一层,因为不同层的修复成本差着几个数量级——改 prompt 是一下午,换模型是一个季度。追问会往「各层修复的优先级」「怎么防止修复引入新问题」上走。
参考答案
归因的第一步:把「幻觉」拆开
幻觉不是一个问题,是一族问题。拿到 bad case 先问一句:正确答案到底存不存在、在哪里。我按这个把幻觉分成四种,对应四个责任层:
- 事实型幻觉:问题有客观正确答案(「这款车的上市时间」),模型答错了。可能是模型知识过期或根本没有,也可能是检索没给到。
- 检索型幻觉:正确答案就在知识库里,但没被检索到,或检索到了模型没用。
- 指令型幻觉:模型理解了问题但答非所问、格式不对、无视约束(「用 100 字回答」结果写了 500 字)。
- 策略型幻觉:产品设计逼着模型编答案——比如产品要求「任何情况下都要给出回答」,那模型遇到不知道的问题只能瞎编,这个锅在产品不在模型。
这个分类的意义在于:每一类的修复手段和负责人完全不同,混在一起讨论就是一锅粥。
四层排查法:从便宜到贵
我排查的顺序是按修复成本从低到高排,因为大部分幻觉其实是便宜的问题。
第一查产品策略(成本:改配置)。先看是不是产品机制在制造幻觉:有没有「必须回答」的霸王条款?有没有缺省值设置不合理(比如默认联网但联网超时后没降级逻辑)?有没有温度参数调得太高?我遇到过一个案例,客服机器人幻觉率飙升,查了一圈发现是运营把 temperature 从 0.1 调到了 0.8 想「让回复更活泼」,五分钟改回来解决。这层的问题特征是同配置下大面积、同类型的出错。
第二查 Prompt(成本:改文案)。看 prompt 有没有给模型留出编答案的空间:有没有明确说「不知道就说不知道」?有没有给拒答和转人工的出口?检索结果为空时 prompt 指令是什么——很多幻觉发生在「知识库没查到,但 prompt 没说没查到该怎么办」,模型只能自由发挥。还有 few-shot 示例里有没有混入了错误示范。这层的修复是小时级的。
第三查检索(成本:调链路)。如果产品挂了知识库,做三步验证:把 query 单独拿去检索,看 top-k 结果里有没有正确答案——没有,是召回问题(embedding 不匹配、切分粒度不对、知识库本身缺这条);有,看它被排在第几——排在十名开外,是排序问题,加 rerank;排在前三但模型回答时没用上,那是生成阶段的上下文使用问题,回到 prompt 层解决,比如要求模型显式引用来源。经验上,挂了 RAG 的系统里,六成以上的「幻觉」其实是检索层的锅。
第四才轮到模型能力(成本:换模型/精调)。前三层都排除了——知识没有正确答案,或者正确答案喂到嘴边模型还是理解错、推理错——这才是模型能力边界。判断标准是构造一个「开卷考试」:把正确资料直接放进上下文,模型还答错,那就是能力问题。修复手段是换更强的模型、针对该任务类型精调,或者干脆承认这个问题超出现有能力,产品上转人工。这一层最忌讳的是绕过前三层直接喊「模型不行」——换模型是几个月的周期,而如果病灶本来在检索层,换再强的模型回来,错还是照错。
让归因成为机制,而不是靠人肉
单次归因靠经验,规模化归因要靠建设。我的做法是给幻觉 bad case 打标签入库(四种类型 + 场景 + 严重度),定期看分布:检索型占比突然上升,通常是知识库更新出了岔子;指令型集中在某类任务,说明 prompt 模板要修。这个分布本身就是迭代路线图——优先修占比最大、修复成本最低的那类,幻觉率的下降是可见的。
还有一个机制是修复后必须回归:每次改 prompt 或调检索参数,用历史幻觉 case 集 + 正常 case 集各跑一遍,防止修好了 A 场景、打破了 B 场景。幻觉治理最怕打地鼠,回归评测集是唯一的防空洞。
可能的追问
- C 端通用聊天没有知识库,怎么归因? 答:少一层检索,但多一层「模型知识边界」的判断。先确认这个问题在不在模型训练数据的时间范围和覆盖领域内——问 2026 年新出的政策,模型不知道是正常的,该做的是产品上接联网检索或时间声明,而不是骂模型笨。
- 四层里你最常修的是哪层? 答:有 RAG 的系统是检索层,占一半以上;纯对话产品是 prompt 和产品策略层。真正归到模型能力的不到两成——大多数「模型不行」其实是「系统没给模型创造条件」。
- 怎么定量评估幻觉治理的效果? 答:建一个带标准答案的评测集(几百条,覆盖高危场景),每次迭代跑自动评测(用大模型做 judge 判事实一致性),线上再配合用户点踩率和抽样人工审核,离线在线两个数对齐看。