第7章：自建领域 Benchmark

公开 benchmark 是”行业标准考试”,自建 benchmark 是”你公司的内招面试”——前者通用,后者才能反映你业务真正需要的能力。本章给一份完整的 5 步法,带你为客服 / 代码 / 搜索三类业务设计领域 benchmark,讲清防老化、防 hacking、隐私合规、跨团队 leaderboard 的工程模式。读完这章,你能为团队建立一个”持续养护”的领域评测体系。

📑 目录

1. 为什么公开 benchmark 不够
2. 自建 Benchmark 5 步法
3. 防老化:每季度 refresh
4. 防 reward hacking:对抗思维
5. 隐私 / 合规
6. 三类业务的实战设计
7. 跨团队 leaderboard
自我检验清单
参考资料

1. 为什么公开 benchmark 不够

1.1 三个根本问题

问题	说明
Domain mismatch	客服 agent 跑 GAIA,得分高也不代表客服好
Contamination	模型训练时见过 benchmark 题,分数虚高
Reward hacking 风险	UC Berkeley 大事件证明公开 benchmark 不可信

1.2 自建 benchmark 的三大价值

✅ 业务对齐:测的就是你业务真正需要的能力 ✅ 不会被 contamination(私有数据) ✅ 持续演进:跟你业务一起长

🌟 生产 agent 团队的共识:至少 50% 的 eval 资源投在自建 benchmark——公开 benchmark 跑跑就行,主战场是自家。

2. 自建 Benchmark 5 步法

2.1 Step 1:收集真实样本

来源:

来源	备注
生产对话 log	必须脱敏 / 合规审核
客服工单系统	真实业务问题
用户调研	主动收集 edge case
客户经理标注	业务专家主导
Synthetic data	LLM 生成补充(注意防 collapse)

目标:200-2000 条真实样本,覆盖业务主要场景 + 长尾。

2.2 Step 2:设计评测维度

用模块八第 2 章的 5 维框架:

维度	你业务的具体定义
Capability	业务任务做对没?
Reliability	同题反复跑稳吗?
Safety	有没有违反业务规则?
Cost	平均 $/任务
Latency	E2E P95

每条 benchmark 题应该至少测 2-3 个维度(不只 capability)。

2.3 Step 3:制定评分标准

按任务类型选合适 verifier:

任务	评分
答案唯一(EM)	rule-based verifier
答案多种正确	reference-based + LLM Judge
开放回答	LLM Judge 多 verifier 投票
Tool 调用对错	检查 final state
Agent 行为	trajectory 整体 LLM Judge

🍎 铁律(模块七、八多次强调):verifier 自己应该 ≥ 99% 准确率,否则评测噪声 > 真实 improvement。

2.4 Step 4:持续维护

每周:从生产 log 抽 5-10 条新 case 加入
每月:人工 spot check 模型在 benchmark 上的失败 case
每季度:删过期 / 不再有代表性的题,加新题

Benchmark 不是一次性产物,是持续养护的 living thing。

2.5 Step 5:CI 自动化

把 benchmark 集成到 CI(下章详):

# .github/workflows/eval.yml
on: pull_request
jobs:
  custom_benchmark:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          pip install -r eval/requirements.txt
          python eval/run_custom_benchmark.py
      - if: ${{ failure() }}
        run: echo "Custom benchmark regression > 5%, blocking PR"

3. 防老化:每季度 refresh

3.1 老化的表现

Q1: 模型 acc 65%
Q2: 模型 acc 75%(改了 prompt,看起来进步)
Q3: 模型 acc 85%(实际生产投诉率上升)

Benchmark 老化时,模型在 benchmark 上的进步不再反映真实业务。

3.2 三种 refresh 策略

策略	说明
Rolling refresh	每季度淘汰 20% 老题,加 20% 新题
Holdout split	70% 公开训练 + 30% 隐藏 holdout
Versioning	benchmark v1, v2, v3 各自存在,跟踪长期演进

3.3 标志:什么时候必须 refresh

多个模型在 benchmark 上 saturated(都接近满分)
业务场景有重大变化(新产品 / 新用户群)
发现某些题被 hack
距上次 refresh 超 6 个月

4. 防 reward hacking:对抗思维

4.1 设计时就考虑”会被怎么 hack”

每写一道 benchmark 题,问自己:

□ verifier 只看输出末尾吗?
□ 关键词匹配能被绕过吗?
□ 中间步骤评分了吗?
□ 多个 verifier 交叉验证吗?
□ 题目里是否有"暗示答案"的 metadata 模型可读到?

4.2 加入对抗 verifier

HACK_PATTERNS_FOR_THIS_BENCHMARK = [
    # 客服 benchmark 特定:不能直接复述用户问题
    re.compile(r"^.{0,100}\b" + re.escape(user_question[:50]) + r"\b"),
    # 不能简单转人工
    re.compile(r"已为您转接人工|稍等"),
    # 不能避而不答
    re.compile(r"我不太确定|建议您"),
]

def hack_score(response, user_question):
    return sum(p.search(response) is not None for p in HACK_PATTERNS_FOR_THIS_BENCHMARK)

# benchmark reward
final_score = capability_score - 0.2 * hack_score(response, user_question)

4.3 多版本 verifier

同一道题,设计多个独立 verifier:

