💬 NLP

Code Is More Than Text: Uncertainty Estimation for Code Generation

本文提出了一种用于代码生成的创新三轴不确定性估计框架，该框架利用代码特有的属性（如标记脆弱性、意图-代码差距以及可执行性），在检测不可靠输出方面显著优于基于自然语言衍生的基准模型。

原作者： Yuling Shi, Caiqi Zhang, Yuexian Li, Haopeng Wang, Yeheng Chen, Nigel Collier, Xiaodong Gu

发布于 2026-06-09

📖 1 分钟阅读☕ 轻松阅读

原作者： Yuling Shi, Caiqi Zhang, Yuexian Li, Haopeng Wang, Yeheng Chen, Nigel Collier, Xiaodong Gu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一个非常有才华、但有时又过于自信的机器人助手在为你编写计算机代码。有时，它能写出完美的代码；而有时，它会写出看起来没错、但却隐藏着微小且不可见的错误的代码，这些错误会导致整个程序在稍后崩溃。

核心问题在于：机器人并不总是知道自己在犯错。 它可能会说：“我百分之百确定这是正确的！”但实际上却是错误的。这是很危险的，因为如果你信任了一个错误的程序，它可能会破坏你的软件或导致安全问题。

这篇论文介绍了一种新的询问机器人的方式：“你到底有多确定？”

作者们认为，询问关于代码的问题与询问关于写故事的问题是不同的。你不能直接使用用于文本的同一种“置信度测量仪”。他们发现了代码之所以独特的三个特殊原因，并基于这些原因构建了一个三部分的“不确定性检测器”。

以下是这个三部分检测器的工作原理，使用了简单的类比：

1. “错一块砖”问题（词法不确定性/Lexical Uncertainty）

概念： 在故事中，如果你用错了词，句子可能仍然通顺。但在代码中，如果你写错了一个符号（比如漏掉一个逗号或写错一个数学符号），整个程序就会崩溃。
类比： 想象你在搭一座纸牌屋。如果你放的一张牌稍微歪了一点，整个塔可能会倒塌。机器人的“置信度”并不是均匀分布在整个房子上的；它通常在大部分地方都没问题，唯独在那个“摇晃的卡片”处出了问题。
解决方案： 作者并没有检查整个故事，而是寻找那些“摇晃的卡片”。他们检查代码中机器人表现得最困惑（高熵）的具体部分。如果机器人在代码的哪怕一个微小片段上犹豫不决，他们就会将整个程序标记为有风险。

结果： 这种方法非常快速且成本低廉，能捕捉到其他方法会遗漏的许多错误。

2. “计划与执行”的差距（算法不确定性/Algorithmic Uncertainty）

概念： 机器人可以有一个解决问题的绝佳想法，但在实际执行步骤时出错。有时，两种不同的代码解决方案表面看起来完全不同，但做的是同一件事。而有时，它们看起来很相似，但做的事情却不同。
类比： 想象要求机器人解释如何烤蛋糕。

方法 A： 让它写出食谱（代码）。
方法 B（本文的方法）： 先让它用纯英文解释这个“计划”（“首先，混合鸡蛋，然后加入面粉……”）。
如果机器人针对同一个蛋糕给出了五种不同的计划，说明它对“策略”感到困惑。如果五个计划都一样，说明它对“逻辑”很有信心。
解决方案： 作者要求机器人生成几种不同的“纯英文计划”来对应这段代码。如果这些计划之间存在分歧，说明机器人对逻辑本身是不确定的，即使代码看起来没问题。

3. “试驾”（功能不确定性/Functional Uncertainty）

概念： 代码很特殊，因为它真的可以被“运行”。你可以看到它是否有效或无效。
类比： 想象机器人制造了一辆玩具车。与其仅仅看蓝图，不如给它一条赛道让它跑起来。

