2023 古い記事のレビュー：RAGシステム構築プロセスと評価の手引き

検索拡張生成（RAG）は、大規模言語モデル（LLM）とベクトルデータベースの最も人気のあるアプリケーションの1つになってきている。 ウィービエイトRAGアプリケーションは、チャットボットやQ&Aシステムでよく使われている。

他のエンジニアリング・システムと同様に、性能評価は以下の点で重要である。 ラグ RAGのパイプラインは3つの要素に分かれている：

1. インデクシング
2. 取り出す
3. 生成

RAGの評価は、これらのコンポーネント間の相互作用の複雑さとテストデータの収集の難しさのために困難である。この論文では、評価のためのLLMの使用におけるエキサイティングな発展と、RAGコンポーネントの現状を示す。

手短に言えば私たちは、このようなパートナーシップに刺激を受けています。 ラガス のクリエイター、ジティン・ジェイムズとシャウフル・エスによる対談。これらの対話は ラガス そして、ARESによって開拓されたRAGシステムのLLM評価における新たな発展が、既存の評価基準を振り返り、調整可能なRAGパラメータを把握することを促した。研究の過程で、RAG実験追跡ソフトウェアの可能な形態についてさらに考察し、RAGシステムがエージェント・システムとどのように異なり、どのように評価されるのかをさらに明確にした。

私たちのブログ記事には、主に以下の5つのセクションがあります：

• LLMアセスメントゼロサンプル、少数サンプル、LLM評価器のサイズの微調整など、LLMを使用したRAGパフォーマンスのスコアリングにおける新たなトレンド。
• RAG指標生成、検索、インデックスを評価するために使用される一般的な指標と、それらがどのように相互作用するか。
• RAGの調整パラメータRAGシステムのパフォーマンスに大きく異なる影響を与える決定とは？
• スケジューリングRAGシステムの実験構成追跡はどのように管理するのですか？
• RAGから代理店評価へRAG は、索引付け、検索、生成の 3 段階のプロセスであると定義する。本節では、RAGシステムがAgentシステムに変換される場合と、その違いを評価する方法について述べる。

LLMアセスメント

この中で最も新しく、最もエキサイティングな部分であるLLM評価から始めよう！機械学習の歴史は、Yelpのレビューが肯定的か否定的かを判断したり、"ボストン・セルティックスのヘッドコーチは誰か？"というクエリに関連する記事かどうかを判断するなど、データを手作業で注釈付けする労力に大きく依存してきた。LLMは、より少ない手作業でデータに注釈をつけるのに、徐々に効率的になってきている。これは、RAGアプリケーションの成長を加速させている重要な**「新しいトレンド」**である。

任せる ラガス ゼロサンプルLLM評価などのフレームワークによって開拓された最も一般的なテクニックは、ゼロサンプルLLM評価である。ゼロサンプルLLM評価では、「これらの検索結果の関連性を1から10のスケールで評価してください」といったテンプレートで大規模言語モデルをプロンプトします。クエリは{query}で、検索結果は{search_results}です。"次の図は、LLMがRAGシステムの性能評価にどのように使用できるかを示している。

1.精度、リコール、nDCGなどの設計指標、2.これらのキューの特定の言語、3.評価に使用する言語モデル（GPT-4、Coral、Llama-2、Mistralなど）。現時点での大きな懸念は、評価にLLMを使用するコストである。例えば、GPT-4を使って10件の検索結果を評価する場合（1件あたり500トークン、さらにクエリとコマンドに100トークン、合計約6,000トークンを想定）、1件あたり約1,000ドルのコストがかかる。 トークン 0.005、つまり100のクエリーを評価するのに3ドル。

RagasのようなフレームワークがゼロサンプルのLLM評価を推進するにつれて、人々はより少ないサンプルのLLM評価の必要性に疑問を持ち始めている。ゼロサンプルのLLM評価は「十分」であるため、RAGシステムチューニングの北極星としての役割を果たすには十分かもしれない。下図に示すように、RAGASのスコアは、生成された2つのメトリクスのそれぞれについて、4つのゼロサンプルLLMプロンプトで構成されています：誠実さ 歌で応える 回答の妥当性（Answer Relevancy）また、検索用の2つの指標もある：コンテキスト・プレシジョン（コンテキスト精度） 歌で応える コンテキスト・リコール（文脈想起）.

 すじ

