7.8
深览指数
科技人人都是产品经理·学不会AI··AI 生成
Agent 时代的 AI 评估新范式
本文系统剖析了从传统 Chatbot 到 Agent 时代，AI 评估面临的三个结构性难题：评估维度爆炸、过程黑盒化、自动化评估信任危机。作者基于实践经验，提出团队应优先通过手工分析 20-50 条真实执行记录建立失败模式分类，再构建评估体系。核心方法论包括：以分类优于打分、验证 LLM-as-Judge 的 TPR/TNR、建立“仁慈的独裁者”人机协作流程。文章强调，Agent 评估的真正稀缺资源不是先进工具，而是数据科学的基本功——花时间看原始数据。适合正在构建或优化 Agent 产品评估体系的 AI 应用团队、AI Infra 工程师阅读。原文 ↗
核心观点
- ▍Agent 时代 AI 评估的核心困境是评估维度爆炸、过程黑盒化和自动化评估信任危机，传统 Chatbot 的线性评估体系已完全失效。
- ▍评估体系应建立在错误分析基础上：先花 30 分钟手工看 20-50 条真实的 Agent 执行记录，通过 Open Coding 和 Axial Coding 建立属于自己业务的失败模式分类清单，而非直接搭建平台。
- 01作者建议团队将 60%-80% 的开发时间花在错误分析和评估上，而大多数团队实际只花 10%。
- 02LLM-as-Judge 用二元评分（Pass/Fail）比打分制（1-5 分）效果更好，因为不同人或同一人在不同时间对“3分”的理解差异巨大。
- 03验证 Judge 需关注 TPR（真阳性率）和 TNR（真阴性率）而非准确率。若失败率仅 5%，一个永远 Pass 的 Judge 准确率也有 95%。
- 04合成数据生成的最佳实践是先基于真实数据定义关键变化维度（如问题类型、紧急程度），再手动写 20 个种子维度组合，最后用 LLM 扩展。
- 05人机协作评估推荐“仁慈的独裁者”机制：指定一位领域专家作为最终判断标准，以避免多人标注带来的标准差异与漂移问题。
- 06CI 评估（发布前）使用小数据集（约 100 条）做确定性检查；生产监控（发布后）采样分析发现新失败模式，两者需形成循环。
反方 / 局限
- — 作者承认，合成数据在高度专业化的领域知识、低资源语言、高风险决策场景中可能产生严重偏差，应谨慎使用。
- — LLM-as-Judge 本身存在固有偏差（倾向高分/严格、对特定语言敏感），且偏差会随模型版本更新而变化，需要持续监控而非一次验证。
- — 作者指出“标准漂移”是常态——专家在标注过程中会不断重新定义标准，这意味着评估体系的参考标准本身也在动态变化。
HamelLLM-as-JudgePyAI 大会The Revenge of the Data ScientistOpen CodingAxial CodingGuardrailsEvaluators
16 分钟 · 5 卡片 · 10 资料
读原文 →