01

60 秒回答模板

大模型产品的 badcase 不是用户不满意的统称，而是偏离产品目标、质量标准或安全边界的具体失败样本。我会先按业务目标制定 badcase taxonomy，例如事实错误、无关回答、幻觉引用、指令不遵循、上下文丢失、安全违规、体验差和成本延迟问题；再为每类定义严重级别、判定标准、正反例和处理优先级。评估归属上，产品负责定义目标、场景、标准和优先级；算法或工程负责模型与系统问题定位；人审团队负责按 rubric 标注；外包可以承担规模化标注，但必须经过培训、抽检、金标校准和一致性评估。最终 badcase 要回流到评测集、提示词、检索、模型、交互和运营策略中。

考点 badcase 标准必须来自产品目标
难度 真实面经题
回答目标 制定 badcase 标准和评估分工
02

深入解析

01

badcase 要按目标定义

badcase 不是所有负反馈，也不是所有模型答错。它应对应产品承诺和用户任务，比如答案不正确、没有解决问题、引用不可信、违反安全规则、交互不可用或成本延迟不可接受。先定义目标，标准才不会漂移。

02

建立失败分类和严重级别

可以把 badcase 分为意图理解错、知识缺失、检索失败、事实错误、幻觉、格式不符、上下文丢失、安全违规和体验问题。每类再按严重程度分级，例如阻断任务、高风险误导、轻微不完整或表达瑕疵。

03

rubric 要有正反例

评估标准不能只写一句好或不好。要有清晰 rubric、判定边界、示例、反例和常见争议处理方式。比如什么算事实错误，什么算表达不完整，什么情况需要判安全违规，标注员才能稳定执行。

04

产品、人审和外包分工不同

产品经理负责定义业务目标、用户场景、badcase taxonomy、优先级和验收口径；内部人审或专家负责标准打磨和高价值样本判断；外包团队可做规模化标注，但不能替代产品对标准和业务优先级的负责。

05

标注质量需要校准

无论人审还是外包，都要做培训、试标、金标集、双人标注、抽检、分歧仲裁和一致性指标。发现标注漂移时要更新 rubric 和样例，避免评估结果只是标注员偏好的噪声。

06

badcase 要进入迭代闭环

badcase 的价值在于驱动改进。要把样本按原因分配给产品、算法、检索、工程或运营，形成修复动作，并沉淀到回归评测集。修完后要验证同类问题是否下降，而不是只处理单个样本。

03

易错点

  • 把 badcase 简单等同于用户点踩或投诉。
  • 没有分类和严重级别，所有问题都混在一起处理。
  • rubric 只有抽象描述，没有正反例和边界说明。
  • 把评估标准完全交给外包，产品不负责业务口径。
  • 没有金标、抽检和一致性校准，标注质量不可控。
  • 收集 badcase 后不进入回归评测和迭代闭环。
04

面试官追问

如何区分用户主观不喜欢和真正的 badcase？

不是。用户不满意可能来自预期、入口、等待、交互或业务策略；badcase 标准要能定位可改进的失败类型，如事实错、遗漏、拒答错、格式错、风险问题和体验问题。

badcase 严重级别应该如何划分？

先按用户任务和业务目标定义质量维度，再把错误拆成类型、严重程度和判定样例。每个等级都要有正反例和处理建议，方便产品、人审和外包团队保持一致。

外包标注团队和产品团队意见不一致时怎么办？

产品定义标准、场景优先级和业务影响；人审负责复杂语义和主观质量判断；外包适合按明确 rubric 做大规模标注。高风险和模糊样本应回到产品或专家复核。

如何判断标注标准发生漂移？

用培训样本、标注考试、双人标注、一致性指标、抽检、申诉机制和周期性校准。外包不能只看产量，要看误判率、分歧率和高风险漏判。

badcase 样本如何转成回归评测集？

可以先进入人工复核和专家仲裁，并更新 rubric。如果大量分歧来自标准不清，说明 badcase 定义需要细化，而不是简单要求标注员服从。

产品经理在 badcase 评估中应该负责到什么程度？

不同 badcase 类型对应不同 owner：模型事实错给算法/数据，知识缺失给知识库，入口误导给产品，延迟成本给工程，风险漏拦给安全或审核。