初級呼び出し元 + 管理者
RAG を構築せずに、すべてのモデルへ Web 検索を
ゲートウェイ層での検索注入。クライアントのプロトコルごとにネイティブな検索ブロックを合成するため、オープンモデルにも検索グラウンディングが付きます。グレースフルにデグラデーションし、ハイジャックした検索は課金されません。
コミュニティが実際に不満を言っていること
オープン / セルフホストのモデルには検索がなく、時間に敏感な話題では弱点が露呈します。そのためだけに RAG スタックを構築するのは重すぎます。ベンダーの検索 API はそれぞれ形式と従量課金が異なるため、モデルを切り替えるたびに再統合が必要です。
「ゲートウェイですべてのモデルに検索を追加できないか」は、インテグレーターから繰り返し出る要望です。
GateLLM の実現方法
GateLLM はゲートウェイ層で検索をハイジャックします。検索エンジン(serper、インラインでテスト可能)を設定し、モデル単位の三状態トグル(ケイパビリティ宣言に従う / 強制オン / 強制オフ)でどのモデルに検索を付けるかを決めます。ヒット時はゲートウェイが先に検索し、結果を参考資料としてユーザーメッセージに注入してから、アップストリームモデルを呼びます。ベンダーのテキストが直接返ることはありません。
注入された内容はクライアントのプロトコルごとにネイティブな検索ブロック(Anthropic server_tool_use / OpenAI url_citation / Responses web_search_call)に合成されるため、クライアントは各 SDK のネイティブ形式で引用を描画します。
検索の失敗はリクエストをブロックせずグレースフルにデグラデーションし、ハイジャックした検索は利用量の課金対象外です。
実際に効果が出る 5 つのレバー
- エンジン管理:serper API キー + インラインテスト + 複数エンジンの優先度
- モデル単位の三状態トグル:ケイパビリティに従う / 強制オン / 強制オフ。優先順位はモデル > アップストリーム > ケイパビリティ宣言
- プロトコルごとのネイティブ検索ブロック:Anthropic / OpenAI / Responses がそれぞれの引用形式で描画
- 安全なデグラデーション:検索失敗がリクエストをブロックすることはなく、デグラデーションの理由はログ詳細のお知らせ領域に残る
- 課金の透明性:ハイジャックした検索は利用量の課金対象外。メモリ使用量には文書化された上限式がある