考察点
这道题把「幻觉」从技术概念拉到了事故现场:不是问你怎么解释幻觉,而是问你负责的 AI 功能已经推荐错了,你现在干什么。面试官想看的是三层能力:应急反应是否有序(先止血还是先查原因,很多人一上来就钻进代码);归因思路是否分层(模型问题、数据问题、产品设计问题,处理方式完全不同);有没有从一次事故沉淀出长期机制的意识。电商场景的特殊性在于,错误推荐可能直接造成资损(报错价)、客诉(推荐不存在的功能)甚至合规风险(医疗保健品的错误宣称),这比聊天机器人说错话严重得多。追问一般往「怎么向用户补偿」「怎么防止复发」「上线前怎么拦住」走。
参考答案
第一时间的动作:止血先于归因
发现明显错误推荐,我的动作顺序是固定的:先降级,再评估,最后修复。降级指立即把出问题的 AI 功能切到保底路径——导购场景就回退到传统搜索推荐结果,或者把 AI 推荐卡片加上人工审核后才放出;这个动作应该在半小时内完成,不需要等查清楚原因。评估是定量:错误推荐的曝光量有多大、影响面是单点 query 还是某个品类、有没有实际产生客诉或资损。这里要克制一个冲动:不要在原因没查清时发公告或大规模补偿,电商场景里过度反应本身会引发恐慌性投诉。止血完成后才进入排查。
归因分三层,每层药方不同
模型层的幻觉是模型「一本正经地编」:虚构商品卖点、编造参数。这类问题的根治办法是把自由生成改成受约束生成——商品事实必须从商品库实时取数,模型只负责组织语言,prompt 里明确「不知道的就说不知道」,再配合输出侧的事实校验(生成的参数和商品库字段比对,对不上就拦截重写)。数据层的问题更隐蔽:商品库本身字段缺失或过期、RAG 召回错了文档,模型只是如实转述了错数据。这要回到数据治理,修知识库、调召回。产品层的问题最容易被忽略:是产品设计把模型逼到了必须编的地步——比如 UI 上承诺「AI 为你精选最优款」,逼着模型在候选都不行的情况下也要硬选一个。这三层我每次都会各查一遍,实际项目里大约一半被定性为「幻觉」的问题,根子其实在数据和产品设计。
对用户的处理:按实际损失分级响应
没有造成实际损失的(用户看到了错推荐但没下单),沉默修复即可,不需要惊动。产生损失的(基于错误信息下单、买错型号),走客服通道个案处理,退换货成本该认就认——京东的售后体系本身就是干这个的,AI 推荐导致的问题纳入现有售后流程,别发明新流程。唯一需要主动触达的情况是涉及健康安全的错误宣称(比如保健品的功效说错),这类要召回式处理,主动联系已购用户。原则是:补偿跟着损失走,不跟着舆情走。
从事故到机制:三层防线
一次事故处理完,必须沉淀出长期机制,否则白交学费。我的做法是三层防线:上线前的红线评测集,把本次事故的 case 固化进去,以后每次模型或 prompt 变更必须全量回归,红线 case 一个都不能错;线上的实时拦截,对价格、功效宣称、资质类内容做关键词+结构化比对的双重校验,命中即拦截转人工话术;持续的比例监控,按周抽样人工检查 AI 推荐的事实准确率,跌破阈值(比如 99%)自动触发降级策略。幻觉在技术上无法清零,产品要做的是让残余的幻觉不造成实际伤害——这是电商 AI 和聊天 AI 在风控思路上最大的区别。
可能的追问
- 「明显错误」多严重算明显?由谁判定? 答:提前定义分级:涉及价格、库存、功效、资质的错误是红线,任何一例都算事故;推荐不准但信息真实的算体验问题,走常规优化。判定靠抽检+用户举报双通道,红线问题设告警,不等攒多了才发现。
- 实时拦截会不会误伤正常推荐? 答:会,所以拦截只针对事实性断言(具体数字、功效词),观点性表达不拦;误拦率要监控,超过 5% 说明规则太粗,该上更精细的结构化比对而不是加关键词。
- 模型供应商(或自研团队)说「这是概率问题,改不了」怎么办? 答:部分接受。生成侧的概率问题改不了,就在工程侧兜:事实校验、受约束生成、高风险品类白名单。PM 的职责是把「模型做不到」翻译成「产品怎么仍然安全」,而不是逼模型团队承诺零幻觉——那个承诺没有意义。
- 怎么向老板汇报这类事故? 答:按「影响面(量化)-根因(分层)-已止血动作-长期机制-复发概率判断」五段式,数据说话,不隐瞒也不渲染。重点是把「这次交了学费买到什么机制」讲清楚,这比道歉有用。