01

60 秒回答模板

AI 产品满意度低的 bad case，我会先从用户结果定义，而不是只从模型错误定义。触发来源可以是低评分、投诉、重复追问、放弃任务、人工转接、长时间无响应等。分层上先按用户意图和任务类型分，再按问题原因分成理解错、事实错、拒答错、幻觉、响应慢、格式不符合、体验不连贯、安全风险等；同时按影响面和严重度定优先级。处理流程是抽样复盘用户上下文，标注真实期望、模型输出、失败原因和责任模块，再分流给 prompt/RAG/模型/产品交互/审核策略等 owner。短期可以做规则兜底、提示优化、人工接管或高风险拦截；长期要沉淀评测集、改指标看板、做 A/B 实验，并验证满意度和任务完成率是否改善。

考点 badcase 漏斗
难度 真实面经题
回答目标 分层处理低满意度 bad case
02

深入解析

01

badcase 要从用户 outcome 定义

AI 产品的 badcase 不只是模型答错。只要用户目标没有达成，都可能是 badcase，包括答案慢、表达不符合预期、多轮对话绕圈、需要重复输入、风险内容漏过、或者用户不信任结果。这样定义更贴近产品满意度。

02

触发信号要多源合并

低满意度可以来自显式低分、投诉、点踩，也可以来自隐式行为，比如连续追问同一问题、复制率低、人工转接、任务中断、响应超时、重新生成多次。显式反馈少且有偏，所以需要结合行为指标和人工抽样。

03

分层要同时看场景和原因

先按用户意图、任务类型、用户群体或入口分层，避免把所有问题混在一起。再按失败原因标注，比如意图理解、知识召回、事实生成、格式遵循、多轮记忆、延迟、交互引导和安全策略。这样才能知道是产品流程问题还是模型能力问题。

04

优先级按严重度和规模排序

不是所有 badcase 都同等处理。高优先级包括安全合规风险、影响核心任务完成、影响大流量入口、容易复现、修复成本低收益高的问题。低频且主观偏好强的问题可以进入观察池，不一定立即改模型。

05

处理要区分短期止血和长期修复

短期可以用提示词、规则兜底、结果重排、人工接管、禁用高风险能力或优化错误提示。长期要建设评测集、训练或微调、改检索链路、优化交互流程和指标口径。产品经理要推动 owner 和节奏，而不是只把问题丢给算法。

06

闭环用指标验证

修复后要看满意度、任务完成率、转人工率、重复追问率、延迟和风险率是否改善，并抽样检查是否引入新问题。badcase 还要沉淀到回归评测中，防止后续版本质量回退。

03

易错点

  • 把 badcase 只理解成模型答错，忽略延迟、交互、信任和任务完成。
  • 只收集用户点踩，不结合隐式行为和人工抽样。
  • 分层太粗，只写“算法问题/产品问题”，无法指导 owner 修复。
  • 所有 badcase 平均处理，没有按严重度和影响面排优先级。
  • 只做短期 prompt 修补，不沉淀评测集和回归机制。
  • 上线修复后不看指标变化，无法证明满意度真的提升。
04

面试官追问

用户点踩就一定是模型错吗？

不一定。可能是答案慢、交互不符合预期、用户目标变化、结果不可执行，也可能是模型事实错误。需要结合上下文复盘。

badcase 标注维度怎么设计？

至少包括用户意图、任务类型、失败原因、严重度、是否可复现、责任模块和建议修复方向。复杂场景可以增加用户群体和入口。

如何判断一个 badcase 是否优先处理？

看影响用户数、是否核心链路、严重程度、复现概率、风险等级和修复收益成本比。安全和核心任务失败优先级最高。

满意度提升如何验证？

用 A/B 实验或灰度对比，看显式满意度、任务完成率、重复追问率、转人工率和投诉率，同时人工复核关键样本。

产品经理在这个流程里负责什么？

负责定义指标、组织样本复盘、拆解原因、协调算法/工程/设计 owner、制定优先级，并验证修复是否真正改善用户 outcome。