さらに関連性のある LLM 応答が必要ですか?これらの検索拡張生成の課題に対処する (パート 1)

この 2 部構成シリーズの第 1 回では、最適ではない埋め込みモデル、非効率なチャンキング戦略、メタデータ フィルタリングの欠如によって、LLM から適切な応答を取得することがどのように困難になるかを見ていきます。これらの課題を克服する方法を次に示します。

を使用する生成 AI アプリケーションを構築する検索拡張生成(RAG) は多くの課題を引き起こす可能性があります。ベクトル データベースに依存して関連するコンテキストを取得し、大規模な言語モデルへのプロンプトに含めて、より関連性の高い結果を提供する RAG 実装のトラブルシューティングを見てみましょう。

このプロセスを 2 つの主要な部分に分けて説明します。 1 つ目は、このシリーズの最初の記事で説明する埋め込みパイプラインです。ベクトルデータベース埋め込みあり:

ここでは、不十分な結果につながる可能性のある 3 つの主な領域、つまり最適ではない埋め込みモデル、非効率的なチャンキング戦略、メタデータ フィルタリングの欠如について検討します。 (次の記事では、LLM との実際のやり取りを見て、そこで発生し、悪い結果につながる可能性のあるいくつかの一般的な問題を検討します。)

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

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

RAG と埋め込み全般に比較的慣れていない場合は、知っておくべき最良のリソースの 1 つが次のとおりです。 MTEB (Massive Text Embedding Benchmark) 埋め込みリーダーボード。この記事では検索のユースケースに焦点を当てていますが、もちろん、埋め込みは分類、クラスタリング、要約などの他の多くのアプリケーションにも使用できます。

リーダーボードは、特定のユースケースで最適なパフォーマンスを発揮するモデルを特定するのに役立ちます。

RAG のパフォーマンスが低下する最も一般的な理由の 1 つは、この分野を初めて使用する開発者が埋め込み生成の例を見つけるために Google 検索を行うことです。 Word2Vec、sBERT、RoBERTa などの埋め込みモデルを使用するサンプルは、検索のユースケースには不適切な選択肢であることがよくあります。

不適切な関連性の結果をデバッグしていて、sBERT などを使用して埋め込みを生成したためにこの記事を見つけた場合は、おそらく関連性の問題の原因が特定されています。

その場合、次に疑問になるのは、類似性検索結果を改善するためにどの埋め込みモデルを使用できるかということです。ユースケースの詳細がわからない場合は、次の 3 つをお勧めします。

テキスト埋め込み-ada-002 (Ada v2)

OpenAI の Ada v2非常に多くの開発者が Open AI の API から始めるため、おそらくこれがほとんどの RAG アプリケーションにとって最も一般的な開始点となります。 Ada v2 は、検索ユースケースで見事にパフォーマンスを発揮し、テキストやコードなど、さまざまな種類のコンテンツを処理できるように構築されています。

入力シーケンスの最大長が最大 8,192 トークンであるため、代替モデルよりもはるかに長いテキストの埋め込みを作成することもできます。これは祝福でもあり呪いでもあります。

シーケンス サイズが大きいと、より多くのテキスト コンテンツの埋め込みを作成するプロセスが簡素化され、埋め込みモデルがより大きなテキスト本文内の単語や文間の関係を識別できるようになります。

ただし、これにより、生成プロセスを容易にするために探しているものが関連するコンテキストの塊である場合に、2 つの長い文書の類似性を比較する際に、類似性検索がよりあいまいになる可能性があります。

Ada v2 には 2 つの大きな欠点があります。 1つ目は、ローカルで実行できないことです。埋め込みを作成するには、OpenAI の API を使用する必要があります。これは、多くのコンテンツの埋め込みを作成する場合にボトルネックを引き起こす可能性があるだけでなく、1,000 トークンあたり 0.0001 ドルのコストも追加されます。

2 つ目は、Open AI モデルから作成されたエンベディングがそれぞれ 1,536 次元であることです。クラウド ベクトル データベースを使用している場合、ベクトル ストレージのコストが大幅に増加する可能性があります。

選択する場合: API 呼び出しのみを必要とするシンプルなソリューションが必要で、大きなドキュメントをベクトル化する必要がある可能性があり、コストは問題ではありません。

jina-embeddings-v2 (ジナ v2)

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

Jina v2 は、Ada v2 の問題に対する解毒剤を提供します。これは Apache License 2.0 の下でオープン ソースであり、ローカルで実行できます。これは、独自のコードを実行するつもりがない場合には、もちろん欠点でもあります。また、Ada v2 の半分の次元の埋め込みベクトルも生成します。

したがって、ベンチマークの使用例でわずかに優れた検索パフォーマンスが得られるだけでなく、ベクトル データベースの観点から見た場合、より低いストレージとコンピューティング要件で改善された結果が得られます。

