eval-audit

评估审计

检查大模型评估流水线，并按优先级列出问题及具体的后续步骤。

概述

1. 收集评估产物：轨迹、评估器配置、裁判提示词、标注数据、指标仪表板
2. 从六个方面运行诊断检查
3. 生成按影响排序的发现报告，每项发现都附有修复方法的链接

前提条件

可通过可观测性 MCP 服务或本地文件访问评估产物（轨迹、评估器配置、裁判提示词、标注数据）。如果不存在，请跳转至“没有评估基础设施”。

连接到评估基础设施

检查用户是否已连接可观测性 MCP 服务（Phoenix、Braintrust、LangSmith、Truesight 或类似服务）。如果已连接，请使用它提取轨迹、评估器定义和实验结果。如果没有，请索取本地文件：CSV、JSON 轨迹导出文件、笔记本或评估脚本。

诊断检查

逐项检查以下各个方面。检查可用产物，判断问题是否存在；如果存在，则记录一项发现。

根据对用户产品的影响确定发现的优先级。最重要的发现应排在最前面。

1. 错误分析

检查： 用户是否对真实或合成轨迹进行了系统性的错误分析？

查看：已标注的轨迹数据集、失败类别定义、轨迹审查记录。如果已有评估器，但没有记录失败类别，则很可能跳过了错误分析。

缺失时的发现： 在没有进行错误分析的情况下构建的评估器，衡量的是通用质量（“有帮助性”“连贯性”），而非实际失败模式。如果没有轨迹，请先从 error-analysis 开始；如果没有轨迹，则先运行 generate-synthetic-data。

参见：你的 AI 产品需要评估、大模型评估常见问题

检查： 失败类别是通过头脑风暴得出，还是从实际情况中观察得出？

从研究中借用的通用标签（“幻觉评分”“毒性”“连贯性”）表明类别是通过头脑风暴得出的。基于具体应用的类别（“遗漏查询约束”“客户端语气不当”“虚构房产特征”）则表明类别是从实际情况中观察得出的。

通过头脑风暴得出时的发现： 通用类别会遗漏应用特有的失败，并导致评估器在纸面上评分很高，却无法发现真实问题。请从轨迹入手，使用 error-analysis 重新进行分析。

参见：谁来验证验证者？

2. 评估器设计

检查： 评估器是否采用二元通过/失败判定？

标记使用 Likert 量表（1-5）、字母等级（A-F）或没有明确通过/失败阈值的数字评分。

非二元判定时的发现： Likert 量表难以校准。标注人员对 3 分和 4 分的区别意见不一，裁判也会继承这种噪声。可考虑使用 write-judge-prompt，将判定转换为带有明确标准的二元通过/失败判定。

参见：创建推动业务成果的 LLM 裁判

检查： LLM 裁判提示词是否针对特定失败模式？

标记整体性评估（“这个回答有帮助吗？”“为这个输出的质量打分。”）。

判定标准含糊时的发现： 整体性裁判会给出无法采取行动的结论。每个裁判都应只检查一种失败模式，并配有明确的通过/失败判定标准和少量样例。使用 write-judge-prompt。

检查： 是否尽可能使用基于代码的检查？

标记使用 LLM 裁判评估可客观检查的标准：格式验证、约束满足、关键词是否出现、模式是否一致。

过度依赖裁判时的发现： 用代码替代客观检查（正则表达式、解析、模式验证、执行测试）。仅在标准需要解释判断时使用 LLM 裁判。

检查： 是否将相似度指标用作主要评估方式？

标记将 ROUGE、BERTScore、余弦相似度或嵌入距离用作生成质量的主要评估器。

存在此情况时的发现： 这些指标衡量的是表层重合度，而非正确性。它们适用于检索排序，但不适用于生成评估。应改用基于特定失败模式的二元评估器。

参见：LLM 评估常见问题

3. 裁判验证

检查： 是否根据人工标签验证 LLM 裁判？

查找：混淆矩阵、TPR/TNR 测量值、对齐分数。已用于生产但没有验证数据的裁判属于关键问题。

未经验证时的发现： 未经验证的裁判可能会持续漏掉失败项，或将通过的轨迹标记为失败。使用 validate-evaluator，在留出的测试集上通过 TPR 和 TNR 测量对齐情况。

参见：创建推动业务成果的 LLM 裁判

检查： 是否使用 TPR/TNR 而非原始准确率来衡量对齐情况？

标记将“准确率”、“一致率”或 Cohen's Kappa 用作主要对齐指标。

