Amazon Web Services ブログ

生成系 AI アプリケーションでベクトルデータストアが果たす役割とは

この記事は、The role of vector datastores in generative AI applications を翻訳したものです。

生成系 AI は今、質問に答えたり、ストーリーを書いたり、アート作品を制作するだけでなく、コードも生成することができるその力で、人々の想像力をかき立て、業界に変革を起こしています。AWS のお客様からも、生成系 AI をビジネスで最も効果的に活用するにはどうすれば良いのかというご質問が多く寄せられるようになっています。ほとんどのお客様は、特定分野のデータ (財務記録、健康記録、ゲノムデータ、サプライチェーン、その他) を豊富に蓄積しており、それらのデータから自社のビジネスや業界全体について、貴重な独自の視点を得ています。このような独自データは、お客様の生成系 AI 戦略において、強みや差別化要因となり得るものです。

同時に、多くのお客様が生成系 AI アプリケーションで使用されるベクトルデータストア、つまりベクトルデータベースへの人気が高まってきていることに気づいており、生成系AIアプリケーションをめぐる総合的なデータ戦略において、これらのソリューションをどう適合させればいいのかと考えを巡らせています。本投稿では、生成系 AI アプリケーションにおけるベクトルデータベースの役割と、生成系 AI の能力を活かすうえで AWS のソリューションをどのように活用できるのかについて説明していきます。

生成系 AI アプリケーション

すべての生成系 AI アプリケーションの中心には大規模言語モデル (LLM) があります。LLM は、インターネットでアクセス可能なあらゆるコンテンツなど、大量のコンテンツによりトレーニングされた機械学習 (ML) モデルです。公開されている膨大な量のデータによりトレーニングされた LLM は、基盤モデル (FM) と見なされ、さまざまなユースケースに合わせて調整可能です。Amazon SageMaker JumpStart は、テキストプロンプトを使って写真のようにリアルな画像を生成できる Stability AI の Text2Imageモデルや、Hugging Face の Text2Text Flan T-5 テキスト生成用モデルなど、事前にトレーニングされたオープンソースのさまざまな専用基盤モデルを提供し、これらをもとにアプリケーションを構築できるようになっています。Amazon Bedrock は、基盤モデル を使って生成系 AI アプリケーションを構築・拡張するための最も簡単な方法であり、AI21 Labs、Anthropic、Stability AI、Amazon Titan のモデルに API 経由でアクセスすることが可能です。

基盤モデルに頼るだけの生成系 AI アプリケーションは、現実世界の幅広い知識にアクセスできるものの、特定分野の話題や専門的な話題について正確な結果を生成するようにカスタマイズする必要があります。また、専門的な対話であればあるほど、ハルシネーション (正確ではないが、もっともらしい結果) の発生頻度が高くなります。では、分野の特異性に合わせて生成系 AI アプリケーションをカスタマイズするにはどうすればいいのでしょうか。

ベクトルデータストアを使用して分野の特異性を追加

プロンプトエンジニアリング (in-context learning、コンテキスト(文脈)内学習とも呼ばれます) は、生成系 AI アプリケーションをお客様の業種やユースケースなどの特定分野の文脈に合わせて調整し、精度を向上させる最も簡単な方法かもしれません。ハルシネーションを完全になくすことはできないものの、この手法を使えば、生成系 AI が出力する結果の意味の範囲を自分の分野に絞り込むことが可能です。

基本的に、基盤モデルは一連の入力トークンをもとに次のトークンを推測します。この場合の「トークン」とは、テキスト生成における単語やフレーズなど、意味論的意味を持つ任意の要素を指します。文脈上関連性のある入力を多く提供すればするほど、推測される次のトークンも文脈上の関連性を持ったものになる可能性が高くなります。基盤モデルへの問い合わせに使用するプロンプトには、入力トークンに加え、文脈上関連性の高いデータが可能な限り多く含まれています。

