【geek-terminalニュース】脱ベクトルDB論とRAG検索基盤の最新情報

【事象の全貌と背景】
以前お伝えしたPageIndexやベクトルメモリ劣化の続報です。今回の焦点は、RAGの主役が「ベクトルを保存する箱」から、「検索、ランキング、根拠提示、レイテンシ制御まで含む実行基盤」へ移りつつある、という地味だがかなり根の深い変化です。ただし最初に線引きしておくと、Turbopufferのストレージ再設計、Perplexityのpplx-embed-v2-context-9b-preview、Photon、Cohere Embed 5に関する具体的な性能値や製品構成は、提示された公式・大手メディア確認枠では独立確認されていません。したがって本稿では、Turbopuffer自社ブログやMarkTechPost報道に基づく先行情報として扱い、断定ではなく「説明されています」「報じられています」というトーンで整理します。

そのうえで、動きとしては非常にギーク向けです。Turbopufferは「RIP vector database」というかなり挑発的な文脈で、従来のサーバレス・ベクトルDBから、文書とインデックスの配置、書き込み、コンパクション、クエリ実行を作り替える新ストレージエンジン、通称turbopuffer v3へ移行すると説明しています。ここで重要なのは、ベクトル検索を捨てる話ではないことです。むしろ逆で、ベクトルインデックスだけを設計の中心に置くと、現代のRAGで必要な複合検索、フィルタリング、ランキング、根拠抽出、低レイテンシ応答に耐えにくくなる。だから「ベクトルDB」というカテゴリ名そのものを越えて、検索実行基盤として再設計する必要がある、という主張です。

公式確認済みの周辺事実としては、Microsoft LearnのSQL Server Management Studioリリースノートで、vector data type、vector index operations、Query Plansに関する対応が示されています。これは「脱ベクトルDB」を裏づける直接証拠ではありません。むしろ既存DB管理ツール側にもベクトル型やベクトルインデックス操作が取り込まれていることを示す話です。つまり業界全体では、ベクトルが消えるのではなく、ベクトルが通常の検索・DB・クエリ計画の中に吸収されていく局面に入っている、と見るのが自然です。

【技術的ディープダイブ】
Turbopufferの主張で刺さるのは、「ベクトルインデックスをストレージ設計の主役から外す」という点です。従来のRAGは、文書をチャンク化し、埋め込みを作り、ベクトルDBに入れ、クエリ時に近傍検索して上位k件をLLMへ渡す、という流れが定番でした。しかし実運用では、単純な近傍検索だけでは足りません。日付、権限、テナント、ソース種別、鮮度、引用可能性、重複排除、再ランキング、回答に使える証拠の密度まで見ないと、ユーザーの体感品質はすぐ崩れます。だから問題は「ANNが速いか」だけではなく、「どのクエリプランをどの順番で走らせ、どの段階で候補を絞り、どこでランキングし、どの根拠を残すか」へ移っています。

関連してTurbopufferは、BYOE、つまり利用者が外部で埋め込みを作って持ち込む方式から、埋め込み処理をサービス内部へ寄せる方向も示しており、検索レイテンシ低下を主張しています。これも単なる便利機能ではありません。埋め込みモデル、チャンク化、ストレージ、インデックス、再ランキングが別々のサービスに分かれるほど、RAGはネットワーク往復、形式変換、バージョン不整合、評価困難性を抱えます。ネイティブ埋め込みは、その断絶を検索基盤側で吸収しようとする設計です。

Perplexity ResearchとTurbopufferについては、RAG向けの文脈埋め込みモデル「pplx-embed-v2-context-9b-preview」が公開されたと報じられています。このモデルは、各チャンクを単体ではなく文書全体の文脈込みで埋め込む設計とされ、単なる「正解チャンク」検索ではなく、回答とそれを支える証拠文脈の検索を改善する狙いがあると説明されています。ここが非常に重要です。RAGの失敗は、検索ヒットがゼロになることよりも、「それっぽいが回答の根拠としては弱い断片」を拾うことで起きがちです。文脈埋め込みは、チャンクを孤立したベクトル点ではなく、文書内での意味的な役割ごと持ち込もうとするアプローチです。

さらにPerplexityは、Rust製の社内検索・ランキングエンジン「Photon」も公開したと報じられています。報道では、既存のオープンソース派生エンジンを置き換え、全本番トラフィックの検索とランキングを処理し、p99レイテンシを800msから65msへ削減したとされています。この数値は公式・大手メディア確認枠では独立確認されていないため、あくまで報道ベースとして扱う必要がありますが、仮に方向性が正しいなら、RAG競争の重心はモデルサイズだけでなく、検索エンジンの実装言語、メモリ配置、ランキングパイプライン、テールレイテンシ制御へ広がっていることになります。平均レイテンシではなくp99が語られている点も、実サービスの匂いが濃い。AI検索では、たまに遅い1リクエストが体験全体を壊すからです。

