💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

本文介绍了 OpenCoder，这是一个能够估计并利用特定来源不确定性的不确定性感知框架，旨在通过过滤和排序异构检索证据来提高仓库级代码生成的正确性，并证明了其收益取决于特定的大语言模型后端以及证据间的相互作用。

原作者： Chandan Kumar Sah, Xiaoli Lian, Li Zhang

发布于 2026-07-29

📖 1 分钟阅读☕ 轻松阅读

原作者： Chandan Kumar Sah, Xiaoli Lian, Li Zhang

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

想象一下，你正试图搭建一座复杂的乐高城堡，但你手里拿到的只有一本只涵盖了前门构造的说明书。你知道门怎么造，但城堡还需要窗户、屋顶和一个秘密的地底通道。这就是人工智能（AI）在尝试编写用于现实世界项目的计算机代码时所面临的日常挣扎。虽然 AI 在编写小型、孤立的代码片段方面已经变得非常出色，但当被要求构建一个能够融入庞大现有软件“社区”的东西时，它往往会迷失方向。为了解决这个问题，研究人员使用了一种叫做**检索增强生成（Retrieval-Augmented Generation, RAG）**的技术。把 RAG 想象成给 AI 配备了一个超强能力的搜索引擎：在它写下第一行代码之前，它会查找类似的项目，检查“社区规则”（项目的特定规范），并找到可以使用的正确工具（API）。

然而，这里有一个陷阱。仅仅因为搜索引擎找到了大量信息，并不意味着这些信息是有用的。有时，AI 找到的一段代码看起来很相似，但实际上会破坏项目；或者有时，它找到的工具并不适合特定的任务。信息就在那里，但它们是嘈用的、冲突的，或者干脆就是错误的。研究人员一直在追问的一个核心问题是：我们如何教会 AI 不仅仅是去“寻找”正确的信息，还要知道“该信任多少”信息？如果 AI 无法分辨出一个有用的线索和一个误导性的红鲱鱼（假线索）之间的区别，那么它建造的城堡会在你试图打开门的那一刻就崩塌。

这正是来自北京航空航天大学研究人员的一项新研究所关注的重点。他们引入了一个名为 OpenCoder 的系统，它扮演着 AI 的一位怀疑论者且高度组织化的项目经理的角色。OpenCoder 不会盲目信任搜索引擎找到的每一条信息，而是为每一条线索分配一个“怀疑得分”。它会询问：“我们对这个 API 是正确的确定性有多高？”或者“这段相似的代码与我们的项目发生冲突的可能性有多大？”通过将不确定性视为一种有用的信号而非漏洞，OpenCoder 过滤掉了噪音，根据线索看起来有多可靠对其进行排序，甚至知道何时停止并修复自己的错误。

研究人员通过要求 AI 完成 32 个不同的现实世界任务来测试这个系统。他们发现，当使用强大的 AI 模型 GPT 时，OpenCoder 将最终代码的成功率从使用标准搜索方法的 56.25% 大幅提升到了 78.13%。然而，研究人员发现了一个关键的细微差别：这种提升与一个使用了标准搜索但增加了“验证与修复”步骤的对照组的表现相匹配。这表明，虽然 OpenCoder 的不确定性过滤机制有所帮助，但成功的巨大飞跃主要源于该系统的验证和纠错能力，而不仅仅是过滤本身。其“秘方”不仅在于找到更多信息，更在于系统能够说：“这件特定的证据看起来不太靠谱，所以我们忽略它，”以及“那件看起来很扎实，所以我们使用它，”同时还拥有一个捕捉错误的防护网。

不过，这个故事并非简单的“AI 永远获胜”。研究人员谨慎地指出，这种成功很大程度上取决于使用的是哪种 AI “大脑”。当他们将 GPT 换成另一个名为 Gemini 的模型时，结果就不那么明确了。改进并不具有统计学上的显著性，这表明 OpenCoder 的“不确定性雷达”在不同的 AI 个性下表现各异。此外，当项目缺失过多信息时，该系统会遇到瓶颈。在这些证据不完整的案例中，一个带有验证和修复功能的标准系统表现实际上优于 OpenCoder。这表明，当搜索引擎最初无法找到必要的工具时，OpenCoder 的过滤机制有时会抑制掉仅有的少量可用证据，而不是改善最终决策。

