最近 arXiv で興味深い論文を見つけました。『Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction』というタイトルで、著者はテキサスA&M大学、ウォータールー大学、カリフォルニア大学サンディエゴ校、スタンフォード大学、イリノイ大学アーバナ・シャンペーン校といった大学群に、Verdent AI、Lambdaといった企業が名を連ねています。
タイトルからして核心的な考え方はほぼ明らかです。リトリーバーにこだわるのはもうやめて、検索という行為そのものを再考しよう、というものです。読んで非常に啓発されたので、この論文の内容を詳しく解説します。
図1：BrowseComp-Plusにおける性能とコストのパレート最適。青い星はQwen3-Embed-8Bリトリーバーを使用したソリューション、緑の星はこの論文で提案されている2つのDCI-Agentです。右上の費用対効果の高い領域で、DCIが従来のリトリーバーを圧倒していることがわかります。精度は11ポイント高く、コストは424ドルも削減されています。
マクルーハンの古い言葉が再び引用される
論文の冒頭でマーシャル・マクルーハンの言葉が引用されています。「メディアは、人間の関係性や行動の規模と形態を形成し、制御する。」
エージェントによる検索という文脈では、この言葉は次のように言い換えられます。エージェントがコーパスをどのように「見る」かが、エージェントが何をできるか、何ができないかを決定する。
従来のRAG（検索拡張生成）の流れはよく知られています。ドキュメントをチャンクに分割し、インデックスを構築し、BM25または密な埋め込み（dense embedding）を使い、クエリを投げるたびにtop-kの結果を取得します。このパラダイムは、静的な大規模コーパスで単一ターンの質問応答を行うシナリオでは問題なく、効率も十分です。しかし著者は、問題はエージェントが高性能化しすぎたことにあると指摘します。
Search-R1やASearcher、さらにBrowseComp-Plusのような新しいベンチマークにおけるディープリサーチタスクでは、エージェントはすでに計画を立て、クエリを書き換え、複数回の検索を自律的に実行できます。しかし、どれほど試行錯誤しようとも、エージェントとコーパスの間には常にリトリーバーという層が介在し、各ステップで圧縮されたtop-kのスライスしか見ることができません。これは厄介な状況です。エージェントにはアイデアがあるのに、「目」が制限されているのです。
リトリーバーが長年苦手としてきたいくつかのシナリオを挙げてみましょう。正確な文字列一致が必要な場合はどうするのか？複数の弱いシグナルを組み合わせてクエリを実行する必要がある場合は？新しい手がかりを発見し、すぐに原文で検証したい場合は？これらはすべて、従来の検索インターフェースでは扱いにくいものです。多くの有用な証拠はtop-kに到達する前にフィルタリングされてしまい、後段の推論能力がどれほど強力でも取り返しがつきません。
ならばエージェントに直接grepさせては？
著者のアプローチは単純明快です。リトリーバーがボトルネックなら、その層を取り除いてしまおう、というものです。エージェントにbash、grep、find、catといった汎用的なターミナルツールを使わせ、生のコーパスを直接操作させるのです。
このアプローチはDirect Corpus Interaction（DCI）と名付けられました。日本語では「直接コーパス対話」といった意味です。
図2：左は従来のリトリーバー媒介モデル。オフラインでインデックスを構築し、エージェントはクエリを投げてtop-kを取得します。右はDCIモデル。エージェントはgrep、glob、bashなどのコマンドを使って生コーパスを直接操作します。埋め込みモデルもベクトルインデックスもなく、あるのはシェルだけです。
2026年にもなって、まだgrepを使うのか？と直感的には思われるかもしれません。しかし、よく考えると非常に合理的です。
ここ1、2年で、コーディングエージェントはCLIベースの操作に非常に習熟しています。SWE-agent、Agentless、Claude Code、OpenHands、Aiderといったプロジェクトはすべて、grep + read + bashという組み合わせが、十分に高性能なモデルにとってリポジトリ内の正確な位置特定、コード修正、テスト実行に十分であることを証明しました。コード作成がこれで可能なら、ドキュメント検索でできない理由はあるのでしょうか？
DCIパラダイムのメリットも明確です。
- オフラインでのインデックス構築コストがない。コーパスを入れるだけで即座に検索可能です。
- 動的なコーパスに自然に対応。ファイルが変更されれば即座に検索結果に反映され、インデックスの再構築は不要です。
- インターフェースの解像度が高い。エージェントは
grep 'foo' file | grep 'bar'のような重ねての制約条件による検索や、grep -n 'keyword' file | headでの正確な位置とコンテキストの確認が行えます。 - 意味理解がインデックスからLLM自身に移行するため、モデルの進化がそのまま恩恵となります。
2つのエージェント実装：軽量版とフル装備版
比較実験のため、著者は2種類のDCI実装を用意しました。
DCI-Agent-Liteは超軽量版で、Piという軽量ターミナルコーディングエージェントを改造したものです。提供されるツールはbashとreadの2つだけです。基盤モデルにはGPT-5.4 nanoを使用し、推論努力（reasoning effort）を最大のhighに設定しています。このバージョンの目的は、「インターフェースの変更」という変数を純粋に隔離することです。検索専用モジュールも、埋め込みも、リランカーも一切なく、純粋にシェルだけで動作します。
DCI-Agent-CCは、Claude Codeをそのままハーネスとして利用し、基盤モデルをClaude Sonnet 4.6（medium reasoning）に変更したものです。このバージョンは性能の上限を探るためのもので、より優れたプロンプト、より堅牢なツールオーケストレーション、組み込みのコンテキスト管理が追加されています。ただし、本質的には依然としてDCIであり、リトリーバーインターフェースは一切使用していません。
両エージェントとも最大ターン数（max turn budget）は300に設定され、十分な探索空間が与えられています。
長い軌跡でコンテキストが爆発しないようにするには？
DCIで避けて通れない問題の一つが、grep検索で数百、数千のマッチがヒットしたり、catで数万トークンのファイルを開いたりした場合、数十回の検索でコンテキストウィンドウがすぐにパンクしてしまうことです。
図3：3つのランタイムコンテキスト管理戦略 - 切り詰め、圧縮、要約。
著者はDCI-Agent-Liteに軽量なランタイムコンテキスト管理の仕組みを実装し、以下の3つのメカニズムを重ねて使用しています。
切り詰め（Truncation）は最もシンプルで、各ツール呼び出しの出力が一定の文字数を超えた場合に切り捨てますが、その呼び出しが行われた痕跡は残します。
圧縮（Compaction）はLLMを呼び出す必要がなく、純粋なメモリ上での操作です。累積ツール出力が閾値を超えると、古いターンのツール実行結果を短いプレースホルダーに置き換えますが、ツール呼び出し自体の構造（スケルトン）は保持します。
要約（Summarization）は最もヘビーな介入です。コンテキストのプレッシャーが依然として高い場合、要約エージェントを呼び出して履歴を短い要約に圧縮し、直近の数ラウンドはそのまま保持します。
これら3つのメカニズムを組み合わせて、未処理（L0）からフル装備（L4）までの5段階の戦略を定義しています。L0は何もせず、L1は50K文字での切り詰めのみ、L2は20K文字での切り詰め、L3はL2に圧縮を追加、L4はL3に要約を追加します。
評価は正確性だけでなく、カバレッジと位置特定精度で
回答の正確性だけを見ていては、DCIと従来の検索の違いを語ることはできません。そこで著者は、軌跡レベルの2つの指標を導入しました。
カバレッジ（Coverage）は、その軌跡が正解ドキュメント（gold document）を発見できたかどうかを測る指標です。any（少なくとも1つ発見）、mean（再現率、平均していくつ発見したか）、all（すべて発見）の3つの観点で評価します。これは「広さ」の指標です。
位置特定精度（Localization）は、正解ドキュメントを発見した後、そのドキュメント内部で重要な証拠の断片を正確に特定できたかどうかを測る指標です。これは「深さ」の指標であり、「正解ドキュメントに到達した後、さらに深く掘り下げられるか」を反映します。
簡単に言えば、カバレッジは「到達できたか」を測定し、位置特定精度は「到達した後、精査できたか」を測定します。この2つを組み合わせることで、DCIとリトリーバーの違いが明確になります。
実験結果：リトリーバーを完全に圧倒
著者は3種類のベンチマークを実施しました。エージェント型検索（BrowseComp-Plus）、6つの多段階推論QA（NQ/Trivia/Bamboogle/HotpotQA/2Wiki/MuSiQue）、6つのIRランキング（BRIGHT 4つ + BEIR 2つ）です。
エージェント型検索では、同じClaude Sonnet 4.6を基盤モデルとして、Qwen3-Embedding-8BリトリーバーをDCIに置き換えたところ、精度が69.0%から80.0%に向上し（+11ポイント）、コストは1440ドルから1016ドルに削減されました（-29.4%）。DCI-Agent-CCも、最強の組み合わせであるGPT-5 + Qwen3-Embedding-8B（71.7%）を含むすべての検索ベースラインを上回り、8.3ポイント高いスコアを達成しました。軽量版のDCI-Agent-Liteは62.9%の精度を達成し、コストはわずか93ドルでした。これはo3 + Qwen3-Embedding-8B（66%）に匹敵する性能でありながら、コストを647ドルも節約できたことになります。
多段階推論QAでは、DCI-Agent-CCの平均精度は83.0%で、最強の検索エージェントベースラインであるASearcher-Local-14B（52.3%）を実に30.7ポイントも上回りました。最も顕著だったのは難易度が最も高いMuSiQueで、DCI-Agent-CCが74%を獲得したのに対し、ASearcherはわずか24%で、50ポイントの差がつきました。HotpotQAでは30ポイント、2Wikiでは26ポイント上回っています。軽量版のDCI-Agent-Liteも68%で、堂々の2位です。
IRランキングはさらに顕著で、本来リトリーバーの本場とも言える分野です。しかし、DCI-Agent-CCが6つのデータセットすべてで優勝し、平均NDCG@10は68.5に達しました。これは最強のReasonRank-32B（47.0）を21.5ポイントも上回っています。Lite版も56.7で、ReasonRank-32Bを9.7ポイント上回りました。
では、DCIの強みは一体どこにあるのか？
これが論文の最も興味深い部分です。著者は多くの紙幅を割いて変数制御実験を行い、性能向上の源泉がどこにあるのかを徹底的に解明しています。
図4：左はBrowseComp-Plus全830問におけるDCI-Agent-CCと従来のリトリーバーの比較。右はDCIのツール使用分布で、Bashが62.4%、Grepが33%を占めています。Bash内部はさらに、チェーン検索、ドキュメント覗き見、正規表現などに分類されます。
まず、RQ1（研究課題1）の分析から得られた直感に反する発見です。DCIの勝利は、より多くの正解ドキュメントを取得できたからではない。
100問のサブセットで比較したところ、Qwen3-Embedding-8Bの平均カバレッジ率は56.7%でしたが、DCI-Agent-Liteは28.0%にとどまりました。しかし、カバレッジany（少なくとも1つの正解ドキュメントを見つけた割合）では両者はほぼ互角（74.0 vs 70.0）で、位置特定精度スコアではDCIが48.4、リトリーバーが21.7と、26.7ポイントの大差がつきました。
これは何を意味するのでしょうか。BrowseComp-Plusの問題の多くは正解ドキュメントが1～4つしかありません。DCIは一度有用なドキュメントを発見すると、即座にモードを切り替えます。「広く浅く探す」ことから「局所を深く掘る」ことに集中するのです。正解ドキュメントの連鎖をすべて回収することへのこだわりを捨て、「すでに到達したドキュメントから、より多くの価値を引き出せるか」に集中します。
著者はこの現象を検索インターフェースの解像度（retrieval interface resolution）と名付けました。リトリーバーが提供するのは「ドキュメントレベル」または「パラグラフレベル」の解像度ですが、DCIは「文字レベル」の解像度を提供できます。エージェントは1行、1文、さらには1トークン周辺のコンテキストを正確に特定し、それに基づいて次の検索を開始できます。
ツール使用分布もこの点を裏付けています。Bashコマンドの中で、チェーン検索（grepをパイプでつなぐ）が22.3%、ドキュメント覗き見（head/tail/sedで一部を見る）が18%、正規表現検索が17%、単一キーワードgrepが14.1%、findによるファイル検索が14%です。これらはすべて「精査」型の操作です。ファイル全体をcatする操作はわずか9.2%に過ぎません。エージェントが行っているのは、制約の組み合わせ、正確なマッチング、断片検証、必要に応じた読み取りなのです。
すべてのシナリオに適しているわけではない
著者は非常に誠実で、いくつかのストレステストを実施して限界を明らかにしています。
RQ4 - コーパス規模の壁：著者はBrowseComp-Plusのコーパスを10万ドキュメントから20万（FineWebのダミードキュメントを注入）、そして40万にまで拡大しました。
図5：異なるコーパス規模でのDCI-Agent-CCのパフォーマンス。10万件では費用対効果が最適ですが、20万件に増えるとツール呼び出し回数が38.5回から86.9回に増加し、精度は13.6ポイント低下しました。40万件では完全に破綻し、精度は37.5%に急落、平均ツール呼び出し回数は122.4回で、20問が予算上限に達しました。
この結論は非常に重要です。DCIのスケーラビリティは検索の深さにおいては優れているが、検索の広さにおいてはコストが急激に上昇するということです。一度エージェントが優れた「アンカードキュメント」を見つければ、その後の操作は非常に効率的です。しかし、最初のアンカーを見つけるためのコストは、候補空間の拡大に伴って指数関数的に増加します。したがって、従来の密/疎検索は、大規模な静的コーパスにおいて依然として代替不可能な価値を持ちます。
RQ5 - コンテキスト管理戦略の重要性：L0からL4までの5段階を比較しました。結論は直感に反するもので、より積極的な管理が常に効果的とは限らず、明らかに非単調な曲線を示しました。L1が最も高速で、最も多くのゴールド証拠を保持しましたが（31.3）、最も精度が高かったのはL3でした（77）。L2は最も低コストでしたが、精度は最悪（69）で、L4は要約を追加したにもかかわらず、再び低下しました。
これは何を示しているのでしょうか？忘れるべきことは忘れなければならないということを示唆しています。すべての証拠を完全に保持することが、最適な動作状態を維持することとは限りません。多段階の仮説修正には「選択的忘却」が必要であり、圧縮が弱すぎるとエージェントの焦点がずれ、圧縮が強すぎると有用な中間構造が失われます。最適なバランスを見つける必要があるのです。
RQ6 - ツールの表現力の寄与度：このアブレーション（除去分析）は非常に厳しいものでした。著者はDCI-Agent-Liteのツールをreadとgrepだけに削減し（bashパイプも禁止）、それでも戦えるかどうかを検証しました。
結果は戦える、というものでした。read + grepだけで61%の精度を達成し、依然としてQwen3-Embedding-8Bリトリーバー（45%）を16ポイント上回り、ツール呼び出し回数もほぼ同じでした。完全なbashツールセットを使用すると、さらに12ポイント向上しましたが、ツール使用量、遅延、計算リソースは2倍になりました。
したがって、最も核心的な性能向上は、bashの多彩さではなく、インターフェースそのものの変化に由来するということです。最小限のツールセットで、向上分の大部分を引き出せるのです。
コードの詳細：Piをラップする薄いPython層
RQ6は「最小限のツールセットで十分」と述べていますが、その最小限のツールセットとは具体的にどのようなものなのでしょうか？論文を読むだけでは物足りず、実際にリポジトリ（github.com/DCI-Agent/DCI-Agent-Lite）をクローンして調べてみました。その結果、全体的な実装は想像以上に「軽量」で、全体の87%がPython、13%がシェルスクリプトで構成されており、ディレクトリ構造も非常にクリアです。
全体アーキテクチャ：DCI-Agent-Lite ≈ Pi + コンテキスト管理パッチ + 評価フレームワーク
まず意外な事実をお伝えします。DCI-Agent-Lite自体のPythonコード量は非常に少なく、本質的には「グルー層（接着剤の役割を果たす層）」です。実際に動作するエージェントのコアはPiで、これはEarendilチームが開発した超軽量ターミナルコーディングエージェントです（TypeScriptで記述され、npmでインストールされます）。
リポジトリのディレクトリ構造はおおよそ次のとおりです。
DCI-Agent-Lite/
├── src/dci/ # Python CLIラッパー層（dci-agent-liteエントリポイント）
├── prompts/ # タスクテンプレートと評価用プロンプト
├── scripts/ # データダウンロード + ベンチマーク実行スクリプト
├── setup.sh # ワンクリック環境構築
└── pyproject.toml # uvでPython依存関係を管理
注意すべきは、setup.shにjdf-prog/pi-mono（論文の筆頭著者Dongfu Jiang氏によるフォーク）のcodex/context-management-ablationブランチをクローンし、npm run buildするステップが含まれていることです。つまり、著者はPiをフォークし、その上に「コンテキスト管理アブレーション」のパッチを適用したのです。論文で言及されているL0からL4の5段階の戦略は、このパッチによって実装されています。Lite側のPythonコードは主に、パラメータの引き渡し、Piプロセスの起動、出力の収集、および軌跡の保存を担当します。
なぜPiがベースとして選ばれたのか
Piの設計思想はDCIと完璧にマッチしています。Piの公式スローガン「There are many agent harnesses, but this one is yours.」がすべてを物語っています。具体的にいくつかの重要な特性を見てみましょう。
超シンプルなシステムプロンプト。Piのデフォルトのシステムプロンプトは驚くほど短く、「あなたは役に立つアシスタントです」といった無駄な記述がありません。トークンに十分な余裕を持たせており、これは長い軌跡をたどるディープリサーチのシナリオにおいて特に重要です。
少数のネイティブツールのみで、bashがコア。PiはClaude Codeのように最初からRead/Grep/Glob/Edit/Taskといった多数のツールを持っているわけではありません。提供されるのはbashとreadだけで、あとはユーザーがシェルコマンドを組み立てる必要があります。これはまさに論文のRQ6が検証しようとした点です。最小限のツールセットで十分であるということです。
圧縮メカニズムを内蔵。Piはデフォルトで、コンテキスト制限に近づくと古いメッセージを要約して短いテキストに自動的に置き換えます。著者のフォークでは、このメカニズムが調整可能なL0～L4戦略に拡張されました。
派手な機能がない。サブエージェント、プランモード、MCPなどはなく、Piが意図的に「そぎ落とした」ものです。これらはすべて拡張機能として自分で追加する必要があります。この「骨が見えるまで削ぎ落とした」スタイルのおかげで、制御実験が容易になり、性能差がハーネスによるノイズではないことを確認できます。
実際の実行フロー
最小限の実行可能なコマンドは以下のとおりです。
uv run dci-agent-lite \
--provider openai \
--model gpt-5.4-nano \
--cwd "corpus/wiki_corpus" \
--extra-arg="--thinking high" \
--extra-arg="--context-management-level level3" \
"現在のディレクトリにあるwiki_dump.jsonlを使用して質問に答えてください：ロンドン大火はどの通りから発生しましたか？grepではなくrgを使用してください。"
主要パラメータを分解してみましょう。
--cwd "corpus/wiki_corpus"がポイントです。エージェントの作業ディレクトリが、そのままコーパスディレクトリになります。Piの起動後、bashのpwdはwiki_dump.jsonlが存在するフォルダを指します。エージェントが後続で実行するrg、find、catはすべてここで実行されます。これは、モデルがコーパスライブラリの中に「住み込む」ようなものです。この設計は、論文の「エージェントが推論する環境内で直接操作する」という記述と完璧に一致します。
--extra-arg="--thinking high"はPiに渡され、さらにOpenAIの推論努力（reasoning effort）に渡されます。GPT-5.4 nanoの低コストと高いthinking effortの組み合わせが、Liteバージョンの性能を支える重要な要素です。
--extra-arg="--context-management-level level3"は、論文のTable 1にある5段階の戦略のスイッチです。level3がデフォルト値（切り詰め + 圧縮、要約なし）です。
ユーザープロンプトの「grepではなくrgを使用する」という指示は、一見冗長に見えますが、実は重要なエンジニアリング上の詳細です。rg（ripgrep）はgrepよりも桁違いに高速で、数百万のドキュメントを含むコーパスではほぼ必須です。setup.shでもripgrepが特別にインストールされます。
軌跡データの保存方法
実行後、エージェントは検索プロセス全体をoutputs/runs/<timestamp>/以下にシリアライズします。
question.txt— 元の質問final.txt— 最終回答conversation_full.json— 全対話履歴。毎ターンの思考、bashコマンド、ツール結果がすべて含まれます。
このJSONこそが、論文で軌跡分析を行うための原材料です。RQ2のツール分布図は、このようなJSONから解析されています。これにより、エージェントが何をしているのかを非常に細かい粒度で分解できるのです。
コンテキスト管理層の実装詳細
これは工学的に最も注目すべき点です。論文では3つのメカニズムが説明されていますが、それがPiのようなエージェントループに具体的にどのように組み込まれているのでしょうか？Piの拡張メカニズムと著者によるパッチから、大まかに以下のように推測できます。
切り詰めは、ツールの実行結果がメッセージ履歴に書き込まれる前に発生します。bashの実行後、生の出力が数万文字になる可能性がありますが、切り詰めロジックがレベルの閾値に従って超過分をカットします。モデルが見るのは切り詰められた後のバージョンです。これがトークン消費に最も大きな影響を与えます。
圧縮は「メモリ内で、LLMを呼び出さない操作」であり、純粋な構造操作です。累積ツール出力が240K文字を超えると、「直近12ラウンド以外」の古いツール実行結果がResult_Placeholderのようなプレースホルダーに置き換えられますが、ツール呼び出し自体の構造は保持されます。これにより、エージェントは自分が何をしたかを認識しつつ、処理済みの原文を背負い続けることはありません。
要約はL4でのみ有効化されるヘビーな操作です。圧縮後も推定トークン数が閾値を超える場合に、LLMを呼び出して圧縮済みの履歴を短い要約に圧縮し、直近20Kトークンはそのまま保持します。論文では、3回連続で要約に失敗した場合は諦めて無限ループを回避するという詳細も述べられています。
これら3層が重なる仕組みと、論文のRQ5の非単調な結論を合わせると、一つのことが明確になります。何を忘れるべきか、いつ忘れるべきか、どのように忘れるべきか、それ自体が工学的な問題であり、「圧縮すればするほど良い」という単純な直感では解決できないのです。
なぜこれで62.9%の精度を達成できたのか
上記の要素をすべてまとめると、DCI-Agent-LiteがBrowseComp-PlusでGPT-5.2+リトリーバーのソリューションを上回る性能を発揮できた理由は、以下の要因が重なったからだと考えられます。
第1に、Piのシステムプロンプトが超シンプルで、「自己紹介」にトークンを無駄遣いしないこと。第2に、作業ディレクトリがコーパスを直接指しているため、エージェントはカスタムの検索APIを苦労して学ぶ必要がなく、慣れ親しんだbashを使えること。第3に、コンテキスト管理によって長い軌跡の爆発問題を抑制し、300ターンの予算が実現可能になったこと。第4に、GPT-5.4 nanoの高い推論努力とripgrepの速度によって、「検索しながら考える」というサイクルを高速に回せたことです。
最後に、筆者が最も感銘を受けたのは、これが実際に自分のPC上のドキュメントに対して直接実行できるという点です。リポジトリのREADMEにある「Your private deep-research assistant」というキャッチコピーは誇大広告ではありません。クラウドサービスにドキュメントをアップロードする必要も、ベクトルデータベースをインストールする必要も、埋め込み計算に何時間も待つ必要もありません。uv run dci-agent-lite --cwd ~/my-papers/を実行するだけです。この「箱から出してすぐ使える」点は、個人のナレッジベースシナリオにとって非常に魅力的です。
筆者の所感
論文を読み、コードを調べ尽くして感じたのは、この研究の真の価値は特定の数値にあるのではなく、「検索」という行為を単なるリトリーバー設計の問題ではなく、インターフェース設計の問題として再定義したことにあると思います。
過去10年の検索研究は、ほぼモデルの改良に注力してきました。より良いスパースアルゴリズム、より強力な密な埋め込み、より賢いリランカーです。しかし、エージェント自体がすでに研究者のように思考し（仮説を立て、文字列を検証し、文脈を読み、クエリを変更する）できるのであれば、類似度ベクトルに圧縮する層は、むしろボトルネックになります。より解像度の高いインターフェースを与え、意味処理をエージェント自身に任せた方が、全体のパフォーマンスが向上する可能性があるのです。
もちろん、このパラダイムにも明確な限界はあります。
- 大規模な静的コーパス（数千万ドキュメント以上）は、依然として密なリトリーバーの独壇場です。
- 基盤モデルの能力に対する要求が非常に高く、弱いモデルでは長い軌跡の複雑な検索に耐えられません。
- コスト構造が変わり、「一回限りのインデックス構築という固定費」から「検索ごとの限界費用」に変わるため、高QPSのサービスには割に合わない可能性があります。
- 評価指標を更新する必要があり、recall@kだけを見るのでは不十分で、軌跡レベルの位置特定精度を見る必要があります。
しかし、見方を変えれば、ローカル、異種混在、動的に変化するエージェントワークスペース、例えば開発者のローカルコードベース、企業内で絶えず更新されるドキュメント、研究者のPCに散在するPDFなどでは、DCIパラダイムは真の競争力を持っています。インデックスを構築する必要がなく、ファイルが変更されれば即座に検索できます。エージェントが推論しているその環境で直接操作することで、非常にスムーズな使用感が得られるでしょう。
さらに、GitHub上でAnthropicがこの1年推し進めてきたClaude CodeやAgent Skillsの流れは、まさにLLMをシェルの中へ、ファイルシステムの中へ、実環境の中へと直接置く方向へ進んでいます。この観点から見ると、DCIはほぼ必然的な産物と言えるでしょう。
今後、注目すべき方向性がいくつかあると思います。DCIを従来の検索とどのようにハイブリッド化するか（例えば、最初に密な検索で大まかに絞り込み、その後grepで精密化する）。DCIにキャッシュ層を追加して、繰り返し検索のコストをどのように削減するか。そして、より軽量な基盤モデル（7B/14Bクラス）でも、このパラダイムの恩恵を受けられるかどうか、といった点です。
リポジトリは現在9スター、1フォークで、論文も先週arXivに公開されたばかり（2605.05242）であり、プロジェクト全体はまだ非常に初期段階にあります。しかし、私はこの考え方は追跡する価値があると思います。そのエンジニアリングのハードルは非常に低く、ほとんどの人が再現して、自分のPDFやNotionのエクスポートデータでその効果を試すことができます。論文を読むよりずっと面白い体験になるでしょう。