OpenCompass 把评测变成运行层，超出排行榜截图

这里用上海人工智能实验室的真实照片作为视觉锚点很合适，因为 OpenCompass 来自中国研究基础设施，更接近一套机构化评测栈，而不是一次性的排行榜。[6]

截至 2026-05-26 UTC，OpenCompass 释放出的有用信号，并不限于中国又出现了一个评测框架。更值得抓住的一点在于，OpenCompass 正在把模型比较从排行榜截图文化中移开，推向一个可复现的运行层：配置、任务切分、执行、裁判、报告以及基准族维护，都被放进同一份评测契约之中。[1][2][3]

这个区别对 AI-China 观察很重要，因为国内模型市场的变量已经多到一个汇总分数很难承载实质意义。Qwen、GLM、DeepSeek、Hunyuan、InternLM、MiniCPM、Yi 以及其他模型家族，会因为托管端点、开放 checkpoint、提示模板、上下文窗口、推理后端、工具调用封装和裁判模型而出现差异。排行榜结果仍然有用，前提是读者能够重建产生这个结果的路径。OpenCompass 的重要性，正在于它把这条路径推到更显眼的位置。

图片语境：封面使用的是 Flickr 上题为 “Shanghai AI Lab” 的真实照片，上传时间为 2025 年 8 月。[6] 它不是生成式 AI 图片、图表或合成基准图形。这里的视觉重点是机构性：评测基础设施由实验室和工程团队建设，也由营销页面之外的长期工程实践支撑。

新论文准确命名了评测问题

2026 年 5 月 19 日提交到 arXiv 的 OpenCompass 论文，把问题界定为碎片化。静态基准评测要处理多样的任务类型、不一致的判定标准以及彼此分离的数据处理流程，这使跨领域、大规模评测很难高效运行。[1] 论文给出的答案是一套围绕模块化组件设计的平台，而不是某个精巧基准：配置、任务切分、执行与调度、任务执行和结果可视化。[1]

这份组件清单解释了这个项目值得关注的原因。在成熟的评测栈里，基准只是一个输入。运行层面的问题同样重要：一次运行怎样配置，任务怎样拆分，模型由什么后端提供服务，输出怎样被判定，局部失败怎样处理，运行结束后结果怎样进入可检查状态。把 OpenCompass 作为一种尝试来读，它最强的地方在于把这些问题纳入默认工作流，而不是放到事后附注中处理。[1][3]

论文还写到，OpenCompass 支持基于规则的评测器、LLM-as-judge 评测器和级联评测器，数据集覆盖知识、推理、计算、科学、语言和代码。[1] 这是一个很宽的覆盖声明，但边界也清楚：只有评测包络保持可见，广度才有价值。若一个结果混合了本地 checkpoint、托管 API、自定义提示模板、裁判模型和非默认抽取规则，除非这些选择随分数一起呈现，否则这个分数就不具备可迁移性。

工作流就是产品

OpenCompass 快速入门文档把运行模型讲得很具体。它描述了四个阶段：配置、推理、评测和可视化。[3] 配置阶段设定模型、数据集、评测策略、后端和展示方式。推理和评测可以作为并发任务运行。可视化阶段随后把结果汇总为可读表格，并保存为 CSV 和 TXT 文件。[3]

这些听起来基础，却正是多数模型比较需要的纪律。AI 评测中常见的失败形态，并非没有人能跑测试，而是每个团队都跑了略有差异的测试，随后又把输出当作可比较结果来讨论。一个团队使用带有厂商提示封装的托管端点，另一个团队在 vLLM 下使用本地 checkpoint，第三个团队改了抽取规则，第四个团队调整了 temperature 或 max tokens。缺少配置形态的记录时，结果会变成一次运行的叙事，而不是关于模型的证据。

OpenCompass 没有魔法般解决这个问题，但它为生态提供了一套共享语法。代码库自身的搭建路径包括 pip 安装、源码安装、用于更完整数据集支持的可选 extras、LMDeploy 和 vLLM 这样的加速后端、面向 OpenAI 和 Qwen 等服务的 API 评测路径、离线数据集准备、自动数据集下载，以及可选的 ModelScope 数据集加载。[2] 这些细节不是装饰。它们标出了复现性会断裂的位置：包 extras、数据集来源、后端选择、API 路由和模型配置，都会影响一个分数的含义。

因此，OpenCompass 作为基础设施的重要性高于它作为排行榜的重要性。排行榜是输出。更持久的价值在于那份配方，它让另一个团队能够追问：换一个后端、换一个裁判、换一个数据集切片，或换一条模型服务路径之后，这个输出是否仍然成立。

LLM-as-judge 很有力，也改变了证据边界

最重要的评测器边界是裁判选择。OpenCompass 增加并记录了 GenericLLMEvaluator，用于规则不足以覆盖的场景：开放式答案、事实性判断、没有清晰选项标识的输出，以及手写规则过于脆弱的任务。[4] 文档说明，用户可以把裁判层指向 OpenAI 或 DeepSeek 官方 API 这样的模型服务，也可以通过 LMDeploy、vLLM 或 SGLang 等工具运行本地服务。[4]

这种能力的用处和风险来自同一处。它有用，因为许多现代任务无法用精确匹配诚实计分。模型可以在答案格式不同的情况下解出题目，也可以生成需要语义判断的开放式回应。裁判模型让评测能够进入这些领域。

但裁判模型也会成为实验的一部分。若一次 OpenCompass 运行使用 DeepSeek 做裁判，另一次使用 Qwen，第三次使用通过 SGLang 提供服务的本地模型，基准结果就不再只关于候选模型。它同时关于候选模型、裁判模型、裁判提示和裁判服务条件。OpenCompass 的价值在于让这些部分可配置，进而可审计。剩下的负担属于编辑与科学实践：报告应说明一个数字来自规则计分、裁判计分还是级联计分，并且不应把这些模式装作可以互换。[1][4]

放在 AI-China 分析中，这是一个重要边界。中国实验室经常围绕推理、代码、数学、多语言理解、长上下文和智能体任务发布强模型主张。合适的回应，是询问这项主张由哪条评测路径产生。OpenCompass 让开发团队能够复现或挑战这条路径的一部分，把讨论从截图转向运行记录。

周边组织显示评测正在变成一个组合

OpenCompass 如今也不再只是一个代码库。OpenCompass GitHub 组织呈现出更宽的评测组合：用于 LLM 评测的主平台 OpenCompass，用于大型多模态模型评测的 VLMEvalKit，MMBench，CompassVerifier，CompassJudger，以及 GUI-agent 和金融场景等更新的专门基准仓库。[5] 组织主页列出主项目支持超过 100 个数据集，同时把 VLMEvalKit 描述为支持超过 220 个大型多模态模型和 80 多个基准。[5]

从战略层面看，中国的评测栈正在走向复数形态。纯文本模型比较、多模态能力、裁判建模、验证器建模、GUI-agent 任务、金融任务、科学任务和长上下文评测，正在变成相互分开的赛道。这样比把所有主张压进一个通用排名更健康，同时也让尽调工作更难。一个模型可以在通用中文考试基准上很强，却在 GUI grounding 上偏弱；可以在规则计分下表现好，在裁判计分下稳定性下降；可以赢下短上下文代码任务，却在长周期智能体工作流中失败。

OpenCompass 生态的价值，来自它对这些分隔的保留。若输出又被压回单一营销层级，它的用处就会减弱。好的基准栈应让分歧更清晰，而不是把分歧抹平。

接下来观察什么

第一项观察，是 OpenCompass 是否持续记录完整的运行包络。这个平台已经暴露了足够多会造成结果漂移的旋钮：模型后端、API 端点、数据集来源、并发、提示模板、裁判模型和评测器类型。[2][3][4] 更强的报告机制，应把这些旋钮默认展示出来。

第二项，是 OpenCompass 及相邻项目能否跟上智能体评测。GUI agents、工具使用、浏览器工作、代码执行和长周期规划，都很难由旧式静态问答习惯承载。OpenCompass 组织已经指向工具利用、多模态、验证器模型和 GUI-agent 工作。[5] 真正的测试在于，这些赛道能否成熟为可复现的运行手册，而不只是令人印象深刻的孤立演示。

第三项，是跨平台可比性。OpenCompass 可以评测本地 checkpoint 和 API 服务模型，也可以通过不同的加速或服务框架转接。[2][4] 只有报告保留本地权重、厂商管理端点和第三方托管封装之间的区别，这才是一项优势。否则，一个“模型分数”会遮住让这个分数成为现实的平台。

实际结论很窄。OpenCompass 不应被当作裁定哪个中国模型最佳的神谕。它更适合被当作评测工作台，让更好的问题以更低成本被提出：哪个数据集切片改变了结果？哪个裁判模型移动了排名？同一个 checkpoint 在 vLLM 和托管 API 下表现是否不同？多模态分数能否经受 GUI 任务检验？另一个团队能否从配置中复现这次运行？

随着中国模型生态变得更密，这些问题才真正重要。排名表仍然有用，但它需要等评测栈先完成更安静的工作：把运行变得足够可检查，让一个分数能够被信任、被质疑或被重复。

cronfeed.work