リトリーバル・オーグメンテッド・ジェネレーションにおける関連性の課題にどのように対処するか

リトリーバル・オーグメンテッド・ジェネレーションにおける関連性の課題への対処法

関連するコンテキストを取得して大規模な言語モデルに提供するプロンプトに含めるために、ベクトルデータベースに依存するRAG実装のトラブルシューティングを解説します。

このプロセスを2つの主要なパートに分けます。最初のパートは、埋め込みパイプラインです。このシリーズの最初の記事で取り上げますが、埋め込みパイプラインはベクトルデータベースに埋め込みを追加します。

ここでは、下記の3つの主要な要素が結果の質を下げる可能性があることを考慮します。最適でない埋め込みモデル、非効率なチャンキング戦略、およびメタデータのフィルタリングの欠如です。 (次の記事では、LLMとの実際の相互作用と、悪い結果につながる一般的な問題を見ていきます)

適切な埋め込みモデルの選択

埋め込みモデルの選択は、RAGアプリケーションの全体的な関連性と使いやすさに重要な影響を及ぼします。そのため、各モデルの能力について微妙な理解が必要であり、それらの能力がアプリケーションの要件とどのように一致するかを分析する必要があります。

• VoAGIニュース、12月6日：機械学習をマスターするためのGitHubリポジトリ•データエンジニアリングをマスターするための5つの無料コース
• 少ないデータ注釈 + より多くのAI = 深いアクティブラーニング
• 新しいLAMPスタック：生成AI開発の革新を照らす

RAGと埋め込みについて比較的新しいのであれば、知っておくべき最良のリソースの1つは、Massive Text Embedding Benchmark (MTEB)の埋め込みリーダーボードです。この記事では取得の使用例に焦点を当てていますが、埋め込みはもちろん、分類、クラスタリング、要約など他の多くの応用にも使用できます。リーダーボードは、特定のケースに最適なモデルを特定するのに役立ちます。

RAGのパフォーマンスが悪い最も一般的な理由の1つは、この分野が初めての開発者が埋め込みの生成例を検索してしまい、Word2VecやsBERT、RoBERTaなどの埋め込みモデルを使用したサンプルを見つけることです。これらのモデルは取得の使用例には適していません。この記事で検索結果の関連性が低いためにデバッグしている場合、sBERTのようなものを使用して埋め込みを生成した可能性が高いため、関連性の問題の原因が特定された可能性があります。

その場合、次の質問はおそらく埋め込みモデルを使用して類似性検索結果を改善する方法です。あなたのケースの詳細を把握していないため、おすすめする3つのモデルは次のとおりです:

1. text-embedding-ada-002 (Ada v2)

OpenAIのAda v2は、多くの開発者がOpen AIのAPIを使って始めるため、おそらく多くのRAGアプリケーションの最初の選択肢です。Ada v2は取得の使用例で優れた性能を発揮し、テキストやコードを含むさまざまなタイプのコンテンツを処理するように設計されています。最大の入力シーケンス長は8,192トークンまで許容されているため、代替モデルよりもはるかに長いテキストの埋め込みを作成することができます。これは利点と欠点の両方です。大規模なシーケンスサイズを持つことで、テキストコンテンツの埋め込み作成プロセスが簡素化され、埋め込みモデルがより大きなテキスト本文の単語や文章間の関係を特定することができます。

ただし、コンテキストの生成を支援するために関連するチャンクを探している場合に、2つの長いドキュメントの類似性を比較するためには、よりぼやけた類似検索結果が得られるかもしれません。

Ada v2の2つの大きな欠点があります。まず、ローカルで実行できません。埋め込みの作成にOpenAIのAPIを使用する必要があります。これは多くのコンテンツの埋め込みを作成したい場合にボトルネックを作り出すだけでなく、1,000トークンごとに0.0001ドルのコストも発生させます。2つ目は、Open AIモデルから作成された埋め込みはそれぞれ1,536次元です。クラウドベクターデータベースを使用している場合、これはベクトルストレージコストをかなり増やすことができます。

選択するタイミング: API呼び出しのみを必要とするシンプルなソリューションが必要であり、大きなドキュメントをベクトル化する必要があり、コストが問題ではない場合

2. jina-embeddings-v2 (Jina v2)

Jina v2は、Ada v2と同じ8,000の入力シーケンスサポートを提供する新しいオープンソースの埋め込みモデルであり、取得の使用例でわずかに優れたスコアを獲得します。

