OpenCompass：一站式大模型评测平台核心原理与实战指南

1. 项目概述：OpenCompass，你的大模型评测“导航仪”

如果你正在大模型的海洋里航行，面对层出不穷的新模型和眼花缭乱的评测榜单，感到无所适从，那么OpenCompass就是你需要的那个“导航仪”。这不是一个简单的跑分工具，而是一个由上海人工智能实验室开源的一站式、可复现的大模型综合能力评测平台。简单来说，它帮你回答一个核心问题：这个模型到底行不行？在哪些方面行？

我接触过不少评测框架，有的只聚焦于特定任务，有的配置复杂到让人望而却步。OpenCompass的吸引力在于它的“全栈”和“易用”。它预置了超过70个主流评测数据集，覆盖了知识、推理、语言、长文本、代码、安全等几乎所有你能想到的维度，总计约40万道题目。这意味着，你不需要再四处搜集、预处理各种评测集，一个平台就能完成从语言理解到复杂推理的全面体检。无论是想对比自家训练的模型与ChatGPT的差距，还是验证Llama 3在中文任务上的真实表现，OpenCompass都能提供一套标准化的“考场”和“考卷”。

它的设计哲学很明确：公平、开放、可复现。所有评测配置（模型加载方式、提示词模板、采样参数）都以配置文件的形式固化下来。这意味着你今天跑出来的结果，三个月后换个人、换台机器，只要配置一样，就能得到完全一致的结果。这对于学术研究和工业界的模型选型至关重要，避免了因为评测方法不一致导致的“公说公有理，婆说婆有理”的混乱局面。

接下来，我会带你深入OpenCompass的内部，拆解它的核心设计、手把手教你完成一次完整的评测，并分享我在实际使用中积累的避坑经验和调优技巧。无论你是算法研究员、应用开发者，还是对LLM能力好奇的技术爱好者，这篇文章都能让你快速上手，并理解其背后的门道。

2. 核心设计思路：模块化与分布式，如何支撑海量评测

OpenCompass之所以能高效处理如此庞杂的评测任务，其核心在于两个关键设计：高度模块化的架构和智能的任务切分与分布式调度。理解这两点，你就能明白它为何既能灵活扩展，又能高效运行。

2.1 模块化架构：像搭积木一样配置评测任务

OpenCompass将一次评测任务抽象为几个核心组件，每个组件都可以独立配置和替换。这种设计让评测任务的组合变得极其灵活。

1. 数据集 (Dataset)：这是“考题”的来源。OpenCompass不仅支持本地数据文件，还支持从ModelScope等平台动态加载，避免了下载数百GB数据的痛苦。每个数据集配置定义了如何读取数据、如何构造输入（Prompt）。例如，对于GSM8K数学推理题，它会将题目包装成“Question: ... Let's think step by step.”的格式；对于MMLU知识问答，则可能采用标准的A/B/C/D选择题格式。

2. 模型 (Model)：这是“考生”。支持方式非常广泛：

• HuggingFace 模型：直接通过transformers库加载，这是最常用的方式。
• API 模型：如GPT-4、Claude、文心一言等，通过统一的接口封装进行调用。
• 推理后端加速模型：通过LMDeploy、vLLM等高性能推理框架加载，极大提升吞吐量。 模型配置中定义了模型路径、生成参数（如temperature, max_tokens）、以及对话模板（对于Chat模型）。

3. 评测器 (Evaluator)：这是“阅卷老师”。它负责将模型生成的答案与标准答案进行比对，给出分数。OpenCompass内置了多种评测器：

• 规则匹配评测器：适用于有明确答案的任务，如选择题（匹配选项字母）、数学题（匹配最终数值）、代码题（通过单元测试）。
• LLM-as-a-Judge：对于主观性强的任务（如创意写作、安全性），使用一个更强的LLM（如GPT-4）来评判另一个LLM的输出。这是当前主观评测的主流方法。
• 特定任务评测器：如用于数学推理验证的MATHVerifyEvaluator。

4. 总结器 (Summarizer)：这是“成绩统计员”。在所有分片任务完成后，它负责汇总各个数据集、各个模型的结果，计算平均分、生成排行榜和详细的评测报告（通常是一个结构清晰的JSON或Markdown文件）。

你的评测配置（一个Python文件），本质上就是将这些“积木”组合起来。这种模块化意味着，当你有一个新的模型格式或一个新的评测数据集时，你只需要实现对应的模块并注册即可，无需改动核心流程。

2.2 智能任务切分与分布式执行：把大象放进冰箱的策略

评测一个模型在几十个数据集上的表现，数据量可能达到几十万条。在单卡上顺序执行，可能需要数天甚至数周。OpenCompass的分布式策略是其高效性的灵魂。

它采用了一种“分而治之”的策略。当你提交一个任务时，OpenCompass会首先进行任务划分 (Task Partition)。划分的维度有两个：

1. 模型维度：不同模型之间天然可以并行。
2. 数据集维度：同一个模型在不同数据集上的评测也可以并行。

更细粒度地，对于单个数据集，如果数据量很大（如数万条），OpenCompass还会自动将数据集分片 (Shard)，每个分片作为一个独立的子任务。例如，一个包含10万条数据的数据集，可能会被切分成100个任务，每个任务处理1000条数据。

划分完成后，这些海量的子任务会被提交到一个任务队列中。OpenCompass支持多种后端：

• 本地多进程：在单台多卡服务器上，利用Python的multiprocessing启动多个工作进程，每个进程绑定一块GPU，从队列中拉取任务执行。这是最常用的方式。
• Slurm/PBS：在超算集群上，可以将每个任务提交为一个独立的作业。
• Docker：支持容器化部署，保证环境一致性。

一个关键细节：OpenCompass采用了惰性生成和缓存的策略。对于模型推理，只有在任务真正被某个工作进程执行时，才会加载对应的模型权重。并且，一旦某个模型在某个GPU上被加载，后续分配到同一GPU的、需要同一模型的任务会复用这个已加载的实例，避免了重复加载模型带来的巨大开销。这是它能实现高效分布式评测的关键优化。

实操心得：合理设置分片大小分片大小 (--max-partition-size) 是一个需要权衡的参数。分片太小（如100条），会产生大量任务，任务调度和管理开销会变大；分片太大（如5000条），则单个任务运行时间过长，不利于负载均衡，且万一任务失败，重试成本高。我的经验是，对于生成任务（每条数据推理时间较长），分片大小设置在500-1000比较合适；对于判别任务（如PPL困惑度计算，速度很快），可以设置到2000-5000。你可以通过--debug模式先跑一个小样本，估算单条数据的平均处理时间，再来调整。

3. 从零开始：手把手完成你的第一次评测

理论说得再多，不如亲手跑一遍。我们以评测一个流行的开源模型，比如Qwen2.5-7B-Instruct，在小学数学推理数据集GSM8K上的表现为例，走通全流程。

3.1 环境搭建：一步一脚印，避开依赖地狱

OpenCompass官方推荐使用Conda管理环境，这能最大程度避免包冲突。以下是我验证过的稳定步骤：

# 1. 创建并激活环境 conda create -n opencompass python=3.10 -y conda activate opencompass # 2. 安装OpenCompass核心包 pip install -U opencompass

如果网络通畅，这通常是最快的方式。但有时你会遇到网络问题或需要最新特性，那么从源码安装是更好的选择：

git clone https://github.com/open-compass/opencompass.git cd opencompass pip install -e .

安装选项解析：

• pip install -U opencompass：安装核心功能，支持大部分评测。
• pip install “opencompass[full]”：安装全部可选依赖，包括一些特定数据集需要的库（如代码评测需要的evalplus）。如果你不确定要评测哪些数据集，建议安装这个版本，一劳永逸。
• pip install “opencompass[api]”：如果你需要评测OpenAI、Claude等API模型，必须安装此选项，它会安装openai等SDK。
• pip install “opencompass[lmdeploy]”或pip install “opencompass[vllm]”：如果你打算使用LMDeploy或vLLM进行推理加速。注意：这些加速框架通常有特定的CUDA、PyTorch版本要求，且彼此可能存在冲突。我强烈建议为它们创建独立的虚拟环境。

避坑指南：CUDA版本与PyTorch匹配这是深度学习环境的老大难问题。OpenCompass本身不限制PyTorch版本，但你需要确保安装的PyTorch与你系统的CUDA驱动版本兼容。使用nvidia-smi查看CUDA驱动版本（如12.4），然后去 PyTorch官网 查找对应的安装命令。例如，对于CUDA 12.1，你可能需要pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121。不匹配的版本会导致无法利用GPU或直接报错。

3.2 数据准备：三种方式，总有一款适合你

评测需要数据。OpenCompass提供了三种数据获取方式：

方式一：离线下载（推荐首次使用）这是最直接的方式，下载官方打包好的核心数据集。

# 在opencompass项目根目录下操作 wget https://github.com/open-compass/opencompass/releases/download/0.2.2.rc1/OpenCompassData-core-20240207.zip unzip OpenCompassData-core-20240207.zip -d data/

解压后，所有数据会放在data/目录下，结构清晰。这种方式适合网络稳定、希望本地持有所有数据的用户。

方式二：自动下载（按需加载）OpenCompass支持在首次运行时自动从服务器下载所需数据集。你只需要在命令后加上--dry-run参数，它会在准备阶段下载缺失的数据。

opencompass --models hf_qwen2.5_7b_instruct --datasets gsm8k_gen --dry-run

执行后，程序会列出需要的数据集并开始下载。这种方式省心，但要求网络能访问GitHub等资源。

方式三：ModelScope集成（免下载）对于部分数据集，OpenCompass可以直接从ModelScope平台流式读取，无需本地存储。这非常适合数据量巨大或本地存储紧张的场景。

# 首先安装 modelscope pip install modelscope # 设置环境变量，告诉OpenCompass优先从ModelScope获取数据 export DATASET_SOURCE=ModelScope

之后运行评测时，相关数据集会自动从ModelScope加载。你可以在官方文档的dataset_statistics页面查看哪些数据集支持此功能。

3.3 运行第一个评测：CLI与脚本两种姿势

准备好环境和数据后，就可以开始评测了。OpenCompass提供了两种启动方式：命令行(CLI)和Python脚本。CLI适合快速、简单的评测；脚本则能实现所有复杂配置。

姿势一：使用CLI（最快上手）假设我们想用Qwen2.5-7B-Instruct跑GSM8K：

opencompass --models hf_qwen2.5_7b_instruct --datasets gsm8k_gen

解释一下这个命令：

• --models hf_qwen2.5_7b_instruct：hf_前缀表示这是一个HuggingFace格式的模型。qwen2.5_7b_instruct是OpenCompass预定义的一个模型配置别名，指向Qwen/Qwen2.5-7B-Instruct这个模型仓库。
• --datasets gsm8k_gen：gsm8k_gen是OpenCompass为GSM8K数据集预定义的生成式评测配置。_gen后缀表示这是一个生成任务（模型需要输出解题步骤和答案），与之相对的是_ppl（困惑度判别任务，通常用于基座模型）。

程序会开始运行，你会在终端看到任务划分、进度条和实时日志。默认情况下，它会使用所有可用的GPU进行分布式计算。

姿势二：使用Python脚本（功能全面）CLI虽然方便，但功能有限。更强大的方式是编写一个Python配置文件。OpenCompass在examples/目录下提供了大量示例。我们创建一个简单的eval_demo.py：

from opencompass.openicl.icl_prompt_template import PromptTemplate from opencompass.openicl.icl_retriever import ZeroRetriever from opencompass.openicl.icl_inferencer import GenInferencer from opencompass.datasets import GSM8KDataset from opencompass.utils.text_postprocessors import first_capital_postprocess from opencompass.summarizers import GSM8KSummarizer # 1. 定义数据集 gsm8k_reader_cfg = dict(input_columns=['question'], output_column='answer') gsm8k_infer_cfg = dict( prompt_template=dict( type=PromptTemplate, template=dict(round=[ dict(role='HUMAN', prompt='Question: {question}\nLet\'s think step by step.'), ]), ), retriever=dict(type=ZeroRetriever), inferencer=dict(type=GenInferencer, max_out_len=512), ) gsm8k_eval_cfg = dict(evaluator=dict(type=AccEvaluator), pred_postprocessor=dict(type=first_capital_postprocess)) gsm8k_datasets = [ dict( type=GSM8KDataset, path='data/gsm8k', reader_cfg=gsm8k_reader_cfg, infer_cfg=gsm8k_infer_cfg, eval_cfg=gsm8k_eval_cfg, ) ] # 2. 定义模型 models = [ dict( type=HuggingFaceCausalLM, abbr='qwen2.5-7b-instruct', path='Qwen/Qwen2.5-7B-Instruct', tokenizer_path='Qwen/Qwen2.5-7B-Instruct', model_kwargs=dict(device_map='auto', torch_dtype=torch.bfloat16), max_out_len=1024, batch_size=8, run_cfg=dict(num_gpus=1), # 指定每份模型副本使用的GPU数 ) ] # 3. 组合并运行 work_dir = './outputs/demo' datasets = gsm8k_datasets

然后运行：

opencompass eval_demo.py

脚本方式让你能精细控制每一个环节，例如自定义提示词模板、调整批次大小、设置不同的后处理逻辑等。

运行后发生了什么？

1. 任务划分：程序根据你的GPU数量（假设有4张卡）和模型配置（num_gpus=1），可能会将数据集分成多个分片，生成几十个独立任务。
2. 分布式执行：4个工作进程启动，每个进程占用1张GPU，加载模型，然后从任务队列中领取数据分片进行处理。
3. 结果收集：每个任务完成后，会生成一个中间结果文件（通常保存在outputs/下的子目录）。
4. 总结报告：所有任务完成后，总结器会自动运行，读取所有中间结果，计算模型在GSM8K上的准确率，并生成一份格式清晰的报告。报告路径通常在outputs/${时间戳}/summary/目录下。

打开总结报告，你就能看到模型的最终得分了。

4. 深入核心：模型、数据集与评测范式详解

掌握了基础操作，我们深入看看OpenCompass如何支持如此多样的模型、数据集和评测方法。

4.1 模型支持：从本地HF到云端API

OpenCompass通过统一的抽象接口支持各类模型，核心是BaseModel类。对于用户来说，最常见的是以下三种配置方式：

1. HuggingFace 本地模型这是最常用的场景。配置中需要指定模型路径（本地或HuggingFace Hub）、Tokenizer路径、模型加载参数等。

dict( type=HuggingFaceCausalLM, # 或 HuggingFaceChatGLM3 等特定类 abbr='internlm2-7b', path='internlm/internlm2-7b', tokenizer_path='internlm/internlm2-7b', model_kwargs=dict( device_map='auto', torch_dtype=torch.bfloat16, # 使用BF16节省显存 trust_remote_code=True, # 对于需要自定义代码的模型（如Qwen），必须开启 ), max_out_len=2048, batch_size=4, run_cfg=dict(num_gpus=1), )

关键参数解析：

• abbr: 模型缩写，用于报告标识。
• path: 模型在HF Hub上的ID或本地路径。
• torch_dtype: 推荐使用torch.bfloat16，在支持它的GPU上能在几乎不损失精度的情况下大幅减少显存占用。如果显卡不支持（如某些旧卡），则用torch.float16。
• batch_size: 推理批次大小。增大批次能提升吞吐，但会增加显存消耗。需要根据模型大小和GPU内存调整。对于7B模型，在24G显存的卡上，batch_size=8或16通常是安全的。
• run_cfg.num_gpus: 该模型实例需要占用几张GPU。对于大于70B的模型，可能需要num_gpus=2或4进行张量并行。

2. API 模型评测GPT-4、Claude等闭源模型同样简单。你需要先设置好API Key环境变量。

export OPENAI_API_KEY='sk-...' export OPENAI_BASE_URL='https://api.openai.com/v1' # 如果是其他兼容接口

然后在配置中：

dict( type=OpenAI, abbr='gpt-4o-2024-05-13', path='gpt-4o-2024-05-13', key='ENV', # 从环境变量 OPENAI_API_KEY 读取 max_out_len=2048, run_cfg=dict(num_gpus=0), # API调用不占用本地GPU batch_size=1, # API通常串行调用 )

对于最新的o1系列推理模型，OpenCompass也提供了专门支持，需要设置更大的max_completion_tokens。

3. 加速推理后端 (LMDeploy/vLLM)当评测的模型很大或需要极高吞吐时，使用原生HuggingFace推理可能成为瓶颈。这时可以切换到LMDeploy或vLLM。

# 使用LMDeploy后端进行评测 opencompass --models hf_internlm2_7b --datasets mmlu_gen -a lmdeploy

在脚本配置中，你需要使用对应的包装类，如LMDeploy。这些后端通过持续的批处理、高效的注意力机制实现，能将吞吐量提升数倍甚至数十倍，特别适合大规模批量评测。

实操心得：模型加载的显存优化对于非常大的模型（如70B），即使使用bf16，单卡显存也不够。除了使用num_gpus进行张量并行，还可以利用device_map=‘auto’让accelerate库自动进行模型分片，配合offload_folder参数将部分层卸载到CPU内存。另一种更高效的方式是使用bitsandbytes库进行4/8比特量化。虽然OpenCompass配置中不直接暴露量化参数，但你可以通过自定义model_kwargs传入load_in_4bit=True等参数（需提前安装bitsandbytes）。量化会轻微影响精度，但对于能力摸底式的评测，是一个可行的权衡。

4.2 数据集与评测范式：规则评判与AI裁判

OpenCompass将数据集与评测范式紧密绑定。一个数据集配置通常包含三部分：数据读取器 (Reader)、推理配置 (Inferencer)和评测配置 (Evaluator)。

1. 生成式评测 (Generation) vs. 判别式评测 (Perplexity)

• _gen后缀：用于生成式任务。模型根据输入（提示词）生成一段文本，评测器再对这段文本进行评判。适用于问答、推理、代码生成、摘要等开放式任务。GSM8K、HumanEval都属于此类。
• _ppl后缀：用于判别式任务，通常是选择题。模型计算每个选项的困惑度（Perplexity），选择困惑度最低的选项作为答案。这种方式不需要模型生成，只需前向计算，速度更快，常用于MMLU、C-Eval等知识性选择题评测。对于基座模型（没有经过对话对齐），这种评测方式往往更稳定。

2. 提示词工程 (Prompt Engineering)评测结果对提示词非常敏感。OpenCompass的PromptTemplate模块让你能灵活定义。

prompt_template=dict( type=PromptTemplate, template=dict( round=[ dict(role='SYSTEM', prompt='You are a helpful assistant.'), dict(role='HUMAN', prompt='Please answer the following question.\n{question}'), # 可以加入 few-shot examples dict(role='HUMAN', prompt='Q: Example question 1?'), dict(role='ASSISTANT', prompt='A: Example answer 1.'), dict(role='HUMAN', prompt='Q: {question}'), ] ), )

对于Chat模型，正确设置SYSTEM、HUMAN、ASSISTANT角色对应的提示词模板至关重要，这直接影响了模型是否能理解指令并遵循格式输出。OpenCompass为许多主流Chat模型（如Llama-3、Qwen、ChatGLM）预置了正确的对话模板。

3. LLM-as-a-Judge (AI裁判)对于创意写作、安全性、事实性等没有标准答案的任务，规则匹配无能为力。OpenCompass集成了“大模型评大模型”的能力。

# 使用预置的LLM Judge配置评测创意写作数据集 opencompass --datasets creative_writing_llmjudge_gen --models hf_qwen2.5_7b_instruct

在这种配置下，评测流程是： a. 被评测模型生成回答。 b. 将问题、被评测模型的回答、以及评分规则（Rubric）一起，构造成一个新的提示词，提交给一个“裁判模型”（如GPT-4）。 c. “裁判模型”根据规则输出一个分数或评价。 d. OpenCompass解析裁判模型的输出，得到最终得分。

OpenCompass的GenericLLMEvaluator模块让配置AI裁判变得非常简单。你需要指定裁判模型（如gpt-4）、评分规则提示词、以及解析裁判输出的后处理函数。

4.3 结果解读与可视化

评测完成后，所有结果都汇总在outputs/${timestamp}/summary/目录下。最重要的文件是summary_${timestamp}.txt或summary_${timestamp}.json。

文本报告会以清晰的表格形式展示各个模型在各个数据集上的得分。例如：

| Model | GSM8K | MMLU | C-Eval | ... | Average | |----------------------|-------|------|--------|-----|---------| | qwen2.5-7b-instruct | 78.2 | 68.5 | 72.1 | ... | 73.2 | | llama3-8b-instruct | 75.6 | 66.8 | 70.3 | ... | 71.5 |

JSON报告则包含了更详细的信息，如每个数据子类的得分、模型生成的具体答案样例等，便于进行细致的分析。

OpenCompass还提供了一个Web可视化工具（虽然目前功能相对基础），你可以通过它来更直观地对比多个模型的雷达图或趋势图。对于团队协作和报告呈现，将JSON结果导入到Excel或BI工具中进行自定义分析是更常见的做法。

5. 高级技巧与实战避坑指南

当你开始大规模、定制化地使用OpenCompass时，会遇到一些更具体的问题。这里分享一些我踩过坑后总结的经验。

5.1 性能调优：让评测跑得更快更稳

1. 充分利用多卡与多机

• --max-num-worker：这是控制数据并行工作进程数的关键参数。通常设置为可用的GPU数量。如果你的任务有多个模型，OpenCompass会尝试让不同模型也并行跑。
• --num-gpus（在模型配置中）：这是控制模型并行的参数。对于一个70B模型，设置num_gpus=4，OpenCompass会尝试用4张卡来加载一个模型实例。注意，max-num-worker和num-gpus是相乘的关系。如果有2个worker，每个worker的模型需要2张卡，那么至少需要4张物理GPU。
• 混合并行策略：对于超大规模评测（如同时测10个模型），资源可能不够。一种策略是使用--max-num-worker 1但让每个worker使用多卡 (num_gpus>1) 来跑大模型，然后通过脚本顺序提交多个任务。另一种策略是利用集群调度系统（如Slurm），为每个模型评测任务提交一个独立的作业。

2. 推理后端选择

• HuggingFace (transformers)：兼容性最好，支持所有HF格式模型，但原生推理速度最慢，显存优化一般。
• vLLM：对于大多数Decoder-only模型（如Llama、Qwen），吞吐量极高，尤其擅长处理长序列和大量并发请求。但它对模型架构有一定要求，且早期版本对某些模型（如ChatGLM）支持不佳。
• LMDeploy：由InternLM团队开发，对InternLM系列模型优化极好，同时兼容性也相当不错。它提供了TurboMind推理引擎，性能优秀，且集成了量化、服务部署等全套工具链。选择建议：如果你的模型是InternLM，无脑选LMDeploy。如果是主流架构（Llama, Qwen），追求极致吞吐，选vLLM。如果模型比较小众或需要特定功能（如自定义注意力），则用HuggingFace。

3. 缓存与断点续跑评测可能因为各种原因中断（如OOM、网络超时）。OpenCompass有较好的容错机制，但更可靠的做法是利用其缓存。中间结果（outputs/下的.pkl或.json文件）一旦生成，后续重跑时会自动跳过。你可以定期备份outputs目录。如果任务完全卡死，可以删除outputs/下正在进行的任务目录（通常以_tmp结尾或时间戳最新），然后重新运行。

5.2 常见问题排查 (FAQ)

下面是我遇到的一些典型问题及解决方案，整理成了速查表：

5.3 自定义评测：添加新数据集或新模型

OpenCompass的扩展性很强。添加新数据集通常需要：

1. 将数据整理成标准格式（如JSON Lines，每行一个样本，包含question,answer等字段）。
2. 在configs/datasets/下创建一个新的配置文件，定义Dataset、Reader、Inferencer、Evaluator。
3. 参照现有配置，编写数据读取、提示词构建、答案后处理和评分逻辑。

添加新模型（特别是新的API或推理框架）稍微复杂一些，可能需要继承BaseModel类并实现generate和get_ppl等方法。不过，大多数遵循OpenAI API格式或HuggingFaceAutoModelForCausalLM接口的模型，都能通过现有包装类快速接入。

我个人在添加企业内部私有模型时，最常用的方法是实现一个简单的HTTP客户端类，模仿OpenAI类的接口，然后将模型服务地址和密钥配置进去，就能无缝接入OpenCompass的评测流水线了。

6. 生态与展望：不止于跑分的OpenCompass 2.0

OpenCompass早已超越了一个单纯的评测工具，它正在成长为一个完整的评测生态，即OpenCompass 2.0，主要由三部分组成：

1. CompassRank (排行榜)：这是最直观的成果展示。OpenCompass团队定期用海量数据集评测主流开源和API模型，将结果呈现在 官方网站 上。这个排行榜的价值在于其一致性和可复现性，所有结果都基于相同的配置和代码跑出，横向对比意义重大。你可以把它当作模型选型的“消费指南”。

2. CompassHub (基准集线器)：可以把它理解为“评测数据集的App Store”。研究者可以在这里发布、发现和一站式使用各种评测基准。它解决了数据集分散、格式不统一、预处理麻烦的痛点。如果你构建了一个新的评测数据集，强烈建议提交到CompassHub，让更多人基于你的基准进行公平对比。

3. CompassKit (工具包)：这是OpenCompass的核心引擎，也是我们一直在讨论的部分。它持续集成最新的评测方法，如长文本评估（NeedleBench, RULER）、智能体（Agent）工具调用评估、代码能力评估（HumanEval, MBPP+）、鲁棒性（对抗攻击）评估等。

未来的方向，从Roadmap可以看出，团队正聚焦于更复杂、更贴近实际应用场景的评估：

• 主观与对齐评估：如何量化评估模型输出的“有用性”、“诚实性”和“无害性”，是当前的研究热点。CompassArena等基于人类偏好或AI裁判的评估方法会越来越重要。
• 长上下文：随着模型上下文窗口突破百万，如何系统评估其长文档理解、信息检索和推理能力，NeedleBench和RULER只是开始。
• 智能体（Agent）：评估模型使用工具、规划步骤、与环境交互的能力，这比静态问答复杂得多，需要模拟真实环境。
• 多模态：虽然本文聚焦LLM，但OpenCompass也已开始支持大型视觉-语言模型（LVLM）的评估。

作为一线使用者，我的体会是，OpenCompass最大的价值在于它降低了大规模、标准化模型评测的门槛。以前需要一个小团队折腾几周的事情，现在一个人一两天就能搞定。它让研究者能更专注于模型本身的创新，而非重复搭建评测基础设施。当然，它也不是银弹，提示词的微妙影响、评测数据集的固有偏差、以及“考试能力”是否等同于“真实应用能力”的哲学问题，依然需要使用者保持清醒的认知。但无论如何，有了OpenCompass这个强大而精密的“导航仪”，我们在探索大模型能力的航程中，无疑拥有了更可靠的地图和罗盘。