研究还意外地发现了不同类型的信息是如何协同工作的。你可能会认为，拥有“相似代码”、“项目上下文”和“API 知识”总是比只拥有其中之一更好。但研究人员发现，并没有统一的规律。有时，增加“相似代码”反而会干扰 AI，除非它能与正确的“项目上下文”配对。这就像拥有地图、指南针和 GPS：如果你只有 GPS，你可能会迷路；如果你有地图和指南针但没有 GPS，你可能也没问题；但如果你三者都有且它们相互矛盾，你可能会原地打转。每个线索的价值完全取决于其他线索的存在情况。

为了实现这一目标，OpenCoder 执行的是一个五步舞步。首先，它构建一个包含所有项目规则和工具的库。第二，它将用户的请求分解为小的步骤。第三，它开始搜寻线索，但这次它会根据线索感觉到的“不确定性”进行评分。第四，它生成代码，但会密切关注“不确定性得分”，以避免使用不靠谱的线索。最后，也是最重要的一步，它充当自己的质量控制检查员。它通过一系列测试运行代码。如果代码失败，它不会直接放弃；它会识别错误，并根据验证反馈尝试修复代码。

最后，论文指出，AI 编程的未来不仅仅是让 AI 变得更聪明或给它更多的数据。其核心在于教会 AI 保持谦逊和批判精神。通过将不确定性作为引导决策的工具——过滤坏数据、验证输出并即时修复错误——像 OpenCoder 这样的系统可以构建更可靠的软件。但正如研究人员警告的那样，这并不是一个在任何情况下都奏效的魔杖。它在 AI 拥有足够好的信息来处理，并且特定的 AI 模型能够正确理解“怀疑得分”时效果最好。目前，OpenCoder 是一个强有力的进步，它证明了有时，知道自己“不知道什么”才是解开谜题最重要的部分。

技术摘要：超越“检索什么”：检索增强代码生成中的不确定性

问题陈述

仓库级代码生成要求大语言模型（LLM）能够合成既符合跨文件依赖关系、又遵循项目规范及私有 API 的实现。虽然检索增强生成（RAG）通过提供外部仓库证据解决了参数化知识的局限性，但现有方法主要侧重于优化“检索什么”信息（例如：相似代码、仓库上下文、API 知识）。它们在很大程度上忽略了这些证据固有的“不确定性”。

检索到的证据通常是异构且不可靠的：相似的代码示例可能在语义上相关，但在功能上却不兼容；仓库上下文可能包含冗余或冲突的依赖项；API 知识可能是不完整的或作用域错误的。现有方法仅优化检索相关性，而没有明确建模这些来源中的不确定性如何影响下游的生成、验证与修复。因此，结合额外的证据可能会引入噪声并传播检索错误，导致生成的代码虽然可执行，但仍存在大量的 API 误用或功能缺陷。

方法论：OpenCoder

作者引入了 OpenCoder，这是一个将不确定性视为“可操作控制信号”而非“事后置信度评分”的感知不确定性框架。该框架通过五个阶段运行：

仓库知识与不确定性剖析： 构建一个包含三种证据来源的索引：项目特定 API ( $A$ )、上下文仓库代码 ( $X$ ) 以及语义相似的代码示例 ( $S$ )。
查询不确定性分解： 将用户查询分解为实现步骤，并预测每个步骤所需的证据。
不确定性感知多源检索： 从 $A$ $A$ 、 $X$ $X$ 和 $S$ $S$ 中检索候选对象。至关重要的是，OpenCoder 为每个检索项分配一个特定来源的不确定性得分 $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ ，其中较高的值表示对相关性、完整性或兼容性的置信度较低。
- 证据通过结合余弦相似度 ( $r_m$ )、预测的来源意图权重 ( $w_m$ ) 和不确定性进行评分： $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ 。
- 低置信度的证据会被过滤，剩余项会在共享的上下文预算下进行去重和排序。
不确定性引导的代码生成： LLM 在以查询、过滤后的证据集以及来源级不确定性轨迹为条件的条件下生成候选代码。
验证与不确定性缓解： 生成的候选代码经过静态检查和可执行测试。系统选择第一个通过测试的候选对象。如果没有任何原始候选对象通过，系统会识别出“众数”（mode）候选对象（即来自最大的自一致性组），并进行最多两轮的基于验证引导的修复。