コンテキストデータは通常、特定分野のデータを保存するシステムである社内のデータベースもしくはデータレイクから取得されます。これらのデータストアから特定分野のデータを追加するだけでもプロンプトを補強することができますが、ベクトルデータストアは意味的関連性のある入力を使用してプロンプトを設計するのに役立ちます。この手法は 検索拡張生成 (RAG, Retrieval Augmented Generation) と呼ばれます。実際には、文脈的にパーソナライズされたデータ (ユーザープロフィール情報など) と意味的に類似したデータの両方を用いて、プロンプトを設計することになると考えられます。

生成系 AI を使用するには、特定分野のデータを一連の要素としてエンコードし、それぞれが内部で 1 つの「ベクトル」として表現されるようにする必要があります。このベクトルには、いくつかの次元にまたがる一連の数値 (数列) が含まれます。以下の図は、コンテキストデータをセマンティック要素に変換してから、ベクトルに変換する流れを例示したものです。

これらの数値は、多次元ベクトル空間で要素を相互に関連づけてマッピングするのに使用されます。ベクトル要素がセマンティックである ( 1 つの意味を表す) 場合、近接性が文脈関係の指標となります。このように使用される場合、これらのベクトルは「エンベディング (埋め込み) 」と呼ばれます。たとえば、食料品や料理の分野の文脈を表す多次元空間では、「チーズ」のセマンティック要素が「乳製品」のセマンティック要素の近くに置かれることになります。特定分野の文脈によって、セマンティック要素は単語、フレーズ、センテンス、パラグラフ、文書全体、画像、あるいはまったく別のものになる可能性があります。特定分野のデータセットを、互いに関連性のある意味要素に分解します。たとえば、以下の図は、料理の文脈のベクトル空間をわかりやすく示したものです。

結果的に、プロンプトに関連する文脈を生成するには、データベースに問い合わせを行い、ベクトル空間の入力と密接に関連する要素を見つける必要があります。ベクトルデータストアは、ベクトルを大規模に保存し、問い合わせを行うためのシステムであり、効率的な最近傍クエリアルゴリズムと適切なインデックスにより、データ検索を改善します。このようなベクトル関連の機能を備えたデータベース管理システムであれば、どれでもベクトルデータストアとして使うことができます。一般的に使用されるデータベースシステムの多くは、このようなベクトル機能と共に、他の機能を提供します。ベクトル機能を備えたデータベースに特定分野のデータセットを保存することの利点の 1 つに、ベクトルがソースデータの近くに配置されることがあります。外部データベースに問い合わせをしなくても、追加のメタデータによりベクトルデータを補強でき、データ処理パイプラインの簡略化が可能です。

ベクトルデータストアを今すぐ使い始められるように、AWS は米国時間の 2023 年 7 月 26 日、Amazon OpenSearch Serverless用のベクターエンジンを発表しました。一般提供が開始されれば、同エンジンは、数十億個の埋め込みを保存し、問い合わせるためのシンプルな API を提供します。しかし、運用とデータ統合が簡素化されることから、いずれはすべての AWS データベースにベクトル機能が搭載されることになると考えられます。また、より高度なベクトルデータストアのニーズに対応するために、以下の選択肢を提供しています。

埋め込みはソースデータの近くに保存される必要があります。したがって、現在データをどこに保存しているのか、これらのデータベース技術の習熟度、ベクトル次元を単位とした規模、埋め込みの数、および性能要件によって、どの選択肢が適切なのかが決まります。これらの選択肢について具体的なガイダンスについて見ていく前に、まずは RAG の仕組みと、RAG にベクトルデータストアを適用する方法について理解しておくことにましょう。

RAG でのベクトルデータストアの使用

埋め込み(ベクトル) を使って、生成系 AI アプリケーションの精度を高めることができます。以下の図は、その際のデータフローを表しています。

特定分野のデータセット (上の図の右側、青色で表示) を取得し、セマンティック要素に分割して、基盤モデルを使ってこれらのセマンティック要素のベクトルを計算します。次に、これらのベクトルをベクトルデータストアに保存します。これにより、類似性検索が実行できるようになります。