ゼロサンプルから少ないサンプルへのLLM評価への移行は簡単である。私たちは、検索結果とクエリとの関連性を示す注釈付きの例をインストラクション・テンプレートに含めました。このテクニックの発見はGPT-3の重要なブレークスルーの一つである。

例えば、この例に5つの手動関連性スコアを追加すると、プロンプトに30,000トークンが追加されます。上記と同じコストを仮定すると、100クエリで$3から$15への増加を評価します。これは単純な推定例であり、LLMの実際の価格設定モデルに基づいていないことに注意してください。重要な考慮点は、より少ないサンプル例を追加するには、より長いコンテキストモデルが必要になる可能性があるということです。

このようなゼロサンプルまたは少数サンプルの推論に基づくLLM評価は、すでに非常に魅力的なものであるが、さらなる研究により、知識の蒸留によるアルゴリズムの訓練によって、LLM評価のコストをさらに削減できることが示されている。これは、評価タスクのトレーニングデータを生成し、より小さなモデルに微調整するためにLLMを使用することを指す。

ある アレスSaad-Falconらは、検索機能を強化した生成システムを評価するための自動化されたフレームワークにおいて、独自のLLM評価器を訓練することで、ゼロサンプルのキューを上回ることができることを発見した。最初に、ARESは3つの入力を必要とする：ターゲットコーパスからの段落のコレクション、150以上の人間の嗜好検証データ、ドメイン内のクエリのアンダーサンプリングされた5つの例である。.ARESは次に 文脈的関連性そして回答の信憑性 歌で応える 回答の妥当性 軽量分類器の微調整。

著者による実験的微調整 デバート-v3-ラージこのモデルには、より経済的な4億3,700万個のパラメータが含まれ、各分類器ヘッドはベース言語モデルを共有し、合計3つの分類ヘッドが追加されます。合成データをトレーニングセットとテストセットに分割してARESシステムを評価した結果、微調整されたモデルは、ゼロサンプルと少数サンプルのGPT-3.5-turbo-16kを大幅に上回ることがわかりました。 詳細（予測駆動推論（PPI）における信頼区間の革新的な使用や実験の詳細など）については、以下を参照してください。 サード＝ファルコンら論文。

評価におけるLLMの潜在的な影響をよりよく理解するために、既存のRAGシステマティック・ベンチマーク手法と、LLM評価におけるその特別なバリエーションについて引き続き説明する。

RAG指標

生成、検索、索引付けというトップレベルの観点からRAGメトリクスを紹介する。次に、インデックスの構築、検索手法のチューニング、生成オプションというボトムレベルの観点から、RAGのチューニングパラメータを紹介する。

