RAGアプリケーションデザインにおける実用的な考慮事項

実用的な考慮事項 RAGアプリケーションデザインにおける重要なポイント

これはRAG分析の第2部です：

• パート1：RAGの欠点
• パート2：RAGアプリケーションデザインの実用的考慮事項

RAG（Retrieval Augmented Generation）アーキテクチャは、LLMの入力文字列長制限と知識の切り捨ての問題を克服するために効率的であることが証明されています。現在のLLM技術スタックでは、RAGはローカルな知識にアプリケーションを基礎づけ、幻想を緩和し、LLMアプリケーションを監査可能にするための基盤の一つです。RAGアプリケーションを構築する方法はたくさんあります。さまざまなタイプのベクトルデータベースもあります。

RAGアプリケーションのデモは簡単ですが、実際に製品化するのは難しいということを多くの人が気づいています。この記事では、RAGアプリケーション開発の実際的な詳細について見ていきましょう。

アジェンダ

• 「2Dから3Dへ：アラインドジオメトリックプライオリティを用いたテキストから3D生成の一貫性向上」
• オラクルは、AIとクラウドを基盤とした未来のビジョンを明らかにしました
• 「AIの透明性を解き放つ：Anthropicのフィーチャーグルーピングがニューラルネットワークの解釈可能性を向上させる方法」

・完璧なLLMベースライン・RAGの性能の期待・情報の保存・RAGの強みと弱点・より良いRAGアプリケーションに向けて ∘ LLMの処理 ∘ 埋め込みモデルを同じページに維持する ∘ チャンキング戦略の重要性 ∘ 情報の損失を減らす ∘ LLMの共感・結びの言葉・参考文献

完璧なLLMベースライン

入力文字列の長さに制限のない生成型LLMがあると仮定すると、入力文字列の長さは生成型LLMの正確性に影響しません。それ以外は他の人気のあるLLMとまったく同じ動作をします。このモデルを完璧なLLMと呼びます。これは卓越したパフォーマンスを持っているわけではなく、現実には不可能な無制限の入力文字列長を持っているため、完璧だと考えます。無制限の入力文字列長は非常に魅力的な機能です。実際には、非常に長い入力文字列を持つLLMを研究している野心的なプロジェクトもいくつかあります。その中の1つは、入力文字列が100万トークンのLLMの可能性を研究しています！しかし、それでもアプリケーションでは十分ではないかもしれません。なぜなら、それはまだ4〜5MBの大きさであり、実際のビジネスにおける大量のドキュメントよりも小さいからです。

さて、疑問です。完璧なLLMを持っていたとしても、RAGアーキテクチャを考える必要はあるでしょうか？無制限の入力文字列長を持つ完璧なLLMは、複雑なRAGの構築の必要性を減らします。ただし、おそらくは、RAGアーキテクチャを考慮する必要があります。RAGアーキテクチャは、LLMの入力文字列長制限を克服するだけでなく、LLM呼び出しのコストを削減し、処理速度を向上させるのに役立ちます。生成型LLMはコンテンツをシーケンスで処理する必要があります。入力が長いほど遅くなります。

私たちがRAGアプリケーションを設計する際、仮定された完璧なLLMをベースラインとして使用し、RAGアプリケーションを厳密に検証する必要があります。これにより、RAGの利点と欠点を明確に把握し、RAGアプリケーションを改善する方法を見つけることができます。

RAGのパフォーマンス期待値

ベースラインモデルとして、生成型AIアプリケーションの入力はLLMに直接フィードされます。これにより、LLMは入力テキストの情報をすべて消化する機会を得ます。最終結果の正確さは、生成型LLMのパフォーマンスにのみ依存します。

バニラRAGアプリケーションでは、最終パフォーマンスに影響を与える2つの要素があります。その要素は、意味的な検索方法とRAGの実装です。RAGアーキテクチャは埋め込みモデルを使用して、真実の知識とクエリのベクトルを生成し、ベクトルの類似性関数を使用して最も関連性のあるコンテンツを検索します。テキストから意味を抽出する埋め込みモデルの力は非常に重要です。埋め込みモデルに加えて、RAGの開発にはさまざまな実装の詳細もあり、これも最終結果に大きな影響を与えます。したがって、RAGの出力の正確さは、生成型LLMの正確さ、意味的検索の正確さ、およびRAG情報保存率の積に等しいです。後ほどRAG情報保存率の概念について説明します。

これらの3つの要素はすべて100％未満であるため、RAGアプリケーションの予測精度は完璧なLLMモデルを基にした同じアプリケーションよりも低くなります。RAGが適切に設計されていない場合、そのパフォーマンスは非常に大きく低下します。これは、RAGアプリケーションの設計を考え始めるときに心にとめておくべき最初の概念です。そうでなければ、予期しないパフォーマンスに驚かされることになります。

最終的なパフォーマンスはこれらの3つの要素によって駆動されるため、RAGアプリケーションの設計はすべての3つのコンポーネントを中心に据えて、満足のいく結果を得るために行われる必要があります。

情報の保存

LLMモデルと意味的検索の両方が100％の正確さを達成することはできないと理解するのは簡単です。RAG情報保存率とは何か説明しましょう。

アプリケーションにフィードするテキストコーパスには非常に豊富な情報が含まれていることは理解できます。コーパス内のエンティティの関係を以下のように示し、情報がLLMにどのようにフィードされるかを見てみましょう：

このチャートはテキストコーパス内のエンティティの関係を描いています。エンティティはコーパス全体に広がり、参照関係もどこにでも存在します。チャンキング後、エンティティは各シロに制約され、シャンク間の関係はすべて切断されます。検索フレーズでは、上位k個のシャンクのみがLLMを介して送信される機会を持ちます。つまり、エンティティと関係の一部しかLLMに転送されないことを意味します。LLMは、クエリに応答するために広範な関係知識を必要とする場合には困難が生じます。

エンティティの関係に加えて、チャンキング操作は入力のさまざまな他のタイプの情報にも影響を与えます：

1. 文脈情報：

ほとんどの場合、テキストには複数のレイヤーの文脈情報が含まれています。例えば、「The Elements of Statistical Learning」という本は18章あり、各章は単一のトピックに焦点を当てています。それぞれの章にはサブトピックや第2レベルサブトピックなどがあります。人々は文脈の中でテキストを理解することに慣れています。チャンキング戦略によって、コンテンツとその文脈が切り離されます。

2. 位置情報：

テキストはドキュメント内の位置に応じて重みが異なります。ドキュメントの先頭と末尾のテキストの重要性は、中間にあるテキストよりも高くなります。章の先頭や末尾にあるテキストは、章の中間にある場合よりも重要です。

3. 順序情報：

自然なテキストは、明示的および暗黙の言語的なつながりを使用してトピックを結び付けることがよくあります。たとえば、物語は「最初に」と始まり、それから「それから」、「したがって」、「その後」など、いくつかの接続詞で続きます。チャンキング戦略では、このようなつながりが完全ではありません。パズルが欠けているだけでなく、順序も入れ替わります。

4. 記述情報：

これは、1つの主題を説明する情報を指します。チャンキングでは、記述情報が一緒になることが保証されない場合があります。例えば、電話中に突然通話が切れるとします。通話がどれだけ重要か、それが起こった時期によって、影響の度合いは些細なものから非常にイライラするものまで様々です。

RAGの強みと弱点

チャンキングとベクトルの類似検索のみを使用するRAGを「バニラRAG」と呼ぶと、前述の入力情報の一部が失われるため、RAGは一部の種類のクエリのみを処理できることがわかります。具体的には以下のようなものです：1. 狭い範囲の記述型質問応答に優れています。例えば、どの主題が特定の特徴を持っているかなど。

2. 関係推論には向いていません。つまり、エンティティAからエンティティBへのパスを見つけたり、エンティティのクリークを特定したりすることができません。

3. 長距離要約には適していません。例えば、「ハリー・ポッターの戦いをすべてリストする」や、「ハリー・ポッターは何回戦ったか」といったものです。

RAGアプリケーションは、これらのタスクに対してパフォーマンスが低いです。なぜなら、LLMにはわずかなチャンクしか与えることができず、これらのチャンクは散らばっているからです。LLMは必要な情報を収集して開始することが不可能です。

RAGアプリケーションは主に生成型LLMと組み合わせて使用されますが、これによりRAGアプリケーションは完璧なLLMアプリケーションと同等の高レベルの推論能力を持つという印象を与えます。しかし、LLMは完璧なモデルと比較して十分な入力を持っていないため、RAGアプリケーションは同じレベルの推論能力を持ちません。入力情報の制限についての認識は、RAGが何ができるか、できないかを理解するのに役立ちます。RAGに最適なフィールドを探し、間違った場所に強制的に配置するのを避けるべきです。