Cohere Embed 5については、最大品質重視の「embed-v5.0-pro」と、高スループット・低レイテンシ向けの「embed-v5.0-fast」が用意されたと報じられています。また、マルチモーダル入力と128kトークンのコンテキストウィンドウに対応するとも説明されています。ここから見えるのは、埋め込みモデル自体も一枚岩ではなくなっていることです。インデックス作成時には重くても高精度なモデルを使い、クエリ時には速いモデルや別系統の検索エンジンで回す。あるいはテキスト、画像、PDF、社内文書を同じ検索体験に載せる。RAGは「ベクトルDBを選ぶ」問題から、「検索スタック全体をどう分業させるか」という設計問題へ移っています。

【コミュニティの生々しい熱量と議論】
今回、提示された検索結果2にはReddit、Hacker News、lobste.rs、LessWrongなどの具体的な投稿や引用が含まれていません。そのため、実在するコミュニティ発言を引用したように見せることはできません。ここはかなり大事です。Geek Terminal的には、Redditの熱狂やHNの辛辣なツッコミを入れたい題材ですが、素材がない以上、架空の「現場の声」を作るのはアウトです。

ただし、議論が起きるポイントはかなり明確です。肯定派が食いつくのは、RAGの品質問題が「ベクトルDBを入れれば解決」ではなかったことを、インフラ側がようやく正面から認め始めたように見える点でしょう。これまで多くのAIアプリ開発者は、検索漏れ、古い情報の混入、同義語の弱さ、権限フィルタの遅さ、引用根拠の薄さ、再ランキングのコストに苦しんできました。なので「ベクトルDBではなく検索実行基盤だ」という言い方は、現場の痛みにかなり近い。

一方で、懐疑派の視点も強いはずです。「脱ベクトルDB」と言いながら、結局はベクトルを使っているのではないか。単にベクトルDBベンダーが検索エンジン化、あるいはRAGプラットフォーム化しているだけではないか。Photonのp99 800msから65msという数字も、比較条件、ワークロード、ランキング段数、キャッシュ状態、ハードウェア、クエリ分布が見えなければ評価しにくい。Cohere Embed 5のPro/Fast構成も、実際には価格、スループット、ドメイン適合、再学習コスト次第です。こうした疑問は健全です。RAG基盤はベンチマークだけでなく、実データと運用制約で化ける領域だからです。

ギーク的に一番面白いのは、検索品質の議論が「モデルを賢くする」から「検索パイプラインを機械として仕上げる」へ戻ってきたことです。チャンク設計、文脈埋め込み、ネイティブ埋め込み、複合インデックス、クエリプラン、再ランキング、根拠提示、p99レイテンシ。どれも派手なデモ映えはしません。しかしAIアプリの体感品質は、まさにこの地味な層で決まります。LLMが最後に美文を書いても、渡された証拠が薄ければ幻覚する。逆に検索基盤が強ければ、少し小さなモデルでもかなり実用的に見える。この逆転が今回の本質です。

【今後の展望とエコシステムへの影響】
「ベクトルDBがオワコンになる」というより、「ベクトルDBだけでRAGを語る時代が終わる」と見るべきです。ベクトルインデックスは残ります。むしろMicrosoftのSSMS対応のように、一般的なDBや管理ツールにもベクトル型とベクトルインデックス操作は広がっています。ただし、価値の中心はベクトル保存そのものから、検索実行計画、ランキング、マルチモーダル文脈、証拠提示、低レイテンシ運用へ移ります。

この変化はAIアプリ開発の選定基準を変えます。これまでは「どのベクトルDBが速いか」「どの埋め込みモデルが強いか」を別々に比較していました。これからは、インデックス時とクエリ時を分けて最適化できるか、文書全体の文脈をチャンクへ反映できるか、権限フィルタやメタデータ検索とベクトル検索を自然に統合できるか、p99レイテンシを制御できるか、回答に使った根拠を監査できるかが問われます。RAGの勝負は、保存層ではなく実行層へ下りてきています。

企業利用では、この流れはさらに強くなります。社内文書検索、カスタマーサポート、法務、医療、金融のような領域では、正しそうな回答よりも、どの文書のどの根拠に基づくかが重要です。つまり検索結果は、LLMへ渡す燃料であると同時に、監査ログであり、説明責任の材料でもあります。文脈埋め込みやランキングエンジンが注目されるのは、単に精度を上げたいからではなく、RAGをプロダクト品質にするための足場だからです。

今回のニュース群は、公式・大手メディアによる独立確認が限定的なため、個々の性能値を確定事実として扱うべきではありません。それでも方向性としては、かなり筋が通っています。RAGは「ベクトルDBを入れたら完成」ではなく、「検索、埋め込み、ランキング、証拠、運用レイテンシをまとめて設計する」段階に入った。ベクトルDBの墓標ではなく、RAGインフラの成人式。派手なモデル発表の陰で、AIアプリの体感を決める土台が静かに組み替わっています。