Google CloudはAlloyDBのScaNN索引を更新し、公式のスケール上限として100億件超のベクトルを扱えるとした。このスケールでのベンチマーク値は、P95レイテンシ51ミリ秒以内、再現率95%。AlloyDBはGoogle Cloudのマネージドデータベースサービスで、PostgreSQL互換のインターフェースを備える。
今回の変更は索引構造そのものに手を入れたものだ。従来のScaNNは2階層または3階層のツリーでベクトルを整理していたが、今回は4階層に増やした。
ツリーを1層増やし、検索対象を2桁減らす
近似最近傍探索は、ベクトルを類似度でクラスタ化して階層状のグループにまとめ、クエリ時には最上位層から下へたどりながら、各階層で最も近い分岐だけを展開していく方式だ。階層数が探索の計算量を左右する。2階層ツリーはおおよそO(N^1/2)、3階層ではO(N^1/3)に下がり、4階層ではさらにO(N^1/4)まで圧縮される。
100億件規模では、この指数の差が大きく効いてくる。概算では、Nを100億とすると平方根はおよそ10万、立方根はおよそ2150、4乗根はおよそ316。1回のクエリで触れる候補数は、10万件規模から300件程度まで落ちる。51ミリ秒という数字はここから来ている。
Googleが挙げる具体的な手法には、Top-K分岐戦略、SOARアルゴリズム、重心の調整、バランス木の構築があり、さらにメモリ制約を回避する動的サンプリングも用いている。旧構造の課題として同社が名指ししたのは2点で、ツリーが大きくなるほど索引構築とクエリ走査の計算量が増えること、そして100億件規模でのサンプリングは利用可能メモリを使い切りやすいことだ。
データ量を押し上げたのはエージェントだ
Google自身の説明によれば、エンタープライズ向けエージェントアプリケーションの需要がユースケースを数十億件のベクトル規模へと押し上げており、基盤となるベクトルデータベースがしばしば追いつけなくなっているという。
この一文が、今回の拡張の出どころを示している。従来の検索拡張生成では、企業が社内文書をすべてチャンクに分割しても、規模は数千万から数億件程度に収まることが多い。エージェントは違う。実行の一歩ごとに履歴を振り返り、ツールの説明を確認し、ユーザーの好みを参照する必要があり、1つのタスクで十数回の検索が発生することもある。データの出所も文書からセッション記録、操作ログ、中間生成物へと広がり、これらは日々増分で積み上がっていく。
もう一段計算してみる。P95の51ミリ秒で見積もると、1回のエージェントタスクが15回の検索を行うとすれば、ベクトルデータベースだけでおよそ0.77秒を費やす計算になる。これはデータベース部分だけの話で、モデル推論、ツール呼び出し、ネットワーク往復は別勘定だ。検索レイテンシは単発のやり取りでは目立たないが、マルチホップの連鎖に組み込まれると体感の一部になる。
汎用データベースが専用製品を飲み込みつつある
100億件規模のベクトル検索をPostgreSQL互換のマネージドサービスに組み込むという判断は、同じ方向を指している。ベクトルはもはや独立した専用インフラを必要としない、という方向だ。
企業顧客にとって、この計算は分かりやすい。業務データはもともとリレーショナルデータベースに存在し、ユーザーテーブル、注文テーブル、権限ルールもそこにある。ベクトルだけを別の専用データベースに置くと、バックアップも権限管理も一貫性保証も二重になり、データベースをまたぐトランザクション境界まで自前で処理しなければならない。既存のデータベースに索引を追加するだけで済むなら、運用の複雑さは単純に半分近くまで下がる。
この2年ほどで、専用ベクトルデータベースの立ち位置も変わってきた。極限の性能や検索アルゴリズムの進化速度では依然として優位性を保っているが、汎用データベース側は「十分に使える」水準を、数百万件から数億件、そして今や数百億件へと引き上げ続けている。専用製品に残された余地は、レイテンシとスループットの要求が最も厳しい、ごく一部の領域まで狭められている。
今回AlloyDBは、パーティション数、ベクトルの次元数、索引構築にかかる時間、QPSの上限は公表していない。これらの数値は実際の選定においてピーク時のスケールよりも参考になることが多く、とりわけ索引構築にかかる時間は重要だ。100億件規模での索引再構築コストは、法外に高くなる可能性がある。
参考資料：Google Cloud公式ブログ、AlloyDB ScaNN索引ドキュメント、CocoLoop。ベクトル規模、P95レイテンシ、再現率の数値は公式発表に基づき、計算量の換算値は編集部による概算です。