この記事は約5分で読めます。
サーバーワークスの村上です。
お客様の生成AI活用支援では、RAGの運用を支援する機会も多いです。
このブログでは、RAGのオフライン評価についてご紹介します。
オフライン評価とは
オフライン評価とは、ユーザーにRAGを使ってもらうのではなく、評価データセットに対して評価スコアを算出する評価手法です。
人間が評価するオンライン評価は正確性が高いため、本来はオンライン評価を優先すべきではあるのですが、マンパワーを要するのが難点です。
反対にオフライン評価は機械的にスコアを算出できるため、多くのケースを少ない工数で評価できる点にメリットがあります。
シーン設定
RAGの導入は済んでいる
PoCレベルで構いませんが、すでにRAGは導入済みと仮定します。本ブログではAmazon BedrockのKnowledge Baseとします。
これから導入するという方はAWSが作成しているGenerative AI Use Cases JP (GenU)が取り組みやすいです。サーバーワークスで支援も可能です。
ユーザーの使用履歴を保存している
ユーザーがLLMへ入力した内容やLLMからの出力を保存しているものと仮定します。
GenUを使っている場合はDynamoDBに情報が保存されます。
結論
- 手っ取り早く評価したい場合、すでにあるRAGの使用履歴をそのまま評価データセットとして採用し、RagasのResponse Relevancyで評価する（可能であればFaithfulnessも取得する）。
- プロンプトに対する参照回答（referenceResponses）を用意できる場合は、AWSのRAG評価機能を使う。AWSの機能が要件にマッチしない場合はRagasなどのツールを活用する。
AWSのRAG評価機能を使う場合
2024年のre:InventにてRAGの評価機能が登場しました。本機能を使う場合について記載します。
やること①評価データセットを作成する
AWSのRAG評価機能を使う場合、評価データセットの作成が前提となります。
以下、RAG評価機能のイメージ図です。
プロンプトに対して本来検索されるべきコンテキスト（referenceContexts）または望ましい回答（referenceResponses）を準備し、Jsonl形式でAmazon S3に保存する必要があります。
評価データセットの準備にはある程度のマンパワーが必要ですが、ユーザーのRAG利用傾向が変わらない限り、継続的に使えるものになりますのでメリットはあると考えます。
やること②RAG評価ジョブを作成する
作成した評価データセットを使って、RAGを評価します。
利用の流れや取得できるメトリクスは、以前のブログに記載していますので詳細は割愛します。
やること③精度が悪いケースを特定する
評価ジョブによってメトリクスを取得したら、LLMの回答精度が悪かったケースを発見できます。例えばCorrectness（正確性）の数値が低いケースなど。
これらのケースに対して、なぜ精度が低かったのか分析し、改善を試みます。
ここが難しいところではありますが、RAGのデータフローの処理ステップごとに採れるアプローチがいくつかあります。下記のブログが参考になります。
やること④以前のバージョンとメトリクスを比較する
ある設定変更を行い、特定の質問・回答で精度が良くなったとしても、全体としては改悪となっている可能性もあります。
そのため設定変更したら、再度評価ジョブを作成し、評価します。
AWSのRAG評価機能には、以前の評価ジョブと比較できる機能があり、設定変更前後でメトリクスの変化を確認できます。
※Amazon Bedrock の新しい RAG 評価機能と LLM-as-a-Judge 機能 | Amazon Web Services ブログより引用
この比較で改善したことが確認できたら、本番環境に適用するなどの運用サイクルが考えられます。
Ragasを使う場合
RagasはRAGの評価で有名なツールです。AWSのRAG評価機能を使わずにRagasを使う場合もあります。
やること①Response Relevancyの算出
AWSのRAG評価機能とは異なり、評価データセットを作りこまなくても取得できるメトリクスがあります。
それがResponse Relevancy（回答の関連性）で、ユーザーの入力とLLMからの出力があれば算出できます。
ただし、注意すべき点として、Response Relevancyはあくまで質問と回答の関連性を測るものであり、回答の正確性は測れないという点です。
メトリクスの算出ロジックは、「ユーザーのプロンプト」と「LLMの出力から想定されるプロンプト」のコサイン類似度を計算するというものです。
そのため、LLMの出力にハルシネーションが発生していても、出力から想定されるプロンプトがユーザーのプロンプトと類似してればメトリクス自体は高く出てしまうからです（あくまで関連性であり正確性ではない）
やること②Faithfulnessの算出
Faithfulness（忠実性）はLLMの出力がRAGで検索されたコンテキストにどれだけ一致しているかを測るメトリクスです。
算出にはコンテキスト（retrieved context）とLLMからの出力（response）が必要です。
冒頭に記載の通り、データベースにRAGの履歴（ユーザーのプロンプトとLLMの出力）を保存している想定ですが、コンテキストは保存していないケースもあるかもしれません。その場合、Faithfulnessを算出するには追加でコンテキストも保存する必要があります。
Faithfulnessは、Response relevancyよりもハルシネーションを発見しやすいメトリクスであるのが特徴です。コンテキストの内容から逸脱した出力（＝ハルシネーション）があるとFaithfulnessのスコアは低くなるからです。
やること③評価データセットを作成しAnswer Correctnessなどを算出
以降はAWSのRAG評価機能と同様ですが、ユーザーの入力に対する望ましい回答（ground truth）などを評価データセットとして用意し、Answer Correctness（回答の正確性）など追加のメトリクスを取得することで、示唆を得ることが可能です。
まとめ
- どのメトリクスを取得すれば、どんな情報が手に入るのか
- そのメトリクスを取得するためには、どんな情報が必要なのか
以上を整理することで理解が進むと思います。このブログが参考になれば幸いです。
