AIデータベース：ベクターデータベースは使うべきか？
本シリーズの第1回では、機械学習やLLMにおけるベクターの役割と、ソフトウェアにおけるベクター表現について説明しました。本記事では、データベースの観点から、AIが直面する現代的な課題にどのように対応しているのかを概観します。
ベクターデータベース
AIは本質的にベクターで構成されており、ベクターがAIそのものとも言えます。では、前回説明したようなベクター演算を中心に設計されたデータベースを使えばよいのではないでしょうか。過去10年ほどで、そのようなデータベースが数多く登場しています。代表的なオープンソースソフトウェアとしては、Milvus, Qdrant, Weaviate, Vespa, ChromaDB, LanceDB.などがあります。
これらのデータベースの違いは何でしょうか。いくつかの記事で比較されていますが、プロトタイプなどの小規模用途に最適化されたものもあれば、本番環境向けに設計されたものもあります。また、本シリーズ前回で述べたように、主要なAIサービスとの連携が重要であることから、各データベースは外部サービスとの統合機能でも競争しています。さらに、さまざまなインデックス方式やレプリケーションなどのデータ管理機能も提供されています。多くの企業がこれらのデータベースをクラウドサービスとして提供しています。
一方で、PostgreSQL内でベクター操作を扱うツールを提供するTigerData（旧Timescale）は、AI用途にベクターデータベースは適していないと主張しています。その主張の要点は、ベクターは通常、元となるコンテンツ（テキスト、音声、動画、化学・生物配列など）と一緒に参照されるという点です。したがって、多様なデータを一元的に管理するほうが合理的であるとしています。また、ベクターはデータベース用語でいう「派生データ」であり、元データの変更に応じて更新される必要があるため、元データから切り離されると価値が大きく低下すると指摘しています。
筆者はこの主張の妥当性について判断はしませんが、別の記事では従来型データベースとベクターデータベースのトレードオフがよりバランスよく論じられています。多くの組織では、外部のAIサービスを利用してベクターを生成し、その後は元データを保持しない、あるいは参照しないケースもあります。Weaviateのように、元データとベクターの両方を保存できるベクターデータベースも存在します。また、ベクターデータベースが特定の役割を非常に高い性能で果たすのであれば、他システムとの統合コストを考慮しても採用する価値はあるでしょう。
Tursoの創業者であるGlauber Costaは、元データに対するテキスト検索の方がベクター検索よりも優れた結果を出す場合があると指摘する専門家の意見も紹介しています。
最終的には、各組織が自らのニーズに応じて最適なデータベースを選択する必要があります。近年では、汎用データベースもAI対応を進めており、次にそれらを見ていきます。
ベクター操作のためのSQL
SQLにおけるVECTORデータ型の登場により、リレーショナルデータベースもAI対応を進めています。MySQLおよびそのフォークであるMariaDBでは、ベクター間の距離を計算する基本機能が提供されています。AIコンサルティング企業Peripety LabsのCEOであるMark Hinkleによれば、現時点ではMariaDBの方がMySQLよりもベクター対応が進んでいるものの、どちらもまだ初期段階にあるとのことです。
MySQLやMariaDBがシンプルさを重視して設計されているのに対し、PostgreSQLは非常に多機能で、幅広い用途に対応できることを目指しています。SQLデータベースで実現したい機能があれば、PostgreSQLにはそれを実現する機能や拡張がほぼ存在すると言えるでしょう。
TigerDataが提供するpgaiおよびpgvectorという拡張機能は、PostgreSQLをAIの世界と接続します。pgaiは元データの変更に応じてベクターを自動更新し、pgvectorはベクター類似検索を提供します。
また、PostgreSQLはGPUによる高速化にも対応しています。TigerDataの資料では、ベクターデータベースよりも高速にベクター処理が可能であるとするベンチマーク結果も示されています。
さらに、TursoはSQLiteをベースに、ベクター列を持ち、データ更新時に自動でベクターを更新する新たなオープンソースデータベースを開発しています。
そのほか、YugabyteやClickHouseなども、SQLインターフェースとAI向け機能を兼ね備えたオープンソースデータベースとして注目されています。
ベクターデータベースを選ぶか、汎用データベースを選ぶかは、埋め込み（embedding）以外のデータ検索が必要かどうかによって判断されることが多いです。「ハイブリッド検索」と呼ばれる手法では、ベクター検索と従来の検索を組み合わせてデータを取得します。Open Tech StrategiesのKarl Fogelは、特定の高性能要件がない限り、ベクター機能を備えた汎用データベースを使うことを推奨しています。
その他の動向
AI分野に乗り遅れまいと、多くのデータベースが対応を進めています。よく言われる「乗り遅れるな」という表現の通り、あらゆる技術がこの分野に参入しています。
MongoDBは「Atlas Vector Search」を提供し、主要AIサービスと連携したデータ検索機能をアピールしています。ドキュメントには、データベースへのデータ格納例も掲載されています。NoSQL時代を代表するデータベースであるCassandraも、生成AIへの適用を打ち出しています。
テキスト検索分野で長い歴史を持つElasticsearchも、ベクターのインデックス作成・保存・検索を行う拡張機能を提供しています。
さらに、グラフデータベースもAI分野に進出しており、「Neo4j for GenAI」といった取り組みがその一例です。
AIエコシステム
「エコシステム」という言葉はやや使われすぎている感もありますが、さまざまなツールが連携して動作するAIの世界を表現するには適切な言葉です。特にオープンソースの分野では、多様なツールがそれぞれの役割を担い、アプリケーション全体を構成しています。
AIの本質は、非構造化データから有用な構造を生み出すことです。本記事が、構造化データがどのように現代のAIを支えているのかを理解する一助となれば幸いです。
