💬 NLP

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

本論文は、ソース固有の不確実性を推定および活用することで異種混合な検索エビデンスをフィルタリングおよびランク付けし、それによってリポジトリレベルのコード生成の正確性を向上させる、不確実性を考慮したフレームワークであるOpenCoderを紹介するが、その利点は特定のLLMバックエンドおよびエビデンス間の相互作用に依存することも示している。

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

公開日 2026-07-29

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： 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に超強力な検索エンジンを与えることだと考えてください。コードを一行も書く前に、AIは似たようなプロジェクトを調べ、その地域のルール（プロジェクト固有の慣習）を確認し、使用すべき適切なツール（API）を見つけ出します。

しかし、落とし穴があります。検索エンジンが大量の情報を発見したからといって、その情報が役に立つとは限りません。AIが、見た目は似ているけれど実際にはプロジェクトを壊してしまうコードを見つけてしまうこともあれば、特定の仕事には適合しないツールを見つけてしまうこともあります。情報は存在するのですが、それがノイズであったり、矛盾していたり、あるいは単に間違っていたりするのです。研究者が問い続けてきた大きな疑問はこうです。「どうすればAIに、単に正しい情報を見つけるだけでなく、『それをどの程度信頼すべきか』を知ることができるようになるのか？」もしAIが、役立つ手がかりと、誤解を招くレッドヘリング（偽の手がかり）の違いを判別できなければ、ドアを開けようとした瞬間に崩壊してしまうようなお城を築いてしまうことになるでしょう。

ここで、北京航空航天大学の研究者による新しい研究が登場します。彼らは、AIにとっての「懐疑的で超組織的なプロジェクトマネージャー」として機能する、OpenCoderと呼ばれるシステムを紹介しています。検索エンジンが見つけたあらゆる情報を盲目的に信じるのではなく、OpenCoderはすべての手がかりに対して「疑念スコア」を割り当てます。「このAPIが正しいものであるという確信はどの程度か？」あるいは「この類似コードが私たちのプロジェクトと衝突する可能性はどの程度か？」といった具合に問いかけます。不確実性をバグとしてではなく、有用なシグナルとして扱うことで、OpenCoderはノイズをフィルタリングし、手がかりを信頼性に基づいてランク付けし、さらには自らの間違いを止めて修正する方法さえも理解しているのです。

研究者たちは、32種類の現実世界のタスクに対してAIにコードを書かせることで、このシステムをテストしました。その結果、強力なAIモデルであるGPTを使用した場合、OpenCoderは最終的なコードの成功率を、標準的な検索手法を用いた際の**56.25%から78.13%**へと大幅に向上させました。しかし、研究者たちは重要なニュアンスを発見しました。この改善は、標準的な検索に「検証と修復」のステップを加えたコントロールグループのパフォーマンスと一致していたのです。これは、OpenCoderの不確実性フィルタリングが役に立った一方で、成功率の大幅な上昇は主に、システムの「検証して修正する能力」によってもたらされたことを示唆しています。秘訣は、より多くの情報を見つけることではなく、「この特定のエビデンスは怪しいので無視しよう」と言ったり、「この別のエビデンスは確かなので使おう」と言ったりしながら、ミスを捕まえるためのセーフティネットを併用することにありました。

しかし、物語は単純な「AIの勝利」では終わりません。研究者たちは、この成功が「どのAIの脳が思考しているか」に大きく依存することを注意深く指摘しています。GPTを別のモデルであるGeminiに入れ替えると、結果ははるかに不明瞭になりました。改善は統計的に有意ではなく、OpenCoderの「不確実性レーダー」は、AIのパーソナリティによって働き方が異なることを示唆しています。さらに、プロジェクトに必要な情報が不足している場合、システムは壁に突き当たりました。このようなエビデンスが不完全なケースでは、検証と修復を備えた標準的なシステムの方がOpenCoderよりも優れた性能を発揮しました。これは、検索エンジンがそもそも必要なツールを見つけられない場合、OpenCoderのフィルタリングメカニズムが、利用可能な数少ないエビデンスさえも抑制してしまうことがあることを示しています。

また、本研究は、異なる種類の情報がどのように組み合わさって機能するかについても驚くべき発見をしました。あなたは、「類似コード」、「プロジェクトのコンテキスト」、そして「APIの知識」を持つことは、それらを一つだけ持つよりも常に優れていると思うかもしれません。しかし、研究者たちは、そこに普遍的なルールは存在しないことを発見しました。時には、「類似コード」を追加することが、適切な「プロジェクトのコンテキスト」と組み合わされていない限り、AIを混乱させてしまうことがあります。それは、地図、コンパス、そしてGPSを持っているようなものです。GPSだけがあれば迷うかもしれませんし、地図とコンパスがあればGPSがなくても大丈夫かもしれません。しかし、もし三つすべてを持っていて、それらが矛盾していたら、堂々巡りになってしまうかもしれません。各手がかりの価値は、他にどのような手がかりが存在するかによって完全に決まるのです。

これを実現するために、OpenCoderは5つのステップによるダンスを行います。第一に、プロジェクトのすべてのルールとツールのライブラリを構築します。第二に、ユーザーのリクエストを小さなステップに分解します。第三に、手がかりを探しに行きますが、今回はそれらがどれほど「不確実」であるかに基づいてスコアリングを行います。第四に、コードを生成しますが、怪しい手がかりを使用しないよう「不確実性スコア」を厳重に監視します。最後に、そしておそらく最も重要なことに、自らの品質管理検査官として機能します。コードをさまざまなテストにかけます。もしコードが失敗した場合、単に諦めるのではなく、エラーを特定し、その検証フィードバックに基づいてコードの修復を試みます。

結局のところ、この論文は、AIコーディングの未来は、単にAIを賢くしたり、より多くのデータを与えたりすることではないと示唆しています。それは、AIに「謙虚さと批判的な視点」を教えることです。不確実性を、悪いデータを排除し、出力を検証し、即座にエラーを修正するための意思決定を導くツールとして扱うことで、OpenCoderのようなシステムはより信頼性の高いソフトウェアを構築できます。しかし、研究者が警告するように、これはあらゆる状況で機能する魔法の杖ではありません。それは、AIが十分な良質な情報を持っており、かつ特定のAIモデルが「疑念スコア」を正しく理解できるように調整されている場合に最も効果を発揮します。現時点では、OpenCoderは強力な一歩であり、「自分が何を知らないかを知ること」こそが、パズルを解くための最も重要な部分であることを証明しています。

技術要約：「何を検索するか」を超えて：検索拡張コード生成における不確実性

問題提起

リポジトリレベルのコード生成には、大規模言語モデル（LLM）が、ファイル間の依存関係、プロジェクトの慣習、およびプライベートAPIを尊重した実装を合成することが求められます。検索拡張生成（RAG）は、外部のリポジトリ証拠を提供することでパラメトリックな知識の限界に対処しますが、既存のアプローチは主に「どのような」情報を検索するか（例：類似コード、リポジトリのコンテキスト、API知識）の最適化に焦点を当てています。これらは、この証拠に付随する「不確実性」をほとんど軽視しています。

検索された証拠は、しばしば異質で信頼性に欠けます。類似コードの例は、意味的には関連していても機能的には互換性がない場合があり、リポジトリのコンテキストには冗長または矛盾する依存関係が含まれている可能性があり、API知識は不完全であったりスコープが誤っていたりすることがあります。従来の手法は、検索の関連性を最適化しますが、これらのソースにおける不確実性が、ダウンストリームの生成、検証、および修復にどのように影響するかを明示的にモデル化することはありません。その結果、追加の証拠を組み合わせることでノイズが導入され、検索エラーが伝播し、APIの誤用や機能的な欠陥を含む実行可能なコードが生成される可能性があります。