机器人制造了车（代码）。
机器人还发明了一些测试轨道（测试用例），来看看车子是否正常工作。
机器人带着车在这些轨道上行驶。
解决方案： 如果机器人在自己发明的 5 个测试轨道中有 4 个都翻车了，那么机器人应该非常不确定这辆车是否完好。这是一种直接的“行为”检查，你无法在普通文本中进行这种操作（你无法通过“运行”一段段落来观察它是否真实）。

“三脚凳”（集成系统/The Ensemble）

作者将这三种方法组合成了一个系统。

第一条腿： 检查摇晃的卡片（词法）。
第二条腿： 检查计划是否一致（算法）。
第三条腿： 检查车子能否行驶（功能）。

他们发现，将这三种方法结合在一起的效果远好于只使用其中一种。这就像拥有一个由三种不同材料制成的安全网；如果其中一个失效，其他的仍能捕捉到错误。

论文的核心要点

代码是不同的： 你不能直接复制粘贴用于写故事的方法来检查代码。代码需要自己的特殊规则。
速度 vs. 准确度： “摇晃卡片”检查（词法）速度极快，且几乎与复杂方法一样准确。这对于需要在编辑器中实现即时反馈的自动补全功能非常有用。
最佳结果： 当他们结合所有三种方法时，得到了最好的结果，能够比以往的方法更准确地识别出不确定的代码。
注释 vs. 代码： 他们发现了一个有趣的现象：机器人在“注释”（代码中的英文解释）方面的置信度其实是一个坏兆头。如果机器人在英文注释上感到不确定，通常意味着代码是错误的。但如果它对代码本身感到不确定，那才是真正的危险。

简而言之，这篇论文告诉我们：要了解机器人对代码是否有信心，不要只听它说了什么。要检查它的薄弱环节，对比它的计划，并进行一次试驾。

技术摘要：代码不仅仅是文本：代码生成的确定性估计

问题陈述

大型语言模型（LLMs）正越来越多地作为 IDE 助手和自主智能体的代码生成器进行部署。然而，静默错误的程序会带来显著的安全与可靠性风险，因为这些错误可能会绕过审查并在下游步骤中累积。虽然可靠的确定性估计（Uncertainty Estimation, UE）对于选择性预测和人机协同审查至关重要，但目前的各种方法大多是直接从自然语言（NL）生成领域移植过来的。这些源自 NL 的方法将代码仅仅视为一种 token 序列，未能利用使代码具有独特性的属性：

Token 脆弱性（Token Fragility）： 与意义在出错后仍具可恢复性的自然语言不同，单个错误的 token（例如一个运算符或索引）就可能破坏整个程序。
意图—代码间隙（Intent–Code Gap）： 算法意图可以从具体的实现中抽象出来；表层的代码变化可能隐藏着相同的逻辑，而相同的语法可能隐藏着不同的算法。
可执行性（Executability）： 代码可以针对测试用例进行执行，从而提供一种独特的关于正确性的行为信号。

本文认为，现有的 UE 方法依赖于统一的序列不确定性或表层聚类，忽略了这些关键信号。

方法论

作者提出了一个三轴框架来评估代码确定性，其中每个轴对应于代码的一个独特属性。这些信号旨在实现正交且互补。

1. 词法不确定性（Token 脆弱性）

概念： 解决代码中不确定性的稀疏性问题。该方法不再对整个序列计算平均熵（这会稀释关键错误），而是专注于最不确定的位置。
实现： Top-K Token 熵。模型生成一个贪婪输出。不确定性得分是序列中 $K$ 个最高 token 级熵（ $H(y_t)$ ）的平均值。
原理： 单个高熵 token 通常指示了一个关键决策点，即模型在此处感到犹豫，这比整个序列的平均熵更能预测失败。

2. 算法不确定性（意图—代码间隙）

