/w=3840,quality=90,fit=scale-down)
※本記事は、AWS re:Invent 2024のセッション「Power a cost-effective RAG solution using Amazon Titan Embeddings Text (AIM358)」の内容を基に作成されています。このセッションでは、大規模文書を処理し、Q&A、要約、会話型アシスタントなどの様々なタスクに対応する検索を可能にするための生成AIの活用について解説しています。特に、NetDocumentsが数十億のドキュメントを40倍低いコストで処理できるAmazon Titan Embeddings Textのバイナリ版をどのように活用しているかを紹介しています。セッションの詳細はYouTube (https://www.youtube.com/watch?v=8B1RW6uw8GQ) でご覧いただけます。AWS re:Inventについての詳細は https://go.aws/reinvent をご参照ください。本記事の内容は講演者の見解を反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報については原講演をご視聴ください。
1. はじめに
1.1. セッションの目的：コスト効率の良いRAGソリューションの紹介
Miguel：本日は、コスト効率の良いRAGソリューションについて探求するセッションへようこそ。このセッションでは、Lucianと私が共同でNetDocumentsの成功事例を皆様と共有する予定です。私はMiguelと申します。Amazonでエンベディングチームに所属する応用科学者です。後ほど、TravisとManishも登壇し、プレゼンテーションを続けることになっています。
まず、このトークの背景について少し説明させてください。技術の変化が起こるたびに、最初は概念実証から始まります。ある程度の精度に達し、パフォーマンスの向上が見られます。しかし通常、その段階ではすべてのユースケースに対応したり、大規模に使用したりすることはできません。最近のエンベディングに関しても同様の状況がありました。
このセッションでは、何百万、何十億ものドキュメントを扱う際に重要となる、低コストを維持しながらRAG用のエンベディングを拡張するための方法を紹介します。具体的には、次のポイントについて説明していきます。まず、エンベディングの基本概念、その使用理由、方法、スケールアップ時の考慮事項について説明します。次に、Titan Embeddingsがそれらの課題にどのように対処し、その技術をどのように活用できるかを紹介します。その後、Travisが続いてNetDocumentsの成功事例について説明し、最後にManishがこの技術を使用するためのベストプラクティスを紹介します。
1.2. 発表者の紹介
Miguel：私はMiguelと申します。Amazonで応用科学者として働いており、エンベディングチームに所属しています。本日は、TravisとManishと共にプレゼンテーションを行います。彼らは後ほど私の後に登壇する予定です。
Travis：私はTravis Wasserと申します。NetDocumentsで働いています。弊社は法務テック向けのドキュメント管理会社です。法律事務所や大企業の法務部門と連携しています。都合のいいことに、数十億ものドキュメントを扱っています。このセッションでは、実際にどのようにバイナリエンベディングを活用してコスト削減と効率化を実現したかについて、実際の数値を交えながら説明します。
Manish：皆さん、私の声は聞こえていますか？ Travisの話したコスト削減効果とバイナリエンベディングの活用事例について引き続き解説していきます。私は、これらの技術をAWS上でどのように実装できるかを、実践的なアーキテクチャ図とともに説明します。特にリランキングの手法を用いた精度向上の方法に焦点を当てて解説します。
1.3. エンベディング技術の背景と課題
Miguel：技術革新が起こるとき、まず最初に概念実証が行われます。ある程度の精度に達し、一定のパフォーマンスレベルに到達します。しかし、その段階では通常、すべてのユースケースや大規模な実装に対応できるわけではありません。エンベディング技術に関しても最近まさにこの状況でした。このセッションでは、RAG（Retrieval-Augmented Generation）のためのエンベディングを使用して、何百万、何十億というドキュメントを扱う際に低コストでスケールアップする方法を紹介します。これは大規模に展開する際に非常に重要な要素です。
Travis：2024年1月と2月に私たちNetDocumentsが調査を始めた時、我々は従来のレキシカル（語彙的）検索やメタデータ検索を行っていましたが、意味的検索（セマンティック検索）を実現したいと考えていました。100億のドキュメントがあり、それに対して意味的検索を行うにはどうすればよいか検討しました。既存の浮動小数点ベースのエンベディングモデルでは、コストが途方もなく高くなることがわかりました。消費者企業の観点からは実行不可能な水準でした。そのため、一時的にこのアイデアを棚上げせざるを得ませんでした。
3月末から4月初めにかけて、バイトレベルやビットレベルのエンベディングが登場し始めました。それが会話の出発点となりました。そこでAmazonとの対話を開始し、「何ができるか」を模索し始めました。それが今日に至るパートナーシップの始まりでした。便利なことに、バイナリエンベディングが登場し、そのストーリーは説得力があり、意味的検索を実現可能にしました。
エンベディングの導入に際して考慮すべき課題としては、コスト、多言語対応、大量データの処理速度、そしてエンベディングの保存コストが挙げられます。特に保存コストは、ドキュメント数が増えるにつれて無視できない規模になります。これが今日のトークの主なポイントになります。
2. エンベディングの基礎
2.1. エンベディングとは何か
Miguel：エンベディングについて説明するために、まずウィキペディアの定義を引用します。「自然言語処理において、文のエンベディングとは、意味のある意味情報をエンコードする実数のベクトルの形で文を数値表現したものを指します。」これを理解するのは少し難しいので、一つずつ解説していきましょう。
まず「文のエンベディングとは、実数のベクトルの形での文の数値表現を指す」という部分。これは単に、テキスト（例えば「私たちはお腹が空いているので、プレゼンをもっと早く進めてほしい」というような文）を何らかの方法で数値のリストに関連付けることができるということです。
さらに、このリストの数値は本質的にテキストの意味的情報を符号化しています。例えば、そのテキストが二人以上の人々について言及していることや、空腹を示していること、話者に早く話してほしいという要求が含まれていることなどが、すべてこれらの数値の一部としてエンコードされています。
また、二つのテキストがあり、その意味が似ている場合、それらのエンベディング表現も似たものになります。つまり、意味とテキストの表現の間には対応関係があります。
ここで簡単にいくつかの概念を紹介しておきます。トークンについて誰かが話す場合、それは大まかに単語に対応していると考えることができます。厳密には少し異なりますが、このトークの目的では、そのように考えても良いでしょう。チャンクサイズとは、大きなテキストがある場合、それをどのように分割するかという分割サイズのことです。そして、これらのチャンク間のオーバーラップは、まさにその名の通りです。
エンベディングを作成する方法については、エンベディングモデルをブラックボックスと考えることができます。この場合、Amazon Titan Text Embeddingsを使用してその変換を行うことができます。
2.2. 検索における語彙的マッチングと意味的マッチングの違い
Miguel：エンベディングの重要性を理解するために、次のシナリオを考えてみましょう。「Amazonの最高経営責任者（CEO）は誰か」という質問があり、私たちは4つの文書からこの質問に最も関連する文書を検索する必要があります。
緑色の文書が正解で、文書1「CEOのMatt Garman、AWS健康記者会見」と文書4「Matt Garman、AWS最高経営責任者」が該当します。これらの文書からCEOが誰かを知ることができます。しかし、文書2と文書3は正解ではないため、これらの文書は検索結果として返すべきではありません。
一つのアプローチとして、語彙的マッチングが考えられます。これは、質問から主要なキーワード（この場合「Amazon」と「CEO」）を推測し、それらの単語が出現する文書を検索する方法です。この方法を適用すると、文書1には「AWS」と「CEO」があり、2ポイントのマッチとなります。文書2には「CEO」のみで1ポイントのマッチ。文書3は「AWS」と「CEO」で2ポイント。文書4は「AWS」のみで1ポイントとなります。
ここで問題が発生します。語彙的マッチングでは、文書1と文書3が最も高いスコアになりますが、私たちが欲しいのは文書1と文書4です。なぜなら、文書3は過去の話について言及しているため、現在のCEOを知りたい質問に対しては適切ではないためです。
この例から、単に語彙的情報をエンコードするだけでなく、文書と質問の意味をエンコードするより強力な方法が必要だということがわかります。そのため、文書や質問の意味を理解する必要があるユースケースでは、エンベディングが使用されます。
エンベディングを使えば、質問「Amazonの最高経営責任者（CEO）は誰か」に対して、単なる単語の一致ではなく、意味的に関連する文書を検索できます。さらに、「AmazonのCEOは誰だったか」という新しい質問が来た場合も、エンベディングは質問の意味の違いを理解し、過去のCEOについて言及している文書3を正しく識別できます。これが、私たちの質問間の意味の違いを区別できる理由です。
2.3. エンベディングの仕組みと処理フロー
Miguel：先ほど挙げた例を用いて、エンベディングの実際の処理フローを説明しましょう。4つの文書があり、エンベディングを使って最も関連性の高い文書を見つけたいとします。
最初のステップは、これらの文書のエンベディングを作成することです。各文書に対して、先ほど説明した数値のリストを生成します。色付きの点は、先ほど示した数値のリストを表しています。つまり、各文書に対して、それに対応する数値のリストが1つずつあります。
高校で習ったことを思い出せば、これらの数値のリストが2つの要素しか持たない場合、平面上にプロットすることができます。平面上に文書1、文書2、文書3、文書4を配置するイメージです。
第3のステップは、ユーザーから来る質問をエンベディングすることです。この時点で、文書のエンベディングは平面上に配置され、どこかに保存されています。そして、ユーザーから新しい質問が来ると、その質問をエンベディングし、数値のリストを作成します。
これにより、質問も同じ空間に配置して、どの文書が近いかを調べることができます。この例では、文書1と文書4が最も近いことがわかります。なぜなら、それらの意味が質問の意味と似ているからです。このようにして、ユーザーの質問に最も関連性の高い文書を取得できます。
この方法の素晴らしい点は、新しい質問が来ても、保存された文書のエンベディングをそのまま使えることです。新たな質問が来たら、同じプロセスで質問をエンベディングし、同じ空間に配置し、最も関連性の高い文書を特定します。例えば「過去のCEO」について質問された場合、最も関連性の高い文書は文書3になります。このシステムは、現在と過去という意味の違いを区別できるのです。
2.4. エンベディング導入時の考慮事項
Miguel：実際のシナリオでは、より多くの要素を考慮する必要があります。皆さんの多くは膨大な量のドキュメントを持ち、いくつかの制約があるでしょう。例えば、エンベディングを作成する際、ドキュメント用のエンベディングとクエリ用のエンベディングの両方を作成する必要があり、これにはコストがかかります。ここでは注意が必要です。
第二に、現在は英語のサービスを提供していても、明日はスペイン語やギリシャ語、ドイツ語など新しい市場に対応する必要が出てくるかもしれません。そのような様々な言語のテキストも同様にエンベディングできる必要があります。また、技術チームがコードの一部を持っていて、そのコードについて質問し、適切なコード部分を取得したい場合も、同様の対応が求められます。
第三の考慮点は、数百万または数十億のドキュメントがあり、それらすべてをエンベディングする必要がある場合、処理速度が重要になります。ドキュメントの処理が終わるまで5ヶ月も待つことはできません。
そして本日の主要なトピックとなるのが、エンベディングの保存コストです。ドキュメント数が増えるにつれて、このコストは無視できなくなります。次に、Titan Text Embeddingsがこれらの課題にどのように対処するかを見ていきましょう。
Travis：2024年1月と2月にNetDocumentsで検討を始めた際、我々は言っていました。「今日、私たちはレキシカル検索やメタデータ検索を行っているが、意味的検索をしたい」と。100億ドキュメントがあり、それらをすべて意味的検索できるようにするにはどうすればいいか検討しました。当時の既存の浮動小数点ベースのエンベディングモデルでは、コストが非常に高く、消費者企業の視点からは実行不可能だったのです。そのため、一時的にこのプロジェクトを棚上げせざるを得ませんでした。
3月末から4月初めにかけて、バイトレベルとビットレベルのエンベディングが登場し始め、それが会話のきっかけになりました。私たちはAmazonと対話を始め、「何ができるか」を模索し始めました。それが今日に至るパートナーシップの始まりで、便利なことにバイナリエンベディングが利用可能になり、大規模な意味的検索を実現可能にしました。後ほど詳しく説明しますが、そのストーリーは非常に説得力があります。
3. Amazon Titan Embeddings の特徴
3.1. 基本機能と料金体系
Miguel：ここまでで、エンベディングを使用する理由、使用するタイミング、エンベディングとは何か、そして検索やRAGのユースケースでどのように機能するかを見てきました。これを踏まえて、今日利用可能なTitan Text Embeddingsの特徴を説明します。
まず、これらのエンベディングを作成するコストは非常に低く、1,000語（または正確にはトークン）あたり0.00002ドルです。これは覚えておいてください。現在、テキスト用に英語、多言語、コードの3種類をサポートしています。
また、ドキュメントをエンベディングする速度に関して、お客様に2つの選択肢を提供しています。この点は明白ではないことが多く、多くの質問を受けるので強調しておきます。
1つ目のオプションはオンライン推論です。モデルを呼び出し、テキストを渡して、そのテキストだけをエンベディングします。
2つ目のオプションは推論ジョブを作成することです。基本的にすべてのドキュメントをS3に保存し、「これらがドキュメントなので処理してエンベディングを作成してください」と指示します。数億または数十億のドキュメントを扱う場合、インスタンスをスピードアップし、複数のジョブを並行して実行し、すべてのドキュメントをより速く処理します。
3.2. サポートされる言語と処理方法
Miguel：Titan Text Embeddingsは現在、テキスト用に3つの主要なカテゴリーをサポートしています。まず英語、次に多言語、そして第三にコードです。これらのモデルを使えば、それぞれのタイプのコンテンツに適したエンベディングを生成できます。
処理方法に関しては、ドキュメントを処理する際の速度について、お客様に2つの選択肢を提供しています。この点は必ずしも明白ではなく、多くの質問をいただくので強調しておきたいと思います。
1つ目の選択肢はオンライン推論です。モデルを呼び出し、テキスト部分を渡して、そのテキスト部分だけをエンベディングします。これは個別のテキスト処理に適しています。
2つ目の選択肢は推論ジョブを作成することです。基本的に、すべてのドキュメントをS3に保存し、「これらがドキュメントです。処理して、これら数億または数十億のドキュメントのエンベディングを作成してください」とシステムに指示します。この場合、インスタンスの処理速度を上げ、複数のジョブを並行して実行することで、すべてのドキュメントをより速く処理します。これは大規模なドキュメントコレクションのバッチ処理に最適です。
各言語やコードのサポートにより、様々なユースケースに対応できるようになっています。英語だけでなく、他の言語のコンテンツや技術的なコードのセマンティック検索も実現可能です。これにより、多様な言語環境やコードベースを持つ組織でも、統一された検索体験を提供できます。
3.3. エンベディングのサイズ削減方法（チョッピング、ラウンディング、バイナリ化）
Miguel：ここから、エンベディングの保存コストに関する話題に移ります。これが本トークの主要ポイントです。この問題を単純化してみましょう。コストはメモリ使用量に関連しています。メモリは保存する情報の量に基づきます。
私たちの数値リストを例に考えましょう。各数値には小数点があり、全部で100個の数値があるとします。メモリフットプリント、つまりコストを削減するために使える方法がいくつかあります。
第一のオプションは「チョッピング」です。100個の数値のリストがあるなら、最初の50個だけを保持するか、最初の25個だけを保持するという方法です。これにより、コストをそれぞれ50%または75%削減できます。
第二のオプションは「ラウンディング」です。最初に持っていた各数値には6桁の小数があるとします。最初の整数だけを保持し、残りをすべて切り捨てることができます。さらに積極的に、数値の符号によって0と1を使用することもできます。数値が0以上であれば1を、0未満であれば0を設定するというように。これがフロート版からバイナリ版への変換方法です。
第三のオプションは、これら二つの方法を組み合わせることです。チョッピングしてからラウンディングすれば、メモリ使用量とコストをさらに削減できます。
今日、Titanはこれらすべての選択肢を提供しています。APIに直接アクセスして、ユースケースに最適な方法を選択できます。
数値で見てみましょう。元の完全なリストでは、我々の場合は1,024次元あります。これがベースラインなのでメモリ削減は0%、検索パフォーマンスの保持は100%です。
リストを半分にチョッピングした場合（512次元）、メモリは50%になる一方、パフォーマンスの保持率は99.03%です。つまり、あなたの検索エンジンがスコア100で動作していた場合、それほど低下せず、コストを50%削減しながら99のパフォーマンスを維持できます。
同様に、4分の1に削減（256次元）すると、メモリ削減率は75%、パフォーマンス保持率は96.76%になります。
そして、先ほど説明した極端なラウンディング（バイナリ化）では、数値の精度のため、メモリ削減率は96.87%に達しながら、パフォーマンス保持率は98.51%を維持します。
ここで特に注目したいのは、この二つの列です。これまでのところ、これがメモリ削減とパフォーマンスの間で最良のトレードオフを提供します。もちろん、アプリケーションが許容できるコストとパフォーマンスの感度は、それぞれ異なるでしょう。
すべてに当てはまる解決策はありませんが、最近発表されたバイナリエンベディングは、両者の間の非常に良いトレードオフを提供します。さらなる削減が必要なら、メモリ削減率は98.44%と99.22%に達し、パフォーマンスは元の96.3%または90%に低下します。いずれか一方または複数の選択肢を使用する自由があります。
3.4. 各種エンベディング圧縮方法のパフォーマンス比較
Miguel：各種エンベディング圧縮方法のパフォーマンスを比較した表をお見せします。これは実際のトレードオフを理解するのに役立ちます。
まず、フル次元数（1,024次元）の場合、これは私たちのベースラインなので、メモリ削減率は0%、パフォーマンス保持率は100%です。
次に、次元数を半分（512次元）に削減した場合、メモリは50%削減されますが、パフォーマンスは99.03%維持されます。つまり、コストを半分にしながらも、ほぼ同等のパフォーマンスを維持できるのです。
次元数を4分の1（256次元）に削減すると、メモリは75%削減され、パフォーマンスは96.76%維持されます。ベンチマークで平均すると、これだけの削減でもかなり高いパフォーマンスを保持できています。
極端なラウンディング（バイナリ化）を適用すると、数値の精度によって、メモリ削減率は96.87%に達しながら、パフォーマンス保持率は98.51%という驚異的な数値が得られます。
特に注目すべきは、このバイナリ化のアプローチです。ここでは、メモリ削減とパフォーマンス保持の間で最良のトレードオフが得られています。もちろん、各ユーザーのアプリケーションによって、許容できるコストとパフォーマンスのバランスは異なります。
最近発表されたバイナリエンベディングは、両者のバランスが非常に良いトレードオフを提供します。さらにメモリ削減を進めたい場合は、メモリ削減率を98.44%から99.22%まで高めることができますが、その場合パフォーマンスは元の96.3%または90%に低下します。
ユースケースに応じて、これらのオプションから選択することができます。例えば、高精度が絶対に必要な場合はフル次元を使用し、コスト効率を最優先する場合はバイナリ化を選択するなど、柔軟に対応可能です。これらの選択肢により、エンベディングを実際の運用環境で効果的に利用できるようになります。
4. NetDocuments の成功事例
4.1. NetDocumentsの背景と課題（100億ドキュメントの管理）
Travis：それではスケールでのエンベディングと、なぜバイナリ形式が重要なのかについて説明します。Miguelがメモリ節約とパフォーマンス維持の観点から少し触れましたが、実際の現場ではどのように見えるのでしょうか？
私はTravis Wasserで、NetDocumentsで働いています。私たちのグループは法務テック向けのドキュメント管理会社です。つまり、法律事務所や大企業の法務部門と協力しています。これは都合良く、数十億ものドキュメントを管理していることを意味します。
2024年1月と2月に振り返った時、私たちは「今日、レキシカル検索やメタデータ検索を行っているが、意味的検索をしたい」と考えました。そこで検討を始めました。「100億のドキュメントがあり、それらを意味的に検索するにはどうすればよいか？」
私たちが発見したのは、当時の既存の浮動小数点ベースのエンベディングモデルでは、コストが途方もなく高くなることでした。これは消費者やビジネスの観点からは実現不可能なレベルでした。そのため、残念ながらこのプロジェクトを一時的に棚上げせざるを得ませんでした。
3月末から4月初めにかけて、バイトレベルとビットレベルのエンベディングが登場し始めたのを目にしました。それが会話のきっかけとなりました。その時点でAmazonとの対話を開始し、「何ができるか」を模索し始めました。それが今日に至るパートナーシップの始まりで、便利なことにバイナリエンベディングが利用可能になり、そのストーリーは説得力があり、意味的検索を実現可能にしました。
私たちのような法務ドキュメント管理企業が直面していた最大の課題は、膨大な量のドキュメント（100億以上）の意味的検索を実現するためのコストでした。法的文書は長く複雑で、精密な検索が必要です。しかし、従来の浮動小数点ベースのエンベディングでは、そのストレージコストが法外なものとなり、実用的ではありませんでした。バイナリエンベディングの登場が、この課題に対する解決の糸口となったのです。
4.2. エンベディングコストの内訳（生成コスト、クエリコスト、ストレージコスト）
Travis：エンベディングのコストについて話す前に、まずエンベディングの世界にコンテンツを移行するプロセスを考えてみましょう。10億のドキュメントがあるとしても、それは単なるテキストです。エンベディングを生成する必要があります。これが移行部分となります。もちろん、日々のコンテンツ追加（1日100万ドキュメントなど）に対してもコストを払い続ける必要がありますが、レガシーコンテンツの処理も必要です。
エンベディングのコストを考える際には、主に3つの要素があります：
第一に、エンベディングコンテンツのコストです。これは初期コストです。100億ドキュメントがあれば、一定の費用を支払う必要があります。
第二に、多くの人が忘れがちなのが、ユーザークエリのエンベディングコストです。「2020年のAcme社の取締役会のメンバーは誰か？」というようなクエリを投げる場合、そのテキスト文字列をそのままベクターDBに送ることはできません。テキストと数値表現は互換性がないからです。検索結果を得るためには、ユーザークエリをベクターDBに送る前にエンベディングする必要があります。
これは比較的安価です。「2020年のAcme社の取締役会のメンバーは誰か？」というクエリは10〜15語程度ですから。そのため非常に低コストですが、クエリの量によっては、年間を通じて確実に積み上がっていきます。
そして第三に、最も高価なのがベクターデータベースのコストです。初期コストを支払った後、それを保存する場所が必要です。そうしないと、エンベディングのために費用を支払っても、それがどこかに消えてしまい、再びすべてをエンベディングし直す必要が生じます。これは理想的なシナリオではありません。
これらの要素を考慮すると、エンベディングを実装する際には、初期の生成コスト、継続的なクエリコスト、そして長期的なストレージコストのバランスを取ることが重要です。特に大量のドキュメントを扱う場合、これらのコストはすぐに膨大なものになる可能性があります。
4.3. 従来の浮動小数点エンベディングのコスト試算
Travis：具体的なシナリオを設定して、従来の浮動小数点エンベディングのコストを計算してみましょう。まず、100億のドキュメントがあると仮定します。これらのドキュメントの平均テキストサイズは10キロバイトとします。そして、Miguelが先ほど言及したように、ドキュメントをチャンクに分割する必要があります。
非常に大きなテキストセットを設定して、それをチョッピングしたり極端な丸め処理をしたりすると、効果が低下する可能性があります。そのため、エンベディングに送信する前に、より小さな意味のある部分に分割して、最高の精度と最高のパフォーマンスを得る必要があります。
この場合、512トークンのチャンクサイズと25%のオーバーラップを設定します。これは、チャンキングとエンベディングを保存するための非常に標準的な方法です。この設定により、ドキュメントあたりの平均チャンク数は6になります。
それではこれが何を意味するのか見ていきましょう。Miguelが先ほど触れたように、1,000トークンあたりのコストを支払う必要があります。この場合は0.00002ドルです。これは便利なことに、ほとんどの浮動小数点モデルのコストとまさに同等です。他の浮動小数点モデルに詳しい方なら、これが非常に似ているとわかるでしょう。実はこれは大きな前進です。なぜなら、バイナリが最初に登場した時、コストは約5倍だったからです。
そこから、ドキュメント数に平均チャンク数をかけ、さらにチャンクサイズをかけると、総トークン数になります。大きな数字を扱う準備はできていますか？約31兆トークンです。これは非常に大きな数字ですが、幸いなことに1,000で割ることができます。これは我々にとって良いニュースです。
この計算を行うと、移行コストは614,000ドルであることがわかります。一部の項目が赤色で表示されているのは、なぜでしょうか？私たちはドキュメント管理会社です。サポート記事やその他のコンテンツを使用している場合でも、バージョンがあるでしょう。バージョン1、バージョン2、バージョンXを考慮すると、長期的に考慮する必要があります。最新バージョンのみを保存するのか、すべてのバージョンを保存するのかなど、それは特定のユースケースに基づいて決定されます。
同様に、先ほど言及したように、ユーザークエリがあります。これらも同じことで、エンベディングする必要があります。ユーザークエリが長いほど、またはボリュームが多いほど、コストが増加します。
そして、これは興味深いポイントですが、再エンベディングが必要になった場合はどうなるでしょうか？過去に浮動小数点モデルを使用したことがある方なら、そのサイズのベクターストアがあるかもしれません。Titanに移行したい場合、再エンベディングが必要です。特にビジネスリーダーや予算を立てる必要がある方が5年間の総所有コストを提案しようとする場合、3年目にTitan v3やTitan v4が登場し、精度が大幅に向上して採用するビジネスケースが説得力を持つ場合、それがどのような影響を与えるかを考慮する必要があります。
これらすべてが、エンベディングの初期生成に影響する要素です。これは参入するための初期コストです。しかし、注目すべきは、すでに614,000ドルを処理しましたが、まだこれらを保存していないということです。
では、保存コストという面白い部分に進みましょう。
4.4. バイナリエンベディングによるコスト削減効果
Travis：ここからが本当に面白い部分です。エンベディングの保存コストについて説明します。これこそがバイナリ形式が真価を発揮する領域です。私たちはディスクレベル、CPUレベル、メモリレベルで大幅なコスト削減を実現しました。これらすべての要素が組み合わさることで、より受け入れやすいユースケースとなります。
まず、同様のセットアップで初期条件を定義します。100億のドキュメント、各10キロバイトのテキストがあります。これは純粋にテキストであり、画像、動画、その他のコンテンツは考慮していません。単に10,000文字のテキストがあると仮定しています。
興味深いことに、浮動小数点形式が私たちにとって非常に高価だった理由は、ベクターデータベースに保存する際に、テキストに対する乗数効果があることがわかりました。生のテキストと関連するメタデータを処理し、浮動小数点でエンベディングに変換し、保存しようとすると、200キロバイトに増加しました。これは20倍の増加です。
これは単にストレージレベルに影響するだけでなく、これらの項目をメモリに保持する場合、メモリの大部分を占めることを意味します。しかし興味深いことに、バイナリ形式を採用すると、わずかな増加しか見られませんでした。私たちの特定のユースケースでは、その増加はメタデータに関連していました。特定の法的事件や法的案件に関連しているなどのメタデータがある場合、それは静的な値であり、変更することはできませんでした。
しかし、平均テキストサイズを40キロバイト、50キロバイト、60キロバイトに増やすと、乗数効果ではなく、1対1の比率よりも小さくなり始めることに気づきました。例えば、ファイルが60キロバイトのメタデータを考慮しても、インデックスストレージは50キロバイトだけになることがあります。つまり、バイナリエンベディングを使用することで、チャンクテキストをベクターDBに保存しない限り、1対1以下の関係が見られました。
これにより、大幅なコスト削減が実現しました。浮動小数点では20倍の増加があるのに対し、バイナリでは1.5倍の増加にとどまります。
具体的な数値を見てみましょう。100億のドキュメントが各10キロバイトの場合、これはほぼ2ペタバイトになります。どのベクターDB提供者を使用するにしても、ベンダーサービスでもOpenSearchでも、自分でホストするにしても、何らかのハードウェアが必要です。
この例では、EC2インスタンスで自己ホストする場合を選びました。I4g 4xlargeというストレージ最適化EC2インスタンスを選択しました。これは最もディスク容量の多いインスタンスの一つです。この選択理由は、あなたが見る数字がどれほど高くても、これが最も理想的なパスであり、実際の数字はおそらく異なり、より高くなる可能性が高いからです。
これは基本的に、1,900テラバイトを収容するために必要な最小限のストレージ最適化EC2インスタンス数です。その数は670インスタンスで、月額コストは45万ドル、つまり年間約540万ドルです。ベクターDBが最も高価な部分だと言ったとき、冗談ではありませんでした。
移行に60万ドルを支払いましたが、今後永続的に少なくとも540万ドルを支払う必要があります。これは非常に大きな金額です。さらに、年間20億または40億のドキュメントを追加するなら、この数字は実際に増加します。コンテンツの有効期限を設定しない場合、10年以上経過したドキュメントは削除されるといった保持ポリシーがない場合、その数字はさらに大きくなるでしょう。
しかし、これが最も理想的なパスであることを覚えていてください。このEC2インスタンスには3.4テラバイトの使用可能なストレージがあります。この場合、1,900テラバイトを満たすには670インスタンスが必要でした。しかし通常、ストレージはボトルネックではありません。ボトルネックは通常、CPUかメモリです。毎分多数のクエリがある場合、CPUコストが増加し、より多くのCPUが必要になります。結果をフィルタリングせず、「時間の始まりからのドキュメントが欲しい」と言うだけなら、ディスクにアクセスする必要がなく、キャッシュで利用できるようにするために、より多くのメモリが必要になります。
一方、バイナリエンベディングを使用した場合を見てみましょう。同じ条件で、ストレージは1,900テラバイトから140テラバイトに激減します。これは90%以上の削減です。Miguelが言及したように、バイナリ形式を活用すると、90%以上、96%、98%の削減が可能です。
同じI4g largeインスタンスを使用すると、必要なノード数は670から52に減少し、月額コストは45万ドルから36,000ドルに、年間では540万ドルから43万ドルに減少します。依然として理想的なパスではありますが、興味深いことがあります。670インスタンスがあり、それぞれ16 vCPUを搭載している場合、vCPUの総数は非常に大きくなります。
Miguelが先ほど示したように、メモリの量、パフォーマンス、その他すべてが同様に削減されています。以前は200キロバイトのメモリが必要でしたが、現在は15キロバイトです。つまり、メモリが少なくなっても、ギガバイトあたりのドキュメント数に基づいて、より広く活用できるようになります。
同様に、CPU使用の観点からも、小数点以下に多くの桁を持つ大きな数値文字列から、本質的に1または0に切り替えることで、計算の観点からもより効率的になります。つまり、インスタンスごとのCPUとメモリの両方を、浮動小数点を使用する場合よりも大幅に拡張できます。
同じ種類の注意点はありますが、私たちは「合理的な数字」と呼べるレベルまでコストを削減することができました。これを2倍、3倍にする必要があるかもしれませんが、それでも浮動小数点のための純粋なストレージよりも大幅に安価です。
4.5. 実験結果と実際の運用環境における考慮事項
Travis：ここまで多くの数字について話してきましたが、実際の運用環境では考慮すべき重要な点がいくつかあります。まず、これまでの分析は「最も理想的なパス」に基づいていることを認識すべきです。実際の環境では、パフォーマンスのボトルネックはストレージではなく、CPUやメモリであることが多いです。
例えば、1分あたりの高いクエリ数がある場合、CPUコストが増加し、より多くのCPUリソースが必要になります。結果をフィルタリングせず、「最初からすべての文書が欲しい」と言うだけなら、より多くのデータをキャッシュに保持する必要があり、メモリ要件が高くなります。
一方、結果を最初にフィルタリングする場合（例えば「最新の1年分のドキュメントだけを対象に検索したい」など）、検索対象を限定することで、メモリに保持する必要があるデータ量が減り、キャッシュミスの確率が下がり、ディスクアクセスの必要性が減ります。これによりメモリ設定を低く抑えることができます。
私たちの実際のユースケースでは、従来のレキシカル検索を実施し、そのボリュームを把握していました。しかし、意味的検索に移行すると、検索パターンが変わる可能性があります。クライアントとの対話から発見したのは、正確な単語を思い出すのに苦労しているということでした。レキシカル検索の課題の一つは、探しているドキュメントのほぼ正確な文言を覚えている必要があることです。法的文書では、特に100ページの契約書などでは、これは大きな挑戦です。
意味的検索を導入することで、実際には検索クエリが増加すると予想しています。ここで、もし私たちがCPUやメモリなどの十分なリソースを確保するために、ハードウェアを2倍、3倍、4倍に増やす必要があったり、ストレージ最適化からメモリ最適化、ベクター最適化、コンピュート最適化に移行する必要があれば、それは追加のコストになります。
例えば、I4g（Graviton2）は、R6gd（メモリ最適化マシン）で使用されるCPUと非常に類似しています。しかし、同等の4Xlargeサイズのこのメモリ最適化マシンのストレージは720GBしかありません。これは4.5倍少ないので、670インスタンスに4.5を掛けると、新しいインスタンスコストになります。
また、これは冗長性も考慮していません。クラスタリングに関連する25%のオーバーヘッドは考慮していますが、実際のクラスタ構成は複雑です。もちろん、私たちはすべてのクライアントに対して100億ドキュメントを持つ巨大なクラスタを用意しているわけではありません。特定の最大値までパーティション化し、複数のクラスタを使用しています。時には複数のクライアントが1つのクラスタを共有することもありますが、670インスタンスの単一クラスタになることは避けています。それは管理上の悪夢になるからです。
また、実験中に重要な発見をしたのは、バイナリエンベディングの性能を向上させるために、後ほどManishが説明するリランキングが有効だということです。例えば、バイナリエンベディングを使って上位100件の結果を取得するとします。しかし、チョッピングと極端なラウンディングを組み合わせると、上位200件を取得するかもしれません。そして、これらの結果をリランキングすることで、「63番目の結果が実際には14番目であるべき」または「17番目が実際には82番目であるべき」といった調整ができます。Manishが示すのは、このリランキングアプローチがどのようにバイナリエンベディングで失われた部分を取り戻し、浮動小数点の値に近づけるかということです。
これが実世界のケースの説明として役立つことを願っています。ここで示した数値は実際の数値から若干異なりますが、私たちが使用したテスト値に非常に近いものです。バイナリへの移行が、実際にスケールで意味的検索を実現可能にする上でいかに重要かを理解するのに役立つでしょう。
5. 実装アーキテクチャと最適化戦略
5.1. 基本的なバイナリエンベディングの実装アーキテクチャ
Manish：皆さん、声は聞こえていますか？ Travisが示した数字とバイナリエンベディングによるコスト削減効果は素晴らしいですね。これで私のスライドの解説へとうまく道筋が立ちました。
最も簡単な言葉で説明すると、先ほどの二人が紹介したものをAWS上でどのように構築するかについてです。ドキュメントの取り込み方法やアップロード方法など、一部の内容は省略しています。このセッションに関連する、テキストエンベディングの作成と検索方法に焦点を絞ります。
図の上部にあるのはAmazon S3で、最も安価なストレージシステムです。SDKコンソールまたは自動プロセスを使用して、SFTPを介してすべてのドキュメントをS3に取り込みます。ドキュメントがS3で利用可能になると、Titan V2エンベディングモデルを適用し、OpenSearch Serverlessストアに保存できます。
この場合、OpenSearch Serverlessストアを作成し、エンベディングをそのストアにプッシュすると、エンベディングの準備が整います。Travisはすでに様々なアプローチについて説明しましたが、このアーキテクチャを段階的に拡張して、さらなる改善方法を示します。
ユーザークエリが入ってきた場合、「今日の天気は？」というようなプロンプトやクエリに別のエンベディングモデルを適用し、そのバイナリエンベディングを使ってOpenSearchストアを検索します。この場合、上位5件、上位100件など、何らかの応答IDを受け取り、S3に戻ってドキュメントの該当部分を取得し、アプリケーションに渡します。
これが最もシンプルな形のダイアグラムで、実装方法を示しています。もちろん、バイナリエンベディングを使用することでTravisが説明したように多くのストレージコストを節約できますが、パフォーマンスと精度のいくらかを犠牲にしています。これをどのように取り戻すのか、次のステップで説明します。
5.2. 精度向上のためのリランキング手法
Manish：バイナリエンベディングを使用することでストレージコストを大幅に削減できますが、パフォーマンスと精度が若干低下します。では、このトレードオフをどう解決するか、リランキングを用いた手法をお見せします。
これが一つの方法です。ステップ1では、先ほどと同様に、S3に保存されているすべてのドキュメントにバイナリエンベディングモデルを適用し、その結果をElasticsearchやOpenSearchに保存します。この部分は最初の図と同じで、変更はありません。
ユーザークエリが入ってくると、エンベディングモデルを適用してエンベディングを作成し、Elasticsearchで検索して結果を得ます。上位100件のIDを取得しますが、Miguelが説明したように、同じ呼び出しで両方のタイプのエンベディングを適用することもできます。
このステップ2では、浮動小数点型とバイナリ型の両方のエンベディングを生成しています。両方のタイプのエンベディングを受け取り、その浮動小数点エンベディングをリランカーに送信します。ここで新しいコンポーネントであるリランクを導入しました。
このリランカーは、バイナリエンベディングIDと該当部分を上位100件取得し、さらに浮動小数点エンベディングも取得します。ここで、バイナリエンベディングIDと浮動小数点エンベディングの間でマッチングやコサイン類似度計算を行います。スコアが高いほどランクが低く、より良い結果が得られます。そして、リランキングされた上位5件の結果を取得し、S3からそのデータを取得します。
この方法では、浮動小数点とバイナリの両方のエンベディングを生成することで、ストレージコストを削減しながら、リランキングによって精度の面でも向上させています。ただし、この場合でも浮動小数点エンベディングをどこかに保存するか、アプリケーションプロセスのどこかに保存する必要があります。
Travis：これはまさに私たちが説明していたことです。バイナリエンベディングと精度に関して少し低下があったとしても、それを取り戻す方法があります。例えば、100件の結果の代わりに200件を検索し、リランキングを適用すれば、63番目のアイテムが実際には14番目であるべきだったり、その逆もあるということです。これにより、バイナリエンベディングによる精度の低下を補完することができます。
5.3. 浮動小数点と二進エンベディングの併用による最適化
Manish：さらに改良できるでしょうか？実はもう一つの方法があります。この解決策をさらに最適化した方法を紹介します。
この新しいアプローチでは、いくつかの追加コンポーネントを導入しています。基本的な流れは同じです。S3のドキュメントにバイナリエンベディングモデルを適用し、Elasticsearchに保存します。ユーザークエリが来ると、バイナリと浮動小数点の両方のエンベディングを作成します。バイナリエンベディングでElasticsearchを検索して上位IDを取得し、浮動小数点エンベディングをリランカーに送ります。
しかし、ステップ1で重要な追加ステップを導入しました。バイナリエンベディングを作成してElasticsearchに保存する際に、同時に浮動小数点エンベディングとテキスト部分をS3に保存します。これにより、ストレージコストが若干増加しますが、S3は安価なストレージなので、許容できるレベルです。
このアプローチの利点は、リランキング時に浮動小数点エンベディング同士を比較できることです。IDをリランカーに送信するとき、今度は浮動小数点対浮動小数点の比較が可能となり、精度がさらに向上します。
「なぜそもそもバイナリエンベディングに変換したのか？」と疑問に思うかもしれませんが、検索の主要部分とコストの大部分はElasticsearch内で発生します。バイナリエンベディングを適用して保存することで、ストレージコストを大幅に削減できました。しかし精度を向上させたい部分、つまりリランキングでは、浮動小数点対浮動小数点のエンベディング比較を利用して精度を高めています。
このように、両方の良い点を活かし、より良い結果を得ることができます。これをS3に送信し、結果を取得して利用可能にします。
この方法は一例です。DynamoDBなど他の選択肢もありますが、S3は最も安価なストレージであり、必要に応じてすべてのドキュメントを保存できます。
Travis：これは非常に重要なポイントです。私たちNetDocumentsが直面した課題の一つは、バイナリエンベディングを使用することで得られるコスト削減と、それによる精度の低下のバランスをどう取るかということでした。Manishが示したこのハイブリッドアプローチでは、検索の主要部分にはコスト効率の良いバイナリエンベディングを使用し、精度が重要なリランキング部分では浮動小数点エンベディングを活用します。これにより、コストを大幅に抑えながらも高い精度を維持できます。
実験の結果、この方法によって浮動小数点だけを使用した場合に近いパフォーマンスを実現しながら、ストレージコストを90%以上削減できることがわかりました。これは特に私たちのような数十億のドキュメントを扱う環境では、非常に大きな意義があります。
5.4. S3とOpenSearch Serverlessを活用した実装例
Manish：ここまでの説明を実装するための具体的なAWSアーキテクチャを見ていきましょう。最初の図で示したシンプルなアーキテクチャを基本として、各コンポーネントの連携方法を詳しく説明します。
上部にはAmazon S3があり、すべてのドキュメントがここに保存されます。SDKコンソールや自動プロセスを使ってSFTPでドキュメントをS3に取り込みます。S3に保存されたドキュメントに対して、Titan V2エンベディングモデルを適用し、その結果をOpenSearch Serverlessストアに保存します。
具体的には、OpenSearch Serverlessストアを作成し、バイナリエンベディングをそこにプッシュすると、検索可能なエンベディングが準備できます。このアプローチでは、バイナリエンベディングを使用することで、Travisが説明したように大幅なストレージコスト削減が実現できます。
ユーザークエリが入力されると、そのクエリに対してエンベディングモデルを適用し、OpenSearchで検索を実行します。検索結果として上位のドキュメントIDが返されたら、S3からそれらのドキュメントの関連部分を取得してアプリケーションに提供します。
精度向上のためのリランキングを導入する場合は、ユーザークエリに対してバイナリと浮動小数点の両方のエンベディングを生成します。バイナリエンベディングを使ってOpenSearchで検索し、結果のIDを取得します。同時に、S3には浮動小数点エンベディングも保存しておき、これらを使ってリランキングを行います。
この実装アーキテクチャの大きな利点は、主要なコスト要因であるOpenSearchでのストレージに最もコスト効率の良いバイナリエンベディングを使用し、精度が重要なリランキング部分では浮動小数点エンベディングを活用するという点です。S3は比較的安価なストレージなので、浮動小数点エンベディングを保存するのに適しています。
実装する際の重要なポイントは、バイナリエンベディングのインデックス作成時に最適なチャンキング戦略を選択することです。大きすぎるチャンクサイズや不適切なオーバーラップは精度に影響します。また、リランキングの実装では、検索結果の数（上位100件や200件など）を適切に調整することで、精度とパフォーマンスのバランスを取ることができます。
このアーキテクチャは特に大規模なドキュメントコレクションを持つ組織にとって、コスト効率と検索精度のバランスを取るための実用的なアプローチを提供します。
6. まとめと質疑応答
6.1. バイナリエンベディングの主要なメリット
Travis：ここで、これまでの内容をまとめてみましょう。浮動小数点エンベディングの場合、1,900テラバイトのストレージ、670インスタンス、年間540万ドルのコストが必要でした。一方、バイナリエンベディングでは、ストレージ量が大幅に少なく、必要なインスタンス数も大幅に少なく、そしてコストも大幅に低くなります。
これはあくまで一例ですが、自分に合った方法を見つけるためにはテストが必要です。Miguelの説明からわかるように、いくつかの異なる方法があります。次元数を減らすことでいくらか節約できますし、極端なラウンディングを行うだけでも節約できます。極端なラウンディングとチョッピングを組み合わせればさらに節約できます。あなたの精度ポイントがどこにあるか、何があなたに合理的かを見極めてください。
Manish：このプレゼンテーションを終えるにあたり、私たちが話し合った内容をまとめてみましょう。エンベディングの導入理由、エンベディングの概要、そしてTitan Embeddingsバージョン2モデルについて説明しました。このモデルは数週間前に発表されたばかりのバイナリエンベディングをサポートしています。
また、NetDocumentsの成功事例についても紹介しました。彼らはストレージコストを大幅に削減しながらも、顧客のための検索結果を向上させることができました。さらに、いくつかのアーキテクチャ図を通じて実装方法についても説明しました。
バイナリエンベディングの主要なメリットとして、最も重要なのはコスト削減効果です。Travisが示したように、年間540万ドルから43万ドルへと90%以上のコスト削減を実現しています。これは特に大規模なドキュメントセットを扱う組織にとって、意味的検索の実用的な導入を可能にします。
また、バイナリエンベディングはCPUとメモリの効率も向上させます。浮動小数点と比較して、計算とストレージの両面で効率的です。これにより、同じハードウェアでより多くのドキュメントを処理できるようになります。
さらに、リランキング技術と組み合わせることで、精度の低下を最小限に抑えることができます。実際、適切に設計されたシステムでは、浮動小数点エンベディングとほぼ同等の検索精度を維持しながら、大幅なコスト削減を実現できます。
最終的に、バイナリエンベディングは大規模RAGソリューションの実装を経済的に実現可能にする技術であり、現代の企業が膨大な量のドキュメントから価値を引き出すための重要なツールとなっています。
6.2. 導入時の注意点と推奨事項
Travis：自分のユースケースに合ったものを見つけることが重要です。テストを行う必要があり、実際にテストが必須です。Miguelの説明でわかるように、実装方法はいくつもあります。次元数を減らせば節約効果があります。極端なラウンディング（バイナリ化）だけでも節約できます。極端なラウンディングとチョッピングを組み合わせれば、さらに節約できます。
精度のポイントがどこにあるのか、あなたのケースに何が合理的かを見極める必要があります。私たちの場合、極端なラウンディングを行い、上位100件の結果を取得するとします。しかし、チョッピングと極端なラウンディングを組み合わせると、上位200件の結果を取得するかもしれません。これがManishが説明していたリランキングと関連します。
バイナリエンベディングによって精度が多少低下しても、結果をリランキングすることでその精度を取り戻すことができます。上位100件ではなく上位200件の結果を取得し、リランキングすることで「実は63番目の結果が14番目であるべき」「17番目の結果が実際には82番目であるべき」といった調整ができます。
Manishが示したのは、このリランキングアプローチが、バイナリエンベディングで失われた精度をどのように回復し、浮動小数点の値に近づけるかということです。
Manish：バイナリエンベディングを導入する際の重要な注意点として、まず適切なチャンクサイズとオーバーラップの設定が挙げられます。これらは検索精度に大きく影響します。大きすぎるチャンクや不適切なオーバーラップは精度低下の原因になります。
また、リランキングを実装する場合、初期検索での結果数（上位何件を取得するか）を慎重に検討する必要があります。バイナリエンベディングの精度がやや低いため、浮動小数点の場合よりも多めの結果を取得し、リランキングすることで精度を高めることができます。
さらに、S3に浮動小数点エンベディングを保存する際のコスト増加と精度向上のバランスを考慮してください。S3は比較的安価ですが、大量のドキュメントでは無視できないコストになることもあります。
導入初期は小規模な実験から始め、実際のデータと検索パターンに基づいて調整することをお勧めします。特に、リランキングのパラメータ調整は経験的に最適値を見つけることが多いです。
最後に、バイナリエンベディングによるコスト削減効果は大きいですが、システム全体のパフォーマンスモニタリングも忘れないでください。CPUやメモリの使用率、検索レイテンシなどを継続的に監視し、必要に応じて調整することが長期的な成功の鍵となります。
6.3. 今後の展望
Manish：このプレゼンテーションの締めくくりとして、バイナリエンベディングの将来性について触れたいと思います。私たちは今日、エンベディングの導入理由、エンベディングの基本概念、Titan Embeddingsバージョン2モデルについて説明しました。この最新モデルは、数週間前に発表されたばかりのバイナリエンベディングをサポートしています。
また、NetDocumentsの事例では、バイナリエンベディングがどのように顧客のための検索結果を向上させながら、ストレージコストを大幅に削減できたかを紹介しました。さらに、これを構築するためのアーキテクチャ図についても説明しました。
今後の展望としては、バイナリエンベディング技術はさらに発展していくでしょう。特に精度向上と処理速度の最適化が期待されます。現在のTitan V2モデルは素晴らしい出発点ですが、今後のバージョンでは精度とコストのバランスがさらに改善される可能性があります。
Travis：私たちNetDocumentsの観点からは、バイナリエンベディングの導入により、真のRAGベースのワークフローを日常業務の一部として提供できるようになりました。これにより、AIへのさらなる展開が大幅に容易になっています。
あなたの会社を考える際には、実際のコンテンツがどのようなものかを考えてみてください。これまでに取り込んだすべてのドキュメントを検索するのか、小さなナレッジベースだけを対象にするのか、あるいは「最新の1年分のドキュメントのみ」を検索するのか。これらはすべて考慮すべき要素ですが、バイナリエンベディングによるコスト削減効果（約90%）は非常に大きなメリットをもたらします。
将来的には、追加機能や新しいモデルの導入による性能向上、より多様な言語サポートの拡大などが期待されます。また、特にリランキング技術の進化により、バイナリエンベディングの精度がさらに向上する可能性もあります。
最終的には、今回紹介したコスト効率の良いRAGソリューションは、多くの組織にとって大規模な意味的検索と生成AIの統合を実現する道を開くものです。AWS re:Inventの今後のセッションでも、この分野のさらなる進化について取り上げられることでしょう。