Databricksは本日、Lakebase Searchを発表しました。これはLakebaseに組み込まれたハイブリッドベクトル・全文検索システムであり、AWSとAzureでベータ版として利用可能です。2つのネイティブPostgres拡張機能（lakebase_vectorおよびlakebase_text）を搭載し、エージェントループ全体が単一のデータバックエンド（Lakebase）に依存できるようにします。
エージェントは検索を運用ワークフローに変換します。コンテキストを取得し、推論し、行動し、記憶します。これにより、読み取りパス（検索）と書き込みパス（記憶）が深く結びつき、リアルタイムで新たに生成された洞察にアクセスするために即時検索が不可欠になります。これまでのPostgresには、検索の大規模化に求められるスケールと経済性を備えたネイティブのソリューションはありませんでした。
エージェントにとって、検索は実際には運用ワークロードです。エージェントは現在、人間のユーザーよりも4倍多くのデータベースをLakebase上で運用しており、その主な要件は人間とはまったく異なります。従来の検索エンジンは、古くなったデータの読み取り専用スナップショットを前提としていますが、エージェントは検索をライブな運用データベースとして扱います。典型的なエージェントスキーマでは、チャンク化されたドキュメントと埋め込みがアクティブな会話メモリログと直接共存し、継続的な読み取り/書き込みループを形成します。エージェントはあるターンで新しい学習をメモリに書き込み、次のターンでそのデータが完全にインデックス化され検索可能である必要があります。高速な検索だけでなく、最新の書き込みに対する即時検索が必要です。
検索は独特なワークロードであり、2つの特徴があります。第一に、実際にクエリするデータよりもはるかに多くのデータを保存し、大部分がコールド状態になります。第二に、ベクトル検索は深刻なデータ膨張を引き起こします。1KBのテキストファイルはベクトル化されると拡大します。これは、ドキュメントが複数のチャンクに分割され、各チャンクが個別の高次元埋め込みを生成するためです（インデックスオーバーヘッドを考慮する前でも）。これが数千のほとんどアイドル状態のテナントに掛け合わされると、従来の検索アーキテクチャは破綻します。業界標準のベクトルインデックス（HNSWなど）は本質的にメモリバウンドであり、高速なグラフトラバーサルはインデックスがRAMに常駐することに大きく依存するため、コールドなマルチテナントデータをホスティングするコストは高くなります。
昨年、DatabricksはLakebaseを導入しました。これは、データを安価なクラウドオブジェクトストレージに保存するサーバーレスPostgres OLTPアーキテクチャですが、階層型キャッシュ（RAM、ローカルNVMe、ページサーバー）により、ホットページはローカルディスクレイテンシで読み取られます。チームは、これがまさに最新の検索に必要なアーキテクチャであることに気付きました。しかし、クエリ速度を犠牲にせずに経済性を実現するには、階層型ストレージ階層に合わせて特別に設計されたインデックスレイアウトが必要でした。そこで、Lakebase Searchを構築しました。
階層型アーキテクチャと専用の階層型インデックスを組み合わせることで、速度ペナルティなしで次世代のスケールを達成します。オブジェクトストレージから必要なページのみをインテリジェントにローカルキャッシュにフェッチすることで、より小さなPostgresインスタンスでも巨大なコンピュートリソースを必要とせずに同じリコールとレイテンシを実現します。経済性については、ベクトルのコールドテールはほぼ無料のオブジェクトストレージに置かれ、ホットワーキングセットはNVMe上にあります。クエリした分だけ支払い、保存した分には支払いません。
lakebase_vectorは、RaBitQ（ランダム化二値量子化）を使用してベクトルをクラスタリングおよび圧縮し、インデックスフットプリントを32倍縮小しながら高いリコールを維持します。以前は300GBのRAMを必要としていた1億ベクトルのインデックスが、10GB未満に収まります。このメモリフットプリントの削減により、単一のインデックスで10億ベクトル以上にスケールできます。アクティブなワーキングセットはローカルNVMeにキャッシュされ、コールドテールはオブジェクトストレージに常駐します。
lakebase_textは、GINインデックスを、クラウドオブジェクトストレージからのシーケンシャル読み取りに最適化されたインデックスに置き換えます。PostgresにネイティブBM25関連性ランキングを導入し、RAMフットプリントを削減します。両方の拡張機能が同じエンジン内で実行されるため、ハイブリッド検索は単一のSQLクエリで実行でき、ベクトル類似度とキーワード関連性が逆数融合ランキング（RRF）で結合されます。
ベンチマーク結果は、LAION-100M（1億の768次元ベクトル）において、単一インスタンス、シングルコネクション、ウォームキャッシュで、Recall@10が0.955（P99レイテンシ30ms、QPS 51）、0.942（18ms、104 QPS）、0.926（14ms、142 QPS）を示しています。従来のpgvector HNSWインデックスでは512GB RAMのインスタンスが必要で、インデックス構築に約40時間かかるのに対し、lakebase_vectorは192GBのインスタンスで1.5時間で構築でき、コールドキャッシュ最初のクエリは1.13秒です。
Lakebase Searchは、エージェントに単一のバックエンドを提供し、メモリとコンテキストのための個別のデータベース統合を不要にします。継続的な検索実験や、エージェント専用の検索エンジンもサポートします。Lakebase Searchベータ版は本日、AWSとAzureで利用可能です。