トップレベルの視点からRAGメトリクスを提示するもう一つの理由は、インデクシングにおけるエラーは検索と生成に引き継がれるが、生成におけるエラー（我々が定義する階層など）はインデクシングにおけるエラーには影響しないということである。RAG評価の現状では、RAGスタックをエンドツーエンドで評価することはほとんどなく、多くの場合 オラクルコンテキスト もしかしたら 制御干渉用語（CIT）(例えば、ロスト・イン・ザ・ミドル実験）。同様に、エンベッディングは通常、近似最近傍誤差を考慮しない暴力的なインデックスで評価されます。近似最近傍誤差は通常、クエリパーセカンドとリコールのトレードオフの観点から精度の最適点を見つけることによって測定され、ANNリコールはクエリに「関連する」とマークされた文書ではなく、クエリの真の最近傍となる。

指標の作成

RAGアプリケーションの全体的な目標は、検索されたコンテキストの使用によってサポートされた、役に立つ出力を生成することである。評価は、出力がコンテキストを使用し、冗長な情報を避け、不完全な答えを防ぐために、ソースから直接取得されないことを考慮しなければならない。出力をスコアリングするためには、各基準をカバーするメトリクスを開発する必要がある。

ラガス 大規模言語モデリング（LLM）出力のパフォーマンスを測定するために、2つのスコアが導入されている。信用度 検索された文脈に基づいて、回答の事実上の正確さを評価する。回答の妥当性 質問に対する回答の関連性を判断する。回答の信頼性スコアが高くても、回答の関連性スコアが低い場合があります。例えば、もっともらしい回答は文脈をそのまま再現するかもしれませんが、この場合、解答の関連性は低くなります。解答に完全性が欠けていたり、重複した情報が含まれている場合、解答の関連性スコアはペナルティを受けます。

2020年、グーグルは ミーナミーナが目指しているのは、「ミーナは、このようなことができるのだ」ということを示すことだ。 合理的かつ具体的 対話のオープンドメインのチャットボットのパフォーマンスを測定するために、彼らはSSA（Sensibleness and Specificity Average）という評価指標を導入した。ボットの応答の妥当性は、文脈の中で意味を持ち、具体的である必要がある（Specificity Average）。このため、人間がチャットボットと会話し、手動で採点する必要がある。

曖昧な答えを避けることは良いことだが、大規模な言語モデルが登場しないようにすることも同様に重要である。 空想の産物 .イリュージョンとは、ビッグ・ランゲージ・モデルによって生成された答えが、実際の事実や提供された文脈に基づいていないという事実を指す。ラマインデックス 利用する 誠実さ評価 を測定する。スコアは、応答が検索されたコンテキストと一致しているかどうかに基づいている。

生成された回答の質の評価は、多くの指標に依存します。回答は事実に基づいていても、指定されたクエリに関連していない場合があります。さらに、回答は曖昧で、回答をサポートする重要なコンテキスト情報が欠けていることもあります。次に、パイプラインの前のレイヤーに戻り、検索メトリクスについて説明します。

指標の検索

評価スタックの次のレイヤーは情報検索である。検索履歴を評価するには、人間がどの文書がクエリに関連しているかを注釈する必要がある。従って、1つのクエリのアノテーションを作成するために、100の文書の関連性をアノテーションする必要があるかもしれない。これは、一般的な検索クエリではすでに非常に困難なタスクであり、ドメインに特化した（例えば、法的契約、医療患者の履歴など）検索エンジンを構築する場合、この課題はさらに悪化する。

アノテーションのコストを軽減するため、検索関連性を判断するためにヒューリスティックがよく使われる。最も一般的なのはクリックロギングで、クエリが与えられた場合、クリックされたタイトルは関連性があるが、クリックされていないタイトルは関連性がない可能性がある。これは機械学習における弱い監視としても知られている。

データセットの準備ができたら、評価でよく使われる3つの指標を挙げる： 正規化分配器 そしてリコール 歌で応える 精密 NDCG（Normalised Discount Cumulative Gain）は、複数の関連タグによるランキングを測定する。例えば、ビタミンDに関するクエリに対して、ビタミンB12に関する文書は最も関連性の高い結果ではないかもしれないが、ボストン・セルティックスに関する文書よりは関連性が高い。相対的なランキングはさらに複雑であるため、バイナリ関連性ラベル（1が関連、0が無関係）が使用されることが多い。 Recallは検索結果にどれだけ多くのポジティブサンプルが含まれているかを測定し、Precisionは関連性があるとラベル付けされた検索結果の割合を測定する。

このように、ビッグ・ランゲージ・モデルは次のようなプロンプトでPrecisionを計算することができます：「次の検索結果のうち、いくつがクエリ{query}に関連していますか？{search_results}」。Recallのプロキシもビッグランゲージモデルのプロンプトから得ることができます："これらの検索結果はクエリ{query}に答えるために必要なすべての情報を含んでいますか？{search_results}"からも得ることができる。また、Ragasのヒントをチェックすることをお勧めします。 こちら.

ビッグ・ランゲージ・モデリング（Big Language Modelling）のプロンプトは、「クエリ{query}に基づいて、どちらの検索結果セットがより適切か？セットA｛セット_A｝とセットB｛セット_B｝。非常に重要です！出力を'セットA'または'セットB'に限定してください。

では、さらに深く、ベクター・インデックスを比較する方法を理解しよう。

インデックス指標

Weaviateに慣れ親しんだ経験豊富なユーザーなら、次のことを知っているかもしれない。 ANNベンチマークベンチマークテストがきっかけ Weaviate バージョン 1.19 における gRPC API の開発ANNベンチマークはQueries Per Second (QPS)とRecallを測定し、シングルスレッドの制限などの詳細を考慮する。データベースは一般的にレイテンシとストレージコストに基づいて評価されるが、ランダムベクターインデックスは精度測定に重点を置いている。これは SQLのselect文での近似計算 似たようなものだが、ベクトル・インデックスが普及するにつれて、近似によるエラーがより注目されるようになるだろうと予測している。

精度はリコールで測定される。ベクトルインデキシングにおいて、リコールとは、ブルートフォースサーチによって決定された最近傍の数に対する、近似インデキシングアルゴリズムによって返された真実の最近傍の数の比率である。これは情報検索(Information 検索)は、全関連文書の中から検索された関連文書の割合を指す「リコール」の典型的な用法とは異なる。両者は通常、関連する@Kパラメータで測定される。

完全なRAGスタックの文脈において、興味深い疑問がある：ANNの精度エラーが情報検索（IR）のエラーにつながるのはどのような場合か？ 例えば、80%のリコールで1,000QPSを達成したり、95%のリコールで500QPSを達成することができるかもしれませんが、上記の検索指標（例えば、nDCGやLLM（Large Language Modelling）のリコールスコアを検索すること）にどのような影響がありますか？

RAG指標に関するまとめ

まとめとして、インデックス作成、検索、生成の評価指標を示す：

• 生成例えば、Rationality and Specificity Average、Sensibleness and Specificity Average、SSA）。
• 取り出すLLMスコアリングにおける文脈的精度対文脈的想起の新たな可能性と、想起、精度、nDCGを測定するための人間によるアノテーションの概要。
• インデクシングRecallは、ベクトル探索アルゴリズムによって返された、真実の最近傍探索の数によって測定されます。ここで重要なのはANNのエラーがIRのエラーに忍び込むのはどんな時か？

すべてのコンポーネントは通常、パフォーマンスとレイテンシーまたはコストの間でトレードオフできる。より高価な言語モデルを使用することで、より高品質な生成が可能になり、リコーダで結果をフィルタリングすることで、より高品質な検索が可能になり、より多くのメモリを使用することで、より高い想起インデックスが可能になる。パフォーマンスを向上させるために、これらのトレードオフをどのように管理するかは、「RAGのつまみ」を調査し続けることで明らかになるだろう。最後に、評価時間がユーザー体験に近いため、生成から検索、インデックス作成までトップダウンの観点からメトリクスを提示することにした。また、RAGアプリケーション開発者の経験に近いため、インデックス作成から検索、生成までのボトムアップの観点からチューニングのつまみを提示する予定です。

RAG調整パラメータ

RAGシステムを比較するための指標について説明したところで、パフォーマンスに大きな影響を与える重要な決定について説明しよう。

インデックス調整パラメータ

これは2023年3月のWeaviate 1.18で導入されたベクトル圧縮アルゴリズムで、ベクトルの連続した断片をグループ化し、その集合内の値をクラスタ化し、重心によって精度を下げるものです。たとえば、4 つの 32 ビット浮動小数点数からなる連続したフラグメントを表現するには 16 バイトが必要ですが、8 つの重心を持つ長さ 4 のフラグメントはわずか 1 バイトで済み、16:1 のメモリ圧縮比を達成します。最近の PQ の並べ替えの進歩により、圧縮による想起の損失は大幅に減少しましたが、非常に高い圧縮レベルではまだ注意が必要です。

次に使用するルーティング・インデックスである。ベクトル数が10K以下のデータセットでは、RAGアプリケーションはブルートフォースインデクシングで満足できるかもしれない。しかし、ベクトル数が増加するにつれて、ブルートフォースインデックスのレイテンシは、HNSWのような近接グラフアルゴリズムに基づくインデクシングよりもはるかに高くなります。 RAGメトリクスで説明されているように、HNSWの性能は、通常、クエリパーセカンドとリコールを比較したパレート最適点によって測定されます。これは推論に使用される検索キューのサイズを調整することで行われる。 もし それを実現するためにより大きく もし を指定すると、検索プロセスでより多くの距離比較を行うことになり、検索速度は大幅に遅くなるが、より正確な結果を得ることができる。次のパラメータには、インデックスを構築する際に使用されるものが含まれる。 イーエフコンストラクション (グラフにデータを挿入する際のキューのサイズ）と 最大接続数 (各ベクトルに格納されるノードごとのエッジ数）。

我々が探求しているもう1つの新しい方向性は、PQの重心に対する分布の偏りの影響と、以下のようなハイブリッド・クラスタリングやグラフ・インデクシング・アルゴリズムとの関係である。 ディスカン もしかしたら IVFOADC+G+P)の相互作用がある。リコール・メトリクスを使用することは、重心を再フィットする必要があるかどうかを決定するのに十分かもしれませんが、どのベクトルのサブセットを再フィットに使用するかという問題が残ります。リコールが低下した最新の100Kベクトルを使用すると、新しい分布にオーバーフィットする可能性があるので、データ分布のタイムラインの混合をサンプリングする必要があるかもしれません。このトピックは、ディープラーニングモデルの継続的な最適化に関するポイントと密接に関連しており、「規制の最適化」のセクションでさらに議論することができます。

データのチャンキングは、Weaviateにデータを挿入する前の重要なステップです。チャンキングは長い文書を小さな部分に変換する。各チャンクには重要な情報が含まれており、Large Language Model (LLM)のToken制限内に収まるため、検索が向上する。文書の解析には複数の方法がある。上の図は、研究論文をタイトルに基づいてチャンキングした例です。例えば、チャンク1はアブストラクト、チャンク2はイントロダクションといった具合です。チャンクを組み合わせてオーバーラップを作る方法もある。これには、前のブロックからトークンを取り出し、それを次のブロックの開始点として使用するスライディングウィンドウが含まれる。ブロックが少し重なると、リトリーバーが前のコンテキスト／ブロックを理解できるため、検索が向上する。次の画像は、チャンクされたテキストのハイレベルな概略図である。

取り出す

エンベッディング・モデル、ハイブリッド・サーチの重み、オート・カットの使用有無、並び替えモデルである。

ほとんどのRAG開発者は、OpenAI、Cohere、Voyager、Jina AI、Sentence Transformers、および他の多くのオプションなど、使用される埋め込みモデルをすぐに調整すると思われます！開発者はまた、モデルの次元性とPQ圧縮への影響を考慮する必要があります。

次の重要な決定は、ハイブリッド検索におけるスパース検索法とデンス検索法の集計重みをどのように調整するかである。重みはパラメータ アルファ.アルファ 0は純粋 bm25 検索アルファ を1に設定すると、純粋なベクトル検索になる。したがって アルファ データとアプリケーションによる

Weaviateは現在、2つのモデルを提供している。 コヒアの並び替えモデル::リランク-英語-v2.0 歌で応える リランク・マルチリンガル-v2.0.その名前が示すように、これらのモデルは、主に使用される学習データと、その結果として得られる多言語能力によって異なる。将来的には、モデル能力に関してより多くの選択肢を提供することを期待している。これは、性能と待ち時間の間の本質的なトレードオフを伴うものであり、アプリケーションによっては意味があるかもしれないが、他のアプリケーションにとっては意味がないかもしれない。検索におけるパラメーターをチューニングする過程で、どのような有能な並べ替え装置が必要で、いくつの検索結果を並べ替える必要があるのかを発見するのは大変なことであった。これはまた、RAGスタックでカスタムモデルを微調整するための最も簡単なエントリーポイントの一つであり、"Regulatory Optimisation "でさらに説明する。

もうひとつの興味深いチューニング・パラメーターは、マルチインデックス検索である。チャンキングの議論と同様、これはデータベースの構造的な変更を伴う。全体的な疑問はどのような場合にフィルターではなく、別コレクションを使うべきですか？ を転送する必要があります。 ブログ 歌で応える ドキュメンテーション を2つのセットに分けるか、あるいは ソース 属性 ドキュメント カテゴリーは？

フィルタを使用すると、各ブロックに複数のラベルを追加し、分類器がそれらをどのように使用するかを分析するためにアブレーションを行うことができるため、これらのラベルの有用性をテストする迅速な方法が得られます。例えば、LLMへのコンテキストの入力で、コンテキストのソースを明示的にラベル付けするような、多くの興味深いアイデアがあります。以下はブログからの検索結果{search_results}。以下はドキュメントからの検索結果{documentation}」のように。LLMがより長い入力を扱えるようになると、複数のデータソース間のコンテキスト融合がより一般的になると予想されるため、別の関連するハイパーパラメータが登場する。

生成

生成に関してまず注目すべきなのは、どの大規模言語モデル（LLM）を選ぶかということだ。例えば、OpenAI、Cohere、Facebook、そして多くのオープンソースからモデルを選ぶことができる。多くのLLMフレームワーク（例えば ラングチェーンそしてラマインデックス 歌で応える Weaviateのジェネレーション・モジュール)は様々なモデルと簡単に統合できる。どのモデルを選択するかは、データを非公開にするかどうか、コスト、リソースなどの要因による。

一般的なLLM固有のレギュレーション・パラメーターは温度である。温度設定は出力のランダム性を制御する。温度0は、応答がより予測可能で変動が少ないことを意味し、温度1は、モデルが応答にランダム性と創造性を導入することを可能にする。したがって、温度を1に設定して生成モデルを複数回実行すると、再実行するたびに応答が異なるかもしれません。

ロングコンテキストモデル（LCM）は、アプリケーションにLLMを選択する際の新たな方向性です。入力としてより多くの検索結果を追加することは、回答の質を向上させるのか？Lost in the Middle実験に関する研究では、いくつかの赤信号が出ています。それは "ロスト・イン・ザ・ミドル" その中で、スタンフォード大学、カリフォルニア大学バークレー校、Samaya AIの研究者は、関連する情報が検索結果の最初や最後ではなく、途中に配置されている場合、言語モデルが応答を生成する際にそれを組み込むことができない可能性があることを示す対照実験を行った。グーグル・ディープマインド、トヨタ自動車、パデュー大学の研究者による別の論文では、次のように指摘されている："大規模な言語モデルは、無関係な文脈に気を取られやすい".この方向性の可能性にもかかわらず、この記事を書いている時点では、長いコンテキストのRAGはまだ初期段階にある。幸いなことに、ラガス・スコアのような指標は、新しいシステムを素早くテストするのに役立つ！

先に説明したLLM評価における最近のブレークスルーと同様に、チューニングの生成的側面は3つの段階に分けられる：1.プロンプト・チューニング、2.数ショット例、3.ファイン・チューニング。プロンプト・チューニングでは、"Please answer the question based on the search results provided."（提供された検索結果に基づいて質問に答えてください）というような特定の言語表現を調整する。対「質問にお答えください。重要、以下の指示に従ってください。質問への回答は、提供された検索結果のみに基づいてください！"の違いです。

前述したように、サンプルレス例とは、言語モデルの生成をガイドするために、手作業で書かれた質問、文脈、答えのペアを多数集めたものを指す。最近の研究（例えば 「コンテキスト・ベクトル)は、このように潜在的な空間をブートストラップすることの重要性をさらに実証している。Weaviate Gorillaプロジェクトでは、GPT-3.5-turboを使ってWeaviateのクエリを生成したが、少ないサンプル例のクエリ翻訳に自然言語を追加したところ、パフォーマンスが大幅に向上した。

