最近在技术社区里Opus 5 和 GPT-5.6 这两个新一代大模型版本被反复放在一起讨论。很多评测都集中在“谁能调用更多工具”“谁能更快接上外部 API”上但有一个更朴素的评测角度反而容易被人忽略禁掉所有外部工具后只靠模型自身参数里的知识和推理能力两者的真实差距到底在哪里。本文不打算抛出某个榜单结论而是想把“无工具场景下的大模型对比评测”这套方法论完整拆开讲清楚评测维度、脚本设计、结果分析和容易踩的坑帮助你以后自己也能复现一套可信的模型对比实验。1. 背景为什么“禁掉工具”才能看出真实水平大模型厂商在宣传新版本时通常会强调工具调用、联网搜索、代码解释器这类增强能力。工具调用确实能大幅扩展模型的使用边界但它也会在无意中掩盖模型本身的一部分短板。比如一个模型在数学题上表现不佳但如果允许它调用 Python 代码解释器它就能借助外部计算能力得到正确答案这时候评测结果更像是“模型接入工具链的能力”而不是“模型自身的数学推理能力”。把工具全部禁掉之后模型必须在没有外部辅助的条件下完成推理、计算、记忆和输出。这个场景更接近模型在离线环境下的真实基线水平也更能反映出训练数据质量、模型规模、对齐策略和推理能力的综合结果。1.1 工具调用与纯文本推理的本质区别工具调用的典型工作流是模型在生成过程中识别出“我需要搜索”或“我需要执行一段代码”然后输出一个结构化调用请求由外部系统执行后把结果返回给模型模型再把结果组织成语义连贯的最终回复。在这个链路中模型并不需要真的擅长计算它只需要擅长“判断何时调用工具”和“解读工具返回结果”。纯文本推理则是完全不同的能力维度。模型只能根据上下文、自身参数知识和内部思维链来生成内容没有外部兜底。这更接近一个“裸考”场景考察的是模型在预训练阶段积累的知识图谱、注意力机制对长程依赖的建模能力以及强化学习阶段对齐后的推理稳定性。1.2 为什么工程评估中需要关注“无工具”指标在实际业务项目中并不是所有场景都适合引入工具调用。有些企业内部 API 没有对外开放、部分数据不能通过联网获取还有一些高并发场景为了控制成本和延迟会直接关闭工具调用功能。此时无工具能力的强弱直接决定了模型在真实业务中的最低可用水平。如果两个模型都开启工具时表现相近而禁掉工具后差距明显加大这通常说明两者在“基础推理能力”上存在结构性差异。对于要长期基于模型做业务开发的团队来说基础能力比临时的工具增强更值得关注因为基础能力难以通过外挂插件来弥补。2. 大模型对比评估的核心概念在动手跑评测之前有必要先把几个概念理清楚否则很容易得出偏颇的结论。2.1 Benchmark 评测集的局限性目前社区常用的公开基准测试集例如 MMLU、GSM8K、HumanEval、MATH 等确实可以快速反映模型在某一类任务上的表现。但这类数据集存在两个明显问题第一公开数据集容易被训练数据覆盖。如果模型厂商在预训练或后训练阶段见过这些题目评测分数就会虚高不能代表模型在全新问题上的表现。第二静态基准的题目形式比较固定模型厂商可以通过指令微调“刷分”。所以仅凭几个公开 Benchmark 的分数来判断两个新模型的强弱参考价值有限。2.2 “无工具评测”的定义本文所说的“禁掉所有工具”指的是在评测 API 请求中禁用以下能力函数调用 / Tool Calling联网搜索代码解释器图片生成或图片理解等外部视觉工具插件或自定义 Action模型只能接收纯文本输入并输出纯文本回复。如果 API 参数中默认启用了工具需要显式关闭如果模型在无工具模式下仍然能生成代码或中间过程这属于模型自身能力不算外部工具辅助。2.3 客观评测与主观评测客观评测适合判断答案确定的题目例如数学计算、SQL 生成结果比对、信息抽取字段匹配。主观评测则适合考察逻辑自洽性、可读性、创造性等内容。实际评估中建议两者结合客观题用脚本自动打分主观题采用多轮盲评或 LLM-as-Judge 辅助打分。3. 评测环境准备评测环境并不需要很复杂一台普通开发机、两个模型厂商的 API 权限、一个 Python 脚本就够了。下面给出通用建议。3.1 API 接入与模型版本确认不同模型厂商的 API 接口并不完全一致但基本都遵循“请求消息列表 参数配置 返回消息”的交互模型。以 OpenAI 兼容接口和 Anthropic 接口为例两种接入方式的核心差异在于请求体和参数名。需要注意的是Opus 5 和 GPT-5.6 这类当前尚处于快速迭代阶段的模型API 版本和模型别名可能会发生变化。在开始评测前建议先通过各厂商的模型列表接口确认可用的模型 ID并建议在脚本中记录本次评测使用的完整模型版本便于后续复现。示例代码如下import os import requests # 以 OpenAI 兼容接口为例确认当前环境可用的模型 api_key os.environ[OPENAI_API_KEY] base_url os.environ.get(OPENAI_BASE_URL, https://api.openai.com/v1) resp requests.get( f{base_url}/models, headers{Authorization: fBearer {api_key}}, timeout30, ) models resp.json() print([item[id] for item in models[data]][:20])3.2 评测数据集设计原则无工具评测的题目不需要太多但要保证覆盖度。建议准备 50 到 100 道题目每道题包含题目类型。输入文本。参考答案。评分方式精确匹配、关键词匹配、语义匹配。题目应当避免直接照搬公开 Benchmark 的原题建议自己编写或对公开题做大幅改写降低“训练数据泄露”的影响。3.3 编写统一评测脚本为了避免手工测试带来的误差建议写一个评测脚本统一管理请求、重试、超时和结果记录。下面是一个可运行的 Python 脚本骨架采用 OpenAI 兼容接口并默认将 temperature 固定为 0让输出尽量确定性。import json import time import csv import httpx from typing import List, Dict, Optional class ModelEvaluator: def __init__(self, api_key: str, base_url: str, model: str, temperature: float 0.0): self.api_key api_key self.base_url base_url.rstrip(/) self.model model self.temperature temperature self.client httpx.Client(timeout120) def chat(self, messages: List[Dict[str, str]]) - Optional[str]: url f{self.base_url}/chat/completions headers { Authorization: fBearer {self.api_key}, Content-Type: application/json, } # 注意无工具评测不传入 tools 参数 payload { model: self.model, messages: messages, temperature: self.temperature, max_tokens: 512, } try: resp self.client.post(url, jsonpayload, headersheaders) resp.raise_for_status() data resp.json() return data[choices][0][message][content] except Exception as e: print(f请求异常: {e}) return None def run_single(self, question: Dict) - Dict: messages [ {role: system, content: 你是一个严谨的评测助手请直接给出答案不要调用任何外部工具。}, {role: user, content: question[input]}, ] start time.time() output self.chat(messages) elapsed time.time() - start return { question_id: question[id], output: output, elapsed: round(elapsed, 2), } def load_questions(path: str) - List[Dict]: with open(path, r, encodingutf-8) as f: return json.load(f) def save_results(results: List[Dict], path: str) - None: with open(path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这个脚本的思路很简单逐条读取题目调用统一 chat 接口记录模型输出和耗时。所有输出都会写入 JSON 文件后续再用评分脚本做比对。4. 评测维度拆解无工具评测的维度设计决定了最终结论是否可信。下面几个维度是模型核心能力的代表。4.1 数学与计算能力数学题是最能体现“没有外部计算器时模型是否可靠”的题型。建议包含四则运算、百分比换算、线性方程、概率基础题等。题目难度不宜过高要以中等难度为主否则两个模型可能都答不出来无法拉开区分度。示例题一个商品原价 1280 元先降价 15%再提价 10%最后的价格是多少请给出计算过程。评分时既看最终数值是否准确也看计算过程是否合理。这里要特别注意如果模型在无工具模式下写出了中间计算代码这并不是外部工具只是模型内部推理过程的一种表达可以算作有效作答。4.2 代码生成与代码理解代码评测要区分“生成通过的代码”和“代码理解的正确性”。无工具场景下模型无法运行代码因此只能依赖静态推理判断代码是否合法、逻辑是否完整。建议设计两类题目根据自然语言描述生成代码函数。给定一段代码找出其中的 bug 并说明原因。第一类题目用测试用例自动判分第二类题目用人工或 LLM-as-Judge 评定修复方案是否正确。考虑到无工具模式下没有执行环境代码评测要注意语法层面的可运行性而不是追求完整工程的构建成功率。4.3 长文本理解与信息定位长文本理解是模型在真实业务中非常重要的能力。评测时可以准备 3000 到 5000 字的文档要求模型定位特定信息、概括段落主旨、按时间线整理事件。由于没有工具模型无法分段检索或通过向量库增强只能依靠注意力机制对长文本的建模能力。评分时建议既看信息是否准确也看回答是否覆盖多个关键点。长文本评测的误差来源主要是输入截断所以评测前要明确当前模型上下文窗口必要时把输入控制在窗口范围内避免因为截断导致答案不完整。4.4 多步逻辑推理逻辑推理题是拉开模型差距的常见维度。例如条件推理、真假话判断、排列组合问题、故障排查推理等。这类题目无法靠记忆直接回答模型必须把多个条件组合起来推导。示例题A、B、C、D 四个人排成一排。已知 A 不站在第一位 B 的左边只有一个人 C 站在 D 的左边 D 不站在最后一位。 请问可能的排队顺序是什么这种题目没有外部工具可用模型必须借助内部思维链逐步推理。评测时建议要求模型“先写出推理步骤再给出结论”这样能更清楚地观察推理链是否连贯。4.5 指令遵循与格式稳定性无工具评测中格式稳定性往往比语义准确性更容易被忽略。实际业务系统里模型输出需要被程序解析如果格式不稳定调用方就很难做到自动化。建议设计专门的格式题例如“输出一个 JSON包含 name、age、tags 三个字段。”“用 Markdown 表格列出本周的五个阅读要点。”“只输出数字不要解释。”评分时通过解析器或正则校验字段是否完整、格式是否符合要求。这组题可以直接反映出模型在低自由度输出任务上的可控性。5. 完整评测流程示例下面用一个 10 道题的小示例跑通整个流程说明评测脚本、评分逻辑和结果报表如何配合。5.1 准备评测题目创建文件questions.json内容结构如下[ { id: math_001, category: math, input: 一个商品原价 1280 元先降价 15%再提价 10%最后的价格是多少请给出计算过程。, answer: 1196.8, score_type: numeric }, { id: code_001, category: code, input: 请用 Python 写一个函数 is_palindrome(s)判断字符串是否为回文。, answer: def is_palindrome(s): return s s[::-1], score_type: keyword }, { id: logic_001, category: logic, input: A、B、C、D 四个人排成一排。已知A 不站在第一位B 的左边只有一个人C 站在 D 的左边D 不站在最后一位。请问可能的排队顺序是什么请给出推理过程。, answer: BCAD, score_type: keyword } ]这里只列出 3 题作为演示实际评测建议扩充到 50 题以上。题目数量越少偶然性越大。5.2 编写评测运行脚本在上一节的脚本基础上补充一个main入口支持传入模型参数和题目文件路径。def main(): questions load_questions(questions.json) evaluator ModelEvaluator( api_keyYOUR_API_KEY, base_urlhttps://api.openai.com/v1, modelgpt-4.1, # 按实际版本替换 temperature0.0, ) results [] for q in questions: r evaluator.run_single(q) results.append({**q, **r}) print(f已完成 {q[id]}耗时 {r[elapsed]} 秒) time.sleep(1) # 简单限速防止触发限流 save_results(results, results.json) if __name__ __main__: main()运行命令python evaluate.py预期输出是每个题目逐步完成并生成results.json文件。5.3 编写评分脚本评分脚本负责读取模型输出并按题目中的score_type进行判断。数值类题目提取结果中的浮点数关键词类题目做包含匹配存在多种正确表达时建议使用归一化后再匹配。import re import json def normalize_number(value: str) - str: if value is None: return match re.search(r-?\d(?:\.\d)?, value.replace(,, )) return match.group(0) if match else def score_one(question: dict, output: str) - bool: score_type question.get(score_type, keyword) answer question.get(answer, ) if output is None: return False if score_type numeric: return normalize_number(output) normalize_number(answer) if score_type keyword: key answer.strip().lower() return key in output.strip().lower() return False def main(): questions json.load(open(questions.json, encodingutf-8)) results json.load(open(results.json, encodingutf-8)) total len(questions) correct 0 for q, r in zip(questions, results): if score_one(q, r.get(output, )): correct 1 print(f[PASS] {q[id]}) else: print(f[FAIL] {q[id]}) print(f准确率: {correct}/{total} {correct / total:.2%}) if __name__ __main__: main()5.4 结果说明与报表完成评分后建议按category维度做分组统计。这样可以直观看到模型在数学、代码、逻辑、长文本、格式遵循上的差异。如果两个模型总体准确率接近但类别分布差异大说明各自优势领域不同。在真实对比中不要只看一次运行的准确率建议至少跑三轮同一组题目并记录每轮的输出变化。即使 temperature 设置为 0不同 API 版本、不同负载情形下仍可能出现差异。6. 常见问题与排查思路无工具评测过程中常见问题集中在 API 配置、输出不稳定、评分误差和结果复现四个方面。问题现象常见原因解决思路请求返回 401 错误API Key 无效或环境变量未配置检查环境变量和 API Key 是否有效请求超时输入太长或模型推理过慢缩短输入长度增大超时时间输出内容被截断max_tokens 设置过小按题量调大 max_tokens 到 1024 或更大并发请求被限流短时间请求过多增加 sleep 间隔或改用官方异步 SDK 并控制并发数同一个模型两次输出不同API 未设置 temperature 或模型存在采样随机性固定 temperature 为 0多轮取多数结果准确率异常偏低题目答案格式与模型输出格式不匹配检查评分规则先人工抽查 5 条输出再做归一化结果无法复现模型版本发生变动或评测脚本未记录版本在结果 JSON 中记录模型 ID、请求时间和参数在排查过程中最容易被忽视的是“评分脚本的匹配规则”。有些题目模型回答完全正确但因为没有和参考答案保持同一格式导致脚本判错。建议在批量评分前先手动打印 10 条模型输出观察格式规律再决定使用精确匹配还是包含匹配。7. 工程建议与最佳实践基于模型对比评测的工程经验下面几条建议值得留意。第一评测配置要保持一致。对比两个模型时除了模型 ID 之外temperature、max_tokens、top_p、system prompt 必须完全一致。建议把评测配置写入单独配置文件避免手工修改时引入差异。第二固定上下文窗口。不同模型支持的上下文窗口长度不一致如果题目输入超过某一模型的窗口限制就会被截断导致结果不可比。建议统一将长文本题目控制在两个模型都支持的窗口范围内。第三记录完整元数据。每个模型输出都要对应记录模型 ID、API 版本、请求时间、随机种子等信息。这样后续某一天发现结果异常时才能定位到是模型服务升级还是脚本变动。第四使用多次运行和多数表决。无工具评测中即使 temperature 为 0部分模型仍可能因为底层推理的非确定性输出不同结果。建议对每道题运行 3 次取多数答案作为最终结果能显著降低随机波动的影响。第五评估要结合实际业务。模型排行榜只能提供参考真正决定模型是否适合自己的业务场景还要拿业务侧的典型问题单独做小范围评测。例如你的业务有一类日志解析任务就设计 20 条日志样例对比两个模型在无工具模式下的解析准率。第六不要忽略安全合规问题。调用第三方模型 API 时要注意用户数据和业务内部数据不能随意发送到外部模型服务尤其是涉及个人隐私、企业经营数据时先在受控环境中脱敏再进入评测流程。8. 总结禁掉所有工具之后模型的数学计算、代码生成、长文本理解、多步推理和格式遵循能力会变得非常透明。评测 Opus 5 和 GPT-5.6 这一类新版本模型时与其迷信公开 Benchmark 分数不如自己搭一套可复现的无工具评测流程。只要题目设计合理、脚本逻辑清晰、评分规则稳定你就能在较短时间内看出两个模型在基础能力上的真实差距。如果你准备在自己的业务里做模型选型建议把本文的评测思路改造成一个小型自动化脚本长期维护一组贴合业务的私有评测题。这样当模型版本更新时你可以第一时间重新跑一遍及时掌握模型能力变化。