Jina v2は、Ada v2の問題に対する解決策を提供します。Apache License 2.0でオープンソースであり、ローカルで実行することができますが、もちろん、これを行うために独自のコードを実行することが必要な場合もあります。また、Ada v2と比べて埋め込みベクトルの次元数が半分になります。そのため、ベクターデータベースの観点から見て、ベンチマークの使用例でわずかに優れたパフォーマンスを確保するだけでなく、ストレージと計算量の要件も低減されます。

いつ選ぶべきか：オープンソースのソリューションを使用したい場合で、大量のドキュメントをベクトル化する必要があり、埋め込みパイプラインをローカルで実行するのに慣れている場合。低次元の埋め込みによるベクターデータベースのコスト削減を望んでいます。

3. bge-large-en-v1.5

bge-large-en-v1.5 は、MITライセンスのオープンソースです。現在、MTEBリーダーボードの検索用途で最も評価の高い埋め込みモデルです。入力シーケンスが小さい場合、チャンキング戦略についてより考える必要がありますが、検索用途において最も優れたパフォーマンスを提供します。

いつ選ぶべきか：オープンソースのソリューションを使用したい場合で、入力サイズ制限内に留まるためにチャンキング戦略により多くの時間を費やすことができる場合。埋め込みパイプラインをローカルで実行するのに慣れている場合。検索用途において最も優れた埋め込みモデルを求めています。

本記事の範囲外ですが、MTEBリーダーボードの15のベンチマークを詳しく調べることで、自分の状況に最も近いものを特定することができます。さまざまな埋め込みモデルのパフォーマンスには明確な傾向がありますが、それぞれに特色のあるモデルもあります。埋め込みの選択をさらに絞り込む必要がある場合は、これがさらなる調査の可能な領域です。

チャンキング戦略の最適化

入力テキストのセグメンテーションまたは「チャンキング」は、生成された出力の関連性と正確性に重大な影響を与える要素です。さまざまなチャンキング戦略は独自の利点を提供し、特定のタスクに適しています。以下ではこれらの手法について詳しく説明し、その適用に関するガイドラインを提供します。

固定長チャンキング

• 使用するタイミング：コンテンツ自体が非常に構造化され、固定長である場合を除き、通常は以下に続くより有用なチャンキング戦略を利用することをお勧めします。
• 技術的な考慮事項：実装が非常に簡単ですが、このチャンキング戦略は一般的にRAGアプリケーションでの結果が悪くなる傾向があります。
• 追加の洞察：RAGアプリケーションで固定長戦略を使用し、関連するコンテキストの取得に問題がある場合は、異なるチャンキングアプローチに切り替えることを検討すべきです。

文章レベルのチャンキング

• 使用するタイミング：各文が意味と文脈で豊かである場合にこの戦略が効果的です。これにより、モデルはそれぞれの文内の複雑さに集中し、より一貫性のある文脈に即した応答を生成することができます。RAGの使用用途においては、通常は文章レベルのチャンキングには頼らないでしょう。
• 技術的な考慮事項：文章レベルのチャンキングは、自然言語処理（NLP）ライブラリを使用して文の境界に基づいてトークン化することがよく行われます。
• 追加の洞察：文レベルのチャンキングは、特定の文を検索する場合に特に有用です。例えば、会議の議事録などで特定の文に類似した文を検索しようとしている場合に役立ちます。

段落レベルのチャンキング

• 使用するタイミング：入力テキストが個別のセクションや段落に編成されており、それぞれが独立したアイデアやトピックを示す場合は、この戦略を使用します。これにより、モデルは各段落内の関連情報に焦点を当てることができます。
• 技術的な考慮事項：段落の境界を特定するには、改行文字やその他の区切り文字を検出する必要があります。
• 追加の洞察：段落レベルのチャンキングは、同じトピックのさまざまな側面をカバーするドキュメントがある場合に便利です。たとえば、製品のドキュメンテーションのページでは、製品の機能を紹介し、それを使用するタイミングを説明し、構成方法について説明し、異なる構成の例を示すことがあります。段落レベルのチャンキングを使用すると、LLMにコンテキストとして提供するドキュメントの最も関連性の高い部分を特定するのに役立ちます。

コンテンツに注意したチャンキング