選択する場合:オープンソース ソリューションを使用し、大きなドキュメントをベクトル化する必要がある可能性があり、埋め込みパイプラインをローカルで実行することに抵抗がない場合。低次元の埋め込みを使用してベクトル データベースのコストを削減したいと考えています。

bge-large-en-v1.5

bge-large-en-v1.5 はMIT ライセンスの下でオープンソース化されており、現在、検索ユースケースの MTEB リーダーボードでトップランクの埋め込みモデルです。入力シーケンスが小さい場合は、チャンク化戦略についてさらに考慮する必要がありますが、最終的には、取得のユースケースに最適な総合的なパフォーマンスが提供されます。

いつ選択するか: オープンソース ソリューションを使用する必要があり、入力サイズの制限内に収まるようにチャンク化戦略により多くの時間を費やしたいと考えています。埋め込みパイプラインをローカルで快適に実行できます。取得のユースケースでは最高のパフォーマンスを発揮する埋め込みモデルが必要です。

この記事の範囲外ですが、MTEB リーダーボードの 15 のベンチマークをさらに詳しく調べて、特定の状況に最も近いベンチマークを特定することもできます。

さまざまなエンベディング モデルがさまざまなベンチマークにわたってどの程度優れたパフォーマンスを発揮するかという点では確かにパターンがありますが、多くの場合、それぞれのベンチマークで際立っている特定のモデルが存在します。埋め込みの選択をさらに調整する必要がある場合は、さらに調査する必要がある可能性があります。

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

入力テキストのセグメンテーション、つまり「チャンク化」は、生成される出力の関連性と精度に大きく影響する極めて重要な要素です。さまざまなチャンク化戦略には独自の利点があり、特定の種類のタスクに適しています。ここでは、これらの方法論を詳しく掘り下げ、いくつかの重要な考慮事項を組み込んだその適用のためのガイドラインを提供します。

1. 固定長チャンキング

   • いつ使用するか- コンテンツ自体が高度に構造化されており、長さが固定されている場合を除き、通常は、以下に示すような、より便利なチャンク化戦略に依存する必要があります。

     
     

   • 技術的考慮事項- このチャンク化戦略は実装が非常に簡単ですが、一般的に RAG アプリケーションでは悪い結果につながります。

     
     

   • 追加の洞察RAG アプリケーションで固定長戦略を使用していて、関連するコンテキストの取得に問題がある場合は、別のチャンク化アプローチに切り替えることを検討する必要があります。

     
     

2. 文レベルのチャンク化

   • いつ使用するか- この戦略は、入力テキストの各文に意味とコンテキストが豊富な場合に効果的です。これにより、モデルが各文内の複雑な部分に集中できるようになり、より一貫性があり、文脈に関連した応答を生成できるようになります。 RAG の使用例では、文レベルのチャンク化に依存することはほとんどありません。

     
     

   • 技術的考慮事項-文レベルのチャンク化には、多くの場合、文の境界に基づくトークン化が含まれます。これは、自然言語処理 (NLP) ライブラリを使用して実現できます。

     
     

   • 追加の洞察-文レベルのチャンクは、会議の記録など、特定のテキストに意味的に類似した文を検索する場合など、特定の文を検索する場合に特に役立ちます。

     
     

3. 段落レベルのチャンク化

   • いつ使用するか- 入力テキストが個別のセクションまたは段落に編成され、それぞれが個別のアイデアまたはトピックをカプセル化する場合に、この戦略を使用します。これにより、モデルは各段落内の関連情報に焦点を当てることができます。

     
     

   • 技術的考慮事項-段落の境界を識別するには、通常、段落の終わりを示す改行文字やその他の区切り文字の検出が含まれます。

     
     

   • 追加の洞察-段落レベルのチャンクは、同じトピックのさまざまな側面をカバーする文書がある場合に役立ちます。たとえば、製品ドキュメントのページでは、製品の機能を紹介し、いつ使用するか説明し、その構成方法について説明し、さまざまな構成の例を示します。

     
     

     段落レベルのチャンクを使用すると、コンテキストとして LLM に提供する文書の最も関連性の高い部分を特定するのに役立ちます。

     
     

4. コンテンツを意識したチャンキング

   • いつ使用するか-テキスト内の特定のセクションの関連性が最重要である場合に、この戦略を選択します。たとえば、法律文書では、条項またはセクションに基づいてテキストを分割すると、より文脈に応じた応答が得られます。

     
     

   • 技術的考慮事項-このアプローチでは、テキスト内の意味上の境界を理解するために高度な NLP 技術が必要になる場合があります。

     
     

   • 追加の洞察-コンテンツ認識チャンクは、特定のチャンクをメタデータ フィルタリングと組み合わせてより正確に取得できるため、構造化データまたは半構造化データを扱う場合に特に役立ちます。

     
     

     たとえば、法的文書では、すべての保証条項または補償条項を抽出する必要がある場合があります。また、チャンクの埋め込みをベクター データベースに保存する場合、メタデータを使用して、文書を構築するときに特定のタイプのコンテンツを検索しやすくすることができます。 RAG の使用例。

     
     

