eval-audit

评估审计

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

概述

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

前提条件

可通过可观测性 MCP 服务或本地文件访问评估产物（跟踪记录、评估器配置、裁判提示词、标注数据）。如果这些都不存在，请跳至“无评估基础设施”。

连接评估基础设施

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

诊断检查

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

根据对用户产品的影响为发现排序。最具影响的发现放在最前面。

1. 错误分析

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

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

缺失时的发现： 在未进行错误分析的情况下构建评估器，只会测量泛化的质量（“有帮助性”“连贯性”），而非实际失败模式。请从 error-discovery 开始；如果不存在跟踪记录，则先运行 generate-synthetic-data。

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

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

从研究中借用的通用标签（“幻觉评分”“毒性”“连贯性”）表明类别来自头脑风暴。基于应用场景的类别（“缺少查询约束”“客户语气不当”“虚构房产特征”）则表明类别来自观察。

通过头脑风暴提出时的发现： 通用类别会遗漏应用特有的失败情况，导致评估器纸面得分不错，却漏掉实际问题。请从跟踪记录入手，使用 error-discovery 重新分析。

参见：谁来验证验证者？

2. 评估器设计

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

标记所有使用李克特量表（1-5）、字母等级（A-F）或未设定明确通过／失败阈值的数字评分的评估器。

未采用二元判定时的发现： 李克特量表难以校准。标注人员对 3 分和 4 分的区别意见不一，评审也会受到这种噪声影响。考虑使用 write-judge-prompt，通过明确的定义将评分改为二元通过／失败判定。

参见：创建能推动业务成果的 LLM 评审

检查： LLM 评审提示词是否针对具体的失败模式？

标记所有进行整体评估的提示词（例如“这个回复有帮助吗？”、“为此输出的质量评分”）。

评估过于笼统时的发现： 整体评审给出的结论无法指导行动。每个评审都应只检查一种失败模式，并提供明确的通过／失败定义和少量示例。使用 write-judge-prompt。

检查： 是否在可行时使用基于代码的检查？

标记使用 LLM 评审来检查可客观验证的标准的情况：格式验证、约束满足、关键词是否出现、是否符合架构。

过度依赖评审时的发现： 使用代码（正则表达式、解析、架构验证、执行测试）替代客观检查。仅对需要解释判断的标准使用 LLM 评审。使用 write-code-eval。

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

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

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

参见：LLM 评估常见问题

3. 评审验证

检查： 是否根据人工标签验证了 LLM 评审？

查找：混淆矩阵、TPR/TNR 测量值、对齐分数。已投入生产但没有验证数据的评审属于严重问题。

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

参见：创建能推动业务成果的 LLM 评审

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

标记将“准确率”、“一致百分比”或 Cohen's Kappa 作为主要对齐指标的情况。

使用准确率时的发现： 存在类别不平衡时，原始准确率会产生误导：当 90% 的轨迹通过时，总是判定为“通过”的评审能达到 90% 的准确率，却一个失败案例也发现不了。使用 TPR 和 TNR，它们与偏差校正直接相关。使用 validate-evaluator。

检查： 是否进行了适当的训练／开发／测试集划分？

检查评审提示词中的少量示例是否来自用于衡量评审性能的同一批数据。

数据泄漏时的发现： 将评估数据用作少量示例会夸大对齐分数，掩盖评审的真实问题。将数据划分为训练集（少量示例来源）、开发集（迭代）和测试集（最终测量）。使用 validate-evaluator。

4. 人工审核流程

检查项： 谁在审核追踪记录？

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

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

参见：提升 AI 产品实战指南

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

仅显示输出时的发现： 只审核最终输出会掩盖流水线在哪个环节出错。请展示完整追踪记录：输入、中间步骤、工具调用、检索到的上下文以及最终输出。

检查项： 向审核人员展示数据的方式如何？

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

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

参见：LLM 评估常见问题

5. 标注数据

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

对于错误分析，饱和通常需要约 100 条追踪记录。对于评判器验证，要获得可靠的 TPR/TNR，需要约 50 个 Pass 示例和约 50 个 Fail 示例。如果标注数据稀少，可通过更有效地抽样追踪记录来收集更多数据：

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

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

6. 流水线维护

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

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

分析过时时的发现： 流水线变更后，失败模式会发生变化，而针对旧流水线构建的评估器会漏掉新类型的失败。每次重大变更后都要重新运行错误分析。

检查项： 是否在维护评估器？

留意是否定期重新验证评判器，或更新评估数据集。

只设置不维护时的发现： 随着流水线演进，评估器会逐渐失效。请根据最新的人工标签重新验证评判器，并更新评估数据集以反映当前用法。

没有评估基础设施

如果用户没有任何评估产物（没有追踪记录、评估器或标注数据）：

1. 先对一批真实追踪记录运行 error-discovery。
2. 如果没有生产数据，则使用 generate-synthetic-data 创建测试输入，将其送入流水线运行，然后对生成的追踪记录运行 error-discovery。
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]

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

反模式

• 将审计当作清单逐项勾选，却不检查实际产物。
• 报告与用户流水线中的实际发现无关的泛泛建议。
• 在完成错误分析前就建议使用评估器。
• 对可通过代码检查处理的失败，建议使用大模型评判器。
• 将这项审计视为一次性工作。流水线发生重大变更后应重新审计。