Amazon Web Services ブログ
LLM の埋め込み情報ドリフトを Amazon SageMaker JumpStart から監視する
本記事は 2024年2月2日に公開された ”Monitor embedding drift for LLMs deployed from Amazon SageMaker JumpStart” を翻訳したものです。
生成 AI のワークロードで最も有用なアプリケーションパターンの 1 つが Retrieval Augmented Generation (RAG) パターンです。 RAG パターンでは、入力プロンプトに関連する参照コンテンツを探すために、埋め込みベクトル (テキスト文字列の数値表現) に対して類似検索を実行します。埋め込みはテキストの情報内容を捉え、自然言語処理 (NLP) モデルが言語を数値的に処理できるようにします。埋め込みは浮動小数点ベクトルであるため、3 つの重要な質問を用いて分析することができます。参照データは時間とともに変化するか、ユーザーが尋ねる質問は時間とともに変化するか、そして最後に、参照データが尋ねられている質問をどの程度カバーできているかです。
この記事では、埋め込みベクトル分析とドリフト検出の注意点について学びます。埋め込みは一般的な自然言語処理モデルと特に生成 AI ソリューションにおいて重要な入力データとなるため、時間の経過とともに埋め込みが変化 (ドリフト) するかどうかを測定する方法が必要です。このポストでは、Amazon SageMaker JumpStart からデプロイされた大規模言語モデル (LLM) を用いてクラスタリング手法によりベクトル埋め込みのドリフトを検出する例を示します。また、後述するエンドツーエンドのサンプルアプリケーションを使用するか、あるいはその一部のみを使用して、これらの概念を実際に体験することができます。
RAG の概要
RAG パターンでは、PDF ドキュメント、Wiki 記事、通話の書き起こしなどの外部ソースから知識を検索し、その知識を使って LLM に送られる指示のプロンプトを補強できます。これにより、LLM は応答を生成するときに、より関連性の高い情報を参照できます。例えば、LLM にチョコチップクッキーの作り方を尋ねた場合、自分のレシピライブラリから情報を含めることができます。このパターンでは、レシピのテキストが埋め込みモデルを使って埋め込みベクトルに変換され、ベクトルデータベースに保存されます。入力された質問も埋め込みベクトルに変換され、入力された質問と、類似検索で見つかった参照データが、LLM へのプロンプトに含められます。
埋め込みベクトルが生成される仕組みとそのベクトルについてドリフト分析を実行する方法について、詳しく確認していきましょう。
埋め込みベクトルの分析
埋め込みベクトルは、データの数値表現であり、これらのベクトルを分析することで、参照データの洞察が得られます。この洞察は、後にドリフトの兆候を検出するのに利用できます。埋め込みベクトルは、n 次元空間内の項目を表し、n は大きな値になることが多いです。例えば、この記事で使用されている GPT-J 6B モデルは、4096 次元のベクトルを生成します。ドリフトを測定するために、アプリケーションが参照データと入力プロンプトの両方の埋め込みベクトルをキャプチャすると仮定します。
まず主成分分析 (PCA) を使って次元削減を行います。PCA はデータの変動の大部分を残しつつ次元数を減らそうとします。この場合、分散の 95 % を保持する次元数を見つけることで、2 標準偏差の範囲内にあるものがすべて取り込まれるはずです。
次に、K-Means 法を用いてクラスタ中心の集合を同定します。K-Means 法は、各クラスタが密集している、またはまとまりが高くなるようにデータポイントをグループ化し、クラスタ間の距離が可能な限り遠くなるように試みます。
次の図に示されるクラスタリング出力に基づいて、以下の情報を計算します。
- 95 % の分散を説明する PCA の次元数
- 各クラスター中心点 (重心) の位置
さらに、次の図に示すように、各クラスタでサンプルの割合が高いか低いかを確認します。
最後に、この分析を使って以下の値を計算します。
- 慣性 (inertia) – 慣性は、クラスタ中心への 2 乗距離の和で、K-Means でデータがどの程度うまくクラスタリングされたかを測るものです。
- シルエットスコア (silhouette score) – シルエットスコアは、クラスタ内の一貫性を検証する尺度で、-1 から 1 の範囲の値をとります。1 に近い値は、クラスタ内のデータポイントが同じクラスタの他のポイントに近く、別のクラスタのポイントから離れていることを意味します。クラスタ内外の集まり具合の指標の視覚的な表現が次の図に示されています。
これらの情報を定期的にキャプチャすれば、参照データとプロンプトの埋め込みスナップショットを得ることができます。この情報をから埋め込みのドリフトの兆候を分析できます。
埋め込みドリフトの検出
参照データの埋め込みとプロンプトの埋め込みを含むデータのスナップショットを通して、定期的に、クラスタリング情報を比較できます。まず、分散の 95 % を説明するのに必要な次元数、慣性、クラスタリングジョブのシルエットスコアを比較できます。次の表に示すように、ベースラインと比較して、最新の埋め込みのスナップショットでは分散を説明するのに 39 次元多くの次元が必要となり、データがより分散していることを示しています。慣性も上がっており、サンプルがクラスタ中心からより離れた位置にあることを示しています。さらに、シルエットスコアが下がっているため、クラスタが明確に定義されていないことを意味しています。プロンプトデータの場合、これはシステムに入ってくる質問の種類がより多くのトピックに及ぶためかもしれません。
次に、次の図では、各クラスターのサンプル割合がどのように経時的に変化したかを確認できます。これにより、新しい参照データが以前のデータとほぼ同様なのか、新しい領域をカバーしているのかがわかります。
最後に、クラスター中心が移動しているかを見ることで、クラスター内の情報がドリフトしているかを確認できます。次の表で示されています。
質問の対象となる参照データの範囲
参照データと受け付けた質問がどの程度整合しているかを評価することもできます。これを行うには、各プロンプトの埋め込みベクトルを参照データのクラスタに割り当てます。次に、各プロンプトからそのクラスタの中心までの距離を計算し、その平均、中央値、標準偏差を求めます。この情報を保存し、時間の経過に伴ってどのように変化するかを確認できます。
次の図は、プロンプトの埋め込みと参照データの中心間の距離を時間の経過とともに分析した例を示しています。
ご覧のとおり、プロンプトの埋め込みと参照データの中心の平均距離、中央値距離、標準偏差距離の統計は、最初のベースラインから最新のスナップショットにかけて減少しています。距離値そのものの意味を解釈するのは難しいものの、トレンドを使って参照データと質問の間の内容の類似性が時間とともに良くなっているのか悪くなっているのかを判断できます。
サンプルアプリケーション
前のセクションで説明した実験結果を収集するために、SageMaker JumpStart からデプロイされた RAG パターンに使われるモデルを使用して、RAG パターンを実装するサンプルアプリケーションを構築しました。
このモデルは、Amazon SageMaker のリアルタイムエンドポイントでホストされています。
アプリケーションには以下の 3 つのコアコンポーネントがあります。
- プロンプトをキャプチャするユーザーインターフェイスと、LangChain を使った RAG オーケストレーション層を含む対話型フローを使用しています。
- データ処理フローは、PDF ドキュメントからデータを抽出し、Amazon OpenSearch Service に保存される埋め込みを作成します。また、これらをアプリケーションの最終的な埋め込み偏差分析コンポーネントでも使用しています。
- 埋め込みは Amazon Kinesis Data Firehose 経由で Amazon Simple Storage Service (Amazon S3) でキャプチャされ、AWS Glue の抽出、変換、ロード (ETL) ジョブと Jupyter ノートブックの組み合わせを実行して、埋め込み分析を行います。
次の図は、エンドツーエンドのアーキテクチャを示しています。
完全なサンプルコードは GitHub で公開されています。
提供されているコードは 2 つの異なるパターンで用意されています。
- Streamlit フロントエンドを持つフルスタックのサンプルアプリケーション – Amazon Elastic Container Service (Amazon ECS) と AWS Fargate で実行される LangChain を使った RAG の連携層と Streamlit を使ったユーザーインターフェースを持つ、エンドツーエンドのアプリケーションを提供します。
- バックエンドアプリケーション – フルアプリケーションスタックをデプロイしたくない場合は、AWS Cloud Development Kit (AWS CDK) スタックのバックエンドのみをデプロイし、提供された Jupyter ノートブックを使って LangChain を使った Retrieval Augmented Generation (RAG) の連携を実行することができます。
提供されたパターンを作成するには、以下のセクションで説明されている複数の前提条件があり、まず生成モデルとテキストエンベディングモデルをデプロイした後、追加の前提条件に移ります。
SageMaker JumpStart によるモデルのデプロイ
両方のパターンでは、埋め込みモデルと生成モデルをデプロイすることを前提としています。このために、SageMaker JumpStart から 2 つのモデルをデプロイします。最初のモデル GPT-J 6B は埋め込み モデルとして使用し、2 つ目の Falcon-40b はテキスト生成に使用します。
これらのモデルは、AWS マネジメントコンソール、Amazon SageMaker Studio、またはプログラムによって SageMaker JumpStart からデプロイできます。詳細については、JumpStart 基盤モデルの使用方法を参照してください。デプロイを簡素化するために、SageMaker JumpStart によって自動的に作成されたノートブックから派生した提供されているノートブックを使うことができます。このノートブックは、SageMaker JumpStart の ML ハブからモデルを取得し、2 つの別々の SageMaker リアルタイムエンドポイントとしてデプロイします。
サンプルノートブックには、クリーンアップ用のセクションもありますが、そのセクションは実行しないでください。実行すると今デプロイしたばかりのエンドポイントが削除されます。このハンズオンチュートリアルの最後に、クリーンアップを完了させます。
エンドポイントのデプロイが正常に完了したことを確認したら、サンプルアプリケーション全体をデプロイする準備が整います。ただし、バックエンドと分析用のノートブックのみを探索したい場合は、次のセクションで説明するように、そちらだけをデプロイすることもできます。
オプション 1: バックエンドアプリケーションのみのデプロイ
このパターンでは、バックエンド ソリューションのみを展開し、Jupyter ノートブックを使ってソリューションと対話できます。UI の部分を構築したくない場合に、このパターンを使用します。
前提条件
次の前提条件を満たしている必要があります。
- SageMaker JumpStart を使ってモデルエンドポイントのデプロイ – 上記で説明したように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントをデプロイします。
- デプロイ時のパラメーター設定 – 次の情報を設定します。
- テキストモデルエンドポイント名 – SageMaker JumpStart で展開したテキスト生成モデルのエンドポイント名
- 埋め込みモデルエンドポイント名 – SageMaker JumpStart で展開した埋め込みモデルのエンドポイント名
AWS CDK を使用したリソースのデプロイ
前のセクションで示したデプロイパラメータを使用して、AWS CDK スタックをデプロイしてください。AWS CDK のインストールについて詳しくは、AWS CDK の概要を参照してください。
AWS CDK のデプロイに使用するワークステーションで Docker がインストールされ、実行されていることを確認してください。詳しくは Get Docker を参照してください。
デプロイ時に、ノートブックを実行するために必要な情報が出力されます。次のセクションに示されているように、質問と回答をする前に参照ドキュメントの埋め込みを行う必要があります。
参照ドキュメントの埋め込み
この RAG アプローチでは、まず参照ドキュメントをテキストエンベディングモデルで埋め込み、ベクトルデータベースに格納します。
このソリューションでは、PDF ドキュメントを取り込むパイプラインが構築されています。
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが作成され、そのインスタンスに Amazon Elastic File System (Amazon EFS) のファイルシステムがマウントされ、PDF ドキュメントを保存するための環境が構築されています。AWS DataSync タスクが 1 時間ごとに実行され、EFS ファイルシステムパスで見つかった PDF ドキュメントを取得し、テキスト埋め込み処理用の S3 バケットにアップロードします。このプロセスは参照ドキュメントを埋め込み、その埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を通じて埋め込みアーカイブを S3 バケットに保存します。
参照ドキュメントを取り込むには、次の手順を実行します。
- 作成したサンプルの EC2 インスタンス ID (AWS CDK の出力から
JumpHostId
の値を参照) を取得し、AWS Systems Manager の機能である Session Manager を使用して接続してください。手順については、AWS Systems Manager Session Manager を使用して Linux インスタンスに接続する を参照してください。 - EFS ファイルシステムがマウントされているディレクトリ
/mnt/efs/fs1
に移って、まずmkdir ingest
を実行してingest
というフォルダを作成します。次にcd ingest
を実行して作成したフォルダに移動します。 ingest
ディレクトリに参照する PDF ドキュメントを追加します。
DataSync タスクは、この埋め込みプロセスを開始するために、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするように設定されています。
DataSync タスクは 1 時間おきにスケジュールされて実行されます。オプションで、タスクを手動で開始して、追加した PDF ドキュメントの埋め込みプロセスを即座に開始することもできます。
- タスクを開始するには、AWS CDK の出力から
DataSyncTaskID
のタスク ID を特定し、デフォルト設定でタスクを開始してください。
埋め込み作成後は、次のセクションで示すように Jupyter ノートブックから RAG の質問に答えることができます。
Jupyter Notebook を使った質問と回答
次の手順を完了してください。
- AWS CDK の出力
NotebookInstanceName
から SageMaker ノートブックインスタンス名を取得し、SageMaker コンソールから Jupyter Lab に接続します。 - ディレクトリ
fmops/full-stack/pattern1-rag/notebooks/
に移動します。 - ノートブックインスタンス内でノートブック
query-llm.ipynb
を開き、実行して RAG を使って質問と回答を行います。
ノートブックでは conda_python3
カーネルを使用するようにしてください。
このパターンは、フルスタックアプリケーションに必要な追加の前提条件をプロビジョニングする必要なく、バックエンドのソリューションを検討するのに役立ちます。次のセクションでは、生成 AI アプリケーションとの対話用のユーザー インターフェイスを提供するため、フロントエンド部分も含めたフルスタック アプリケーションの実装について説明します。
オプション 2: Streamlit フロントエンドのフルスタックサンプルアプリケーションのデプロイ
この手法により、質問と応答のユーザーフロントエンドインターフェイスを備えたソリューションをデプロイできます。
前提条件
サンプルアプリケーションをデプロイするには、次の前提条件を満たす必要があります。
- SageMaker JumpStart を使ってモデルエンドポイントのデプロイ – 提供されたノートブックを使用して、前のセクションで説明されているように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントにデプロイします。
- Amazon Route 53 ホストゾーン – このソリューションで使用するために、Amazon Route 53 のパブリックホストゾーンを作成します。または、
example.com
のように既存の Route 53 パブリックホストゾーンを使用することもできます。 - AWS Certificate Manager 証明書 – Route 53 ホストゾーンドメイン名および適用対象のサブドメイン (
example.com
および*.example.com
など) 用に、AWS Certificate Manager (ACM) の TLS 証明書をプロビジョニングします。手順については、パブリック証明書のリクエストを参照してください。この証明書は、Amazon CloudFront およびロードバランサーのオリジンにおける HTTPS を構成するために使用されます。 - デプロイ時のパラメーター設定 – 次の情報を設定します。
- フロントエンドアプリケーションのカスタムドメイン名 – フロントエンドのサンプルアプリケーションにアクセスするためのカスタムドメイン名です。指定されたドメイン名は、フロントエンド CloudFront ディストリビューションを参照する Route 53 DNS レコードの作成に使用されます。たとえば、
app.example.com
です。 - ロードバランサーのオリジンとなるカスタムドメイン名 – CloudFront ディストリビューションのロードバランサーオリジン用のカスタムドメイン名です。指定されたドメイン名は、オリジンロードバランサーを参照する Route 53 DNS レコードの作成に使用されます。たとえば、
app-lb.example.com
です。 - Route 53 ホストゾーン ID – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン ID です。たとえば、
ZXXXXXXXXYYYYYYYYY
です。 - Route 53 ホストゾーン名 – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン名です。たとえば、
example.com
です。 - ACM 証明書 ARN – 指定されたカスタムドメイン名で使用される ACM 証明書の ARN です。
- テキストモデルエンドポイント名 – SageMaker JumpStart でデプロイされたテキスト生成モデルのエンドポイント名です。
- 埋め込みモデルエンドポイント名 – SageMaker JumpStart でデプロイされた埋め込みモデルのエンドポイント名です。
- フロントエンドアプリケーションのカスタムドメイン名 – フロントエンドのサンプルアプリケーションにアクセスするためのカスタムドメイン名です。指定されたドメイン名は、フロントエンド CloudFront ディストリビューションを参照する Route 53 DNS レコードの作成に使用されます。たとえば、
AWS CDK を使用したリソースのデプロイ
前提条件でメモした展開パラメータを使用して、AWS CDK スタックをデプロイしてください。詳細については、AWS CDK の使用開始を参照してください。
Docker が AWS CDK のデプロイに使用されるワークステーションにインストールされており、実行中であることを確認してください。
上の例のコードでは、-c は入力時に指定するコンテキスト情報を表しています。もしくは、pattern1-rag/cdk
ディレクトリにある cdk.context.json
ファイルにコンテキスト情報を記述し、cdk deploy --all
を実行することもできます。
bin/cdk.ts
ファイルでリージョンを指定していることに注意してください。ALB アクセスログを設定するには、リージョンを指定する必要があります。デプロイする前に、このリージョンを変更することができます。
デプロイ時に、Streamlit アプリケーションにアクセスする URL が出力されます。次のセクションで説明するように、質問に対して回答できるようにする前に、参照ドキュメントを組み込む必要があります。
参照ドキュメントの埋め込み
RAG アプローチでは、まず PDF ドキュメントをテキスト埋め込みモデルで処理を行い、ベクトルデータベースに保存します。このソリューションでは、PDF ドキュメントを取り込むためのパイプラインが構築されています。
初回デプロイオプションで説明したように、PDF ドキュメントの取り込み用に EC2 インスタンスが作成され、PDF ドキュメントを保存するために EFS ファイルシステムが EC2 インスタンスにマウントされています。1 時間ごとに DataSync タスクが実行され、EFS ファイルシステムパス内の PDF ドキュメントを取得して、テキスト埋め込みプロセスを開始するために S3 バケットにアップロードされます。このプロセスは参照ドキュメントに埋め込みを行い、埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を介して埋め込みデータのアーカイブを S3 バケットに保存します。
参照ドキュメントを取り込むには、次の手順を実行してください。
- 作成された EC2 インスタンスのサンプル ID を取得 (AWS CDK の出力
JumpHostId
を参照) し、Session Manager を使って接続します。 - EFS ファイルシステムがマウントされている
/mnt/efs/fs1
ディレクトリに移動し、ingest
というフォルダを作成します。 ingest
ディレクトリに、参照する PDF ドキュメントを追加します。
DataSync タスクは、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするよう設定されており、これによって埋め込み処理が開始されます。
DataSync タスクは 1 時間ごとに実行されます。追加した PDF ドキュメントの埋め込み処理を即座に開始したい場合は、手動でタスクを開始することもできます。
4. タスクを開始するには、AWS CDK 出力の DataSyncTaskID
からタスク ID を特定し、デフォルトでタスクを開始します。
質問と回答
参照ドキュメントが埋め込まれた後、Streamlit アプリケーションにアクセスする URL にアクセスすることで、RAG の質問と回答をスタートできます。Amazon Cognito 認証レイヤーが使用されているため、アプリケーションにはじめてアクセスする際は AWS CDK によってデプロイされた Amazon Cognito ユーザープール (ユーザープール名は AWS CDK の出力を参照) でユーザーアカウントを作成する必要があります。Amazon Cognito ユーザーを作成するための手順については、AWS マネジメントコンソールで新規ユーザーを作成するを参照してください。
埋め込みドリフトの分析
このセクションでは、参照スデータ埋め込みとプロンプト埋め込みのベースラインを最初に作成してから、時間の経過とともにその埋め込みのスナップショットを作成することで、ドリフト分析を実行する方法を説明します。これにより、ベースラインの埋め込みとスナップショットの埋め込みを比較できます。
参照データとプロンプトの基準となる埋め込みベクトルの作成
参照データの埋め込み表現のベースラインを作成するには、AWS Glue コンソールを開き、ETL ジョブ embedding-drift-analysis
を選択します。次のように ETL ジョブのパラメーターを設定し、ジョブを実行してください。
--job_type
をBASELINE
に設定します。--out_table
を参照埋め込みデータ用の Amazon DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力のDriftTableReference
を参照してください。)--centroid_table
を参照の重心データ用の DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力のCentroidTableReference
を参照してください。)--data_path
を S3 バケットとプレフィックスに設定します。例:s3://
<バケット名で置換>/embeddingarchive/
(バケット名は AWS CDK 出力のBucketName
を参照してください。)
同様に、ETL ジョブ embedding-drift-analysis
を使用して、プロンプト文章のベースラインの特徴ベクトルを作成します。ETL ジョブのパラメータを次のように設定してジョブを実行します。
--job_type
をBASELINE
に設定する--out_table
をプロンプト文データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力DriftTablePromptsName
を参照)--centroid_table
をプロンプト分類データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力CentroidTablePrompts
を参照)--data_path
を S3 バケットのプレフィックスに設定する 例:s3://
<バケット名で置換>/promptarchive/
(バケット名は AWS CDK の出力BucketName
を参照)
参照データとプロンプトの埋め込みスナップショットの作成
OpenSearch Service に追加情報を取り込んだ後、ETL ジョブ embedding-drift-analysis
を再実行して、参照データのベクトルのスナップショットを作成します。前のセクションで示したように、参照データのベクトルを作成するために実行した ETL ジョブと同じパラメータを使用しますが、--job_type
パラメータを SNAPSHOT
に設定する点が異なります。
同様に、プロンプトの埋め込みスナップショットを取得するには、ETL ジョブ embedding-drift-analysis
を再実行します。前のセクションで示したプロンプトの埋め込みベースラインを作成するために実行した ETL ジョブと同じパラメータを使用しますが、--job_type
パラメータを SNAPSHOT
に設定することを除きます。
ベースラインとスナップショットの比較
参照データとプロンプトについて、埋め込みベースラインとスナップショットを比較するには、提供されたノートブック pattern1-rag/notebooks/drift-analysis.ipynb
を使用します。
参照データやプロンプトの埋め込みベクトルの比較を行うには、各ノートブックの実行ごとに、ノートブックの DynamoDB テーブル名の変数 (tbl
と c_tbl
) を、適切な DynamoDB テーブルに変更してください。
ノートブックの変数 tbl
は、適切なドリフトテーブル名に変更する必要があります。ノートブックでこの変数を設定する場所の例を以下に示します。
テーブル名は以下のように取得できます。
- 参照埋め込みデータについては、AWS CDK の出力
DriftTableReference
からドリフトテーブルの名前を取得します - プロンプト埋め込みデータについては、AWS CDK の出力
DriftTablePromptsName
からドリフトテーブルの名前を取得します
また、ノートブックの変数 c_tbl
は適切な重心テーブル名に変更する必要があります。ノートブック内でこの変数を構成する場所の例を以下に示します。
以下のようにしてテーブル名を取得できます。
- 参照埋め込みデータとは、参照するデータセットを埋め込んだデータのことです。AWS CDK の出力
CentroidTableReference
から、参照データセットが格納されたテーブル名を取得します。 - プロンプト埋め込みデータとは、質問文(プロンプト)を埋め込んだデータのことです。AWS CDK の出力
CentroidTablePrompts
から、プロンプトが埋め込まれたデータが格納されたテーブル名を取得します。
プロンプト文と参照データの類似度分析
まず、AWS Glue ジョブ embedding-distance-analysis
を実行します。このジョブは、参照データの埋め込みに対する K-Means 評価からどのクラスターに各プロンプトが属するかを見つけます。次に、各プロンプトが対応するクラスター中心までの距離の平均値、中央値、標準偏差を計算します。
pattern1-rag/notebooks/distance-analysis.ipynb
ノートブックを実行すると、時間の経過に伴う距離メトリクスのトレンドを確認できます。これにより、プロンプト埋め込みベクトルの距離分布の全体的なトレンドを把握できます。
ノートブック pattern1-rag/notebooks/prompt-distance-outliers.ipynb
では、外れ値を検出する AWS Glue ノートブックです。これは参照データとは無関係のプロンプトが増えていないか特定するのに役立ちます。
類似スコアのモニタリング
OpenSearch Service から得られるすべての類似スコアは、rag
名前空間の下にある Amazon CloudWatch にログ記録されます。RAG_Scores
ダッシュボードは、平均スコアおよび取り込まれたスコアの合計数を表示します。
クリーンアップ
必要以上の料金が発生しないように、作成したすべてのリソースを削除します。
デプロイした SageMaker モデルの削除
デプロイされた SageMaker JumpStart (Amazon の機械学習モデルを素早く構築・デプロイできるサービス) のモデルを削除したい場合は、提供されている例のノートブックのクリーンアップセクションを参照するか、Amazon SageMaker (AWS の機械学習サービス) のコンソール上でモデルを削除することができます。
AWS CDK リソースの削除
cdk.context.json
ファイルにパラメータを入力した場合は、次のように内容を消去してください。
コマンド ライン上でパラメータを入力し、バックエンド アプリケーション (バックエンド AWS CDK スタック) のみをデプロイした場合、次のように削除してください。
コマンドラインでパラメータを入力し、フロントエンドとバックエンド AWS CDK スタック全体をデプロイした場合は、次のように削除します。
まとめ
この記事では、生成 AI の RAG パターンにおける参照データとプロンプトの両方でベクトル埋め込みを取得するアプリケーションの実例を示しました。参照データやプロンプトでドリフトが発生しているかどうかを判断するためのクラスタリング分析の実行方法と、参照データがユーザーの質問の種類をどの程度カバーしているかを示しました。ドリフトを検出できれば、環境が変化し、モデルが最適化されていない新しい入力を受け取っていることを示す兆候となります。これにより、変化する入力に対する現在のモデルの積極的な評価が可能になります。