LLM Evals 常见问题全书（中文导读）

一、最小可行方案（MVP）

• 从错误分析开始，而非基础设施：每次重大变更后花 30 分钟人工审查 20—50 条输出；
• 指定一位懂用户的领域专家作为质量决策者（「仁慈独裁者」），避免委员会瘫痪；
• 项目中 60—80% 的开发时间花在错误分析和评估上，且大部分精力用于理解失败（看数据），而非构建自动化检查；
• 警惕高通过率：100% 通过说明测试不够有挑战性，70% 通过率可能意味着评估更有意义；
• 向团队争取投入的方法：不要推销「evals」概念，展示数据中的发现——「我们在用户看到之前拦截了 47 个问题」比抽象推销有说服力得多。

二、错误分析：评估中最重要的活动

四步流程（借鉴质性研究方法）：

1. 创建数据集：收集代表性 trace，无数据时可先生成合成数据；
2. 开放编码（Open Coding）：人工对 trace 写开放式笔记，聚焦每条 trace 中观察到的第一个失败（上游错误会级联到下游）；
3. 主轴编码（Axial Coding）：把笔记归类为「失败分类法」——这是最重要的一步，最后统计各类别失败数量；
4. 迭代精炼：直到理论饱和——新 trace 不再揭示新失败模式。

三、LLM Judge 校准

• 任务形态：限定范围的二元（pass/fail）分类，不用 1—5 分李克特量表（相邻分值主观、标注不一致、需要更大样本）；
• 校准流程：错误分析 → 提示迭代 → 标注样本 → 在留出测试集上测 TPR（真阳性率）和 TNR（真阴性率）→ 用已知准确率校正失败率估计；
• 主任务和 judge 可以用同一个模型——真正重要的是 judge 与人类判断的对齐程度；先用最强模型建立对齐，之后再优化成本；
• 成本认知：每个 LLM-as-Judge 需要 100+ 标注样本 + 每周维护 + 跨角色协调——只为「修完提示后仍持续存在、且需反复迭代」的问题构建；
• ground truth 标注必须逐条人工验证。

四、高频实践问答精选

• 合成数据怎么生成？用「维度法」：定义维度（如饮食限制 × 菜系 × 复杂度）→ 先手写 20 个元组 → 两步生成法扩大规模（先生成元组、再转自然语言，避免措辞重复）。合成查询要跑过真实系统采集完整 trace，抽样 100 条做错误分析；
• 开箱即用的评估指标有用吗？通用评估浪费时间并制造虚假信心。BERTScore/ROUGE 等相似度指标对大多数 AI 应用没用（例外：搜索和推荐）；
• 评估驱动开发（先写 eval 再开发）对吗？一般不对——LLM 的失败面无限大，先做错误分析，为发现的错误写评估器；
• CI 评估与生产监控有何不同？CI 测试集小（100+ 条精选）、优先确定性断言；生产评估抽样实时 trace、更多依赖 LLM-as-judge、追踪置信区间。生产发现的新失败模式要加入 CI 防回归；
• 护栏（guardrails）与评估器（evaluators）的区别？护栏同步运行在响应到达用户之前（快、确定性、可拦截）；评估器异步批处理（可用 LLM Judge，喂给仪表盘）。不要把慢且非确定性的 Judge 用作同步护栏；
• 如何调试多轮对话？初期只标第一个失败；用最简方式复现（第 4 轮答错退货政策 → 简化为单轮问题，若仍失败说明是基础检索问题）；
• 如何评估 agentic 工作流？两阶段：端到端任务成功（黑盒）+ 步骤级诊断。推荐「转移失败矩阵」：行 = 最后成功状态，列 = 首次失败位置——一眼看出调试精力该投哪里；
• RAG 怎么评？检索组件用传统 IR 指标（Recall@k、Precision@k、MRR）；生成组件走标准流程（错误分析 → LLM judge → 人工验证）；
• 自建还是买标注工具？强烈建议自建——有定制工具的团队迭代速度快约 10 倍，用 AI 开发工具几小时可搭好。

五、人机分工边界

可以借助 LLM（需人工监督）：首轮主轴编码的分组建议、将新 trace 映射到已有失败模式、建议提示改进、分析标注数据找模式。

绝不能外包给 LLM：初始开放编码、验证失败分类法、ground truth 标注、根因分析。

总结：先手动看数据理解问题，再用 LLM 放大你学到的东西——而不是用 LLM 逃避看数据。