最近技术社区里出现了一个挺值得关注的实验标题I gave Claudes Reimann paper to GPT-5.6-Sol Pro. Its now 67.30%。乍看之下这像是两个模型之间的一次“能力对决”有人把 Claude 相关的一篇论文作为测试材料交给 GPT-5.6-Sol Pro 去处理最后得到了一个 67.30% 的分数。这类内容传播速度很快也很容易在评论区吵起来到底谁更强新模型是不是已经超过了旧模型如果只看这个数字其实很难得出任何可靠结论。67.30% 是一个被剥离了上下文的分数评测集多大、题目是什么、判分标准是什么、模型跑了几次、用了什么采样参数这些关键信息全部缺失。没有这些上下文它只能代表一次运行记录不能代表模型能力。这篇文章想做的正是把这类“模型评测实验”拆开来看当你把一份论文、一份文档或一段代码交给不同模型时怎样设计实验才科学怎样解读分数才不误导自己以及如何用一套可复现的流程去回答“这个模型在我关心的任务上到底行不行”。围绕这个目标我会从评测基础概念讲起然后给出一个最小可复现的跨模型评测实验设计包含数据格式、Python 脚本和运行命令。之后会重点分析 67.30% 这类分数的解读边界并结合近期热门的 Claude Code 这类命令行 Agent 工具讨论模型选型和评测思维如何落到真实开发流程中。如果你是技术选型负责人、AI 应用开发者或者只是经常被各种“模型分数”刷屏的工程师这篇文章应该能帮你建立一套更稳的判断框架。1. 为什么单个分数很难说明模型强弱先做一个类比。一个学生某次考试拿了 67 分你能判断他学习好不好吗不能。你至少需要知道满分是多少、试卷难度如何、班级平均分是多少、这次考试是简单单元测还是选拔性考试。模型评测也是一样的道理。67.30% 这个分数只有当它被放进完整的实验上下文里才有讨论价值。模型评测里最容易犯的错误就是“一题定强弱”或者“一次运行定输赢”。很多时候大家只是把同一段文本丢给两个模型然后比较回答的“感觉”。这种比较有参考意义但很难作为决策依据。原因至少有四个第一模型输出具有随机性。即便把温度调到 0不同批次的推理也可能因为算子实现、上下文长度、量化方式等因素产生差异。第二单次运行的样本量通常不够。如果评测集只有 20 道题多答对一道题正确率就波动 5 个百分点这个波动可能比模型之间的真实差距还大。第三评测任务的难度没有校准。如果题目全部是“11 等于几”两个模型都能拿 100 分这个分数没有区分度如果题目全部是前沿数学难题所有模型都接近 0 分同样没有区分度。第四判分标准可能不一致。有的实验用规则匹配判分有的用另一个模型判分有的靠人工打分不同方式产生的分数不能直接对比。所以如果你想认真评估一个模型第一步不是打开聊天窗口输入问题而是先定义清楚评测集是什么、任务是什么、指标是什么、判定方法是什么、基线和对照组是什么。这篇文章稍后会给你一套最小实现让这些步骤可以落地。2. 用论文做评测Reimann 场景为什么有挑战标题里的 Reimann 有一个细节值得先说清楚它大概率是 Riemann 的拼写偏差。Riemann 是德国数学家黎曼的姓氏经常出现在“黎曼猜想”“黎曼积分”“黎曼几何”等数学概念中。如果你搜索时用了 Reimann很容易把结果引到其他真实存在的人名或地名上这在做论文检索和评测数据整理时是个实际坑。那为什么有人会把这样一篇论文作为评测材料因为数学研究论文恰好能同时考察模型的多种能力长上下文理解论文通常有几十页包含大量定理、引理、定义和证明模型需要保持对前文信息的记忆。公式与符号理解数学论文充满 LaTeX 公式和特殊符号模型要能“读懂”符号之间的推导关系。逻辑链复现一个定理的证明往往依赖前面多个结论模型需要跟踪多步逻辑链条。知识召回论文常常引用已有理论模型具备的领域知识会影响它能否理解这些引用。抽象归纳读完论文后能否提炼出核心贡献、方法和局限是更深层次的理解能力。从这个角度看用一篇论文当评测语料比用一句常识问答要更能拉开模型之间的差距。但也要注意正因为论文类任务复杂评测结果的波动也会更大。同样一篇论文问题设计得偏一点分数可能从 80% 掉到 60%判分标准严格一点分数又会变化。这说明使用论文做评测时评测集的设计和判分标准必须同步公开否则分数不具备可比性。另外需要区分一下这篇“Reimann paper”到底是 Claude 模型生成的文档还是研究者写的关于黎曼主题的论文从标题字面无法确定。不过无论来源如何将一篇内容密度高、引用关系复杂的文档作为评测输入本身是一个合理的评测思路。关键不在于这篇论文选得好不好而在于围绕它的评测流程是否完整。3. 大模型评测的基础概念与常见指标在进入实操之前先把几个基础术语对齐一下。评测集Dataset一组输入和期望输出的集合通常包含“输入文本 标准答案/评分标准”。例如你可以准备 50 道数学题、20 篇文档问答或 30 个代码修复任务。任务类型Task Type模型要完成的行为类型。常见的有分类任务从给定选项中选择一个答案例如情感分类、意图识别。抽取任务从原文中抽取实体或关键句例如信息抽取、摘要抽取。生成任务自由生成文本例如论文问答、代码生成、文案创作。推理任务需要多步逻辑推导例如数学证明、程序执行结果预测。指标Metric对模型输出打分的计算方法。不同任务适合不同指标。指标适用任务含义说明Accuracy分类、问答正确结果占总数的比例最直观但类别不平衡时会失真F1信息抽取、检索精确率和召回率的调和平均衡量“抓得准”和“抓得全”的平衡Rouge摘要生成生成文本与参考文本的重叠程度适合评测摘要、翻译但语义理解有限BLEU翻译生成n-gram 匹配的加权统计老牌指标与人工评判相关性有限PassK代码生成K 次生成中至少一次通过测试的比例解决生成类任务单次成功率低的问题人工评分综合任务由人按标准打分主观但更接近真实质量成本高回到 67.30% 这个数字它可能是 Accuracy也可能是某个平台给出的综合分。不同指标含义完全不同不能混为一谈。如果标题里的实验用的是“正确回答了多少道题”这样的口径那么 67.30% 可以理解为在这个评测集上模型回答对了约三分之二的问题。这个水平到底算好还是不好取决于评测集的难度分布和基线分数。再补充一个概念基线Baseline。没有基线分数就没有参照。常见基线有随机猜测多选 4 选项随机猜正确率约 25%、多数类预测全部猜最频繁答案、规则模型、上一代模型或人工表现。如果评测集是四选一的选择题67.30% 已经远高于随机水平如果评测集是二选一那么 67.30% 的优势就被压缩了。所以下次看到一个分数时第一反应应当是基线是多少样本量多大指标怎么算4. 一个最小可复现的跨模型评测实验设计理解了基本概念我们来看实战。假设你想复现标题里的实验将同一篇文档交给另一个模型让它基于文档回答问题最终计算一个准确率分数。这里我会给出一套可以在本地运行的最小实验框架重点演示思路不绑定任何厂商的 SDK。一个完整的最小评测实验包含五个环节准备好评测集也就是文档和问题。调用被评测模型让它基于文档生成答案。对模型答案进行判分。计算汇总分数。记录实验参数确保可复现。4.1 准备评测集评测集建议采用 JSONL 格式每行一个 JSON 对象包含文档内容、问题列表和参考答案。参考答案可以用于构建自动判分规则。{ id: math-001, document: 这里放入论文正文或摘要。实际使用时建议先用脚本把 PDF 或 Markdown 文本抽取出来。, questions: [ { question: 论文提出的核心问题是什么, reference: 核心问题与黎曼函数的零点分布相关 }, { question: 第三节使用的证明策略是什么, reference: 使用了反证法与渐近估计 } ] }将这样的数据保存为math_eval.jsonl。使用 JSONL 而不是 JSON 数组好处是每一行可以独立解析当评测集较大时可以逐行流式读取也方便后续与数据版本管理工具配合。如果你的原始文档是 PDF需要先用工具把文本抽取出来。常见做法是使用 Python 的pdfplumber或PyMuPDF把每一页文本按顺序提取并拼接。注意数学公式在 PDF 转文本过程中容易乱码实际项目里要检查抽取结果必要时使用保留 LaTeX 源码的原始文档。4.2 编写评测脚本下面是一个评测脚本示例它使用 OpenAI 兼容的 Chat Completions 接口来调用模型。这是目前很多模型服务商都兼容的接口格式方便你在不同模型之间切换。# 文件路径eval_runner.py 跨模型评测最小脚本示意版本 注意模型名称、请求参数请以你自己的模型服务商文档为准。 import json import os from openai import OpenAI # 初始化客户端 # 请使用合法合规的 API 服务地址和密钥 client OpenAI( api_keyos.environ.get(MODEL_API_KEY, your-valid-api-key), base_urlos.environ.get(MODEL_API_BASE, https://api.example.com/v1), ) def generate_answer(document: str, question: str, model_name: str) - str: 让模型基于给定文档回答问题。 response client.chat.completions.create( modelmodel_name, temperature0.0, max_tokens1024, messages[ { role: system, content: 你是一名严谨的研究者。请根据给定论文内容回答问题不要编造原文不存在的信息。, }, { role: user, content: f论文内容\n{document}\n\n问题{question}, }, ], ) return response.choices[0].message.content def score_answer(answer: str, reference: str) - float: 判分函数示意。 这里只实现了一个极简规则用于演示流程。 实际项目建议使用三类判分方式之一 1. 人工判分标注规范清晰结果最可信。 2. 裁判模型判分用另一个模型按评分标准打分。 3. 规则判分关键词匹配、向量相似度、代码测试用例等。 answer_norm answer.strip().lower() reference_norm reference.strip().lower() # 简单示例参考答案中的关键词是否出现在模型答案中 # 注意真实评测不能依赖这么简单的规则这里仅演示。 keywords [k for k in reference_norm.split(与) if k] matched sum(1 for k in keywords if k and k in answer_norm) return matched / max(len(keywords), 1) def main() - None: dataset_path math_eval.jsonl model_name demo-model-name tasks [] with open(dataset_path, r, encodingutf-8) as f: for line in f: line line.strip() if line: tasks.append(json.loads(line)) total_score 0.0 total_questions 0 for task in tasks: document task[document] for q in task[questions]: answer generate_answer(document, q[question], model_name) score score_answer(answer, q[reference]) total_score score total_questions 1 print(f任务 {task[id]} 问题得分{score:.2f}) final_score total_score / max(total_questions, 1) print(f模型 {model_name} 最终得分{final_score * 100:.2f}%) if __name__ __main__: main()这段脚本的三个关键点第一温度设置为 0.0 是评测的默认做法能尽量降低采样随机性。但注意即便 temperature0不同推理后端和不同版本仍然可能产生微小差异。第二max_tokens 要足够长避免模型因为输出长度截断而答不完整。第三判分函数写成什么直接决定最终分数。示例里的关键词匹配只是一个演示真实评测不建议单独使用。4.3 使用 YAML 管理实验配置评测实验需要记录的参数很多建议把配置和代码分离。下面是一个 YAML 配置示例# 文件路径eval_config.yaml dataset: path: ./math_eval.jsonl model: name: demo-model-name temperature: 0.0 max_tokens: 1024 judge: mode: reference # reference: 规则判分, llm: 裁判模型, human: 人工评分 metric: accuracy repeat: times: 3 seed: 42这里的repeat.times表示同样的实验建议重复运行多次取平均值作为最终结果。大模型评测天然带有波动性重复运行是成本最低的可靠性提升手段。4.4 运行评测准备好上述文件后在终端执行# 设置模型服务地址和密钥 export MODEL_API_KEYyour-valid-api-key export MODEL_API_BASEhttps://api.example.com/v1 # 运行评测 python eval_runner.py如果一切正常你会看到类似下面的输出任务 math-001 问题得分1.00 任务 math-001 问题得分0.50 模型 demo-model-name 最终得分75.00%这里只是一个演示结果。真实评测中你可能会发现同一模型在不同问题上的得分差异很大这正是评测集的价值暴露模型的短板所在。4.5 如何判断实验是否成功判断评测实验是否有效不能只看最终分数。你要检查三件事模型是否真正“读”了文档可以设计几个“文档必须包含信息才能回答”的问题如果模型在不看文档的情况下也能答对说明问题设计有问题。判分是否稳定随机抽取 20 个模型答案让两个人独立打分对比结果。实验是否可复现隔一天再用相同配置跑一遍分数是否在合理范围内。如果三步都通过这个评测流程才能算“可信”。5. 67.30% 应该怎么解读现在我们把话题拉回开头的 67.30%。假设这个分数来自一次合理的评测样本量、模型版本、判分方式都已知那么它仍然需要放在几个维度里看。第一个维度是基线。如果评测集是四选一选择题随机基线是 25%那么 67.30% 属于远高于随机水平的成绩。如果评测集是二选一判断题随机基线是 50%67.30% 的优势就小很多。更严格的做法是引入一个“上一代模型”或者“规则模型”作为对照看提升幅度是否显著。第二个维度是样本量。统计学常识告诉我们样本量越小分数波动越大。如果评测集只有 20 题多对一题就让分数从 65% 跳到 70%。这种情况下67.30% 和 68% 之间的差异没有统计意义。更稳妥的做法是报告 95% 置信区间或者至少说明“在 N 道题上正确率为 67.30%”。第三个维度是采样参数。模型 API 调用中的 temperature、top_p、seed 等参数会影响输出分布。评测报告必须注明这些参数否则其他人无法复现。理想情况下固定 temperature0并记录模型版本号。第四个维度是判分方式。同一个模型答案用关键词匹配、裁判模型打分和人工打分得到的结果可能差异很大。所以你在任何地方看到一个“XX%”的模型分数第一件事是问这个分数是怎么算出来的谁来判断模型输出是否合格综合来看67.30% 更像是一个“实验快照”记录了某个模型在某份文档、某组问题、某个判分规则下的一次表现。它可以作为一个参考点但在没有完整实验报告的情况下它不足以支撑“某模型强于某模型”的结论。真正有价值的是基于同一评测流程在相同条件下跑多个模型比较分数差异并且把评测集、参数、版本全部公开。6. 从模型评测到实际开发工具选型聊完评测我们回到开发者的真实场景。近期 Claude Code 这类命令行 Agent 工具讨论度很高周围很多工程师在尝试把大模型接入编码工作流。从热词里可以看到大量关于 Claude Code 安装、配置、报错的问题比如“claude 不是内部或外部命令”“error: claude native binary not installed”等。这些问题背后其实隐藏着一个和模型评测相关的点不同的底层模型在真实工具链里的表现差异是评测分数很难完全反映的。6.1 命令行 Agent 为什么会放大模型差异传统聊天式使用大模型时模型只需要“说对话”。但在 Agent 工具里模型需要执行工具调用、读写文件、运行命令、观察报错、修改代码。这个流程对模型的要求更高指令遵循能不能严格按照用户指令执行而不是自由发挥。多步规划当任务很复杂时能不能拆成多个步骤。上下文管理长时间工作后会不会忘记最初目标。工具调用准确率调用的函数名、参数格式是否正确。自我纠错命令执行失败后能不能根据错误信息调整方案。这些能力很难用单一分数概括。因此如果你正在为团队选择 Agent 编程工具建议不要只看官网分数而是用自己团队的真实代码任务做一轮小规模评测。这里的思路和第 4 节的实验设计完全一致准备 10 到 20 个真实开发任务在相同提示词下用不同模型分别执行记录“任务完成率”“平均耗时”“是否需要人工介入”。6.2 Claude Code 安装常见问题排查因为“claude code 安装”“claude 无法识别”这类问题搜索量很高这里给一个通用的排查思路。Claude Code 通常以 Node.js 命令行工具的形式安装安装后需要通过claude命令在终端启动。问题现象可能原因排查方式解决方案提示“claude 不是内部或外部命令”全局安装目录未加入 PATH或安装未成功执行node -v确认 Node 环境执行npm config get prefix查看全局安装目录将全局目录加入 PATH重启终端后重试安装过程中提示权限错误当前用户对全局 node_modules 没有写权限查看错误日志确认命令是否以管理员/root 身份运行使用用户级目录安装或按官方文档配置权限启动后提示缺少认证信息未登录或 API 密钥未配置确认工具文档中的登录流程检查环境变量完成登录注册或设置合法可用的 API 凭据执行任务时反复失败上下文窗口不足、工作区权限限制查看工具输出日志缩小工作区范围清理工作区文件拆分任务为更小步骤需要强调的是具体安装命令请以官方文档为准本文不展开细节。命令行 Agent 类工具变化很快直接参考官方文档是最稳妥的方式。6.3 用评测思维做模型选型结合上面的讨论我建议你建立一个简单的“模型选型评测清单”选定 10 个有代表性的任务覆盖真实业务场景。定义每个任务的“完成标准”尽量量化。固定 prompt 模板不同模型使用相同输入。每个模型跑 3 次记录成功率和人工介入次数。记录模型版本、API 地址、采样参数。这套清单执行起来成本不高但比“感觉 A 模型比 B 模型聪明”要可靠得多。7. 大模型评测常见问题与排查方法为了让你少踩坑我把评测过程中常见的问题整理成一张表。问题现象可能原因排查方式解决方案不同模型跑出来的分数差距不大评测任务太简单或太难区分度不足查看每道题的得分分布分析正确率是否集中在 0% 或 100%调整题目难度加入更多中等难度任务同一模型两次运行分数波动大采样参数未固定或评测集样本量太小检查 temperature、top_p、随机种子统计题目数量固定 temperature0增大样本量重复运行取均值模型没有真正使用提供的文档提示词没有强调必须基于文档回答或模型直接调用预训练知识检查答案中是否包含文档独有信息修改 system prompt加入“只能根据给定内容回答”的约束规则判分结果与人工判断差异大关键词匹配太机械无法处理语义等价表达人工抽查一批答案对比规则判分和人工评分改用裁判模型判分或把规则设计得更细致评测集数据可能已经被模型训练过公开 benchmark 数据被收录到训练语料检查数据发布时间与模型训练截止日期使用私有数据或较新的数据构造评测集长文档被截断模型答非所问上下文窗口不足或分段策略不合理查看文档字符数和上下文窗口上限切换更长上下文的模型或实现分段检索API 请求限流评测跑不完并发请求过多超过服务配额查看 API 限流返回码和配额增加退避重试控制并发数降低请求频率多个模型服务商的输出格式不一致不同厂商的 API schema 和参数名不同查看各厂商文档对比请求和响应结构封装统一接口适配层屏蔽底层差异以上这些问题几乎是每次做模型评测都会遇到的。提前了解能省下大量调试时间。8. 最佳实践把评测做成团队基础设施如果你不只是想跑一次实验而是希望团队长期、稳定地评估模型能力建议把评测流程升级成基础设施。下面几条实践来自我见过的很多项目经验你可以按需采纳。第一版本锁三件套。模型版本、评测集版本、评测脚本版本必须同时记录。很多团队评测结果对不上最后发现是模型悄悄升级了或者评测集文件被改动过。建议使用 Git 管理评测集和脚本发布评测报告时写明 commit hash。第二固定随机性。虽然 temperature0 不能完全消除随机性但它是默认基线。如果业务场景需要更高创造性可以额外记录一组“创造性参数”而不是让评测时温度保持随机。第三判分器要独立。如果你用另一个模型做判分判分模型也要固定版本并使用与生成模型不同的采样参数。否则你测出来的可能不是“模型 A 的生成能力”而是“判分模型 B 对模型 A 输出的偏好”。第四保护评测集。公开 benchmark 数据容易受到污染建议维护一部分私有评测集例如从团队真实业务数据中脱敏构造的任务。这类评测集更能反映实际效果也能避免“刷分”问题。第五报告置信度。不要只报告一个均值还要报告样本量、标准差、置信区间。样本量不足 100 时报告“x 题中正确率为 67.30%”比只写“67.30%”要严谨得多。第六评测失败也要记录。模型在某些题目上为什么失败往往比总分更有价值。建议每次评测都输出一份失败案例分析把模型答案和参考答案放在一起对比。如果团队条件允许还可以把这些流程封装成一个简单的评测平台支持上传数据集、选择模型、运行评测、生成报告。前期的实现成本不高但长期收益很大因为它能把“模型选型”这个经常靠感觉的决策变成可追溯、可比较的工程流程。9. 总结与后续上手路径现在重新看开头的标题I gave Claudes Reimann paper to GPT-5.6-Sol Pro. Its now 67.30%。你应该已经清楚这个分数本身说明不了太多它取决于评测集、模型版本、采样参数和判分方式。但这类实验仍然有价值因为它提醒我们大模型能力需要被系统性地验证而不是靠碎片化传播的分数来证明。如果你想马上实践我建议按这个路径走一遍收集 20 道与业务相关的题目组成一个小型评测集。使用第 4 节的脚本跑通“读取文档 → 生成回答 → 判分 → 输出分数”的流程。固定模型版本和 temperature重复运行 3 次记录分数波动。把评测集、脚本、参数和结果一起存档形成你的第一份模型评测报告。下一次看到任何模型的“XX%”分数时先检查它的评测条件再决定是否采纳。关于后续学习你可以继续深入三个方向评测集构建方法比如如何设计高质量问题判分方法比如裁判模型评分和人工评分规范以及 Agent 工作流评测比如如何衡量工具调用正确率和任务完成率。这几个方向都值得单独写代码和文档沉淀。最后提醒一句模型迭代速度很快今天你觉得可靠的分数可能在下个月就失效。与其追逐某个具体版本的名次不如建立一套能随时重新跑的评测流水线。让自己拥有“评测能力”远比记住“某个模型的分数”更重要。