コーディングエージェントのリトリーバル強化（RAG）による手法選択を測るオープンソース9タスク・ベンチマーク

paper-lantern-challenges）というオープンソースのベンチマークスイートを公開します。これは、9つの日常的なソフトウェアタスクにおいて、検索拡張によるテクニック選択を使う場合と使わない場合のコーディングエージェントの性能を測定します。開示：私は、今回検証している検索システムの著者（paperlantern.ai/code）です。ここで共有しているアーティファクトはプロダクトではなく、ベンチマークスイートそのものです。すべてのプロンプト、エージェントのコード経路、予測ファイルはリポジトリ内にあり、再現可能です。

セットアップ。同じコーディングエージェント（プランナーとしてClaude Opus 4.6、タスクモデルとしてGemini Flash 3）、同じ入力データ、すべての9タスクで同じ評価スクリプト：テスト生成（mutation score）、text-to-SQL（実行精度）、PDF抽出、契約抽出、PRレビュー、テキスト分類、few-shotプロンプト選択、LLMルーティング、要約の評価。独立変数：解決策を書き始める前に、CS文献に対して検索ツールを呼び出せるかどうか。タスクごとに1回だけ行い、リトライなし、出力の手動フィルタリングなし。

タスク選定。タスクは、MLに特化したシナリオではなく、コーディングエージェントが実際に直面する日常のエンジニアリング領域をカバーするよう選びました。選定基準：(1) 明確な定量メトリクス、(2) 天井性能より十分低いベースライン、(3) 既に標準的なデータセットが存在すること、(4) 無料のGemini APIキーで、各タスクあたり約10分程度で評価が再現可能であること。

評価手法。各タスクは、そのタスク標準の定量メトリクスを用います（test_generationにはmutation score、text_to_sqlには実行精度、抽出タスクにはラベル付きスパンに対するF1、分類には重み付きF1など）。タスクごとのスクリプトとデータセットの選択はリポジトリにあります。タスクごとに1ディレクトリ、入口はevaluate.py、各タスクのREADME.mdに手法とデータセットを説明しています。

検索セットアップ。「検索あり」のエージェントは3つのツール呼び出しにアクセスします：explore_approaches(problem) は、文献から候補となる手法をランキングして返します。deep_dive(technique) は、選んだ手法について実装手順と既知の失敗モードを返します。compare_approaches(candidates) は、複数の選択肢がどれも有望に見える場合の比較のためです。エージェントは、いつ・どれくらいの回数それらを呼び出すかを判断します。レイテンシは呼び出し1回あたり約20秒で、結果はセッション間でキャッシュされます。ベースラインのエージェントにはこれらのツールは一切ありませんが、それ以外の土台（スキャフォールド）は同一です。

比較可能性。両エージェントは同じタスク固有のユーザープロンプトを共有します。唯一のシステムプロンプトの違いは、検索エージェントのツール呼び出し文法です。予測とタスクごとのプロンプトはリポジトリでdiff可能です（baseline/ と、タスクごとのwith_pl/サブディレクトリ）。

結果。

タスク	ベースライン	検索あり	デルタ
extraction_contracts	0.444	0.764	+0.320
extraction_schemas	0.318	0.572	+0.254
test_generation	0.625	0.870	+0.245
classification	0.505	0.666	+0.161
few_shot	0.193	0.324	+0.131
code_review	0.351	0.395	+0.044
text_to_sql	0.650	0.690	+0.040
routing	0.744	0.761	+0.017
summeval	0.623	0.633	+0.010

テスト生成のデルタは、エージェントがmutation-awareなプロンプトを発見したことによって生じました。用いられた手法はMuTAPとMUTGENで、これはターゲットのASTレベルの変異（mutation）のすべてを列挙し、その変異ごとに1つのテストが必要になります。ベースラインは、事前学習の事前分布（priors）から一般的なテストを書きました。

契約抽出のデルタは、BEAVER（セクションレベルの関連度スコアリング）とPAVE（抽出後のバリデーション）によるものです。どちらも2026年の手法で、エージェントの学習より後に登場しています。

実験で最も引用されている15件のうち10件が2025年以降に公開されており、これが検索が重要だという保守的な主張の根拠です。エージェントは、そのような手法をパラメトリックなメモリから到達できなかったはずです。

失敗モード。自己改善（self-refinement）がtext-to-SQLを損ねました（SQLの曖昧さに関する記述を読んだ後に、エージェントが正しいクエリを言い直してしまった）。提案された2つの手法（DyT、SeeDNorm）は、自動研究（autoresearch）の実験においてアーキテクチャ非互換であり、破棄されました。検索はより良い選択肢を提示しますが、勝ちが保証されるわけではありません。

再現性。すべてのプロンプト、エージェントコードの各行、すべての予測ファイル、すべての評価スクリプトがリポジトリにあります。各タスクのディレクトリには、手法を説明するREADMEがあり、さらにapproach.mdで、検索によって何が出てきて、エージェントがどの手法を選んだのかを正確に示しています。

リポジトリ：https://github.com/paperlantern-ai/paper-lantern-challenges

詳細なタスク別考察を含む書き下ろし記事：https://www.paperlantern.ai/blog/coding-agent-benchmarks

コメント欄で追加の設計上の選択について共有できるので、よければ。