最後に、RAGアプリケーションのためのLLM微調整は、ますます注目を集めている。以下は、検討すべきいくつかのアプローチである。LLMの評価に関する議論に再び戻ると、よりロバストなLLMを使用してトレーニングデータを生成し、より小さく、より手頃な価格のモデルを構築することが考えられます。もう1つのアイデアは、LLMをコマンド・フォローで微調整できるように、応答の品質に関する人間によるアノテーションを提供することです。モデルの微調整に興味があるなら、HuggingFace PEFTライブラリの使い方に関するBrevの寄稿を以下のサイトでチェックしてください。 チュートリアル.

RAG調整オプションの概要

まとめとして、RAGシステムで利用可能な主なチューニングオプションについて説明した：

• インデクシング：最も高いレベルでは、ブルートフォースサーチだけを使う場合と、ANNインデクシングを導入する場合を検討する必要がある。これは、新規ユーザーと強引なユーザーとのマルチテナントのユースケースをチューニングする場合に特に興味深い。ANNインデクシングでは、PQのハイパーパラメータ（断片化、重心、学習限界）、hNSWのハイパーパラメータ（ef、efConstruction、maxConnections）がある。
• 検索：埋め込みモデルの選択、ハイブリッド検索の重みの調整、再検索器の選択、コレクションを複数のインデックスに分割。
• 生成：LLMを選択し、キューチューニングからサンプル数の少ない例やファインチューニングに移行するタイミングを決める。

