一年时间放在传统软件技术栈里通常只够完成一两个版本迭代放在大模型生态里却足够让多个主流模型家族完成一轮甚至几轮能力升级。“三大模型一年间能力飞跃”这类话题很多人是靠发布会演示、社交媒体片段和排行榜截图建立印象的这些信息适合用来形成直觉不适合直接支撑工程决策。至于具体是哪三个模型不同阶段、不同统计口径下的答案并不一样与其争论名单不如把注意力放在一个更实际的问题上如何判断一个模型家族在过去一年里到底变强了多少。真正需要回答的包括具体在推理、代码、长文本等维度提升了多少提升点在哪里有没有以牺牲其他能力为代价以及回到自己的业务场景中这种提升能否转化为可衡量的收益。要回答这些问题不能停留在看榜而是要把模型评测变成一套可重复、可量化、可追溯的工程流程。下面从评测认知开始逐步搭出一套可用到实际项目的评测流程。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 为例推荐配置如下项目推荐配置说明Python3.10 及以上类型标注和标准库支持更完整依赖包requests、官方 SDK优先使用官方 SDK兼容性更好API Key每个模型家族各一份用环境变量注入不要写进代码测试集JSONL 格式便于逐行读取、增量追加执行沙箱Docker 或独立子进程用于执行模型生成的代码需要注意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, temperature0.0, max_tokens1024): headers { Authorization: fBearer {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, headersheaders, jsonpayload, timeout120, ) 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, encodingutf-8) as fp: return [json.loads(line) for line in fp if line.strip()] if __name__ __main__: parser argparse.ArgumentParser(descriptionLLM minimal evaluator) parser.add_argument(--test-file, requiredTrue) parser.add_argument(--model-name, requiredTrue) parser.add_argument(--base-url, defaulthttps://api.example.com/v1) parser.add_argument(--api-key, defaultos.environ.get(LLM_API_KEY, )) parser.add_argument(--output, defaultresult.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, encodingutf-8) as fp: for item in results: fp.write(json.dumps(item, ensure_asciiFalse) \n)使用方式示例export LLM_API_KEYyour-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, deleteFalse, encodingutf-8 ) as fp: fp.write(code) path fp.name try: result subprocess.run( [python, path], capture_outputTrue, textTrue, timeouttimeout, 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 把成本和延迟纳入对比“能力飞跃”不应该只谈分数。模型一年间的升级往往伴随着更高的计算成本和更复杂的部署要求。工程选型时分数高但成本翻倍的模型需要单独评估性价比。建议每次都记录效果、延迟和费用三类数据对比维度一年前模型快照当前模型快照推理平均分记录实际值记录实际值代码执行通过率记录实际值记录实际值平均首 token 延迟记录实际值记录实际值每千请求费用记录实际值记录实际值上下文窗口记录实际值记录实际值这张表强调的不是某一列的数字而是评测时至少同时记录效果、延迟和费用只记录得分会在做生产决策时缺少关键输入。5. 评测结果判读与常见坑排查分数差多少才算真差距5.1 分数差距多大才算真的差距当测试集只有 20 道题时模型 A 得 15 分、模型 B 得 16 分并不能稳定说明 B 更强。题目本身存在抽样误差单次运行还存在随机性。建议至少准备 50 道以上的核心测试题并且每个模型跑 2 到 3 轮观察分数区间。如果模型自己两次运行的分数波动已经大于两个模型的差距就不能下结论。比较保守的判断标准是分数差距明显超过同模型多次运行的波动区间时才认为存在真实差异。更严格的做法是使用统计检验但统计检验要求题目独立、同分布实际评测中往往很难完全满足因此不要盲目依赖 p 值。5.2 高频问题排查常见评测问题可以通过下表快速定位问题现象可能原因检查方式处理建议 科学量化大模型能力提升：构建可复现的评测流程
一年时间放在传统软件技术栈里通常只够完成一两个版本迭代放在大模型生态里却足够让多个主流模型家族完成一轮甚至几轮能力升级。“三大模型一年间能力飞跃”这类话题很多人是靠发布会演示、社交媒体片段和排行榜截图建立印象的这些信息适合用来形成直觉不适合直接支撑工程决策。至于具体是哪三个模型不同阶段、不同统计口径下的答案并不一样与其争论名单不如把注意力放在一个更实际的问题上如何判断一个模型家族在过去一年里到底变强了多少。真正需要回答的包括具体在推理、代码、长文本等维度提升了多少提升点在哪里有没有以牺牲其他能力为代价以及回到自己的业务场景中这种提升能否转化为可衡量的收益。要回答这些问题不能停留在看榜而是要把模型评测变成一套可重复、可量化、可追溯的工程流程。下面从评测认知开始逐步搭出一套可用到实际项目的评测流程。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 为例推荐配置如下项目推荐配置说明Python3.10 及以上类型标注和标准库支持更完整依赖包requests、官方 SDK优先使用官方 SDK兼容性更好API Key每个模型家族各一份用环境变量注入不要写进代码测试集JSONL 格式便于逐行读取、增量追加执行沙箱Docker 或独立子进程用于执行模型生成的代码需要注意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, temperature0.0, max_tokens1024): headers { Authorization: fBearer {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, headersheaders, jsonpayload, timeout120, ) 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, encodingutf-8) as fp: return [json.loads(line) for line in fp if line.strip()] if __name__ __main__: parser argparse.ArgumentParser(descriptionLLM minimal evaluator) parser.add_argument(--test-file, requiredTrue) parser.add_argument(--model-name, requiredTrue) parser.add_argument(--base-url, defaulthttps://api.example.com/v1) parser.add_argument(--api-key, defaultos.environ.get(LLM_API_KEY, )) parser.add_argument(--output, defaultresult.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, encodingutf-8) as fp: for item in results: fp.write(json.dumps(item, ensure_asciiFalse) \n)使用方式示例export LLM_API_KEYyour-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, deleteFalse, encodingutf-8 ) as fp: fp.write(code) path fp.name try: result subprocess.run( [python, path], capture_outputTrue, textTrue, timeouttimeout, 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 把成本和延迟纳入对比“能力飞跃”不应该只谈分数。模型一年间的升级往往伴随着更高的计算成本和更复杂的部署要求。工程选型时分数高但成本翻倍的模型需要单独评估性价比。建议每次都记录效果、延迟和费用三类数据对比维度一年前模型快照当前模型快照推理平均分记录实际值记录实际值代码执行通过率记录实际值记录实际值平均首 token 延迟记录实际值记录实际值每千请求费用记录实际值记录实际值上下文窗口记录实际值记录实际值这张表强调的不是某一列的数字而是评测时至少同时记录效果、延迟和费用只记录得分会在做生产决策时缺少关键输入。5. 评测结果判读与常见坑排查分数差多少才算真差距5.1 分数差距多大才算真的差距当测试集只有 20 道题时模型 A 得 15 分、模型 B 得 16 分并不能稳定说明 B 更强。题目本身存在抽样误差单次运行还存在随机性。建议至少准备 50 道以上的核心测试题并且每个模型跑 2 到 3 轮观察分数区间。如果模型自己两次运行的分数波动已经大于两个模型的差距就不能下结论。比较保守的判断标准是分数差距明显超过同模型多次运行的波动区间时才认为存在真实差异。更严格的做法是使用统计检验但统计检验要求题目独立、同分布实际评测中往往很难完全满足因此不要盲目依赖 p 值。5.2 高频问题排查常见评测问题可以通过下表快速定位问题现象可能原因检查方式处理建议