用途
eval-audit 用于检查 LLM 评估流水线，并产出一份按影响程度排序的问题清单，每个问题都关联具体的修复动作。它适合在接手一个评估系统、或需要排查评估流水线中潜在问题时使用。
主要能力
该技能会收集评估产物，包括 traces、评估器配置、judge 提示词、标注数据和指标看板，然后围绕六个方面执行诊断检查：
- 错误分析：检查是否对真实或合成 traces 做过系统性错误分析，以及失败类别是头脑风暴得出还是通过观察得出。若评估器存在但没有记录失败类别，则很可能跳过了错误分析。
- 评估器设计：检查评估器是否采用二值通过/失败；LLM judge 提示词是否针对特定失败模式；是否在可能的情况下使用基于代码的检查；是否将相似度指标作为主要评估手段。
- Judge 验证：检查 LLM judge 是否用人工标签验证；对齐度是否用 TPR/TNR 而非原始准确率衡量；是否有正确的训练/开发/测试划分。
- 人工审核流程：检查谁在审核 traces；审核者看到的是完整 traces 还是仅最终输出；数据以何种格式展示给审核者。
- 标注数据：检查标注数据是否充足。错误分析大致需要约 100 条 traces 达到饱和，judge 验证需要约 50 个 Pass 和约 50 个 Fail 示例。采样策略包括随机、聚类、数据分析、分类、反馈。
- 流水线卫生：检查重大变更后是否重新运行错误分析；评估器是否得到维护。
使用方式
检查用户是否连接了 observability MCP server（如 Phoenix、Braintrust、LangSmith、Truesight 或类似工具）。如果可用，使用它拉取 traces、评估器定义和实验结果。如果没有，则请求本地文件：CSV、JSON trace 导出、notebook 或评估脚本。
随后逐项执行上述诊断检查，检查可用产物，判断问题是否存在，记录发现。按对用户产品的影响程度排序，影响最大的优先呈现。
适用场景
适用于继承评估系统、审计现有 LLM 评估流水线、排查评估设计缺陷等场景。
限制
如果用户没有任何评估产物（没有 traces、没有评估器、没有标注数据），应先从真实 traces 样本开始错误发现。如果没有生产数据，使用 generate-synthetic-data 创建测试输入，运行后再对产生的 traces 应用错误发现。不要在错误分析完成前推荐构建评估器、judge 或看板。反模式包括：不检查实际产物而将审计当作清单运行；报告与实际发现脱节的通用建议；在错误分析完成前推荐评估器；对代码检查能处理的失败建议使用 LLM judge；将本次审计视为一次性事件。