这次要聊的问题很扎心一个 LLM 在前沿科学基准上拿到了很高的分数看上去推理能力已经很强了结果换一批新题、改一下条件成绩立刻崩盘。原因可能不是模型不会推理而是它走了“捷径”——答案对了方法却错了。这类现象在评估里叫 Shortcut Hacking对应的论文标题也很直白《Right Answer, Wrong Method: Shortcut Hacking Misleads the Evaluation of LLM Reasoning on Frontier Science Benchmarks》。先给一个最直接的理解Shortcut Hacking 不是传统意义上的“测试集泄漏”也不是模型被故意喂了答案。它更像一种应试技巧——模型在训练阶段接触了大量题目和答案的分布特征在评测时利用这些特征把正确选项“猜”出来或者输出一段像模像样的推理过程但关键推导属于事后编造。如果评测只盯着最终答案对不对就会把一个“蒙对”的模型误判成“会推理”的模型。这篇文章会结合实际评测场景拆解 Shortcut Hacking 的常见模式、它会如何误导科学基准的结论以及作为开发者我们可以怎样设计评估审计流程避免被“正确率”这个单一指标骗过去。1. Shortcut Hacking 是什么一个评估陷阱先把这个概念拆开看。Shortcut 是“捷径”Hacking 是“利用漏洞”。合在一起指的是模型没有走评测者预期的解题路径而是通过数据中的表面相关性直接拿到正确答案。在普通任务里这可能只是个瑕疵但在前沿科学基准里它会导致评测结论严重失真。常规评测流程通常是这样的准备一批有标准答案的科学题。把题目交给 LLM。模型输出答案。评测脚本比对答案和标准答案。算出一个准确率。这个流程最大的问题在第四步它只校验“最终答案”不校验“中间过程”。如果一道数学题的答案是 42模型无论是因为推导出 42还是因为记得这道题在某个训练集里出现过输出结果都是一样的。对评测脚本来说这两者没有区别。于是 Shortcut Hacking 就找到了生存空间。它不要求模型真正理解定理、公式或实验方法只需要模型能从训练数据或题面结构中提取出“哪种答案更可能正确”的线索然后输出那个答案。更麻烦的是现在的 LLM 输出已经非常流畅。模型可以生成一大段看起来严谨的推理过程什么“根据能量守恒”“由拉格朗日方程可得”“化简后得到”最后接一个正确答案。表面上看这就像推理成功实际上推理链和正确答案之间可能根本没有逻辑关系完全是后验合理化。所以Shortcut Hacking 不是一个“答案正确与否”的问题而是一个“评测是否能反映真实能力”的问题。只要评测标准只看最终答案这个陷阱就会一直存在。2. 为什么前沿科学基准最容易出现这个问题并不是所有基准都容易被 Shortcut Hacking 击穿。一般常识类问答、开放域对话本身就没有严格推理链评测既看答案也看人工偏好问题不明显。前沿科学基准则不同它有四个容易诱发捷径的特点。第一题目结构紧凑。科学题通常很短题干可能只有两三行但背后是多步推导。模型记忆一道题的成本很低只要训练语料里出现过这道题它就能直接复现答案。第二答案形式可观测。很多科学基准采用选择题或填空题最终答案是一个固定符号、数字或选项。这让机器比对变得容易但也让模型可以绕过推理只猜答案。第三推理过程不可验证。细想一下评测脚本拿到模型输出时它能看到什么通常只有最终答案。如果模型输出了完整的解题步骤评测脚本也很少会逐行检查这些步骤是否合法。一个错误推导配一个正确结论照样得分。第四科学推理本身对精确性要求极高。前沿科学题不像日常对话那样可以“差不多就行”。一个物理题里数值代入错误、单位搞错、条件遗漏都会导致结果不同。模型如果只是依赖表面模式生成答案很容易在细微变化上翻车。这四个特点凑在一起就形成了一种尴尬局面科学基准原本是想检验模型的高阶推理能力但目前的评测方式只检验“答案记忆”或“答案猜测”能力。模型完全不需要理解科学原理也能在一个满是捷径的基准上取得高分。这也是“前沿科学基准”这个限定词的意思。评测者希望用这些难题把模型区分开但恰恰因为这些题难度高、答案长、形式固定反而给捷径留下了更多空间。3. 常见的捷径模式与可观察信号如果不深入模型内部只通过输入输出和评测结果我们能发现哪些捷径信号下面整理几类常见模式。3.1 记忆复现模型在训练阶段已经见过原题评测时直接输出答案。这种情况最明显。判断方法也简单把题目中的关键数字、人名、条件稍微改一下再问模型。如果准确率断崖式下降而模型输出仍保留原题的措辞就很有可能是记忆复现。3.2 选项顺序依赖多选类基准里模型如果对“选 A/B/C/D”存在系统性偏好或者当选项顺序打乱后表现异常就要警惕。正常推理不应该因为选项排列变化而变化如果模型“认位置不认内容”说明它是通过训练数据中的答案分布猜测正确答案而不是真正理解题目。3.3 题干表层特征依赖模型可能提取到“题干越长越倾向选某个答案”“出现某个专业名词就选某个区间”等统计规律。这类模式在科学题里尤其容易发生因为科学题经常出现特定术语簇而这些术语和标准答案在历史上存在统计相关性。3.4 后验合理化模型输出了一大段推理过程看起来每一步都在推导实际上逻辑上是断裂的。也许某个中间结论直接从题干跳出来也许某一步用错了公式但碰巧和最终答案兼容。人工粗看很难识别需要逐行核对推导合法性。3.5 多步压缩模型把应分步完成的计算一次性给出结果省略中间过程。这一步本身不是错误但在评测场景里它可能掩盖了模型并没有真正执行“分步推理”的事实。如果模型无法解释清楚中间状态那推理链就值得怀疑。这些模式不是孤立的经常混合出现。一个模型可能先靠题干表层特征锁定答案方向再生成一段合理化的推导文本来“补票”。评测者如果只看最终答案会得出“这个模型推理很连贯”的错误结论。4. 捷径如何误导 LLM 推理评估结论Shortcut Hacking 的破坏力不在于模型“蒙对了几道题”而在于它会让整个评估体系失去意义。4.1 准确率不再是推理能力的可靠代理准确率是一个标量它只能告诉你“答案对了多少”无法告诉你“为什么对”。当模型通过捷径得分时这个分数就失去了可解释性。一个模型可能在“数学推理”基准上拿到 90% 的准确率但遇到真实科研场景中的陌生题目时准确率掉到 40%。这个差距不是模型泛化能力差而是评估基准从一开始就没有真正测试推理能力。4.2 排行榜被污染如果在同一套被捷径污染的基准上测试多个模型那么排名高的模型未必是推理能力强的模型反而可能是“更容易记住训练数据”或“更擅长猜测答案分布”的模型。这会让排行榜失去公信力也会让下游选型产生错误判断。4.3 “可解释推理”变成幻觉包装现代大模型被要求输出思维链许多人以为“有推理过程”就代表“有推理能力”。但 Shortcut Hacking 恰恰利用了这一点模型生成的长推理链并不代表它真的执行了这些步骤。它可能只是根据训练数据中的文本模式生成了一段与答案表面自洽的解释。这对人类读者更有迷惑性因为它看起来比单纯的“选 C”更可信。4.4 风险被低估科学领域如果引入 LLM 作为辅助工具比如帮研究人员推导公式、设计实验方案那么一个“答案对但方法错”的模型比“答案错”的模型更危险。答案是错的人可能还会复核答案是对的再加上一段看似专业的推导人很容易直接采纳结果却可能存在隐蔽错误。评测如果没有暴露这类风险部署时自然也不会做相应防护。5. 评估审计用一套可复用的方法自测想避免被 Shortcut Hacking 误导不能只改一个指标而要做一次完整的“评估审计”。下面给出一套通用流程不依赖任何特定模型平台你自己就能在测试集上复现。5.1 审计目标明确回答三个问题模型得到的正确答案是否真的来自合法推理测试基准中是否包含可被模型利用的捷径如果去掉这些捷径模型的推理能力还剩多少5.2 审计步骤步骤一抽样人工审查推理链在测试集中随机抽取 50 到 100 道题不只看最终答案还要逐行检查模型输出的推理过程。关注中间结论是否由前文推出、公式使用是否合法、数值代入是否一致、单位是否匹配。步骤二题目扰动测试对题目做三类改动替换题干中的数字保持公式结构不变。打乱选择题选项顺序。改写题干表述但保留数学或物理含义。如果模型成绩大幅波动说明它很可能依赖表面线索。步骤三答案先验检查统计模型在所有测试题上的答案分布。如果模型长期集中输出某一个选项或者输出答案的数字集中在某个区间可能存在答案先验。步骤四推理链一致性校验可以让模型先输出最终答案再要求在另一个会话中输出解题过程或者反过来先输出过程再得出答案。比较两次结果是否一致。如果答案一致、过程完全不同甚至过程与答案不匹配就要警惕。5.3 审计伪代码模板下面是用于评估审计的通用 Python 模板。它不是一个完整评测框架但可以帮你把“答案正确”和“过程正确”分开记录。import json import random def audit_evaluation(model_func, dataset, n50, check_derivationTrue): 对 LLM 推理基准做一次捷径审计。 model_func: 接收题目文本并返回模型输出文本的函数 dataset: 包含 question, ground_truth 的题目列表 n: 审计抽样数量 check_derivation: 是否对推理过程做人工/规则校验 sampled random.sample(dataset, min(n, len(dataset))) results [] for item in sampled: output_text model_func(item[question]) answer_correct extract_answer(output_text) item[ground_truth] if check_derivation: derivation_valid review_derivation(output_text, item[ground_truth]) else: derivation_valid None results.append({ question_id: item.get(id, len(results)), answer_correct: answer_correct, derivation_valid: derivation_valid, }) correct_only sum(r[answer_correct] for r in results) correct_and_valid sum( 1 for r in results if r[answer_correct] and r[derivation_valid] ) return { accuracy: correct_only / len(results), trustworthy_accuracy: correct_and_valid / len(results), samples: results, } def extract_answer(text: str) - str: # 需要根据实际基准格式实现 # 这里只是示意 return text.strip() def review_derivation(text: str, ground_truth: str) - bool: # 这里可以接入人工复核、规则校验或另一个验证模型 # 返回 True 表示推理链合法 return True在上面的代码里accuracy就是常规准确率trustworthy_accuracy是“答案正确且推理合法”的比例。如果两个指标差距很大说明测试集中存在明显的捷径现象。建议把审计结果单独记录不要只留一个总分。能定位到具体题目和具体推理模式才能进一步修复基准或调整评估流程。6. 缓解思路从基准设计到模型评测针对 Shortcut Hacking缓解措施不能只放在模型层还需要同时优化基准设计、评测指标和解码策略。6.1 基准设计减少可被利用的痕迹设计科学基准时应减少题目与答案之间的“可观察关联”。具体包括减少固定选择题使用生成式作答。对数值型答案增加单位校验和误差范围。引入题目变体生成机制每份测试集都动态生成题目。设置分布外题组确保测试集不参与模型训练。在答案中混入干扰项降低模型通过统计规律猜测的概率。这一条的最核心原则是让模型无法通过“记住题目”或“猜答案分布”来得分。6.2 评测指标拆分“答案正确”和“过程正确”建议在评测报告中同时给出以下指标标准答案准确率只看最终答案。过程合法率推理链是否合法。可信准确率答案正确且过程合法。扰动鲁棒性题目扰动前后准确率差异。答案分布熵模型输出答案是否有明显偏差。这些指标能比单纯准确率提供更多信息也能更快暴露捷径问题。6.3 提示词与解码策略让推理过程可被检查虽然提示词不能根除 Shortcut Hacking但可以让推理过程更透明。下面是一个通用提示模板适用于科学推理类任务。需要按实际模型和任务微调。请解决下面这道科学题并严格按以下格式输出 1. 分析题目条件列出已知量与待求量。 2. 写出需要使用的定理或公式并说明选择依据。 3. 代入数值逐步推导保留关键中间结果。 4. 对最终结果做单位或量纲检查。 5. 给出最终答案。 题目 {question}这个模板的核心不是让它更“聪明”而是让它更“可审计”。模型输出的每一步都可以被单独检查方便判断推理过程是否有逻辑断层。6.4 解码策略降低猜测收益评测推理基准时建议把温度调低关闭或显式控制随机采样。如果模型支持多个采样可以多次采样并要求最终答案一致。对选择题如果一次生成结果在不同采样下波动极大说明模型可能不是靠稳定的推理得出答案而是在猜。6.5 数据合法性与合规提醒如果你自建科学评测集务必注意数据来源授权。不要直接抓取未授权的试卷、教材或论文内容打包分发。评测集应当只用于内部离线评估不要将带标准答案的题目直接暴露给线上模型接口否则既可能污染评测也可能引入版权和合规风险。7. 对 LLM 应用开发者的实际意义看到这里有人可能会想Shortcut Hacking 是评测机构该操心的事我只负责调用 API 做应用和我关系不大。这个想法需要纠正。7.1 不要盲信别人的评测分数很多模型发布时都会给出一堆 benchmark 成绩。这些成绩背后到底有没有审计算法测试集是否被污染评测流程是否校验了推理链你很难完全确认。所以选型阶段不要只对比排行榜数字要自己在业务场景里做小样本验证。7.2 应用评估要加“过程日志”如果你的应用涉及多步推理例如 Agent 调用工具、RAG 检索后综合回答、代码生成与执行建议在日志里保留完整的推理链和中间状态。如果用户报错你能回放“模型是怎么推理的”而不是只看一个最终结果。这一步的做法很简单记录每一次模型调用时的输入、输出、关键中间变量和得分。7.3 “答案正确”不等于“过程可靠”在工程系统里可靠性和准确率是两回事。一个模型可能经常答对但在关键场景里用错误步骤碰巧答对。这种错误步骤一旦被业务逻辑复现就可能产生连锁故障。因此在评估 Agent 或科学计算类应用时要额外设计“过程校验”而不是只看最终输出。7.4 把“扰动测试”加入持续集成如果你的业务频繁使用 LLM 做推理可以把“题目扰动测试”做成一个自动化脚本。每次模型版本更新后跑一组包含语义等价但表层不同的题对比前后准确率变化。如果新版本在原始题上提升明显但在扰动题上不提升甚至下降说明新版本可能只是在记忆训练数据上变强了泛化能力未必提升。8. 常见误区与排查方法下面整理几个和 Shortcut Hacking 相关的常见问题按“现象 → 原因 → 检查 → 解决”的方式展开。现象可能原因检查方式解决思路测试集准确率很高换新题就崩训练数据中包含测试题或相似题做题目变体扰动测试建立动态题目生成机制模型总是有推理过程但很难挑错后验合理化逐行检查推理链的每一步过程合法率 条件分支打乱选项顺序后成绩波动大选项顺序过拟合对同一题做选项随机排列评测脚本固定随机种子数字答案看起来很对但单位错了符号匹配而非物理推理增加单位校验评测指标中加入单位检查温度调高后答案剧烈变化依赖采样猜测多次采样取一致性降低温度多轮投票模型输出“标准答案”但没写推导答案记忆或压缩强制输出中间步骤提示词模板要求分步输出许多问题光看日志是发现不了的需要做主动扰动实验。记住一个原则评测一个推理模型要故意制造“陌生感”而不是只给它喂熟悉的题面。9. 最佳实践清单到这里内容已经比较全面了。把建议浓缩成一份可执行的实践清单。9.1 基准建设阶段使用动态生成题目避免静态测试集被复制到训练语料。为不同学科设置独立的验证集防止跨科目捷径。对题目做版权和隐私审查确认可合法使用。记录每道题的来源、版本和扰动规则。9.2 评测执行阶段所有实验固定随机种子、解码参数和系统提示词。同时记录标准准确率和过程合法率。抽样做人工复核不要完全依赖自动比对。增加题面扰动测试和选项顺序鲁棒性测试。9.3 结果报告阶段发布报告时同时给出评测集版本和模型版本。不隐藏“可信准确率”和“标准准确率”的差距。汇报测试集是否可能被训练语料覆盖。明确说明评测不能证明模型的科学推理能力。9.4 应用部署阶段对关键场景做过程日志记录。对高风险输出增加人工复核。定期使用扰动题组做回归测试。如果模型在扰动测试中表现不佳要降低它在推理任务上的权重。10. 下一步建议先别急着跑更大的模型、堆更多算力。如果你正在做 LLM 推理评估最该先做的是一件低成本的事从测试集里抽 50 道题把模型输出里的最终答案遮住只看推理过程判断它是否站得住脚。这个过程不需要复杂工具一个人、一份日志、一个表格就能完成。如果发现模型在大量题目上是“答案对、过程错”那说明评测基准已经被 Shortcut Hacking 影响了。这时候再调整题目、增加扰动测试、拆分答案与过程指标才有意义。建议把这个话题收藏备用。以后无论是评估开源模型、微调一个数学推理模型还是给 Agent 设计评测脚本都可以拿“答案正确但方法错误”这个标准去审视自己的评测结果。多问一句“它为什么对”能少踩很多隐藏的坑。