RAGメトリクスを理解し、チューニングによってそのパフォーマンスを向上させる方法を理解した上で、実験的トラッキングの可能な実装について説明しよう。

スケジューリング

大規模言語モデル(LLM)評価の分野における最近の進歩と、調整可能なパラメータの概要を考えると、これらすべてを実験追跡フレームワークと組み合わせるエキサイティングな機会がある。例えば、直感的なAPIを持つシンプルなオーケストレーターを使用することで、ユーザーは次のようなことができる：1.5つのLLM、2つの組み込みモデル、5つのインデックス設定の完全なテストをリクエストする；2.実験を実行する；3.ユーザーに高品質なレポートを返す。Weights & Biasesは、ディープラーニングモデルをトレーニングするための注目すべき実験トラッキングの道を切り開きました。Weights & Biasesは、ディープラーニングモデルをトレーニングするための注目すべき実験的追跡の道を切り開いた。我々は、本稿で概説した調整可能なパラメータとメトリクスを用いたRAG実験サポートへの関心が急速に高まることを期待している。

私たちはこの分野で2つの開発方向に従っている。一方では、既存のゼロサンプルLLM（例えばGPT-4、Command、Claude、またオープンソースのLlama-2やMistral）は オラクルコンテキスト 当時はかなり好調だった。だから、次のような大きなチャンスがある 検索部分に焦点を当てる .そのためには、ANNのエラー、埋め込みモデル、ハイブリッド探索の重み付け、PQやHNSWの複数の構成における並べ替えをトレードオフにする方法を見つける必要がある。