手法：OpenCoder

著者らは、不確実性を事後的な信頼度スコアとしてではなく、実行可能な制御信号として扱うために設計された、不確実性を考慮したフレームワークであるOpenCoderを提案しています。このフレームワークは、以下の5つのフェーズで動作します。

リポジトリ知識と不確実性のプロファイリング： 3つの証拠ソース（プロジェクト固有の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は、クエリ、フィルタリングされた証拠セット、およびソースごとの不確実性トレースを条件として、候補となるコードを生成します。
検証と不確実性の緩和： 生成された候補は、静的チェックと実行可能テストを受けます。最初にパスした候補が選択されます。生の候補がパスしない場合、システムは「モード（最頻）」候補（最大の自己整合性グループからのもの）を特定し、最大2ラウンドの検証ガイド付き修復を実行します。

また、本フレームワークは、生成前に自己検索された冗長な、あるいは意図に適合しないAPIを除去するために、**ターゲット指向API精緻化（Target-Aware API Refinement）**を採用しています。

主な貢献

定式化： 本論文は、リポジトリレベルのコード生成を、単純な関連性ランキングを超えた、異質な証拠に対する不確実性下での意思決定問題として定式化しています。
フレームワーク： 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 + Verify/Repair コントロール（同じ証拠を使用するが不確実性考慮型フィルタリングを欠くもの）と同等であり、ベースラインRAGに対する利得の大部分は、不確実性フィルタリング単独ではなく、検証/修復予算によって駆動されていることが示唆されました。
Geminiの性能： Geminiについては、OpenCoder、ベースラインRAG、およびコントロール間の差異に統計的な裏付けはありませんでした。コントロール（RAG + Verify/Repair）がほとんどの指標で最も高い性能を示しました。
相互作用効果： ファクトリアル分析（RQ1）により、単一の証拠ソースが性能に有意な限界効果を持つことはないことが明らかになりました。代わりに、有意なクロスソースの相互作用が観察されました（例：リポジトリコンテキストと類似コード証拠は、GPTにおいて正の相互作用を示しました）。
API検索： ターゲット指向の精緻化は、APIセットの検索を大幅に改善し、GPTではマクロF1を43.4%から64.8%へ、Geminiでは59.1%へと向上させました。
境界条件： コンテキストが制限されたExecRepoBenchのストレス・テストでは、RAG + Verify/RepairコントロールがOpenCoderを大幅に上回りました。これは、リポジトリの証拠が不完全なシナリオでは、不確実性考慮型のフィルタリングが、最終的な決定を改善するどころか、有用な代替案を抑制してしまう可能性があることを示しています。

意義と主張

本論文は、不確実性は、孤立した信頼度推定としてではなく、証拠の融合、実行可能検証、および修復と結合された、実行可能な制御信号として最も有用であると主張しています。

バックエンド依存性： OpenCoderの利点はバックエンドに依存します。GPTの出力選択においては、プレーンなRAGよりも大幅に改善されましたが、検証および修復コントロールと比較して統計的に有意な優位性は示されず、Geminiにおいても明確なメリットは見られませんでした。
証拠の完全性： 本フレームワークの有効性は、リポジトリ証拠の完全性に依存します。証拠が不完全なシナリオでは、不確実性メカニズムが不可欠な情報を誤ってフィルタリングしてしまう可能性があります。
実行可能な制御： 主要な貢献は、「何を検索するか」の最適化から、「検索された証拠がどの程度信頼できるか」をモデル化し、その信号を用いてフィルタリングと生成を導くことへの転換です。

著者らは、OpenCoderが不確実性考慮型統合の可能性を示している一方で、その利点は特定のLLMバックエンドおよび検索されたリポジトリ証拠の品質と完全性に左右されると結論付けています。また、生成されたコードには依然として開発者によるレビューとプロジェクト固有のテストが必要であることを強調しています。