生成系 AI アプリケーション内 (上の図の左側、オレンジ色で表示) では、エンドユーザーからの質問を受け取り、データセットで使用したのと同じアルゴリズムを使ってセマンティック要素に分割し (トークン化) 、ベクトルデータストアに対し、入力要素のベクトル空間内の最近傍を問い合わせます。文脈的に類似したセマンティック要素が提供されたら、作成したプロンプトにそれを追加します。このプロセスにより、LLM が特定分野の文脈へとさらに絞り込まれることから、LLM の出力が正確で、かつその文脈に関連したものになる可能性が高まります。

エンドユーザーのクリティカルパス内でベクトルデータストアの類似性検索を実行する場合は、同時読み取りクエリを使用します。ベクトルデータストアに埋め込みを追加し、データの変更に対応するためのバッチ処理は、そのほとんどをベクトルデータストアへのデータ書き込みが占めています。このような使用パターンの側面と、前に述べた習熟度や規模といった考慮事項によって、どのサービス (Amazon Aurora PostgreSQL、Amazon OpenSearch Service、Amazon OpenSearch Serverless 用のベクトルエンジン、Amazon RDS for PostgreSQL) が適切であるかが決まります。

ベクトルデータストアの考慮事項

これまで説明してきた使用パターンは、ベクトルデータストアに関する独自の重要な考慮事項にもつながります。

使用する特定分野のデータ量と、それらのデータをセマンティック要素に分割するために用いるプロセスによって、ベクトルデータストアで対応する必要のある埋め込みの数が決まります。時間の経過と共に特定分野のデータが増加し、変化するのに合わせて、ベクトルデータストアもその増加に適応する必要があります。このことは、インデックス作成の効率とパフォーマンスに多大な影響を与えます。特定分野のデータセットによって、数億個、場合によっては数十億個もの埋め込みが生成されるというのは珍しいことではありません。トークナイザ を使ってデータを分割しますが、自然言語ツールキット (NLTK) には、汎用のトークナイザ がいくつか含まれており、そちらを使用することができます。しかし、ほかのものを使うことも可能です。最終的に、どのトークナイザ が適切であるかは、特定分野のデータセット内のセマンティック要素によって決まります。前にも述べたとおり、この要素は単語、フレーズ、文章のパラグラフ、文書全体、または独立した意味を持つデータの区分のいずれかとなります。

埋め込みベクトルの次元数もまた、考慮すべき重要な要素の 1 つです。FM が違えば、生成されるベクトルの次元の数も違ってきます。たとえば、all-MiniLM-L6-v2 モデルでは、384 次元のベクトルが生成されます。また、Falcon-40B のベクトルは 8,192 個の次元を持ちます。ベクトルの持つ次元の数が多ければ多いほど、表すことのできる文脈もある程度までは豊富になります。そのうち、戻り値の数が減り、クエリのレイテンシが上昇し、最終的に「次元の呪い」が生じることになります (オブジェクトがわずかしかなく、類似性が見いだせなくなってしまいます)。セマンティック類似性検索を実行するには、通常、次元密度の高いベクトルが必要です。しかし、これらの検索を効率的に処理するために、データベースの埋め込みの次元の数を減らさなければならない場合もあります。

もう 1 つ、正確な類似検索の結果が必要なのかどうかも、考慮する必要があります。ベクトルデータストアのインデックス作成機能により、類似性検索が大幅に高速化される一方で、結果の生成には近似最近傍 (ANN) アルゴリズムも使用されます。ANN アルゴリズムは、精度と引き換えにパフォーマンスとメモリ効率を高めます。常に正確な最近傍値が返されるとは限りません。

