Hamel Husain 和 Shreya Shankar 在 Maven 上教 AI Evals 课，700 多名工程师和 PM 上过。这篇 FAQ 是他们被问最多的约 40 个问题的合集，开头先声明：这些是"大多数情况下有效的尖锐观点，不是普世真理"。全文按七条主线组织，挑最反共识的说。
#最小可行 setup：一个专家 + 一个 notebook
新手问"evals 从哪开始"，答案出人意料地轻：每次大改动后花 30 分钟人工看 20-50 条产出 ，指定一个懂用户的领域专家当"仁慈独裁者"做质量裁决，用 notebook 或让 Claude/Codex 帮你写个自定义标注界面。不需要先买平台。
预算问题更直白：evals 不是单独的预算科目，它是开发过程本身，就像调试是软件开发的一部分。他们自己的项目里 60-80% 的开发时间花在错误分析和评估上 ——大头是"看数据理解失败"，不是搭自动化检查。另外警惕通过率陷阱：evals 100% 通过往往说明测试没在挑战系统，70% 可能才是有意义的评估。
#错误分析是地基，有方法论
核心流程是从质性研究借来的编码方法：Open Coding （逐条 trace 开放式标注失败模式，不加预设分类）→ Axial Coding （把涌现的失败归并成主题）→ 迭代精化。配套纪律：没有参考答案也能标注（先界定"坏"长什么样）、不是模型的错也要记录（UI/数据问题同样是产品问题）、数据集过时了就重跑而不是硬撑。
合成数据的答案很克制：只在特定场景可靠（如覆盖稀有失败模式），用之前先定义重要维度。
#方法论层面的几个硬立场
- 用二元 pass/fail，不用 1-5 分制 。Likert 量表相邻分值主观、标注者喜欢躲进中间值、检测差异需要更大样本。想追踪渐进改进就把"5 个事实覆盖 4 个"拆成 5 个二元检查
- eval-driven development 基本不做 。传统软件失败模式可预判所以 TDD 成立，LLM 失败面无限大——先写 evaluator 是在给想象的错误写测试。正确顺序是错误分析先行，为发现的 错误写 evaluator
- 不是每种失败都要自动化 。成本分层的：断言/regex 便宜随手建；LLM-as-Judge 要 100+ 标注样本加每周维护，只留给修完 prompt 还顽固存在的泛化失败
- 现成的通用指标是误导 。helpfulness/coherence 这类分数测的抽象品质跟你的场景无关，唯一能用的姿势是当"找可疑 trace"的探索信号
- BERTScore/ROUGE 不适合评 LLM 输出
#人的环节：别外包判断
标注外包被点名是"通常的大错"：外部标注员没有领域默会知识，打断"观察失败→改进产品"的反馈环。推荐路径是内部一个仁慈独裁者 + 多人标注时用 Cohen's Kappa 测一致性、对齐会消化分歧。例外只有机械任务（识别电话号码）、不需要产品上下文的任务（翻译）、以及把领域专家请进来 ——AnkiHub 雇四年级医学生评医学 RAG，这叫引智不叫外包。
LLM 能帮的是聚类 trace、生成候选失败模式、写初版 evaluator；不能外包的是界定质量标准、看数据建立产品直觉、和专家对齐。Prompt 自动生成工具同理——手动写 prompt 的过程本身在建立判断。
#工具与生产
- 标注工具倾向自建 而非买现成的：好界面要智能渲染 trace（不是通用 JSON 树）、支持键盘导航和进度显示、能聚类过滤搜索、优先排队"看起来有问题"的 trace——原则是做减法
- 现有 eval 平台普遍缺四块：错误分析/模式发现、全流程 AI 辅助、自定义 evaluator 而非通用指标、支持自建标注应用的 API
- guardrail ≠ evaluator ：guardrail 是生产路径上的实时拦截（要快要便宜），evaluator 是离线质量度量；evaluator 可以复用为自动纠错，但要过成本关
- CI 和生产监控是两件事但要连起来：CI 用固定的 gold set 防回归，生产监控用采样 + LLM 初筛发现新失败模式，发现的问题回流进 gold set
- 模型选择别花太多时间——选个够好的先用，把省下的时间给错误分析
#领域问题快答
- RAG 死了没 ：没死，但别把"能否直查"的问题默认做成向量检索；评 RAG 先分开评 retrieval（召回对不对）再评 generation（答案对不对）
- chunk 大小 ：固定输出任务（摘要、提取）用大 chunk；扩张性输出任务（分析、写作）用小 chunk
- 多轮对话 ：先尝试把问题简化成单轮再评；multi-agent trace 要记录每个 agent 的输入输出
- agentic workflow ：工具调用可以确定性测试（参数对不对、顺序对不对），语义质量还是要回到 trace 级人工审查
这篇 FAQ 最值钱的是它反复指向同一件事：evals 的瓶颈从来不是工具，是"有没有人认真看数据" 。所有的自动化建议都建立在这个前置条件上。