re:Invent 2024: Amazon BedrockのRAGとモデル評価を効率化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Streamline RAG and model evaluation with Amazon Bedrock (AIM359)
この動画では、Amazon Bedrockにおける評価機能の詳細について解説しています。特に、LLM-as-a-judgeという新機能を用いたモデル評価とRAG評価に焦点を当て、品質、レイテンシー、運用コストのトレードオフを考慮した評価方法を紹介しています。Correctness、Completeness、Helpfulness、Logical Coherenceなど9つの評価指標が用意され、0から1の範囲でスコアリングされる仕組みや、評価結果の比較機能、Spider Chartによる可視化など、実用的な機能が実装されています。また、Amazon Bedrock Knowledge Baseと統合されたRAG評価では、Context CoverageやContext Relevanceといった検索性能の評価も可能で、これらの機能によって数週間かかっていた評価作業を数回のクリックで完了できるようになっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Bedrockにおける評価の重要性と本日のアジェンダ
Generative AIアプリケーションを構築するのに役立つ素晴らしいツールや機能が数多くありますが、それらが本当に適切で、期待通りの性能を発揮するかどうかをどのように判断すればよいのでしょうか？評価、そしてさらに評価を重ねる必要があります。本日は、評価について詳しくお話しさせていただきます。私はAmazon Bedrockのプロダクトマネージャーの一人、Jesse Mandersです。後ほど、同僚のSharaとHardikがデモをご紹介させていただきます。
本日は、Amazon Bedrockにおける RAG評価とモデル評価の効率化についてお話しします。 こちらが本日のアジェンダです。まず評価の課題、その重要性、そして評価とは何かについて説明します。次に、モデル評価スイートの一部として最近導入された「LLM-as-a-judge」という新機能についてご紹介します。その後、Hardikがコンソールでの実際の動作をデモでお見せします。続いて、RAG（検索拡張生成）について、その課題と評価方法についてお話しします。私が概要を説明した後、Shailendraが登壇して、この新機能がコンソールでどのように動作するかをご紹介します。最後にまとめと次のステップをご説明し、すぐに始められる方法をお示しします。
評価の課題とAmazon Bedrockのモデル評価機能
まず、大きな視点から見ていきましょう。評価とは何でしょうか？それは、Generative AIアプリケーションの品質、レイテンシー、運用コストという3つの要素のトレードオフを事業として検討することです。私たちは常に、お客様からこれらのトレードオフに関する様々な詳細や、どの要素が事業にとって最も重要かについてお話を伺っています。 さらに詳しく見ると、特に品質の面では、より多くの要素があります。アプリケーションとそのコンテンツを、御社のスタイルやブランドの声に合わせることが重要です。一般的なケースではなく、御社固有のユースケースで評価する必要があります。他社のデータは御社にとって無関係なので、御社独自のデータを使用する必要があります。ユーザーや顧客にとって本当に役立つ情報やデータであることを確認し、信頼性と確実性を確保する必要があります。
これには多くの課題があります。私たちは評価をライフサイクルとして捉えています。これを全て自力で行おうとすると、非常に困難です。 まず、モデルハブを見つけ、次にどのメトリクスやアルゴリズムが重要かを判断する必要があります。これには時としてデータサイエンスチーム全体が関わり、多くの議論が必要で、何が関連性があるかを判断するだけでも長時間かかることがあります。 その後、データセットを見つけ、自社のデータでデータセットを作成する方法を考える必要があります。さらにインフラも用意しなければなりません。モデルをホストする場所、アプリケーションをホストする場所を確保する必要があります。 自動評価の最初のパスを終えた後は、人間によるレビューと判断を取り入れ、実際に期待通りの動作をしているかを確認する必要があります。
もちろん、これらすべてを集約した後、この評価結果が望んでいたものなのか、さらなる改善が必要なのかを理解する必要があります。 そして、最初に示した三角形に戻って、コスト、レイテンシー、品質のトレードオフを再検討します。 ご覧の通り、これは本当に大変な作業です。数週間かかることもあり、新しいアプリケーションや新しいモデルごとにこれを繰り返す必要があります。システムに新しいデータを読み込む場合も、この苦労を繰り返すことになります。
では、このような課題をどのように解決できるのでしょうか？まず最初にお話ししたいのは、Amazon Bedrockのモデル評価についてです。 昨年のre:Inventに参加された方は、モデル評価について、その初期段階でお話しした記憶があるかもしれません。この1年間、私たちは素早く始められるよう、モデル評価に新機能、新しい能力、新しいテクノロジーを追加する取り組みを重ねてきました。モデル評価では、私たちが提供する厳選されたデータセットを使用することも、独自のデータセットを持ち込んで、より実用的な評価を行うこともできます。モデル評価にはいくつかの方法があります。自動評価には2種類あり、F1スコアやBERTScore、その他の完全一致による評価といったアルゴリズム的なプログラム評価と、この後詳しくご説明する、今年新たに加わったLLM-as-judgeがあります。3つ目は、人による評価を選択する場合です。
人による評価のために、私たちは包括的な機能を用意しています。自社のワークチームを活用することも、私たちと協力することもできます。AWSが提供する専門家による完全マネージド型のサービスがあり、プライベートな形で評価をサポートします。評価システムには多くの事前定義された指標が組み込まれていますが、特に人による評価を行う場合は、カスタム指標も用意されています。お客様固有の非常に具体的な評価を細かく行いたい場合も、それは完全に可能です。これらの設定は非常に簡単に実行できるように作られており、ほとんどの場合、数回のクリックで結果を得ることができます。
LLM-as-a-judgeによる新しい評価指標と機能
これにより、何週間も何ヶ月もかかっていた大きな課題のサイクルが、わずかな時間と数回のクリックで済む生産的なサイクルに変わります。では、実際にどのように始めればよいのでしょうか？APIを使用する場合やコンソールに入力する場合のフォーマットには、3つの要素があります。 入力プロンプトがあり、データセット内に異なるユースケースがある場合に結果をより良く理解し整理するのに役立つオプションのカテゴリがあります。そして3つ目として、多くの場合、Ground Truthの応答もオプションです。これらはS3バケット内のJSONLファイルに格納され、この後Hardickが実際の方法をお見せします。
では、モデル評価が実際にどのように機能するのか見ていきましょう。ここには3つの大きな選択肢があります。すでに一般提供されているのは、 BERTScoreやF1スコア、その他の完全一致を使用したプログラムによる評価で、精度、堅牢性、有害性を評価できます。 また、すでに提供している人による評価では、基本的にどのような評価でも可能です。評価者向けの採点基準を作成するか、当社の専門家チームと協力するだけで、シンプルな「いいね」「よくない」の評価から、Likertスケール、選好順位付けまで行えます。
そして、 今回特に時間を割いてお話しする大きな新機能が、LLM-as-judgeです。私たちのサイエンスチームは、これらの判定モデルと判定プロンプトテンプレートが、専門家レベルの人間の評価者との高い相関性を持つことを確認するため、多くの基礎研究を行ってきました。正確性、完全性、読みやすさ、一貫性など、多くの評価が可能です。さて、約束通り、この話題についてより深く掘り下げていきましょう。LLM-as-judgeは今週の日曜日に発表したばかりですが、すでに多くの好意的なフィードバックをいただいており、大きな期待が寄せられています。
それでは、私たちの評価指標についてお話ししましょう。最初の9つの指標から見ていきましょう。これらはQuality（品質）の指標です。これらはQualityとResponsible AIに分類されています。Quality指標には、CorrectnessやCompletenessといった非常に客観的なものから、Faithfulness、Helpfulness、Coherenceなどを経て、ReadabilityやProfessionalな文体やトーンといったより主観的なものまであります。そしてResponsible AIの指標として、Harmfulness（有害性）、Stereotyping（ステレオタイプ）、Answer Refusal（回答拒否）があります。これにより、アプリケーションが適切に機能し、モデルが正しい応答を返しているだけでなく、信頼できる、責任ある原則に従っているということを確認できるのです。
では、これらの評価指標がどのように機能するのか、もう少し詳しく見ていきましょう。例としてCorrectnessを取り上げてみましょう。簡単な例を挙げてみます。入力データセットで「スペインの首都は何ですか？」というプロンプトがあるとします。答えはマドリードだとわかっていますが、モデルの応答がバルセロナだったとします。これがLLMによってジャッジとしてどのように評価されるか見てみましょう。まず、「あなたは役立つアシスタントです」という典型的な設定から始まります。そして質問、LLMからの候補となる応答、そして参照となる応答が与えられ、その応答が正確かどうかをチェックするのが課題となります。Correctnessの評価では、Ground Truthありとなしのオプションがあり、システムが自動的にバックグラウンドで調整を行います。
そして、ここに実際のタスク、質問、参照応答、候補応答があります。データセットからのプロンプトと、ジェネレーターモデルから得られた推論結果を、ジャッジプロンプトに組み込んでいきます。これらすべてが組み合わさって機能するのです。では、スコアリングはどうなるのでしょうか？「応答の説明を行い、その後で評価を行ってください。正解は2点、部分的に正解は1点、不正解は0点です」というものです。ここで重要なポイントは「応答の説明を行う」という部分です。ジャッジモデルにそのスコアを付けた理由を説明させているのです。デモでご覧いただけますが、これは非常に有用です。単なる数字だけでなく、数字と説明が得られるので、現在のシステムの動作が気に入らない場合に、改善のために何をすべきかを理解することができます。
Hardickによるモデル評価のデモンストレーション
それでは、このセットアップの方法を説明しましょう。まず、Generator Model（生成モデル）を選択し、Evaluator Model（評価モデル、つまりジャッジモデル）を選び、利用可能な指標リストから必要な指標を選択します。そしてデータセット（S3からのJSONLファイル）をアップロードします。作成をクリックすると、推論、スコアリング、すべての計算を私たちが処理します。結果はすべて画面に表示され、説明と数値スコアを含む出力ファイルは、セットアップで選択したS3バケットに保存されます。数回のクリックだけで結果を得ることができます。
全体像を見てみましょう。評価には3つの主要なタイプがあります。左側には、チームからのスコア分布を確認できるHuman Evaluation（人による評価）があります。右側には、BERTやF1スコアなど、単純な数値スコアを提供する自動評価またはプログラムによる評価があります。そして中央には、LLM-as-a-judgeレポートがあり、分布を確認したり、プロンプトごとにこれらの数値が何を意味するのかを確認したり、自然言語による説明を探索したりすることができます。
さらに視点を広げると、先ほど話題に出た品質、コスト、レイテンシーのトレードオフについてですが、Amazon Bedrockのプレイグラウンドからコストとレイテンシーの見積もりを取得できます。コンソールにログインするだけで、LLM-as-a-judge、人による評価、プログラムによる評価といったツールから品質指標を得ることができます。これにより、Amazon Bedrock上で品質、コスト、レイテンシーの3つの要素を含む完全な評価が可能になります。
では、Hardickに引き継ぎたいと思います。 先ほど触れたように、LLM-as-a-judgeを使用して、大規模言語モデルを活用して他のモデルを評価できるようになりました。多くの組織が概念実証段階で印象的なGenerative AIアプリケーションを開発していますが、モデル評価に直面すると、それがボトルネックになるという話をよく耳にします。データサイエンティストの専任チームがない場合、どのモデルが適切か、どのモデル設定を使用すべきか、そしてこれらの評価をどのように繰り返していくべきかを理解することは、さらに大きな課題となります。
これらの課題に対処する方法をデモでご紹介しましょう。今、Amazon Bedrockのランディングページを開いていますが、ここではすべての機能 と特徴を確認できます。評価ページに移動して 、今週から利用可能になった2つの新機能、LLM-as-judgeとKnowledge Base evaluationをご覧いただけます。createをクリックしてAutomatic Model as a Judgeオプションを選択し、評価ジョブを作成していきましょう。
これでモデル評価の作成ページに移動しました。まずモデル名を入力し、必要に応じて評価ジョブの説明を追加できます。次に、レスポンスを評価してメトリクスを生成する評価モデルを選択します。 評価モデルとしてClaude 3.5 Sonnetを選択してapplyをクリックします。その下には、評価ジョブに適用できるキーと値のペアであるタグが表示されています。 これはオプション項目なので、このデモでは省略します。 次に、レスポンスを生成するジェネレーターモデルを選択します。このデモでは、Anthropic Claude 3 Haikuモデルを選択してapplyをクリックします。 その後、推論の設定に進みます。
選択したモデルについて、Temperature 、Top P、Top K、そして最大レスポンス長を設定できます。デフォルト設定で問題ないので、そのままスクロールダウンします。ここでメトリクスが表示され、品質メトリクスと責任メトリクス の2種類が利用可能です。両カテゴリーには多くのオプションが用意されています。私のユースケースでは、これらの指標が重要なので、品質メトリクスとしてCompleteness、Relevance、Coherence、Correctnessを選択します。Responsible AIメトリクスとしては、Harmfulness 、Refusal、Stereotypeを選択します。
データセットの設定では、2つのファイルを用意する必要があります。まず、私のAmazon S3バケットの1つにあるデータセットファイルから始めましょう。先ほどご覧いただいた構造を持つJSONLファイルを選択します。「選択」をクリックして、そのファイルがどのようなものか見てみましょう。私が用意したのは、1つのプロンプトだけを含む非常にシンプルなバージョンのJSONLファイルです。ご覧のように、このファイルには2つの要素を持つJSONオブジェクトがあります：プロンプトと参照用の応答です。
コンソールに戻って、残りの情報を入力していきましょう。次に、評価ジョブが完了した後に結果を保存したいAmazon S3バケットの場所を選択します。同じバケットを選択し、出力フォルダを指定します。次にIAMロールを選択します。評価内で特定のアクションを実行するにはIAMロールが必要です。このIAMロールには、Amazon S3バケットへのアクセス権限と、この評価ジョブで使用するモデルへのアクセス権限が含まれています。既存のロールを選択することもできますが、ここでは新しいロールをすぐに作成してみましょう。
下の方にKMSキーのオプションがあります。必要に応じて独自のAWS管理のKMSキーを指定できますが、デフォルトでは常にAWS管理のKMSキーが使用されるので、このままでも問題ありません。それでは「作成」をクリックします。ジョブを作成すると、ステータスが「進行中」になっているのが確認できます。私のAWS環境では既にいくつかの評価ジョブを作成済みなので、そのうちの1つの結果をお見せしましょう。model-eval-dataset-oneを選択すると、この画面の上部に評価の概要が表示されます。評価の設定を確認したい場合は、評価概要を展開すると、データセットの場所、出力の場所、選択したモデルなど、すべての設定が表示されます。
次に、このジョブの一部として評価されたすべてのメトリクスを確認できるモデル概要が表示されます。例えば、正確性（Correctness）が1.0となっており、これは応答が正確であったことを示しています。Responsible AIメトリクスでは、有害性（Harmfulness）のスコアが0となっており、これは応答に侮辱や憎悪などの有害な内容が含まれていなかったことを意味します。下にスクロールすると、このジョブで評価されたすべてのメトリクスを確認できます。これらのメトリクスの例を見てみましょう。有用性（Helpfulness）については、そのメトリクスの分布スコアを確認できます。11個のプロンプトに対して0.83のスコアを獲得したことがわかります。
その直下にプロンプトの詳細があります。プロンプトの詳細を展開すると、このジョブに含まれる各プロンプトの情報、モデルが生成した出力、そして私が提供した正解データを確認できます。右側には各プロンプトのスコアが表示されています。最初のプロンプトでは0.83のスコアが表示されています。なぜこのようなスコアになったのか理解するために、そのスコアをクリックすると、特定のスコアに至った理由が自然言語で説明されます。応答全体を読む必要はありませんが、この応答は正確で簡潔で、質問に答えるというタスクは達成していますが、やや一般的な内容だったため、満点ではなかったことがわかります。
同様に、評価された各メトリクスの分布スコアを確認することができ、 ここで分布スコアの情報を得ることができます。これらの異なる評価が表示されている評価ページに戻りますが、 これらすべてをどのように理解すればよいのでしょうか？どの評価が良い結果を出したのかを比較するにはどうすればよいでしょうか？AWSコンソールの比較機能を使用するだけです。ここでランダムに2つの評価を選んでみましょう。Eval oneとEval threeを選択して、「Compare」というボタンをクリックします。
コンソール上にスパイダーチャートが生成され、2つの評価の違いが明確に表示されます。私の評価では、モデルの変更、モデル設定の変更、そしてPromptの更新を行いました。ご覧のように、Eval oneの方がEval threeよりも読みやすさ、正確性、一貫性が優れていることがわかります。評価の詳細をクリックすると、各評価メトリクスの内訳と、2つの評価ジョブの詳細な比較が表示されます。
これにより、それらの評価ジョブ内のデータとメトリクスだけでなく、 データに対して継続的に反復して追加の評価を実施することができます。データを扱う際に強調したいポイントは、これが一度きりの作業ではないということです。データに対して継続的に反復し、進めながら評価を行い、追加情報を加えていく必要があります。これにより、Generative AIアプリケーションを開発する際の信頼性が高まります。皆さんにも今日からこれを試していただきたいと思います。これがAI導入の助けになることを願っています。
RAG評価の課題と Amazon Bedrock Knowledge Base の紹介
ありがとうございます。それではJesseさんにバトンタッチします。素晴らしいデモでしたね。そこでは多くの機能、すべて新しい機能をご覧いただきました。ジョブ間で結果を比較したり、評価結果がどうなったのかの詳細を深く掘り下げたりすることができます。また、Amazon Bedrockで利用可能なさまざまなモデルを使って、あらゆることを試すことができます。次のトピックに移る前に、おさらいをしましょう。モデル評価には4つのタイプがあります。独自のワークチームを導入できるHuman evaluation、評価を支援する完全マネージド型のAWSサービス、BERTScoreやF1スコアなどの従来のNLPメトリクスを使用したProgrammatic evaluation、そして自然言語による説明、理解しやすいスコア、人間のような評価を提供するLLM-as-a-judge技術があります。これらのモデルを使用して、RAGアプリケーションやカスタマーサービスチャットボットなどの完全なアプリケーションを構築したい場合があるでしょう。
始める際の最初の質問は、構築したものが本当に良いものかどうか、そしてアプリケーションから出力されるコンテンツがユーザーのニーズを満たすかどうかをどのように知るかということです。今週プレビューで公開された新機能、Amazon Bedrock Knowledge BaseによるRAG評価についてご紹介します。
まずは少し視点を広げて、Retrieval-Augmented Generation（RAG）とは何かについてお話ししましょう。RAGは、LLMを活用した検索と回答生成の仕組みと考えることができます。知識ソースから取得した情報を使って入力プロンプトを補強するのです。 RAGは特に、モデルの学習データに含まれていない独自のデータを使用したい場合や、モデルの学習カットオフ日以降に作成されたデータを使用したい場合に有用です。また、知識ベースに基づいた実際の事実をプロンプトに含めることで、モデルがそれらの事実やデータに基づいて情報を生成できるため、ハルシネーション（誤った情報の生成）を減らすことにも役立ちます。
Amazon Bedrock Knowledge Baseにおけるデータの取り込みと準備のプロセスについて見ていきましょう。 簡略化して説明すると、まずユーザーとしてデータを入力します。例えば、ユーザーマニュアルのPDFドキュメントなどです。後ほどデモでは、大きなPDFファイルのBedrock documentationを使用する例をお見せします。データを入力すると、パーサーとチャンカーがすべてのコンテンツを異なるチャンクに分割します。Bedrock Knowledge Baseでは、チャンキング戦略を選択することができます。チャンキングの後、それらのチャンクはテキストデータの数値表現であるベクトル埋め込みに変換されます。これらの埋め込みはベクトルデータベースに保存され、Amazon Bedrock Knowledge Basesでは複数のベクトルデータベースの選択肢が用意されています。
次に、データが取り込まれ、ベクトル化され、ベクトルDBに保存された後の実行時の動作を見てみましょう。 ユーザーとして、まずアプリケーションにプロンプトを送信します。例えば、ドキュメントに関する質問などです。そのプロンプトは、同じ埋め込みエンジンを使用してベクトルに変換されます。その後、ベクトルDBで検索が行われ、ソースデータのすべての情報と質問とのマッチングが行われます。ベクトルの関連性に基づいて最も適合度の高いものが返されます。そのコンテンツは、事実に基づいた回答を確実にするため、元のプロンプトに追加されます。すべての情報を使用して、Generator LLMで最終的な応答を生成します。結果として、取得された文脈やチャンクを示す検索情報と、Generator LLMからの最終的な生成された応答という2つの主要な情報が返されます。
RAG評価の仕組みと新機能の詳細
これは素晴らしく聞こえますが、このようなシステムの評価には重要な課題があります。 知識ベース内のデータが適切であり、検索と埋め込みのプロセスで正しいデータを取得していることを確認する必要があります。ベクトルDBから適切なデータを取得するために、適切な取り込みから検索プロセスまで、多くの設定を構成・調整する必要があります。検索後は、ハルシネーションを最小限に抑えながら、正確で完全な回答を生成する必要があります。RAGの一連のプロセス全体を評価する際には、取得されたコンテキストと生成された回答が要件を満たしているかどうかを評価する必要があります。品質や責任基準を満たさない場合は、取り込みからLLMの応答生成までのライフサイクル全体を段階的に改善する方法を知る必要があります。品質の評価が重要である一方で、バイアス、信頼性、安全性、責任ある要素も考慮しなければなりません。では、Amazon Bedrockを使用したRAGの評価についてさらに詳しくご説明しましょう。
まず、評価を自分に関連するものにするために、データセットを持ち込む必要があります。これについては後ほど方法をお示しします。検索だけを評価することもできます。 バックグラウンドで呼び出すRetrieve APIを使用して、Amazon Bedrock Knowledge Base独自のRetrieve APIを使用するか、Retrieve and Generate評価を使用することができます。これはすべてLLM-as-a-judgeによって実現されています。先ほどモデル評価で説明したのと同じ技術がこのRAG評価でも使用されているのです。そのため、自然言語による説明と、人間のような理解が得られます。
品質とResponsible AIのための評価指標が組み込まれており、Bedrock Guardrailsとの互換性もあります。アカウントにBedrock Guardrailsをすでに設定している場合は、Knowledge Basesを使用したRAG評価ジョブにそれらを適用できます。Hardickが先ほど説明したように、複数のジョブ間での比較もRAG評価で同様に可能です。RAGパイプライン全体で行っている変更が実際に効果を上げているのか、そしてRAGアプリケーションが望ましい結果を出せる方向に進んでいるのかを明確に確認することができます。数回クリックするだけで結果が得られるよう、できるだけシンプルに設計しています。
実際の始め方についてもう少し詳しく説明しましょう。画面に表示されているJSONブロックについて、特に重要な要素が2つあります：入力プロンプトと参照レスポンスです。場合によっては参照レスポンスは不要で、その点については後ほど説明します。これらはS3バケット内でJSONL形式で保存され、ジョブを選択する際に自動的に取り込まれます。
では、先ほど触れた評価指標について詳しく見ていきましょう。検索（Retrieval）は他の機能とは別個に評価できます。検索に関しては、Context CoverageとContext Relevanceという指標があります。以前他のツールを使用したことがある方なら、これらはContext PrecisionとRecallに似ていると理解できるでしょう。検索と生成の両方について、Bedrock Knowledge BasesのRetrieve and Generate APIを使用している場合も対応しています。エンドツーエンドの生成に関する品質指標として、Correctness（正確性）、Completeness（完全性）、Helpfulness（有用性）、Logical Coherence（論理的一貫性）、Faithfulness（忠実性）が提供されます。そしてもちろん、Responsible AIも忘れてはいけません - Model評価でLLM-as-a-judgeが提供する3つの指標と同じく、Answer Refusal（回答拒否）、Harmfulness（有害性）、Stereotyping（固定観念）を評価できます。
これらが実際にどのように機能するのか説明しましょう。先ほどJudgeのプロンプトテンプレートをお見せしましたが、今回はより多くの情報が関係してきます。Retrieve Contextがあるので、おさらいをしましょう。例えば、Judgeの仕組みを示すこのプロンプトテンプレートがあり、そこに情報を注入しています。これは先ほどのCorrectnessの例と同じです。しかし、今回は他にも多くのコンポーネントがあります。Retrieve ContextやContext Relevance、Context Coverageなどの指標があります。
これらを1つずつ見ていきましょう。ほとんどの場合、元のプロンプトがJudgeプロンプトに組み込まれます。例外はFaithfulness、Logical Coherence、Harmfulness、Stereotyping、Refusalで、これらは正解レスポンスと入力プロンプトだけが必要です。FaithfulnessとHelpfulnessでは、システムのレスポンスとRetrieve Contextを使用します。Context Relevanceでは、Retrieve Contextとプロンプトのみが必要です。Context Coverageでは、正解回答とRetrieve Contextが必要です。CorrectnessとCompletenessについては、実は正解データはオプションです - バックグラウンドで、正解データの有無に応じて適切な方法に自動的にルーティングする仕組みを用意しています。
このPromptテンプレートについてですが、私たちは非常にオープンな姿勢で臨んでいます。これらのPromptテンプレートは秘密ではありません。入力内容を正確にお見せできるよう、AWSのドキュメントに全て記載されています。これにより、評価の質の高さを信頼していただけ、スコアの出所を理解でき、さらにスコアの意味についてより詳細な見方ができるようになっています。
では、セットアップの方法をご説明しましょう。先ほどご紹介したLLM-as-a-judgeの手順とよく似ています。まず、Retrieve and Generateのプロセス全体をお見せし、どこで分岐するのかを説明します。最初に、上部で評価モデル（judgeモデル）を選択します。次に、Amazon Bedrock Knowledge Basesと直接統合されているナレッジベースを選択します。その後、Retrieveのみを行うか、Retrieve and Generateを行うかを選択します。Retrieveのみの場合は、生成モデルは必要ありません。しかし、Retrieve and Generate のジョブを実行する場合は、生成モデルを選択できます。先ほど説明した評価指標の中から必要なものを選び、JSONLフォーマットのPromptデータセットをS3バケットからアップロードします。
そして作成をクリックすると、推論と評価を実行します。全てのスコアを集計してレポートカードにまとめます。本当に数回クリックするだけで、慣れていれば数分で完了します。繰り返し作業をしていくうちに、このプロセスに慣れて効率的に評価を設定できるようになります。自然言語による説明付きの分かりやすいスコアが得られ、最低スコアから最高スコアまでの分布を完全な透明性を持って確認できます。
ShaanによるRAG評価のデモンストレーション
ここで、Shaanを招いて、RAG評価のデモをお見せしたいと思います。皆さん、こんにちは。私はShaan Sharaと申します。Amazon Bedrockのプロダクトマネジメントのシニアマネージャーを務めています。本日は、Jesseが先ほど説明したナレッジベースのRAG評価のデモをお見せします。ここがBedrockコンソールで、左側のナビゲーションのInference and Assessmentの下に、以前はModel Evaluationと呼ばれていたものがあります。現在はより包括的になり、Inference Assessmentの下に評価機能があります。ここをクリックすると、Knowledge Basesの新しいタブが表示されます。ここをクリックすると、その仕組みの説明が表示されます。Jesseが説明したように、このナレッジベース評価には同じLLM-as-a-judge技術を使用しています。
ここでは、すでに完了したジョブを確認でき、このページには全てのジョブのステータスが反映されています。これらのジョブは以前に実行され、完了しています。各ジョブを簡単に確認できますが、今お見せしたいのは新しいジョブの設定方法です。そこで、「reinvent demo」という新しいジョブを作成します。このジョブの説明を最大150文字で入力できます。次に評価モデルを選択する必要がありますが、Bedrockは適切なツールを選択できることが特徴です。ここでは、judgeとして選択できる4つのオプションが表示されます。私は個人的な好みでLlama 3.1 70B Instructをjudgeとして選択します。そのモデルをjudgeとして選択した後、ナレッジベースを選択できます。このナレッジベースはBedrockのものです - 全て統合されているので、新しく何かを接続する必要はありません。このシナリオでは、Bedrockに関する質問をし、デモ例として既に公開されているBedrockのドキュメント全てを使用します。
Jesseのプレゼンテーションで説明があったように、ジョブには2つのタイプがあります：Retrieveと、Retrieve-and-generateです。このドキュメントのPDFであるKnowledge Baseを選択し、Retrieval-onlyのジョブを選びます。他の設定オプションも見ていきましょう。設定可能な様々なパラメータについて詳しくご紹介します。私個人としてはデフォルトオプションを選ぶことが多いです。ここで設定について簡単に説明します。ここをクリックすると、検索タイプを選択してデフォルトの設定を上書きできます。Hybrid searchやSemantic searchを選択できますが、このデモではデフォルトを使用します。チャンクサイズも変更できます - 1から100の間で設定可能です。私は5を使用することが多く、5つのチャンクに分割します。メタデータのフィルターについても制御できますが、このデモでは簡単に進めていきます。
次にメトリクスを見てみましょう。ここにはRetrievalの品質メトリクスがあります：Context relevanceは精度（Precision）に似ており、出力された結果がどれだけ関連性があるかを示します。そしてContext coverageは再現率（Recall）に似ており、取得されたテキストが正解（Ground truth）とどれだけ重なっているかを測定します。これらを使ってジョブの設定方法をお見せします。入力と出力のフォーマットをお見せする前に、もう一つのジョブタイプであるRetrieve and generateと、そこで用意されている様々なメトリクスの次元についてもお見せしたいと思います。Retrieve and generateを選択して、そこで用意されているQualityとResponsible AIの次元を素早く見ていきましょう。Retrieve and generateを選択する際は、先ほど選択したJudgeで評価されるGenerator modelも選択する必要があります。ここでモデルを選びましょう。Claude 3.5 Haiku を選択し、Cross-region inferenceを選びます。ここでCross-region inferenceを選択したのは、その処理能力を活用するためです。Applyをクリックしましょう。QualityとResponsible AIの次元を見ていきますが、その前に設定をもう一度クリックしてみましょう。
これらの設定は、Generator modelとKnowledge basesの両方に関するものです。Inferenceパラメータの選択、Source chunksの変更、Temperatureの調整、長さの変更が可能です。Vector embeddingsの検索のデフォルトを変更する方法についても説明しました。Chunksの数も変更できます。私は通常5を使用していますが、時には1つか2つのチャンクで実験することもあります。複雑なクエリをシンプルなクエリに分解する高度な方法も用意していますが、このデモではデフォルトのままにしておきます。
Guardrailsについては、Guardrailsとの統合機能があります。例えば、BedrockですでにGuardrailsを設定済みで、RAG評価の一部としてそれを考慮したい場合は、それを選択してバージョンを指定できます。ただし、このデモではGuardrailsは使用しません。
設定したいパラメータを選択した後、用意されているメトリクスを見てみましょう。QualityとResponsible AIのカテゴリがあります。ここではHelpfulness、Correctness、Logical coherence、Faithfulness、Completenessのメトリクスが確認できます。そしてResponsible AIの側では、Harmfulness、Refusal、Stereotypingのメトリクスを標準で提供しています。多くのお客様からこれらの標準メトリクスを提供すべきだという意見をいただきました。これらは選択・選択解除が可能です。多くのお客様からHallucinationの測定についての要望を聞き、そこでFaithfulnessというメトリクスを導入しました。これをGroundedと呼ぶお客様もいます。
これを選択すると、入力データセットと出力データセットの詳細が表示されます。このビューでは、RAGやKnowledge Basesを様々な観点から評価するための包括的な方法を提供します。将来的には、独自のメトリクスを追加できる機能も提供する予定です。これで、すぐにジョブを実行する準備が整いますが、Jesseが説明したプロンプト形式で入力データセットと出力データセットを選択する必要があります。
Faithfulness、Correctness、Completeness、そしてHarmfulnessを選択しましょう。次に入力データセットと出力データセットを選択します。ここでBrowse S3をクリックします。入力・出力データセットの選択はとても簡単ですが、正しい形式でプロンプトを用意しておく必要があります。ここでデモを選択します。Jesseがスライドで説明しましたが、このファイルがどのような内容か見てみましょう。
会話のターンキーがあり、Ground Truthとなる参照レスポンスがあります。これはすべて既存のAmazon Bedrockのドキュメントから取得したもので、実際に確認することができます。「Amazon Bedrockとは何ですか？」というプロンプトに対して期待される回答がここにあります。Ground Truthの回答は「Bedrockは、Foundation Modelsにアクセスできる完全マネージド型サービスです」となっています。これを入力として生成モデルの結果を確認する際、100%正しい回答との比較ができるわけです。
入力と出力フォーマットを選択しました。これでジョブを開始する準備が整ったと思います。これでジョブが作成されます。ジョブが作成されたら、同じページに戻って、リストされている様々なジョブを確認できます。次のステップでは、ジョブが作成され完了したら、結果がどのように表示されるかをお見せしたいと思います。
まだジョブを選択している段階で、出力を選択しています。KMSなどのオプションもあり、異なるKMS設定を行うことができます。ただし、ここではデフォルトのままにしておきます。IAMロールのオプションもあり、新しいサービスロールを作成することもできますが、このジョブでは既存のロールを使用したいと思います。ジョブを思い通りにコントロールするための機能が全て揃っています。では、既存のサービスロールを使用し、これを選択してスクロールし、作成をクリックします。
ジョブは数分で完了します。同じページに戻ると、さまざまなジョブのステータスが表示されます。それでは、ジョブが完了したときの結果がどのように表示されるのか、詳しく見ていきましょう。
デフォルトのジョブをクリックすると、選択した評価指標のスコアが一目でわかります。Correctnessは0.95、Completenessは0.75、Faithfulnessは0.83とかなり良好で、選択したHarmfulness指標は0です。これらの情報は一目で状況を把握するのに役立ちます。
また、どのような設定を使用したのかを確認して思い出すこともできます。ターン数が10回であったことや、ジョブの内容、使用したGenerator Modelなどがわかります。設定を忘れた場合は、いつでもクリックしてこれらの設定パラメータを確認できます。でも、もっと詳しく調べたい場合はどうでしょうか？このような数値だけでなく、分布を見たい場合はどうすればいいのでしょうか？
そこで、下の部分では、異なるコホートやグループを含む、とてもわかりやすいグラフ表示を提供しています。ここには4つのプロンプトとレスポンスのグループがあることがわかります。これらの1つを見てみましょう - このプロンプトは0.45から0.55の範囲のレスポンスを持っています。なぜ中間的な値になったのか、詳しく見てみましょう。クリックすると、プロンプトが「Bedrock LMSでサポートされている一般的なタスクは何ですか」というシナリオであることがわかります。judgeがGenerator Modelのレスポンスを評価するために使用したground truthもあります。5つの取得ソースを使用し、0.5というスコアを付けたことがわかります。
0から1の範囲で、なぜ0.5なのか非常に興味深いところです。出力を見ると、「Bedrock LMSでサポートされている一般的なタスクには、分類、コンテキストありとなしの質問応答、要約、オープンエンドなテキスト生成が含まれます」となっています。しかし、ground truthを見ると、人間の目で見てもわかるように、コード生成、数学的推論、論理的思考、エンティティ抽出、チェーンオブソート推論など、生成出力に含まれていない情報があります。さらに詳しく見ていくと、judgeは自然言語形式で、私が人間として説明したことと同じ説明を提供しています - つまり、候補となる応答は一部のタスクはカバーしているものの、コード生成、数学的推論、論理的思考、エンティティ抽出、チェーンオブソート推論といった重要なタスクが抜け落ちているということです。そして、半分程度はカバーしているため、0.5というスコアを付けたというわけです。
Ground Truthには全ての回答が含まれており、5つのリソースを使用していることを考えると、Retrievalに問題があるかもしれません。そこで、Chunk Sizeを変更したり、別のサイトやソースを追加したりする実験を行うことができます。これにより、モデルが何を言っているのか、スコアはどうなのか、そしてどうすれば改善できるのかについての洞察が得られます。これは特定のPrompt応答の詳細分析でしたが、表示されている全ての分布についても同様の分析が可能です。別の指標を見たい場合は、Harmfulness Scoreがゼロであることが確認できます - Prompt応答のいずれも有害または不適切な内容は含まれていませんでした。
今見たのは、実行したJobの結果の1つについての詳細情報でした。複数のJobを実行して異なるモデルを実験している場合、それらを比較したいと思うかもしれません。LLM-as-a-judgeを使用したModel Evaluationと同様に、ここでも比較が可能です。そのページに戻って、2つのJobを選択します - デフォルトのものとカスタムのものを選んでみましょう。2つのJobを選択すると、Compare（比較）ボタンが有効になります。
すると、Spider Chartが表示され、選択した2つのJobについて、Correctness、Completeness、Harmfulnessなど、異なる次元での分布が一目で確認できます。ただし、これらの設定がどのようなものだったか思い出す必要があるので、クリックして両方のJobとその設定を確認できます。一方はTemperatureが0.70でChunking Sizeが5、もう一方のカスタムJobではTemperatureが0.3でChunking Sizeが1でした。これで最初のパラメータを思い出すことができます。Spider Chartを見ると、デフォルトの方がCorrectness Scoreが高いことがわかります。Temperatureと Chunking Sizeが高かったことを考えると、カスタムと比べてCorrectness次元で高くなっているのは理解できます。Completenessについても同様で、より多くのChunkがあったためです。これは多くの実験的な試みですが、結果はデフォルトの方が高いスコアを示しています。
スコアを見ると、デフォルトとカスタムで0.95対0.85となっています。Completenessについては、デフォルトの方が0.75対0.68と高いスコアを示しています。Faithfulnessでは、0.83対0.78となっています。Harmfulness次元では両方の評価がゼロを示しており、これはPrompt応答に有害なものが含まれていないという私の観察と一致します。これらはSpider Chartで素早く確認できます。
これらの結果をさらに詳しく分析したい場合は、個々の結果の詳細な分布ページがあります。Evaluation Detailsタブをクリックすると、先ほど確認した2つのJobの詳細な比較を行うことができます。一目で、それぞれのJobのPrompt応答が各範囲でどのように異なるかを確認できます。この機能により、通常は手動での分析や複数のツールが必要となる情報が1か所にまとめられています。Spider Chartでの概要確認でも、詳細な比較でも、必要な情報がすぐに利用できます。
私たちの目標は、差別化されていない重労働をすべて処理し、お客様に利益をもたらすイノベーションを追加することです。私たちのサイエンスチームは、これらのオプションをお客様に提供する前に、これらのメトリクスの開発に多大な研究努力を投じてきました。これらのデモ、プレゼンテーション、そして新機能によって、お客様の負担を軽減し、ユースケースに集中して、お客様のために最高のシナリオとアプリケーションを構築できるようになることを願っています。それでは、Jesseにバトンを渡したいと思います。ありがとうございました。
まとめと今後の展望
LLMをジャッジとして活用したRAG評価が何をできるのか、まとめてみましょう。検索を独立して評価することも、RAGの検索と生成のエンド・ツー・エンドのプロセスを評価することもできます。Amazon Bedrock Guardrailsと統合し、より関連性の高い評価のために独自のデータを持ち込むことができます。システムは0から1に正規化されたすべてのスコアを含む、読みやすいレポートを提供します。透明性を確保するため、ジャッジのプロンプトテンプレートはドキュメントで公開されています。ジョブ間で比較を行い、ユーザーのためにアプリケーションをどのように改善できるかを理解することができます。これらすべてがAmazon Bedrockに直接組み込まれています。
モデル評価とRAG評価に関するセッション全体をまとめると：LLMをジャッジとした評価、人による評価、プログラムによる評価、そして独自のデータセットを持ち込む機能について説明しました。特定のアプリケーション向けの組み込みデータセット、LLMをジャッジとした人間のような評価結果、そしてこれらの結果が何を意味するかを徹底的に理解する機能があります。これにより、アプリケーションを改善し、責任あるAIの原則に従った誇れるものをデプロイすることができます。これらすべてがAmazon Bedrockで利用可能です。
QRコードをスキャンして、私たちの公開ページと提供しているすべての機能をご覧ください。評価セクションには専用ページがあり、Knowledge Basesに関する詳細な情報も掲載されています。アカウントマネージャーやソリューションアーキテクトにお問い合わせいただくか、このセッション後に会場でお話しください。これらのソリューションを評価し、うまく機能することを確認する自信を持っていただけたことで、皆様が何を構築されるのか楽しみにしています。お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion