検索インフラとベクトルストア

ベクトル検索の概念実証と、実際のクエリ量に耐える本番システムは、まったく別のエンジニアリング課題です。私たちは、あなたのRAGパイプライン、エージェント型ワークフロー、あるいはセマンティック検索製品の土台となる検索インフラ層を構築・運用します——ベクトルエンジン、それに供給する埋め込みパイプライン、健全性を保つインデックスのライフサイクル管理、そしてユーザーが気づく前に品質劣化を捉える可観測性スタックです。

私たちはエンジンについてベンダーニュートラルです。当社の実践は、以下を横断してエンジンに依存しません： Qdrant、Milvus、Weaviate、pgvector、Elasticsearch kNNそしてどれを推奨するかは、ベクトル数、クエリパターン、マルチテナンシー要件、運用能力によって決まります。

5万ベクトルのデモから2億ベクトルの本番へ

デモと本番システムの間のギャップは、ほぼ全面的にインフラの問題です。デモは 5万ベクトル をPineconeに読み込み、コサイン類似度クエリを実行し、 40msで結果を返します。本番はそれとはまったく異なります。

• 2億ベクトル と 毎秒500クエリ の持続
• 15のメタデータフィルタ次元 と、ドキュメントの更新頻度は 毎時
• 厳格なテナント分離のもとで1つのクラスタを共有する3チーム

その規模では、HNSWコンパクションのスパイクがP99を 800msまで押し上げ、増分更新を1週間続けると再現率が静かに劣化し、埋め込みパイプラインはドキュメントの変更率に追いつけなくなります。ここが私たちの働く領域です。

エンジン選定はベンチマークの作業であって、ブランドの決定ではない

どのベンダーも最高クラスの性能を謳いますが、ベンチマークはより微妙な実態を語ります。私たちは機能マトリクスからデータベースを選びません——あなたの実際のベクトルを読み込み、あなたの実際のメタデータフィルタで実際のクエリを実行し、運用上意味のある k 値における再現率を、同時負荷下のP50/P95/P99レイテンシとともに測定します。

その結果は、ベンダーのマーケティングとしばしば矛盾します。Pineconeのサーバーレス階層は費用対効果が高く見えますが、持続的な高QPSワークロードが読み取りユニットコストを自己ホスティングの損益分岐点を超えて押し上げるまでのことであり、pgvectorは制約が多く見えますが、反復スキャンがフィルタ検索のギャップを埋めるまでのことです。

埋め込みパイプラインこそ、本番の検索が実際に破綻する場所である

チームは 60% のベクトル検索エンジニアリング労力を、ストアではなくパイプラインに費やしています。パイプラインは、ドキュメントの取り込み、チャンキング、埋め込みモデルの推論、ドキュメント更新時の増分再インデックス、メタデータの伝播を扱います——そしてすべての段階に、検索品質を静かに劣化させる障害モードがあります。

• 古くなった知識 ——本番RAGで2番目に多い障害です。Confluenceでドキュメントが更新されても、インデックスは依然として古い埋め込みを提供します。修正策は、毎晩のバッチ再インデックスではなく、増分的に再埋め込みする変更データキャプチャ（CDC）トリガーです。
• ゴーストドキュメント ——ソースドキュメントが削除されてもそのベクトルが残り、もはや存在しないコンテンツの結果を返します。信頼できる情報源システムとベクトルストアにまたがるアトミックなトランザクションは分割アーキテクチャではほぼ不可能なため、私たちは孤立したベクトルを検出して除去する調整層を構築します。

埋め込みモデルの選定は、ほとんどのチームが認識している以上に重要であり、後から切り替えるのは高コストです： 800万ドキュメント を text-embedding-ada-002 から text-embedding-3-large へアップグレードする際の再埋め込みには数日の計算コストがかかり、ダウンタイムを避けるためのデュアルライトインフラが必要です。私たちは、あなたがコミットする前に、ドメイン固有のクエリセットに対してモデルを評価します。

• Cohere embed-v4 —— 100万トークンあたり0.01ドル で、 100以上の言語にわたる多言語検索をリードします。
• Nomic Embed v2 —— 1億3,700万パラメータで、CPU上で動作し、市場で最高の品質対サイズ比を備えます。
• OpenAI text-embedding-3-large ——優れたオールラウンダー。

適切な選択は、言語構成、レイテンシ要件、そしてAPI依存を許容できるかオンプレミス推論が必要かによって決まります。

インデックスのライフサイクル：誰も警告してくれない運用上の問題

HNSWインデックスは劣化します——バグではなく、アーキテクチャ上の現実です。 1億6,000万ベクトルでは、HNSWの完全な再構築に 3〜6時間を要します。増分更新はグラフ構造を最適でない状態にし、時間とともに再現率を蝕みます。コンパクションイベントはクエリのレイテンシをスパイクさせ、あらゆるアップサート、削除、セグメントマージが、クエリ提供ではなく保守にCPUを費やすサブインデックスの再構築を引き起こします。このトレードオフは避けられません： 0.8から0.95の再現率 へ押し上げると、HNSWのレイテンシは約 31%増加します。