最後に、データガバナンスについて考えてみましょう。特定分野のデータセットには、個人情報や知的財産といった機密性の高いデータが含まれる可能性があります。ベクトルデータストアを既存の特定分野のデータセットの近くに置くことで、アクセス、品質、セキュリティの管理をベクトルデータストアにまで拡張し、運用を簡素化できます。多くの場合、データの意味論的意味に影響を与えることなく、これらの機密データを取り除くことは不可能であり、精度の低下をまねいてしまいます。したがって、埋め込みの作成、保存、問い合わせを行うシステムを通して、データの流れを理解し、制御することが重要です。

pgvector 搭載の Amazon Aurora PostgreSQL や Amazon RDS for PostgreSQL の利用

オープンソースコミュニティが支援する PostgreSQL の拡張機能である pgvector は、Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL の両方で利用できます。この拡張機能は、vectorと呼ばれるデータ型を定義し、類似性検索の 3 つのクエリ演算子 (ユークリッド、内積の負、コサインの距離) と、より高速な近似距離検索を行うためのベクトルのインデックスメカニズムである ivfflat (ベクトルを格納した反転ファイル) を追加します。ベクトルは最大 16,000 次元まで格納できるものの、類似性検索のパフォーマンスを向上するためのインデックスの作成は 2,000 次元に限られます。実際には、ユーザーはより低次元の埋め込みを利用する傾向にあります。この拡張機能については、ブログ記事 Building AI-powered search in PostgreSQL using Amazon SageMaker and pgvector で詳しく説明しています。

すでにリレーショナルデータベースに多大な投資を行っており、特に PostgreSQL に関して豊富な専門的ノウハウを持っているなら、pgvector 拡張機能を備えた Amazon Aurora PostgreSQL の利用を真剣に検討すべきです。さらに、リレーショナルデータベースには高度に構造化されたドメインごとのデータセットがより自然にフィットします。特定のコミュニティ版の PostgreSQL を使用する必要がある場合は、Amazon RDS for PostgreSQL も最適な選択肢になるかもしれません。類似検索クエリ (読み込み) は、サポートされるリードレプリカの最大数に応じてスケールアウトすることもでき、単一の DB クラスタの Amazon Aurora PostgreSQL では 最大15、Amazon RDS for PostgreSQLのリードレプリカ構成でも 最大 15 となっています。

Amazon Aurora PostgreSQL は、オートスケーリングで、ワークロードに応じて DB インスタンスのコンピューティング性能をオンデマンドで自動的に調整できる、 Amazon Aurora Serverless v2 にも対応しています。この設定によって、さまざまなのユースケースにおいて、ピーク時におけるキャパシティのプロビジョニングや複雑なキャパシティプランニングを行う必要がなくなるため、オペレーションを簡素化できます。

Amazon Aurora 機械学習 は、SQL の機能を介して Amazon SageMaker に搭載された ML モデルを呼び出すときに利用できる機能です。この機能を使って FM を呼び出して、自社のデータベースから直接、埋め込みを生成できます。こうして呼び出したものをプロシージャとして保存したり、PostgreSQL の別の機能と統合して、ベクトル化のプロセスをアプリケーションから完全に抽出できます。Amazon Aurora 機械学習にはバッチ機能が搭載されているため、ベクトルの初期セットを作成するために、Aurora から初期状態のデータセットをエクスポートして変換する必要さえないかもしれません。

Amazon OpenSearch Service 用 k-NN プラグインと Amazon OpenSearch Serverless のベクトルエンジンの利用

k-NN プラグインは、検索とアナリティクスの分散型オープンソースソリューション群で、カスタムの knn_vector データ型でOpenSearch インデックスへの埋め込みを保存できるようになっています。このプラグインは最近傍探索に関する、Approximate k-NN (近似 k-NN) 、Script Score k-NN (非近似 k-NN) 、Painlessextensions (非近似 k-NN) の 3 つの実行手段も提供しています。OpenSearch には Non-Metric Space ライブラリ (NMSLIB) と Facebook が開発した AI 検索「FAISS」のライブラリが含まれます。様々な距離検索アルゴリズムを使って、自分のニーズに合った最適な手段を見つけることができます。このプラグインは Amazon OpenSearch Service でも利用できます。ブログ記事 Amazon OpenSearch Service’s vector database capabilities explained で、これらの機能の詳細な解説をご覧いただけます。

