🤖 AI

Semantic Voting: Execution-Grounded Consensus for LLM Code Generation

本文表明，对于缺乏完整预言机的 LLM 代码生成任务，基于执行的共识方法显著优于输出模式投票，且生成测试输入的质量是成功的主要驱动因素，而非所采用的具体聚合规则。

原作者： Shan Jiang, Zijian Yi, Chenguang Zhu

发布于 2026-05-12

📖 1 分钟阅读☕ 轻松阅读

原作者： Shan Jiang, Zijian Yi, Chenguang Zhu

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

想象你是一位招聘经理，正试图为编程职位挑选最佳候选人。你拥有一个由人工智能生成的庞大申请人池，但没有完美的“答案密钥”来核对他们的工作。你只能根据他们在测试中的表现来猜测谁是对的。

这篇论文就像一场大规模实验，旨在找出进行这场面试并选出获胜者的最佳方法。研究人员使用各种人工智能模型测试了 18 种不同的场景，并发现了关于如何选择正确代码的三大秘密。

以下是用简单术语进行的分解：

1. 问题：“全有或全无”的陷阱

大多数系统目前使用一种称为多数投票（Majority Voting）的方法。想象一下，你给所有候选人出一道数学题。如果候选人答对了，他们就得一票；如果答错了（或程序崩溃），他们就一票不得。得票最多的人获胜。

论文认为，这就像一台坏掉的投票机。

缺陷：如果候选人在一个奇怪的测试题上犯了一个微小的错误（例如除以零），系统就会将他们的整个申请扔进垃圾桶，即使他们在其他所有方面都完美无缺。
结果：这种方法经常选错人，或者根本选不出任何人，因为它对微小错误过于敏感。

2. 解决方案：“指纹”方法（语义投票）

研究人员提出了一种新方法，称为语义投票（Semantic Voting）。他们不再仅仅检查“对或错”，而是查看候选人的指纹。

类比：想象你不再只问“你解出谜题了吗？”，而是观察他们如何解出谜题。他们是否在某个特定步骤卡住了？他们是否在某种特定类型的数字上崩溃了？
工作原理：系统在许多不同的测试输入上运行代码。它记录确切的结果模式（例如，“得出答案”、“在负数上崩溃”、“超时”）。它将具有完全相同模式的候选人归为一组。
优势：即使所有人都在一个奇怪的测试上崩溃，系统仍然可以看到 50 名候选人中有 40 名以完全相同的方式崩溃，而另外 10 名以不同的方式崩溃。它选择具有最一致“指纹”的组，保留了旧方法会丢弃的宝贵信息。

3. 三大发现

发现 #1：“指纹”大获全胜

新的“指纹”方法（以及类似的基于执行的方法）比旧的“对/错”投票好得多。

数据：它在各方面的准确率提高了19% 到 52%。
结论：与其只计算代码获得满分的次数，不如关注代码行为的细节，这要好得多。

发现 #2：“测试题”比“评分规则”更重要

一旦你决定使用“指纹”方法，具体使用哪种规则来统计票数其实并不重要。无论你使用新的“语义投票”、“加权投票”系统还是"MBR"系统，它们的性能几乎完全相同。

真正的英雄：最重要的因素是你如何创建测试题。
类比：想象你在测试一辆汽车。
- 糟糕的测试：你只在完美平滑、空旷的道路上行驶（随机模糊测试或简单示例）。汽车看起来很棒，但在现实世界中却失败了。
- 好的测试：你请专家设计特定场景：“在泥泞的山坡上行驶”、“穿过水坑”、“倒车行驶”。
结果：使用“基于草图”的输入（即要求人工智能发明特定类型的挑战，如“包含重复项的列表”或“空列表”）是成功的最大单一因素。它比随机测试高出多达11%。
教训：如果你的测试题好，具体的计分方式就不太重要。如果你的测试题不好，没有任何评分规则能救你。

发现 #3：“深度思考”并不总是有帮助

研究人员测试了让 AI“更努力地思考”（在回答前花费更多时间进行推理）是否有帮助。

意外：对于旧的“对/错”投票，更努力地思考有很大帮助。但对于新的“指纹”方法，更努力地思考实际上使情况略微变差或保持不变。
为什么？当 AI 思考得太深入时，它倾向于产生非常相似的答案。这减少了候选人的“多样性”。如果每个人都如此努力地思考，以至于都犯了相同的错误，系统就无法找到独特且正确的解决方案。就像一个合唱团，每个人都完美地唱准了同一个错误的音符；这无助于你找到正确的歌曲。

总结：我们应该怎么做？

论文得出结论，当我们没有完美的答案密钥时，证据的质量比用来统计它的规则更重要。

停止使用简单的“通过/失败”投票。它丢弃了太多有用的信息。
专注于制作更好的测试用例。要求人工智能生成多样化、具体的场景（如“负数列表”），而不仅仅是随机的。
不要过度纠结于评分。一旦你有了好的测试和跟踪行为的方法，用来选出获胜者的具体数学方法就无关紧要了。
不要强迫 AI 思考太久。有时，答案中的一点多样性比每个人都试图做到完美更好。

简而言之：更好的问题胜过更好的评分规则。

技术摘要：语义投票——面向大语言模型代码生成的执行落地共识

问题陈述

大语言模型（LLM）能够生成代码，但在缺乏完整预言机（即完整测试套件）的情况下，从多个采样候选解中选择正确解仍然具有挑战性。现有的流程通常结合文本投票、排序启发式方法和基于执行的共识，但这些组件的相对贡献尚不明确。具体而言，先前的工作往往混淆了两个关键维度：

