現在の標準構成は、BM25 などの lexical 検索とベクトル検索を並走させて候補を広く取り、cross-encoder の rerank モデルで上位のみに絞り込む二段構成だ。ベクトル検索は言い換えに強い一方、TypeError: cannot read properties のようなエラーメッセージや固有名詞のような完全一致には弱く、この取りこぼしは埋め込みモデルの改善だけでは直らない。lexical 側で広い網を張り、精度が要求される最終段だけ計算コストの高い cross-encoder に任せる、という役割分担がここに来て一巡した。
この構成が既定線になったのは、埋め込みモデル単体を磨き続けるより、検索段を分業させたほうが安く速く精度が上がると各社が同じ結論に達したからだ。rerank を後付けの最適化ではなく最初から組み込む前提の機能として提供する動きが、この構成の定着を裏付けている。
", "examples": [ { "product": "Perplexity（検索基盤、Vespa.ai 上に構築）", "approach": "lexical・embedding 双方のスコアラーで数億〜数十億文書規模から広く候補を取り、cross-encoder の rerank で section・span 単位まで絞り込む", "detail": "毎時数百万件規模のクエリを処理する実運用環境で、ハイブリッド検索＋多段 rerank が機能することを示す代表例", "source_url": "https://blog.vespa.ai/perplexity-show-what-great-rag-takes/" }, { "product": "Databricks Mosaic AI Vector Search", "approach": "rerank 機能を単一パラメータで追加できる形で Public Preview 提供し、enterprise ベンチマークで recall@10 を 74% から 89% に改善", "detail": "rerank を『後から足す最適化』ではなく標準機能として組み込んだ、二段構成の一般化を示す事例", "source_url": "https://www.databricks.com/blog/reranking-mosaic-ai-vector-search-faster-smarter-retrieval-rag-agents" } ], "takeaway": "これから RAG を組むなら最初からハイブリッド＋rerank を既定にする。ベクトル単体で始めて後から rerank を足すのは二重管理になりやすく、Databricks のように標準機能で提供されているなら最初から使う方が合理的。" }, { "heading": "検索を『事前の一回』ではなく『エージェントのループ内ツール』にする", "body_html": "Cognition は SWE-grep / SWE-grep-mini という検索専用モデルを強化学習で訓練し、コーディングエージェントの検索段に組み込んだ。1 ターンあたり最大 8 並列のツール呼び出しを、最大 4 ターン（探索 3 回＋回答 1 回）まで繰り返させる設計で、単発の埋め込み検索でも逐次的なツール呼び出しの繰り返しでもない、第三の形になっている。SWE-grep-mini は毎秒 2,800 トークン超という速度で、Haiku 4.5 比で約 20 倍速いという。
この設計転換の動機は明快で、既存のコーディングエージェントは最初のターンの 60% 以上を検索に費やしていた。埋め込み検索は複雑な多段クエリを取りこぼし、逐次的なエージェント検索は精度が出ても遅い。汎用 LLM に検索を任せるのではなく、検索専用の軽量モデルを間に挟むことで、この速度と精度のトレードオフを崩さずに済ませている。
", "examples": [ { "product": "Cognition SWE-grep / SWE-grep-mini（Windsurf の Fast Context）", "approach": "RL で訓練した検索専用モデルが 1 ターン最大 8 並列・最大 4 ターンの検索をエージェントのループ内で実行し、Fast Context として最大 20 倍高速にコード検索を提供", "detail": "検索を事前処理ではなくエージェントが繰り返し呼ぶツールとして設計した具体例で、埋め込み検索単体・逐次エージェント検索双方の弱点を狙って作られている", "source_url": "https://cognition.com/blog/swe-grep" } ], "takeaway": "1 回のベクトル検索では終わらない多段・探索的なクエリ（特にコード検索）は、汎用 LLM に検索させるより、検索専用の軽量モデルをエージェントのループに挟む設計を検討する。" }, { "heading": "検索基盤のコスト構造が設計の自由度を規定する", "body_html": "Notion は 2 年かけてベクトル検索基盤を作り直した。専用ハードウェアの pod 構成から turbopuffer によるサーバーレス構成へ移行し、ページ編集のたびに全文を再埋め込みしていた処理をハッシュ差分検出に切り替えて再計算範囲を絞り、埋め込み生成・推論を Ray on Anyscale の単一基盤へ統合した。結果としてコストは合計で約 9 割削減され、クエリレイテンシは 70-100ms から 50-70ms に改善しながら、アクティブワークスペースは 15 倍に成長した。
この事例が示すのは、ハイブリッド検索や rerank、エージェント型の多段検索を足すほど呼び出し回数とコストが増えるという単純な事実だ。どのパターンを選べるかは、検索基盤がその呼び出し回数に耐えるコスト構造になっているかに先に規定される。パターンの選定と基盤コストの最適化は、もはや別々の意思決定ではない。
", "examples": [ { "product": "Notion（ベクトル検索基盤の 2 年間の刷新）", "approach": "turbopuffer への移行・ハッシュ差分による再埋め込み削減・Ray on Anyscale への統合で、コストを約 9 割削減しつつレイテンシと 15 倍のスケールを両立", "detail": "検索パターンそのものではなく、検索を支える基盤コストの作り直しが規模拡大の前提条件になったことを示す一次情報", "source_url": "https://www.notion.com/blog/two-years-of-vector-search-at-notion" } ], "takeaway": "rerank やエージェント型の多段検索を足す前に、自社の検索基盤が呼び出し回数の増加に耐えるコスト構造かどうかを先に確認する。基盤側のボトルネックがあると、正しいパターンを選んでも本番投入できない。" } ] }, "editorial": "ハイブリッド検索＋rerank の二段構成はもう『業界の合意』として決着し、争点は次の層に移った。検索をエージェントのループにどう埋め込むか、そしてその埋め込みを支える基盤コストをどう抑えるか。Notion の事例が示す通り、後者を無視して前者だけを追うと本番では回らない。", "quick_picks": [ { "title": "Amazon S3 Vectors が正式リリース、ベクトル保存コストを最大 9 割削減", "summary": "オブジェクトストレージにネイティブなベクトル検索機能を持たせ、専用ベクトル DB 比でコストを最大 90% 削減できると AWS が公式発表した。本号の『基盤コストが検索パターンの選択肢を規定する』という論点と直接つながる動き。", "url": "https://aws.amazon.com/blogs/aws/amazon-s3-vectors-now-generally-available-with-increased-scale-and-performance" }, { "title": "Voyage AI、指示追従型の rerank-2.5 / rerank-2.5-lite を公開", "summary": "自然言語の指示でランキング基準を調整できる rerank モデルを Voyage AI が公式発表し、コンテキスト長も Cohere Rerank v3.5 比で 8 倍の 32K トークンに拡張した。本号のハイブリッド検索＋rerank 構成における rerank 側の選択肢が広がっている一例。", "url": "https://blog.voyageai.com/2025/08/11/rerank-2-5/" }, { "title": "GitHub、Copilot のコード検索向け新埋め込みモデルを投入", "summary": "検索精度を 37.6% 向上させつつインデックスサイズを 8 分の 1 に縮小した新しい埋め込みモデルを GitHub が公式発表した。埋め込み側の改善が二段構成の一段目（候補生成）の質を底上げする、本号の議論と直接つながる事例。", "url": "https://github.blog/news-insights/product-news/copilot-new-embedding-model-vs-code/" } ] }