Back to Index
工程与生产 /

Eval Harness 实战：从工具到自建评估体系

用漏斗式视角理解 Eval Harness：工具选型、lm-eval 与 promptfoo 实战、自建四支柱、Flaky Eval 处理，以及与 Agent Harness 的关系。

6 min read Part of AI Engineering · Ch. 9

Eval Harness 实战：从工具到自建评估体系

一句话先说透：模型是引擎，Eval Harness 是底盘 + 安全带系统。没有它，车能跑；但不稳、不安全，也很难规模化。

你会拿到什么

这篇只做一件事：把“评估”从概念变成可落地工程。

读完你可以直接开始三件事：

  • 选一条适合你的 Eval Harness 工具链；
  • 跑通一条最小可用评估流水线；
  • 把评估接进 CI/CD，并知道怎么处理 Flaky Eval。

0) 先把边界说清：Eval Harness 解决什么，不解决什么

Eval Harness 能解决：

  • 把数据集、执行器、指标、报告绑定成可重复执行流程；
  • 让新版本和 Baseline 可对比；
  • 把评估纳入 PR / Nightly / Release 门禁。

Eval Harness 不能自动解决：

  • 你的数据集是否代表真实用户分布；
  • 你的 Rubric 是否真的对齐业务目标；
  • 你的阈值是否合理；
  • 你的 Judge 是否有系统偏差。

所以要记住：

Eval Harness 是“执行系统”，不是“价值判断系统”。

1) 工具全景 + 选型指南

1.1 主流工具对比（统一列风格）

工具适用场景优势注意事项
lm-evaluation-harness学术基准、开源模型横向评测任务生态成熟，复现性强，社区共识高。- 偏研究语境。
- 业务任务要自定义。
promptfooPrompt 回归、多模型 A/B、产品迭代YAML 声明式配置，接 CI 成本低，上手快。- 非学术榜单主战场。
- 需自建业务数据集。
OpenAI EvalsOpenAI 生态内评估与协作评估模板规范，社区协作友好。- 更贴合 OpenAI 工作流。
DeepEvalPython 测试栈内 LLM 评估与 pytest 风格贴合，工程团队易接入。- 需维护测试结构与依赖。
Braintrust团队级实验与评估运营协作、追踪、看板能力完善。- 需评估商业成本。
RAGASRAG 指标化评估对 Faithfulness/Context 指标支持好。- Judge 成本与方差需要治理。

1.2 选型决策树（Mermaid）

flowchart LR
  A[测试集] --> B[执行器]
  B --> C[指标 / Judge]
  C --> D[结果存储]
  D --> E[报表与分析]
  E --> F{通过门禁?}
  F -->|是| G[合并 / 发布]
  F -->|否| H[修复后重跑]
  H --> A

2) 两个实战深度：lm-eval 与 promptfoo

2.1 lm-evaluation-harness：适合“标准化对比”

pip install lm-eval

lm_eval --model hf \
  --model_args pretrained=your-hf-model \
  --tasks arc_easy,hellaswag \
  --batch_size auto

实战建议：

  • 先 --limit 10 做 dry-run，再全量；
  • 明确记录模板、停止符、采样参数；
  • 仅在“同配置”前提下做分数对比。

2.2 promptfoo：适合“产品迭代回归”

description: "客服意图回归"

prompts:
  - file://prompts/intent_v1.txt
  - file://prompts/intent_v2.txt

providers:
  - openai:gpt-4.1-mini
  - openai:gpt-4.1

tests:
  - vars:
      query: "我要退款，订单号 12345"
    assert:
      - type: contains-json
      - type: javascript
        value: output.intent === 'refund'
  - vars:
      query: "随便聊聊"
    assert:
      - type: llm-rubric
        value: "回答应礼貌，不越权承诺"
npx promptfoo@latest eval -c promptfooconfig.yaml --ci

实战链接：

3) 自建 Eval Harness 工程指南（四支柱 + Golden Set + CI/CD）

3.1 先看总架构（Mermaid）

flowchart LR
  A[Test Set] --> B[Executor]
  B --> C[Metrics / Judge]
  C --> D[Storage]
  D --> E[Dashboard]
  E --> F[Review & Error Analysis]
  F --> A

3.2 四支柱按“搭建顺序”来

  1. Test Set（先有样本）

    • 冒烟集（10~30）
    • 回归集（200~2000）
    • 压力集（边界、长输入、多语）

  2. Evaluator（再定义通过标准）

    • 结构化优先规则校验
    • 文本类再上 LLM Judge
    • 关键桶必须有硬阈值

  3. Storage（再做可追溯）

    • 必备字段：run_id / git_sha / prompt_version / model_id / dataset_version / judge_version / metrics

  4. Visualization（最后做决策视图）

    • 总分趋势
    • 业务桶分数
    • Baseline diff

3.3 Pipeline 迭代流程（Mermaid）

flowchart TD
  A[需求变更 / Prompt变更 / 模型升级] --> B[选择评估集]
  B --> C[执行 Eval Harness]
  C --> D{是否通过门禁?}
  D -->|通过| E[合并/发布]
  D -->|不通过| F[定位失败样本]
  F --> G[改 Prompt/路由/检索/模型]
  G --> C

3.4 Golden Set：把评估变成“活资产”

  • 来源：真实日志分层抽样，不只“好做题”；
  • 标注：双人交叉 + adjudication；
  • 版本：数据集版本必须和 Prompt/模型版本绑定；
  • 演进：每月补充新失败样本，淘汰失效样本。

3.5 CI/CD 门禁建议

  • PR：只跑冒烟 + 关键桶；
  • Nightly：跑全量 Golden + 多模型；
  • Release：必须过硬门禁。

门禁伪代码：

if overall < baseline - delta: fail_or_warn()
if any(critical_bucket < threshold): fail()

4) 常见坑 + Flaky Eval 处理

4.1 “81 -> 83，但退款桶 92 -> 71” 怎么看？

版本OverallRefundChitchat结论
Baseline819275基线可用
New837190总分升了，但关键业务回归，不能上线

原则：总分看趋势，关键桶做门禁。

4.2 Flaky Eval 来源-表现-缓解（工程版）

来源典型表现缓解策略
采样参数未锁同输入输出波动锁定 temperature/top_p/max_tokens
Judge 漂移分数整体平移锁定 judge 版本，升级时双跑
外部检索变化RAG 分数忽高忽低固定检索快照，缓存 top-k 结果
样本过小单条样本影响过大扩样 + 按桶观察 + 置信区间

5) RAG 专项补充：2026 生产权衡（含多模态）

RAG 评估要同时覆盖两层：

  • 检索层：找没找对（Context Precision/Recall）；
  • 生成层：是否忠于上下文（Faithfulness）。

2026 常见权衡：

  • 多模态 RAG（图文/视频）更强，但标注与评估成本更高；
  • LLM Judge 更灵活，但波动和成本也更高；
  • 高风险场景优先“规则 + 人审 + 小流量灰度”。

建议组合：

  • RAGAS 指标 + 传统任务指标（EM/F1）+ 在线业务指标（转化、停留、投诉率）。

6) Eval Harness vs Agent Harness：关系与边界

6.1 结论先行

Eval Harness 是 Agent Harness 的子集与基础。

Eval Harness 关注“输出质量”；Agent Harness 还要治理“过程可靠性”。

6.2 三层演进：Prompt -> Context -> Harness

阶段关注点典型问题对应治理
Prompt Engineering说得清不清楚文案改一版就漂移Prompt 回归测试
Context Engineering给的数据对不对检索噪声、记忆污染RAG/记忆评估
Harness Engineering系统稳不稳定多步骤失败、工具调用风险、状态漂移Eval Harness + Agent Harness

6.3 Agent Harness 比 Eval Harness 多管什么

  • 工具调用成功率与重试策略；
  • 多步骤计划执行稳定性；
  • 状态一致性（记忆/会话/外部系统）；
  • 人在回路（审批、降级、熔断）；
  • 审计与可追责链路。

这也是为什么你在 To-Do 里把 Harness Engineering 放核心位置：它不是“多一层评估”，而是“把 Agent 拉到生产可靠区间”的总工程。

结语

如果你现在只能做一件事：

  • 先把 Eval Harness 跑通并接进 CI；
  • 再逐步扩展到 Agent Harness 的过程治理。

这条路线最稳，也最符合真实团队节奏。

最后更新

  • Last Updated: 2026-04-02

修订记录

  • v2 (2026-04-02)
    • 重构为漏斗式结构；
    • 新增 Agent Harness 对比与 Prompt->Context->Harness 演进表；
    • 新增 3 个 Mermaid 图（总架构、选型决策树、Pipeline 流程）；
    • 新增 Flaky Eval 工程表与“总分提升但关键桶回归”示例表；
    • 统一术语为 Eval Harness，精简长句与重复表述。
  • v1
    • 初版发布。