TL;DR
HIDEは、rustcのソースをfile→module→crateの順にLLMで文書化し、Issue説明・失敗プログラム・コンパイラログ・クエリトレースを証拠に、crate→module→fileの順で疑わしいファイルを絞り込む。スコープ内候補比較と証拠付きコードスライスでプロンプト過負荷を抑える。160件の再現可能なrustcバグで、GPT-5.4使用時にAccuracy@1 42.08%、Accuracy@10 80.42%を報告。RAGではなく、コンパイラ特有の静的な階層構造と動的なクエリ実行を組み合わせる点が特徴。評価はrustcの再現可能バグに限定される。
既存手法との違い
原論文は、意味論ベースのAgentless、実行ベースのSoapFL、依存関係ベースのGraphLocatorと、160件の再現可能なrustcバグ上でHIDEを比較している。GPT-5.4使用時、HIDEはAccuracy@1 42.08%、Accuracy@10 80.42%で、最強ベースラインをそれぞれ5.83%、6.04%上回ると報告。平均154秒/バグ、145,413トークン/バグで、平均実行時間は最小、トークン消費はAgentlessとSoapFLより大幅に少ないと報告している。さらに3種のLLMでAccuracy@10平均76.04%から80.42%を示し、アブレーションでは全変種がHIDEより低いAccuracy@kだったと報告している。本記事は追試していない。
使える条件
対象はrustcのコンパイラバグ切り分けであり、入力としてrustcのリビジョンと、Issue説明・失敗プログラム・コンパイラログ・クエリトレースを含むバグコンテキストを用いる。出力は疑わしいソースファイルのランキングである。原論文の評価対象は160件の再現可能なrustcバグで、LLMとしてGPT-5.4、Gemini-3.1-Pro-Preview、DeepSeek-V4-Proを使用している。1バグ平均154秒・145,413トークンという報告がある。クエリトレースが得られない場合やrustc以外への適用可否は、提示された本文からは確認できない。
限界と未検証の範囲
評価は160件の再現可能なrustcバグに限定され、他コンパイラ、他言語、非再現バグ、クエリトレースなしの環境は未検証である。Accuracy@1は42.08%であり、首位以外の見逃しが残る。平均154秒/バグ、145,413トークン/バグのコストもかかる。3つのLLMではAccuracy@10平均76.04%から80.42%だが、他のLLMやバージョンへの一般化は不明である。文書生成やランキングの誤りが精度に与える影響の詳細は、提示された本文からは確認できない。
解説
ねえ智也くん、このHIDEって論文、rustcのバグの原因ファイルをLLMで見つける話？まず何が嬉しいの？
そう。rustcのバグは、正しいプログラムを弾いたり、コンパイル結果を間違えたりする。直すにはまず原因のソースファイルを特定する必要がある。でもリポジトリが大きくて依存も強いから、その切り分けが難しい。
なるほど。普通のバグ位置特定ツールじゃだめなの？
既存は大きく分けて汎用手法とコンパイラ特化手法がある。原論文は意味論ベースのAgentless、実行ベースのSoapFL、依存関係ベースのGraphLocatorと比較してる。汎用手法はrustcのソース構造やコンパイラ実行の特徴を明示的に使わない、という違いがある。
HIDEはそこをどうするの？
HIDEは二段階。まずfile→module→crateの順にLLMで文書化して、各ファイルが何をして、似た機能のファイルがどう協調するかをまとめる。次にcrate→module→fileの順で疑わしい候補を絞る。
文書化してから絞るんだ。証拠は何を使うの？
Issue説明、失敗プログラム、コンパイラログ、クエリトレース。rustcの静的な階層構造と、クエリ実行の動的な証拠を組み合わせる。RAGじゃなくて、コンパイラ特有の構造と実行を直接使うのが特徴。
プロンプトが大きくなりすぎる問題は？
Scoped Candidate Competitionでモジュール内ごとに候補を比較して、Evidence-Guided Code Slicingでバグ関連のコード断片だけを入れる。候補数とコード量を抑えて、コンテキスト過負荷を減らす。
評価はどうだったの？
160件の再現可能なrustcバグで評価してる。GPT-5.4だとAccuracy@1が42.08%、Accuracy@10が80.42%。最強ベースラインをそれぞれ5.83%、6.04%上回った、と論文は報告してる。平均154秒、145,413トークン/バグで、平均実行時間は最小、トークンはAgentlessとSoapFLより大幅に少ない。
すごい。じゃあ万能？
そうではない。評価は再現可能なrustcバグ160件に限定されてる。他のコンパイラ、他の言語、再現しないバグ、クエリトレースが取れない場合は未検証。Accuracy@1が42.08%だから、首位以外の見逃しも残る。コストもゼロじゃない。
3つのLLMでも試してるんだっけ？
GPT-5.4、Gemini-3.1-Pro-Preview、DeepSeek-V4-ProでAccuracy@10の平均が76.04%から80.42%。アブレーションでは全部の変種がHIDEより低いAccuracy@kだった、と報告されてる。ただ、他のLLMやバージョンへの一般化は提示本文からは確認できない。
なるほどね。静的な構造と動的なクエリ実行を組み合わせるのがポイントなんだ。
そう。あと、僕らが追試したわけじゃなくて、提示された論文の報告として見る必要がある。そのうえで、rustcの切り分けに特化した設計としては筋が通ってる。
じゃあ私の部屋の「原因ファイル」もcrate→module→fileで絞ってほしいな。クエリトレースはないけど。
それはまず片付けてから相談して。