Weaviate 1.22では、非同期インデックスとそれに対応するノード状態APIが導入されています。RAG評価とオーケストレーションのチューニングに焦点を当てたパートナーシップを通じて、インデックスの構築がいつ終了したかを判断し、テストを実行するために活用できるようになることを期待しています。あるテナントは総当たり検索に頼るかもしれないが、他のテナントはデータに適した埋め込みモデルとHNSW設定を見つける必要がある。

さらに、リソースの割り当てを並列化することで、テストを高速化したい場合もある。例えば、4つのエンベッディング・モデルを同時に評価するなどである。前述したように、もう一つの興味深い部分は、データインポーターからもたらされる可能性のあるチャンクやその他のシンボリックなメタデータの調整である。例として、Weaviate Verbaデータセットには、Weaviateの3つのフォルダが含まれている。 ブログそしてドキュメンテーション 歌で応える ビデオ 転記します。チャンクサイズを100と300で比較したい場合、ウェブクローラーを再度呼び出す必要はない。S3のストレージバケットに保存されたデータか、そうでなければ関連するメタデータを含む別のフォーマットが必要になるかもしれないが、より経済的な実験方法を提供する。

一方、データの挿入や更新ではなく、モデルの微調整や勾配ベースの連続学習がある。RAGで使用される最も一般的なモデルは、埋め込みモデル、並べ替えモデル、そしてもちろんLLMである。新しいデータで機械学習モデルを最新の状態に保つことは、新しいモデルの再学習、テスト、デプロイメントを管理する継続学習フレームワークやMLopsオーケストレーションの長年の焦点であった。継続学習LLMを始め、RAGシステムの最大のセールスポイントの1つは、LLM知識ベースの "締め切り "日を延長して、データと同期させることができることだ。私たちは、継続的なトレーニングが、RAGを通じて情報を最新に保つことと、どの程度相互作用するのかは明らかでないと考えています。いくつかの研究（例えばMEMIT）では、体重帰属の因果関係媒介分析を実験的に行っており、「レブロン・ジェームズがバスケットボールをする」というような事実を「レブロン・ジェームズがサッカーをする」に更新している。「というように。これはかなり高度な技術であり、もう一つの方法は、訓練で使用したチャンク（例えば「レブロン・ジェームズがバスケットボールをする」）にラベルを付け、新しい情報を含む検索強化訓練データを使用して再訓練することである。これは我々が注視している重要な分野である。

