科学量化大模型能力提升：构建可复现的评测流程

一年时间放在传统软件技术栈里，通常只够完成一两个版本迭代；放在大模型生态里，却足够让多个主流模型家族完成一轮甚至几轮能力升级。“三大模型一年间能力飞跃”这类话题，很多人是靠发布会演示、社交媒体片段和排行榜截图建立印象的，这些信息适合用来形成直觉，不适合直接支撑工程决策。至于具体是哪三个模型，不同阶段、不同统计口径下的答案并不一样；与其争论名单，不如把注意力放在一个更实际的问题上：如何判断一个模型家族在过去一年里到底变强了多少。真正需要回答的包括：具体在推理、代码、长文本等维度提升了多少，提升点在哪里，有没有以牺牲其他能力为代价，以及回到自己的业务场景中，这种提升能否转化为可衡量的收益。要回答这些问题，不能停留在看榜，而是要把模型评测变成一套可重复、可量化、可追溯的工程流程。下面从评测认知开始，逐步搭出一套可用到实际项目的评测流程。

1. 一年回顾为什么不能只看排行榜：先建立正确的评测认知

1.1 三种观察模型能力变化的方式

第一种是发布会和演示。厂商通常会挑选最能体现优势的场景，配合精心设计的提示词，把模型的高光能力展示出来。这类演示可以快速建立对能力边界的直觉，但样本量太小，存在明显的挑选偏差，不能代表模型的平均水平。

第二种是公共基准测试和排行榜。MMLU、HumanEval、GSM8K、MMLU-Pro 等数据集，常被用来横向比较不同模型在同一批题目上的表现。它们确实是标准化的对比工具，但存在一个随时间推移越来越严重的问题：题目一旦公开，后续训练的大模型就可能“见过原题”。公共榜单的区分度会持续下降，尤其不适合单独用来判断“一年前和现在变化了多少”。

第三种是自建业务评测集。从自己的真实业务中抽取问题，用统一流程调用模型，记录原始输出，再由脚本或人工打分。这种方式成本最高，但对工程决策最有帮助，因为评测内容与实际使用场景一致。

三种方式可以配合：演示负责建立直觉，公共榜单负责观察相对位置，自建评测集负责回答“升级模型或切换供应商，到底能不能给业务带来提升”。

1.2 可靠评测的四条基本原则

第一条是控制变量。调用不同模型时，temperature、top_p、max_tokens、system prompt 必须保持一致。默认情况下 temperature 应设为 0，这是做对比评测时降低随机性的基本手段。

第二条是保持同一批输入。不要因为某个模型“风格不同”就顺手改写提示词。提示词一旦不同，得到的分差就分不清是模型能力差异还是提示词差异。如果确实需要对某个模型单独优化提示词，就必须在评测元数据里记录“该模型经过提示词适配”。

第三条是可复现。每次评测保存完整请求、完整输出、模型快照、API 版本、评测日期和脚本版本。输出落盘为 JSONL，纳入版本管理，三个月后还能重新分析。

第四条是防止数据泄漏。评测题尽量使用未公开、原创、贴近业务场景的题目。若必须使用公开题，至少记录题目发布时间，并意识到模型可能已经见过原题。

注意：评测结论只对“当前测试集 + 当前提示词 + 当前参数”负责。任何一次评测都不能代表模型在所有场景下的能力。

三种观察方式的适用场景，可以通过下表快速判断：

2. 搭建可复现的模型评测环境：从测试集到脚本都要可追溯

2.1 环境准备与依赖

做评测不需要强大的本地算力，只需要能调用模型 API，因此开发机、测试机或 CI 环境都可以。以 Python 为例，推荐配置如下：

需要注意，SDK 版本变化很快，不同版本的接口参数可能不同。项目里要固定依赖版本，并在评测记录中写入 requirements.txt 或等价信息，避免换一台机器就复现不了。

2.2 最小评测脚本设计与实现

下面是一个最小评测脚本，用 requests 调用 OpenAI 兼容的 chat completions 接口。直接用 HTTP 是为了方便对不同模型家族做统一封装；如果只评测某一个模型，使用官方 SDK 会更省事。

import json import time import os import argparse import requests def call_model(model_config, user_prompt, temperature=0.0, max_tokens=1024): headers = { "Authorization": f"Bearer {model_config['api_key']}", "Content-Type": "application/json", } payload = { "model": model_config["model_name"], "messages": [{"role": "user", "content": user_prompt}], "temperature": temperature, "max_tokens": max_tokens, } started = time.time() response = requests.post( f"{model_config['base_url']}/chat/completions", headers=headers, json=payload, timeout=120, ) elapsed = time.time() - started response.raise_for_status() data = response.json() return { "output": data["choices"][0]["message"]["content"], "latency": elapsed, "usage": data.get("usage", {}), } def run_evaluation(test_cases, model_config): results = [] for case in test_cases: try: result = call_model(model_config, case["prompt"]) results.append({ "case_id": case["id"], "category": case.get("category", ""), "output": result["output"], "latency": result["latency"], "usage": result["usage"], "error": None, }) except Exception as exc: results.append({ "case_id": case["id"], "category": case.get("category", ""), "output": None, "latency": None, "usage": None, "error": str(exc), }) return results def load_jsonl(path): with open(path, "r", encoding="utf-8") as fp: return [json.loads(line) for line in fp if line.strip()] if __name__ == "__main__": parser = argparse.ArgumentParser(description="LLM minimal evaluator") parser.add_argument("--test-file", required=True) parser.add_argument("--model-name", required=True) parser.add_argument("--base-url", default="https://api.example.com/v1") parser.add_argument("--api-key", default=os.environ.get("LLM_API_KEY", "")) parser.add_argument("--output", default="result.jsonl") args = parser.parse_args() test_cases = load_jsonl(args.test_file) model_config = { "api_key": args.api_key, "base_url": args.base_url, "model_name": args.model_name, } results = run_evaluation(test_cases, model_config) with open(args.output, "w", encoding="utf-8") as fp: for item in results: fp.write(json.dumps(item, ensure_ascii=False) + "\n")

使用方式示例：

export LLM_API_KEY="your-api-key" python evaluate.py \ --test-file tests.jsonl \ --model-name your-model-name \ --base-url "https://your-endpoint/v1" \ --output result_your-model-name.jsonl

脚本里有几个关键点。temperature 固定为 0.0，是为了减少随机性；请求设置了 120 秒超时，避免长文本生成或网络异常卡住整个流程；所有异常都被捕获并写入 error 字段，而不是中断脚本，这样一轮跑完能一次性看到哪些题目失败。

2.3 评测数据组织与元数据记录

测试集用 JSONL 组织，每一行是一道题：

{"id": "reasoning_001", "category": "reasoning", "prompt": "数列前五项是 2, 5, 10, 17, 26，请写出第六项并简要说明规律。", "reference": "37", "type": "closed"}

字段含义最好固定：id 是题目唯一标识，category 用于按维度统计，prompt 是实际发给模型的提示词，reference 是参考答案，type 标记是客观题还是主观题。

除了测试集，还建议为每次评测生成一份元数据文件，记录模型名称、模型快照或发布日期、API base url、temperature、测试集版本、脚本版本、评测时间。没有这些信息，三个月后再看 result.jsonl，很难判断分数对应的是哪个版本的模型。一个简单的 meta.json 可以是：

{ "model_name": "your-model-name", "model_release_date": "2026-01-15", "base_url": "https://your-endpoint/v1", "temperature": 0.0, "max_tokens": 1024, "test_set_version": "2025-12-01", "script_version": "0.1.0", "evaluation_date": "2026-02-01" }

3. 评测维度怎么定：推理、代码、长文本三大核心能力

3.1 推理能力评测

推理能力评测的核心，是观察模型能否基于已知信息得出正确的中间结论和最终结论。常见题型包括数学计算、逻辑推理、反事实推理和复杂任务分解。

客观题可以直接比对答案，但对模型输出要做归一化处理，比如去除多余空格、统一数字格式、把中文数字转成阿拉伯数字。主观题需要提前写好评分标准，例如“正确性 0 到 3 分、完整性 0 到 2 分、格式 0 到 1 分”，由至少两人独立评分后取平均，降低个人偏好对结果的影响。

3.2 代码能力评测

代码能力评测最有价值的部分是“执行验证”。让模型生成一段可运行代码，在沙箱里执行，用单元测试判断是否通过。只看代码“像不像样”没有意义，必须看执行结果。

下面是一个极简的 Python 代码执行函数：

import os import subprocess import tempfile def execute_python(code: str, timeout: int = 10): with tempfile.NamedTemporaryFile( "w", suffix=".py", delete=False, encoding="utf-8" ) as fp: fp.write(code) path = fp.name try: result = subprocess.run( ["python", path], capture_output=True, text=True, timeout=timeout, env={**os.environ, "PYTHONDONTWRITEBYTECODE": "1"}, ) return result.returncode, result.stdout, result.stderr finally: os.unlink(path)

这个函数把模型生成的代码写入临时文件，在子进程里执行并设置超时，防止死循环拖垮评测机。在学习环境或本地调试时可以临时使用；生产环境的代码评测不建议在本机直接跑，应当放入 Docker 容器或独立沙箱，并限制 CPU、内存、网络和磁盘权限。

注意：执行模型生成的代码必须在沙箱中完成。本地直接运行不可信代码，可能带来环境和数据风险。

3.3 长文本与信息密度评测

长文本能力评测要验证两件事：模型能否“看完”长文本，以及看完之后能否准确找到并整合信息。常见做法是大海捞针测试：在长文档中插入一句关键信息，再让模型回答相关问题，看它能否找到那句话。另一种做法是让模型基于长文档生成摘要，再人工检查摘要是否忠实于原文，是否编造了原文不存在的细节。

评测长文本时，要把输入长度分成几个档位，例如 4K、16K、32K、64K，分别记录成功率和准确率。只测一个长度不能反映真实水平，因为模型在短文本上稳定，不代表在超长文本上也能稳定。

4. 横向与纵向对比：怎么整理一年的变化

4.1 纵向：同一模型家族不同版本

一年回顾最常见做法，是把某个模型家族一年前发布的版本和当前版本放在同一批测试题上对比。这里最常见的错误是只保留当前分数，忘记保存旧版本的输出。如果当时没有保存，一年后可能面临一个尴尬局面：旧版本已经下线或无法通过 API 访问，想补跑也来不及。

推荐做法是给每次评测建立一个快照目录：

evaluation/ 2025-01-model-v1/ tests.jsonl meta.json result.jsonl 2026-01-model-v2/ tests.jsonl meta.json result.jsonl

目录里的 tests.jsonl 必须保持核心题目不变；meta.json 记录模型版本和运行环境；result.jsonl 保存原始输出。只有保留这些历史数据，一年之后才能判断能力变化的方向和幅度。

4.2 横向：不同模型家族

横向对比是在同一批测试题上调用不同模型家族的 API。需要注意，不同模型的上下文窗口、输出 token 上限、价格和限流策略都不同。评测时要尽量把 max_tokens 设置成相同值，否则输出长度会直接影响分数，尤其影响代码题和长文本题。

同时，不同厂商的 API 对超时、重试、并发限制的处理方式不同。评测脚本要加入失败重试和限速机制，否则很容易在某个模型上因为限流出现大量 error 记录，导致有效样本不足，最终统计失真。

4.3 把成本和延迟纳入对比

“能力飞跃”不应该只谈分数。模型一年间的升级，往往伴随着更高的计算成本和更复杂的部署要求。工程选型时，分数高但成本翻倍的模型需要单独评估性价比。建议每次都记录效果、延迟和费用三类数据：

这张表强调的不是某一列的数字，而是评测时至少同时记录效果、延迟和费用，只记录得分会在做生产决策时缺少关键输入。

5. 评测结果判读与常见坑排查：分数差多少才算真差距

5.1 分数差距多大才算真的差距

当测试集只有 20 道题时，模型 A 得 15 分、模型 B 得 16 分，并不能稳定说明 B 更强。题目本身存在抽样误差，单次运行还存在随机性。建议至少准备 50 道以上的核心测试题，并且每个模型跑 2 到 3 轮，观察分数区间。如果模型自己两次运行的分数波动已经大于两个模型的差距，就不能下结论。

比较保守的判断标准是：分数差距明显超过同模型多次运行的波动区间时，才认为存在真实差异。更严格的做法是使用统计检验，但统计检验要求题目独立、同分布，实际评测中往往很难完全满足，因此不要盲目依赖 p 值。

5.2 高频问题排查

常见评测问题可以通过下表快速定位：