更丰富的行为证据（例如，异常感知的执行轨迹）与“全有或全无”的输出模式投票之间的价值对比。
一旦利用行为证据，输入质量与聚合规则之间的相对重要性。

当前的基线方法，如输出模式多数投票（MV），通常会丢弃在任何生成输入上崩溃的候选解，将选择过程简化为拼接返回字符串的精确匹配。这种方法对不完美的生成输入敏感，且无法保留部分行为证据。

方法论：SEMANTICVOTE 与实验设计

SEMANTICVOTE 流程

作者引入了 SEMANTICVOTE，一种旨在研究基于执行共识的方法。与标准的多数投票（MV）不同，SEMANTICVOTE 保留了“异常感知的执行指纹”。

候选解生成：LLM 采样 $N$ 个候选解。
输入生成（基于草图）：LLM 生成 $K$ 个抽象输入草图（例如，“空列表”、“包含重复项的列表”），旨在针对不同的行为等价类。每个草图使用具体值实例化 $M$ 次，产生 $D = K \times M$ 个多样化的测试输入。
指纹提取：每个候选解在沙箱中针对所有 $D$ 个输入执行。系统记录一个指纹向量：每个输入对应一个 (状态，值) 对的元组，其中状态包括成功、异常类型或超时。
聚类：根据指纹的精确相等性对候选解进行聚类。
选择：系统从最大的簇中选择代表。如果存在“全成功”簇，则优先选择；否则，选择最大的异常感知簇。返回所选簇中最短的程序（奥卡姆剃刀原则）。

实验设置

该研究评估了 18 种配置，涵盖：

模型：三个 Gemini 预览端点（3.1 Pro, 3 Flash, 3.1 Flash Lite）。
思考级别：低、中、高。
基准测试：HumanEval+ 和 MBPP+（显著增加测试用例的增强版本）。

作者将 SEMANTICVOTE 与以下方法进行了比较：

输出模式多数投票（MV）：丢弃任何存在执行错误的候选解；按精确输出字符串进行聚类。
加权投票（WV）：按输出模式分组，但根据候选解的成功率进行加权。
MBR-Exec：选择在输入输出/异常上达成一致总和最高的候选解。
AST 归一化 MV：一种结构基线，按规范 AST 结构进行分组。

主要发现

1. 基于执行的选择优于输出模式投票

在所有 18 种配置中，最佳的基于执行的选择器（SEMANTICVOTE、WV 或 MBR-Exec）比输出模式多数投票高出 19–52 个百分点。

输出模式 MV 的表现始终低于简单的“最佳 N 选”（选择第一个语法有效的候选解），并且当生成的输入导致所有候选解崩溃时，它经常完全失效。
MV 的主要失败模式是其“全成功”过滤器，该过滤器会丢弃那些在基准测试中正确但在特定生成输入上失败的候选解。基于执行的方法保留了部分一致性和异常类型，从而能够恢复正确的解。

2. 输入质量是性能的主要驱动因素

一旦候选解在多样化输入上执行，具体的聚合规则（SEMANTICVOTE 与加权投票与 MBR-Exec）产生的影响有限。

统计不可区分性：配对 Bootstrap 测试显示，在所有 18 种配置中，SEMANTICVOTE 与其他基于执行的聚合器之间没有显著差异（ $p > 0.05$ ）。性能差异微乎其微（例如，SEMANTICVOTE 与加权投票的差异仅为 $-0.79 $到$ +0.61$ 个百分点）。
输入策略的主导地位：输入生成策略的选择是方差的最大来源。
- 基于草图的生成（将抽象类别具体实例化）是最强的策略，比直接的 LLM 输入生成高出 0.6–2.1 个百分点，比随机模糊测试或仅示例输入高出多达 11.3 个百分点。
- 这种优势一致地传递给所有三种基于执行的聚合器。

3. 与思考深度的交互

“思考级别”（推理预算）的影响在选择器家族之间有所不同：

输出模式 MV：更深层的思考通过生成更一致输出来提升性能（例如，在 HumanEval+ Flash 上提升 +12 个百分点）。
基于执行的方法：随着思考深度的增加，性能保持平稳或略有下降。作者推测，更深层的思考减少了候选解的多样性，留下的可被利用的不同行为簇更少，从而限制了基于执行共识的效用。

4. 预言机差距分解

失败分析显示，生成失败（候选池中不存在正确候选解）是主导瓶颈，占错误的大多数。选择失败（存在正确候选解但未被选中）平均仅为 1.5–2.7%。

由于正确候选解的池很小，任何聚合规则都几乎没有空间来区分性能，这解释了 SEMANTICVOTE、WV 和 MBR-Exec 的收敛。
增加测试输入数量（ $D$ ）带来的收益递减；性能在 $D=30$ 左右达到饱和，而 $D=10$ 已捕获了大部分增益。

意义与范围

本文将自己定位为实证分解，而非提出新方法。其主要贡献是将推理时的代码选择重新框架化为信号质量问题，而非聚合规则问题。

信号质量：当预言机不可用时，行为证据的质量（源自多样化、结构良好的输入）比用于聚合该证据的规则重要得多。
实际启示：为了改进代码选择，从业者应优先考虑生成多样化、具有行为代表性的测试输入（例如，通过基于草图的生成），而不是优化复杂的投票算法。
局限性：该研究仅限于 Python 基准测试和 Gemini 模型。基于草图的输入生成依赖于 LLM 的领域熟悉度，且具有故意非确定性的程序可能会产生不一致的指纹。

作者得出结论，虽然 SEMANTICVOTE 作为评估工具，但基于执行方法的收敛表明，一旦建立了高质量的行为轨迹，具体的聚类或加权机制就变得次要了。