🧠 AI プロダクト動向

現在の標準構成は、BM25 などの lexical 検索とベクトル検索を並走させて候補を広く取り、cross-encoder の rerank モデルで上位のみに絞り込む二段構成だ。ベクトル検索は言い換えに強い一方、TypeError: cannot read properties のようなエラーメッセージや固有名詞のような完全一致には弱く、この取りこぼしは埋め込みモデルの改善だけでは直らない。lexical 側で広い網を張り、精度が要求される最終段だけ計算コストの高い cross-encoder に任せる、という役割分担がここに来て一巡した。

この構成が既定線になったのは、埋め込みモデル単体を磨き続けるより、検索段を分業させたほうが安く速く精度が上がると各社が同じ結論に達したからだ。rerank を後付けの最適化ではなく最初から組み込む前提の機能として提供する動きが、この構成の定着を裏付けている。

Cognition は SWE-grep / SWE-grep-mini という検索専用モデルを強化学習で訓練し、コーディングエージェントの検索段に組み込んだ。1 ターンあたり最大 8 並列のツール呼び出しを、最大 4 ターン（探索 3 回＋回答 1 回）まで繰り返させる設計で、単発の埋め込み検索でも逐次的なツール呼び出しの繰り返しでもない、第三の形になっている。SWE-grep-mini は毎秒 2,800 トークン超という速度で、Haiku 4.5 比で約 20 倍速いという。

この設計転換の動機は明快で、既存のコーディングエージェントは最初のターンの 60% 以上を検索に費やしていた。埋め込み検索は複雑な多段クエリを取りこぼし、逐次的なエージェント検索は精度が出ても遅い。汎用 LLM に検索を任せるのではなく、検索専用の軽量モデルを間に挟むことで、この速度と精度のトレードオフを崩さずに済ませている。

Notion は 2 年かけてベクトル検索基盤を作り直した。専用ハードウェアの pod 構成から turbopuffer によるサーバーレス構成へ移行し、ページ編集のたびに全文を再埋め込みしていた処理をハッシュ差分検出に切り替えて再計算範囲を絞り、埋め込み生成・推論を Ray on Anyscale の単一基盤へ統合した。結果としてコストは合計で約 9 割削減され、クエリレイテンシは 70-100ms から 50-70ms に改善しながら、アクティブワークスペースは 15 倍に成長した。

この事例が示すのは、ハイブリッド検索や rerank、エージェント型の多段検索を足すほど呼び出し回数とコストが増えるという単純な事実だ。どのパターンを選べるかは、検索基盤がその呼び出し回数に耐えるコスト構造になっているかに先に規定される。パターンの選定と基盤コストの最適化は、もはや別々の意思決定ではない。