大模型评测这件事很多人第一次接触时都会觉得有点虚——模型跑出来的分数到底靠不靠谱同一套题为什么换个框架结果就对不上我最早做模型选型的时候拿几个开源模型在本地跑了一轮评测结果和公开榜单差了将近五个点排查了大半天才发现是提示词模板和解码参数没对齐。从那以后我就养成了一个习惯评测这件事工具链必须统一流程必须可复现否则数字再好看也没有参考价值。OpenCompass 就是在这个背景下进入我视野的它是配套大模型实战学习体系里专门讲评测的一环核心解决的就是怎么用一套标准化流程把模型能力量化出来这个问题。这篇内容适合三类人看正在做模型选型的技术负责人、想给自己微调模型做体检的算法同学以及刚接触大模型评测、想搞清楚评测框架到底怎么落地的新手。我会从设计思路、核心机制、实操流程到踩坑经验完整拆一遍尽量让你看完就能自己搭一套跑起来。1. 评测框架的整体设计与选型逻辑1.1 为什么评测需要一个专门框架先说一个很多人容易忽略的点大模型评测和传统机器学习评测完全不是一回事。传统分类任务你有一批带标签的数据跑一遍推理算准确率就完事了。但大模型是生成式的同一个问题它可能给出十种不同表述的正确答案也可能给出一段看起来很像但实际错误的回答。这就带来三个核心难题答案怎么判对错、不同模型的输出怎么公平比较、评测过程怎么保证可复现。如果不用框架纯手工做评测你大概率会陷入这样的困境每个数据集写一套脚本每个模型适配一遍接口判分规则散落在各个文件里跑完一轮想复现发现环境变了。我见过有团队为了对比三个模型写了上千行胶水代码最后连自己都不敢保证两次跑的结果一致。OpenCompass 这类框架的价值就在于把这些脏活累活标准化了——数据集加载、模型接入、提示词构造、答案抽取、指标计算全部收敛成配置驱动的流水线。从设计哲学上看它走的是配置即评测的路线。你不需要写大量代码而是通过一份配置文件描述清楚用哪些数据集、测哪些模型、用什么评测方式。框架负责把剩下的调度、并发、结果汇总全包了。这种设计对新手特别友好因为你可以先跑通官方示例再逐步替换成自己的数据集和模型学习曲线是平缓的。1.2 框架的分层架构拆解理解 OpenCompass 的架构我建议用四层模型来记忆这样后面配置的时候心里有张地图。层级职责典型组件数据集层提供题目、标准答案、评测规则各类开源评测集、自定义数据集模型层封装不同模型的推理接口本地模型、API 模型适配器任务层把数据集和模型组合成可执行任务任务配置、提示词模板执行层调度、并发、结果落盘与汇总运行器、评分器、报告生成这四层是解耦的意味着你可以只换模型层做横向对比也可以只换数据集层做垂直能力测试。我第一次用的时候没意识到这种解耦的价值后来要做同一模型在不同提示词下的表现差异实验才发现只要改任务层的模板配置就行模型和数据集完全不用动省了大量重复工作。提示新手最容易犯的错是一上来就想改框架源码。实际上绝大多数需求都能通过配置文件满足先翻官方文档的配置说明比读源码效率高得多。1.3 选型时该关注哪些维度市面上评测框架不止一个选型时我一般看四个维度。数据集覆盖度决定你能测多广主流框架通常会内置几十到上百个评测集覆盖知识、推理、代码、数学、长文本等方向。模型接入成本决定你上手快不快好的框架对本地模型和 API 模型都有成熟适配。判分方式的丰富度很关键客观题用精确匹配就行主观题就得靠模型裁判或者人工规则框架得支持多种判分器。结果可复现性是底线配置、随机种子、版本信息都得能固化下来。OpenCompass 在这几个维度上比较均衡尤其是数据集的组织方式和判分器的可扩展性做得比较细。它把每个数据集的提示词模板、答案抽取规则、评分逻辑都封装在数据集定义里你新增一个数据集时照着模板填就行不用从零设计。这种约定优于配置的思路对团队协作特别友好——大家用同一套约定结果才有可比性。2. 核心机制解析从题目到分数的完整链路2.1 提示词模板被低估的分数影响因子很多人以为评测就是把题目喂给模型实际上中间隔着一层提示词模板而这层模板对分数的影响大到超出想象。同一个数据集用不同的模板分数差三到五个点是常事。原因很简单大模型对指令格式极其敏感你让它直接输出答案和让它先分析再给出选项得到的分布完全不同。框架里的模板通常包含几个部分任务描述、题目内容、输出格式约束、少样本示例few-shot。少样本示例的数量和选取方式尤其关键。零样本zero-shot考验的是模型的指令遵循能力少样本则更接近真实使用场景但示例选得不好反而会干扰模型。我在实测中遇到过这样的情况某个推理数据集加了三个示例后模型开始机械模仿示例的句式反而把正确答案带偏了。配置模板时有个实用技巧先用官方默认模板跑一遍作为基线再尝试调整输出格式约束比如强制答案X的格式观察分数变化。如果变化很大说明这个模型对该数据集的格式敏感后续对比时就要固定模板否则横向比较没有意义。2.2 答案抽取生成式输出的翻译官模型输出是一段自然语言而评分器需要的是结构化答案中间这步就是答案抽取。这步看着简单实际是评测链路里最容易出问题的地方。举个典型场景选择题数据集模型可能输出我认为答案是 B因为……也可能输出B还可能输出选项B正确。抽取器得把这些都归一化成B。框架一般提供基于正则的抽取器和基于规则的抽取器。正则抽取器灵活但脆弱模型换个表述就可能匹配不上规则抽取器稳但覆盖不全。我的经验是抽取失败率要作为一项监控指标。跑完评测后一定要看有多少样本抽取失败如果失败率超过百分之几那分数就不可信了因为失败样本往往被记为错误会系统性拉低分数。注意抽取失败和模型答错是两回事。前者是工程问题后者是能力问题。混在一起看会得出错误结论。建议在结果报告里把这两类分开统计。2.3 判分器客观与主观的两套逻辑判分器分两大类。客观题判分相对直接选择题比对选项填空题做字符串匹配或归一化后匹配代码题跑单元测试。主观题判分就复杂了常见做法是用一个能力更强的模型当裁判模型即裁判让它对比模型输出和参考答案给分。模型裁判这套机制好用但有坑。第一个坑是裁判模型本身的偏好它可能偏爱某种表达风格导致风格分被误当成能力分。第二个坑是位置偏见对比两个答案时裁判可能倾向于选排在前面的那个。缓解办法是交换答案顺序跑两次取平均或者用多个裁判模型投票。第三个坑是评分标准不统一同一批数据不同时间跑裁判给的分数可能有波动所以裁判模型的版本和参数必须固定。我在实际项目里对主观题的处理原则是能用客观规则就不用模型裁判。比如数学题与其让裁判判断这个解法对不对不如抽取最终数值做精确匹配实在不行再做符号化简后匹配。只有在开放式生成任务上才动用模型裁判并且一定要做人工抽检校准。2.4 并发调度与结果落盘评测跑起来之后性能就是绕不开的话题。一个中等规模的数据集几千道题串行跑本地模型可能要几个小时。框架一般支持并发推理但并发数不是越大越好。本地模型受显存限制并发太高会 OOMAPI 模型受速率限制并发太高会触发限流报错。我的调参经验是本地模型先测单条推理耗时再根据显存余量估算最大并发通常留百分之二十的余量比较稳。API 模型则要看服务方的速率限制把并发控制在限制值的七成左右配合失败重试机制。结果落盘这块框架通常会把每条样本的原始输出、抽取结果、判分结果都存下来这个原始记录非常宝贵——后面排查问题、做错误分析全靠它千万别为了省空间只存汇总分数。3. 实操全流程从零跑通一次完整评测3.1 环境准备与依赖安装先讲环境。这类框架对 Python 版本和深度学习库版本比较敏感我建议用虚拟环境隔离别和系统环境混在一起。基础依赖通常是 Python 3.8 以上、PyTorch 对应你的显卡驱动版本再加上框架本体。# 创建并激活虚拟环境以 conda 为例 conda create -n eval_env python3.10 -y conda activate eval_env # 安装框架本体具体包名以官方文档为准 pip install opencompass # 如需本地模型推理安装对应推理后端 pip install torch transformers accelerate安装完先别急着跑大评测用框架自带的示例配置做一次冒烟测试确认环境通了。这一步能提前暴露版本冲突、显存不足、模型路径错误等问题比跑到一半报错强得多。提示显卡驱动、CUDA 版本、PyTorch 版本三者必须匹配。我见过太多人卡在这一步装完发现 torch 调不动 GPU白折腾半天。装之前先nvidia-smi看一眼驱动支持的 CUDA 上限。3.2 配置文件怎么写一份可复现的模板配置文件是整个评测的施工图。我习惯把它拆成三块来写模型配置、数据集配置、运行配置。下面给一份结构化的示例字段名以实际框架为准重点是理解组织方式。# 模型配置声明要评测的模型 models [ dict( type本地模型适配器, path/path/to/your/model, # 模型权重路径 max_out_len512, # 最大生成长度 batch_size8, # 批大小受显存约束 run_cfgdict(num_gpus1), # 使用的显卡数 ), ] # 数据集配置声明评测集和评测方式 datasets [ dict( type选择题数据集, abbrdemo_choice, # 结果里的简称 reader_cfgdict( input_columns[question], # 题目字段 output_columnanswer, # 标准答案字段 ), infer_cfgdict( prompt_templatedict( type提示词模板, templatedict( round[ dict(roleHUMAN, prompt问题{question}\n请直接给出选项。), ], ), ), retrieverdict(type零样本检索), ), eval_cfgdict( evaluatordict(type选项匹配评分器), ), ), ] # 运行配置控制调度和输出 work_dir ./outputs/demo_run # 结果目录这份配置的关键在于所有影响结果的参数都显式写出来生成长度、批大小、提示词模板、检索方式、评分器。不要依赖框架默认值因为默认值可能随版本变化一旦变了你的历史结果就没法复现了。3.3 启动评测与过程监控配置写好就可以启动了。命令行一般长这样python run.py configs/demo_config.py --mode all--mode all表示推理和评分一起做也可以拆成两步先推理后评分方便中途调整评分规则。启动后重点盯三件事进度条是否正常推进、显存占用是否稳定、日志里有没有大量报错。如果进度卡住不动多半是某个样本推理超时或者死锁了如果显存持续上涨可能是缓存没释放得调小批大小。跑的过程中我建议开一个终端专门tail -f日志文件实时看输出。有些框架会把每条样本的推理结果打到日志里你能第一时间发现模型输出格式异常——比如本该输出选项结果输出了一大段解释这时候就该停下来检查模板了别等跑完几千条才发现全废了。3.4 结果解读别只看总分评测跑完会生成一份汇总报告通常包含每个数据集的分数、样本数、抽取失败数等。新手最容易犯的错是只看总分排名实际上总分背后的信息量大得多。我一般按这个顺序看先看抽取失败率高了说明工程链路有问题分数不可信再看各数据集的分项分数找出模型的短板方向然后抽样看原始输出尤其是错题判断是真不会还是格式没对上最后才看横向对比和基线模型比差多少。这个顺序能帮你把工程问题和能力问题分开避免被虚假分数误导。观察项正常范围异常信号处理方向抽取失败率低于 2%超过 5%检查抽取规则和模板单数据集分数与公开结果接近偏差超过 5 分核对模板、参数、数据版本推理耗时稳定波动剧烈检查并发和资源竞争输出长度分布符合预期大量截断调大最大生成长度4. 常见问题排查与实战避坑经验4.1 分数对不上公开榜单怎么办这是最高频的问题。分数对不上先别怀疑框架按这个顺序排查数据版本是否一致评测集经常有修订版、提示词模板是否一致少样本数量、示例内容、解码参数是否一致温度、top_p、最大长度、答案抽取规则是否一致。这四项里任何一项不同分数都可能差几个点。我遇到过一次特别隐蔽的情况某数据集官方用的是五样本我配置里写成了零样本结果分数低了将近八分。排查了半天才在数据集定义文件里发现默认检索方式是五样本而我的配置覆盖成了零样本。所以配置里凡是覆盖默认值的地方都要心里有数。4.2 模型输出格式飘忽不定生成式模型的输出格式不稳定是常态。缓解手段有三层第一层在提示词里强约束格式明确说只输出选项字母不要解释第二层在抽取器里做多规则兜底正则匹配不到就尝试关键词匹配第三层在评分时对抽取失败的样本单独标记不直接判错。三层叠加能把格式问题的影响降到最低。注意不要为了迁就抽取器去过度约束提示词那样测出来的就不是模型的真实能力了。约束要适度以正常人类能理解为标准。4.3 并发跑崩与显存溢出显存溢出基本是批大小和序列长度共同作用的结果。估算方法是单条样本的显存占用约等于模型参数量乘以精度字节数再加上激活值和 KV 缓存。实际调的时候别算太细直接从批大小 1 开始往上试每次翻倍崩了就回退一档。API 模型则是限流问题加指数退避重试把并发压到限制值以下。4.4 评测结果不可复现不可复现的根源通常是随机性没控制住采样温度不为零、随机种子没固定、数据加载顺序随机、依赖版本漂移。解决办法是把温度设为 0贪心解码固定随机种子锁定依赖版本用 requirements 锁文件并在结果目录里记录完整的配置快照和环境信息。做到这几点同一份配置任何时候跑结果都应该一致。4.5 常见问题速查表现象可能原因排查动作分数整体偏低模板或参数与官方不一致逐项核对四项一致性抽取失败率高抽取正则覆盖不全抽样看原始输出补规则推理中途卡死单样本超时或死锁加超时机制缩小批大小显存溢出批大小或长度过大降批大小缩短生成长度结果两次不一致随机性未固定温度归零固定种子API 大量报错触发速率限制降并发加重试退避5. 把评测用出价值从跑分到决策5.1 自建数据集的正确姿势公开评测集测的是通用能力真正做业务选型时自建数据集才是关键。自建的核心原则是贴近真实场景题目从实际业务里采样答案由领域专家标注评分规则按业务容错度设计。规模不用大几百条高质量样本比几万条噪声样本有用得多。构建流程我一般这么走先收集真实问题去重清洗再人工标注标准答案标注时同步记录可接受的答案变体然后设计评分规则客观题精确匹配主观题定义评分维度最后做一轮小规模试跑校准评分规则确认评分和人工判断一致后再扩大规模。这个流程里最容易被跳过的是校准这步但它恰恰决定了你的评测结果能不能指导决策。5.2 用评测结果指导模型选型评测分数不是目的决策才是。选型时我建议做一张多维对比表把候选模型在各能力维度上的分数、推理成本、响应延迟、部署难度都列进去加权打分。很多时候综合分最高的模型未必最适合比如某个模型推理能力很强但延迟高在实时场景里就不如一个稍弱但响应快的模型。另外要警惕评测过拟合——如果你的自建数据集和训练数据有重叠分数会虚高。做选型评测时数据集一定要和训练数据隔离最好留一批完全没见过的样本做最终验证。5.3 持续评测的工程化思路模型会迭代数据会更新评测不能只做一次。工程化的做法是把评测纳入持续集成流程模型有新版本就自动触发评测结果和基线对比分数下降超过阈值就告警。这样能把模型悄悄变差这类问题在早期发现。实现上就是把配置文件版本化用脚本串起推理、评分、对比、报告生成输出一份带趋势图的结果看板。我在实际项目里踩过最深的坑是早期没做配置版本管理几个月后想复现某个历史结果发现配置文件早被改得面目全非只能凭记忆重建浪费了大量时间。从那以后所有评测配置都进版本库每次跑完把配置快照和结果一起归档这个习惯救了我很多次。最后分享一个小心得评测框架再完善也替代不了人对结果的判断。分数是参考抽样看原始输出、理解模型为什么错才是真正把评测用出价值的地方。工具帮你把流程标准化判断力还得自己练。 
长河君 · 2026/10/26 13:00:42 · 阅读 1.2k OpenCompass大模型评测实战：从设计原理到可复现流程
大模型评测这件事很多人第一次接触时都会觉得有点虚——模型跑出来的分数到底靠不靠谱同一套题为什么换个框架结果就对不上我最早做模型选型的时候拿几个开源模型在本地跑了一轮评测结果和公开榜单差了将近五个点排查了大半天才发现是提示词模板和解码参数没对齐。从那以后我就养成了一个习惯评测这件事工具链必须统一流程必须可复现否则数字再好看也没有参考价值。OpenCompass 就是在这个背景下进入我视野的它是配套大模型实战学习体系里专门讲评测的一环核心解决的就是怎么用一套标准化流程把模型能力量化出来这个问题。这篇内容适合三类人看正在做模型选型的技术负责人、想给自己微调模型做体检的算法同学以及刚接触大模型评测、想搞清楚评测框架到底怎么落地的新手。我会从设计思路、核心机制、实操流程到踩坑经验完整拆一遍尽量让你看完就能自己搭一套跑起来。1. 评测框架的整体设计与选型逻辑1.1 为什么评测需要一个专门框架先说一个很多人容易忽略的点大模型评测和传统机器学习评测完全不是一回事。传统分类任务你有一批带标签的数据跑一遍推理算准确率就完事了。但大模型是生成式的同一个问题它可能给出十种不同表述的正确答案也可能给出一段看起来很像但实际错误的回答。这就带来三个核心难题答案怎么判对错、不同模型的输出怎么公平比较、评测过程怎么保证可复现。如果不用框架纯手工做评测你大概率会陷入这样的困境每个数据集写一套脚本每个模型适配一遍接口判分规则散落在各个文件里跑完一轮想复现发现环境变了。我见过有团队为了对比三个模型写了上千行胶水代码最后连自己都不敢保证两次跑的结果一致。OpenCompass 这类框架的价值就在于把这些脏活累活标准化了——数据集加载、模型接入、提示词构造、答案抽取、指标计算全部收敛成配置驱动的流水线。从设计哲学上看它走的是配置即评测的路线。你不需要写大量代码而是通过一份配置文件描述清楚用哪些数据集、测哪些模型、用什么评测方式。框架负责把剩下的调度、并发、结果汇总全包了。这种设计对新手特别友好因为你可以先跑通官方示例再逐步替换成自己的数据集和模型学习曲线是平缓的。1.2 框架的分层架构拆解理解 OpenCompass 的架构我建议用四层模型来记忆这样后面配置的时候心里有张地图。层级职责典型组件数据集层提供题目、标准答案、评测规则各类开源评测集、自定义数据集模型层封装不同模型的推理接口本地模型、API 模型适配器任务层把数据集和模型组合成可执行任务任务配置、提示词模板执行层调度、并发、结果落盘与汇总运行器、评分器、报告生成这四层是解耦的意味着你可以只换模型层做横向对比也可以只换数据集层做垂直能力测试。我第一次用的时候没意识到这种解耦的价值后来要做同一模型在不同提示词下的表现差异实验才发现只要改任务层的模板配置就行模型和数据集完全不用动省了大量重复工作。提示新手最容易犯的错是一上来就想改框架源码。实际上绝大多数需求都能通过配置文件满足先翻官方文档的配置说明比读源码效率高得多。1.3 选型时该关注哪些维度市面上评测框架不止一个选型时我一般看四个维度。数据集覆盖度决定你能测多广主流框架通常会内置几十到上百个评测集覆盖知识、推理、代码、数学、长文本等方向。模型接入成本决定你上手快不快好的框架对本地模型和 API 模型都有成熟适配。判分方式的丰富度很关键客观题用精确匹配就行主观题就得靠模型裁判或者人工规则框架得支持多种判分器。结果可复现性是底线配置、随机种子、版本信息都得能固化下来。OpenCompass 在这几个维度上比较均衡尤其是数据集的组织方式和判分器的可扩展性做得比较细。它把每个数据集的提示词模板、答案抽取规则、评分逻辑都封装在数据集定义里你新增一个数据集时照着模板填就行不用从零设计。这种约定优于配置的思路对团队协作特别友好——大家用同一套约定结果才有可比性。2. 核心机制解析从题目到分数的完整链路2.1 提示词模板被低估的分数影响因子很多人以为评测就是把题目喂给模型实际上中间隔着一层提示词模板而这层模板对分数的影响大到超出想象。同一个数据集用不同的模板分数差三到五个点是常事。原因很简单大模型对指令格式极其敏感你让它直接输出答案和让它先分析再给出选项得到的分布完全不同。框架里的模板通常包含几个部分任务描述、题目内容、输出格式约束、少样本示例few-shot。少样本示例的数量和选取方式尤其关键。零样本zero-shot考验的是模型的指令遵循能力少样本则更接近真实使用场景但示例选得不好反而会干扰模型。我在实测中遇到过这样的情况某个推理数据集加了三个示例后模型开始机械模仿示例的句式反而把正确答案带偏了。配置模板时有个实用技巧先用官方默认模板跑一遍作为基线再尝试调整输出格式约束比如强制答案X的格式观察分数变化。如果变化很大说明这个模型对该数据集的格式敏感后续对比时就要固定模板否则横向比较没有意义。2.2 答案抽取生成式输出的翻译官模型输出是一段自然语言而评分器需要的是结构化答案中间这步就是答案抽取。这步看着简单实际是评测链路里最容易出问题的地方。举个典型场景选择题数据集模型可能输出我认为答案是 B因为……也可能输出B还可能输出选项B正确。抽取器得把这些都归一化成B。框架一般提供基于正则的抽取器和基于规则的抽取器。正则抽取器灵活但脆弱模型换个表述就可能匹配不上规则抽取器稳但覆盖不全。我的经验是抽取失败率要作为一项监控指标。跑完评测后一定要看有多少样本抽取失败如果失败率超过百分之几那分数就不可信了因为失败样本往往被记为错误会系统性拉低分数。注意抽取失败和模型答错是两回事。前者是工程问题后者是能力问题。混在一起看会得出错误结论。建议在结果报告里把这两类分开统计。2.3 判分器客观与主观的两套逻辑判分器分两大类。客观题判分相对直接选择题比对选项填空题做字符串匹配或归一化后匹配代码题跑单元测试。主观题判分就复杂了常见做法是用一个能力更强的模型当裁判模型即裁判让它对比模型输出和参考答案给分。模型裁判这套机制好用但有坑。第一个坑是裁判模型本身的偏好它可能偏爱某种表达风格导致风格分被误当成能力分。第二个坑是位置偏见对比两个答案时裁判可能倾向于选排在前面的那个。缓解办法是交换答案顺序跑两次取平均或者用多个裁判模型投票。第三个坑是评分标准不统一同一批数据不同时间跑裁判给的分数可能有波动所以裁判模型的版本和参数必须固定。我在实际项目里对主观题的处理原则是能用客观规则就不用模型裁判。比如数学题与其让裁判判断这个解法对不对不如抽取最终数值做精确匹配实在不行再做符号化简后匹配。只有在开放式生成任务上才动用模型裁判并且一定要做人工抽检校准。2.4 并发调度与结果落盘评测跑起来之后性能就是绕不开的话题。一个中等规模的数据集几千道题串行跑本地模型可能要几个小时。框架一般支持并发推理但并发数不是越大越好。本地模型受显存限制并发太高会 OOMAPI 模型受速率限制并发太高会触发限流报错。我的调参经验是本地模型先测单条推理耗时再根据显存余量估算最大并发通常留百分之二十的余量比较稳。API 模型则要看服务方的速率限制把并发控制在限制值的七成左右配合失败重试机制。结果落盘这块框架通常会把每条样本的原始输出、抽取结果、判分结果都存下来这个原始记录非常宝贵——后面排查问题、做错误分析全靠它千万别为了省空间只存汇总分数。3. 实操全流程从零跑通一次完整评测3.1 环境准备与依赖安装先讲环境。这类框架对 Python 版本和深度学习库版本比较敏感我建议用虚拟环境隔离别和系统环境混在一起。基础依赖通常是 Python 3.8 以上、PyTorch 对应你的显卡驱动版本再加上框架本体。# 创建并激活虚拟环境以 conda 为例 conda create -n eval_env python3.10 -y conda activate eval_env # 安装框架本体具体包名以官方文档为准 pip install opencompass # 如需本地模型推理安装对应推理后端 pip install torch transformers accelerate安装完先别急着跑大评测用框架自带的示例配置做一次冒烟测试确认环境通了。这一步能提前暴露版本冲突、显存不足、模型路径错误等问题比跑到一半报错强得多。提示显卡驱动、CUDA 版本、PyTorch 版本三者必须匹配。我见过太多人卡在这一步装完发现 torch 调不动 GPU白折腾半天。装之前先nvidia-smi看一眼驱动支持的 CUDA 上限。3.2 配置文件怎么写一份可复现的模板配置文件是整个评测的施工图。我习惯把它拆成三块来写模型配置、数据集配置、运行配置。下面给一份结构化的示例字段名以实际框架为准重点是理解组织方式。# 模型配置声明要评测的模型 models [ dict( type本地模型适配器, path/path/to/your/model, # 模型权重路径 max_out_len512, # 最大生成长度 batch_size8, # 批大小受显存约束 run_cfgdict(num_gpus1), # 使用的显卡数 ), ] # 数据集配置声明评测集和评测方式 datasets [ dict( type选择题数据集, abbrdemo_choice, # 结果里的简称 reader_cfgdict( input_columns[question], # 题目字段 output_columnanswer, # 标准答案字段 ), infer_cfgdict( prompt_templatedict( type提示词模板, templatedict( round[ dict(roleHUMAN, prompt问题{question}\n请直接给出选项。), ], ), ), retrieverdict(type零样本检索), ), eval_cfgdict( evaluatordict(type选项匹配评分器), ), ), ] # 运行配置控制调度和输出 work_dir ./outputs/demo_run # 结果目录这份配置的关键在于所有影响结果的参数都显式写出来生成长度、批大小、提示词模板、检索方式、评分器。不要依赖框架默认值因为默认值可能随版本变化一旦变了你的历史结果就没法复现了。3.3 启动评测与过程监控配置写好就可以启动了。命令行一般长这样python run.py configs/demo_config.py --mode all--mode all表示推理和评分一起做也可以拆成两步先推理后评分方便中途调整评分规则。启动后重点盯三件事进度条是否正常推进、显存占用是否稳定、日志里有没有大量报错。如果进度卡住不动多半是某个样本推理超时或者死锁了如果显存持续上涨可能是缓存没释放得调小批大小。跑的过程中我建议开一个终端专门tail -f日志文件实时看输出。有些框架会把每条样本的推理结果打到日志里你能第一时间发现模型输出格式异常——比如本该输出选项结果输出了一大段解释这时候就该停下来检查模板了别等跑完几千条才发现全废了。3.4 结果解读别只看总分评测跑完会生成一份汇总报告通常包含每个数据集的分数、样本数、抽取失败数等。新手最容易犯的错是只看总分排名实际上总分背后的信息量大得多。我一般按这个顺序看先看抽取失败率高了说明工程链路有问题分数不可信再看各数据集的分项分数找出模型的短板方向然后抽样看原始输出尤其是错题判断是真不会还是格式没对上最后才看横向对比和基线模型比差多少。这个顺序能帮你把工程问题和能力问题分开避免被虚假分数误导。观察项正常范围异常信号处理方向抽取失败率低于 2%超过 5%检查抽取规则和模板单数据集分数与公开结果接近偏差超过 5 分核对模板、参数、数据版本推理耗时稳定波动剧烈检查并发和资源竞争输出长度分布符合预期大量截断调大最大生成长度4. 常见问题排查与实战避坑经验4.1 分数对不上公开榜单怎么办这是最高频的问题。分数对不上先别怀疑框架按这个顺序排查数据版本是否一致评测集经常有修订版、提示词模板是否一致少样本数量、示例内容、解码参数是否一致温度、top_p、最大长度、答案抽取规则是否一致。这四项里任何一项不同分数都可能差几个点。我遇到过一次特别隐蔽的情况某数据集官方用的是五样本我配置里写成了零样本结果分数低了将近八分。排查了半天才在数据集定义文件里发现默认检索方式是五样本而我的配置覆盖成了零样本。所以配置里凡是覆盖默认值的地方都要心里有数。4.2 模型输出格式飘忽不定生成式模型的输出格式不稳定是常态。缓解手段有三层第一层在提示词里强约束格式明确说只输出选项字母不要解释第二层在抽取器里做多规则兜底正则匹配不到就尝试关键词匹配第三层在评分时对抽取失败的样本单独标记不直接判错。三层叠加能把格式问题的影响降到最低。注意不要为了迁就抽取器去过度约束提示词那样测出来的就不是模型的真实能力了。约束要适度以正常人类能理解为标准。4.3 并发跑崩与显存溢出显存溢出基本是批大小和序列长度共同作用的结果。估算方法是单条样本的显存占用约等于模型参数量乘以精度字节数再加上激活值和 KV 缓存。实际调的时候别算太细直接从批大小 1 开始往上试每次翻倍崩了就回退一档。API 模型则是限流问题加指数退避重试把并发压到限制值以下。4.4 评测结果不可复现不可复现的根源通常是随机性没控制住采样温度不为零、随机种子没固定、数据加载顺序随机、依赖版本漂移。解决办法是把温度设为 0贪心解码固定随机种子锁定依赖版本用 requirements 锁文件并在结果目录里记录完整的配置快照和环境信息。做到这几点同一份配置任何时候跑结果都应该一致。4.5 常见问题速查表现象可能原因排查动作分数整体偏低模板或参数与官方不一致逐项核对四项一致性抽取失败率高抽取正则覆盖不全抽样看原始输出补规则推理中途卡死单样本超时或死锁加超时机制缩小批大小显存溢出批大小或长度过大降批大小缩短生成长度结果两次不一致随机性未固定温度归零固定种子API 大量报错触发速率限制降并发加重试退避5. 把评测用出价值从跑分到决策5.1 自建数据集的正确姿势公开评测集测的是通用能力真正做业务选型时自建数据集才是关键。自建的核心原则是贴近真实场景题目从实际业务里采样答案由领域专家标注评分规则按业务容错度设计。规模不用大几百条高质量样本比几万条噪声样本有用得多。构建流程我一般这么走先收集真实问题去重清洗再人工标注标准答案标注时同步记录可接受的答案变体然后设计评分规则客观题精确匹配主观题定义评分维度最后做一轮小规模试跑校准评分规则确认评分和人工判断一致后再扩大规模。这个流程里最容易被跳过的是校准这步但它恰恰决定了你的评测结果能不能指导决策。5.2 用评测结果指导模型选型评测分数不是目的决策才是。选型时我建议做一张多维对比表把候选模型在各能力维度上的分数、推理成本、响应延迟、部署难度都列进去加权打分。很多时候综合分最高的模型未必最适合比如某个模型推理能力很强但延迟高在实时场景里就不如一个稍弱但响应快的模型。另外要警惕评测过拟合——如果你的自建数据集和训练数据有重叠分数会虚高。做选型评测时数据集一定要和训练数据隔离最好留一批完全没见过的样本做最终验证。5.3 持续评测的工程化思路模型会迭代数据会更新评测不能只做一次。工程化的做法是把评测纳入持续集成流程模型有新版本就自动触发评测结果和基线对比分数下降超过阈值就告警。这样能把模型悄悄变差这类问题在早期发现。实现上就是把配置文件版本化用脚本串起推理、评分、对比、报告生成输出一份带趋势图的结果看板。我在实际项目里踩过最深的坑是早期没做配置版本管理几个月后想复现某个历史结果发现配置文件早被改得面目全非只能凭记忆重建浪费了大量时间。从那以后所有评测配置都进版本库每次跑完把配置快照和结果一起归档这个习惯救了我很多次。最后分享一个小心得评测框架再完善也替代不了人对结果的判断。分数是参考抽样看原始输出、理解模型为什么错才是真正把评测用出价值的地方。工具帮你把流程标准化判断力还得自己练。