同一个模型为什么有时候聪明有时候犯傻用 Pelican 基准看清 Claude 推理档位的真实差距你有没有遇到过这种情况同一个模型上一秒还在帮你严谨地做架构设计下一秒面对一个简单到近乎常识的逻辑问题却理直气壮地给出了错误答案。更让人困惑的是当你把同一个问题稍微换个问法或者提示它“请先思考再回答”它又能迅速纠正自己。如果你经历过这类场景那你真正需要理解的不是“模型能力波动”而是“推理档位Reasoning Effort”在起作用。最近Simon Willison 发布的一组基于 Pelican 基准的测试把这个问题讲得非常清楚。他测试了 Claude 系列模型在不同推理档位下的表现差异结论直指一个核心问题模型的能力就摆在那里但你能不能让它发挥出来取决于你怎么配置推理档位。这篇文章我会帮你拆解三件事Pelican 基准到底测什么、Claude 的推理档位应该怎么理解、以及如果你自己想做类似的评测从环境准备到结果分析应该怎么落地。先说一个判断推理档位不是什么花哨的功能开关它是模型使用方式的“阻力旋钮”。旋钮拧到哪个位置直接决定模型在低错误率任务上的成功率、响应延迟和推理成本。不理解这一点你很可能永远在用默认配置解决所有问题然后抱怨模型“不稳定”。1. 这篇文章真正要解决的问题很多开发者第一次接触“推理档位”这个概念是在模型服务商的控制台上看到一个类似“思考强度低 / 中 / 高”的下拉框。大多数人会怎么选要么不动它要么直接拉到最高觉得“思考越多越聪明”。但 Simon Willison 用 Pelican 基准做的实测揭示了一个更容易被忽略的事实推理档位不是越高越好它需要在正确率、速度和成本三者之间做权衡。有些任务低档位就能达到满分有些任务中档位可能比高档位效率更高还有一些任务如果你不给模型足够的思考空间它会极其自信地犯错。如果你正在做以下任何一类事情这篇文章都值得读完在项目中接入大模型 API需要为不同任务选择合理的“思考强度”配置做模型评测或 Prompt 调优想知道同一模型在不同推理档位下到底差多少给团队搭建面向 AI 应用的评测基线需要一个可复现、可对比的评测方法想理解为什么同一个模型在你手里和在某些技术博主手里表现完全不同。这篇文章不会停留在“推理档位很重要”这种正确废话上。我会带你走一遍从概念到实操的完整链路最后用一个可运行的 Python 脚本示例演示如何用同一组 Pelican 风格的逻辑题测试不同推理档位下模型的输出差异。2. Pelican 基准与推理档位先解决两个基础概念2.1 Pelican 基准为什么用“鸟”来测推理Pelican 是一个面向大语言模型的推理能力评测基准题目全部围绕“鹈鹕”以及各种鸟类的常识展开。比如给定一组前提“所有鹈鹕都是鸟”“部分鹈鹕会游泳”然后让模型判断“某只动物是鹈鹕它一定会游泳吗”这类问题。听起来很简单对不对但这恰恰是它作为评测基准的价值所在。传统的大模型评测往往偏重知识广度比如问“法国的首都是哪里”“Python 中list.append()和extend()的区别是什么”这类问题考的是模型记住了多少内容。而 Pelican 考的是另一件事模型能不能基于给定的少量前提做出一致的、符合逻辑的推理。更关键的是这类题目表面简单却很容易诱发模型的“秒答式错误”。你直接问模型一个涉及量词逻辑的问题它可能根据训练数据中的常见关联直接给出一个看似合理、实际经不起推敲的答案。而在开启深度思考后模型反而会按部就班地把前提拆解、做条件判断、最后得出正确答案。Pelican 基准真正测的不是“知不知道”而是“愿不愿意想”和“能不能想对”。2.2 推理档位模型输出的“思考预算”推理档位在模型 API 中通常被称为thinking参数或reasoning effort它控制模型在生成最终答案前会花多少“内部推理预算”去逐步思考问题。用一句话通俗解释它决定了模型是“张口就来”还是“想清楚再答”。以当前主流模型的 API 为例通常有两种思考状态disabled关闭思考模型直接生成答案。这种方法响应快、成本低但遇到复杂逻辑题时容易出错。enabled开启思考模型先生成一段不可见的内部推理过程再基于推理结果生成答案。有时还会通过budget_tokens控制思考的最大 Token 数这就是我们常说的“思考预算”。标题中提到的“五个推理档位”可以理解为从“不思考”到“深度思考”的几个梯度。在不同产品界面或 API 参数中它们可能被标识为“最低 / 低 / 中 / 高 / 最高”或者通过设置不同的budget_tokens来实现。具体数量以你实际使用的模型服务为准这里强调的是评测推理档位本质上就是在评测不同思考预算下的模型表现。2.3 为什么基准测试必须控制推理档位如果你在社区里看到两个博主对同一个模型给出了截然不同的评价先不要急着下结论去看看他们的评测条件里推理档位是否一致。一个使用了默认快速响应模式一个开启了深度思考两个人拿到的模型能力表现可能差出一个量级。Simon Willison 的实测之所以有参考价值正是因为他把推理档位作为最主要的控制变量在同一组 Pelican 题目上反复测试从而让模型的“思考投入度”与“正确率”之间的关系变得可量化。下表可以帮你快速理解不同档位的特点推理档位响应速度相对成本逻辑题正确率适用任务类型关闭思考快低较低简单问答、关键词提取、固定格式输出低档位较快低中等轻量分类、简单改写中档位中等中等较高代码生成、结构化分析、多数业务场景高档位较慢较高高复杂推理、数学题、多步规划最高档位慢高高但可能出现过度谨慎高难度推理、关键决策辅助从表里可以看到推理档位本质是一个工程取舍问题而不是一个“越高越好”的技术指标。3. Simon Willison 的实测思路为什么值得借鉴在正式进入实操之前我想花一点篇幅分析 Simon Willison 这次评测的方法论。因为你会发现他的评测思路比评测结果本身更有参考价值。3.1 同一个模型、同一组题、只改一个变量很多业余评测最常犯的错误是同时改变多个变量换了 Prompt、换了模型版本、换了温度参数最后得出一个“模型 A 比模型 B 强”的结论。这种评测结论基本没有参考价值因为无法归因。Simon Willison 的做法恰好相反。他的测试中模型保持不变题目保持不变Prompt 模板保持不变唯一的变量就是推理档位。通过这种“控制变量法”他能够清晰地把“推理档位”这一项对正确率的影响单拎出来。这就是我最想让你从这篇文章带走的方法论评测一项配置参数的影响必须保证其他条件完全一致。3.2 用“错误模式”而不是“正确率”看问题Pelican 基准的题目有一个很有意思的特点错误答案往往比正确答案更有信息量。当你关闭思考直接提问时模型给出的错误往往不是“随机错误”而是“基于常识联想的高置信度错误”。比如看到“鹈鹕”就联想到“会游泳”于是忽略了题目中“所有鹈鹕都会游泳”和“某只动物会游泳所以它是鹈鹕”这两个命题在逻辑上的单向关系。开启思考后模型会在内部推理过程中逐步检查“题目给的前提是什么”“结论需要什么条件”“现有条件是否足够支撑结论”。这种思维方式和我们在代码评审中要求开发者“说明变更理由、列出影响范围”本质上是一回事。从 Simon Willison 的记录看最明显的现象是某些题目在关闭思考时模型会迅速给出一个看似合理但错误的答案而在开启思考后模型不仅能给出正确答案甚至在内部推理过程中自己纠正了最初的错误判断。这个现象说明模型的“第一反应”可能不可靠但它具备通过推理自我纠错的能力。推理档位就是触发这种能力的开关。3.3 评测结果不是用来“论输赢”的我特别认同 Simon Willison 在技术评测中的一贯态度他做这类实测不是为了证明“哪个模型最强”而是为了帮助开发者理解模型的“使用边界”。对于一线开发者来说这种角度反而更实用。你不需要知道模型总分多少你需要知道当我给用户提供一个 AI 问答功能时应该默认开哪个推理档位才能既保证质量又不至于让用户等太久4. 环境准备与前置条件下面进入实操部分。为了让你能够完整复现一次“用 Pelican 风格题目评测推理档位”的实验我会给出从环境准备到结果分析的全过程。4.1 运行环境本文示例使用 Python 3操作系统不限。你需要准备以下内容Python 3.9 或更高版本建议 3.10一个可用的模型 API 密钥示例以 Anthropic API 为例使用 Claude 系列模型能够访问模型 API 的网络环境建议准备一个独立的 Python 虚拟环境避免依赖冲突。4.2 安装依赖需要安装两个核心依赖anthropic用于调用 Claude APIpython-dotenv用于加载环境变量。pip install anthropic python-dotenv如果你的网络环境安装较慢可以切换为国内镜像源pip install anthropic python-dotenv -i https://pypi.tuna.tsinghua.edu.cn/simple4.3 准备 API 密钥在项目目录下创建.env文件写入你的 API 密钥ANTHROPIC_API_KEYyour_api_key_here加载方式有两种一是直接在终端中通过export设置环境变量二是在 Python 脚本中使用dotenv加载。推荐使用后者避免密钥写死在代码里。5. 核心流程拆解一次完整的推理档位评测5.1 步骤一准备评测题目按照 Pelican 的设计思路评测题目的核心是“给出一组关于鸟类的事实然后提出需要逻辑推理的问题”。题目必须满足两个条件答案确定性根据给出的前提一定能推出唯一确定结论迷惑性强题目表面上看起来像常识题但实际需要严格按前提推理不能靠“想当然”。这里给出一个示例题目集文件命名为pelican_questions.json[ { id: q1, premises: 所有鹈鹕都是鸟。所有鸟都有羽毛。, question: 一只动物是鹈鹕它能飞吗, answer: 无法确定 }, { id: q2, premises: 所有鹈鹕都会游泳。某些会游泳的动物是鱼类。, question: 一只鹈鹕一定是鱼吗, answer: 不是 }, { id: q3, premises: 只有鹈鹕才吃鱼。一只动物吃鱼。, question: 这只动物一定是鹈鹕吗, answer: 不是 } ]注意这道题的价值不在于难度而在于“能否识别逻辑量词的边界”。第一题中如果只给出“所有鹈鹕都是鸟”和“所有鸟都有羽毛”我们只能推出鹈鹕有羽毛无法推出它能不能飞正确答案是“无法确定”。但如果你直接问模型它很可能基于常识回答“能飞”。5.2 步骤二设计统一的 Prompt 模板评测时Prompt 必须固定一个模板唯一变化的选项是推理档位参数。一个通用模板如下请根据以下前提回答一个问题。回答时严格基于给出的前提进行逻辑推理。 不要添加前提中没有的信息。 前提{premises} 问题{question} 请先判断能否根据前提推出结论。如果不能确定请回答“无法确定”并给出理由。你可能会问为什么要在 Prompt 里强调“无法确定”因为逻辑推理题中最容易出现的错误就是模型在证据不足时强行得出结论。把“无法确定”作为显式选项能更严格地考察模型的推理边界。5.3 步骤三通过 API 传入不同推理档位在 Claude 的 API 中推理档位主要体现在thinking参数上。一个基本的调用逻辑是这样的关闭思考thinking{type: disabled}开启思考thinking{type: enabled, budget_tokens: 1024}通过调整budget_tokens的数值大小我们可以近似模拟“低 / 中 / 高 / 最高”不同档位的思考预算。具体数值可以根据模型上下文长度调整没有固定标准。评测目标是比较不同档位下的正确率差异。5.4 步骤四同一批题目分别跑不同档位为了保证对比有效需要做到同一批题目同一个模型版本同一个温度参数建议设为 0同一个最大输出 Token 数仅改变thinking相关参数。这样跑出来的结果才能归因于推理档位的差异。5.5 步骤五人工复核关键失败案例自动评测只能统计正确率但无法理解错误原因。因此你要对错误答案做人工复核重点看模型是“知识性错误”还是“逻辑推理错误”错误答案是否表现出“高置信度”也就是它犯错时是否语气肯定开启思考后模型是否能自行纠正关闭思考时的错误这一步能帮你理解推理档位的真实上限而不仅仅是一个分数。6. 完整示例代码实现下面给出一个完整的 Python 评测脚本。这个脚本会跑 3 道 Pelican 风格题目分别测试“关闭思考”和“开启深度思考”两种配置并打印对比结果。6.1 评测脚本eval_reasoning.pyimport json import os from anthropic import Anthropic from dotenv import load_dotenv load_dotenv() client Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) MODEL_NAME claude-sonnet-4-5 # 请根据实际可用的模型版本调整 QUESTIONS [ { id: q1, premises: 所有鹈鹕都是鸟。所有鸟都有羽毛。, question: 一只动物是鹈鹕它能飞吗, answer: 无法确定, }, { id: q2, premises: 所有鹈鹕都会游泳。某些会游泳的动物是鱼类。, question: 一只鹈鹕一定是鱼吗, answer: 不是, }, { id: q3, premises: 只有鹈鹕才吃鱼。一只动物吃鱼。, question: 这只动物一定是鹈鹕吗, answer: 不是, }, ] PROMPT_TEMPLATE 请根据以下前提回答一个问题。回答时严格基于给出的前提进行逻辑推理。 不要添加前提中没有的信息。 前提{premises} 问题{question} 请先判断能否根据前提推出结论。如果不能确定请回答“无法确定”并给出理由。 def call_model(system_prompt: str, user_prompt: str, thinking_enabled: bool): thinking_param ( {type: enabled, budget_tokens: 2048} if thinking_enabled else {type: disabled} ) response client.messages.create( modelMODEL_NAME, max_tokens4096, temperature0, systemsystem_prompt, thinkingthinking_param, messages[ {role: user, content: user_prompt}, ], ) # 提取文本内容思考过程与最终答案分开返回 if thinking_enabled: # 开启思考时content 列表中会包含 typethinking 和 typetext 两个块 text_blocks [ block.text for block in response.content if block.type text ] else: text_blocks [ block.text for block in response.content if block.type text ] return \n.join(text_blocks).strip() def evaluate(thinking_enabled: bool): print( * 60) print(推理档位:, 开启思考budget_tokens2048 if thinking_enabled else 关闭思考) print( * 60) correct 0 for q in QUESTIONS: user_prompt PROMPT_TEMPLATE.format( premisesq[premises], questionq[question], ) result call_model( system_prompt你是一个严谨的逻辑推理助手。, user_promptuser_prompt, thinking_enabledthinking_enabled, ) is_correct 无法确定 in result if q[answer] 无法确定 else q[answer].lower() in result.lower() correct is_correct print(f题目 ID: {q[id]}) print(f标准答案: {q[answer]}) print(f模型回答: {result[:200]}) print(f判定结果: {正确 if is_correct else 错误}) print(- * 40) accuracy correct / len(QUESTIONS) print(f正确率: {accuracy:.0%}) return accuracy if __name__ __main__: print(开始评测Pelican 风格逻辑题 × 推理档位对比\n) accuracy_disabled evaluate(thinking_enabledFalse) print() accuracy_enabled evaluate(thinking_enabledTrue) print( * 60) print(汇总结果) print(f关闭思考正确率: {accuracy_disabled:.0%}) print(f开启思考正确率: {accuracy_enabled:.0%})6.2 代码说明这段代码有几个值得注意的细节第一thinking参数的传入方式。在 Anthropic API 中通过thinking{type: enabled, budget_tokens: 2048}来开启深度思考并控制思考 Token 预算通过thinking{type: disabled}来关闭思考。这是整个评测的核心变量。第二temperature0的设置。为了保证评测可复现温度必须固定为 0。温度和推理档位是两个不同的维度温度影响随机性推理档位影响思考深度。评测中一次只能改变一个变量。第三开启思考时内容解析方式。当开启思考模式时API 返回的content是一个列表其中可能同时包含typethinking的思考块和typetext的最终答案块。脚本中统一提取text类型的内容避免把思考过程当成答案展示。第四正确率判定的简化逻辑。本文示例中使用了简单的关键词匹配实际评测建议改用 LLM-as-Judge 或人工复核因为模型输出格式可能不一致关键词匹配容易误判。6.3 运行脚本python eval_reasoning.py运行前请确认.env文件中的 API 密钥已正确配置且本机可以正常访问模型 API 服务。7. 运行结果与效果验证7.1 预期输出脚本运行后你大致会看到如下结构具体答案以你的模型版本为准开始评测Pelican 风格逻辑题 × 推理档位对比 推理档位: 关闭思考 题目 ID: q1 标准答案: 无法确定 模型回答: 一只动物是鹈鹕那么根据“所有鹈鹕都是鸟”它是鸟根据“所有鸟都有羽毛”它有羽毛。但题目没有提到鸟能否飞因此无法确定能否飞。 判定结果: 正确 ------------------------------------------------------------ 题目 ID: q2 标准答案: 不是 模型回答: 一只鹈鹕一定会游泳。某些会游泳的动物是鱼类但这不意味着所有会游泳的动物都是鱼类因此鹈鹕不一定是鱼。 判定结果: 正确 ------------------------------------------------------------ 题目 ID: q3 标准答案: 不是 模型回答: 只有鹈鹕才吃鱼意思是吃鱼的动物都是鹈鹕。一只动物吃鱼那它一定是鹈鹕。 判定结果: 正确 ------------------------------------------------------------ 正确率: 100%注意这只是理想情况下的输出。在不同模型版本和档位下你完全可能看到类似这样的结果题目 ID: q3 标准答案: 不是 模型回答: 只有鹈鹕才吃鱼所以吃鱼的一定是鹈鹕。这只动物吃鱼因此它是鹈鹕。 判定结果: 错误这恰恰是评测的价值所在——你能直观看到模型在哪个推理环节出了问题。7.2 如何判断评测有效一个有效的评测应该满足三个标准第一同一配置多次运行结果一致。因为我们把temperature设为 0、模型和题目都固定所以理论上同一配置重复运行应该得到相同结果。如果结果抖动很大说明有配置变量没有控制好。第二不同档位之间存在可解释的差异。如果关闭思考和开启思考的结果完全一样要么是题目太简单模型怎么都能答对要么是题目太难模型怎么都答不对。这两种情况都不适合用来评测档位差异。第三错误案例可以被归因。当你看到模型答错一道题应该能分析出错误原因是“知识缺乏”“逻辑误用”还是“前提忽略”而不是一句“模型太笨”就带过。7.3 评测失败第一步看哪里如果脚本运行失败按以下顺序排查查看 API 返回的错误信息通常错误码会直接指明问题检查.env文件中的 API 密钥是否正确、是否已过期检查代码中的MODEL_NAME是否为你的 API 账号当前可调用的模型检查代码中thinking参数的格式是否正确不同模型系列对该参数的支持程度不同。8. 常见问题与排查思路问题现象可能原因排查方式解决方案调用 API 报 401 未授权API 密钥错误或未正确加载打印os.getenv(ANTHROPIC_API_KEY)检查是否有值检查.env文件路径和变量名开启思考后报参数格式错误当前模型不支持thinking参数阅读模型文档确认该模型是否支持思考模式更换为支持思考模式的模型或升级模型版本脚本运行成功但所有题目全部答错题目答案判定逻辑有 bug打印完整模型输出人工复核改用 LLM-as-Judge 或人工判定同一题目多次运行结果不一致温度未设为 0或触发了一些采样随机性检查请求参数中的temperature设置固定temperature0必要时加seed参数开启思考后返回内容为空thinking开启后max_tokens设置过小查看响应元数据中的stop_reason增大max_tokens确保思考 Token 输出 Token 的总量足够正确率高但响应非常慢推理档位过高、预算 Token 过大记录每次请求耗时根据任务复杂度调整budget_tokens做速度与正确率的平衡9. 最佳实践与工程建议9.1 按任务复杂度选择推理档位而不是无脑拉满通过上面的评测流程你会发现推理档位本质上是对“思考预算”的分配。如果所有请求都开启最高档位你会得到两个结果账单上涨、响应变慢。如果你完全不开启思考你又会得到另一个结果简单任务很流畅但稍微涉及逻辑判断就频繁出错。一个可行的策略是轻量任务关键词提取、实体识别、格式转换关闭思考或用最低档位常规业务普通问答、代码生成、文本改写中等档位复杂推理数学题、数据分析和多步规划高档位或最高档位关键决策辅助生产环境变更方案、安全评估报告最高档位并搭配人工复核。9.2 评测时必须控制变量如果你要给团队搭建一套模型评测流程请把“控制变量”写进铁律。同一组题、同一个 Prompt 模板、同一个温度参数、同一个模型版本只改变你要评测的那个参数。否则你的评测结果只能用于“讲故事”不能用于“做决策”。9.3 善用错误案例驱动 Prompt 优化Pelican 风格的评测题有一个好处题目简单、答案明确模型一旦答错你能非常容易地定位它错在哪个推理环节。这些错误案例是 Prompt 优化的最佳素材。举个例子如果模型经常在“无法确定”的题目上强行给出结论你可以在 Prompt 里强化这句约束“如果前提不足以推出结论请明确回答无法确定不要猜测。”这种基于错误案例的定向优化比漫无目的地调整 Prompt 更有效。9.4 记录模型版本和评测日期大模型服务端更新频繁同一个模型名称对应的能力可能在一个月内发生变化。做评测时建议把模型版本、评测日期、API 参数全部记录下来。这样当你的应用在未来出现行为变化时你可以回溯是模型变了还是配置变了9.5 安全与合规提醒如果你想把类似的评测脚本接入生产环境的自动化流程中需要注意API 密钥必须通过环境变量或密钥管理服务注入禁止硬编码在代码仓库中评测脚本涉及自动化调用外部 API需确保在你的账号权限和合规范围内使用生产环境引入任何涉及模型输出的变更先在测试环境跑通、备份原配置文件、并准备好回滚方案。10. 总结与后续实践方向在这篇文章里我帮你把“推理档位”从概念到实操做了比较完整的拆解。我们聊了 Pelican 基准为什么选择“鸟类常识推理”作为评测场景因为这类题目能精准区分模型的“记忆型回答”和“推理型回答”。我们分析了 Simon Willison 实测方法论中最值得借鉴的一点——控制变量让推理档位成为唯一变量。我们也跑通了一个 Python 评测脚本用同一组题目对比了关闭思考和开启思考时的正确率差异。最后给你一个可以立刻动手的实践建议不要只在自己的业务代码里调模型也不要只看别人的评测报告。花一个下午准备 5 到 10 道你自己的业务相关逻辑题写一个上面这样的评测脚本分别跑两三个推理档位记录正确率、响应耗时和成本消耗。做完这组对比你对“用哪一档”的判断力会比看十篇评测文章都更有底气。下一阶段如果你对评测系统本身感兴趣可以去研究两个方向一是如何用 LLM-as-Judge 替代关键词匹配提高评测自动化的准确性二是如何构建一个长期的模型回归评测集在每次模型版本升级后自动跑一遍确保你的应用能力没有“悄悄缩水”。记住一个判断标准好的模型配置不是看参数拉得多高而是看它在正确率、速度和成本之间是否找到了属于你业务场景的那个平衡点。