前述したように、この種の連続的なチューニングを、PQ主センタを使ってWeaviateに直接組み込む方法も検討している。Weaviateに初めて入力されるK個のベクトルに対するPQセントロイドは、データ分布の大きな変化の影響を受ける可能性がある。機械学習モデルの継続的なトレーニングは、悪名高い「壊滅的な忘却」問題に悩まされる。これは、PQセンター・オブ・マス・リフィットを設計する際に考慮した点のひとつである。

RAGから代理店評価へ

この記事を通して、我々は ラグ 代わりに 代理店 評価我々の意見ではラグ インデックス作成、検索、生成のプロセスと定義される。 代理店 システムの範囲はよりオープンになる。下図は、プランニング、メモリー、ツールといった主なコンポーネントの見方を示したもので、これらのコンポーネントが組み合わさることで、システムに重要な機能が備わりますが、同時に評価が難しくなります。

RAGアプリケーションの一般的な次のステップは、高度なクエリーエンジンを追加することです。この概念に慣れていない読者のために、LlamaIndexとWeaviateシリーズをチェックしてください。サブクエッションクエリーエンジン、SQLルーター、自己修正クエリーエンジンなど、様々な高度なクエリーエンジンがあります。また、WeaviateモジュールのpromptToQuery APIや検索クエリ抽出器の可能な形も検討しています。それぞれのクエリエンジンには、情報検索プロセスにおいてそれぞれの利点があるので、いくつかのクエリエンジンとその評価方法について掘り下げてみよう。

