生产环境 Agent 的第一套评测集：用失败工单还是真实对话抽样？
rahulladumor · reddit · 2026-11-05
作者梳理 Anthropic、AWS、Shopify 三家对「生产中 Agent 的首个 eval 集从哪来」的不同建议，并给出自己的综合方案。
三方分歧
- Anthropic：从 bug tracker/支持队列抽 20-50 个真实失败案例即可起步；早期每次改动影响明显，小样本够用。
- AWS：从生产/试点日志构建 golden dataset，尤其关注差结果与负反馈。
- Shopify：放弃精 curated 的 golden set，转向从真实商家对话抽样、由至少 3 名产品专家标注的 Ground Truth Sets。
作者解读：两者回答的是不同问题——失败集问「坏的地方修了吗」，对话抽样问「Agent 在真实流量上到底多好」。前者快、无需标注团队；后者需要专家和经过校准的 judge。建议先做前者，judge 校准后再补后者。
单边评测的风险：支持队列工单多是「它本该做 X 却没做」，按此修复最省力的作弊方式是放宽策略(如乱批退款)。必须为每个用例写「should-not twin」——策略窗口外的近似请求必须拒绝。Anthropic 原话：「One-sided evals create one-sided optimization.」
具体构建清单
- 取最近 20-50 个答错的工单，按用户影响排序，改写成含参考答案、无歧义的单一任务(多次尝试 0% 通过通常是任务写坏了而非模型不行)。
- 每个任务旁写一个 should-not 孪生用例。
- 能用规则判定就在代码里判定(正确工具调用、退款额度内、escalation 标志)；需要 LLM judge 时先与人工标注校准，并定期审计漂移。
- 稳定通过的用例移入回归套件(回归 eval 应接近 100% 通过)。
脱敏陷阱：CloudWatch Logs 数据保护只是对所选标识符类型的查询视图，策略生效前摄入的日志不会被掩码，部分标识符还需邻近关键词；自由文本业务细节无托管类别。应在用例写入 repo 时自行脱敏。
「编程与Agent」频道最新
- LukeW 旗下 agent 应用 Intent 更新：工作区侧边栏与私密密钥请求 — LukeW · 2026-11-06
- Mistral 收编 SkipLabs 组建语言团队,为 AI 代码重构编译器与类型系统 — syhw · 2026-11-06
- Luke Wroblewski 发 Intent 更新:用工作区取代易崩溃的聊天线程 — LukeW · 2026-11-06
- 从 100 条生产 traces 起步：七步搭建贴合真实故障的 AI evals — HamelHusain · 2026-11-06
- 开发者发布游戏用像素画模型，支持精确尺寸与参考图风格一致 — HugoDuprez · 2026-11-06
- Hamel Husain：私有评测要测真实系统，而非抽象代理基准 — HamelHusain · 2026-11-06