このフェーズでは、言語モデルに対して取得された接地データを含む予想されるユーザー プロンプトを調べることで、取得拡張生成 (RAG) ソリューションを評価します。 このフェーズに到達する前に、前のフェーズを完了する必要があります。 テスト ドキュメントとクエリを収集し、テスト ドキュメントをチャンクし、チャンクをエンリッチし、チャンクを埋め込み、検索インデックスを作成して、検索戦略を実装する必要があります。 次に、これらの各フェーズを評価し、結果が期待値を満たしていることを確認する必要があります。 この時点で、ソリューションからユーザー クエリに関連する基礎データが返されることに自信が持てるはずです。
この基礎データは、ユーザーのクエリに対処するために言語モデルに送信されるプロンプトのコンテキストを形成します。 プロンプト エンジニアリング戦略 は、この記事の範囲外です。 この記事では、基礎データの観点から言語モデルへのエンジニアリングされた呼び出しの評価について説明します。 この記事では、一般的な言語モデル評価メトリックと、モデル評価の計算またはスタンドアロン メトリックとして使用できる特定の類似性と評価メトリックについて説明します。
この記事では、言語モデルのメトリックまたは類似性と評価のメトリックの完全なリストの提供はありません。 重要なポイントは、さまざまなメトリックが特定のユース ケースに対応することです。 ワークロードに関する包括的な理解を持っているのは、あなただけです。 自分とデータ サイエンティストは、測定する対象と最も適切なメトリックを決定する必要があります。
この記事はシリーズの一部です。 最初に 概要 をお読みください。
言語モデルの評価メトリック
基底性、完全性、使用率、関連性、正確性など、言語モデルの応答を評価するために使用する必要があるメトリックがいくつかあります。 RAG パターンの全体的な目標は、応答を生成するときに関連するデータを言語モデルのコンテキストとして提供することです。そのため、これらの各メトリックは高いスコアを付けるのが理想的です。 ただし、ワークロードによっては、互いに優先順位を付ける必要がある場合があります。
重要
言語モデルの応答は非決定的です。つまり、言語モデルに対して同じプロンプトを実行すると、多くの場合、異なる結果が返されます。 このコンセプトは、評価プロセスの一部として言語モデルを把握するのに重要です。 言語モデルの使用を評価するときは、1 つのターゲットではなくターゲット範囲を使用することを検討します。
根拠を理解する
グラウンドネス ( 忠実性とも呼ばれることもあります) は、応答がコンテキストに完全に基づいているかどうかを測定します。 応答がコンテキストに存在するもの以外の情報を使用していないことを立証します。 低い根拠性メトリックは、言語モデルが不正確または無意味な応答を出力している可能性があることを示します。
根拠性を計算する
応答の根拠性を計算するには、次のメソッドを使用します。
- Azure AI Content Safety に基づく基盤 は、自然言語推論を使用して、主張（ここではセクション）がソースドキュメント内のコンテキストに基づいているかどうかを判断するカスタムモデルです。
- 大規模な言語モデルベースの接地は 、言語モデルを使用して応答の接地レベルを決定します。
- Ragas の忠実性ライブラリ。
- MLflow 忠実度の計算。
根拠性を評価する
根拠性の算定地が低いということは、言語モデルでチャンクを関連性のあるものとして認識されていないことを示しています。 コレクションにデータを追加するか、チャンク戦略やサイズを調整するか、プロンプトを微調整する必要があるかを評価してください。
完全性を理解する
完全性は 、応答がクエリのすべての部分に応答するかどうかを測定します。 完全性は、コンテキスト内のチャンクがクエリに適切かつ直接関連しているかどうかを理解し、完全な回答を提供するのに役立ちます。
完全性を計算する
次のメソッドを使用して、応答の完全性を計算できます。
言語モデルを使用して、言語モデルの応答の品質を測定します。 測定するには、質問、コンテキスト、生成された回答が必要です。 次の手順では、大まかなプロセスについて説明します。
- 模言語モデルを使用して、質問の言い換え、要約、または単純化を行います。 このステップでは意図を識別します。
- モデルに、インテントまたはインテントに対する答えが、検索された文書の中にあるか、または検索された文書から導出できるかどうかをチェックするよう求めます。 答えは、各ドキュメントに対して "はい" または "いいえ" にすることができます。 "はい" で始まる回答は、取得したドキュメントがインテントまたはインテントに対する回答に関連していることを示します。
- "はい" で始まる回答を持つインテントの比率を計算します。
- スコアを 2 乗してエラーを強調表示します。
完全性を評価する
完全性が低い場合は、埋め込みモデルを評価して、改善します。 コンテンツ内の語彙と、埋め込みモデルの語彙を比較します。 ドメイン固有の埋め込みモデルが必要かどうか、または既存のモデルを微調整する必要があるかどうかを判断します。 次の手順は、チャンク戦略を評価するためのものです。 固定サイズのチャンクを使用する場合は、チャンクサイズを増やすことを検討してください。 また、問題に完全対処するのに十分なデータがテスト データ内にあるかどうかを評価することもできます。
使用率を理解する
使用率 は、応答がコンテキスト内のチャンクからの情報で構成される範囲を測定します。 目標は、各チャンクがどの程度応答の一部であるかを判断することです。 使用率が低い場合、結果がクエリに関連していない可能性があります。 使用率は、完全性と共に評価する必要があります。
使用率を計算する
言語モデルを使用して使用率を計算します。 応答と、チャンクを含むコンテキストは言語モデルに渡すことができます。 言語モデルに、回答を含むチャンクの数を決定するように依頼できます。
使用率を評価する
次の表で、完全性と使用率を評価する方法を説明します。
| 使用率が高い | 使用率が低い | |
|---|---|---|
| 高い完全性 | 対処は必要ありません。 | 返されたデータは質問に応答しますが、無関係なまとまりも返します。 より可能性の高い結果または決定論的な結果が得られるように、上位 k のパラメーター値を減らすことを検討します。 |
| 完全性が低い | 言語モデルでは、指定したチャンクが使用されますが、完全には質問に対処できません。 次の手順を実行することを検討します。
|
返されたデータは質問に完全には回答せず、指定したチャンクは完全には利用されません。 次の手順を実行することを検討します。
|
関連性
関連性 は、言語モデルの応答が関連し、クエリに関連する範囲を測定します。
関連性を計算する
次のメソッドを使用して、応答の関連性を計算できます。
メモ
Microsoft Foundry ポータルを使用して計算を実行するか、この記事のガイダンスを使用して関連性を自分で計算できます。
関連性を評価する
関連性が低い場合は、次のタスクを実行します。
言語モデルに提供されるチャンクが関連していることを確認します。
- 関連する実行可能なチャンクが返されないかどうかを判断します。 これらのチャンクを検出した場合は、埋め込みモデルを評価します。
- 実行可能なチャンクがない場合は、関連するデータが存在するかどうかを確認します。 存在する場合は、チャンク戦略を評価します。
関連するデータの部分が返された場合は、プロンプトを評価します。
評価方法の完全性のスコアは、関連性スコアに似た結果をもたらすべきです。
正確性を理解する
正確性 は、応答が正確で事実に基づく程度を測定します。
正確性を計算する
次の方法を使用して、正確性を評価できます。
- 言語モデル: 言語モデルを使用して正確性を計算します。 言語モデルに応答を渡すことができます。理想的には、結果の生成に使用される言語モデルとは異なる言語モデルです。 応答が事実かどうかを判断するように言語モデルに依頼できます。
- 外部の信頼できるソース: 外部の信頼できるソースを使用して、応答の正確性を検証します。 信頼できるソースの API に応じて、信頼できるソースのみを使用するか、言語モデルと組み合わせることができます。
正確性を評価する
正確性が低い場合は、次のタスクを実行します。
- 言語モデルに提供されるチャンクが実際には正しく、データ バイアスがないことを確認します。 ソース ドキュメントまたはコンテンツの問題を修正することが必要な場合があります。
- チャンクが事実に基づいて正しい場合は、プロンプトを評価します。
- モデルに、より事実に基づく接地データまたは微調整で克服する必要がある不正確さが継承されているかどうかを評価します。
類似性と評価メトリックを理解する
Data Science で使用できる類似度と評価のメトリックはたくさんあります。 一部のアルゴリズムは、音声テキスト変換や言語間翻訳など、ドメイン固有です。 メトリックの計算については、アルゴリズムごとに独自の戦略があります。
データ サイエンティストは、測定対象と、測定に使用できるメトリックまたはメトリックの組み合わせを決定します。 たとえば、言語翻訳の場合、bilingual evaluation understudy (BLEU) メトリックでは、機械翻訳と人間による翻訳の両方に表示される n グラムの数がチェックされ、翻訳で同じ単語が使用されているかどうかに基づいて類似性が測定されます。 コサイン類似度では、機械翻訳と人間による翻訳の間の埋め込みを使用して、セマンティック類似性を測定します。 目標が高いセマンティック類似性を達成し、人間の翻訳と似た単語を使用することなら、コサイン類似度と高いBLEUスコアの両方が必要です。 セマンティック類似性のみに関心がある場合は、コサイン類似度に焦点を当てます。
次のリストには、一般的な類似性と評価のメトリックのサンプルが含まれています。 一覧表示されている類似性メトリックは、トークン ベース、シーケンス ベース、または編集ベースとして記述されます。 これらの説明は、メトリックが類似性の計算に使用するアプローチを示しています。 このリストには、異なる言語間でテキスト翻訳の品質を評価するための 3 つのアルゴリズムが含まれています。
- 最も長い共通部分文字列 は、2 つの文字列間の最も長い共通部分文字列を検索するシーケンスベースのアルゴリズムです。 最長共通部分文字列の比率は、最長共通部分文字列を取得し、小さいほう、または大きいほうの入力文字列の文字数で除算します。
- 最も長い一般的なサブシーケンス (LCS) は、2 つの文字列間で最も長いサブシーケンスを検出するシーケンス ベースのアルゴリズムです。 LCS では、部分列が連続した順序である必要はありません。
- コサイン類似性 は、2 つのベクトル間の角度のコサインを計算するトークンベースのアルゴリズムです。
- Jaro-Winkler 距離 は、1 つの文字列を別の文字列に変換するための最小ステップ数をカウントする編集ベースのアルゴリズムです。
- ハミング距離 は、1 つの文字列を別の文字列に変換するために必要な置換の最小数を測定する編集ベースのアルゴリズムです。
- Jaccard インデックス は、2 つの文字列の積集合をそれらの文字列の和集合で除算することによって類似性を計算するトークン ベースのアルゴリズムです。
- Levenshtein 距離 は、1 つの文字列を別の文字列に変換するために必要な 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 回限りの操作ではないことを理解することが重要です。 ドキュメントのコレクションは時間の経過共に変化します。 顧客が尋ねる質問は時間の経過とともに変化し、運用から学ぶにつれて質問の種類に対する理解が深まります。 このプロセスを何度も再考する必要があります。 過去の評価の文書を維持することは、将来の設計と評価の取り組みにとって重要です。
責任ある AI、コンテンツの安全性、セキュリティ評価
RAG システムがエンタープライズ ワークフローに深く統合されるにつれて、評価は、根拠や完全性などの従来のメトリックを超えて拡張する必要があります。 責任ある AI プラクティスでは、取得および生成されたコンテンツが安全性、プライバシー、倫理的基準とどのように一致しているかを評価する必要があります。 このセクションでは、セキュリティで保護され、信頼できる状態を維持しながら、RAG ソリューションが効果的であることを確認するのに役立つ責任ある評価の主要なディメンションについて説明します。
コンテンツの安全性評価
RAG システムは、ナレッジ ベースから有害なコンテンツを取得または生成する可能性があり、これは精神的、社会的、または物理的なリスクを引き起こす可能性があります。 評価には、次の種類のコンテンツの検出と軽減が含まれている必要があります。
人種、民族、国籍、性別、性的指向、宗教、移民状態、能力、外観、または体の大きさに基づいて個人またはグループを対象とするヘイトスピーチとバイアス
武器、身体的危害、または負傷または殺害の意図の描写を含む、暴力コンテンツ
自傷行為に関する言及(自傷行為や身体損傷の説明など)
明示的な解剖学的言及、エロ行為、性的暴力、ポルノ、または虐待を含む性的コンテンツ
コンテンツ セーフティなどのツールを使用して、取得したコンテンツに有害な要素のフラグを設定し、スコア付けします。 これらのスコアを評価パイプラインに組み込んで、安全な出力を確保します。
知的財産の保護
以下を含む著作権で保護されたコンテンツを不注意で取得または生成するために RAG システムを評価する必要があります。
曲の歌詞、記事、レシピ、独自のドキュメントなどのテキスト作品。
ロゴ、ブランドアセット、アートワーク、架空のキャラクター、その他の保護された画像などのビジュアル作品。
コンテンツ フィルターと著作権検出モデルを実装して、取得元と生成された応答から保護された素材を特定して除外します。
セキュリティと敵対的脅威
RAG システムは間接的なプロンプトインジェクション攻撃に対して脆弱であり、悪意のある命令が取得されたドキュメントに埋め込まれます。 これらの攻撃の結果として、次のような結果が生じる可能性があります。
ナレッジ ベースからの未承認のデータ公開。
ドキュメントが破損したために応答が改ざんされました。
侵害された取得ソースによる安全制御のバイパス。
セキュリティ評価には、敵対的なテスト、ドキュメントのサニタイズ、異常な取得パターンの監視を含める必要があります。
プライバシーとデータ保護
RAG システムが機密データまたは個人データを含むリポジトリとやり取りする場合、プライバシー リスクの評価は不可欠です。 この種類のデータには、次のものが含まれます。
直接識別子: 名前、社会保障番号、パスポート番号、および国民 ID 番号。
連絡先情報: 電子メール アドレス、電話番号、物理アドレス、および IP アドレス。
財務データ: クレジット カード番号、銀行口座の詳細、トランザクション レコード。
生体認証データ: 指紋、顔認識、音声認識、網膜スキャン。
健康情報: 医療記録、保険情報の詳細、治療履歴など、保護された医療情報 (PHI) や医療保険の携行性と説明責任法 (HIPAA) が含まれます。
雇用データ: 従業員 ID、給与、および業績レビュー。
資格 情報： ユーザー名、パスワード、API キー、アクセス トークン。
自動個人データ検出ツールを使用し、厳密なアクセス制御を適用して、取得および生成中のプライバシー違反を防ぎます。
主な考慮事項
ソースの品質は重要です。 キュレーションおよび審査されたドキュメントは、有害または不適切なコンテンツのリスクを軽減します。
取得によってリスクが増幅する可能性があります。 不適切な取得戦略では、ランダムな可能性よりも安全でないコンテンツが頻繁に表示される可能性があります。
ドキュメントの破損は、次の固有の脅威です。 悪意のあるアクターは、ナレッジ ベースに有害なコンテンツを挿入する可能性があります。
コンテキスト ウィンドウの重要事項: 正当なコンテンツと悪意のあるコンテンツを混在させると、検出と評価が複雑になります。
継続的な監視が必要です。 ドキュメント リポジトリと取得パターンの定期的な監査は、安全性と信頼を維持するために不可欠です。
RAG 実験アクセラレータ リポジトリ
このシリーズの記事では、RAG ソリューションの設計と評価に関連するすべてのフェーズと設計の選択肢について説明します。 彼らは、それを行う方法ではなく、あなたが何をすべきかに焦点を当てています。 Microsoft のトップカスタマーと連携するエンジニアリング チームは 、RAG 実験アクセラレータと呼ばれるツールを開発しました。 RAG 実験アクセラレータは、カスタムのコードベースの実験フレームワークです。 RAG ソリューションの開発を最適化し、強化します。 このフレームワークにより、研究者や開発者は RAG パフォーマンスを促進する重要なコンポーネントを効率的に調査して微調整できます。 このイノベーションにより、最終的には、より正確でコヒーレントなテキスト生成が実現します。
リポジトリ内の実装ではコマンド ライン インターフェイス (CLI) を使用するため、さまざまな埋め込みモデルを簡単に試し、チャンク戦略を調整し、さまざまな検索アプローチを評価して RAG システムの可能性を最大限に引き出すことができます。 ハイパーパラメーター調整用の単純な構成を使用して、RAG 開発の主要な側面に集中するのに役立ちます。
このフレームワークでは、言語モデルの構成に対する包括的なサポートも提供されます。 このサポートは、モデルの複雑さと生成品質の完璧なバランスを取るのに役立ちます。 このツールは、実験を簡略化し、時間を節約し、RAG モデルのパフォーマンスを向上させます。
RAG と Vision アプリケーション フレームワーク
この記事に記載されている RAG ソリューションでのメディアの操作に関するガイダンスの多くは、Microsoft の主要顧客と連携している別のエンジニアリング チームから提供されたものです。 チームは、 RAG with Vision Application Framework というフレームワークを作成しました。 このフレームワークは、MHTML ドキュメントのテキストコンテンツと画像コンテンツの両方を処理する Python ベースの RAG パイプラインを提供します。
フレームワークは、MHTML ファイルからテキストと画像を読み込み、チャンクし、エンリッチします。 その後、データのチャンクが Azure AI 検索に取り込まれます。 このフレームワークは、処理とコスト効率に対して、画像強化のためのキャッシュを実装します。 また、パイプラインの一部として評価も組み込まれています。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
- Raouf Aliouat |ソフトウェア エンジニア II
- Rob Bagby | プリンシパルコンテンツ開発者 - Azureパターンおよびプラクティス
- ポール・執事 |ソフトウェア エンジニア
- プラバルデブ |プリンシパル ソフトウェア エンジニア
- スビ・ハドリ |シニア データ サイエンティスト
- Ritesh Modi |プリンシパル エンジニア
- Ryan Pfalz |シニア テクニカル プログラム マネージャー
- マフディ・セタイシュ |プリンシパル ソフトウェア エンジニア
- ランディ・サーマン |プリンシパル AI クラウド ソリューション アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。