エージェントには検索が必要であり、検索にはlakebaseが必要です
によって Pranav Aurora, Zhou Sun 、 Jinjing Zhou による投稿
トランザクションデータベース内に統合されたベクター検索を提供するプラットフォームとして、Databricks Lakebaseが挙げられます。本日、Lakebaseに組み込まれたハイブリッドベクターおよび全文検索機能である「Lakebase Search」を発表しました。現在、AWSおよびAzureでベータ版としてご利用いただけます。2つのネイティブPostgres拡張機能であるlakebase_vectorとlakebase_textを搭載しており、エージェントのループ全体で単一のデータバックエンド（lakebase）を利用できるようになります。
これにより、次元の異なるスケール、優れた経済性、そしてエージェントファーストの使いやすさが実現します。
エージェントは検索をオペレーショナルなワークフローへと変換します。コンテキストの取得、推論、実行、そして記憶を行います。これにより、読み取りパス（検索）と書き込みパス（記憶）が深く結びつき、生成されたばかりのインサイトにリアルタイムでアクセスするための即時検索が不可欠になります。
これまで、そのループには、大規模な検索が求めるスケールと経済性のために構築されたPostgresネイティブな環境が存在しませんでした。
現在、エージェントは人間のユーザーよりも4倍多くのデータベースをLakebase上で運用しており、その主な要件は人間のものとはまったく異なります。従来の検索エンジンは、古いデータの読み取り専用スナップショットを想定しています。しかし、エージェントは検索をライブなオペレーショナルデータベースのように扱います。
一般的なエージェントのスキーマを見てみましょう。チャンク化されたドキュメントと埋め込み（embeddings）が、アクティブな会話履歴ログのすぐ隣に配置されています。これにより、継続的な読み書きのループが生まれます。エージェントはあるターンで新しい学習内容をメモリに書き込み、次のターンでそのデータを完全にインデックス化して検索可能にする必要があります。彼らに必要なのは高速な検索だけではありません。完全に最新の書き込みに対する即時検索が必要なのです。
検索は、2つの決定的な特徴を持つユニークなワークロードです。
第一に、実際にクエリを実行するよりもはるかに多くのデータを保存するため、その大部分がコールドデータ（アクセス頻度の低いデータ）になります。
第二に、ベクトル検索は深刻なデータの肥大化を引き起こします。1 KBのテキストファイルは、ベクトル化されると拡張されます。これは、インデックスのオーバーヘッドを考慮する前であっても、ド キュメントが複数のチャンクに分割され、各チャンクが個別の高次元埋め込みを生成するためです。
ほとんど稼働していない何千ものテナント全体でこれが掛け合わされると、従来の検索アーキテクチャは破綻します。HNSWのような業界標準のベクトルインデックスは、根本的にメモリバウンド（メモリ制限）です。高速なグラフ探索はインデックスがRAM上に常駐することに大きく依存しているため、コールドなマルチテナントデータをホストするとコストが高くなります。
昨年、私たちはLakebaseを紹介しました。これは、データは安価なクラウドオブジェクトストレージに保存されるものの、階層型キャッシュ（RAM、ローカルNVMe、ページサーバー）によってホットページをローカルディスク並みのレイテンシで読み取ることができる、サーバーレスのPostgres OLTPアーキテクチャです。
私たちは、これこそが現代の検索が必要としているアーキテクチャそのものであると気づきました。しかし、落とし穴がありました。クエリ速度を損なわずにこの経済性を実際に引き出すには、階層型ストレージ構造に常駐するように明示的に設計されたインデックスレイアウトが必要だったのです。Lakebaseにはそれがありませんでした。そこで、私たちはそれを構築しました。
階層型アーキテクチャと専用に構築された階層型インデックスを組み合わせることで、以下を実現します。
この経済性は、表で見ると最も分かりやすいです。クラウドの定価に基づく、1テラバイト（TB）あたりの月額料金は以下の通りです。
データの保存場所 | コスト |
RAM | 約3,000ドル / TB / 月 |
ローカルNVMe（キャッシュ） | 約100ドル / TB / 月 |
オブジェクトストレージ | 約20ドル / TB / 月 |
当社のインデックス作成手法により、LakebaseはアクティブなワーキングセットのみをRAMに保持できます。大部分を占めるコールドデータはオブジェクトストレージに置かれるため、システムコストは2桁（100分の1）も安くなり、同時にアプリケーションが実際に必要とする高性能な検索を提供できます。
Lakebase Searchを構築する際、私たちは譲れない2つの特性に焦点を当てました。
Lakebase Searchを構築するにあたり、2つの厳格な要件がありました。1つは100% Postgresネイティブであること（標準のpgvector/tsvector型やエコシステムツールを再利用すること）、もう1つはインデックス作成が階層型クラウドオブジェクトストレージ向けにゼロから構築されていることでした。
これを実現するため、本日、2つの新しいPostgres拡張機能のベータ版をリリースします。どちらも、RAMを過剰にプロビジョニングすることなく、最先端の検索関連性を提供という同じ目標を共有しています。
標準のpgvectorデータ型と演算子はそのまま維持し、基礎となるインデックスタイプを変更しました。データはネイティブのpgvectorフォーマットのままであるため、互換性が維持され、他のシステムへのエクスポートも可能です。RaBitQ（Randomized Binary Quantization）を使用してベクトルをクラスタリングおよび圧縮することで、高い再現率を維持しながらインデックスのフットプリントを32分の1に縮小します。これまで300GB of RAMを必要としていた1億ベクトルのインデックスが、10GB未満に収まります。このメモリフットプリントの削減により、単一のインデックスを10億以上のベクトルにスケールさせることができます。アクティブなワーキングセットはローカルNVMeにキャッシュされ、コールドデータはオブジェクトスト レージに配置されます。
PostgresはGINインデックスを介して正確なキーワードマッチングを処理しますが、パフォーマンスを維持するためにはGINインデックスがRAM上に常駐している必要があります。このアーキテクチャでは、データセットのサイズに比例してメモリコストが線形に増加します。
lakebase_textは、GINをクラウドオブジェクトストレージからのシーケンシャルリードに最適化されたインデックスに置き換えます。これにより、RAMフットプリントを増やすことなく、ネイティブのBM25関連性ランキングをPostgresに導入します。
両方の拡張機能が同じエンジン内で実行されるため、ハイブリッド検索は単一のSQLクエリで実行できます。ベクトルの類似度とキーワードの関連性は、相互ランク融合（RRF）を介して結合され、結果をオペレーショナルテーブルと結合してフィルタリングすることができます。
単一インスタンス上で、LAION-100M（1億個の768次元ベクトル、上位10件の検索）を用いてLakebase Searchのベンチマークを実施しました。 ウォームキャッシュと単一接続でのクエリパフォーマンスは、肥大化ゼロで正確な最近傍探索の再現率を達成します。
Recall@10 | P99レイテンシ | QPS |
|---|---|---|
0.955 | 30 ms | 51 |
0.942 | 18 ms | 104 |
0.926 | 14 ms | 142 |
従来、この規模を達成するにはメモリバウンドなアーキテクチャが必要でした。標準のpgvector HNSWインデックスでは、パフォーマンスの高い探索を行うために、近傍グラフとそのターゲットヒープページがRAM上に常駐している必要があります。1億ベクトルの場合は下記の通りになります。
このアーキテクチャは、総所有コスト（TCO）へのアプローチを変革します。従来 の検索では、クエリの量に関係なく固定の基本コストが必要でしたが、Lakebaseは実際の使用状況を追跡します。
ワークロードタイプ | 従来のアーキテクチャ（メモリバウンド） | Lakebase Searchのアーキテクチャ |
大規模なナレッジベース（ほぼ使われていない状態） | 使われていない状態のデータセットをRAM上に保持するための固定のベースラインコスト。 | コンピュートをゼロにスケール。オブジェクトストレージの料金のみを支払う。 |
エージェントのメモリとチャット（バースト性） | トラフィックスパイクに対処するための、過剰にプロビジョニングされたRAMとコンピュート。 | スパイクに合わせてコンピュートを動的にスケールし、その後ゼロにスケールダウン。 |
検索バー（持続的） | データセット全体をRAMに収めるための大規模なインスタンス。 | データセットがRAMへの常駐を回避するため、より小さく安価なインスタンス。 |
メモリとコンテキストのための単一のバックエンド：
エージェントがコンテキスト用のベクトルデータベースとメモリ用のトランザクションデータベース を繋ぎ合わせる必要はありません。検索ロジックをデータベースに直接組み込むことで、エージェントループ全体が1つのバックエンドで実行されます。Lakebase SearchはPostgresであり、標準的なpgvectorおよびtsvectorタイプを完全に再利用するため、既存のMCP、標準ドライバー、コネクターにネイティブに接続できます。さらに重要なのは、検索が運用データのすぐ隣で行われるため、ハイブリッド検索の実行、アプリケーションのテーブルとの結合、テナントによる安全なフィルタリングをすべて単一のSQLクエリで実行できる点です。
継続的な検索の実験
チャンキング戦略やハイブリッドの重みの最適化には、試行錯誤が必要です。再処理のために外部のバッチシステムにデータをエクスポートする代わりに、Lakebase Searchはレイクハウスと連携して緊密なフィードバックループを構築します。数テラバイトのデータセットをコストゼロで即座にブランチし、並列コンピュートを使用して帯域外でインデックスを構築、オフライン評価のためにエージェントのフィードバックをレイクハウスにルーティングできます。
エージェントごとの専用検索エンジン
従来のアーキテクチャでは、すべてのエージェントで単一の検索クラスターを共有する必要がありました。Lakebaseの使われていないインデックスはストレージコストがほぼゼロであるため、特定のエージェント、ユーザー、またはセッション専用に分離された数千のコーパスをプロビジョニングできます。これにより、検索は古いスナップショットから運用上の読み書きループへと移行します。エージェントがあるターンで書き込んだデータは次のターンでコミットされ、完全なトランザクション保証を伴って検索可能になります。
Lakebaseは、個別のベクトルストア、検索クラスター、トランザクションデータベースを連携させる必要性を排除します。ライフサイクル全体を単一のPostgresシステム内に統合することで、階層化されたクラウドオブジェクトストレージのスケールと低コストを実現すると同時に、エージェントワークフローに必要なリアルタイムの読み書きエルゴノミクスを提供します。
Lakebase Searchは、本日よりAWSおよびAzureでベータ版としてご利用いただけます。あなたのエージェントは、何を構築するでしょう？
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。