Shortcut Hacking：答对题≠会推理，LLM评测如何避免失真？

现在很多团队在评估 LLM 时会把“答对题”当成“会推理”。这个逻辑在大多数场景下成立但到了前沿科学基准上已经出现一个明显的问题模型用错误的方法得到了正确的答案。论文标题写得很直接——Right Answer, Wrong Method: Shortcut Hacking Misleads the Evaluation of LLM Reasoning on Frontier Science Benchmarks。Shortcut Hacking 不是一句口号它是一个会直接污染评测结论的机制。模型并没有真正完成多步推理而是靠题目模板、选项位置、记忆片段、甚至少样本示例中的格式线索绕过了推理过程最后给出正确答案。如果评测只看最终结果这些“假阳性”会被算成模型的真实推理能力导致模型能力被高估评测排名失真后续的模型选型和技术判断也会跟着跑偏。这篇文章围绕 Shortcut Hacking 展开重点讲三件事第一它是什么和常规的数据污染有什么区别第二它为什么对前沿科学类基准评测影响更大第三实操层面怎么检测、怎么规避以及怎么设计一套更不容易被“抄近路”的评测流程。如果读者正在做 LLM 评测、跑榜单、或者要基于基准结果选模型这篇文章可以直接收藏。1. 核心概念速览先把这次研究涉及的关键概念和结论放在一张表里方便快速判断。能力项说明研究对象LLM大语言模型在科学类基准上的推理能力评估核心问题模型通过捷径获得正确答案但推理方法不正确导致评测结果失真关键概念Shortcut Hacking指模型利用数据模式、模板线索、记忆内容绕过真正推理影响范围前沿科学基准、数学推理基准、多步推理评测、模型能力排名与数据污染的区别数据污染是训练语料包含测试答案Shortcut Hacking 是模型利用任务结构中的捷径特征主要危害高估推理能力、错误判断模型间的真实差距、误导模型选型检测思路拆解推理过程、对比中间步骤、设计对抗性样本、控制信息泄露适用读者评测工程师、LLM 应用开发者、算法研究员、技术决策者工具链评测框架、自动化评分工具、推理链日志分析、统计显著性检验从这张表可以看出Shortcut Hacking 本质上是一个“评测设计缺陷”问题。它不是模型本身出了故障而是评测协议没有足够严格地区分“正确答案”和“正确推理”。2. Shortcut Hacking 是什么不只是“背答案”要理解 Shortcut Hacking先得明确一个容易被忽略的事实模型答对一道题可能来自多条路径。正常路径是模型读取题目、抽象出问题结构、执行多步推理、生成中间结论、最终得到答案。这条路径是我们希望评测去捕捉的。捷径路径则完全不同。模型可能在训练数据中见过近似题目直接匹配记忆中的答案根据题目中的格式化特征推测输出例如选项长度、位置、标点分布利用少样本示例中的输出格式跳过推理直接拼接答案对标准化题干做“关键词触发”例如看到“水的沸点”就直接输出“100°C”不区分题目究竟在问什么在当前上下文中捕捉到模型自身之前生成的部分把不完整的中间结果错当成结论。这些路径都会导致最终答案正确但推理过程缺失或错误。论文里把这种现象称为Shortcut Hacking和常见的“数据污染”data contamination并不是同一回事。数据污染强调的是训练语料里包含了测试集答案属于数据侧问题Shortcut Hacking 更强调评测任务的结构设计给了模型“可乘之机”属于评测方法问题。这样的区分很重要。如果团队只是用新题替换旧题却没有重构题目结构和评分协议Shortcut Hacking 依然会存在。前沿科学基准尤其容易中招因为这类题目通常有稳定的格式、固定的选项布局、标准化的化学式表达和公式排版这些表面特征恰恰会给模型提供捷径。3. 为什么前沿科学基准更容易被误导前沿科学基准通常覆盖数学、物理、化学、生物等学科题目往往结构高度标准化。这种标准化对人工阅卷友好但对 LLM 评测来说却容易引入额外风险。3.1 结构标准化带来的“特征泄露”一道科学题通常包含题干、选项或子问题、答案区。模型在大量相关语料上训练之后很容易学到一种表层映射某种题型配某种答案模式。比如如果基准中某个类别的题目答案总是落在“C 选项”或者某个知识点的标准答案总是同一个表述模型就会利用这种统计偏差来猜答案。这不是推理而是模式匹配。但评测系统如果只记录最终答案无法区分。3.2 多步推理中的“部分正确”陷阱前沿科学题的推理链通常很长定义问题、公式推导、数值代入、单位换算、结论验证。模型可能在第一步就出错了但后续步骤恰好拼出了一个正确答案也可能前面几步正确最后一步错误可最终输出通过四舍五入等形式接近正确答案。这类“部分正确”很容易在自动评分中被判定为正确。Shortcut Hacking 在这个场景下表现为模型根本没有建立完整的推理链只是跳过关键分支直接输出了在分布上较有把握的答案。从答案看仿佛模型掌握了解题方法从推理过程看则完全是另一回事。3.3 少样本示例泄露推理路径评测中常用 few-shot 方式给模型展示示例。示例的本意是提供格式参考但如果示例中包含了解题步骤或答案推导过程模型可能会模仿格式而非学习推理。更隐蔽的是示例中可以存在“输出位置泄露”模型发现示例中最后一行往往是答案于是它学会“直接生成最后一行”中间过程全部省略。这种问题在没有严格评测协议时很难被注意到。3.4 评测分数上升但不代表能力上升前沿科学基准的分数增长不总是对应模型推理能力的增长。如果题目的捷径特征没有清除模型可以通过更长的上下文、更大的参数量、更强的模式记忆来提升分数但真正的多步推理能力可能没有同步增长。评测分数看起来“涨了”实际涨的是拟合评测分布的能力。这也是 Shortcut Hacking 对技术决策影响最大的一个点团队依据错误分数做模型选型和能力评估后续投入方向也会被带偏。4. 检测 Shortcut Hacking 的实操方法要发现模型是否走了捷径不能只看最终答案需要把评测过程拆开围绕“推理方法”设计检测机制。4.1 收集并审查推理链最直接的方法是让模型输出完整推理过程chain-of-thought并对推理链做人工或自动化审查。审查不只看结论更看关键步骤是否存在、是否有逻辑跳跃、是否引用了题干中不存在的信息。实际操作时可以按下面这个流程实施在评测用例中要求模型先输出推理步骤再输出最终答案将推理步骤和最终答案分开记录对推理步骤做关键词缺失检测例如变量定义、公式引用、单位换算是否存在对推理逻辑做二次采样抽样人工审核记录“答案正确但推理不完整”的样本数量。这个方法不能完全自动化但能快速暴露一个大致的比例。如果这类样本占比很高说明评测结果的可靠性存疑。4.2 加入对抗性变体测试把原始题目做小范围扰动再用扰动后的题目重新评测。如果模型得分剧烈下降说明它依赖的是表面特征而不是真正的推理能力。常见的扰动方法调换题目中数值的先后顺序改变选项顺序把题干的提问方式从“求速度”改为“求位移与时间的比值”把化学物质名称替换为同义表达调整少样本示例的顺序和格式。如果模型在原始题目上表现稳定在扰动后表现大幅下降就说明评测存在 shortcut 风险。4.3 对比“只出答案”和“带推理出答案”的分数同一组题目跑两种模式模式 A只让模型输出最终答案模式 B先输出推理步骤再输出最终答案。如果模式 B 的得分显著低于模式 A说明模型在没有“推理约束”的情况下更依赖捷径在得分。这种差异本身就是 Shortcut Hacking 存在的证据。4.4 引入答案分布分析统计模型在不同题型、不同选项位置的准确率。如果所有正确答案都偏向某一个选项位置或者某个知识域的正确率异常高于其他域就要警惕模型是不是在拟合基准结构。例如可以按选项位置分组统计选项位置题目数模型准确率随机基线准确率A5024%25%B5022%25%C5058%25%D5020%25%如果出现某个位置显著偏高需要进一步检查该位置题目的特征。4.5 置信度与答案一致性检查对同一道题多次采样观察模型答案是否稳定。真正经过推理得到的答案通常具有一致性基于捷径或随机猜测的答案多次采样会呈现较大方差。如果模型在某个领域准确率高但一致性差这个结论很可能是“抢答”产生的不是稳定推理的结果。5. 评测协议设计的改进方向检测出 Shortcut Hacking 之后真正要做的是改进评测协议让“推理能力”和“捷径识别”在评测中被区分开。5.1 将推理过程纳入评分项评测不应该只比对最终答案应该把推理步骤拆分成多个评分节点。每个节点独立给分如果一个节点缺失或逻辑错误即使最终答案正确也不能给满分。一个简单的评分配置可以这样设计{ scoring: { final_answer_weight: 0.3, reasoning_steps_weight: 0.5, format_weight: 0.1, consistency_weight: 0.1 }, requirements: { must_contain: [formula, substitution, unit_conversion], forbidden: [direct_answer_without_reasoning] } }权重可以根据场景调整但原则是推理步骤的权重不能低于最终答案。5.2 使用“过程约束”提示模板评测时可以在提示词中显式约束模型的输出格式要求先写已知条件、再列公式、再代入计算、最后给出结论。这不能完全阻止 Shortcut Hacking但能减少模型“只输出答案”的情况便于后续审查。一个参考模板请按以下步骤回答题目 1. 提取题目中的已知条件和目标量 2. 写出需要用到的公式或定理 3. 代入数值进行计算保留单位和有效数字 4. 在“最终答案”一行输出结论。 题目{question}这类提示词不改变题目本身只是强制暴露推理过程让评估系统有内容可查。5.3 建立“过程-结果”联合评分脚本自动化评分时建议同时输出结果评分和过程评分便于对比。def evaluate_sample(sample, predicted_answer, reasoning_text): result_score 1.0 if predicted_answer.strip() sample[gold_answer].strip() else 0.0 reasoning_score check_reasoning_steps(reasoning_text, sample[required_steps]) final_score 0.3 * result_score 0.7 * reasoning_score return { result_score: result_score, reasoning_score: reasoning_score, final_score: final_score, suspect_shortcut: result_score 1.0 and reasoning_score 0.5 }这段代码展示的是思路实际落地时check_reasoning_steps可以是规则匹配、关键词检测也可以是另一个小模型做的分类任务。5.4 对测试集做分层保留不要把所有测试题一次性开放。把一部分题目设为“保留集”只用于最终评估不在验证阶段使用。这样可以降低模型通过多次尝试记住测试题分布的风险。保留集设计可以参考以下配置test_split: visible: 80% held_out: 20% held_out_usage: final evaluation only perturbation_generation: on held_out set basis5.5 报告多个指标而不是单一准确率评测报告中建议至少包含以下指标最终答案准确率推理过程完整率推理步骤错误率答案一致率多次采样Shortcut Hacking 疑似样本比例。单一准确率无法反映评测质量多个指标组合在一起才能帮助判断“分数上涨”到底是能力上涨还是捷径得分。6. 批量评测与自动化流水线设计评测一个模型通常要跑大量题目这里涉及批量任务设计。批量评测不只是一个 for 循环还需要考虑日志记录、失败重试和离线分析。6.1 评测任务队列设计建议将评测任务拆成三个目录原始题目、中间推理结果、评分结果。evaluation/ ├── datasets/ # 原始题目 │ ├── physics.json │ ├── chemistry.json │ └── biology.json ├── outputs/ # 模型推理结果 │ ├── physics/ │ ├── chemistry/ │ └── biology/ └── scores/ # 最终评分 ├── final_score.csv └── process_score.csv批量评测时每个任务写入独立日志异常时记录错误原因而不是直接中断整个流水线。6.2 评测请求的批量执行如果模型通过 API 提供服务批量评测需要注意限流和超时。可以参考下面的 Python 模板import requests import time import json def evaluate_in_batch(items, api_url, max_retries3): results [] for idx, item in enumerate(items): for attempt in range(max_retries): try: resp requests.post( api_url, json{question: item[question], prompt_template: item[template]}, timeout60 ) resp.raise_for_status() data resp.json() results.append({ id: item[id], answer: data.get(answer), reasoning: data.get(reasoning), status: success }) break except Exception as e: if attempt max_retries - 1: results.append({ id: item[id], answer: None, reasoning: None, status: ffailed: {str(e)} }) time.sleep(2) return results这只是一个通用模板。实际接口地址、参数名、返回结构需要按具体模型服务的文档调整。6.3 失败重试与结果复核批量评测过程中网络超时、并发限制、服务 5xx 错误都很常见。建议对失败任务单独记录最后统一重试而不是在循环中反复重试同一个任务。这样既能提高成功率又能保留完整的失败日志便于定位问题。6.4 评测结果与元数据归档每个评测批次都要记录评测时间、模型版本、提示词版本、数据集版本。这些元数据看起来琐碎但 Shortcut Hacking 分析高度依赖版本回溯能力。如果发现评测结果异常可以通过元数据定位是模型更新、提示词变化还是数据集调整引起的。7. 资源占用与性能观察Shortcut Hacking 评测流程通常包含推理链生成和过程审核这会带来额外的推理成本。7.1 推理链生成对计算资源的影响要求模型输出推理步骤会明显增加输出 token 数。相比只输出最终答案带推理链的输出往往要高出 3 到 10 倍。对 GPU 推理服务来说输出 token 数是影响显存占用和推理时延的重要因素。显存占用需要以实际模型和推理框架为准。可以重点观察三个指标单请求最大显存占用批量并发时的显存峰值推理链模式相比纯答案模式的显存增量。如果使用本地 GPU 推理建议先用小批量测试观察显存余量再逐步增加并发。7.2 CPU 推理与 GPU 推理的差异CPU 推理在生成短答案时还可以接受一旦要求长链条推理输出时延会明显上升。更稳妥的做法是评测阶段优先使用 GPU 推理并把推理链单独缓存避免重复计算。如果只能用 CPU 推理建议缩减评测集规模或降低输出长度上限。7.3 如何降低推理链评测成本只在重点样本上要求完整推理链普通样本只做答案评测对推理链做长度限制要求模型精炼输出把评分阶段放到离线不占用在线推理资源对已验证安全的高频样本做缓存避免重复请求。这些方式都能在不严重损失评测质量的前提下控制资源消耗。8. 常见问题与排查方法问题现象可能原因排查方式解决方案模型答对但推理过程为空提示词未强制要求推理查看请求日志和输出记录在提示词中加入推理步骤要求模型在扰动后分数骤降模型依赖表面特征对比原始题和扰动题准确率加入对抗性变体评测推理步骤有但逻辑错误推理链生成不稳定人工抽检推理链加入过程评分节点多次采样答案不一致模型在猜测而非推理计算多次采样一致性指标增加采样次数并做一致性过滤某个选项位置准确率异常偏高存在选项位置泄露按选项位置统计准确率打乱选项顺序评测分数涨但下游效果不涨模型拟合基准分布用保留集做最终评估隐藏保留集只做离线评估批量任务大量失败接口限流或超时查看服务端日志增加重试间隔和失败重试队列推理链输出过长提示词缺少长度约束统计输出 token 分布设置最大输出长度或精简要求排查时首先确认评测日志是完整的。没有日志所有问题都无法复现。建议把原始请求、模型输出、评分结果、版本号存成一条完整记录再定位问题。9. 最佳实践与合规建议Shortcut Hacking 不只影响论文结论也会在实际技术决策中带来风险。这里给出几条工程化建议。9.1 第一次先跑小样本大规模评测之前先抽样 30 到 50 道题跑一次完整的答案加推理链流程生成一份过程评分报告。确认没有明显捷径特征后再扩展到全量评测。这一步成本很低但能避免整个评测流程在错误协议下重复劳动。9.2 建立最小可运行评测配置保留一组固定的 few-shot 示例、提示词模板和评分规则形成一份“最小可运行配置”。当模型版本或数据集更新时先在这份配置上跑回归快速判断评测是否失效。9.3 数据与结果分目录管理评测不只是跑一次它是一套持续运行的流程。输入数据、推理结果、评分结果、日志要分目录存储避免互相覆盖。9.4 接口服务限制访问范围如果评测系统使用 API 服务接口默认绑定内网地址不要对外暴露。请求接口加入鉴权防止被外部任务占用资源。9.5 使用公开基准时注意授权与隐私科学基准测试题可能涉及版权、机构私有数据或未公开的学术材料。使用前确认数据授权范围不要将受限数据随意上传到第三方 API 服务。涉及科研数据时优先使用本地推理或在授权环境内处理。9.6 发布结论前做效果复核如果评测结果要用于模型选型或技术报告必须对高得分样本做抽检确认推理过程真实可靠。尤其是“答案正确但推理可疑”的样本要单独列出并分析原因。10. 总结与下一步Shortcut Hacking 提醒我们一个直接的事实评测分数和真实推理能力之间存在一条容易被忽略的裂缝。答对题可能只是匹配到了模式而不是完成了推理。对于前沿科学基准这类高结构化任务这种风险尤其突出。建议读者在下一轮模型评测中先做三件事在提示词层要求模型输出推理链并记录完整过程对部分题目做扰动测试观察模型是否依赖表面特征在最终评测报告中同时给出答案准确率和推理过程完整率不要只报一个数字。评测协议本身也应该被当作系统来维护。数据版本、提示词版本、模型版本、评分规则每一层都要有记录。只有把评测流程的可信度提上去那些关于 LLM 推理能力的结论才真正站得住。