用代码解释大模型：可执行验证重塑LLM行为评测

摘要：研究提出“代码解释”方法：让大模型生成覆盖整个数据集的可执行程序，而非逐样本生成难以复核的思维链。程序运行结果可与模型输出自动比对，以 Consistency 指标筛选候选解释，并借助执行反馈继续修正。论文在三个开源代码模型、八项任务及 Claude Opus 5.5 上验证：代码解释比 CoT 短 6—100 倍，但在 24 个设置中的 9 个更贴近模型行为；对语言结构复杂的任务，一致性会降至无信息基线附近。该工作把解释从“看起来合理”推进到“能否复现模型”，但尚不能证明代码真正揭示了模型的内部推理机制。

---

从自然语言解释转向可执行解释

这项研究的核心并不是再生成一段更长的 Chain-of-Thought（CoT），而是改变解释的基本单位：让模型编写一个覆盖整个输入数据集的确定性程序。程序输出与 LLM 在相同输入上的实际输出若一致，就能由执行环境自动核验。

论文定义的核心指标是 Consistency：

[ C(P,M,D)=\frac{1}{|D|}\sum_{x\in D}\mathbf{1}[P(x)=M(x)] ]

其中，(P) 是模型生成的解释程序，(M) 是被解释模型，(D) 是验证数据集。该指标衡量的是程序在多大比例的样本上复现模型行为，而不是程序是否与模型内部计算图完全相同。候选程序可按这一分数排序，Claude Opus 5.5 的实验还把不一致样本和执行结果反馈给模型，用于迭代修改程序。

为什么程序比逐样本 CoT 更可测

传统 CoT 是针对单个输入生成的文本。它可以解释某次回答，却很难直接回答另一个测试样本中的问题是否遵循相同规则。代码解释则把规则压缩为可执行对象：输入进入函数，输出可直接与标签或模型答案比较，并可加入单元测试、边界条件和反例分析。

工程上可把它实现为“生成—执行—比对—修正”闭环：

1. 向模型提供训练或验证输入以及目标任务定义；
2. 要求模型输出候选程序、类型签名和依赖；
3. 在沙箱中执行程序，记录异常、超时和输出差异；
4. 以 Consistency 或任务准确率筛选候选；
5. 将失败样本与执行日志回传，继续生成或修订程序。

这一机制能够把解释评估从人工阅读扩展到批量回归测试。代码还可以被静态分析、单元测试和形式化检查，因而比自由文本更容易进入审计流水线。

实验结果：压缩率很高，解释有效性并不稳定

研究覆盖三个开源代码能力模型、八项任务，并扩展至 Claude Opus 5.5。代码解释比 CoT 短 6—100 倍，在全部 24 个模型—任务设置中的 9 个，其输出比 CoT 更贴近被解释模型。

但“短”并不等于“更真实”。在包含复杂语言结构的任务上，程序的一致性显著下降，甚至不高于无信息基线；生成的程序也更常依赖较长的硬编码模式。这意味着模型可能没有提炼出紧凑、稳定的决策规则，只是在用条件分支重新编码输入表面特征。

执行反馈确实提升了 Claude Opus 5.5 的一致性，却没有消除复杂任务上的落差。反馈闭环可以修正明显错误，却不能自动解决“模型行为本身高度非线性或对提示敏感”的建模难题。

指标解释与评测边界

Consistency 衡量的是行为拟合，不是因果解释。即便程序达到很高一致率，也可能只是复现数据集上的统计规律，或借助硬编码查找表覆盖测试样本。要区分真正规则与过拟合，至少还需要检查：

• 在未见输入和分布漂移数据上的一致性；
• 程序是否包含异常庞大的常量、字符串或标签查找表；
• 删除部分输入特征后，程序与模型是否以相同方式退化；
• 对抗样本、边界值和反事实输入上的同步失败率；
• 程序规模、运行时间和依赖复杂度；
• 与规则学习、决策树及符号程序等基线的公平比较。

因此，Consistency 更适合作为“可验证行为模型”的评价指标，而不能单独充当“模型真实推理过程”的证明。高一致性仍是必要条件，却不是充分条件。

工程权衡：可执行性换来测试成本

代码解释的主要优势是可自动验证，但代价同样明确。

输入侧：验证程序需要覆盖多个输入，才能观察模型跨样本的一致行为。数据集越大，解释程序的统计意义越强，但执行成本也越高。

输出侧：若任务输出是开放文本，仅比较精确字符串会低估语义一致性；若使用模型裁判或嵌入相似度，又会引入额外模型成本和非确定性。更稳妥的做法是把结构化标签、数值容差和语义等价检查分层处理。

安全侧：生成代码必须置于无网络、有限 CPU、内存和执行时间预算的沙箱中，并限制文件、进程和系统调用。解释系统本身不能成为任意代码执行入口。

模型侧：执行反馈要求模型根据失败日志改写程序，可能增加推理 Token、工具调用轮次和总体时延。对延迟敏感场景，应先生成多个短候选，再仅对高价值或不一致样本人工执行验证。

开发者落地建议

在实际系统中，代码解释适合用于分类、抽取、路由、规则判断和格式化等输入输出边界清晰的任务。它可以作为模型行为回归测试的补充：先用程序解释近似线上模型，再在固定数据集中比较两者差异，从而发现提示更新、模型升级或数据分布变化造成的漂移。

推荐将以下指标纳入上线门槛：

• 留出集 Consistency，而非仅报告训练集拟合度；
• 程序长度、硬编码常量和条件分支数量；
• 沙箱执行成功率、平均延迟与超时率；
• 与原始模型的标签级、语义级一致性；
• 反事实与对抗输入上的同步错误率；
• 失败样本分类，例如逻辑错误、缺失规则、边界处理和分布外输入。

若程序在留出集上明显落后于 CoT，或主要依赖查找表与长分支，就不应把它包装成可靠的模型解释。可以保留它作为轻量代理模型，但同时记录其适用边界。

研究意义

这项工作最有价值之处，是把 LLM 解释从不可自动复核的自然语言陈述，推进到可执行、可回归、可做反事实测试的程序对象。它尤其适合构建“模型行为测试夹具”：开发者在更换模型或提示词后，不必只靠人工阅读回答差异，而可以运行解释程序快速定位漂移。

不过，研究证明的是代码解释在部分任务上能以极短形式复现模型行为，并可通过执行反馈改善复现率；它尚未证明这些程序等价于 LLM 的内部推理，也未证明复杂语言任务上的低一致性可以通过更大模型、更多数据或更复杂优化彻底解决。可验证性提升了，解释的因果深度仍待进一步研究。

---

消息来源：ArXiv Machine Learning (cs.LG) (2026-11-13)

—— 完 ——

主题标签： #LLM可解释性 关注 #可执行解释 关注 #Consistency指标 关注 #模型行为验证 关注 #代码生成 关注