なぜ私たちはVector Lakebaseを構築したのか：AIエージェント時代に向けた非構造化データアーキテクチャの再設計
はじめに
ベクトルデータベースは、現代のAIアプリケーションにおける重要な課題の一つを解決しました。Embeddingを保存し、近似最近傍探索（ANN）やメタデータフィルタリングを組み合わせることで、RAG、セマンティック検索、レコメンド、パーソナライゼーション、AIエージェントなどに必要な低レイテンシー検索を実現できます。
一方、AIシステムが静的なアシスタントから継続的に稼働するエージェントへと進化する中、企業は非構造化データ基盤に対して、より広範な機能を求めるようになっています。単に情報を検索できるだけでは不十分であり、データを改善・再編成・分析・精緻化し、その成果を本番環境へ継続的に反映できる次のような処理も必要になります。
- 重複排除やクラスタリング
- データ品質の分析
- Embeddingモデル変更時の再Embedding
- オフライン評価
- 学習データの準備
- エージェントの軌跡やユーザーフィードバックの分析
- インデックスの再構築
- 権限、リネージ、モデルバージョンの管理
こうしたオンライン検索とオフライン処理を、分断された複数システム間でデータコピーしながら運用すると、整合性、コスト、再利用性の問題が生じます。こうした要件の変化は、システムアーキテクチャそのものを変えます。
Zillizのソリューションが、Zilliz Vector Lakebaseです。
Vector Lakebaseとは
Vector Lakebaseは、AIワークロード向けのレイクネイティブなデータアーキテクチャです。主に次の要素を統合します。
- 低レイテンシーなベクトル検索とハイブリッド検索(ベクトルデータベース水準のサービング性能)
- オープンなデータレイクストレージ
- レイク上で管理・再利用できるインデックス
- データ、メタデータ、権限、フィードバックを含む共通のセマンティックレイヤー
これで、同じ非構造化データをシステム間で複製することなく、オンラインAIアプリケーション、インタラクティブな探索、オフライン分析に活用できます。
これは、単なる検索とは異なる問いに答えるものです。つまり、本番AIチームが同じデータを、検索、探索、分析、ガバナンス、フィードバック、継続的な改善にわたって利用する必要がある場合、どのようなアーキテクチャが求められるのか、という問いです。
単純に「ベクトルデータベースとデータレイクを並べる」という考え方ではありません。非構造化・マルチモーダルデータを、検索、分析、拡張、バージョン管理、ガバナンスにまたがって再利用できる共通基盤として扱うことがポイントです。
これは、ベクトルデータベースを置き換えるものではなく、その概念と役割を拡張したものと捉えるのが最も適切です。Vector Lakebaseでは、ベクトル検索は引き続き中心的な役割を持ち、より広いAIデータ基盤の中でオンラインサービングを担います。
なぜ今、Vector Lakebaseが必要なのか
RAGやセマンティック検索の初期段階では、Embeddingを保存し、高速に検索できれば多くの要件を満たせました。しかし、システムが成熟すると、次のような問いが出てきます。
- 数十億規模のEmbeddingを調査し、クラスタや冗長性、ドリフトを把握するにはどうするか
- Embeddingモデルを変更したとき、データ全体をどう再処理するか
- 本番環境の検索ログ、引用、修正履歴、エージェントの軌跡をどう改善に利用するか
- アクセス頻度の低いコールドデータを、常時稼働の高価なコンピュートなしで検索できるか
- Iceberg、Lance、Parquet、オブジェクトストレージ上の既存データをどう活用するか
これらは検索エンジンだけの問題ではありません。フィードバックや新たなデータが生まれ、ディスカバリーがそれらをよりクリーンなデータや高品質なインデックスへと変換し、その改善結果を再び本番検索へ戻す継続的なループが必要です。
CS/CD：Continuous ServingとContinuous Discovery
Zillizはこのループを、**CS/CD（Continuous Serving / Continuous Discovery）**と表現しています。
Continuous Serving
本番環境で継続的に応答するワークロードです。
- 本番RAG
- エージェントメモリ
- セマンティック検索
- レコメンド
- パーソナライゼーション
- リアルタイムAIアプリケーション
Continuous Discovery
データを分析・改善するワークロードです。
- クラスタリング
- 重複排除
- 再Embedding
- データ品質分析
- オフライン評価
- 学習データの準備
- エージェント軌跡の分析
- インデックス再構築
オンライン環境からは、検索ログ、ユーザー行動、引用、訂正、フィードバック、エージェントの実行履歴などが生成されます。オフライン処理はそれらを分析し、データ、メタデータ、インデックス、セマンティックな文脈を改善します。その結果を新しいスナップショットとして本番環境へ戻すことで、検索品質を継続的に更新できます。
従来の構成では、ベクトルデータベースからデータをエクスポートし、別のバッチ基盤で処理してから再インポートすることがあります。この方法では、コピー間の不整合、インデックスの再構築、非アトミックな更新といった運用上の問題が起こり得ます。
Vector Lakebaseは、このループを一つの論理的なデータ基盤上で動かすことを目指しています。
3つの原則
Vector Lakebaseの考え方は、One Data、One Index、One Semantic Layerの3つに整理できます。
1. One Data
オープンなレイクストレージを、AIデータの共通基盤として利用します。対象はEmbeddingだけではありません。
- 文書、チャンク、コード、会話
- ベクトルとスカラーメタデータ
- 画像、音声、動画
- ログ、エージェントの軌跡
- 権限、リネージ、処理結果
- インデックス成果物
RAGアプリ、分析ジョブ、コンプライアンス確認、学習データ作成、再Embeddingのたびに別々のコピーを作るのではなく、同じ論理データを複数の用途から利用します。
2. One Index
インデックスを、特定のオンラインエンジン内部に閉じた実装詳細ではなく、再利用可能なデータ資産として扱います。
インデックスは、構築、バージョン管理、公開、再利用が可能で、どのデータスナップショットから作成されたかを追跡します。
用途に応じて、次のような利用形態が考えられます。
- ミリ秒単位の本番検索向けホットインデックス
- 対話的な調査向けのウォーム／キャッシュアクセス
- 探索やオフライン処理向けのレイク常駐データとインデックス
サービングとディスカバリーで別々にインデックスを作り直すことを避け、検索結果の一貫性を保つことが狙いです。
3. One Semantic Layer
Embeddingは非構造化データを表す一つの方法にすぎません。実用的なAI基盤では、次のような情報も必要です。
- 要約、ラベル、エンティティ、トピック
- チャンクと参照元
- アクセスポリシー
- Embeddingモデルや生成モデルのバージョン
- データリネージ
- ユーザーフィードバック
- 検索や評価の結果
共通のセマンティックレイヤーがあれば、RAGは信頼できるコンテキストを検索し、エージェントは過去のメモリやツール実行結果を再利用できます。ガバナンスでは、生成結果を元データやモデルバージョンまで追跡しやすくなります。
処理フローを4段階で見る
運用面では、この同じループが、データ取り込み、ベクトル化とエンリッチメント、クエリサービング、オフライン処理という4つのステージを通じて実行されます。
1. データ取り込み (Data Ingestion)
データは、ベクトルデータベースAPI、文書処理パイプライン、オブジェクトストレージ、既存のレイク形式などから取り込めます。
本番システムでは、本文だけでなく、出典、権限、鮮度、リネージ、ガバナンスルールも保持する必要があります。検索で見つかったすべての文書を同じ信頼度で扱うことはできないためです。
2. ベクトル化、拡張、インデックス構築
Embeddingを生成し、メタデータを付与したうえで、用途に応じた検索構造を構築します。
- ベクトルインデックス
- キーワードインデックス
- 全文検索インデックス
- JSONインデックス
- スカラーインデックス
アーキテクチャ上の重要なポイントは、インデックスが特定のサービングエンジンに依存しないことです。インデックスはバージョン管理、公開、再利用が可能であり、どのデータスナップショットを基に構築されたものかを追跡することもできます。
これにより、インデックスのライフサイクル管理は、個々のアプリケーション内部に埋め込まれた実装上の詳細ではなく、データ基盤そのものの一部となります。
3. クエリサービング
RAG、エージェント検索、セマンティック検索、マルチモーダル検索、レコメンド、AIメモリなどにクエリを提供します。
実際の検索では、ベクトル類似度だけでなく、キーワード、全文検索、メタデータ、権限、鮮度、情報源の品質、ハイブリッドランキングなどを組み合わせます。
4. オフライン処理
オフラインジョブでは、クラスタリング、重複排除、異常検知、品質分析、再Embedding、評価、学習データ探索、インデックス再構築などを実行します。
これらのワークフローは大規模なデータバッチを対象に実行され、必ずしもミリ秒単位のレイテンシーを必要とするわけではありません。しかし、オンラインアプリケーションで使用されているものと同じベクトル、メタデータ、インデックス、セマンティックコンテキストにアクセスできる必要があります。
これらの処理結果は、データレイク、インデックスシステム、セマンティックレイヤーへと書き戻されます。具体的には、よりクリーンなデータセット、精度の高いラベル、改善されたコンテキスト断片、新しいインデックスバージョン、更新されたフィードバックシグナルなどです。
また、それらはアトミックなスナップショットとして公開されるため、本番環境が構築途中の不完全なインデックスを読み込むことはありません。これが中核となる運用ループです。すなわち、サービングがフィードバックを生み、ディスカバリーがデータを改善し、改善されたデータが再びサービングへ戻ります。
3つのコンピュートモード
Zilliz Vector Lakebaseは、ワークロードの性質に合わせて3つのコンピュートモードを提供します。
| ワークロード種類 | コンピュートモード | 主な用途 | 特徴 |
|---|---|---|---|
| Real-time serving | Long-Running Compute | 本番RAG、リアルタイム推薦、オンラインエージェント | ホットデータとインデックスをメモリやローカルディスクに保持し、予測可能な低レイテンシーを重視 |
| Interactive discovery | On-Demand Compute | コールドデータ検索、異常調査、類似データ探索 | 必要なときに起動し、常時稼働クラスタを避ける。分単位の課金粒度に対応 |
| Batch analytics | Offline Batch Compute | クラスタリング、重複排除、全件再Embedding | 大規模ジョブを実行し、結果を公開した後にリソースを解放 |
日本企業における典型的な適用シーン（例）
Long-Running Compute
- EC サイトのリアルタイム推薦 ：EC 企業では、商品の類似検索やパーソナライズされた推薦を行うために、低レイテンシーのコンピュートモードを必要としています。特に「手ぶらでショッピング」機能では、画像ベースの商品検索をリアルタイムで行う必要があります。
- 医療業界の電子カルテ検索 ：病院では、患者の電子カルテや医学文献をリアルタイムで意味検索し、診断の参考にします。例えば、「糖尿病患者の最新治療法」といったクエリで、関連する論文や治療ガイドラインを即座に検索することができます。
- 製造業の品質管理 ：製造会社では、センサーデータから異常を検出するために、リアルタイムのベクトル検索を行います。これにより、故障を早期に発見し、メンテナンスの効率を向上させます。
- 金融機関のリスク管理 ：金融機関では、顧客の行動データからリスクを検出するために、リアルタイムのベクトル検索を使用します。これにより、不正取引を早期に発見し、損失を最小限に抑えることができます。
- メディア業界のコンテンツ推薦 ：メディアでは、視聴者の視聴履歴や嗜好をリアルタイムで意味検索し、パーソナライズされたコンテンツ推薦を行います。これにより、視聴者のエンゲージメントを向上させ、解約率を低減できます。
- 法律業界のリアルタイム法的文書検索：法律事務所では、膨大な契約書、判例、法令データベースからリアルタイムで意味検索を行い、弁護士の業務効率化を支援します。例えば、「AI 関連契約の著作権条項」といったクエリで、関連する契約書の条項や判例を数秒で抽出することが可能です。また、顧客からの法的相談に対して、過去の類似事例や関連法令を瞬時に検索し、より迅速で正確な回答を提供できます。
On-Demand Compute
- データ分析と探索 ：データレイク上の半構造化・非構造化データを探索するために、オンデマンドのコンピュートモードを使用します。これにより、必要なときにだけリソースを起動し、コストを最適化することができます。
- 画像データの類似検索 ：ロボティクス企業では、100TB に及ぶロボットカメラの画像データから類似の画像を検索するために、オンデマンドのコンピュートモードを使用します。これにより、データの探索や分析を効率的に行うことができます。
- コールドデータの検索 ：通信企業では、過去の顧客データや通話記録から必要な情報を検索するために、オンデマンドのコンピュートモードを使用します。これにより、コールドデータの検索を低コストで行うことができます。
Offline Batch Compute
- データのクレンジングと準備 ：大規模なデータのクレンジング、重複排除、クラスタリングを行うために、オフラインのバッチコンピュートモードを使用します。これにより、AI モデルの学習データを効率的に準備することができます。
- エンベディングの再計算 ：エンベディングモデルを更新した際に、全データの再エンベディングを行うために、オフラインのバッチコンピュートモードを使用します。これにより、モデルの精度を向上させることができます。
- インデックスの再構築 ：インデックスの再構築を行うために、オフラインのバッチコンピュートモードを使用しています。これにより、検索の精度と速度を向上させることができます。
重要なのは、3つのモードが同じ論理データ基盤を参照する点です。オフライン処理による改善を新しいスナップショットとして公開し、そのままオンラインサービングへ反映できます。
ストレージとコンピュートの分離に伴う課題およびその解決方法
ストレージとコンピュートの分離は、弾力的なAI基盤に必要です。一方、コンピュートをゼロまで縮退させると、最初のクエリでオブジェクトストレージ上のコールドデータやインデックスを読む必要があります。
Zillizは、このコールドスタートを軽減するために、量子化などを利用し、検索時にロードするインデックス量を削減する方法を説明しています。詳細はこちらの技術記事へご参照ください。
ただし、これは特定ワークロードを前提とした説明であり、起動時間やデータ量に関する数値を一般的な保証として解釈すべきではありません。
I/O増幅とLoon、Vortex
ベクトル検索が返すのは、多くの場合レコードIDです。しかし、アプリケーションには本文チャンク、タイムスタンプ、権限、メタデータ、文書への参照なども必要です。
一般的な列指向レイアウトでは、少数レコードの取得でも、オブジェクトストレージから大きなブロックを読み込む場合があります。これがポイントリードにおけるI/O増幅につながります。
ZillizはVector Lakebase向けに、Loonというストレージエンジンを開発しています。Loonは、混合レイアウト、行アラインメント、マニフェストベースのバージョン管理を採用しています。また、Linux Foundation傘下のオープンなファイル形式であるVortexを基盤とし、スキャンとポイントリードの両方を効率化する設計です。
こちらの技術記事では、300万行、128次元ベクトル、S3ストレージ、256並列リーダーという条件の内部テストで、VortexがParquetと比べてポイントリード当たりのダウンロード量を削減したと報告されています。この結果は内部ベンチマークであり、実際の効果はデータ構成、アクセスパターン、ストレージ、並列度などに依存します。
ポイントは、ある特定のベンチマークにおいて一方のフォーマットのほうが高速である、ということだけではありません。重要なのは、同じ論理データに対して、サービングとディスカバリーでは求められるアクセスパターンが異なるという点です。
オンラインシステムには高速なポイントリードが必要であり、バッチシステムには効率的なスキャンが求められます。Vector Lakebaseは、ユーザーにデータを二重管理させることなく、その両方をサポートする必要があります。
External Collectionで既存レイクを活用する
企業の非構造化データは、すでにIcebergテーブル、Lanceデータセット、Parquetファイル、オブジェクトストレージのディレクトリなどに保存されていることがあります。
すべてのデータを新しい検索基盤へ移動することは、現実的とは限りません。
Zilliz Vector LakebaseのExternal Collectionは、外部データを既存の場所に残したまま、Zilliz側で検索インデックスを構築・管理するための仕組みです。重複ストレージや二重書き込みパイプラインを避けながら、既存レイク上のデータを検索・分析できるようにすることが目的です。
ベクトルデータベースとの関係
Vector Lakebaseは、ベクトルデータベースの置き換えではありません。
一つのアプリケーションで高速なセマンティック検索を実現することが主な要件なら、ベクトルデータベースだけで十分な場合があります。MilvusやZilliz Cloudのようなベクトル検索基盤は、次の用途で引き続き重要です。
- 低レイテンシーANN検索
- ハイブリッド検索
- メタデータ／スカラーフィルタリング
- 全文検索やJSONフィルタリング
- 類似度メトリクス
- インデックスのライフサイクル管理
- 本番サービングの信頼性
Vector Lakebaseが必要になるのは、同じデータ、Embedding、インデックス、セマンティック情報を、複数のアプリケーション、チーム、モデル、バッチ処理から再利用したい場合です。
この構成では、ベクトルデータベースは広いデータアーキテクチャの中のサービングレイヤーになります。
Lakebaseとの違い
一般的なLakebaseは、オープンなレイクストレージに対して、トランザクション、スキーマ、ブランチ、クローン、SQLアクセスといったデータベース的な機能を提供します。主な対象は構造化されたアプリケーションデータです。
Vector Lakebaseは、同様のレイクネイティブな発想を、非構造化・マルチモーダルAIデータへ適用します。
中心となる抽象概念は、ベクトル、チャンク、インデックス、ラベル、要約、権限、フィードバック、意味的な関係、モデルが生成したコンテキストです。そのため、単なる「Lakebaseにベクトル列を追加したもの」ではありません。
まとめ
ベクトルデータベースは、RAGやセマンティック検索に必要な高速検索を実現しました。しかし、本番AIシステムでは検索に加えて、データの改善、評価、再Embedding、インデックス再構築、ガバナンス、フィードバック分析が必要になります。
Vector Lakebaseは、これらを一つのレイクネイティブなAIデータ基盤上でつなぐアーキテクチャです。
- データを共通化するOne Data
- インデックスを資産として再利用するOne Index
- 意味、権限、履歴を共有するOne Semantic Layer
- サービングとディスカバリーを循環させるCS/CD
- オンライン、オンデマンド、オフラインを使い分けるコンピュートモデル
重要なのは、ベクトルデータベースから別の仕組みへ移行することではありません。ベクトル検索を中核に残しながら、非構造化データのライフサイクル全体を扱えるようにアーキテクチャを拡張することです。
Zilliz Vector Lakebaseはパブリックプレビュー中
Zilliz Vector Lakebaseのパブリックプレビューを開始しました。これは、Zilliz Cloudが、単なるマネージド型ベクトルデータベースから、低レイテンシーのベクトルサービングと、データレイクのオープン性、スケーラビリティ、コスト効率を統合したセマンティックデータプラットフォームへと進化する、大きな一歩です。
Zilliz Vector Lakebaseの主な機能：
- 階層型サービング：リアルタイム性能とコストのさまざまなトレードオフに最適化されたサービング
- オンデマンド検索：常時稼働のコンピュートを必要とせず、大規模ワークロードや探索的ワークロードに対応
- 外部データレイク検索：既存のデータレイク上のデータを直接インデックス化し、検索
- 包括的なAI検索：ベクトル、テキスト、JSON、地理空間データを対象とした、ハイブリッド検索とリランキングによる包括的なAI検索
- Vortexを基盤とした統合レイクネイティブストレージ：LanceやParquetよりも高速かつ低コストなランダムリードを実現する、オープンフォーマットVortexを基盤とした統合レイクネイティブストレージ
現在のデータ基盤でサービングとディスカバリーが別々のシステムに分かれている場合、Vector Lakebaseは検討する価値があります。
Zilliz Cloudでぜひお試しください。新規に業務用メールアドレスで登録すると、100ドル分の無料クレジットが付与されます。また、具体的なユースケースについてもお気軽にご相談ください。