技術要約：Libra: エージェントによる情報検索のための環境学習

問題提起

大規模なソフトウェアリポジトリ内におけるコードのローカライゼーション（特定）は、自律的なコーディングエージェントにとって不可欠な能力であり、ダウンストリームのタスク解決率と強く相関している。エージェントの性能を向上させる既存のアプローチは、一般的に以下の2つのカテゴリーに分類される：

1. モデル中心型（Model-Centric）: リポジトリ由来のデータを用いて基礎となる基盤モデルをファインチューニングする。この手法はシステムを特定のモデルに固定してしまい、最先端の商用LLMが持つ優れた推論能力を損なう可能性がある。
2. 静的環境拡張（Static Environment Augmentation）: 検索を補助するために、静的なインデックス（階層的なサマリー、逆インデックス、または知識グラフなど）を構築する。これらはモデルに依存しないが、インデックスは静的であり、エージェント固有の検索課題に対して動的に適応したり、継続的な改善のためにインタラクション・データを活用したりするメカニズムを欠いている。

現在、特定のリポジトリに対してエージェントの情報検索能力を能動的に進化させることができる、モデルに依存しないデータ駆動型のフレームワークが不足している。

手法：Libraフレームワーク

Libraは、静的なインデックスから、リポジトリ内にネイティブに存在する、能動的に進化するプレーンテキスト・インデックスへのパラダイムシフトを提案する。本システムは、3つの凍結されたエージェントと、可変的な環境アーティファクトである「Libra Catalogs」を用いた、敵対的なLLM最適化ループによって駆動される自己進化フレームワークを採用している。

1. 可変アーティファクト：Libra Catalogs

Libraは、リポジトリのルートおよびサブモジュールディレクトリ内に配置される、Markdownファイルの階層（「カタログ」と呼称）を構築する。これらのファイルは、リポジトリのルーティング情報をエンコードするナビゲーション可能なインデックスとして機能する。静的な埋め込みやグラフとは異なり、これらのカタログは人間が読みやすく、編集可能であり、システムによって更新される可変の状態変数である。

2. 3つの凍結されたエージェント

最適化ループは、重みとプロンプトが固定された3つの異なるエージェントを利用する：

• Prompter (データ合成器): 合成的な質問と回答のペアを生成する。リポジトリからランダムなコードチャンク $c$ をサンプリングし、$c$ によって回答可能であり、正解となるファイルパス $p^*$ を回答とする自然言語のクエリ $q$ を捏造する。Promterは、セマンティック検索を強制するために、正確な識別子（identifier）の使用を避けるよう指示される。
• Solver (クエリ解決器): ダウンストリームのコーディングエージェントを表す。クエリ $q$ と現在のカタログ状態 $K$ が与えられたとき、Solverはカタログのみをガイドとして使用して、正しいファイルパス $\hat{p}$ を特定しようと試みる。極めて重要な点として、Solverはこのプロセス中に正解のチャンクやパスにアクセスすることはできない。
• Healer (LLM最適化器): 最適化器として機能する。Healerは、Solverの失敗集合 $F$（$\hat{p} \neq p^*$ の場合）を分析し、ルーティング信号を修復するためにMarkdownカタログ $K$ を書き換える。Healerは、失敗の原因が情報の欠落、ノイズ、あるいは構造的な問題に起因するものかどうかを診断し、カタログに対して標的を絞った編集を行う。

3. 最適化ループ

システムは以下のラウンド（$T$）で動作する：

1. テストフェーズ: Prompterがバッチ形式でクエリを生成する。Solverは現在のカタログを使用してそれらを解決しようと試みる。失敗は失敗集合 $F$ に集約される。
2. ヒーリング（修復）フェーズ: Healerが $F$ を処理し、将来のルーティングエラーを最小限に抑えるためにカタログ $K$ を更新する。
   このループは、収束するまで（あるいは最適化されたカタログが永続的なインデックスとして機能するまで）継続される。

主な貢献

• 環境の学習（Environmental Training）: 本論文は、LLMの重みをファインチューニングするのではなく、環境（インデックス）を学習することを提案しており、モデルに依存しないアーティファクトを作成することで、LLMの重みを再学習することなく検索性能を向上させる。
• 敵対的自己改善（Adversarial Self-Improvement）: システムは、Prompterが困難なクエリを作成し、Solverが現行のインデックスの弱点を露呈させ、Healerがこれらの失敗に基づいてインデックス構造を反復的に洗練させるという、敵対的なループを利用している。
• プレーンテキスト・インデックス: ベクトル埋め込みや複雑なグラフではなく、Markdownカタログを使用することで、Libraは、コードベースにネイティブに統合され、解釈可能で、移植性と編集性に優れたインデックスを提供する。

実験結果

著者らは、SWE-BENCH LITEデータセットから抽出した12個のPythonリポジトリを用いてLibraを評価した。

• 対数的な改善: sympyリポジトリにおいて、合成クエリによる学習は、コードのローカライゼーション精度において継続的な対数的改善をもたらした。システムは、ステップ0でのファイル精度60.3%からスタートし、ステップ85で83.3%に達し、最先端のベースラインを上回った。
• 実世界タスクへの汎化: 合成データのみで学習されたカタログは、実世界のSWE-BENCH LITEバグローカリゼーションタスクへの転移に成功した。学習されたLibra Solverは、最小限のツールセット（BashとReadのみ）を使用しているにもかかわらず、LocAgentやRepoMemと比較して、最高のパフォーマンス（5ターンで77.8% File ACC、10ターンで82.3%）を達成した。
• モデル非依存性: 最適化されたカタログは、再学習なしに異なるSolverモデル（GPT-5-mini, GPT-5, Gemini-2.5-Flash）の性能を向上させる永続的なリソースとして機能した。性能の向上は、より弱いモデル（例：Gemini-2.5-Flashは+31.0ポイント）において最も顕著であった。
• ヒーリング効果: 個々のテストインスタンスの分析によれば、54.3%のインスタンスが学習の初期段階から後期段階にかけて改善しており、改善したケースと低下したケースの比率は3.3:1であった。これは、システムがルーティングの失敗を体系的に修正できる能力を示している。

意義と主張

本論文は、**「テキストベースのインデックスをインタラクションのフィードバックを通じて最適化することが、従来の検索手法に代わる実行可能かつ適応可能な選択肢を提供することを、Libraは示している」**と主張している。

著者らが強調する主なポイントは以下の通りである：

1. パラダイムシフト: 静的な外部埋め込みから、リポジトリ内にネイティブに存在する、能動的に進化するプレーンテキスト・インデックスへの移行。
2. 転移可能性: 自己生成された合成クエリのみで学習されたシステムが、実世界のソフトウェアエンジニアリングタスクを解決するための学習されたルーティング能力を正常に転移できること。
3. コストと移植性: このアプローチは、競争力のある性能を達成しながら、解釈可能性（人間が読めるカタログ）と移植性（モデルに依存しない）において明確な利点を提供する。

著者らは限界についても認めており、最適化ループの計算負荷の高さや、現在のリポジトリが静的であることを前提としている点などを挙げ、増分更新やマルチホップ・クエリ合成については今後の課題としている。しかし、本フレームワークが、静的な環境拡張とモデル固有のファインチューニングとの間の溝を埋めることに成功したと断言している。