「最終的な答えだけを、説明抜きで返せ」とプロンプトで念を押す。なのにWeb検索ツールを与えた瞬間、モデルは「検索結果によると、200 West Streetは749フィートで、888 7th Avenueは628フィートなので…」と語り出し、本来欲しかった Yes の一語が説明文の海に沈む。出力を後段でパースしているエンジニアなら、これがどれだけ厄介かすぐ分かるはずだ。
DoorDashの5人のエンジニアが6月17日にarXivへ出した論文 Decoupling Search from Reasoning は、この「検索を使わせると壊れる出力契約」を入口に、もっと大きな構造問題を突いている。彼らはこの現象を Search-Induced Verbosity(検索が誘発する冗長化)と名付けた。Claude Sonnet 4 に HotpotQA を解かせた実測では、予測の78.1%が "Based on the search results…" で始まり、完全一致に失敗したケースの62.3%は正解が答えの中に文字列として含まれていた。モデルは答えを知っているのに、検索がモデルの振る舞いを「抽出」から「要約・説明」へずらしてしまう。
🧩 なぜ検索がモデルの出力を歪めるのか
原因は機能ではなく構造にある、というのが論文の見立てだ。OpenAIやGoogleが提供する「native検索」(モデルAPIの内側で検索まで面倒を見てくれる方式)は、便利な反面、retrieval方針・検索プロバイダの選択・証拠の差し込み方・コスト・レイテンシ・生成時の振る舞いまで、すべてをモデルプロバイダ一社の境界の裏に束ねている。中で何が起きているか覗けないし、調整も再利用も他モデルへの移植もできない。冗長化はその密結合が表に出た一症状にすぎない。
ここが本質だと思う。native検索を「モデルに付いてくる機能」として受け取る限り、検索の質もコストも相手任せのブラックボックスになる。論文の主張は「リアルタイムのgroundingは、固定された機能ではなく最適化できるインターフェース境界として扱え」という一点に尽きる。
🔍 DSG、検索をモデルの外に出す
提案手法 Decoupled Search Grounding(DSG)は、検索をモデルの内側から引き剥がし、MCP互換のゲートウェイに移す。MCP(Model Context Protocol)はAnthropic発のオープン標準で、AIアプリと外部のデータやツールをつなぐ「AIのUSB-C」とよく説明される。DSGは検索を一個の標準ツールとしてモデルの外側に括り出し、これまでモデルプロバイダが握っていた制御を、自分で回せるノブとして表に引き出す。
引き出される主なノブはこうだ。
- プロバイダルーティング。Serper、BrightData、Firecrawl、Exa といった検索プロバイダをレジストリで正規化する。新しいHTTPプロバイダは、エンドポイント・ヘッダ・リクエストテンプレート・レスポンスのフィールド対応・コスト情報を書いたYAMLアダプタを足すだけで載る。
- ソースを保つ整形。検索結果を title / url / content の構造化レコードに正規化し、出典URL付きの番号付きスニペットとしてモデルに渡す。取得テキストを不透明な一塊に溶かし込まない。
- フォールバック連鎖。プロバイダがタイムアウトやエラーを返したら、設定したフォールバック先へ自動的に流す。一時障害でgrounding文脈が途切れない。
- 取得深さ。モデルに渡す件数(max_results)を2〜15件で調整できる。
- 二層キャッシュ。完全一致キャッシュと意味キャッシュを重ねる(後述)。
モデルに渡る整形済みの文脈は、こういう素朴な形になる。
Result 1
Title: Kulangsu, a Historic International Settlement
Source: https://whc.unesco.org/en/list/1541/
Content: UNESCO World Heritage page for Kulangsu / Gulangyu.
出典が一行ずつ明示されるので、モデルは「検索結果によると〜」と前置きを生成する動機が薄れる。検索を構造化されたツール応答として、安定した出力境界の内側に閉じ込めておくことで、出力契約が守られる。先ほどの例なら、native出力の245文字が、DSGでは Yes の3文字に戻る。
一度引いた検索を使い回すキャッシュ
コスト削減の主役はキャッシュだ。ゲートウェイはクエリが来るとまず正規化して完全一致キャッシュを引く。外れたらクエリを埋め込みベクトルにして意味キャッシュの最近傍を探し、コサイン類似度が閾値τ以上なら、その過去結果を再利用する。どちらも当たらなければ初めて実プロバイダのフォールバック連鎖を叩く。キャッシュにはプロバイダ・ドメインごとのTTLが付くので、鮮度が要る検索はすぐ失効し、変わらない事実は長く残る。
効果は露骨だ。SimpleQAのクエリを二周流すリプレイ実験で、一周目(コールド)はヒット率6.2%・$0.7385だったのが、二周目(ウォーム)はヒット率99.4%・$0.0045まで落ち、レイテンシも68%下がった。同じ検索を二度買わない、というだけの話だが、エージェントが似たクエリを大量に投げる本番では効きが大きい。
💰 SimpleQAで91%減、ただし鮮度はnativeの勝ち
5つのフロンティアモデル(GPT-4o、GPT-4o-mini、Gemini 2.5 Flash、Gemini 2.5 Pro、Claude Sonnet 4)の平均で、SimpleQAの結果はこうなる。
| 構成 | 正答率 | 検索コスト(1,000クエリ) |
|---|---|---|
| 検索なし | 30.8% | $0 |
| native検索 | 87.7% | $20.00 |
| DSG + BrightData | 86.1% | $1.80 |
| DSG + Serper | 83.3% | $0.67 |
native とほぼ同じ正答率を、検索コスト91%減で出している。DoorDash自身のeコマースのクエリ意図理解(QIU)ワークロードではさらに極端で、native(Gemini Flash)の93.40%・$7.90に対し、DSG+Serperは93.90%・$0.110。精度はわずかに上、コストは98.6%減だ。これを共有の本番grounding層として、モデルを差し替え可能なまま動かしているという記述が、研究で終わっていない証拠になっている。
ただし万能ではない。鮮度が物を言うFreshQAでは native が72.6%でDSG(68.0%)を上回った。プロバイダ側が抱える独自の鮮度パイプラインは、汎用の検索APIとキャッシュでは再現しきれない。HotpotQAのような多段推論でも、検索の上乗せは単段の事実検索ほどは効かない。だからDSGの結論は「常に勝つ」ではなく、「制御が効くべき場面では native より広いフロンティアを引ける」という慎重なものだ。この線引きの誠実さには好感を持った。
検索を「モデルの機能」として丸呑みしない
LiteLLMのようなモデルゲートウェイで、モデルを差し替え可能な境界に変えるのは、もう当たり前の設計になった。DSGはそれを検索に対してやっただけ、とも言える。だが効いてくる場面は地味じゃない。検索APIの請求書、プロバイダロックイン、そして構造化出力をエージェントに守らせる終わりのない戦い。この三つに心当たりがあるなら、検索をモデルの機能として丸呑みするのをやめて、自分が制御するゲートウェイの裏に追い出す、という選択肢を一度検討する価値はある。コードはまだ公開されていないが、設計の骨子(プロバイダのYAML抽象、二層キャッシュ、出典付き整形)は論文から十分に追える。