OpenSearch は分散型の性質上、非常に多数の埋め込みのあるベクトルデータストアにとって最適な選択肢と言えます。インデックスは水平方向にスケーリングされるため、埋め込みの保存や類似検索の実行において、より高いスループットに対応できます。また、検索の実行に用いられる手法やアルゴリズムをより細かくコントロールしたい顧客にとっても、最適な選択肢になります。検索エンジンはトランザクションの動作をトレードオフとし、低レイテンシ、高スループットのクエリを実行できるよう設計されています。

Amazon OpenSearch Serverless は、Amazon OpenSearch Service 用のオンデマンドのサーバーレス構成で、OpenSearch クラスターのプロビジョニング、構成、チューニングの運用上の複雑さを解消します。インデックスのコレクションを作成して、自社のインデックスデータを入力するだけで、開始できます。新たに発表された Amazon OpenSearch Serverless 向けベクトル検索エンジンは、検索および時系列コレクションと併せて、新たなタイプのベクトルコレクションとして提供されます。これにより、ベクトルの類似性検索を簡単に始めることができます。簡単な操作で Amazon Bedrock 組み合わせて、自社の生成系 AI アプリケーションにプロンプトエンジニアリングを統合できるため、機械学習やベクトル技術の高度な専門知識の必要はありません。ベクトル検索エンジンによって、 1 回の API コールでベクトルの埋め込みやメタデータ、記述テキストのクエリを簡単に実行できるようになるため、アプリケーションスタックの複雑さを低減しながら、より正確な検索結果が得られるようになります。

k-NN プラグインを搭載した OpenSearch のベクトルは、nmslib や faiss エンジンの使用時には最大 16,000 次元、Lucene エンジン使用時には最大 1,024 次元をサポートします。Lucene はベクトル検索と併せて、OpenSearch のコアとなる検索や分析機能を提供します。OpenSearch は類似検索をはじめとするほとんどの操作にカスタムの REST API を使用します。これにより、OpenSearch のインデックスとのやり取りの際の柔軟性が向上し、スキルを Web ベースの分散型アプリケーションの構築に再利用できます。

OpenSearch はセマンティック類似検索とキーワード検索のユースケースを組み合わせる必要がある場合も、最適な選択肢となります。生成系 AI アプリケーションのプロンプトエンジニアリングには、コンテキストデータの検索と RAG の両方が含まれます。例えば、カスタマーサポート用のエージェントアプリケーションでは、同じキーワードを持つ以前のサポートケースや、意味が似ているサポートケースを含めてプロンプトを作成することがあるため、文脈に合わせて適切な応答をするソリューションが求められます。

Neural Search のプラグイン (現在は実験的に提供されています) を使用すると、自社の OpenSearch のワークフローにML の言語モデルを直接統合できるようになります。このプラグインで OpenSearch は、データの取り込みや検索中に得られたテキストのベクトルを自動的に作成します。作成されたベクトルは、検索クエリの実行時にシームレスに利用されます。これによって、RAG で使われる類似検索タスクを簡素化することができます。

さらに、特定分野のデータ上でフルマネージド型のセマンティック検索を利用したい場合は、Amazon Kendra を検討ください。すぐに使用できるセマンティック検索機能を備えているため、ドキュメントやパッセージの最先端のランク付けが可能になり、テキスト抽出、パッセージ分割、埋め込みの取得、ベクトルデータストアの管理といったオーバーヘッドがなくなります。 Amazon Kendra をセマンティック検索のニーズに合わせて使用し、検索結果を自社開発のプロンプトにパッケージすることで、運用にかかる経費を最小限に抑えて、RAG のメリットを最大限に活用できます。このユースケースの詳しいガイダンスは、ブログ記事 高精度な生成系 AI アプリケーションを Amazon Kendra、LangChain、大規模言語モデルを使って作る でご覧いただけます。

