大規模言語モデル（LLM）は、ボットや知識エキスパート、研究アシスタントなど、多くの素晴らしいアイデアを実現してきました。これらの優れたアプリケーションのほとんどは、LLMを特定の知識領域と組み合わせ、ベクトルデータベースが関与しています。たとえば、特定のドメインに関する質問がある場合、最善の方法はDBから可能なドメインを取得し、動的にプロンプトを構築することです。
適切なベクトルデータベースを選択することは、アプリケーションの効率と効果に大きな影響を与えることがあります。現在、さまざまなベクトルデータベース製品が利用可能であり、一般的には専門のベクトルデータベースと統合ベクトルデータベースの2つのカテゴリに分類されます。専門のベクトルデータベース（例：Pinecone）は使いやすさから人気がありますが、スケーリングやさまざまなデータ型のサポートには不十分な場合があります。そのため、統合ベクトルデータベースが必要とされています。
# 統合ベクトルデータベースとは
統合ベクトルデータベースは、ベクトル検索機能と伝統的な構造化データベースを組み合わせたタイプのデータベースです。専門のベクトルデータベースがベクトルインデックスのみを設計しているのに対し、統合ベクトルデータベースはベクトルと構造化データを同じデータベースに格納し、ベクトル検索アルゴリズムを構造化データベースと組み合わせています。この統合により、効率的な通信、柔軟なメタデータフィルタリング、SQLとベクトルの結合クエリの実行、一般的なデータベースに関連する成熟したツールと統合を活用するなど、いくつかの利点があります。
MyScale (opens new window)は、AIアプリケーションとソリューションに最適化されたクラウドベースのデータベースであり、オープンソースのOLAPデータベースであるClickHouseをベースにしています。MyScaleは、統合ベクトルデータベースでベクトル検索のパフォーマンスを向上させることに成功しています。他の統合ベクトルデータベースが提供するすべての利点に加えて、独自のベクトルインデックスアルゴリズムMSTGによる優れたパフォーマンスなど、いくつかの追加の特典も提供しています。
この記事では、トップクラスの統合ベクトルデータベースであるMyScaleに焦点を当て、これらの統合ベクトルデータベースがどのようにLLMアプリケーションを向上させるかについて説明します。
# 通信の重要性
通信はアプリケーションのパフォーマンスに非常に重要です。低コストと改善されたスケーラビリティを持つため、DBaaS（データベースサービス）やSaaS（ソフトウェアサービス）が広く採用されています。これらのサービスを使用する場合、通信は重要な要素となります。
専門のベクトルインデックスでは、すべてのデータを保持することができない場合があります。そのため、別の場所にデータを保存する必要があります。このセットアップでは、1つのクエリで4つのデータ転送が発生するため、2つのリクエストを順次実行する必要があります。しかし、統合データベースソリューションでは、1つのリクエストで2つの転送のみが必要です。
送信回数が少ないと、レイテンシが低下し、ユーザーエクスペリエンスに影響を与えます。通信レイテンシに真剣に取り組んでいる場合、またはデータベースに大量のクエリを実行したい場合は、統合ソリューションの1つとしてMyScaleを検討してください。
# 制約なしで何でもフィルタリング
LLMアプリケーションはツールによって補完されます。そして、ベクトルデータベースは最も重要なツールです。大量のベクトルを検索する場合、キーワードで結果を絞り込むことが通常はより良い選択です。これらのベクトルは記事、ウェブページ、またはプロンプトを表すことができます。そのため、メタデータフィルタリング検索の概念が登場します。
フィルタリング検索はLLMアプリケーションでは非常に一般的です。精度を向上させるために、いくつかの不要なデータを削除するために使用することがあります。ほとんどのベクトルインデックスサービスでは、メタデータフィルターを使用して不要なデータを削除するためのフィルターを提供しています。ただし、データのサイズやフィルター関数自体に制約がある場合があります。たとえば、Pineconeの実装では、40 KBのメタデータ制限があり、メタデータフィルターの機能が制約されます。非常に大きな段落内の正規表現パターンに一致させたり、クエリされた場所から地理的に遠いデータをフィルタリングしたりする場合、これは大きな障壁となるでしょう。
MyScaleなどのデータベースソリューションは、ほぼ任意のサイズとタイプのデータに対してメタデータフィルタリングを実行することができます。ジオロケーション（H3やS2など）、正規表現マッチング、数式の閾値設定など、メタデータフィルターとして任意のものを使用することができます。
地理的な距離を計算する必要がある場合、次のように使用できます：
WHERE h3Distance(<h3インデックスのデータ列>, <h3インデックス>) > 10
キーワードに一致する一連の記事を検索する場合、文字列のパターンマッチを使用してベクトル検索を制約することができます：
WHERE column_1 LIKE '%value%'
正規表現を使用して検索範囲を絞り込むこともできます。
WHERE match(column_1, '(?i)(value\s)')
数式を使用してフィルタリングすることもできます。例えば、few shot learnerの予測を計算し、しきい値を使用して結果をフィルタリングする場合：
WHERE 1/(1+exp(column_1)) > 0.9
また、SQLのサブクエリを使用してメタデータフィルタリングを実行することもできます：
WHERE column_1 IN (SELECT ... FROM another_table WHERE ...)
さらに、メタデータフィルタリングを実行できるデータは、実際には列として格納されています。サイズやデータ型に対する追加の制約はありません。他のテーブルから外部の列をJOINすることもできるため、パフォーマンスの良い複雑なクエリパイプラインを設計することができます。
# 複数のベクトルインデックスを1つのインスタンスで
一部のLLMアプリケーションでは、複数のベクトル列が必要な場合があります。例えば、段落を検索する前に記事を検索したり、関連情報を取得する前にプロンプトを決定したりする場合、アプリケーションに複数のベクトルインデックスが必要になる場合があります。
ほとんどの専門のベクトルデータベースは、1つのインスタンスあたり1つのベクトルインデックスしかサポートしていません。つまり、ベクトル列ごとに新しいインスタンスが必要になります。アプリケーションに複数のベクトルデータベースインスタンスが必要な場合、一貫性のないレイテンシと計算によるパフォーマンスへの影響や、長期的なメンテナンスの問題が発生する可能性があります。
しかし、統合ベクトルデータベース、特にMyScaleは、ベクトルインデックスをデータインデックスの一種として扱います。テーブルごとにベクトルインデックスを作成することができます。複数のアプリケーションがベクトルデータベースを必要とする場合、それぞれのアプリケーションに対してテーブルとベクトルインデックスを作成し、1つのインスタンスに統合することができます。これにより、複数のベクトルインデックスを使用するLLMアプリケーションに対して1つのインスタンスのみが必要になります。
# 結論
SQLインターフェイスによる急な学習曲線にもかかわらず、統合されたベクトルデータベースには否定できない利点があります。柔軟なメタデータフィルタリング、複数のインデックスサポート、および改善された通信効率を提供することで、LLMアプリを新たな高みへと導くことができます。MyScaleでは、統合されたベクトルデータベースが未来であると確信しています。MyScaleは、高性能な統合ベクトルデータベースソリューションであり、進化したベクトルインデックスアルゴリズムに支えられ、高いデータ密度とコスト効率 (opens new window)の両方を提供します。