该框架还采用了目标感知 API 精炼（Target-Aware API Refinement），在生成前移除自检索的、冗余的或意图不兼容的 API。

核心贡献

公式化： 本文将仓库级代码生成公式化为在异构证据下的不确定性决策问题，超越了简单的相关性排序。
框架： OpenCoder 是一个统一的系统，它估计特定来源的不确定性，并将其在证据过滤、多源集成、生成、验证和修复过程中实现操作化。
因子分析： 通过对 API 知识、仓库上下文和相似代码证据进行全因子分析，作者证明了检索效用具有交互依赖性。不存在通用的证据来源加性排序；特定来源的价值取决于伴随的证据以及 LLM 后端。
受控评估： 作者在 GPT 和 Gemini 后端上针对可执行的仓库级任务进行了严格的匹配评估，将不确定性感知处理与下游验证及修复的效果进行了隔离。

实验结果

评估使用了扩展的 32 个匹配的 RepoExec-inline 任务集，以及针对 10 个部分上下文 ExecRepoBench 任务的压力测试。

GPT 表现： 在 32 个 RepoExec-inline 任务集中，OpenCoder 将选定输出的正确率从 56.25%（基准 RAG）提升至 78.13%（提升了 21.88 个百分点，标称 $p = .039$ ）。然而，它与 RAG + 验证/修复 控制组（使用相同的证据但缺乏不确定性感知过滤）持平，这表明相对于基准 RAG 的增益主要由验证/修复预算驱动，而非仅由不确定性过滤驱动。
Gemini 表现： 对于 Gemini，OpenCoder、基准 RAG 与控制组之间的差异在统计学上并不显著。控制组（RAG + 验证/修复）在大多数指标上表现最强。
交互效应： 因子分析（RQ1）显示，没有任何单一的证据来源对性能产生显著的边际效应。相反，观察到了显著的跨来源交互作用（例如，仓库上下文与相似代码证据对 GPT 表现出正向交互）。
API 检索： 目标感知精炼显著改善了 API 集检索，使 GPT 的宏观 F1 值从 43.4% 提高到 64.8%，Gemini 从 43.4% 提高到 59.1%。
边界条件： 在上下文受限的 ExecRepoBench 压力测试中，RAG + 验证/修复控制组的表现明显优于 OpenCoder。这表明当仓库证据不完整时，不确定性机制可能会抑制有用的替代方案，而非提升最终决策。

重要性与主张

本文主张，不确定性最有价值之处不在于作为孤立的置信度估计，而是作为一种与证据融合、可执行验证及修复相结合的可操作控制信号。

后端依赖性： OpenCoder 的收益取决于后端。虽然它显著提高了 GPT 的输出选择效果（相对于纯 RAG），但它并未表现出相对于“验证与修复控制组”的统计学显著优势，也未在 Gemini 上表现出明显的优势。
证据完整性： 该框架的有效性依赖于仓库证据的完整性。在证据不完整的场景下，不确定性机制可能会误将必要信息过滤掉。
可操作控制： 主要贡献在于从优化“检索什么”转向建模“检索到的证据有多可靠”，并利用该信号来引导过滤与生成。

作者总结道，虽然 OpenCoder 展示了不确定性感知集成的潜力，但其优势取决于特定的 LLM 后端以及检索到的仓库证据的质量/完整性。他们强调，生成的代码仍需开发人员进行审查和项目特定的测试。