verifier_a: 字符串匹配
verifier_b: LLM Judge
verifier_c: 业务规则 check(从订单系统拿真实状态)

通过 = 至少 2/3 verifier 同意

4.4 EvilGenie 风格 trap

故意在 benchmark 中埋一些”诱饵 hack 路径”——看模型会不会咬钩:

benchmark 设计:
  题 1-20 是正常题
  题 21-25 设计成"verifier 只看末尾数字,但解法应该思考"
  
如果模型在题 21-25 acc 高于题 1-20 → 有 hack 倾向

5. 隐私 / 合规

5.1 PII 处理

import presidio_analyzer
import presidio_anonymizer

def anonymize_for_benchmark(text):
    analyzer = presidio_analyzer.AnalyzerEngine()
    results = analyzer.analyze(
        text=text,
        entities=["PHONE_NUMBER", "EMAIL_ADDRESS", "PERSON", "CREDIT_CARD"],
        language="en",
    )
    anonymizer = presidio_anonymizer.AnonymizerEngine()
    return anonymizer.anonymize(text, results).text

所有从生产抽的 benchmark 数据必须过 PII detector。

5.2 合成数据替代

PII 重的场景,直接用 LLM 合成 benchmark 数据:

prompt = """
生成 10 个客服对话场景,涵盖:
- 退款问题
- 物流查询
- 商品咨询
不要使用真实姓名、电话、身份证号——使用明显的假数据(如"张三"、"13800000000")。

输出 JSON 格式。
"""
synthetic_cases = llm.generate(prompt, n=20)

但要警惕模块七第 7 章讲的 synthetic data collapse——保留 10-30% 真实(脱敏)数据混合。

5.3 数据驻留

跨境业务:EU 用户数据只能用 EU 区域模型评 benchmark。否则 GDPR 风险。

5.4 Benchmark 数据访问控制

角色	访问级别
Eval team	全权
Engineer(写 agent 的)	只能看分数,不能看具体题(防止”针对 benchmark 调 prompt”)
Product manager	看 dashboard 摘要
外部 audit	经审批的子集

6. 三类业务的实战设计

6.1 客服 Agent benchmark

benchmark: customer_service_v3
size: 500 cases
dimensions:
  - capability: 0.5    # 答案是否正确
  - reliability: 0.2   # pass^3 是否稳
  - safety: 0.2        # 是否违反 SOP
  - cost: 0.05         # token / 工具调用
  - latency: 0.05

cases:
  - id: cs_001
    type: refund_inquiry
    user_msg: "..."
    user_history: [...]   # 上下文
    expected_actions: ["check_order", "process_refund"]
    expected_response_traits: ["empathetic", "concise"]
    forbidden_actions: ["transfer_human"]   # 不能转人工
    sla:
      ttft: 1000  # ms
      e2e: 30     # s
    # 多 verifier
    verifiers:
      - rule_based: action_match
      - llm_judge: response_quality_rubric
      - business_rule: respects_sla

6.2 Code Agent benchmark

benchmark: code_agent_v2
size: 200 problems
based_on: real PRs from internal repos(脱敏)
dimensions:
  capability:
    - patch_applies: 0.3
    - tests_pass: 0.5
    - no_test_modification: 0.2  # 反 hack:不能改 test
  reliability:
    - pass^3: ...
  cost: $/PR
verifiers:
  - sandbox_pytest
  - lint_check
  - test_file_diff_check  # 检测 test 被修改

6.3 Search Agent benchmark

benchmark: search_agent_v1
size: 300 multi-hop queries
domain: 公司内部知识库
dimensions:
  capability:
    - answer_em: 0.6
    - cited_correct_doc: 0.3   # 引用对吗
    - hallucination_free: 0.1
  cost: tool_calls
verifiers:
  - exact_match_with_normalize
  - doc_id_match
  - llm_judge_grounding

7. 跨团队 leaderboard

7.1 内部 leaderboard 价值

Team A: agent v1.0  → benchmark 65%
Team A: agent v1.1  → benchmark 68%(+3%)
Team B: agent baseline → benchmark 58%
Team B: agent v2 → benchmark 72%(超越 A)

→ 良性竞争,共享 best practices

7.2 实现

# 用 Wandb 或自建 leaderboard
wandb.log({
    "team": "agent_team_a",
    "version": "v1.1",
    "benchmark_score": 0.68,
    "capability": 0.72,
    "reliability_pass3": 0.55,
    "cost_per_task": 0.18,
    "commit_sha": "abc123",
})

7.3 注意

多团队共享 benchmark 必须严格控制访问(只看分数)
定期人工抽审高分 trajectory 找 hack
排行榜不是唯一衡量——业务 KPI 仍是终极

🍎 leaderboard 是工具,不是目的。

✅ 自我检验清单

📚 参考资料

综述与方法论

Beyond Accuracy: Multi-Dimensional Framework:arXiv 2511.14136
Designing Benchmarks for Eval(Berkeley RDI 系列):博文

工具

Microsoft Presidio(PII detection):github.com/microsoft/presidio
Anthropic AI Safety Levels:对抗 benchmark 设计参考
Synthetic Data Generation:多个论文(模块七第 7 章)

工业实践

Anthropic Internal Eval Process:Anthropic 公开过部分 eval 实践
OpenAI Production Eval:OpenAI 各种 release post 中提到的方法