この段階に到達するまでに、検索インデックスがすでに生成され、実行する検索が決定されています。 このフェーズでは、想定されるユーザー プロンプト (取得した基礎データを含む) を大規模言語モデルに照らして評価するという観点から、検索拡張生成 (RAG) ソリューションを評価するプロセスに対処します。 このフェーズに到達する前に、テスト ドキュメントとクエリを収集し、テスト ドキュメントをチャンク化し、チャンクを拡充し、チャンクを埋め込み、検索インデックスを作成し、検索戦略を実装する準備フェーズを完了する必要があります。 これらの各フェーズを評価し、結果に満足する必要があります。 この時点で、ソリューションからユーザー クエリに関連する基礎データが返されることを快適に感じるはずです。
この基礎データは、ユーザーのクエリに対処するために大規模言語モデルに送信されるプロンプトのコンテキストを形成します。 プロンプト エンジニアリング戦略 は、この記事の範囲外です。 この記事では、基礎データの観点から大規模言語モデルへのエンジニアリングされた呼び出しの評価について説明します。 この記事では、一般的な大規模な言語モデル評価メトリックの 一部 と、大規模言語モデル評価の計算に使用できるかスタンドアロン メトリックとして使用できる、特定の類似性と評価メトリックについて説明します。
この記事では、大規模言語モデルのメトリックまたは類似性と評価のメトリックの完全なリストの提供はありません。 これらのメトリックの数は毎日増加しています。 この記事で説明する重要なポイントは、さまざまなメトリックがあり、メトリックごとに独自のユース ケースがあるということです。 自分のワークロードを全体的に理解できるのは、あなただけです。 データ サイエンティストと一緒に、測定する内容と、そのタスクの達成に役立つメトリックを決定する必要があります。
この記事はシリーズの一部です。 概要を参照してください。
大規模言語モデルの評価メトリック
大規模な言語モデルの応答を評価するために使用できるメトリックには、根拠性、完全性、使用率、関連性などいくつかあります。
重要
大規模言語モデルの応答は非決定論的です。つまり、大規模言語モデルに対するプロンプトが同じでも、異なる結果が返される可能性があり、多くの場合、異なる結果が返されます。 評価プロセスの一部として大規模言語モデルを使用する場合は、これを理解しておくことが重要です。 大規模言語モデルを使用して評価する場合は、1 つのターゲットに対してターゲット範囲を使用することを検討してください。
現実性
根拠性 (忠実性と呼ばれることもあります) は、応答がコンテキストに完全に基づいているかどうかを測定します。 応答がコンテキストに存在するもの以外の情報を使用していないことを立証します。 根拠性の低いメトリックは、大規模言語モデルが、"幻覚" と呼ばれる想像の領域または無意味な領域に陥っている可能性があることを示します。
計算
- Azure AI Content Safety サービス (AACS) ベースの根拠性 は、自然言語推論 (NLI) を使用して、クレーム (この場合はチャンク) がソース ドキュメントで含意されているかどうかを判断するカスタム モデルです。
- 大規模言語モデル ベースの根拠性 では、大規模言語モデルを使用して、応答の根拠性レベルを決定します。
- Ragas の忠実性ライブラリ
- MLflow の忠実性の計算
評価中
根拠性が低い場合は、大規模言語モデルでは、対象チャンクが関連性があるとは見なされていないことを示します。 コーパスへのデータの追加、チャンク戦略またはチャンク サイズの調整、あるいはプロンプトの微調整が必要かどうかを評価する必要があります。
Completeness
完全性は、応答がクエリのすべての部分に応答しているかどうかを測定します。 完全性は、コンテキスト内のチャンクがクエリに適切かつ直接関連しているかどうかを理解し、完全な回答を提供するのに役立ちます。
計算
- AI 支援: 取得スコアのプロンプト
- 大規模言語モデルは、大規模言語モデルの応答の品質を測定するのに役立ちます。 この測定を実行するには、質問、コンテキスト、生成された回答が必要です。 大まかなプロセスの概要を次に示します。
- 大規模言語モデルを使用して、質問の言い換え、要約、または単純化を行います。 このステップでは意図を識別します。
- モデルに、各ドキュメントに対して回答が「いいえ」または「はい」になる可能性がある、取得されたドキュメントから意図または意図に対する回答が見つかるか、または導き出せるかどうかを確認するように要求します。 "はい" で始まる回答は、取得したドキュメントが意図または意図に対する回答に関連していることを示します。
- "はい" で始まる回答を持つ意図の比率を計算します。
- スコアを 2 乗してエラーを強調表示します。
評価中
完全性が低い場合は、埋め込みモデルの評価から始めます。 コンテンツ内のボキャブラリと、選択した埋め込みモデルのボキャブラリを比較します。 ドメイン固有の埋め込みモデルが必要かどうか、または既存のモデルを微調整する必要があるかどうかを判断します。 次の手順として、チャンク戦略を評価します。 固定長を使用している場合は、チャンク サイズを増やすことを検討してください。 また、問題に完全対処するのに十分なデータがテスト データ内にあるかどうかを評価することもできます。
稼働率
使用率では、応答の構成要素として、コンテキスト内のチャンクからの情報がどの程度を占めているかを測定します。 目標は、応答の一部となっている各チャンクの規模を判断することです。 使用率が低い場合、結果がクエリに関連していない可能性があります。 使用率は、完全性と共に評価する必要があります。
計算
大規模言語モデルを使用して、使用率を計算できます。 応答と、チャンクを含むコンテキストは大規模言語モデルに渡すことができます。 大規模言語モデルに、回答に必要なチャンクの数を決定するよう指示できます。
評価中
完全性と使用率の両方をまとめたガイダンスを次の表に示します。
| 使用率が高い | 使用率が低い | |
|---|---|---|
| 完全性が高い | 操作は不要です | この場合、返されたデータは質問に対処できますが、無関係なチャンクが返されました。 より可能性の高い結果または決定論的な結果が得られるように、上位 k のパラメーター値を減らすことを検討してください。 |
| 完全性が低い | この場合、提供したチャンクは使用されていますが、質問に完全には対応していません。 次の点について検討してください。
|
この場合、質問に完全に答えておらず、提供しているチャンクが十分に活用されていません。 これらの問題に対処するには次を検討してください。
|
関連性
大規模言語モデルの応答がどの程度適切で、クエリに関連しているかを測定します。
計算
- AI 支援: Azure AI Studio での関連性 - Azure AI Studio を使用して計算を実行するか、この記事のガイダンスを使用して関連性を自分で計算できます。
- Ragas の回答の関連性ライブラリ
- MLflow の関連性の計算
評価中
関連性が低い場合は、次を評価します。
- 大規模言語モデルに提供されるチャンクが関連していることを確認します。
- 返されなかった関連する有効なチャンクがあるかどうかを判断します。 ある場合は、埋め込みモデルを評価します。
- 実行可能なチャンクがない場合は、関連するデータが存在するかどうかを確認します。 存在する場合は、チャンク戦略を評価します。
- 関連性のあるチャンクが返された場合は、プロンプトを評価します。
完全性 などの他の評価方法を計算し、関連性測定で観察されたものと同様のスコアを生成する必要があります。
類似性と評価のメトリック
概要で説明したように、データ サイエンスでは、数百もの類似性と評価のメトリックが使用されています。 一部のアルゴリズムは、音声テキスト変換や言語間翻訳など、ドメイン固有です。 メトリックの計算については、アルゴリズムごとに独自の戦略があります。
データ科学者は、測定する対象と、測定に使用できるメトリックまたはメトリックの組み合わせを決定します。 たとえば、言語翻訳の領域では、Bleu メトリックが、機械翻訳と人間による翻訳の両方に表示される n-gram の数を確認し、同じ単語の使用に基づいて類似性を測定します。 コサイン類似度では、機械翻訳と人間による翻訳の間の埋め込みを使用して、セマンティック類似性を測定します。 高いセマンティック類似性を持ち、人間による翻訳に似た単語を使用することが目的だった場合、高いコサイン類似度を持つ高い Bleu スコアが目標になります。 セマンティック類似性のみに関心がある場合は、コサイン類似度に焦点を当てます。
次のリストには、一般的な類似性と評価のメトリックの小さなサンプルが含まれています。 一覧表示されている類似性メトリックは、トークン ベース、シーケンス ベース、または編集ベースとして記述され、類似性の計算に大きく異なるアプローチを使用する方法を示していることにご注意ください。 また、リストには、異なる言語間でテキスト翻訳の品質を評価するための 3 つのアルゴリズムが含まれていることにもご注意ください。
- 最長共通部分文字列 - 2 つの文字列間で最も長い共通部分文字列を検索するシーケンス ベースのアルゴリズム。 最長共通部分文字列の比率は、最長共通部分文字列を取得し、小さいほう、または大きいほうの入力文字列の文字数で除算します。
- 最長共通部分列 (LCS) - 2 つの文字列間で最も長い部分列を検索するシーケンス ベースのアルゴリズム。 LCS では、部分列が連続した順序である必要はありません。
- コサイン類似度 - 2 つのベクトル間で角度のコサインを計算するトークン ベースのアルゴリズム。
- Jaro Winkler - ある文字列を別の文字列に変換するための最小ステップ数をカウントする編集ベースのアルゴリズム。
- ハミング - ある文字列を別の文字列に変換するのに必要な代入の最小数を測定する編集ベースのアルゴリズム。
- Jaccard - 2 つの文字列の積集合をそれらの文字列の和集合で除算して類似性を計算するトークン ベースのアルゴリズム。
- Levenshtein - ある文字列を別の文字列に変換するのに必要な 1 文字の編集の最小数を決定して類似性を計算する、編集ベースのアルゴリズム。
- BLEU - ある言語から別の言語への機械翻訳の結果であるテキストの品質を評価します。 Bleu は、機械翻訳と人間品質の翻訳間で n-gram の重複を計算して、この評価を行います。
- ROUGE - ある言語から別の言語への機械翻訳を人間が作成した翻訳と比較します。 n-gram、skip-bigram、または最長共通部分列の重複を使用する ROUGE バリアントがいくつかあります。
- METEOR - 完全一致、ステミング後の一致、同意語、言い換え、配置を調べて、機械翻訳の結果であるテキストの品質を評価します。
一般的な類似性と評価のメトリックについては、次のリソースを参照してください。
ドキュメント、レポート、集計
結果に対するハイパーパラメーターの影響を理解できるように、実験用に選択したハイパーパラメーターと結果の評価メトリックの両方を文書化する必要があります。 ハイパーパラメーターと結果は、埋め込みや検索評価などの詳細レベルと、システム全体をエンド ツー エンドでテストするなどのマクロ レベルで文書化する必要があります。
設計と開発時に、ハイパーパラメーターと結果を手動で追跡できる場合があります。 ただし、テスト ドキュメント全体とテスト クエリ コーパスに対して複数の評価を実行すると、数百の評価実行と数千の結果が生じる場合があります。 評価のパラメーターと結果の永続化を自動化する必要があります。
ハイパーパラメーターと結果が永続化されたら、ハイパーパラメーターの選択肢がメトリックに与える影響をより簡単に視覚化できるように、チャートとグラフの作成を検討する必要があります。 視覚化により、どの選択がパフォーマンスの低下や急増につながるかを特定できます。
RAG ソリューションの設計と評価は 1 回限りの操作ではないことを理解することが重要です。 ドキュメントのコーパスは時間の経過とともに変化します。 顧客が尋ねる質問は時間の経過とともに変化し、運用から学ぶにつれて質問の種類に対する理解が深まります。 このプロセスを何度も再考する必要があります。 過去の評価の文書を維持することは、将来の設計と評価の取り組みにとって重要です。
RAG 実験アクセラレータ
これらの記事では、RAG ソリューションの設計と評価に関わるすべてのフェーズと設計の選択肢について説明します。 方法ではなく、何を実行すべきかに焦点を当てています。 Microsoft の主要顧客と協力するエンジニアリング チームが、 RAG Experiment Acceleratorと呼ばれるツールを開発しました。 RAG 実験アクセラレータは、検索拡張生成 (RAG) ソリューションの開発を最適化および強化するために設計された最先端の実験フレームワークです。 RAG 実験アクセラレータを使用すると、研究者や開発者は RAG パフォーマンスを向上させる重要なコンポーネントを効率的に調査して微調整することができ、最終的にはより正確で一貫性のあるテキスト生成が可能になります。
CLI ベースのインターフェイスを使用すると、さまざまな埋め込みモデルを簡単に実験でき、チャンク戦略を調整し、さまざまな検索アプローチを評価して RAG システムの可能性を最大限に引き出すことができます。 単純な構成を使用してハイパーパラメーター チューニングの複雑さを抽象化しながら、RAG 開発の中核的側面に集中できます。
さらに、このフレームワークには大規模言語モデル構成の包括的サポートが用意されているため、モデルの複雑さと生成品質の完璧なバランスを実現できます。 このツールを使用すると、実験プロセスを効率化して貴重な時間を節約し、RAG モデルのパフォーマンスを大幅に向上させることができます。
自然言語理解の限界を押し広げている熟練した研究者であっても、テキスト生成機能の強化を目指す業界の専門家であっても、この実験フレームワークは RAG 開発の取り組みを加速させる究極のソリューションです。 RAG 実験の未来を受け入れ、この最先端のツールを使用してモデルの真の可能性を引き出しましょう。
RAG と Vision アプリケーション フレームワーク
この記事に記載されている RAG ソリューションでのメディアの操作に関するガイダンスの多くは、Microsoft の主要顧客と連携している別のエンジニアリング チームから提供されたものです。 このチームは、 RAG with Vision Application Frameworkと呼ばれるフレームワークを作成しました。 このフレームワークは、MHTML ドキュメントのテキスト コンテンツと画像コンテンツの両方を処理する Python ベースの検索拡張生成 (RAG) パイプラインを提供します。
フレームワークは、MHTML ファイルからテキストと画像の両方を読み込み、チャンク化し、強化し、チャンクを Azure Search に取り込みます。 このフレームワークは、処理とコスト効率の両方のために、画像強化のためのキャッシュを実装します。 このフレームワークには、パイプラインの一部として評価も組み込まれています。
共同作成者
- Ritesh Modi
- Rob Bagby
- Ryan Pfalz
- Raouf Aliouat
- Randy Thurman
- Prabal Deb
- Mahdi Setayesh
- Soubhi Hadri
- Paul Butler