如何验证微调后的模型真的变强了lm-evaluation-harness 模型评测三步走【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness如果你手头有一个刚微调完的语言模型最想知道的一定是它到底比原始模型强在哪lm-evaluation-harness 就是专门解决这个问题的评测框架它用统一的提示词和打分标准把不同模型放到同一套考卷上比较。本文带你从零跑通第一次评测并学会看懂结果报告从此告别凭感觉说模型变强了。一个真实场景微调后的模型到底强在哪小林花了三天微调了一个模型跑了几条样例感觉回答变聪明了。但别人问他强了多少、强在哪些任务上他却说不出来。这就是最典型的评测需求用统一标准量化模型能力而不是靠几条样例的主观印象。lm-evaluation-harness 的做法很简单粗暴但有效内置 60 多个学术基准hellaswag、arc_easy、mmlu、gsm8k 等把问题和标准答案打包成固定格式的考卷模型逐题作答最后统一判分。同一个分数体系才能支撑有意义的横向对比。接下来我们跟着小林的节奏完成一次完整的A/B 评测用原始模型和微调模型跑同一个任务对比分数。第一步装好环境让评测跑起来先把仓库克隆到本地并安装基础包git clone --depth 1 https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness cd lm-evaluation-harness pip install -e .⚠️ 注意新版框架把模型后端拆成了可选的 extras基础包不包含transformers 和 torch。跑 HuggingFace 模型前记得补装你的场景安装命令用 HuggingFace transformers 模型pip install lm_eval[hf]用 vLLM 做高速推理pip install lm_eval[vllm]调 OpenAI / Anthropic 等 APIpip install lm_eval[api]装完后先别急着跑用下面命令确认框架能认出内置任务lm-eval ls tasks看到一长串任务列表hellaswag、arc_easy、lambada_openai……就说明环境 OK 了。这一步你带走的一个能列出 60 内置评测任务的可用环境这是后面所有操作的地基。第二步先测基线再测微调模型评测的第一步永远是先测基线——也就是微调前的原始模型。基线分数是后面所有对比的参照物没有它微调后的分数就是无源之水。我们选 hellaswag 任务常识推理判断哪个结尾最合理做实验。先看它的配置是怎么定义的见lm_eval/tasks/hellaswag/hellaswag.yamltask: hellaswag dataset_path: Rowan/hellaswag output_type: multiple_choice doc_to_text: {{query}} metric_list: - metric: acc aggregation: mean higher_is_better: true - metric: acc_norm aggregation: mean higher_is_better: true大白话翻译这个任务用 Rowan/hellaswag 数据集题型是从几个选项里挑一个打分用 acc 和 acc_norm 两种准确率分数越高越好。跑评测的命令只有一行lm-eval run --model hf --model_args pretrainedgpt2 --tasks hellaswag --device cuda:0 --batch_size 8 第一次跑通之前强烈建议加--limit 0.1只跑 10% 的数据先把流程跑通、确认没有报错再放开跑全量。框架官方文档docs/interface.md里也明确标注--limit参数就是设计来给你做快速测试的。等命令行打出类似这样的进度条和结果表第一次评测就成功了| Tasks |Version|Filter|n-shot|Metric| |Value | |Stderr| |-------------|-------|------|-----:|------|---|-----:|---|-----:| |hellaswag | 1|none | 0|acc |↑ |0.2817|± |0.0045| | | |none | 0|acc_norm|↑|0.3070|± |0.0046|趁热打铁把pretrainedgpt2换成你微调模型的路径本地目录或模型名都行跑出第二张表。两张表放一起胜负立刻分明。评测里经常提到few-shot意思是把几个示例连同题目一起塞给模型模型照葫芦画瓢作答。下图就是一个经典的 few-shot 提示示例——给模型几个英语→法语的翻译例子再让它翻译新词想给任务加 few-shot 示例只需加一个参数--num_fewshot 5每个问题前带 5 个示例。示例数量也会写进结果表的 n-shot 列保证别人能复现你的评测。这一步你带走的一条能跑的评测命令以及模型在具体任务上的第一份成绩单。第三步读报告——三张表看懂评测结果评测输出的 JSON 结构长这样docs/python-api.md有完整说明results: hellaswag: acc: 0.2817 acc_norm: 0.3070 acc,stderr: 0.0045新手最容易懵的是acc 和 acc_norm 到底啥区别perplexity 又是什么这里给你一份指标速查表指标大白话解释记住这三点acc标准准确率模型选对的比例越高越好acc_norm长度归一化准确率惩罚话多的模型通常比 acc 更可靠perplexity困惑度模型对标准答案的惊讶程度越低越好loglikelihood模型给某个答案打的对数概率通常越大越好exact_match生成结果与标准答案完全一致的比率越高越好为什么要有acc_norm因为选择题里答案越长模型算出的总概率天然越低acc会悄悄偏向短答案。acc_norm用答案长度做了归一化把这种偏差抹平了。框架在lm_eval/api/metrics.py里统一注册了这些指标和聚合方式你看到的每个分数都是同一套代码算出来的这就是分数可比的底气。结果表里每个分数后面还跟着stderr标准误比如0.2817 ± 0.0045。± 号后面的数告诉你这个分数的波动范围样本量越大波动越小。两个模型的分数差距如果小于这个波动范围就不能轻易下A 比 B 强的结论——这就是为什么要看完整结果再下判断。这一步你带走的一眼看懂评测报告的能力以及分数高低的判断标准这把尺子。踩坑时间为什么两次结果不一样小林很快遇到了新问题同一个模型、同一个任务跑了两遍分数居然不一样。排查清单如下检查batch_size设置改成auto时框架会自动探测最优批大小但不同机器探测结果可能不同。想要结果可复现就用固定整数比如--batch_size 8。检查 n-shot 是否一致0-shot 和 5-shot 的分数差之千里对比时务必锁定同一个--num_fewshot。检查任务版本结果表里的 Version 列写明了任务版本比如 1.0框架升级后任务定义可能变化不同版本的任务分数不可直接比较。启用缓存--cache_requests true可以缓存预处理后的提示词--use_cache 缓存前缀可以缓存模型推理结果。评测中途断了接着跑能省一大半时间。小心 YAML 引号陷阱写自定义配置时until: [\n]这种转义字符必须用双引号。用单引号[\n]会被当成字面量反斜杠加 n模型永远不会在换行处停下来。这是docs/footguns.md里被反复点名的高频事故。⚠️ 公平对比的黄金法则除了模型本身其他一切参数保持完全一致。包括任务、few-shot 数量、batch 大小、生成参数、设备。改任何一个变量结果就失去可比性。这一步你带走的一张分数为什么不一样的排查清单以及一套可复现评测的固定流程。进阶方向从会用到会改跑通标准评测只是起点lm-evaluation-harness 的开放性体现在三个层次1. 看单个样本找模型短板加--log_samples --output_path ./results/框架会把每个样本的输入、模型输出、标准答案全部存下来。评测完翻一翻比看总分有用得多——你会亲眼看到模型错在哪类题上这是微调方向的直接线索。2. 跑自己的评测任务框架的TaskManager支持指定额外的任务目录你把自己写的 YAML 任务文件放进include_path就能和内置任务一起跑。lm_eval/tasks/下每个子目录就是一组任务随便翻开一个 yaml 文件照着模板改数据集路径和指标就能造出自己的考卷。3. 接更多类型的模型和任务框架的评测覆盖远不止选择题和生成题。比如 Norwegian 评测集 NorEval 就整合了文本分类、序列生成、多选问答等多种任务类型一个框架统一打分这一步你带走的三条从会用框架走向用框架解决自己问题的路径知道改代码该从哪里下手。下一步动手做一次完整的 A/B 评测现在轮到你了。建议按下面的清单完成一次真实评测练习装好环境lm-eval ls tasks能列出任务用--limit 0.1在 hellaswag 上跑通原始模型换成你的微调模型跑出第二张结果表对比 acc、acc_norm、stderr写一句模型在常识推理上强了多少的结论加--num_fewshot 5再看一次观察 few-shot 的影响加--log_samples翻看错题找出模型的短板类型做完这些你已经完成了从不会评测到能设计可复现的对比实验的跨越。还想深入的话官方文档都躺在仓库的docs/目录里docs/interface.md讲 CLI 全参数docs/python-api.md讲如何在 Python 脚本里调用docs/config_files.md讲 YAML 配置文件docs/footguns.md是官方踩坑大全。下一篇进阶文章我们聊怎么动手写一个属于自己的评测任务。【免费下载链接】lm-evaluation-harnessA framework for few-shot evaluation of language models.项目地址: https://gitcode.com/GitHub_Trending/lm/lm-evaluation-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
