收集:多渠道捞,别只靠用户投诉
bad case 来源至少四个。用户侧:点赞点踩、投诉、客服工单,这是最真实的信号但量小且有偏;线上抽检:按天随机抽样一定数量的会话人工过一遍,这是发现「沉默失败」的唯一办法——用户问了、答案错了、用户默默走了,没有任何投诉;评测集回归:每次发版跑回归,新挂掉的就是新发 bad case;主动构造:团队内部红队、针对高危场景的刻意攻击。四个渠道汇到一个池子里统一管理,带上完整上下文:用户输入、模型输出、会话历史、用的模型版本和 prompt 版本,缺了这些后续没法归因。
归因:先分大类,再下钻
拿到 bad case 别急着改,先归类。实用的分类框架是五类:理解错(没听懂用户要什么)、知识错(事实错误、幻觉、知识过期)、推理错(逻辑链条断了)、格式错(答对了但没按要求输出)、不该答的答了(安全红线)。归因时多问一层「为什么」:知识错,是 RAG 没检索到,还是检索到了但模型没用?前者修检索,后者修 prompt。Cursor 早期有个经典问题:改代码时经常漏改相关联的文件,归因下来是上下文窗口里塞的文件不对,修复方向是给模型更好的代码库索引,而不是骂模型笨。归因到错误层,修复成本能差十倍。
分层:不是所有 bad case 都值得修
按「频率 × 严重度」画个四象限,这是排优先级最顺手的工具。高频高严重:核心场景答错,最高优先级,当周的迭代主题;高频低严重:比如回答啰嗦、格式不齐,攒一批用一次 prompt 调整扫掉;低频高严重:安全红线类,频率再低也要立专项,豆包、文心一言这些 C 端产品都栽过这类跟头,一次舆情顶半年口碑;低频低严重:直接进池子存着,不修,它们的存在本身就是正常的——AI 产品永远有长尾 bad case,追求清零是工程洁癖,不是产品思维。
修复:三把刀,成本递增
修复手段按成本从低到高:第一把是产品侧修复,成本最低——在输入端做意图引导(推荐问法、模板),在输出端做兜底(答案置信度低时给参考链接或转人工),这类修复今天提明天上;第二把是 prompt 和 RAG 修复,补充指令、加 few-shot 示例、修检索逻辑,一两天的事;第三把才是模型修复,微调甚至等基座模型升级,周期按周按月算。原则是能用便宜手段修的别动贵的,我见过 60% 以上的 bad case 靠 prompt 和 RAG 就解决了。但反过来也要清醒:如果一类 bad case 是模型能力天花板(比如复杂数学推理),prompt 救不了,诚实的产品方案是识别出这类问题并给替代路径,而不是硬扛。
闭环:修完的 bad case 必须回流评测集
这一步最容易被忽略,也是「治理」和「救火」的分水岭。每个修复的 bad case 都要进回归评测集,打上标签,之后每次发版自动跑,防止修复回退——大模型改一处 prompt 修好 A 问题带崩 B 问题是家常便饭,没有回归集就是打地鼠。同时要定期做 bad case 复盘:每月看各类 bad case 占比趋势,理解错占比持续高说明产品交互有问题,知识错占比高说明知识库该更新了。bad case 池是最好的产品需求池,比用户调研真实得多。
组织上怎么跑起来也要提前想。
流程再好,没人跑等于零。小团队的务实配置是:产品经理 owner 整个流程,定分类框架和优先级;算法或工程同学负责修复执行;抽检和归因可以全员轮值,每周固定一小时过新捞的 bad case,一次看个二三十条。关键是节奏固定,别搞成「有空再看」——bad case 治理死于拖延,不死于技术。大一点的团队可以配专职的 AI 训练师或数据标注负责人,但 owner 还是得是产品,因为只有产品能对「什么叫好」拍板。