• 使用するタイミング：テキスト内の特定のセクションの関連性が重要な場合に、この戦略を選択してください。たとえば、法的文書では、節やセクションに基づいてテキストをセグメント化することで、より特定の文脈に即した応答を得ることができます。
• 技術的な考慮事項：このアプローチでは、テキスト内の意味的な境界を理解するために高度なNLP技術が必要な場合があります。
• 追加の洞察：コンテンツに注意したチャンキングは、構造化または半構造化データを扱う場合に特に有用です。特定のチャンクはメタデータフィルタリングと組み合わせることで、より精確な検索に役立ちます。たとえば、法的文書では、保証または免責条項の抽出が必要な場合があります。また、チャンクの埋め込みをベクターデータベースに保存する際には、RAGの使用用途を構築する際に特定のタイプのコンテンツを検索しやすくするためにメタデータを使用できます。

再帰的なチャンキング

• 使用時期：再帰的なチャンキングは、階層的なアプローチを使用してデータをますます小さな断片に分割します。例えば、テキスト文書をチャンキングする場合、まずは段落に分割し、次に文に分割し、最後に単語に分割するかもしれません。データが最初のセットのチャンクに分割されたら、その小さなチャンクのそれぞれに再帰的にチャンキングプロセスを適用し、興味のある最小のチャンクサイズに達するまで繰り返します。
• 技術的な考慮事項：再帰的なチャンキングの実装には、追加の基準に基づいてチャンクをさらに細かく分割する多段階の解析戦略が含まれる場合があります。もしLangChainを使用している場合、その再帰的な実装はここで説明されているものよりも少しシンプルです。
• 追加の洞察：このアプローチによって、モデルは高レベルのテーマから詳細なニュアンスまで、複雑な文書（学術論文や技術マニュアル、法的契約など）のコンテキストを理解することができます。これは、類似性検索が広範なクエリに対してもより具体的なテキストを特定することができるため、柔軟性の利点をもたらします。ただし、このアプローチは、テキスト分割構成でのチャンク間の重複を選択する場合、同じソース文書からの類似したチャンクが類似性検索で過剰に表示される可能性もあることに注意が必要です。

一般的なアプローチとして、大きなコーパスをチャンク化してベクトル化する前に、データをいくつかのアドホック実験によって評価することを検討する必要があります。特定のクエリで取得したい文書を手動で確認し、LLMに提供する理想的なコンテキストを表すチャンクを特定し、それぞれのチャンキング戦略を試して、LLMが最も関連性の高いチャンクを提供するかどうかを確認することです。

コンテキストウィンドウの考慮事項

LLMの利用可能なコンテキストウィンドウは、チャンキング戦略を選択する上で重要な要素です。コンテキストウィンドウが小さい場合、モデルに組み込むチャンクをより選択的にする必要があり、関連性の高い情報が含まれるようにします。逆に、より大きなコンテキストウィンドウは、追加のコンテキストを含めることができるため、柔軟性があります。その追加のコンテキストが必須ではない場合でも、モデルの出力を向上させることができます。

これらのチャンキング戦略を実験し、これらの考慮事項を考慮に入れることで、生成される出力の関連性を評価できます。重要なことは、選択した戦略をRAGアプリケーションの特定の要件に合わせ、入力の意味的な統合性を維持し、コンテキストの包括的な理解を提供することです。これにより、最適なパフォーマンスのための適切なチャンキングプロセスを見つけることができます。

メタデータフィルタリング

検索インデックスの埋め込み数が増えるにつれて、関連するコンテキストを見つける際に類似最近傍法（ANN）はあまり役に立たなくなります。例えば、ナレッジベースに200の記事の埋め込みをインデックス化しているとしましょう。もし精度1%でトップの最近傍法を特定できる場合、それは200記事のうち上位2つの記事を見つけることができるため、かなり関連性の高い結果を得ることができます。

さて、ウィキペディアの全記事を含む検索インデックスを考えてみましょう。およそ670万の記事になります。もし最近傍法が最も類似した記事の上位1%に存在する場合、あなたは上位67,000の最も類似した記事の1つを取得できることになります。ウィキペディアのようなコーパスでは、まだターゲットからかなり遠くになる可能性があります。

メタデータフィルタリングは、ドキュメントを最初にフィルタリングし、その後に最近傍法アルゴリズムを適用することで、コンテンツの一部を絞り込む方法を提供します。多数の可能な一致候補と取り組む場合、この初期のプリフィルタリングは、最近傍法を取得する前に選択肢を絞り込むのに役立ちます。

次に、LLMとの相互作用について詳しく掘り下げ、結果の悪化につながる一般的な問題を調査します。

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