企业官网建设流程全解析

大模型评测这件事，很多人第一次接触时都会觉得有点虚——模型跑出来的分数到底靠不靠谱？同一套题为什么换个框架结果就对不上？我最早做模型选型的时候，拿几个开源模型在本地跑了一轮评测，结果和公开榜单差了将近五个点，排查了大半天才发现是提示词模板和解码参数没对齐。从那以后我就养成了一个习惯：评测这件事，工具链必须统一，流程必须可复现，否则数字再好看也没有参考价值。OpenCompass 就是在这个背景下进入我视野的，它是配套大模型实战学习体系里专门讲评测的一环，核心解决的就是"怎么用一套标准化流程，把模型能力量化出来"这个问题。这篇内容适合三类人看：正在做模型选型的技术负责人、想给自己微调模型做体检的算法同学，以及刚接触大模型评测、想搞清楚评测框架到底怎么落地的新手。我会从设计思路、核心机制、实操流程到踩坑经验完整拆一遍，尽量让你看完就能自己搭一套跑起来。

1. 评测框架的整体设计与选型逻辑

1.1 为什么评测需要一个专门框架

先说一个很多人容易忽略的点：大模型评测和传统机器学习评测完全不是一回事。传统分类任务，你有一批带标签的数据，跑一遍推理算准确率就完事了。但大模型是生成式的，同一个问题它可能给出十种不同表述的正确答案，也可能给出一段看起来很像但实际错误的回答。这就带来三个核心难题：答案怎么判对错、不同模型的输出怎么公平比较、评测过程怎么保证可复现。

如果不用框架，纯手工做评测，你大概率会陷入这样的困境：每个数据集写一套脚本，每个模型适配一遍接口，判分规则散落在各个文件里，跑完一轮想复现发现环境变了。我见过有团队为了对比三个模型，写了上千行胶水代码，最后连自己都不敢保证两次跑的结果一致。OpenCompass 这类框架的价值就在于把这些脏活累活标准化了——数据集加载、模型接入、提示词构造、答案抽取、指标计算，全部收敛成配置驱动的流水线。

从设计哲学上看，它走的是"配置即评测"的路线。你不需要写大量代码，而是通过一份配置文件描述清楚：用哪些数据集、测哪些模型、用什么评测方式。框架负责把剩下的调度、并发、结果汇总全包了。这种设计对新手特别友好，因为你可以先跑通官方示例，再逐步替换成自己的数据集和模型，学习曲线是平缓的。

1.2 框架的分层架构拆解

理解 OpenCompass 的架构，我建议用"四层模型"来记忆，这样后面配置的时候心里有张地图。

这四层是解耦的，意味着你可以只换模型层做横向对比，也可以只换数据集层做垂直能力测试。我第一次用的时候没意识到这种解耦的价值，后来要做"同一模型在不同提示词下的表现差异"实验，才发现只要改任务层的模板配置就行，模型和数据集完全不用动，省了大量重复工作。

提示：新手最容易犯的错是一上来就想改框架源码。实际上绝大多数需求都能通过配置文件满足，先翻官方文档的配置说明，比读源码效率高得多。

1.3 选型时该关注哪些维度

市面上评测框架不止一个，选型时我一般看四个维度。数据集覆盖度决定你能测多广，主流框架通常会内置几十到上百个评测集，覆盖知识、推理、代码、数学、长文本等方向。模型接入成本决定你上手快不快，好的框架对本地模型和 API 模型都有成熟适配。判分方式的丰富度很关键，客观题用精确匹配就行，主观题就得靠模型裁判或者人工规则，框架得支持多种判分器。结果可复现性是底线，配置、随机种子、版本信息都得能固化下来。

OpenCompass 在这几个维度上比较均衡，尤其是数据集的组织方式和判分器的可扩展性做得比较细。它把每个数据集的提示词模板、答案抽取规则、评分逻辑都封装在数据集定义里，你新增一个数据集时照着模板填就行，不用从零设计。这种"约定优于配置"的思路，对团队协作特别友好——大家用同一套约定，结果才有可比性。

2. 核心机制解析：从题目到分数的完整链路

2.1 提示词模板：被低估的分数影响因子

很多人以为评测就是"把题目喂给模型"，实际上中间隔着一层提示词模板，而这层模板对分数的影响大到超出想象。同一个数据集，用不同的模板，分数差三到五个点是常事。原因很简单：大模型对指令格式极其敏感，你让它"直接输出答案"和让它"先分析再给出选项"，得到的分布完全不同。

框架里的模板通常包含几个部分：任务描述、题目内容、输出格式约束、少样本示例（few-shot）。少样本示例的数量和选取方式尤其关键。零样本（zero-shot）考验的是模型的指令遵循能力，少样本则更接近真实使用场景，但示例选得不好反而会干扰模型。我在实测中遇到过这样的情况：某个推理数据集加了三个示例后，模型开始机械模仿示例的句式，反而把正确答案带偏了。

配置模板时有个实用技巧：先用官方默认模板跑一遍作为基线，再尝试调整输出格式约束（比如强制"答案：X"的格式），观察分数变化。如果变化很大，说明这个模型对该数据集的格式敏感，后续对比时就要固定模板，否则横向比较没有意义。

