考察点
这道题考察的是大模型应用的质量运营能力，常出现在问完「你们怎么评测」之后的连环追问里。面试官想看到的是闭环思维：badcase 不是收集完就完事，而是要驱动归因、修复、回归三个动作，最终沉淀成评测资产。没有闭环的 badcase 库只是垃圾桶。
参考答案
收集：被动渠道 + 主动挖掘
badcase 的来源要分层设计，只靠用户反馈会严重低估问题面。
被动渠道有三个。一是显式反馈：点踩、转人工、投诉，信号最准但量最少——实际点踩率通常远低于真实不满意率，大多数用户不满意时直接走人。二是行为信号：用户反复追问同一意图、会话中途放弃、复制后没有再回来（对工具型产品可能是好信号也可能是坏信号，要结合场景），这类隐式信号量大但噪声高，适合做粗筛。三是业务指标异常：某类意图的成功率突然下跌、某工具调用失败率上升，用监控告警兜住。
主动挖掘是拉开差距的部分。定期从线上日志里按规则捞可疑 case：judge 低分的、重试超过两次的、工具报错的、输出触发敏感词过滤的；再做聚类挖掘，把线上 query 按语义聚类，找那些成功率显著低于大盘的簇——往往对应你没想到的长尾场景。红队和内部狗食（dogfooding）也是稳定来源。
归因：统一错误分类法是前提
badcase 进库第一步是打标，标签体系决定后面能不能归因。常见的错误维度（按链路环节分）：
| 环节 | 典型错误 |
|---|---|
| 理解 | 意图识别错、多轮指代消解错 |
| 检索 | 召回缺失、召回无关、排序错位 |
| 规划 | 任务分解错、步骤冗余、死循环 |
| 工具 | 选错工具、参数错、超时未处理 |
| 生成 | 幻觉、格式不符、答非所问 |
| 安全 | 越权、泄露、注入成功 |
打标用 LLM 初标 + 人工复核争议样本。归因的价值在于量化分布：知道 40% 的 badcase 出在检索环节，就知道下一期优化预算该投给 RAG 而不是换模型。没有这个分布，团队很容易陷入「哪里被投诉就改哪里」的应激式开发。
修复：区分个案修复和系统性修复
归因后分两类处理。个案（某条知识过期、某个接口变更）直接修。系统性问题（一类意图识别都差、某工具描述导致参数普遍填错）要立项：改 prompt、补 few-shot、改工具 schema、加校验，严重的进微调数据。警惕一种反模式：往 system prompt 里无限堆补丁——每出一个 badcase 加一句「不要做 X」，prompt 越来越长，新补丁和老指令互相打架，整体效果反而退化。补丁超过十几条就该考虑合并重写或走微调。
回归：让事故变成资产
这是闭环的最后一环，也是最常被漏掉的。每个修复的 badcase 必须进评测集，带预期输出和错误标签。之后每次改动（prompt、模型、知识库、工具）都跑全量回归，关注两个数：老 badcase 的修复保持率（不能修了 A 坏 B）和整体成功率。评测集按「核心场景集 + badcase 回归集 + 红队安全集」三层组织，发布门禁卡在核心集成功率和安全集零通过（攻击全部拦截）上。
工程细节上有几点值得说。评测集要版本化，和代码一起进 git，哪次改动配哪版评测集可追溯；badcase 里的用户数据要脱敏后再入库；评测集会「过期」——业务变了、知识库更新了，原来的预期答案可能不再正确，需要定期复审，否则回归全是误报。
跑通这个闭环之后，团队的迭代模式会从「拍脑袋改 prompt」变成「数据驱动的定向优化」，这是大模型应用团队和玩具项目的分界线。
可能的追问
- badcase 太多修不过来，怎么排优先级？ 答：按「影响面 × 严重度」排：影响面看该类错误在线上流量中的占比，严重度看是否涉及安全、资损、合规。高频低危的走批量规则修，低频高危的走人工逐个修。
- 怎么防止修复一个 badcase 引入新的 badcase？ 答：这就是回归集存在的意义。修复时要求「针对性修复」而不是「全局改行为」——优先改检索数据、工具描述这类局部因素，动 system prompt 这种全局因素时必须全量回归。
- 线上流量里捞 badcase 有什么低成本技巧？ 答：用便宜模型先做粗筛打分，只把低分段送贵模型或人工；再按意图聚类后每簇只抽检代表样本，一个簇的问题通常是同质的，修一个代表等于修一簇。