より良いRAGアプリケーションへ

RAGアプリケーションの制限について説明しましたが、どのように性能を向上させることができるかを見てみましょう。

LLMの扱い方

多くの場合、入力クエリを扱う際には、ユーザーが送信したものをそのまま受け入れる傾向があります。これは理想的ではありません。プロンプトの漏洩やプロンプトの不正挿入などのセキュリティリスクだけでなく、性能も期待できないからです。

研究者によると、LLMはプロンプトの誤りや表現の違いに敏感です[1]。LLMが最高のパフォーマンスで実行されることを確認するためには、すべての誤りを修正し、入力をLLMが追いやすい形に言い換えることを考慮してください。

埋め込みモデルを同じページに保つ

ほとんどの場合、ユーザーは「トニー・アボットについてもっと教えて」といった短いクエリを送信します。そのクエリは、その特定のクエリの本質を捉えた埋め込みベクトルに変換されます。直接クエリで意味検索を行うことは難しいです。なぜなら：

1. ユーザークエリは短く、質問形式です。制約された意味的な特徴を持っています。一方、ドキュメントの埋め込みは、さまざまな形式の文や表現で長く、ベクトルには豊富な情報が含まれています。
2. ユーザークエリの制約された意味的な特徴のため、意味検索機能はクエリの些細な詳細を過剰に解釈しやすくなります。ドキュメントの埋め込みにはノイズが多く含まれる可能性があります。チャンキングは、関係や文脈、シーケンシャルなつながりの多くを欠落させるため、状況をさらに悪化させます。
3. 埋め込みモデルと生成型LLMは異なるモデルです。それらは異なる方法で訓練され、振る舞いも異なります。埋め込みモデルは生成型LLMほどの推論能力を持っていません。生成型LLMほど言語的な詳細を尊重しません。ユーザー入力で直接検索する場合、最悪の場合では、意味検索機能はキーワード検索に出力を減らします。
4. 埋め込みモデルと生成型LLMは、全体のプロセスで異なる役割を果たす2つの異なるモデルです。彼らは独自の理解に基づいて各自の仕事をしますが、互いとコミュニケーションする手段を持っていません。取得される情報はLLMが最良の結果を出すために必要なものであるとは限りません。これらの2つのモデルは互いと合わせる方法を持っていません。

この問題を回避するためには、まずユーザーのクエリを増強するために生成的なLLMを使うことがおそらく必要です。以下の例を考えてみてください：

元のユーザークエリ：Tony Abbottについて教えてください。

そして、元のクエリをベースに再表現された増強クエリ（Bardを使用）：

– Tony Abbottの政治的背景は何ですか？

– Tony Abbottの最も注目すべき業績は何ですか？

– Tony Abbottの政治的見解は何ですか？

– Tony Abbottの個人的な興味は何ですか？

– Tony Abbottが関与しているいくつかの論争は何ですか？

改善された情報の豊かさがわかりますか？増強クエリはより多くの機能を提供するため、より良い検索結果を生み出します。さらに、増強クエリを送信することにより、LLMは埋め込みモデルに必要な情報を伝える機会を得て、埋め込みモデルはLLMに高品質なチャンクを提供するのをより良く行えるようになるのです。これが2つのモデルが協力する方法です。

チャンキング戦略の重要性

チャンクサイズは、RAGアプリケーションにおいて調整できる数少ないスーパーパラメータの1つです。より良い結果を得るためには、より小さなチャンクサイズを使用することが推奨されています。Microsoftの分析によれば、次のようなものがあります[2]：

テキストを分割する際に、異なる分割戦略を選択することもできます。最も単純な方法は単語の区切りで切り取ることです。また、文や段落の区切りで切り取るなど、異なる戦略を試すこともできます。さらに良い結果を得るためには、隣接するチャンクをオーバーラップさせることもできます。Microsoftの分析によると、異なるチャンキング戦略の比較は次のようになります[2]：

埋め込みモデルは、意味の抽出能力に限界があります。複数のトピックや複数のターンのコーパスを提示する際には、単純なモデルよりも効果が薄いです。そのため、RAGはより短いチャンクを好みます。では、最適なチャンクサイズは何でしょうか？Microsoftの分析では、最も小さなチャンクサイズは512トークンでした。より小さなチャンクがより良い結果をもたらすという発見に触発されたものでしょう。一部の商用RAGアプリケーションでは、チャンクサイズがわずか100トークン程度でした。最も小さなチャンクサイズが常により良い結果を生み出すのでしょうか？

既に述べたように、チャンキング戦略によりテキストコーパスが小さな部分に分かれるため、情報が失われます。チャンクサイズが小さいほど、より多くの情報が失われます。そのため、最適なチャンクサイズが存在します。あまりにも小さいチャンクは理想的ではないかもしれません。ただし、最適なチャンクサイズを求めることは、スーパーパラメータの調整と同様です。データを実験する必要があります。

情報の損失を減らす

Microsoftの分析では、重なり具合が多いチャンキングが精度を向上させることがわかりました。なぜそれが助けになるのでしょうか？また、RAGのパフォーマンスをさらに向上させるためのより良い方法を見つけることはできるのでしょうか？

重なりの背後にある理由は、重なりが隣接するチャンクを結びつけ、チャンクに対してより良い文脈情報を提供することができるからです。ただし、非常に攻撃的な25%の重なりでも、精度を42.4%から43.9%に向上させることしかできません。つまり、これはRAGパフォーマンスを最適化する最も効率的な方法ではありません。さらなる向上を重ねることはできません。重なりチャンキングは、小さなチャンクには選択肢ではありません。

重なり具合を含めたチャンキング戦略が示唆するとおり、情報を保持することでLLMがより良い応答を行えるようになります。入力情報をできるだけ保存する方法は何でしょうか？

オーバーラップチャンキング戦略は、前のチャンクの直近のいくつかの文がより多くの文脈情報を提供してくれることを期待していました。そして私たちは理解できるように、直近のいくつかの文は非常に代表的ではないかもしれません。オーバーラップの代わりに、前のチャンクのLLMによって生成された要約を使用することもできるかもしれません。

そして、入力テキストには複数のレイヤーの文脈情報があることを覚えておいてください。それがあなたのアプリケーションの場合、レイヤー化された文脈情報をチャンクに先だって追加したいかもしれません。または、より効率的な方法は文脈情報をメタデータとして保存することかもしれません。

ナレッジグラフを使用したRAGは現在トレンドです。ナレッジグラフの助けを借りて、RAGは関係をグラフデータベースに保存することができます。チャンク間のつながりは完全に保持されます。それは、リレーションシップの推論がプロジェクトにとって重要な要素である場合、非常に考慮すべき解決策です。

ただし、ナレッジグラフを使用したRAGには課題があります。非構造化テキストからナレッジグラフを構築することは容易ではありません。テキストの入力からエンティティ-リレーションシップの三つ組を抽出する実験がかなりあります。ソリューションを実際に展開する場合は異なる話です。自動的に抽出されたエンティティとリレーションシップには多くのノイズが含まれており、実際の情報が不足していることがあります。出力の品質を非常に注意深く検査する必要があります。ナレッジグラフのポピュレーションの後でも、サポートされるクエリはグラフデータベースの設計と密接に結びついています。

ナレッジグラフと同様に派手ではありませんが、ベクトル検索が可能なリレーショナルデータベースもツールボックスの非常に重要なコンポーネントです。pgvectorのようなデータベースは、セマンティック検索機能を保持しながら複雑な情報を列として格納することができます。他のエンタープライズシステムとの統合が容易であり、ナレッジグラフよりも柔軟です。

これらはすべて検討すべき有効なオプションです。ただし、多くのベクトル有効化のグラフデータベース、検索エンジン、およびリレーショナルデータベースは、ベクトルデータベースとして完全に最適化されていないことにご注意ください。特に頻繁にインデックスを更新する必要がある場合、非常に大規模なベクトルインデックスを処理する際の速度は理想的ではない可能性があります。異なるタイプのベクトルストアへの紹介の詳細については、[3]をご覧ください。

LLMエンパシー

時には、RAGは質問に対して十分に適切な回答をしてくれません。パフォーマンスを向上させるためにすべてのツマミを回す代わりに、次のような質問を考慮する必要があります：

• LLMは必要な情報をすべて持っていますか？
• 情報はLLMに適した方法で組織されていますか？

