LM Evaluation Harness 实操指南:安装、跑分、自定义任务到 Agent 回归评测
这篇从命令级实操出发,讲清 LM Evaluation Harness 如何安装、运行标准 benchmark、编写 YAML 自定义任务、解析结果,并把模型评测接到 Prompt、RAG 和 Agent 回归流水线。
核心结论
LM Evaluation Harness 先解决模型层可复现跑分:同一批任务、同一套 prompt、同一套指标,才能比较模型版本和参数变化。
业务 Agent 评测不能只看 benchmark 分数,必须额外记录工具调用正确率、任务完成率、危险动作拦截率和人工接管率。
自定义 YAML task 是把内部业务样本接进 Harness 的关键入口;不做自定义任务,企业只能得到公开榜单参考。
上线前建议形成端到端流水线:模型 benchmark -> Prompt 回归 -> RAG 检索评测 -> Agent 沙箱任务 -> CI 周期回归。
所有量化阈值都应从业务风险倒推,不要照搬公开榜单;高风险场景宁可慢一点,也要保留证据、日志和人工确认。
实操代码与命令
1. 本地安装与确认 CLI
bashpython -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install "lm_eval[hf]"
lm-eval --help
lm-eval ls tasks | head官方 README 说明基础框架和不同模型后端通过 extras 安装;CLI 文档说明新版入口包含 run、ls、validate 三类子命令。
2. 跑一个 0-shot/5-shot 标准任务
bashlm-eval run \
--model hf \
--model_args pretrained=EleutherAI/pythia-160m,dtype=float32 \
--tasks hellaswag,arc_easy \
--num_fewshot 0 \
--batch_size 8 \
--device cuda:0 \
--output_path ./runs/pythia-160m-zeroshot \
--log_samples
lm-eval run \
--model hf \
--model_args pretrained=EleutherAI/pythia-160m,dtype=float32 \
--tasks hellaswag \
--num_fewshot 5 \
--batch_size auto \
--device cuda:0 \
--output_path ./runs/pythia-160m-5shotfew-shot 的意义是把少量示例拼进提示词,观察模型是否能从示例中学习任务格式。生产评测应固定 num_fewshot、模型版本和随机种子。
3. vLLM/多 GPU 加速运行
bashpip install "lm_eval[vllm]"
lm-eval run \
--model vllm \
--model_args pretrained=Qwen/Qwen2.5-7B-Instruct,tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.85 \
--tasks mmlu,arc_challenge \
--num_fewshot 5 \
--batch_size auto \
--output_path ./runs/qwen25-7b-vllm
accelerate launch -m lm_eval run \
--model hf \
--model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16,parallelize=True \
--tasks mmlu \
--num_fewshot 5 \
--batch_size 4 \
--output_path ./runs/qwen25-7b-accelerate大模型评测通常受显存和吞吐限制。vLLM 适合高吞吐推理,accelerate 适合把 HF 模型分发到多卡。
4. 自定义中文业务 Task YAML 示例
yamltask: internal_zh_rag_refusal
include: default.yaml
dataset_path: json
dataset_kwargs:
data_files:
validation: ./data/internal_zh_rag_refusal.jsonl
validation_split: validation
output_type: generate_until
doc_to_text: |
你是企业知识库助手。请只依据给定资料回答;资料不足时回答“无法从资料确认”。
资料:{{context}}
问题:{{question}}
答案:
doc_to_target: "{{answer}}"
generation_kwargs:
until:
- "\n"
max_gen_toks: 128
metric_list:
- metric: exact_match
aggregation: mean
higher_is_better: true
metadata:
version: 1.0
description: 中文知识库拒答与来源一致性回归集官方 New Task Guide 和 Task Configuration 文档推荐用 YAML 定义任务、数据集、prompt、输出类型和指标。
5. 校验并运行自定义 Task
bashmkdir -p custom_tasks/internal_zh_rag_refusal
cp internal_zh_rag_refusal.yaml custom_tasks/internal_zh_rag_refusal/default.yaml
lm-eval validate \
--tasks internal_zh_rag_refusal \
--include_path ./custom_tasks
lm-eval run \
--model hf \
--model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \
--tasks internal_zh_rag_refusal \
--include_path ./custom_tasks \
--num_fewshot 0 \
--batch_size 4 \
--output_path ./runs/internal-rag-regression \
--log_samplesvalidate 会提前检查 task、配置语法、数据访问、metric 和模板渲染,比直接跑大批量任务更省时间。
6. 解析结果并设置回归门禁
pythonimport json
from pathlib import Path
result_file = next(Path("runs/internal-rag-regression").rglob("results*.json"))
report = json.loads(result_file.read_text(encoding="utf-8"))
results = report["results"]
gates = {"internal_zh_rag_refusal": {"exact_match": 0.82}}
failed = []
for task, metrics in gates.items():
actual = results[task]
for metric, minimum in metrics.items():
value = actual.get(metric)
if value is None or value < minimum:
failed.append(f"{task}.{metric}={value}, expected >= {minimum}")
if failed:
raise SystemExit("Evaluation gate failed:\n" + "\n".join(failed))
print("Evaluation gate passed")阈值示例不是通用标准。客服知识库、代码 Agent、金融风控和内部办公助手应分别设置不同门禁。
7. GitHub Actions 周期回归示例
yamlname: llm-eval-regression
on:
workflow_dispatch:
schedule:
- cron: "0 18 * * 1"
jobs:
eval:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- run: pip install "lm_eval[hf]"
- run: |
lm-eval validate --tasks internal_zh_rag_refusal --include_path ./custom_tasks
lm-eval run --model hf --model_args pretrained=\${{ vars.EVAL_MODEL }} --tasks internal_zh_rag_refusal --include_path ./custom_tasks --output_path ./runs/latest --log_samples
python scripts/check_eval_gate.py
- uses: actions/upload-artifact@v4
with:
name: lm-eval-report
path: runs/latest建议使用自托管 runner 或隔离评测机,避免把内部样本、模型权重和日志暴露到不受控环境。
端到端评测流水线:从模型跑分到 Agent 回归
用 LM Evaluation Harness 跑公开任务和内部 YAML task,固定模型版本、后端、num_fewshot、batch_size、commit hash 和输出目录。
用 promptfoo 或自建脚本比较 system prompt、few-shot 示例、输出格式约束和拒答策略,记录格式错误率与成本。
用 Ragas 或人工标注集评估召回命中率、引用准确率、无答案拒答率、过期资料识别率和幻觉率。
让 Agent 在沙箱里调用浏览器、代码、数据库或业务 API,记录工具选择、参数、失败重试、越权拦截和执行日志。
用真实业务任务评估最终完成率、人工接管率、平均耗时、可回放性和错误恢复成本。
把阈值门禁接入 CI/CD;高风险任务必须有人工审批、日志留存、脱敏和回滚方案。
真实场景案例
案例一:中文知识库模型升级前的量化回归
客服知识库准备从旧模型切到新模型。团队担心新模型回答更流畅,但来源引用变差,或者对无答案问题开始编造。
- 1从历史工单抽取 300 条中文问题:180 条单文档有答案、70 条跨文档综合、50 条无答案拒答。
- 2先用 LM Evaluation Harness 自定义 YAML task 跑模型层回答格式和准确率,固定 0-shot 与 3-shot 两套配置。
- 3再接 RAG 流程,统计 top-3 召回命中率、引用准确率、拒答率和幻觉率。
- 4把失败样本写入下周回归集,避免只修当前 prompt。
示例门禁可设为:有答案准确率 >= 82%,无答案拒答率 >= 90%,引用准确率 >= 88%,幻觉率 <= 5%,单问平均成本不超过旧模型 1.3 倍。未达标模型只能进入内部灰度,不进入正式客服。
- 这些阈值是示例,必须按业务风险调整。
- 不要用英文公开 benchmark 替代中文客服样本。
- 必须保存 sample 日志,方便定位是检索失败还是模型生成失败。
案例二:编程 Agent 允许创建 PR 前的沙箱评测
研发负责人想判断是否允许 Agent 在仓库里创建修复 PR,但担心它误改权限、删除测试或引入隐蔽副作用。
- 1选取 80 个历史任务:50 个小 bug、20 个测试补齐、10 个文档更新;每个任务提供 issue、预期测试和禁止修改目录。
- 2模型层先用 Harness 跑代码理解与格式遵循任务,排除明显不稳定模型。
- 3Agent 层在隔离分支执行,记录 diff、命令、测试输出、失败日志和人工审批意见。
- 4人工把结果标注为可合并、需小改、错误方案、危险操作四类。
示例门禁可设为:任务完成率 >= 65%,危险操作拦截率 100%,自动测试通过率 >= 80%,人工接管率 <= 35%,禁止目录改动为 0。达不到门禁时,只允许建议模式,不允许自动 PR。
- 测试通过不代表方案正确,还要看 diff 是否扩大影响面。
- 有写权限的 Agent 必须保留最小权限、隔离分支和人工 review。
案例三:多模态 Agent 的评测扩展
团队要评估能读截图、网页和 PDF 的研究 Agent,普通文本 benchmark 无法覆盖视觉理解和页面操作。
- 1准备 100 个截图/PDF/网页任务,标注目标字段、允许来源和禁止推断项。
- 2文本模型层继续用 Harness 跑基础推理和格式输出,筛掉弱模型。
- 3多模态层用独立脚本记录图片理解准确率、页面定位成功率、引用来源命中率和人工修正次数。
- 4把最终结果写回统一报告,和文本 Harness 结果一起作为选型依据。
多模态 Agent 不能只看最终报告是否像样。更关键的是字段抽取准确率、页面定位成功率、来源可追溯率和不可确认信息拒答率。
- 图片/PDF 样本要覆盖低清晰度、表格、截图遮挡和中文页面。
- 不要把文本 benchmark 高分误认为视觉任务可靠。
对比判断表
| 评测对象 | 推荐工具/方法 | 核心量化指标 | 示例门禁 | 常见误判 |
|---|---|---|---|---|
| 基础模型 | LM Evaluation Harness、Hugging Face Evaluate | accuracy、exact_match、perplexity、格式遵循率 | 核心任务相对旧模型不下降超过 2 个百分点 | 公开榜单高不代表中文业务好 |
| Prompt | promptfoo、自建断言 | 格式错误率、拒答合规率、成本、延迟 | 格式错误率 <= 3%,拒答策略通过率 >= 95% | 只测成功样本,不测边界样本 |
| RAG | Ragas、人工标注、检索日志 | top-k 召回、引用准确率、幻觉率、无答案拒答率 | 幻觉率 <= 5%,无答案拒答率 >= 90% | 把模型错误和检索错误混在一起 |
| 工具调用 | 沙箱任务、日志回放 | 工具选择正确率、参数正确率、重试成功率、越权拦截 | 危险动作拦截率 100% | 只看最终答案,不看过程 |
| Agent 任务 | 真实任务集、人工标注、CI 回归 | 任务完成率、人工接管率、平均耗时、可回放率 | 低风险任务完成率 >= 70%,可回放率 100% | 把 demo 成功当成生产可用 |
| 安全对抗 | 红队样本、越权测试、提示注入测试 | 敏感信息泄露率、越权执行率、注入成功率 | 高风险操作 0 自动执行 | 只测正常路径,不测攻击路径 |
落地检查清单
先给结论:Harness 不是榜单工具,而是可复现评测底座
LM Evaluation Harness 的价值不是给模型贴一个绝对排名,而是把任务、prompt、模型后端、评分规则和输出日志标准化。官方 README 将其定位为 few-shot language model evaluation framework,并说明它支持多种后端和大量 benchmark;这意味着它最适合做模型层的可复现实验,而不是直接宣称某个 Agent 能上线。引用:EleutherAI LM Evaluation Harness README。
新版 CLI 文档把入口拆成 lm-eval run、lm-eval ls、lm-eval validate。实际使用时,建议先 ls tasks 确认任务名,再 validate 自定义任务,最后 run 完整评测。这样比直接跑长任务更稳。引用:LM Evaluation Harness CLI Interface。
企业落地时要把 Harness 放在第一层:先比较基础模型,再测试 prompt,再评估 RAG,最后进入 Agent 沙箱任务。否则很容易把模型能力、检索质量、工具权限和业务流程混为一谈。
底层机制:统一 Prompt、统一请求、统一评分
Harness 的核心流程可以拆成五步:读取 task 配置和数据集,把每条样本渲染成 prompt,通过统一模型接口生成或计算 loglikelihood,再把输出交给 metric/aggregation,最后写入任务级结果和样本级日志。这样同一套任务能在不同模型后端上重复运行。
few-shot 评测不是简单多问几次,而是把示例拼进上下文,让模型在看到少量输入输出格式后回答目标样本。num_fewshot 改变后,prompt 长度、成本和分数都可能变化,所以报告必须记录该参数。
模型兼容依赖抽象接口。官方 Model Guide 说明自定义模型需要实现 LM 接口中的 loglikelihood、loglikelihood_rolling、generate_until 等方法;这也是 Harness 能支持 HF、vLLM、API 和自定义后端的原因。引用:LM Evaluation Harness Model Guide。
自定义 Task:企业内部评测的关键步骤
如果只跑公开任务,结论最多说明模型在公开 benchmark 上怎样。企业要评估中文客服、知识库、代码规范、合规问答,就必须把内部样本做成 task。官方 New Task Guide 说明 v0.4.0 之后可通过 YAML 定义 task,并用 --include_path 引入外部任务目录。引用:LM Evaluation Harness New Task Guide。
YAML 任务至少要明确 task 名称、dataset_path、split、doc_to_text、doc_to_target、output_type 和 metric_list。Task Configuration 文档列出 dataset_path、dataset_name、dataset_kwargs、doc_to_text、doc_to_target、metric_list 等字段,并说明可以用 !function 接入 Python 函数处理更复杂逻辑。引用:LM Evaluation Harness Task Configuration。
对中文业务任务,不建议一开始追求复杂指标。第一版可用 exact_match、f1、人工评分或规则断言跑通流程;等错误样本积累后,再引入 LLM-as-judge、语义相似度或更细的业务指标。
结果怎么看:不要只看平均分,要看样本级失败
平均 accuracy 只能说明整体趋势,不能说明为什么失败。正式评测必须打开 --log_samples,保留输入、模型输出、目标答案、metric 和元数据。只有看样本级日志,才能区分模型不会、prompt 误导、数据脏、检索失败还是评分规则不合适。
置信区间和显著性也不能忽略。对于 50 条以内的小样本,1 到 2 条样本变化就能让分数明显波动;对内部核心回归集,建议至少保留 200 条以上样本,并按题型分层统计。
量化边界要和业务风险绑定:知识库可把无答案拒答率设为硬指标,编程 Agent 把危险操作拦截率设为硬指标,客服场景把敏感信息泄露率设为硬指标。
前沿扩展:LLM-as-judge、CI/CD、多模态和安全对抗
LLM-as-judge 适合开放问答、摘要质量、解释完整性等难以 exact match 的场景,但 judge 模型也会偏置。建议把 judge 分数、人工抽检和规则指标组合使用,不要让另一个模型成为唯一裁判。
CI/CD 集成的重点不是每次跑全量榜单,而是跑核心回归集。模型、prompt、检索策略或工具权限变化时,必须跑一轮门禁;大规模 benchmark 可以每周定时运行并归档报告。
多模态 Agent、安全对抗和分布式大规模评测需要额外框架。Harness 可以承担文本模型层评测,但截图理解、网页操作、工具越权、提示注入和红队样本需要单独任务执行器和审计日志。
适用人群:谁应该读到什么程度
企业 AI 产品经理和 Agent 项目负责人,应重点理解分层评测、量化门禁和上线风险;不需要亲自写每个 YAML,但必须知道哪些指标能决定是否放量。
RAG、智能体和业务算法工程师,应重点掌握自定义 task、样本日志、阈值门禁和 CI 回归,把评测从一次性试验变成持续工程流程。
学术研究者和 benchmark 调优工程师,需要继续阅读官方 task guide、model guide 和具体 task 实现。本文提供工程入口,但不会替代完整研究复现实验。
零基础新手可以先照着安装和标准任务命令跑通,再改一个内部 JSONL 样本;不要一上来就做 Agent 自动化评测。
常见问题
LM Evaluation Harness 可以直接评估 Agent 吗?
不能直接等同。它适合评模型输出和标准任务,Agent 还需要额外评估工具调用、执行过程、权限边界、最终任务完成质量和人工接管成本。
few-shot 评测应该设多少 shot?
没有通用答案。公开 benchmark 要按论文或榜单设置复现;业务回归建议固定 0-shot 和少量 few-shot 两套配置,避免每次变更后结果不可比。
自定义 task 一定要写 Python 吗?
不一定。简单分类、选择题、生成式问答可以先用 YAML 配置;只有复杂后处理、特殊指标或动态过滤样本时,再用 !function 接 Python 函数。
小团队没有评测工程师怎么办?
先用 30 到 100 条真实样本做 JSONL,跑通安装、validate、run、log_samples 和人工复盘流程。等样本和指标稳定后,再接 CI 和更复杂工具。
公开榜单高的模型一定适合企业知识库吗?
不一定。企业知识库要看中文资料、权限、召回、引用、拒答和幻觉率;公开 benchmark 只能作为初筛,不能替代内部样本回归。
评测频率应该多高?
只要模型、prompt、检索策略、数据切分、工具权限或系统版本变化,就应该跑核心回归集。高频业务可每周固定跑,重大上线前必须跑。