「プロダクションに適したRAGアプリケーションの12のチューニング戦略ガイド」
「プロダクションに最適なRAGアプリケーションの12のチューニング戦略ガイド」
これらの「ハイパーパラメータ」やチューニング戦略を使用して、検索増強生成(RAG)パイプラインのパフォーマンスを向上させる方法
![検索増強生成アプリケーションのチューニング戦略](https://ai.miximages.com/miro.medium.com/v2/resize:fit:640/format:webp/1*14bRGUWZojH8Y1x12kA2IQ.png)
データサイエンスは実験的な科学です。それは「完全勝利の食事券定理」というものから始まります。これにより、すべての問題に最も適した汎用アルゴリズムは存在しないことが示されます。そして、データサイエンティストは実験の追跡システムを使用して、機械学習(ML)プロジェクトのハイパーパラメータを調整し、最高のパフォーマンスを達成するためにチューニングするのを支援してもらいます。具体的には、実験のオーケストレーションというウェブサイトで解説されています。
この記事では、データサイエンティストの視点から検索増強生成(RAG)パイプラインについて説明します。RAGパイプラインのパフォーマンスを向上させるために試すことのできる潜在的な「ハイパーパラメータ」について議論します。例えば、ディープラーニングでの実験と同様に、データ拡張技術がハイパーパラメータではなく、チューニングおよび実験が可能な操作範囲である点にも触れます。
検索増強生成(RAG):理論からLangChainの実装まで
元の学術論文の理論から、OpenAI、Weaviate、およびLangChainを使用したPythonの実装へ
towardsdatascience.com
この記事では、次の「ハイパーパラメータ」を関連するステージでソートして説明します。RAGパイプラインのデータ取り込みステージでは、次のようなパフォーマンスの向上が可能です:
また、推論ステージ(検索と生成)では、次のように調整できます:
この記事では、RAGのテキスト使用例について説明しています。マルチモーダルRAGアプリケーションの場合は、異なる考慮事項が適用される場合があります。
取り込みステージ
取り込みステージは、RAGパイプラインの構築のための準備段階であり、MLパイプラインのデータクリーニングおよび前処理の手順と類似しています。通常、取り込みステージには次の手順が含まれます。
- データの収集
- データのチャンク分割
- チャンクのベクトル埋め込みの生成
- ベクトル埋め込みとチャンクの保存
![RAGパイプラインの取り込みステージ](https://ai.miximages.com/miro.medium.com/v2/resize:fit:640/format:webp/1*4WQ2HYCrZO8VwOXeugeGAg.png)
このセクションでは、推論ステージで取得されるコンテキストの関連性を向上させるために適用および調整できる効果のある手法とハイパーパラメータについて説明します。
データクリーニング
あらゆるデータサイエンスパイプラインと同様に、データの品質はRAGパイプラインの結果に大きな影響を与えます[8, 9]。以下の手順に進む前に、データが以下の基準を満たしていることを確認してください。
- クリーン:自然言語処理で一般に使用される基本的なデータクリーニング手法を少なくとも適用し、特殊文字が正しくエンコードされていることを確認してください。
- 正確:情報が一貫しており、事実に基づいていることを確認して、LLMが混乱することのない相反する情報を避けてください。
チャンキング
ドキュメントをチャンク分割することは、RAGパイプラインの外部知識源の重要な準備手順であり、パフォーマンスに影響を与えることがあります[1, 8, 9]。これは、通常、長いドキュメントを小さなセクションに分割すること(小さなスニペットを論理的にまとめることもできます)によって、情報の論理的に一貫したスニペットを生成するためのテクニックです。
考慮する必要がある1つのポイントは、チャンキングのテクニックの選択です。たとえば、LangChainでは、異なるテキスト分割ツールが文字、トークンなどによってドキュメントを分割します。これは、使用するデータのタイプに依存します。たとえば、入力データがコードの場合とMarkdownファイルの場合で異なるチャンキングテクニックを使用する必要があります。
チャンクの理想的な長さ(chunk_size)は、使用ケースによります。質問応答の場合は、より短い具体的なチャンクが必要ですが、要約の場合はより長いチャンクが必要です。また、チャンクが短すぎると、十分なコンテキストが含まれない場合があります。一方、チャンクが長すぎると、関係のない情報が含まれる可能性があります。
さらに、チャンク間の「ローリングウィンドウ」(overlap)を考える必要があります。
埋め込みモデル
埋め込みモデルは、検索結果に大きな影響を与える核心要素です[1, 4]。生成される埋め込みの次元数が高いほど、埋め込みの精度が高くなります。
利用可能な代替埋め込みモデルのアイデアを得るために、Massive Text Embedding Benchmark (MTEB) Leaderboardを参照することができます。これには164のテキスト埋め込みモデルがカバーされています(執筆時点での情報)。
MTEB Leaderboard – a Hugging Face Space by mteb
コミュニティによって作成された素晴らしいMLアプリを発見しましょう
huggingface.co
汎用の埋め込みモデルをそのまま使用できますが、ドメイン外の問題を回避するために、特定の使用ケースに合わせて埋め込みモデルを微調整することも有益です[9]。LlamaIndexによる実験によれば、埋め込みモデルを微調整すると、検索評価メトリックスにおけるパフォーマンスが5-10%向上する可能性があります。 [2].
注意:すべての埋め込みモデルを微調整することはできません(たとえば、OpenAIの text-embedding-ada-002
現在微調整できません)。
メタデータ
ベクトル埋め込みをベクトルデータベースに保存する場合、一部のベクトルデータベースではメタデータと共に保存できます(またはベクトル化されていないデータ)。ベクトル埋め込みにメタデータを付与することは、追加の検索結果の後処理に役立ちます。たとえば、日付、章、または副章の参照などのメタデータを追加できます。
マルチインデックス
メタデータが異なるタイプのコンテキストを論理的に区別するための十分な情報を提供しない場合、複数のインデックスを試してみることができます。たとえば、異なるドキュメントタイプに異なるインデックスを使用できます。ただし、検索時に一部のインデックスルーティングを組み込む必要があります。メタデータと別のコレクションについて詳しく学びたい場合は、ネイティブマルチテナンシーの概念についてさらに学ぶことをお勧めします。
インデックス作成アルゴリズム
ベクトルデータベースとベクトルインデックスライブラリは、近似最近傍探索(ANN)検索を使用して、規模に応じた高速な類似度検索を可能にします。ANNアルゴリズムは、最近傍の近似を行うため、k最近傍(kNN)アルゴリズムよりも精度が低い場合があります。
Facebook Faiss(クラスタリング)、Spotify Annoy(ツリー)、Google ScaNN(ベクトル圧縮)、HNSWLIB(近接グラフ)など、異なるANNアルゴリズムを試すことができます。また、これらのANNアルゴリズムには、HNSWの場合のef
、efConstruction
、maxConnections
などのパラメータを調整できるものもあります。
さらに、これらのインデックス作成アルゴリズムにはベクトル圧縮を有効にすることもできます。ANNアルゴリズムと同様に、ベクトル圧縮により一部の精度が失われますが、ベクトル圧縮アルゴリズムとその調整の選択によって、これも最適化することができます。
ただし、実際にはこれらのパラメータは、ベクトルデータベースとベクトルインデックスライブラリの研究チームによってベンチマーク実験中に調整され、RAGシステムの開発者ではなく調整されています。ただし、性能の最後のビットを引き出すためにこれらのパラメータを試してみたい場合は、この記事を参考にすることをお勧めします。
RAG評価の概要 | Weaviate – ベクトルデータベース
RAG評価の新しいトレンドと最先端の状況について学びましょう。
weaviate.io
推論ステージ(取得と生成)
RAGパイプラインの主要なコンポーネントは、取得と生成のコンポーネントです。このセクションでは、取得(クエリの変換、取得パラメータ、高度な取得戦略、および再ランキングモデル)を改善する戦略について主に検討しています。これは2つのコンポーネントのうち、より大きな影響を与える部分です。ただし、生成を改善するための戦略(LLMおよびプロンプトエンジニアリング)にも触れています。
![RAGパイプラインの推論ステージ](https://ai.miximages.com/miro.medium.com/v2/resize:fit:640/format:webp/1*tT14GpYfEMSqCjnt2UQOGQ.png)
クエリの変換
RAGパイプラインで追加の文脈を取得するための検索クエリもベクトル空間に埋め込まれているため、そのフレーズが検索結果にも影響を与えることがあります。したがって、検索クエリが満足のいく検索結果をもたらさない場合は、さまざまなクエリ変換技術 [5、8、9] を試してみることができます。例えば:
- 言い換え: LLMを使用してクエリを言い換えて再試行します。
- 仮説的なドキュメント埋め込み(HyDE): LLMを使用して検索クエリに対する仮説的な応答を生成し、両方を検索に使用します。
- サブクエリ: 長いクエリを複数の短いクエリに分割します。
検索パラメータ
検索はRAGパイプラインの重要なコンポーネントです。最初の考慮事項は、セマンティック検索が使用ケースに適しているか、ハイブリッド検索を試してみたいかどうかです。
後者の場合、ハイブリッド検索における疎な検索と密な検索法の集約の重み付けを試行する必要があります [1、4、9]。そのため、パラメータalpha
(セマンティック(alpha = 1
)とキーワードベースの検索(alpha = 0
)の重み付けを制御する)の調整が必要となります。
ハイブリッド検索を使用したRAGパイプラインの検索パフォーマンスの向上
伝統的なキーワードベースの検索とモダンなベクトル検索を組み合わせて、より関連性の高い検索結果を見つける方法
towardsdatascience.com
また、取得する検索結果の数も重要な役割を果たします。取得されるコンテキストの数は、使用されるコンテキストウィンドウの長さに影響を与えます(Prompt Engineeringを参照)。また、再ランキングモデルを使用している場合は、モデルに入力するコンテキストの数を考慮する必要があります(Re-ranking modelsを参照)。
なお、セマンティック検索のための使用される類似度尺度は変更可能なパラメータですが、使用される埋め込みモデルに応じて設定する必要があります(例:text-embedding-ada-002
はコサイン類似度をサポートし、multi-qa-MiniLM-l6-cos-v1
は、コサイン類似度、内積、ユークリッド距離をサポートしています)。
高度な検索戦略
このセクションは実際には独立した記事になり得ます。この概要では、できるだけ簡潔にします。以下のテクニックの詳細な説明については、このDeepLearning.AIのコースをお勧めします:
高度なRAGアプリケーションの構築と評価
文ウィンドウの検索や自動結合検索などの方法を学び、RAGパイプラインのパフォーマンスを向上させましょう…
www.deeplearning.ai
このセクションの基本的なアイデアは、取得用のチャンクが必ずしも生成用のチャンクと同じである必要はないということです。理想的には、取得用のより小さなチャンク(Chunkingを参照)を埋め込みますが、より大きなコンテキストを取得します。 [7]
- 文ウィンドウの検索: 関連する文だけでなく、取得した文の前後の適切な文のウィンドウも取得します。
- 自動結合検索: ドキュメントはツリーのような構造で組織化されています。クエリ時には、関連するが別々の小さなチャンクを大きなコンテキストに統合することができます。
リランキングモデル
意味論的検索は、検索クエリに対する文脈を意味的類似性に基づいて取得しますが、「最も類似している」とは必ずしも「最も関連している」とは限りません。Cohereのリランクモデルなどのリランキングモデルは、各取得された文脈の関連性についてクエリのスコアを計算することで、関連しない検索結果を除外するのに役立ちます[1, 9]。
「最も類似している」とは必ずしも「最も関連している」を意味しない
リランクモデルを使用している場合、リランクモデルの入力の検索結果の数およびLLMにフィードするリランク結果の数を調整する必要がある場合があります。
埋め込みモデルと同様に、特定の使用ケースにリランクモデルの微調整を試してみることがあります。
LLM
LLMは応答を生成するためのコアコンポーネントです。埋め込みモデルと同様に、オープンソースのモデル、特許技術のモデル、推論コスト、文脈の長さなどの要件に応じて様々なLLMを選ぶことができます[1]。
また、埋め込みモデルやリランキングモデルと同様に、特定の文言や声のトーンを取り入れるためにLLMを微調整することも検討されます。
プロンプトエンジニアリング
プロンプトのフレーズやプロンプトのエンジニアリングは、LLMの完成度に大きな影響を与えます[1, 8, 9]。
回答は検索結果に基づいてください。他のものに基づいた回答は認められません!
非常に重要!回答は必ず提供された検索結果に基づいてください。なぜ回答が検索結果に基づいているのかを説明してください!
さらに、プロンプトに少数の例示を使用すると、完成度の品質が向上する場合があります。
検索パラメータで説明されているように、プロンプトにフィードする文脈の数は、実験するべきパラメータです[1]。関連する文脈を増やすことでRAGパイプラインのパフォーマンスが向上する一方で、「Lost in the Middle」[6]の効果が発生する可能性があります。この効果により、多くの文脈の中に関連する文脈が認識されないかもしれません。
まとめ
より多くの開発者がRAGパイプラインのプロトタイプ作成の経験を積むにつれて、RAGパイプラインを本格的なパフォーマンスに持っていくための戦略を議論することがますます重要になってきました。この記事では、以下の関連する段階に応じてRAGパイプラインの中で調整できる異なる「ハイパーパラメータ」やその他のつまみについて説明しました:
この記事では、取り込みステージで次の戦略をカバーしています:
- データのクリーニング:データがクリーンかつ正確であることを確認します。
- チャンキング:チャンキング技術の選択、チャンクサイズ(
chunk_size
)とチャンクオーバーラップ(overlap
)。 - 埋め込みモデル:埋め込みモデルの選択、次元数、および微調整の有無など。
- メタデータ:メタデータの使用有無とメタデータの選択。
- マルチインデックス:異なるデータコレクションに複数のインデックスを使用するかどうかを決定します。
- インデックスアルゴリズム:ANNとベクトル圧縮アルゴリズムの選択とチューニングは、通常は開発者によって調整されません。
そして、推論段階(検索と生成)における以下の戦略:
- クエリ変換:言い換え、HyDE、またはサブクエリの実験。
- 検索パラメータ:検索技術の選択(ハイブリッド検索が有効な場合は
alpha
)と取得する検索結果の数。 - 高度な検索戦略:文ウィンドウや自動マージ検索などの高度な検索戦略の使用の可否。
- 再順位付けモデル:再順位付けモデルの使用可否、再順位付けモデルの選択、再順位付けモデルに入力する検索結果の数、再順位付けモデルの微調整の可否。
- LLM(Large Language Model):LLMの選択とLLMの微調整の可否。
- プロンプトエンジニアリング:異なる表現やフューショットの例を実験する。
この記事が気に入ったら?
無料で購読して、新しい記事が公開された際に通知を受け取りましょう。
Leonie Monigattiが記事を公開するたびにメールを受け取る。
Leonie Monigattiが記事を公開するたびにメールを受け取る。登録することで、VoAGIアカウントが作成されます(既にアカウントをお持ちの場合は除く)…
VoAGI.com
LinkedIn、Twitter、およびKaggleで私に連絡してください!
参考文献
参考文献
[1] Connor Shorten and Erika Cardenas (2023). Weaviate Blog. RAG評価の概要(2023年11月27日アクセス)
[2] Jerry Liu (2023). LlamaIndex Blog. 合成データによるRAGの埋め込みの微調整(2023年11月28日アクセス)
[3] LlamaIndex Documentation (2023). パフォーマンスの高いRAGアプリケーションの構築(2023年11月28日アクセス)
[4] Voyage AI (2023). 埋め込みによるRAGの品質:Chat.LangChainの事例研究(2023年12月5日アクセス)
[5] LlamaIndex Documentation (2023). クエリ変換(2023年11月28日アクセス)
[6] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023年). Lost in the middle: How language models use long contexts. arXivプレプリント arXiv:2307.03172.
[7] DeepLearning.AI (2023年). 高度なRAGアプリケーションの構築と評価 (2023年12月4日アクセス)
[8] Ahmed Besbes (2023年). Towards Data Science. 生産環境で信頼性のないRAGの理由 (2023年11月27日アクセス)
[9] Matt Ambrogi (2023年). Towards Data Science. リトリーバル強化生成システムのパフォーマンスを向上させる10の方法 (2023年11月27日アクセス)
画像
特に示されていない場合、すべての画像は著者によって作成されました。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles