大規模言語モデルのエンドツーエンドの評価フェーズ
このフェーズでは、言語モデルに対して取得されたグラウンド データを含む予想されるユーザー プロンプトを調べることで、Retrieval-Augmented Generation (RAG) ソリューションを評価します。 このフェーズに到達する前に、前のフェーズを完了する必要があります。 テスト ドキュメントとクエリを収集し、テスト ドキュメントをチャンクし、チャンクをエンリッチし、チャンクを埋め込み、検索インデックスを作成し、検索戦略を実装する必要があります。 次に、これらの各フェーズを評価し、結果が期待値を満たしていることを確認する必要があります。 この時点で、ソリューションからユーザー クエリに関連する基礎データが返されることに自信が持てるはずです。
この基礎データは、ユーザーのクエリに対処するために言語モデルに送信されるプロンプトのコンテキストを形成します。 プロンプト エンジニアリング戦略は、この記事の範囲外です。 この記事では、基礎データの観点から言語モデルへのエンジニアリングされた呼び出しの評価について説明します。 この記事では、一般的な言語モデル評価メトリックと、モデル評価の計算またはスタンドアロン メトリックとして使用できる特定の類似性と評価メトリックについて説明します。
この記事では、言語モデルのメトリックまたは類似性と評価のメトリックの完全なリストの提供はありません。 この記事で説明する重要なポイントは、さまざまなユース ケースがあるメトリックがあります。 ワークロードを包括的に理解できるのは、自分だけです。 自分とデータ サイエンティストは、測定対象と適切なメトリックを決定する必要があります。
この記事はシリーズの一部です。 最初に、「概要」を参照してください。
言語モデルの評価メトリック
基底性、完全性、使用率、関連性、正確性など、言語モデルの応答を評価するために使用する必要があるメトリックがいくつかあります。 RAG パターンの全体的な目標は、応答を生成するときに関連するデータを言語モデルのコンテキストとして提供することです。理想的には、上記の各メトリックは高いスコアを付ける必要があります。 ただし、ワークロードによっては、互いに優先順位を付ける必要がある場合があります。
重要
言語モデルの応答は非決定的です。つまり、言語モデルに対して同じプロンプトを実行すると、多くの場合、異なる結果が返されます。 このコンセプトは、評価プロセスの一部として言語モデルを把握するのに重要です。 言語モデルの使用を評価するときは、1 つのターゲットではなくターゲット範囲を使用することを検討します。
現実性
根拠性は、忠実度とも呼ばれ、応答が文脈に完全に基づいているかを測定します。 応答がコンテキストに存在するもの以外の情報を使用していないことを立証します。 低い根拠性メトリックは、言語モデルが不正確または無意味な応答を出力している可能性があることを示します。
根拠性を計算する
応答の根拠性を計算するには、次のメソッドを使用します。
- Azure AI Content Safety ベースの根拠性は、自然言語推論を使用して、クレーム (この場合はチャンク) がソース ドキュメント内のコンテキストに基づいているかどうかを判断するカスタム モデルです。
- 大規模言語モデル ベースの根拠性 では、模言語モデルを使用して、応答の根拠性レベルを決定します。
- Ragas の忠実性ライブラリ。
- MLflow の忠実性の計算。
根拠性を評価する
根拠性の算定地が低いということは、言語モデルでチャンクを関連性のあるものとして認識されていないことを示しています。 コレクションにデータを追加するか、チャンク戦略やサイズを調整するか、プロンプトを微調整する必要があるかを評価してください。
Completeness
完全性は、応答がクエリのすべての部分に応答しているかどうかを測定します。 完全性は、コンテキスト内のチャンクがクエリに適切かつ直接関連しているかどうかを理解し、完全な回答を提供するのに役立ちます。
完全性を計算する
応答の完全性を計算するには、次のメソッドを使用します。
- AI 支援による検索スコアのプロンプト。
- 言語モデルは、言語モデルの応答の品質を測定するのに役立ちます。 測定するには、質問、コンテキスト、生成された回答が必要です。 次の手順は、大まかなプロセスを簡潔に説明します。
- 模言語モデルを使用して、質問の言い換え、要約、または単純化を行います。 このステップでは意図を識別します。
- モデルに、インテントまたはインテントに対する答えが、検索された文書の中にあるか、または検索された文書から導出できるかどうかをチェックするよう求めます。 答えは、各ドキュメントに対して "はい" または "いいえ" にすることができます。 "はい" で始まる回答は、取得したドキュメントがインテントまたはインテントに対する回答に関連していることを示します。
- "はい" で始まる回答を持つインテントの比率を計算します。
- スコアを 2 乗してエラーを強調表示します。
完全性を評価する
完全性が低い場合は、埋め込みモデルを評価して、改善します。 コンテンツ内の語彙と、埋め込みモデルの語彙を比較します。 ドメイン固有の埋め込みモデルが必要かどうか、または既存のモデルを微調整する必要があるかどうかを判断します。 次の手順は、チャンク戦略を評価するためのものです。 固定サイズのチャンクを使用する場合は、チャンクサイズを増やすことを検討してください。 また、問題に完全対処するのに十分なデータがテスト データ内にあるかどうかを評価することもできます。
稼働率
利用度 は、応答がコンテキスト内のチャンク情報でどの程度構成されているかを測定します。 目標は、各チャンクがどの程度応答の一部であるかを判断することです。 使用率が低い場合、結果がクエリに関連していない可能性があります。 使用率は、完全性と共に評価する必要があります。
使用率を計算する
言語モデルを使用して使用率を計算します。 応答と、チャンクを含むコンテキストは言語モデルに渡すことができます。 言語モデルに、回答に必要なチャンク数を決定するよう指示できます。
使用率を評価する
次の表で、完全性と使用率を評価する方法を説明します。
使用率が高い | 使用率が低い | |
---|---|---|
完全性が高い | 対処は必要ありません。 | この場合、返されたデータは質問に対処しますが、無関係なチャンクも返します。 より可能性の高い結果または決定論的な結果が得られるように、上位 k のパラメーター値を減らすことを検討します。 |
完全性が低い | この場合、言語モデルは指定したチャンクを使用しますが、質問に完全には対処しません。 次の手順を実行することを検討します。
|
この場合、返されるデータは質問に完全には回答せず、指定したチャンクは完全には利用されません。 次の手順を実行することを検討します。
|
関連性
関連性は、言語モデルの応答がどの程度適切で、クエリに関連しているかを測定します。
関連性を計算する
応答の関連性を計算するには、次のメソッドを使用します。
メモ
Azure AI Foundry ポータルを使用して計算を実行するか、この記事のガイダンスを使用して関連性を自分で計算できます。
関連性を評価する
関連性が低い場合は、次のタスクを実行します。
- 言語モデルに提供されるチャンクが関連していることを確認します。
- 関連する実行可能なチャンクが返されないかどうかを判断します。 これらのチャンクを検出した場合は、埋め込みモデルを評価します。
- 実行可能なチャンクがない場合は、関連するデータが存在するかどうかを確認します。 存在する場合は、チャンク戦略を評価します。
- 関連性のあるチャンクが返された場合は、プロンプトを評価します。
評価方法として、完全性や 出力のスコアは、関連性スコアに似た結果を得るべきです。
正確性
正確性 は、応答が正確で事実に基づく程度を測定します。
正確性を計算する
正確性を評価するには、次のようないくつかの方法があります。
- 言語モデル - 言語モデルを使用して正確性を計算します。 言語モデルに応答を渡すことができます。理想的には、結果の生成に使用される言語モデルとは異なる言語モデルです。 応答が事実かどうかを判断するように言語モデルに依頼できます。
- 外部の信頼できるソース - 外部の信頼できるソースを使用して、応答の正確性を検証します。 信頼できるソースの API に応じて、信頼できるソースのみを使用することも、言語モデルと共に使用することもできます。
正確性を評価する
正確性が低い場合は、次のタスクを実行します。
- 言語モデルに提供されるチャンクが実際には正しく、データ バイアスがないことを確認します。 ソース ドキュメントまたはコンテンツの問題を修正する必要がある場合があります。
- チャンクが事実に基づいて正しい場合は、プロンプトを評価します。
- モデルに、追加のファクト グラウンド データまたは微調整で克服する必要がある不正確さが継承されているかどうかを評価します。
類似性と評価のメトリック
Data Science で使用できる類似度と評価のメトリックはたくさんあります。 一部のアルゴリズムは、音声テキスト変換や言語間翻訳など、ドメイン固有です。 メトリックの計算については、アルゴリズムごとに独自の戦略があります。
データ サイエンティストは、測定対象と、測定に使用できるメトリックまたはメトリックの組み合わせを決定します。 たとえば、言語翻訳の場合、bilingual evaluation understudy (BLEU) メトリックでは、機械翻訳と人間による翻訳の両方に表示される n グラムの数がチェックされ、翻訳で同じ単語が使用されているかどうかに基づいて類似性が測定されます。 コサイン類似度では、機械翻訳と人間による翻訳の間の埋め込みを使用して、セマンティック類似性を測定します。 目標が高いセマンティック類似性を達成し、人間の翻訳と似た単語を使用することなら、コサイン類似度と高いBLEUスコアの両方が必要です。 セマンティック類似性のみに関心がある場合は、コサイン類似度に焦点を当てます。
次のリストには、一般的な類似性と評価のメトリックのサンプルが含まれています。 一覧表示されている類似性メトリックは、トークン ベース、シーケンス ベース、または編集ベースとして記述されていることに注意してください。 これらの説明は、メトリックが類似性の計算に使用するアプローチを示しています。 このリストには、異なる言語間でテキスト翻訳の品質を評価するための 3 つのアルゴリズムが含まれています。
- 最長共通部分文字列は、2 つの文字列間で最も長い共通部分文字列を検索するシーケンス ベースのアルゴリズムです。 最長共通部分文字列の比率は、最長共通部分文字列を取得し、小さいほう、または大きいほうの入力文字列の文字数で除算します。
- 最長共通部分列 (LCS) は、2 つの文字列間で最も長い部分列を検索するシーケンス ベースのアルゴリズムです。 LCS では、部分列が連続した順序である必要はありません。
- コサイン類似度は、2 つのベクトル間で角度のコサインを計算するトークン ベースのアルゴリズムです。
- Jaro-Winkler distance は、ある文字列を別の文字列に変換するための最小ステップ数をカウントする編集ベースのアルゴリズムです。
- ハミング距離は、ある文字列を別の文字列に変換するのに必要な代入の最小数を測定する編集ベースのアルゴリズムです。
- Jaccard 指数は、2 つの文字列の積集合をそれらの文字列の和集合で除算して類似性を計算するトークン ベースのアルゴリズムです。
- レーベンシュタイン距離は、ある文字列を別の文字列に変換するのに必要な 1 文字の編集の最小数を決定して類似性を計算する、編集ベースのアルゴリズムです。
- BLEU は、ある言語から別の言語への機械翻訳の結果であるテキストの品質を評価します。 BLEU は、機械翻訳と人間品質の翻訳間で n-gram の重複を計算して、この評価を行います。
- ROUGE は、ある言語の機械翻訳と人間が作成した翻訳を比較するメトリックです。 n-gram、skip-bigram、または最長共通部分列の重複を使用する ROUGE バリアントがいくつかあります。
- METEOR は、完全一致、ステミング後の一致、同意語、言い換え、配置を調べて、機械翻訳の結果であるテキストの品質を評価します。
一般的な類似性と評価メトリックの詳細については、次のリソースを参照してください。
複数の評価メトリックを一緒に使用する
言語モデル評価メトリックを一緒に使用して、RAG ソリューションのパフォーマンスを把握する必要があります。 複数の評価メトリックを一緒に使用する例をいくつか次に示します。
根拠性と正確性
根拠と正確性のメトリックは、システムがコンテキストを正確に解釈して使用しているかどうかを判断するのに役立ちます。 接地性が高くても正確性が低い場合は、言語モデルがコンテキストを使用しているが、正しくない応答を提供することを意味します。 不適切な応答は、コンテキストの不適切な使用やソース データの問題が原因である可能性があります。 たとえば、接地が 0.9 で、正確性が 0.4 の場合、システムは正しいソース マテリアルを参照しているが、正しくない結論が得られたことを示します。 「アインシュタインは量子力学を開発した」という応答を、アイントと量子の両方の力学に個別に言及するコンテキストに基づいて考えてみましょう。 この応答は根拠はありますが、実際には正しくありません。
このメトリックの組み合わせは、一方のメトリックを他のメトリックよりも優先することが、特定のワークロードにとって非常に重要な場合があります。 たとえば、ソース データに誤った情報が意図的に含まれている可能性があり、システムがその誤った情報を応答に保持することが重要な場合です。 その場合は、正しい応答よりも根拠のある応答に優先順位を付ける必要があります。 それ以外の場合は、ワークロードは、コンテキスト データを参照するのことが求められますが、最終的には、正確性が優先されます。
使用率と完全性
使用率と完全性のメトリックは、一緒に取得システムの有効性を評価するのに役立ちます。 使用率 (0.9) が高く、完全性が低い (0.3) と、システムが正確だが不完全な情報を取得したことを示します。 例えば、第二次世界大戦の原因について尋ねられると、システムはポーランドの侵略に関する情報を完全に取得するかもしれないが、他の重要な要因を見逃すかもしれない。 このシナリオは、コンテキストの一部として使用されなかった関連情報を含むチャンクがあることを示している可能性があります。 このシナリオに対処するには、より多くのチャンクを返し、チャンクのランク付け戦略を評価し、プロンプトを評価することを検討してください。
基礎性と活用と類似性
根拠、使用率、類似性のメトリックを組み合わせることで、情報を変換しながら、システムが信頼度をどの程度維持しているかを特定できます。 高い接地性 (0.9) と使用率 (.9) と類似性の低い (0.3) は、システムが正確な接地データを使用しているが、言い換えは不適切であることを示します。 このシナリオに対処するには、プロンプトを評価します。 プロンプトを変更し、結果をテストします。
ドキュメント、レポート、集計
ハイパーパラメーターが結果にどのように影響するかを理解できるように、実験に選択したハイパーパラメーターと、その結果の評価指標の両方を文書化する必要があります。 ハイパーパラメーターと結果は、埋め込みや検索評価などの詳細レベルと、システム全体をエンド ツー エンドでテストするなどのマクロ レベルで文書化する必要があります。
設計と開発時に、ハイパーパラメーターと結果を手動で追跡できる場合があります。 ただし、テスト ドキュメント全体とテスト クエリ コレクションに対して複数の評価を実行すると、数百の評価実行と数千の結果が生じる場合があります。 評価のパラメーターと結果の永続化を自動化する必要があります。
ハイパーパラメーターと結果が保存されたら、ハイパーパラメーターがメトリックに与える影響を視覚化するのに役立つチャートやグラフを作成することを検討してください。 視覚化により、どの選択がパフォーマンスの低下や急増につながるかを特定できます。
RAG ソリューションの設計と評価は 1 回限りの操作ではないことを理解することが重要です。 ドキュメントのコレクションは時間の経過共に変化します。 顧客が尋ねる質問は時間の経過とともに変化し、運用から学ぶにつれて質問の種類に対する理解が深まります。 このプロセスを何度も再考する必要があります。 過去の評価の文書を維持することは、将来の設計と評価の取り組みにとって重要です。
RAG 実験アクセラレータ
これらの記事では、RAG ソリューションの設計と評価に関わるすべてのフェーズと設計の選択肢について説明します。 方法ではなく、何を実行すべきかに焦点を当てています。 Microsoft の主要顧客と協力するエンジニアリング チームが、 RAG Experiment Acceleratorと呼ばれるツールを開発しました。 RAG Experiment Accelerator は、最先端の実験フレームワークです。 RAG ソリューションの開発を最適化し、強化するように設計されています。 RAG Experiment Accelerator を使用すると、研究者や開発者は RAG のパフォーマンスを向上させる重要なコンポーネントを効率的に調査して微調整できます。 このイノベーションにより、最終的には、より正確でコヒーレントなテキスト生成が実現します。
RAG Experiment Accelerator はコマンドライン インターフェイスを使用するため、さまざまな埋め込みモデルを簡単に試したり、チャンク戦略を調整したり、さまざまな検索アプローチを評価して RAG システムの可能性を最大限に引き出すことができます。 ハイパーパラメーター調整用の単純な構成を使用して、RAG 開発の主要な側面に焦点を当てることができます。
このフレームワークでは、言語モデルの構成に対する包括的なサポートも提供されます。 このサポートは、モデルの複雑さと生成品質の完璧なバランスを取るのに役立ちます。 このツールを使用すると、実験プロセスを効率化し、時間を節約し、RAG モデルのパフォーマンスを大幅に向上させることができます。
RAG と Vision アプリケーション フレームワーク
この記事に記載されている RAG ソリューションでのメディアの操作に関するガイダンスの多くは、Microsoft の主要顧客と連携している別のエンジニアリング チームから提供されたものです。 このチームは、 RAG with Vision Application Frameworkと呼ばれるフレームワークを作成しました。 このフレームワークは、MHTML ドキュメントのテキスト コンテンツと画像コンテンツの両方を処理する Python ベースの RAG パイプラインを提供します。
フレームワークは、MHTML ファイルからテキストと画像を読み込み、チャンクし、エンリッチします。 その後、データのチャンクが Azure AI 検索に取り込まれます。 このフレームワークは、処理とコスト効率に対して、画像強化のためのキャッシュを実装します。 このフレームワークには、パイプラインの一部として評価も組み込まれています。
貢献者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- Raouf Aliouat | Software Engineer II
- Rob Bagby | Principal Architecture Center Content Lead
- Paul Butler | Software Engineer
- Prabal Deb | Principal Software Engineer
- Soubhi Hadri | Senior Data Scientist
- Ritesh Modi | 主任技師
- Ryan Pfalz | Senior Technical Program Manager
- Mahdi Setayesh | Principal Software Engineer
- Randy Thurman | Principal AI Cloud Solution Architect