5. 再帰的なチャンク化

   • いつ使用するか-再帰的チャンクは、階層的なアプローチを使用して、データをより小さな部分に分割します。たとえば、テキスト ドキュメントをチャンク化する場合、最初にテキストを段落に分割し、次に文に分割し、最後に単語に分割します。

     
     

     データが最初のチャンクのセットに分割されたら、チャンク化プロセスを小さなチャンクのそれぞれに再帰的に適用し、目的の最小チャンク サイズに達するまで繰り返すことができます。

     
     

   • 技術的考慮事項-再帰的チャンクの実装には、チャンクが追加の基準に基づいてサブチャンクにさらに分割されるマルチレベルの解析戦略が必要となる場合があります。使用している場合ラングチェーン、その再帰的な実装は、ここで説明するものよりも少し単純です。

     
     

   • 追加の洞察-このアプローチにより、モデルは高レベルのテーマから詳細なニュアンスに至るまで、複数のレベルでコンテキストを理解できるようになり、学術論文、技術マニュアル、法的契約書などの複雑な文書に特に役立ちます。これにより、類似性検索により、より広範なクエリと短いクエリの両方で類似したテキストを識別できるため、柔軟性の利点がもたらされます。

     
     

     ただし、これは、特にテキスト スプリッター設定でチャンク間のオーバーラップを長くすることを選択した場合、同じソース ドキュメントの類似したチャンクが類似性検索でも過剰に表示される可能性があることも意味します。

一般的なアプローチとして、大きなコーパスを分割してベクトル化する前に、データに対してアドホックな実験を行うことを検討する必要があります。

特定のクエリに対して取得するドキュメントを手動で検査し、LLM に提供したい理想的なコンテキストを表すチャンクを特定し、チャンク化戦略を試して、どのチャンクが最も関連性が高いと思われるチャンクを提供するかを確認します。 LLM が持つべきもの。

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

LLM の利用可能なコンテキスト ウィンドウは、チャンキング戦略を選択する際の重要な要素です。コンテキスト ウィンドウが小さい場合は、最も関連性の高い情報が確実に含まれるように、モデルにフィードするチャンクをより選択する必要があります。

逆に、コンテキスト ウィンドウが大きいほど柔軟性が高まり、すべてが厳密に必要ではない場合でも、モデルの出力を強化する可能性のある追加のコンテキストを含めることができます。

これらのチャンク化戦略を試し、これらの考慮事項を考慮することで、生成される出力の関連性に対するそれらの影響を評価できます。重要なのは、選択した戦略を RAG アプリケーションの特定の要件に合わせて調整し、入力のセマンティックな整合性を維持し、コンテキストの包括的な理解を提供することです。

これにより、最適なパフォーマンスを実現する適切なチャンク化プロセスを見つけることができます。

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

検索インデックス内の埋め込みの数が増えると、プロンプトに含める関連コンテキストを探すときに近似最近傍 (ANN) が役に立たなくなります。ナレッジ ベース内の 200 件の記事の埋め込みにインデックスを付けたとします。

上位最近傍を 1% の精度で特定できれば、1% はこれら 200 件のうちの上位 2 件の記事を表しており、それら 2 件のうちの 1 つを取得することになるため、かなり関連性の高い結果が見つかる可能性があります。

ここで、Wikipedia のすべての記事を含む検索インデックスを考えてみましょう。これは約 670 万件の記事に相当します。最も近い記事が最も類似した記事の上位 1% に入っている場合、それは、最も類似した 67,000 件の記事の 1 つを取得していることを意味します。

これは、Wikipedia のようなコーパスを使用すると、依然として的外れな結果になる可能性があることを意味します。

メタデータ フィルタリングを使用すると、最初にドキュメントをフィルタリングし、次に最近傍アルゴリズムを適用することでコンテンツを絞り込むことができます。多数の一致候補を扱う場合、この最初の事前フィルタリングは、最近傍を取得する前に可能なオプションを絞り込むのに役立ちます。

次回は、LLM との対話について詳しく説明し、悪い結果につながる可能性のあるいくつかの一般的な問題を調べます。

試すDataStax Astra DB 、リアルタイム データに基づいて実稼働レベルの AI アプリケーションを構築するための唯一のベクトル データベースです。

Chris Latimer 著、DataStax

ここでも公開されています