2.2 答案抽取：生成式输出的"翻译官"

模型输出是一段自然语言，而评分器需要的是结构化答案，中间这步就是答案抽取。这步看着简单，实际是评测链路里最容易出问题的地方。举个典型场景：选择题数据集，模型可能输出"我认为答案是 B，因为……"，也可能输出"B"，还可能输出"选项B正确"。抽取器得把这些都归一化成"B"。

框架一般提供基于正则的抽取器和基于规则的抽取器。正则抽取器灵活但脆弱，模型换个表述就可能匹配不上；规则抽取器稳但覆盖不全。我的经验是：抽取失败率要作为一项监控指标。跑完评测后一定要看有多少样本抽取失败，如果失败率超过百分之几，那分数就不可信了，因为失败样本往往被记为错误，会系统性拉低分数。

注意：抽取失败和模型答错是两回事。前者是工程问题，后者是能力问题。混在一起看会得出错误结论。建议在结果报告里把这两类分开统计。

2.3 判分器：客观与主观的两套逻辑

判分器分两大类。客观题判分相对直接，选择题比对选项，填空题做字符串匹配或归一化后匹配，代码题跑单元测试。主观题判分就复杂了，常见做法是用一个能力更强的模型当裁判（模型即裁判），让它对比模型输出和参考答案给分。

模型裁判这套机制好用但有坑。第一个坑是裁判模型本身的偏好，它可能偏爱某种表达风格，导致风格分被误当成能力分。第二个坑是位置偏见，对比两个答案时，裁判可能倾向于选排在前面的那个。缓解办法是交换答案顺序跑两次取平均，或者用多个裁判模型投票。第三个坑是评分标准不统一，同一批数据不同时间跑，裁判给的分数可能有波动，所以裁判模型的版本和参数必须固定。

我在实际项目里对主观题的处理原则是：能用客观规则就不用模型裁判。比如数学题，与其让裁判判断"这个解法对不对"，不如抽取最终数值做精确匹配，实在不行再做符号化简后匹配。只有在开放式生成任务上，才动用模型裁判，并且一定要做人工抽检校准。

2.4 并发调度与结果落盘

评测跑起来之后，性能就是绕不开的话题。一个中等规模的数据集几千道题，串行跑本地模型可能要几个小时。框架一般支持并发推理，但并发数不是越大越好。本地模型受显存限制，并发太高会 OOM；API 模型受速率限制，并发太高会触发限流报错。

我的调参经验是：本地模型先测单条推理耗时，再根据显存余量估算最大并发，通常留百分之二十的余量比较稳。API 模型则要看服务方的速率限制，把并发控制在限制值的七成左右，配合失败重试机制。结果落盘这块，框架通常会把每条样本的原始输出、抽取结果、判分结果都存下来，这个原始记录非常宝贵——后面排查问题、做错误分析全靠它，千万别为了省空间只存汇总分数。

3. 实操全流程：从零跑通一次完整评测

3.1 环境准备与依赖安装

先讲环境。这类框架对 Python 版本和深度学习库版本比较敏感，我建议用虚拟环境隔离，别和系统环境混在一起。基础依赖通常是 Python 3.8 以上、PyTorch 对应你的显卡驱动版本，再加上框架本体。

# 创建并激活虚拟环境（以 conda 为例） conda create -n eval_env python=3.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_len=512, # 最大生成长度 batch_size=8, # 批大小，受显存约束 run_cfg=dict(num_gpus=1), # 使用的显卡数 ), ] # 数据集配置：声明评测集和评测方式 datasets = [ dict( type='选择题数据集', abbr='demo_choice', # 结果里的简称 reader_cfg=dict( input_columns=['question'], # 题目字段 output_column='answer', # 标准答案字段 ), infer_cfg=dict( prompt_template=dict( type='提示词模板', template=dict( round=[ dict(role='HUMAN', prompt='问题：{question}\n请直接给出选项。'), ], ), ), retriever=dict(type='零样本检索'), ), eval_cfg=dict( evaluator=dict(type='选项匹配评分器'), ), ), ] # 运行配置：控制调度和输出 work_dir = './outputs/demo_run' # 结果目录

这份配置的关键在于所有影响结果的参数都显式写出来：生成长度、批大小、提示词模板、检索方式、评分器。不要依赖框架默认值，因为默认值可能随版本变化，一旦变了你的历史结果就没法复现了。

3.3 启动评测与过程监控

配置写好就可以启动了。命令行一般长这样：

python run.py configs/demo_config.py --mode all

--mode all表示推理和评分一起做，也可以拆成两步先推理后评分，方便中途调整评分规则。启动后重点盯三件事：进度条是否正常推进、显存占用是否稳定、日志里有没有大量报错。如果进度卡住不动，多半是某个样本推理超时或者死锁了；如果显存持续上涨，可能是缓存没释放，得调小批大小。

跑的过程中我建议开一个终端专门tail -f日志文件，实时看输出。有些框架会把每条样本的推理结果打到日志里，你能第一时间发现模型输出格式异常——比如本该输出选项，结果输出了一大段解释，这时候就该停下来检查模板了，别等跑完几千条才发现全废了。

3.4 结果解读：别只看总分

评测跑完会生成一份汇总报告，通常包含每个数据集的分数、样本数、抽取失败数等。新手最容易犯的错是只看总分排名，实际上总分背后的信息量大得多。

我一般按这个顺序看：先看抽取失败率，高了说明工程链路有问题，分数不可信；再看各数据集的分项分数，找出模型的短板方向；然后抽样看原始输出，尤其是错题，判断是真不会还是格式没对上；最后才看横向对比，和基线模型比差多少。这个顺序能帮你把"工程问题"和"能力问题"分开，避免被虚假分数误导。

4. 常见问题排查与实战避坑经验

4.1 分数对不上公开榜单怎么办

这是最高频的问题。分数对不上，先别怀疑框架，按这个顺序排查：数据版本是否一致（评测集经常有修订版）、提示词模板是否一致（少样本数量、示例内容）、解码参数是否一致（温度、top_p、最大长度）、答案抽取规则是否一致。这四项里任何一项不同，分数都可能差几个点。

我遇到过一次特别隐蔽的情况：某数据集官方用的是五样本，我配置里写成了零样本，结果分数低了将近八分。排查了半天才在数据集定义文件里发现默认检索方式是五样本，而我的配置覆盖成了零样本。所以配置里凡是覆盖默认值的地方，都要心里有数。

4.2 模型输出格式飘忽不定

生成式模型的输出格式不稳定是常态。缓解手段有三层：第一层在提示词里强约束格式，明确说"只输出选项字母，不要解释"；第二层在抽取器里做多规则兜底，正则匹配不到就尝试关键词匹配；第三层在评分时对抽取失败的样本单独标记，不直接判错。三层叠加能把格式问题的影响降到最低。

注意：不要为了迁就抽取器去过度约束提示词，那样测出来的就不是模型的真实能力了。约束要适度，以"正常人类能理解"为标准。

4.3 并发跑崩与显存溢出

显存溢出基本是批大小和序列长度共同作用的结果。估算方法是：单条样本的显存占用约等于模型参数量乘以精度字节数，再加上激活值和 KV 缓存。实际调的时候别算太细，直接从批大小 1 开始往上试，每次翻倍，崩了就回退一档。API 模型则是限流问题，加指数退避重试，把并发压到限制值以下。

4.4 评测结果不可复现

不可复现的根源通常是随机性没控制住：采样温度不为零、随机种子没固定、数据加载顺序随机、依赖版本漂移。解决办法是把温度设为 0（贪心解码），固定随机种子，锁定依赖版本（用 requirements 锁文件），并在结果目录里记录完整的配置快照和环境信息。做到这几点，同一份配置任何时候跑结果都应该一致。

4.5 常见问题速查表

5. 把评测用出价值：从跑分到决策

5.1 自建数据集的正确姿势

公开评测集测的是通用能力，真正做业务选型时，自建数据集才是关键。自建的核心原则是贴近真实场景：题目从实际业务里采样，答案由领域专家标注，评分规则按业务容错度设计。规模不用大，几百条高质量样本比几万条噪声样本有用得多。

构建流程我一般这么走：先收集真实问题，去重清洗；再人工标注标准答案，标注时同步记录"可接受的答案变体"；然后设计评分规则，客观题精确匹配，主观题定义评分维度；最后做一轮小规模试跑，校准评分规则，确认评分和人工判断一致后再扩大规模。这个流程里最容易被跳过的是"校准"这步，但它恰恰决定了你的评测结果能不能指导决策。

5.2 用评测结果指导模型选型

评测分数不是目的，决策才是。选型时我建议做一张多维对比表，把候选模型在各能力维度上的分数、推理成本、响应延迟、部署难度都列进去，加权打分。很多时候综合分最高的模型未必最适合，比如某个模型推理能力很强但延迟高，在实时场景里就不如一个稍弱但响应快的模型。

另外要警惕"评测过拟合"——如果你的自建数据集和训练数据有重叠，分数会虚高。做选型评测时，数据集一定要和训练数据隔离，最好留一批完全没见过的样本做最终验证。

5.3 持续评测的工程化思路

模型会迭代，数据会更新，评测不能只做一次。工程化的做法是把评测纳入持续集成流程：模型有新版本就自动触发评测，结果和基线对比，分数下降超过阈值就告警。这样能把"模型悄悄变差"这类问题在早期发现。实现上就是把配置文件版本化，用脚本串起推理、评分、对比、报告生成，输出一份带趋势图的结果看板。

我在实际项目里踩过最深的坑，是早期没做配置版本管理，几个月后想复现某个历史结果，发现配置文件早被改得面目全非，只能凭记忆重建，浪费了大量时间。从那以后所有评测配置都进版本库，每次跑完把配置快照和结果一起归档，这个习惯救了我很多次。

最后分享一个小心得：评测框架再完善，也替代不了人对结果的判断。分数是参考，抽样看原始输出、理解模型为什么错，才是真正把评测用出价值的地方。工具帮你把流程标准化，判断力还得自己练。