私たちは、品質を損なうことなく継続的な取り込みを吸収するライフサイクル管理を設計します：

• ブルーグリーン・インデックスローテーション ——別のインフラ上で再構築し、ゼロダウンタイムでアトミックに切り替えます。
• 自動化された再現率検証ゲート ——すべての主要な操作の後、ゴールデンクエリセットを現在のインデックスと比較します。再現率が閾値を下回れば、切り替えは行われません。
• GPU加速のHNSW構築 は、QdrantとElasticsearchで再構築時間を1桁短縮します。ただし、いつ再構築し、どう検証し、どう切り替えるかのオーケストレーションはカスタムエンジニアリングです。

量子化はこれをさらに押し進めます。Qdrantは現在、 1.5ビット、2ビット、非対称 の量子化を提供し、ElasticsearchのBBQはヒープを float32と比較して95%以上削減します。これらはメモリを節約しスループットを向上させますが、各方式は異なるデータ分布に対して異なる再現率プロファイルを持ちます——そのため私たちは、本番で量子化を導入する前に、あなたの具体的なベクトルに対する再現率への影響を特性評価します。

実際の規模でのマルチテナンシーと分離

を提供するプラットフォームチーム 200以上の社内MLチーム、あるいは数千の顧客テナントを持つSaaS製品には、分離を保証するインフラが必要です：テナントAのクエリがテナントBのデータを返してはならず、監査ログはすべてのクエリをテナントの識別情報まで追跡でき、コールドテナントがホットテナントの必要とするリソースを消費してはなりません。

• Weaviate ——テナント状態（ACTIVE、INACTIVE、S3へのOFFLOADED）を持つワンシャード・パー・テナントモデルは、高テナント数のデプロイメントにとって最も成熟した実装です。
• Milvus ——データベース、コレクション、パーティション、あるいはパーティションキーのレベルでの分離をサポートし、コンプライアンス要件に粒度を合わせます。

どちらも規模ではカスタムオーケストレーションを要します——テナントのプロビジョニング、状態遷移、クォータ管理、テナント間の漏洩検出は、データベース自体が扱うものではありません。私たちは、 SOC 2またはISO 27001 コンプライアンスを必要とする規制対象デプロイメントのために、マルチテナンシーを管理可能にする運用層を構築します。

エージェント型ワークフローがインフラ要件を再構築している

エージェント型AIの波は、ベクトルストアがなすべきことを変えます。静的なRAGは固定コーパスに対してドキュメントを検索します。エージェント型ワークフローは、 エピソード記憶 （会話履歴と中間推論）、大規模なドキュメントコーパスにわたる セマンティック検索 、そして ユーザープロファイル層 を必要とします——多くの場合、単一のエージェントステップでこの3つすべてに同時にアクセスします。 サブ400ms というレイテンシ要件はバッチRAGよりも厳しく、ACIDトランザクションのサポートは、部分書き込みなしで状態を更新するマルチステップエージェントにとって不可欠になりつつあります。

単一のベクトルデータベースでこの3つのメモリ層すべてをうまく扱えるものはないため、チームはマルチストア・アーキテクチャを組み立てます： Redis はセッション状態用、 QdrantまたはMilvus はセマンティック検索用、そして グラフデータベース は関係性の追跡用です。 OracleのUnified Memory Core（2026年3月） は、ベクトル、JSON、グラフ、リレーショナル、空間の各クエリを1つのエンジンに収束させようとしています。私たちは、エージェント型システム向けの検索層を設計します——どのストアがどのメモリタイプを扱うか、クエリがどのようにストア間をルーティングされるか、そしてエージェントが単一の推論ステップで複数のバックエンドにまたがって状態を更新する際に、どのように一貫性が保たれるか。

私たちが提供するもの

すべてのエンゲージメントは、 ベンチマークフェーズから始まります：あなたのベクトルを読み込み、あなたのクエリを実行し、定量化されたエンジン推奨を作成します。そこから、私たちは本番インフラを構築します：

• この ベクトルストア・クラスタは、キャパシティプランニングとスケーリングのランブックを備えます。
• この 埋め込みパイプラインは、CDCトリガーの増分再インデックスとモデルバージョン管理を備えます。
• この インデックス・ライフサイクル自動化は、ブルーグリーン・ローテーションと再現率検証ゲートを備えます。
• この マルチテナンシー・オーケストレーション層は、テナント分離が必要なときに用います。
• この 可観測性スタックは、ドリフト検出、再現率回帰アラート、P95/P99レイテンシ監視を備えます。
• 移行ツール は、エンジン間を移行するチーム向けで、中間の Parquet 形式を用いて、完全な再埋め込みを強いるのではなく、次元数が一致する場合に埋め込みを保持します。

私たちは、すべてのエンゲージメントを明示的な 月次インフラコスト予測でスコープするので、コミットする前に本番のコストがわかります。