POC / 评测阶段发现 AI 答错时，正确做法是分类归因再对症下药，而不是逐条喂答案。

核心心法：Badcase 是信号，不是作业。它的价值在于暴露系统性问题，而不是让你一条条去修补。

步骤总览

步骤 名称 核心问题 主要产出
1 收集 & 分类 错的 case 有什么共性？ 分类表（可复现/错误类型/输入特征/题目类型）
2 归因到根本原因 错在 Prompt / 模型 / 标注 / 任务定义？ 根因清单
3 对症修复 怎么改？每次只动一个变量 Prompt 改动 / 换模型 / 修标注 / 重定义任务

第一步：收集 & 分类（找规律）

把所有错误 case 集中，沿以下维度分类：

分类维度 问题
可复现 vs 偶发 同一输入再跑一次，还是错吗？
错误类型 完全答反？还是模糊/不确定？
输入特征 错的 case 有无共性（光线、角度、特定词汇……）
题目类型 集中在陷阱题还是常规题？

目标是找规律，而不是处理单条。

第二步：归因到根本原因

根本原因 典型症状
Prompt 没说清楚 边界情况 AI 自己猜，猜错方向
模型能力不够 该类任务模型天然处理不了
评测集/标注有问题 "正确答案"本身标错了
任务定义有歧义 连人工审核都会分歧，AI 无法一致作答

Agent 时代的四类归因（含验证方法与责任人）

当评测对象从单轮 Prompt 扩展到端到端 Agent，归因维度也随之扩展。每一类有不同的"怎么验证"和"谁来修"：

归因类别 典型表现 验证方法 主要责任人
模型能力问题 换了 Prompt 和数据，模型仍然答错 同一问题测多个模型对比 Server RD（换模型/Finetune）
Prompt 设计问题 调整 Prompt 后模型回答正确 A/B 测试不同 Prompt 版本 Server RD（优化 Prompt）
检索召回问题 相关文档未被召回，或召回了无关文档 检查检索日志、手动替换 query Server RD（调 RAG 链路）
Agent 行动问题 任务执行失败或出错导致结果异常 核查原始数据源、复查工具调用 Server RD（修工具/规划逻辑）

另有数据缺失类（底层没有对应知识/字段）→ 由 PM 补文档、QA/RD 清洗补充数据。归因结论决定改谁、谁改，是评测四角色（PM/运营/RD/QA）协作的交汇点，见 效果评测体系。

第三步：对症修复（每次只动一个变量）

  • Prompt 没说清 → 补规则、加约束、加 few-shot 样本（把规律提炼成规则写进 Prompt，或做成示例——这才是"告诉 AI 正确答案"的正确用法，不是单条喂）
  • 模型能力不够 → 换模型，重跑评测集对比
  • 标注错了 → 修正评测集，重新计算准确率
  • 任务定义模糊 → 重新定义任务边界，或调整 POC 的判断标准

常见误区

错误做法：发现一条答错 → 把正确答案塞进 Prompt → 这条对了，下一条类似的照样错，且完全不知道问题在哪。

正确做法：攒够 Badcase → 分类 → 找到根因类别 → 系统性修复。

线上数据回流闭环

评测的生命力在于持续分析。上线后要建数据回流机制：定期采集线上真实用户输入、AI 输出及反馈，一方面更新评测集（保持"活性"和真实性），另一方面把失败 case 喂进 Bad Case 分析。

核心理念：任何一个 Bad Case 都不能被忽视。要建从发现 → 记录 → 归因 → 解决 → 验证的完整闭环——修复后必须回归验证，确保问题被真正解决、避免重蹈覆辙。这是 AI 能力持续进化的关键。

与 POC 四步法的关系

对应 POC验证 第四步"看结果"：跑完评测集后，错误的那批 case 是"金矿"，用于判断这个方向是否值得继续，以及下一步改什么。

PM 此阶段职责

  1. 组织 Badcase 收集：定义错误标准，拉通业务方/算法/标注员把 case 攒进同一份表
  2. 主导分类与归因：技术能告诉你"模型在哪挂的"，但只有 PM 能判断"任务定义有没有问题、标准是否合理"
  3. 决定修复策略：每次只动一个变量、记录变更与效果，避免"改一堆变量后不知道哪个起作用"
  4. 决策是否放弃方向：当根因是"模型能力天然不够"且换模型无效，要敢于砍方向，回到 POC 重新定标准

协作对象：算法工程师、评测工程师、标注员、业务方

相关页面

→ POC验证 → 效果评测体系 → Prompt测试与Agent测试 → AI评测打分方法 → 数据准备五环节 → 提示词设计五要素 → Few-Shot少样本提示 → 模型选型方法论 → AIPM课程 Day11