マルチホップ・クエリー・エンジン（別名サブイシュー・クエリー・エンジン)は複雑な問題を小問題に分解するのに最適である。この質問に答えるには、Ref2VecとWeaviateがそれぞれ何であるかを知る必要があります。この質問に答えるには、Ref2VecとWeaviateがそれぞれ何であるかを知る必要がある。 したがって、関連するコンテキストを取得するために、両方の質問に対してデータベースを2回呼び出す必要がある。その後、2つの回答が組み合わされ、1つの出力が生成される。マルチホップクエリーエンジンの性能評価は、サブクエスチョンを見ることで行うことができる。LLMが関連性のあるサブクエスチョンを作成し、各クエスチョンに正確に回答し、2つの回答を組み合わせて事実に正確で関連性のある出力を提供することが重要です。また、複雑な質問をする場合は、マルチホップ・クエリー・エンジンを使用するのが最善です。

マルチホップ問題は、何よりもまずサブクエスチョンの精度に依存します。ここでは、次のようなプロンプトで、同様のLLM評価を使用することが考えられます。 あるシステムはこの質問を{sub_question_1}と{sub_question_2}に分割することにしました。 質問のこの分解は意味がありますか？" 次に、それぞれのサブ質問に対して2つの別々のRAG評価を実行し、LLMが元の質問に答えるためにそれぞれの質問の答えを組み合わせることができるかどうかを評価します。

RAGからAgentへの複雑さの進化のもう一つの例として、ルーティングクエリーエンジンを考えてみましょう。下の図は、エージェントがクエリをSQLまたはベクトルデータベースクエリにルーティングする方法を示しています。このシナリオは、マルチインデックスルーティングの議論と非常に似ており、生成された結果を評価し、SQLとベクトルデータベースを記述する必要性を示唆し、LLMルータが正しい判断をしたかどうかを尋ねるために、同じようなアプローチを使うことができます。また、SQLクエリの結果に対してRAGASのコンテキスト関連性スコアを使うこともできる。

RAGからAgentの評価へ」の議論を要約すると、Agentの一般的な使用パターンを見分けることは現状では不可能であると考えている。マルチホップクエリーエンジンやクエリールーターは比較的理解しやすいので、あえて示した。MemGPTのようなメタ内部メモリ管理のヒントと同様に、計画ループ、ツールの使用法、ツールAPIリクエストをフォーマットするモデルの能力を評価する方法に関連する、よりオープンエンドな評価が追加されると、Agentを評価する方法に関する共通の抽象化を提供することは難しくなります。

評決を下す

RAG評価の概要をお読みいただきありがとうございます！簡単な復習として、まず、評価にLLMを使用するという新しいトレンドを紹介しました。これは、反復RAGシステムにとって大幅なコストと時間の節約をもたらします。次に、RAGスタックの評価に使用される従来のメトリクスについて、生成から検索、インデックス作成までの背景を紹介しました。これらのメトリクスの性能を向上させたい構築者のために、インデックス作成、検索、生成のためのいくつかの調整可能なパラメータを示す。これらのシステムの実験的追跡の課題を提示し、RAG評価とエージェント評価の違いについての我々の見解を述べる。本論文がお役に立てば幸いです！