最後に、pgvector を搭載した AmazonAurora PostgreSQL および Amazon RDS for PostgreSQL、the vector engine for OpenSearch Serverless のベクトル検索エンジン、OpenSearch Service with k-NN は LangChain でサポートされています。LangChain は、LLM をベースとするデータアウェアなエージェントスタイルのアプリケーションの開発のための Python のフレームワークとして幅広く利用されています。

まとめ

埋め込みは特定分野のデータセットの近くで保管し管理する必要があります。そうすることで、外部のデータソースを使用せずに、追加のメタデータと一体化することができます。データは静的なものではなく、時間の経過とともに変化するため、埋め込みをソースデータの近くに保存することで、データパイプラインを簡素化し、埋め込みを常に最新の状態に保つことができます。

pgvector を備えた Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL は、Amazon OpenSearch Serverless 用のベクトル検索エンジンや k-NN プラグイン搭載の Amazon OpenSearch Service と同様に、ベクトルデータストアのニーズに対応するための優れた選択肢であるものの、どのソリューションが適切なのかは最終的なユースケースや優先順位によって異なります。この投稿では SQL や NoSQL の精通度に応じたさまざまな選択肢を紹介しており、選択したデータベースにベクトル検索機能がない場合において、いずれの選択肢も運用のために多額のコストをかけることなく、すぐに導入できるものです。どの選択肢を選ぶにせよ、ベクトルデータストアソリューションは、アプリケーションによってディスパッチされる並行スループットを維持する必要があります。すべての埋め込みを揃えてソリューションを大規模に検証することで、期待通りの類似検索の応答時間を得ることができます。

同時に、Amazon SageMaker JumpStart や Amazon Bedrock によって提供された基盤モデルと併用されるプロンプトエンジニアリングによって、ML スキルに多額の投資を行うことなく、お客様を喜ばせる画期的な生成系AIソリューションを構築できます。

最後に、この分野のテクノロジーは急速に進化しており、私たちは状況の変化に応じて常に最新のガイダンスを提供できるよう最善は尽くすものの、この投稿で推奨した内容が必ずしもすべてに当てはまるわけではないことを念頭に置いていただけますと幸いです。

AWS で生成系 AI アプリケーションの構築を始めるにはこちらをご覧ください。迅速なイノベーションに向けて、AWS が提供する多様なツールや機能をチェックし、お客様体験の再構築に役立てていただけることを願っています。

著者について

G2 Krishnamoorthy はアナリティクス担当バイスプレジデントとして、AWS のデータレイクサービス、データ統合、Amazon OpenSearch Service、Amazon QuickSight チームをリードしています。現職以前は、Facebook/Meta でアナリティクスおよび ML プラットフォームの構築と運営を手掛けたほか、Microsoft で SQL Server データベースのさまざまなパーツや Azure Analytics、Azure ML の開発に携わりました。

Rahul Pathak はリレーショナルデータベースエンジン担当バイスプレジデントとして、Amazon Aurora、Amazon Redshift、Amazon QLDB チームをリードしています。現職以前は、AWS のアナリティクス担当バイスプレジデントとして AWS のデータベースポートフォリオ全体を担当していました。デジタルメディアアナリティクス企業および IP ジオロケーションを手掛ける企業の 2 つの会社の共同創業者でもあります。

Vlad Vlasceanu は AWS のデータベース部門のワールドワイドテックリーダーを務めています。お客様の目的にあったデータベースの導入加速を支援し、ワークロードに応じた適切なデータベースが選択できるようにするためのガイダンスの開発に注力しています。AWS 内のデータベースエキスパートコミュニティのリーダーも務めており、ソリューションアーキテクトのデータベーススキルを向上させ、お客様に最適なデータベースソリューションが提供できるよう支援しています。

 

この記事の翻訳はソリューションアーキテクトの木村 達也、丸山 友輔が担当しました。原文はこちらです。