エージェント的AIの世界でベクトルデータベースはどんな役割を果たすのか？それは、最近の数か月で組織が向き合ってきた問いだ。これは確かな勢いを持つ論点だった。大規模言語モデルが百万トークンの文脈ウィンドウへと拡張するにつれて、企業アーキテクトの間で信頼できる主張が流布した。目的別に構築されたベクトル検索はつかの間の手段であり、インフラストラクチャではない。エージェント的記憶は検索の問題を吸収するだろう。ベクトルデータベースはRAG時代の遺物だった。
実運用の証拠は、逆の方向へ進んでいる。
Qdrant、ベルリン拠点のオープンソースベクトル検索企業は、木曜日に5000万ドルのシリーズBを発表しました。これは、2年前の2800万ドルのシリーズAの2年後です。このタイミングは偶然ではありません。同社はプラットフォームのバージョン1.17も出荷しています。これらは一緒に、特定の主張を反映しています：エージェントが現れたとしても、検索の問題は縮小せず、拡大して難しくなった。
「人間は数分ごとにいくつかのクエリを行いますが、」とQdrantのCEO兼共同創業者アンドレ・ザヤルニはVentureBeatに語った。「エージェントは毎秒数百、時には数千のクエリを処理し、意思決定を可能にする情報を集めているだけだ。」
その変化は、RAG時代のデプロイメントが設計されていなかった方法で、インフラ要件を変えます。
記憶だけでは置換できない理由: エージェントには検索レイヤーが必要
エージェントは、訓練されていない情報で動作します。企業の独自データ、最新情報、継続的に変化する数百万の文書。コンテキストウィンドウはセッション状態を管理しますが、それらのデータを高いリコールで横断検索したり、変化に応じた検索品質を維持したり、自律的意思決定が生み出すクエリ量を支えたりすることはできません。
「現在あるAIメモリのフレームワークの大半は、何らかのベクトルストレージを使用しています」とザヤルニは言いました。
その意味は直接的です。記憶の代替として位置づけられているツールであっても、下には検索インフラが依存しています。
ロードに対してその検索レイヤーが目的別に作られていないとき、3つの失敗モードが現れます。文書規模では、見逃しは遅延の問題ではなく、単一エージェントターンの各検索パスで意思決定の質を積み上げる品質問題です。書き込み負荷の下では、新しく取り込まれたデータが最適化されていないセグメントに留まるため、インデックス作成が追いつかず、最新データの検索は遅く、現在情報が最も重要なときに正確さが低下します。分散インフラを横断しては、1つの遅いレプリカがエージェントターンのすべての並列ツール呼び出しに遅延を伝播させます。人間のユーザーには不便として受け止められる遅延ですが、自律的なエージェントには耐え難いです。
Qdrantの1.17リリースは、それぞれを直接対応します。関連性フィードバック・クエリは、次の検索パスでの類似度スコアを軽量なモデル生成信号を用いて調整することでリコールを改善します。埋め込みモデルを再訓練することなく。遅延ファンアウト機能は、最初のレプリカが設定可能なレイテンシ閾値を超えた場合に2番目のレプリカを照会します。新しいクラスター全体のテレメトリAPIは、ノードごとのトラブルシューティングをクラスタ全体を横断する単一ビューに置き換えます。
なぜQdrantはもうベクトルデータベースとは呼ばれたくないのか
ほぼすべての主要データベースが現在、ベクトルをデータ型としてサポートしています――ハイパースケーラーから従来のリレーショナルシステムまで。この変化は競争の論点を変えました。データ型はもはや参入条件です。残る専門分野は、実運用スケールでの検索品質です。
この区別が、ザヤルニがQdrantをベクトルデータベースと呼ばれたくない理由です。
「AI時代の情報検索レイヤーを構築している」と彼は語った。「データベースはユーザーデータを保存するためのものだ。検索結果の品質が重要なら、検索エンジンが必要だ。」
初めてのチームへのアドバイス: すでにスタックにあるどのベクトル対応を使ってください。目的別検索へ移行するチームは、規模がその問題を強いるときにそうします。『私たちは毎日、Postgresから始めて十分だと思っていたがそうではない』という企業が私たちのもとへ来るのを見ています。
QdrantのアーキテクチャはRustで書かれており、メモリ効率と低レベルの性能制御を、より高位の言語が同じコストで提供できない水準にしています。オープンソースの基盤はその利点をさらに強化します――コミュニティのフィードバックと開発者の採用が、Qdrantのような規模の企業が、はるかに大規模なエンジニアリング資源を持つベンダーと競合することを可能にします。
「それがなければ、私たちは現在の地位には全くいなかっただろう」とザヤルニは語った。
どうやって2つの現場チームが汎用データベースの限界を見つけたか
Qdrant上で本番AIシステムを構築している企業は、それぞれ異なる方向から同じ主張をしています。エージェントには検索レイヤーが必要で、対話的または文脈的なメモリはそれを代替できない、という主張です。
GlassDollarはSiemensやMahleを含む企業がスタートアップを評価するのを支援します。検索がコア製品です。ユーザーは自然言語でニーズを説明し、数百万社のコーパスからランク付けされた候補リストを返します。アーキテクチャはすべてのリクエストに対してクエリ拡張を実行します。1つのプロンプトが複数の並列クエリへと広がり、それぞれ異なる角度から候補を取得し、結果を結合して再ランクします。それはエージェント的リトリーバルパターンであり、RAGパターンではなく、大量運用を支えるためには目的別検索インフラが必要です。
同社はElasticsearchから移行し、インデックス済み文書が1,000万件に達する規模へと拡大する過程で、インフラコストを概算40%削減し、Elasticsearchの関連性ギャップを補うために維持していたキーワードベースの補償レイヤーを削除し、ユーザーエンゲージメントが3倍に増えました。
「私たちはリコールで成功を測る」とGlassDollarのプロダクト責任者カメン・カネヴはVentureBeatに語った。「結果に最高の企業が含まれていなければ、他の何も意味をなさない。ユーザーは信頼を失う。」
エージェント的メモリと拡張コンテキストウィンドウだけでは、GlassDollarが必要とする負荷を吸収できません。
「それはインフラの問題であり、会話状態管理の課題ではありません」とカネヴは言った。「コンテキストウィンドウを拡張するだけで解決できるものではありません。」
もう一つのQdrantのユーザーは &AIで、特許訴訟のためのインフラを構築しています。同社のAIエージェントAndyは、数十年、複数の法域にまたがる数億件におよぶ文書をセマンティック検索します。特許弁護士はAI生成の法的文書に基づいて行動しません。したがってエージェントが提示するすべての結果は現実の文書に根ざしていなければなりません。
「私たちの全体的なアーキテクチャは、生成ではなく検索をコアのプリミティブとすることで幻覚リスクを最小化するよう設計されています」と&AIの創業者兼CTOヘービー・ターナーはVentureBeatに語った。
&AIにとって、エージェントレイヤーと検索レイヤーは設計上別物です。
「Andy、私たちの特許エージェントはQdrantの上に構築されています」とターナーは言いました。「エージェントがインターフェースで、ベクトルデータベースがグラウンドトゥルースです。」
現状の設定を変更するべき3つのサイン
実用的な出発点は、すでにスタックに組み込まれているベクトル機能を使うことです。評価の焦点は、ベクトル検索を追加するかどうかではなく、現状の設定が適切でなくなる時です。その時点を示す3つのサインは、検索品質が直接ビジネス成果に結びつくこと、クエリパターンが拡張、多段再ランキング、あるいは並列ツール呼び出しを伴うこと、データ量が数千万件の文書を超えることです。
その時点で評価は運用上の質問へ移ります。現状の設定は、分散クラスタ全体で何が起きているかをどれだけ見えるようにしてくれるのか、エージェントのクエリ量が増えたときの性能余力はどれだけあるのか。
「現在、検索レイヤーを置換するものについて多くのノイズがあります」とカネヴは言いました。「検索品質が製品そのものであり、結果の欠落が実際のビジネスに影響を与えるような製品を作る人には、専用の検索インフラが必要です。」