使用准确率时的发现： 在类别不平衡的情况下，原始准确率会产生误导：当 90% 的轨迹通过时，始终判定为“通过”的裁判也能达到 90% 的准确率，却无法发现任何失败项。应使用与偏差校正直接对应的 TPR 和 TNR。使用 validate-evaluator。

检查： 是否正确划分了训练集、开发集和测试集？

检查裁判提示词中的少量样例是否来自与衡量裁判性能相同的数据。

发生数据泄漏时的发现： 将评估数据用作少量样例会虚增对齐分数，并掩盖裁判实际存在的问题。应划分训练集（少量样例来源）、开发集（迭代）和测试集（最终测量）。使用 validate-evaluator。

4. 人工审核流程

检查： 谁在审核跟踪记录？

确定标注数据的是领域专家还是外包标注人员。

如果由缺乏领域专业知识的外包人员标注，则发现： 普通标注人员能发现格式错误，却会漏掉特定领域的问题（剂量错误、法律引文不正确、房产特征不匹配）。请让领域专家参与审核。

参见：改进 AI 产品实地指南

检查： 审核人员看到的是完整跟踪记录，还是只有最终输出？

如果只看输出，则发现： 只审核最终输出会掩盖工作流在哪一步出了问题。请展示完整跟踪记录：输入、中间步骤、工具调用、检索到的上下文和最终输出。

检查： 数据以什么形式展示给审核人员？

留意原始 JSON、未格式化文本，或将跟踪记录数据放在单元格中的电子表格。

如果是原始格式，则发现： 审核人员会把精力花在解析数据上，而非判断质量。请以自然的形式呈现：渲染 Markdown、为代码添加语法高亮、将表格显示为表格。使用 build-review-interface。

参见：LLM 评估常见问题

5. 标注数据

检查： 标注数据是否充足？

对于错误分析，约 100 条跟踪记录是达到饱和的大致目标。对于评审器验证，通常需要约 50 个通过示例和约 50 个失败示例，才能可靠地评估 TPR/TNR。如果标注数据稀缺，请通过更有效地抽样跟踪记录来收集更多数据：

• 随机抽样： 除其他策略外，始终加入随机样本，以发现未知问题。
• 聚类： 按语义相似度对跟踪记录分组，并审核每个簇中的代表样本。
• 数据分析： 分析延迟、轮次、工具调用和令牌的统计数据，以发现异常值。
• 分类： 使用现有评估、预测模型或大模型来找出有问题的跟踪记录。请谨慎使用。
• 反馈： 使用明确的客户反馈（投诉、点踩信号）筛选跟踪记录。

如果数据不足，则发现： 小型数据集会导致失败率不可靠、置信区间过宽。使用上述抽样策略收集更多标注数据，或使用 generate-synthetic-data 补充。

6. 流程卫生

检查： 重大变更后是否会重新运行错误分析？

检查上次执行错误分析的时间，并与模型切换、提示词重写、新功能或生产事故的时间进行对比。

如果分析已过时，则发现： 流程变更后，故障模式会发生变化；为旧流程构建的评估器会漏掉新的故障类型。每次重大变更后都要重新运行错误分析。

检查： 是否持续维护评估器？

查看评审器是否会定期重新验证，或评估数据集是否会更新。

如果评估器建成后就不再维护，则发现： 随着流程演进，评估器的效果会下降。请使用新的人类标注重新验证评审器，并更新评估数据集，以反映当前用法。

没有评估基础设施

如果用户没有任何评估材料（没有跟踪记录、评估器或标注数据）：

1. 先对真实跟踪记录样本运行 error-analysis。
2. 如果没有生产数据，则使用 generate-synthetic-data 创建测试输入，将其通过流程运行，然后对生成的跟踪记录执行 error-analysis。
3. 在完成错误分析之前，不要建议构建评估器、评审器或仪表板。

报告格式

按影响从高到低呈现发现。对每项发现：

### [Problem Title]
**Status:** [Problem exists / OK / Cannot determine]
[1-2 sentence explanation of the specific problem found]
**Fix:** [Concrete action, referencing a skill or article]

按六个诊断领域分组。省略未发现问题的领域。

反模式

• 不检查实际材料，只按清单逐项执行审核。
• 报告与用户流程中的实际发现脱节的泛泛建议。
• 在完成错误分析之前就建议使用评估器。
• 对于代码检查可以处理的故障，建议使用大模型评审器。
• 将此次审核视为一次性事件。流程发生重大变更后应重新审核。