以下の例を考えてみましょう：

私たちはSharePointのウェブサイト上でRAGアプリケーションを構築しています。ウェブページの1つはすべてのプロジェクトとそのチームメンバーについてで、すべての人々のプロフィールを含んでいます。私たちは、RAGがプロジェクトとチームメンバーの質問に正確に答えることを確認する必要がありますが、初期の結果は非常に失望的でした。

初期の調査では、SharePointのウェブサイトが情報の所属関係が簡単に理解できるように構造化されていないことがわかりました。すべてのHTMLタグを削除した後、ウェブページのコンテンツは次のようになります：

project Aクライアント連絡先：Steveチームメンバー：person Aperson Bperson Aの電子メールperson Bの電子メールperson Aの役割person Bの役割person Aの説明person Bの説明project B...

人間が誰が誰かを理解するのが混乱する場合、RAGも苦労します。情報をより適切に整理するために、Pythonコードを使用して情報をHTMLプロパティに従って集約し、プロジェクトごとにチームメンバーの名前を単一のテキストファイルに分割し、各人の情報を独自のファイルに入れました：

file project_A.txt：プロジェクト名：project_Aクライアント連絡先：Steveチームメンバー：Adam SmithJobs Muskfile person_A.txt：名前：Adam Smith電子メール：[email protected]役割：エンジニア説明：趣味/情熱：ロッククライミング...

生成されたテキストファイルは非常に小さいですが、RAGのチャンキングの実践とは一致していないように思われます。その理由は、非常に凝縮されたファイルが分割の問題を回避し、ノイズを完全に減少させたからです。新しく生成されたファイルでは、「プロジェクトxに取り組んでいるのは誰ですか？」や「Adam Smithの趣味は何ですか？」のような質問にRAGは問題ありません。

ただし、質問を逆にするとRAGは苦労しました。「Adam Smithはどのプロジェクトに取り組んでいますか？」という質問を反転させると、Adam Smithがプロジェクトメンバーの中にリストされているのを見ました。埋め込みモデルがそれを捉えることができない理由はあまりわかりません。LLMが仕事をうまくこなすのを助けるために、情報を際立たせることができます。人物のファイルに明示的にプロジェクトの関与を示す行を追加しました：

file person_A.txt：名前：Adam Smith電子メール：[email protected]役割：エンジニア説明：趣味/情熱：ロッククライミングプロジェクト：project_A

この追加の行により、RAGアプリケーションは上記の質問に100％正確に答えることができます。

結言

新興技術であるRAGは急速に進化しています。私はそのビルディングブロックを一つずつ調査することで、それが私に多くの助けになることを見つけました。詳細を見ることで、その技術の長所と短所についてより深い洞察を得ることができ、新しい提案がどれだけ重要かを考えることができます。RAGアプリケーションの開発を支援するいくつかの非常に人気のあるフレームワークがあります。いくつかの実装アイデアは私にインスピレーションを与えましたが、単に始めやすいという理由だけでRAGを学ぶか開発することはおすすめしません。

これまでこの記事を読み進めてきたなら、RAGが複雑なアーキテクチャであることに同意する必要があるでしょう。人気のあるフレームワークはすべての詳細をまとめてしまい、詳細が重要でないと思わせました。私の提案は、ベアボーンのRAGを学び、その後に追加の機能を考慮することです。そのような最小限のRAGでどのように機能するかを分析することで、本質と各パーツの影響を知ることができます。そんな最小限のRAGを使って始めることはそれほど難しくありません。以下の記事をご覧ください：RAGのデメリット。

参考文献

プロンプトの頑健性：測定方法と向上方法

LLMプロンプトの頑健性、測定、向上、およびPromptBenchの使用に関する議論。

pub.towardsai.net

Azure Cognitive Search：ハイブリッド検索とランキング機能によるベクトル検索の超越

あなたの生成AIモデルに最適なコンテンツをどのように見つけますか？このブログ記事ではAzureの使用方法を紹介します…

techcommunity.microsoft.com

ベクトルデータベースを導入する前に知るべきこと

適用可能な生成AIに向けた私たちの旅を続けるには、いくつかの課題について議論したいと思います…

VoAGI.com

RAGのデメリット

最近、大型言語モデル（LLM）の台頭により、RAGシステムへの関心が高まっています。多くの実践者が…

VoAGI.com

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!