Agent评测平台设计#

一、评测平台架构

数据集管理 ──→ 评测引擎 ──→ 结果分析 ──→ 发布门禁
     │              │            │            │
 版本化存储    多维度评测    统计+可视化   CI/CD集成
 标注协议      并行执行      回归检测     阻断/放行
 采样策略      成本控制      报告生成     通知告警

二、数据集版本化

数据集结构：

{
  "dataset_id": "rag-eval",
  "version": "3.2.0",
  "created_at": "2026-05-26",
  "schema_version": "1.0",
  "metadata": {
    "domain": "tech-docs",
    "annotators": ["annotator_A", "annotator_B"],
    "agreement_score": 0.85
  },
  "samples": [
    {
      "id": "q001",
      "query": "RRF 的 k 参数默认值是多少？",
      "category": "factual",
      "difficulty": "easy",
      "ground_truth": "k=60",
      "relevant_docs": ["doc_123", "doc_456"],
      "expected_tools": ["knowledge_search"],
      "metadata": {"source": "manual", "reviewed": true}
    }
  ]
}

版本管理原则：

三、标注协议与质量控制

标注流程：

原始问题 → 标注员A标注 → 标注员B交叉验证
                              ↓
                    一致 → 入库
                    不一致 → 仲裁员裁决 → 入库 + 记录分歧

一致性度量：

• Cohen’s Kappa：两人一致性（>0.6 可接受，>0.8 优秀）
• Fleiss’ Kappa：多人一致性
• 单人标注时：诚实披露偏差 + 定期抽检 + 下轮交叉验证

标注规范示例：

四、多维度评测

Agent Task Completion 评测（最难的维度）：

• 简单任务：脚本验证（如”查询后返回格式正确”）
• 复杂任务：人工判断 + 评分标准（“是否完成了用户意图”）
• 多步任务：检查每一步的工具调用序列是否合理
• 开放任务：LLM-as-Judge 评分 + 人工校准

五、发布门禁体系

代码合并 → 触发评测 Pipeline
  │
  ├─ 快速评测（5分钟）：核心 20 条 query
  │   └─ 任何指标劣化 >5% → 阻断合并
  │
  ├─ 标准评测（30分钟）：完整数据集
  │   └─ 关键指标低于 SLO → 阻断发布
  │
  └─ 完整评测（2小时）：多次运行+统计显著性
      └─ 用于版本里程碑评审

门禁规则示例：

六、回归检测

新版本评测结果 vs 基线版本评测结果
  │
  ├─ 逐 query 对比：哪些 query 变好/变差？
  │   └─ 变差的 query → 自动归类（检索劣化/生成劣化/工具调用错误）
  │
  ├─ 分类别对比：哪个 category 整体劣化？
  │   └─ factual 类劣化 → 可能是 BM25/索引问题
  │   └─ reasoning 类劣化 → 可能是 prompt/模型问题
  │
  └─ 统计显著性检验
      └─ paired t-test / bootstrap → 差异是否显著

七、现成评测框架与平台（2026-09 现状）

自建平台前先看现成工具能覆盖多少，通常是「开源框架跑评测 + 可观测平台存结果」：

八、公开 Agent 基准（做选型参考，不能替代自建评测集）

看公开基准分数要注意：Agent 分数受脚手架（harness）影响很大，厂商自报分数和第三方复现常有差距；同一基准不同版本不可比。

Agent 评测平台我设计了四个核心模块。第一是数据集版本化管理，每个数据集有版本号和 schema，新增样本是 minor 版本，修正标注是 patch 版本，保证评测可复现。标注质量通过交叉验证和 Cohen’s Kappa 一致性度量控制。第二是多维度评测引擎，不只看生成质量，还要评检索质量用 Recall 和 MRR、工具调用正确性、任务完成度和安全性。其中 Agent Task Completion 是最难评的维度，简单任务用脚本验证，复杂任务需要 LLM-as-Judge 加人工校准。第三是发布门禁，CI/CD 中集成快速评测和标准评测两级门禁，关键指标劣化超过阈值直接阻断发布。第四是回归检测，逐 query 对比新旧版本找出劣化点，按类别归因是检索问题还是生成问题，用统计检验判断差异是否显著。落地时不必全部自研：评测可以用 DeepEval、Ragas、promptfoo 这类开源框架跑，结果挂到 Langfuse 或 LangSmith 的 trace 上；公开基准像 SWE-bench Pro、τ²-bench 只做模型选型参考，而且要注意版本和污染问题，比如 OpenAI 已经不再报告 SWE-bench Verified。整个平台的核心价值是把”凭感觉调参”变成”数据驱动迭代”。

追问方向：

• “LLM-as-Judge 有什么偏差？”→ 位置偏差（偏好第一个答案）、冗长偏差（偏好更长的回答）、自我偏好（偏好自己模型的输出）；缓解方法：多次评测取均值、用不同模型交叉评、定期人工校准评分标准
• “评测成本怎么控制？”→ 快速迭代用核心子集（50-100 条代表性用例），全量评测定期跑；LLM 评分先在人工对齐集上验证小模型（各家 mini / flash / turbo 档）是否够用，够用就替代昂贵模型；缓存重复评测结果避免相同输入重复调用
• “数据集多大才够？”→ 取决于置信区间要求。通过率的 95% 置信区间半宽约 1.96×√(p(1−p)/n)：通过率 0.8 时，50 条约 ±0.11（只够粗筛），200 条约 ±0.055，要到 ±0.03 需要约 700 条。比较两个版本时用同一批样本做配对检验（逐 query 对比），比单纯堆数量更有效
• “怎么处理非确定性？”→ 同一 query 多次运行（3-5 次）取中位数或均值消除随机波动；设置 temperature=0 减少采样随机性；评测报告附带置信区间而非单一数字

易错点：

• ❌ “单次评测就能下结论”——必须多次运行+统计检验
• ❌ “只评最终答案”——Agent 需要评工具调用序列和中间步骤
• ❌ “人工标注一定准确”——需要一致性度量和仲裁机制
• ✅ 核心思路：可复现(版本化)+多维度(不只看准确率)+自动化(CI门禁)+可归因(回归分析)