概念： 在算法意图层面而非表层语法层面衡量一致性。
实现： 伪代码一致性。模型不是采样多个代码实现（这会引入实现噪声），而是被提示生成 $N$ 个描述算法步骤的自然语言解决方案计划（伪代码）。
指标： 样本间的协议程度使用 步长感知 ROUGE-L（step-aware ROUGE-L） 进行衡量，该指标将计划拆分为语义步骤并计算双向匹配。计划之间的高分歧表示高不确定性。

3. 功能不确定性（可执行性）

概念： 利用代码的可执行能力来衡量行为正确性。
实现： 行为一致性。模型生成一个候选程序和 $M$ 个自生成的测试用例。候选程序在沙盒中针对这些测试进行执行。
指标： 不确定性得分是候选程序针对其自生成测试的失败率（ $1 - \text{通过率}$ ）。这作为一个校准信号，而非像 CodeT 那样作为一种重排序机制。

集成（Ensemble）

这三个信号（ $U_{lex}, U_{algo}, U_{func}$ ）运行在不同的尺度上。作者将每个得分进行秩归一化（rank-normalize）至 $[0, 1]$ ，并通过加权求和进行组合。默认权重分别为 Lexical、Functional 和 Algorithmic 轴的 $(0.2, 0.4, 0.4)$ 。

核心贡献

三轴框架： 本文引入了一个直接映射到 token 脆弱性、算法意图和可执行性的代码特定 UE 框架，超越了源自 NL 的抽象。
实证验证： 该方法在四个基准测试（APPS-Intro, APPS-Interview, HumanEval, MBPP）和五个具备代码能力的 LLM（包括 Qwen3-14B, DeepSeek-Coder-V2, Devstral-Small-2505）上进行了评估。
成本-性能分析： 研究表明，尽管 Top-K token 熵是一种单次传递（single-pass）方法，但其性能能匹配最强的多轮传递（multi-pass）NL 基线，且计算成本降低了超过 3 倍。
信号正交性： 分析证实这三种信号捕捉到了不同的信息（低两两相关性），并针对不同的失效模式（例如：词法针对单 token 错误，算法针对策略失配，功能针对语义错误）。

结果

性能提升： 三轴集成在所有模型上将平均 AUROC 从 0.696（最强的 NL 衍生基线）提升至 0.766。在 Qwen3-14B 上，集成达到了 0.800 AUROC。
词法效率： Top-K token 熵（单次传递）实现了 0.728 的平均 AUROC，匹配了多轮传递的“一致性 (VR)”基线（0.728），同时速度显著更快（在 HumanEval 上为 2.29s vs 7.10s 每题）。
Token 范围不对称性： 对 token 范围的分析显示，仅在 代码 token 上 计算的熵（AUROC 0.716）是一个强信号，而仅在 注释 token 上 的熵表现比随机更差（AUROC 0.375）。这表明代码内部自然语言解释的不确定性与功能正确性呈负相关。
跨语言泛化： 词法信号（Top-5 熵）可泛化至非 Python 语言（C++, Java, Go, JS），始终优于单次传递基线和多轮传递一致性方法。

重要性与主张

本文声称，代码确定性估计需要进行代码特定的设计，而非直接移植自自然语言。作者认为，随着代码-LLM 部署的成熟，瓶颈正从能力扩展转向校准。

核心要点包括：

Token 脆弱性意味着代码中的不确定性是稀疏的；关注高熵 token 比计算序列平均值更有效。
伪代码抽象为一致性估计提供了比原始代码更清晰的基础，实现了意图与实现噪声的分离。
可执行性提供了一个独特的、低成本的行为信号，这在 NL 生成中是无法获得的。
实践指导： 对于延迟敏感型场景（如 IDE 自动补全），建议使用 Top-K token 熵 作为具有竞争力的低成本默认方案。当校准至关重要且成本受限较少时，完整的三轴集成框架 能提供最强的性能。

作者将这项工作定位为这些轴向的“首次实例化”，并建议未来的框架应扩展到包含其他代码特定信号（如类型检查、静态分析），而不是强行将其纳入 NL 式的估计器中。