re:Invent 2024: Amazon Titan Embeddingsで実現する低コストRAG
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Power a cost-effective RAG solution using Amazon Titan Embeddings Text (AIM358)
この動画では、RAGソリューションにおけるコスト効率の高いEmbedding手法について解説しています。Amazon Titan Text Embeddingsを用いたBinary Embeddingの活用により、従来のFloat型と比べてストレージコストを90%以上削減できることが示されます。NetDocumentsの事例では、100億のドキュメントを扱うシステムで、年間コストを535万ドルから43.2万ドルへと大幅に削減できたことが紹介されます。また、Binary Embeddingによる精度低下を補うためのRe-ranking手法や、Amazon S3とElasticSearchを組み合わせた具体的な実装アーキテクチャについても詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
RAGソリューションのコスト効率化：本セッションの概要
コスト効率の高いRAGソリューションの実現方法についてご紹介いたします。本日は、NetDocumentsの成功事例をご紹介させていただきます。私はMiguelと申しまして、AmazonでエンベディングチームのSenior Applied Scientistを務めております。後ほどステージに登壇いただくTravisさんとManishさんとご一緒させていただくことを大変光栄に思います。
それでは早速、本セッションの趣旨についてお話しさせていただきます。新しい技術が登場する際には、まずProof of Conceptの段階があり、ある程度のパフォーマンスは達成できるものの、すべてのユースケースやスケールでの利用には適さない段階があります。エンベディングについても最近まさにそのような状況でした。本セッションでは、RAG向けのエンベディングを、低コストを維持しながらスケールアップする方法をご紹介します。これは、ドキュメント数が数百万から数十億に増加する際に特に重要となります。
本日のトピックとして、以下の点についてお話しさせていただきます。まず、エンベディングとは何か、なぜ使用するのか、スケール時の考慮点は何かについてご説明します。次に、Titan Embeddingsがどのようにしてそれらの課題に対応し、どのように活用できるのかについてお話しします。その後、TravisがNetDocumentsの成功事例を、そしてManishがこの技術を活用するためのベストプラクティスをご紹介いたします。
エンベディングの基本概念と検索への応用
それでは、エンベディングの説明から始めさせていただきます。次のようなシナリオを想定してみましょう。「AWSのCEOは誰ですか？」という質問があり、4つのドキュメントの中から適切なものを見つけ出す必要があるとします。緑色で示されたドキュメントが正解です。1つ目は記者会見でのMatt Garmanに関する記事で、CEOが誰かがわかります。4つ目のドキュメントもMatt GarmanがChief Executive Officerであることを示しており、正解です。しかし、2番目と3番目のドキュメントは不適切なので、これらは返すべきではありません。
ここで考えられるアプローチの1つが、レキシカルマッチです。レキシカルマッチとは、質問からキーワード（この場合はAWSとCEO）を抽出し、それらの単語が出現するドキュメントとマッチングを行う方法です。この場合、ドキュメント1にはAWSとCEOがあるので2ポイント、ドキュメント2にはCEOがあるので1ポイント、ドキュメント3にはAWSとCEOがあるので2ポイント、ドキュメント4にはAWSのみで1ポイントとなります。レキシカルマッチングを使用すると、ドキュメント1と3が返されることになりますが、これは望ましくありません。私たちが必要なのはドキュメント1と4です。この方法では、ドキュメント3が過去の話をしているという区別ができません。つまり、単なる語句の一致だけでなく、ドキュメントや質問の意味（セマンティック情報）を理解する、より強力な手法が必要なのです。そのため、ドキュメントやパッセージ、質問の内容を理解する必要があるユースケースでは、エンベディングが使用されています。
Embeddingとは何か説明していきましょう。Wikipediaによると、自然言語処理において、文のEmbeddingとは、意味のある意味論的情報を符号化した実数のベクトルという形式で表現された文章の数値表現を指します。
「私たちはお腹が空いているので、セッションを早く進めてほしい」というテキストがあった場合、これを数値のリストに関連付けることができます。 この数値のリストは、テキストに関する意味論的な情報を本質的に符号化しています。複数の人がいること、空腹であること、そして話者に早く話してほしいということ - これらすべてが数値の一部として符号化されているのです。
さらに、2つのテキストがある場合、それらの意味が似ているならば、そのEmbedding表現も似たものになります。つまり、テキストの意味とその表現の間には対応関係があるのです。ここで話を分かりやすくするために、いくつかの概念を簡単に紹介します。誰かがTokenについて話す場合、おおよそ単語として考えることができます。厳密には少し異なりますが、この講演の目的では、そのように考えて構いません。Chunk sizeは大きなテキストをどのように分割するかを指し、Overlapは単にそれらのチャンク間の重なりを指します。
次に、これらのEmbeddingをどのように作成するかについて説明します。この場合、Embeddingモデルをブラックボックスとして考えることができ、 Amazon Titan Text Embeddingを使用してそのマッピングを行うことができます。 先ほどの例に戻りましょう。この場合、4つのドキュメントがあり、Embeddingを使用したいと考えています。最初のステップは、それらのEmbeddingを作成することです。 ここでEmbeddingを作成していきます。色付きの点は、先ほど示した数値のリストを表しています。 各ドキュメントに対して、1つの数値リストが対応します。
高校で習ったように、もしそれらの数値、つまり数値のリストが2つの要素しか持たない場合、それをプロットに表すことができます。平面上に、これが1番、2番、3番、4番という形で表現できます。ステップ3では、 ユーザーから受け取った質問をEmbeddingします。この時点で、ドキュメントのEmbeddingはその平面上にあるので、どこかに保存しておく必要があります。ユーザーから新しい質問が来たら、それをEmbeddingして数値のリストを作成します。この時点で、同じ空間に配置し、どのドキュメントが近いかを確認することができます。
このケースでは、Document 1とDocument 4の方が意味的に質問の内容に近かったことがわかります。このように、ユーザーの質問に対して最も関連性の高いドキュメントを取得することができるのです。さらに素晴らしいのは、新しい質問が来た場合でも、すでに保存されているドキュメントを活用できることです。同じプロセスで質問をEmbeddingし、同じ空間に配置して、最も関連性の高いドキュメントを特定できます。この場合、Document 3が該当し、現在ではなく過去について言及していることを理解できています。このように、質問間の意味的な違いを区別することができるのです。
大規模ドキュメント処理におけるエンベディングの課題
ここで「それは良い例だけど、実際の現場ではもっと考慮すべきことがあるでしょう」とおっしゃるかもしれません。確かに、多くの方々は様々な制約のある大量のドキュメントを扱っているはずです。
例えば、Embeddingを作成するタイミングについて考える必要があります。Embeddingはドキュメントとクエリの両方に対して作成する必要があり、コストがかかるため注意が必要です。次に言語サポートの問題があります。現在は英語に対応していますが、明日にはスペイン語、ギリシャ語、ドイツ語など新しい市場が出てきた場合はどうするのでしょうか？そういったテキストもEmbedding化できる必要があります。同様に、技術チームがコードスニペットを持っている場合、コードに関する質問をして適切な部分を取得できる必要があります。さらに、何百万、何十億というドキュメントをEmbedding化する必要がある場合、迅速に処理する必要があります - 5ヶ月も処理を待つわけにはいきません。ドキュメント数が増えるにつれて、Embeddingの保存コストも大きな課題となってきます。これが今日お話しするテーマです。
次に、Titan Text Embeddingsがこれらの課題にどのように対応しているかを見ていきましょう。ここまでで、なぜEmbeddingを使用したいのか、いつ使用すべきか、Embeddingとは何か、そして検索やRetrievalのユースケースでどのように機能するかを見てきました。 現在、Titan Text Embeddingsでは、Embeddingの作成コストが非常に低く、1,000 Tokenあたり約$0.00002となっています。現在、テキストに関して英語、多言語、コードをサポートしています。Embeddingの速度については、お客様に2つの選択肢を提供しています。1つ目は、Online inferenceで、モデルを呼び出して1つのテキストだけをEmbedding化します。2つ目は、Inference jobsを作成し、すべてのドキュメントをAmazon S3に保存して、何百万、何十億というドキュメントのEmbeddingを作成する方法です。インスタンスを高速化し、複数のジョブを並列で実行することで、すべてのドキュメントをより速く処理します。
では、このトークの主要なポイントである、Embeddingの保存コストについて見ていきましょう。この問題を単純化してみましょう。コストはメモリに関連し、メモリは保存される情報量に基づいています。数値のリストから始めると、各数値には小数点があり、100個の数値があります。検索エンジンのメモリ使用量、ひいてはコストを削減するには、いくつかの方法があります。 オプション1は単純に切り捨てる方法です - 100個の数値のリストがある場合、最初の50個か25個だけを保持することで、コストをそれぞれ50%または75%削減することができます。
2つ目のオプションは、数値を丸めることです。この例では、それぞれの数値は当初6桁ありましたが、最初の整数だけを残して、残りをすべて切り捨てることができます。 さらに積極的なアプローチとして、数値の符号に応じて0と1を使用することもできます。数値がゼロ以上の場合は1を、ゼロ未満の場合は0を設定します。これがFloat形式からBinary形式への変換方法です。
マイナス1はゼロより小さいので0を設定する、といった具合です。そして3つ目のオプションは、これら2つを組み合わせることができます。 まず切り捨てを行い、その後で丸めることで、ソリューションのメモリ使用量とコストをさらに削減できます。現在、Titanではこれらすべてのオプションを提供しており、 APIを通じて、ユースケースに最適なものを選択できます。
この表について少し詳しく説明させていただきます。私たちのケースでは1024次元の完全なリストを使用した場合、これがベースラインとなるため、メモリ削減は0%で、パフォーマンスは100%維持されます。これを半分に切り捨てると、メモリを50%節約でき、パフォーマンスは99.03%を維持できます。つまり、モデルや検索エンジンが100のパフォーマンスで動作している場合、その水準は維持できませんが、メモリコストを50%削減しながら99のパフォーマンスを実現できるということです。同様に、4分の1の256に切り捨てた場合、メモリ削減は75%で、ベンチマークでは平均して96.76%のパフォーマンスを維持できます。
先ほど説明した極端な丸め処理を行うと、98.51%のパフォーマンスを維持しながら、96.87%のメモリ削減を達成できます。ここでこの2つの列に注目していただきたいのですが、これまでのところ、メモリ削減とパフォーマンスの間で最適なトレードオフを実現できています。アプリケーションが許容できるコストと維持したいパフォーマンスの感度は、それぞれのケースで異なります。すべてのケースに適合するソリューションはありませんが、最近リリースされたBinaryオプションは、その両方の間で非常に良いトレードオフを提供します。
NetDocumentsの事例：Binary Embeddingによるコスト削減
さらなる削減を行うと、メモリ削減は98.44%と99.22%（これまでで最高）を達成でき、パフォーマンスは元の90%または96.3%を維持できます。しかし、これらのオプションのいずれかを選択することができます。それでは、NetDocumentsからの素晴らしいパートナーであるTravisをステージにお迎えしたいと思います。彼らの成功事例と、Titan Embeddingsをどのように活用しているかについてお話しいただきます。ありがとうございました、Miguel。それでは、スケールでのEmbeddingと、なぜBinaryが重要なのかということから始めたいと思います。Miguelがメモリ削減と高い精度の維持について触れましたが、実際のシナリオではどのように見えるのでしょうか？
少し自己紹介をさせていただきます。NetDocumentsのTravis Wasserと申します。私たちのグループは、リーガルテック向けのドキュメント管理会社です。法律事務所や大手企業の法務部門とお仕事をさせていただいており、そのため何十億もの文書を扱っています。2024年1月から2月にかけて振り返ってみると、現在は字句検索やメタデータ検索を行っているものの、
セマンティック検索を実現したいと考えていました。100億の文書でどのようなことができるか、そしてそれらを保存してセマンティック検索を行うとどうなるかを検討し始めました。その結果、当時の浮動小数点ベースのEmbeddingsモデルでは、途方もなく高額なコストがかかることが判明しました。消費者企業の観点からも実現可能性が低かったため、残念ながら一時的にプロジェクトを棚上げせざるを得ませんでした。
3月末から4月初めにかけて、ByteレベルやBitレベルのEmbeddingsが登場し始め、これが議論の発端となりました。その時点でAmazonに「何ができるか」について相談を始め、それが現在に至るパートナーシップの始まりとなりました。ちょうど良いタイミングでBinary Embeddingsが利用可能になり、ご覧いただけるように、これが実現可能となった理由は非常に説得力のあるものでした。
本題に入りましょう。まずMiguelが話していたEmbeddingsの生成に関する項目から始めます。これは基本的に、コンテンツをEmbeddingsの世界に移行することだと考えてください。10億の文書がありますが、生成が必要なのはテキストだけです。これが移行の部分となります。日々100万件の文書を処理する必要がありますが、レガシーコンテンツも対応する必要があります。
Embeddingsのコストについて話すと、まずコンテンツのEmbedding化のコストがあります。これが初期コストです。100億の文書があれば、それに応じた料金を支払う必要があります。多くの人が見落としがちなのは、ユーザーのクエリもEmbedding化する必要があるという点です。「2020年のAcme社の取締役会メンバーは誰か」というような質問をした場合、そのテキスト文字列をそのままVector DBに送信することはできません。テキストと数値表現が互換性を持たないためです。そのため、検索結果を得るためにVector DBに送信する前に、ユーザーのクエリをEmbedding化する必要があります。
これは比較的安価なものです。「2020年のAcme Co.の取締役会メンバーは誰でしたか？」というのは10〜15単語程度なので、非常に低コストですが、クエリの量によっては、年間を通じてかなりの費用が積み重なっていきます。 そして、もちろん最も高額なのがVector Databaseのコストです。この初期コストを支払った後は、どこかにデータを保管する必要があります。保管場所がなければ、Embeddingを生成するためにお金を使っても、それは虚空に消えてしまい、すべてを最初からやり直さなければならなくなってしまいます。
ここでシナリオを設定してみましょう。まず100億個のドキュメントから始めます。ドキュメントの平均テキストサイズは10キロバイトと仮定します。先ほどMiguelが言及したように、これらのドキュメントをチャンク分割する必要があります。非常に大きなテキストを持っていて、それを極端に切り詰めようとすると、それらはすべて効果を低下させる要因となります。最高の精度と性能を得るために、Embeddingを生成する前に、より小さな、扱いやすい意味のある部分に分割したいと考えています。この場合、25%のオーバーラップを持つ512 Tokensで、これは一般的なチャンク分割と埋め込みの保存方法で、平均チャンク数は6となります。
さて、シナリオが設定されたところで、これが何を意味するのか詳しく見ていきましょう。 1000 Tokensあたりのコストを支払う必要があり、この場合は$0.00002です。これは都合よく、ほとんどのFloat Pointモデルのコストと同じペースです。Binaryが最初に登場したときは約5倍のコストでしたので、これは大きな進歩です。 そこから、ドキュメント数に1ドキュメントあたりの平均チャンク数とチャンクサイズを掛けることで、総Token数が算出されます。
Binary Embeddingの具体的な効果：ストレージとコストの大幅削減
大きな数字の準備はできていますか？約31兆Tokensとなります。これは大きな数字ですが、都合よいことに、 1000で割ることができます。 計算すると、移行コストは$614,000となります。赤字の項目がいくつか見えると思います。ドキュメント管理企業として、サポート記事やその他のコンテンツを使用する場合でも、バージョンが存在します。Version 1、Version 2、Version Xを考慮すると、長期的に考慮しなければならない要素があります。最新バージョンのみを保存するのか、すべてのバージョンを保存するのか、これらの決定は特定のユースケースに基づいて行われます。
同様に、先ほど言及したように、ユーザークエリがあります。それらのクエリが長くなるほど、あるいは量が多くなるほど、コストは増加します。また、先ほど言及したように、入力前にEmbeddingを生成する必要があります。再Embeddingが必要になった場合はどうなるでしょうか？過去にFloat Pointモデルを使用したことがある方は、Float Pointを使用するX サイズのVector Storeを持っているかもしれません。そのため、Titanを使用するように移行する場合は、再Embeddingが必要になります。特にビジネスリーダーや予算策定を担当する方が5年間の総所有コストを提案しようとする際に考慮しなければならないことの1つは、3年目にTitan V3やTitan V4が登場し、精度が大幅に向上して活用したくなるような説得力のあるビジネスケースがある場合、どうなるかということです。これらはすべて、これらのEmbeddingの初期生成に影響を与える要因です。これが参入のための初期コストであることを強調しておきたいと思います。しかし、お気づきの通り、すでに$614,000を扱っていますが、まだ保存すらしていません。
それでは楽しい部分、ストレージの話に入っていきましょう。先ほど触れたEmbeddingの保存について説明します。 これは、Binaryが真価を発揮した領域の一つです。ディスクレベル、CPUレベル、メモリレベルで大幅なコスト削減を実現し、それらが積み重なってより実用的なユースケースとなりました。 セットアップは非常にシンプルです：100億のドキュメントで、それぞれ10キロバイトのテキスト。これは純粋なテキストの話で、画像やビデオなどは考慮していません。つまり、1万文字程度ということです。
興味深かったのは、私たちがfloat形式が高コストだと気付いた理由にも関係するのですが、Vector Databaseに保存する際にテキストに対して乗数効果があることが分かりました。生のテキストと関連するメタデータをfloat形式のEmbeddingに変換して保存すると、サイズが200キロバイトまで増加することが判明したのです。これは20倍の増加です。これは単にストレージレベルで影響があるだけでなく、メモリ上にこれらのアイテムを保持する場合にも、かなり大きなメモリ容量を必要とすることを意味します。
興味深いことに、Binaryを使用した場合でも若干の増加は見られましたが、私たちのユースケースでは、その増加はメタデータに関連するものがほとんどでした。特定のメタデータ、例えば法的案件や事案との関連性などは、静的な値なので対処のしようがありませんでした。しかし、平均テキストサイズを40キロバイト、50キロバイト、60キロバイトと増やしていくと、乗数効果ではなく、実際には1対1の比率を下回ることに気づきました。つまり、60キロバイトのファイルでも、メタデータを計算に入れても、インデックスのストレージは50キロバイト程度で済むのです。Binary Embeddingを使用することで、Vector DB内にチャンクテキストを保存しない場合、1対1以下の関係性が見られました。つまり、20倍に対して1.5倍という大きな違いが出たのです。
具体的な数字を見てみましょう。 10キロバイトの文書が100億件の場合、約2ペタバイトになります。興味深いのは、これを運用する方法を考える際、Vector DBのプロバイダーが誰であれ - ベンダーサービスでもOpen Searchでも、自社ホスティングでも - 何らかのハードウェアが必要になるということです。この例では、EC2インスタンスで自社ホスティングする場合を想定しています。ベンダーを使用する場合は数字が異なりますし、私たちの実際の数字も異なりましたが、分かりやすい例を示したかったのです。 この場合、i4.4xlargeを選択しました。これはストレージ最適化されたEC2インスタンスで、最大のディスク容量を持つものの一つです。これを選んだ理由は、これから見る数字が高額であっても、これが最も理想的なケースだからです。
実際の数字はおそらく異なり、より高くなる可能性が高いでしょう。これは本質的に、1900テラバイトを収容するために必要な最小限のストレージ最適化EC2インスタンス数を示しています。その数は670インスタンスで、月額コストは45万ドル、つまり年間約540万ドルになります。Vector DBが最もコストがかかる部分だと言った時、冗談ではなかったのです。
移行に60万ドルを支払いましたが、これからは永続的に少なくとも540万ドルを費やすことになります。これは大きな額です。年間20億件または40億件のドキュメントを追加している場合、この数字は実際にもっと増えていきます。コンテンツの保持期限を設定していない場合、つまり10年以上経過したドキュメントは削除するといったような保持ポリシーがない場合、この数字は増え続けることになります。
先ほど最も理想的なケースについて触れましたが、i4.4xlargeには3.4テラバイトの使用可能なストレージがあり、この場合、それを満たすために670インスタンスが必要でした。通常、ボトルネックとなるのはストレージではなく、CPUかメモリです。1分あたりの大量のクエリが発生する場合、それによってCPUコストが上がる可能性があります。結果をフィルタリングせずに、単に最初から全期間のドキュメントが欲しいと指定すると、より多くのメモリが必要になります。なぜなら、ディスクにアクセスする必要がないよう、より多くのデータをキャッシュで利用可能にする必要があるからです。
結果を最初にフィルタリングして、例えば直近1年分のドキュメントだけを指定してから検索すると、対象セットが限定されるため、メモリに保持する必要があるデータが少なくなり、キャッシュミスが発生してディスクにアクセスする可能性が減ります。ストレージについて最も理想的なケースを選んだ理由は、他のすべての要素が特定のユースケースに基づいており、時間とともに変化する可能性が高いからです。私たちのケースでも、レキシカル検索を行い、そのボリュームは把握していましたが、セマンティック検索に移行すると、レキシカル検索での経験に基づいてセマンティック検索の数値を予測しても、それは正確ではない可能性があります。
クライアントとの会話で分かったことの1つは、正確な文言を覚えておくのに苦労していたということです。これはレキシカル検索の課題の1つです。探そうとしているドキュメントのかなり正確な文言を覚えておく必要があり、法的文書の場合、これは困難です。100ページの契約書なら、なおさらです。セマンティック検索を導入すると、実際に検索クエリは増加すると予想しており、そこでこれらの数値が関係してきます。CPUやメモリのために2倍、3倍、4倍のハードウェアを割り当てる必要がある場合、あるいはストレージ最適化からメモリ最適化やコンピュート最適化に移行する場合、それらはすべて追加コストとなります。
参考までに、ストレージ最適化が時として意味を持つ理由は、R6gdメモリ最適化マシンで使用されているCPUと非常に似たGraviton 2を使用するi4gを選択したからです。その R6gd 4xlargeには720ギガのスペースしかなく、これは約4.5倍少なくなります。つまり、670インスタンスがある場合、それを4.5倍すると、新しいインスタンスコストが分かります。これはクラスタリングに関連する25%のオーバーヘッドは考慮していますが、冗長性は考慮していません。
Binary Embeddingの実践的応用：精度とコストのバランス
気になる方もいらっしゃるかもしれませんが、私たちは全クライアントの100億ドキュメントを1つのクラスターに置いているわけではありません。特定の上限を設けて複数のクラスターに分割しています。670個のインスタンスを1つのクラスターにするのは悪夢のようなものですから、時には1つのクラスターに複数のクライアントが存在することもあります。これが1月と2月にこの問題を検討した際に、うまくいかなかった不都合な真実です。
では、なぜ今これが理にかなうようになったのか見ていきましょう。Binaryについて、先ほどと同じように見ていきますが、その数字を見てください - 1900テラバイトから140テラバイトに減少しました。これはかなり驚くべき数字です - 90%以上の削減効果があり、Miguelが説明していた通り、これを活用すると90%以上、96%、98%の削減が可能になります。これは素晴らしいことですが...
...同じi4g.4xlargeインスタンスを使用してみましょう。52ノードで月額36,000ドル、年間432,000ドルの支払いで済むようになりました。これは最も理想的なケースを示していますが、興味深いのは次の点です：670インスタンスに16 vCPUを掛けると、非常に大きな数のvCPUになります。面白いことに、CPUの数は減少していますが、先ほどMiguelが示したように、メモリ使用量やパフォーマンスなども同様に削減されています。以前は200キロバイトのメモリが必要でしたが、今は15キロバイトで済みます。そのため、メモリは少なくなっていますが、ギガバイトあたりのドキュメント数に基づいてより効率的に使用できるようになっています。
常にベストな解決策というわけではなく、より多くのリソースが必要な状況も確実にあります。1対1の関係にはなりませんが、時間と労力を節約できる可能性を提供してくれます。CPU使用コストの観点からは、小数点以下に多くの桁を持つ大きな数値文字列から、本質的に1か0に切り替わります。計算の観点からも、従来のFloat Pointを使用する場合と比べて、CPUとメモリの両方をインスタンスごとにはるかに効率的に活用できます。
これを強調したいのは、私たちが妥当な数字まで削減できたからです。ユースケースに応じてこの数字を2倍や3倍にする必要があることは承知していますが、CPUやメモリの目標を達成するためにこれを2倍や3倍にしても、Float Pointのための生のストレージを用意するよりもはるかに安価です。RAGに話を戻すと、私たちはSemantic Searchについて多く議論してきました。私たちにとって、今後どのようにポジショニングしていくかを検討する上で重要な点の1つは、コンテンツをEmbeddingした後、通常の運用の一部としてRAGベースのワークフローへの道を開くことができるということです。これにより、AIへのさらなる進出が格段に容易になります。
自社のことを考え、実際のコンテンツがどのようなものかを検討する際、これまでに取り込んだすべてのドキュメントを見ているのか、小規模なナレッジベースを見ているのか、それとも直近1年分のドキュメントだけを見ているのか、といった要素すべてが重要になってきます。しかし、最終的には約90%のコストを削減できることが重要なポイントです。まとめとして具体的な数字をお見せしましょう： float32の場合、1,860テラバイトのストレージ、670インスタンス、年間535万ドルのコストがかかります。 Binaryの場合、ストレージ量は大幅に減少し、必要なインスタンス数も少なく、コストも大幅に削減されます。
これは、自社に最適なものを見つける必要がある典型的な例です。Miguelの回答でご覧いただいたように、次元数の削減によるコスト削減、極端な丸め処理、あるいは極端な丸め処理と切り捨ての組み合わせなど、いくつかのアプローチがあります。精度のポイントがどこにあり、何が自社にとって理にかなっているのかをテストする必要があります。極端な丸め処理を行って上位100件の結果を取得する場合や、切り捨てと極端な丸め処理を組み合わせて上位200件を取得する場合など、これはManishaが説明するRe-rankingの話につながります。Binaryメトリクスで低下した部分は、結果のRe-rankingによって取り戻すことができます。200件の結果を取得して100件に絞る場合でも、Re-rankingによって真の関連性を判断することができます。
Manishaが説明するのは、Binaryを使用することで失われた部分を取り戻し、float値に近い値まで回復させるためのRe-rankingアプローチです。この半実践的なケーススタディが参考になれば幸いです。通常の企業の事情により、これらの数字は実際の数字とは若干異なりますが、私たちがテストした実際の数字に非常に近いものです。これにより、あらゆる規模でSemantic Searchを実現可能にするためにBinaryへの移行が重要である理由が明確になったと思います。それでは、BinaryエンベディングとRe-rankingのアーキテクチャについて説明するManishaに交代したいと思います。
AWS上でのBinary Embeddingの実装アーキテクチャ
ありがとうございます、Travis。Binaryエンベディングを使用して達成したコスト削減の数字は素晴らしいですね。私のスライドの説明に完璧な導入になりました。 最もシンプルな言葉で説明させていただくと、お二人が共有した内容をAWS上でどのように構築するかについてです。ドキュメントの取り込みやアップロードなどの側面は省略し、テストエンベディングの作成と検索に関連する部分に焦点を当てています。
上部にあるのが最も安価なストレージオプションであるAmazon S3です。SDKコンソールを使用するか、SFTPを使用した自動プロセスでS3にドキュメントをプッシュすることができます。S3でドキュメントが利用可能になったら、Titan v2エンベディングモデルを適用し、Amazon ElasticSearchにストアとして保存できます。この場合、ElasticSearchストアを作成し、エンベディングをプッシュして、エンベディングを使用できる状態にします。Travisが既に異なるアプローチについて説明しましたが、このアーキテクチャを徐々に発展させて、さらなる改善方法をお見せしていきます。
クエリがプロンプトとして入力されると、別の Embedding モデルを適用してそのクエリを Embedding チャンクに分解します。その後、これらのバイナリ Embedding を使用して ElasticSearch ストア内を検索します。トップ5やトップ100のIDなどのレスポンスを受け取り、S3からそれらのドキュメントやパッセージを取得して、アプリケーションに渡すことができます。 Travis が言及したように、Binary Embedding を使用することでストレージコストは削減できますが、その分パフォーマンスと精度が低下するため、それを取り戻す必要があります。
これに対処する方法の一つをご紹介します：ステップ1では、S3に保存されているすべてのドキュメントに対して、Binary Embedding モデルを適用し、それを ElasticSearch に保存します。ユーザークエリが入力されると、Embedding モデルを適用して Embedding を作成し、ElasticSearch で検索を行います。Mula が共有したように、同じ呼び出しで両方のタイプの Embedding を適用できます。ステップ2では、Float型と Binary の両方の Embedding タイプを使用します。両方のタイプの Embedding を受け取り、その Float Point Embedding を Reranker に送信します。
バイナリ検索からトップ100のIDとパッセージ、そしてFloat Point Embedding を受け取る Reranker コンポーネントを導入しました。Binary Embedding のIDと Float Point Embedding の間でコサイン類似度を使用してクロスリファレンスを行います。スコアが高いほどランクは下がり、より良い結果が得られます。リランク後、S3からそのデータを取得します。Float Point と Binary の両方の Embedding を生成することで、ストレージコストを削減しながら、リランキングによる精度も確保できています。
このアーキテクチャをさらに改善するため、追加のコンポーネントを導入しました。ドキュメントは S3 に保存したまま、Binary Embedding モデルを適用して ElasticSearch に保存します。ユーザークエリが到着すると、Binary と Float の両方の Embedding を作成します。Binary Embedding は ElasticSearch でトップIDを検索するために使用し、Float Point Embedding は Reranker に送られます。さらに、Float Point Embedding とパッセージを S3 に保存する追加ステップを加えました。Binary と Float Point の両方の Embedding を保存することでストレージコストは若干増加しますが、S3 は費用対効果の高いストレージソリューションであり、これによってIDを送信する際に Float Point Embedding を利用できるようになりました。
これらのIDを Reranker に送り返す際、Float Point 同士を比較することで精度が向上します。なぜ最初に Binary Embedding に変換したのかと疑問に思われるかもしれません。検索の大部分は Amazon ElasticSearch で行われ、ストレージと費用の大部分は ElasticSearch 自体で発生します。Binary Embedding を適用して保存することで、ストレージコストを大幅に削減できました。しかし、精度を向上させたい実際のリランキングでは、Float Point から Float Point への Embedding を使用して結果を改善しています。このケースでは、両方の利点を活用して、より良い結果を得ることができ、それらを Amazon S3 から取得して利用可能にすることができます。
これは実装方法の一例です。DynamoDBやその他のソリューションを提案する方もいるかもしれませんが、必要に応じてすべてのドキュメントを保存できるAmazon S3の方が、よりコスト効率の良いストレージオプションとなります。これで本プレゼンテーションは終了となります。私たちは、Embeddingが重要である理由、Embeddingの基礎、そして最近発表されたBinary EmbeddingをサポートするようになったAmazon Titan Text Embeddings version 2モデルについて説明しました。また、NetDocumentsの事例を紹介し、彼らがストレージコストを大幅に削減しながら、顧客により良い検索結果を提供できるようになった経緯についてお話ししました。さらに、これらのソリューションを実装する方法についていくつかのアーキテクチャ図を用いて解説しました。
以上で終了となります。皆様、re:Inventの残りの日程をお楽しみください。質問がございましたら、このあと会場の外で質疑応答の時間を設けておりますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion