このリポジトリは、Re:Inforce 2024コードトークをサポートするサンプルコードをホストしています。このリポジトリのコードは、セッション中に読みやすさのために意図的に簡単に最適化することができ、実稼働環境での使用を目的としていません。
このリポジトリのコードの目的は、検索拡張生成(RAG)チャットボットの機能コアを実証することであり、一般的な生成AIワークロードに関連するデータ保護に関する考慮事項の一部を強調することです。
RAGチャットボットスタイルのユースケースを生産中のAWSを展開したい場合は、次のオプションのいずれかを検討してください。
このリポジトリには、一連のアイデアを示すために実行できる一連のPython「スクリプト」が含まれています。スクリプトには、順番に実行されると、RAGチャットボットがどのように機能するか、およびGenaiベースのワークロード内でデータをどのように保護できるかについてのストーリーを語るためです。ただし、スクリプトはすべてスタンドアロンであり、慣習的であり、順次実行する必要はありません。
ここで提供されるPythonスクリプトの一部は、実行する前に変更する必要があります。スクリプトは、一貫性のためにRe:Inforceプレゼンテーションに示されているとおりに正確に保存されます。スクリプトを更新する必要があるインスタンスは、 #UPDATE_TO_RUN_YOURSELFセルフで注釈付けされます。
Pythonの例のスクリプトを実行するために必要なAWSリソース(Amazon Kendra Index、Example Dataなど)は、このリポジトリのユーザーが提供できますが、以下はこれらのリソースをどのように作成するかについての指示です。
Pythonスクリプトが機能する前に作成および参照する必要がある主なAWSリソースは、Amazon KendraインデックスとAmazon S3バケットのデータを指すKendraデータソースです。 Amazon Kendra Indexには無視できないコストがあり、このソリューションを展開する前にこれらのコストを理解するために注意する必要があることに注意してください。
このリポジトリで提供されるコードは、AWS上の生成AIアプリケーションビルダーの展開を補完することを目的としています。生成AIアプリケーションビルダーをAWSに展開し、「RAG」オプションを有効にして「テキスト」ユースケースの展開を展開する場合、次のセクションに示すようにKendraインデックスを作成できます。
展開ガイドに従って、AWSソリューションに生成AIアプリケーションビルダーを展開します。
データ保護に関連するため、VPCエンドポイントを活用することによりパブリックインターネット上でトラフィックを最小限に抑えるVPCオプションを有効にしてソリューションを展開することを検討してください。
展開ダッシュボードが展開されると、ユースケースを展開できます。
ユースケースを展開するときは、 textオプションを選択します。 Select knowledge baseセクションで、 yesを選択します。[RAG]オプションを選択し、 Kendra noベースとして選択し、Kendraインデックスをまだ持っていない場合は、「既存のKendraインデックスはありますか?」あなたのために作成するために。他のすべてのデフォルト値は問題ありませんが、ニーズに合わせて必要に応じて/必要に応じて調整します。
生成AIアプリケーションビルダーが展開されると、Amazon Kendraインデックスが表示されます。これで、そのインデックスにKendraデータソースを追加する必要があります。まず、既存のAmazon S3バケットを作成または再利用して、データを保存します。 dataディレクトリの内容と、このリポジトリのsrc/kendra-acl.jsonをそのS3バケットにアップロードして、結果の構造が次のようになります。
engineering/rootrunner3k-techspecs.txt
wiki/ecorobopotato.txt
kendra-acl.json
AWS管理コンソールのAmazon Kendraインデックスに移動し、 Add Data Sourcesオプションを選択します。 Amazon S3 connectorオプションを選択します。データソースに名前を付けます。 IAMの役割を作成するか、必要に応じて既存の役割を使用します。 Configure sync settingsで、S3バケットの場所を入力し、 Access control list configuration file location設定でkendra-acl.jsonファイルを設定し、 Additional configurationを展開し、インデックスのあるプレフィックスとしてengineeringとmarketingを追加します。他のすべてのデフォルト値は、Kendraデータソースを作成および展開するのに十分です。データソースが作成されたら、データソースsync操作を少なくとも1回開始し、Pythonスクリプトを実行する前にその同期が完了するのを待つ必要があります。
Amazon Bedrockモデルを呼び出す前に、モデルアクセスを有効にする必要があります。このリポジトリはClaude 3 Sonnetを使用するため、少なくともこのモデルを有効にする必要があります。
CloudWatch Pythonファイルを具体的に実行するには、特にAmazon CloudWatchログの宛先を使用して、Amazon Bedrock Model Inkocation Loggingを有効にする必要があります。
このプロセスの一部として、CloudWatchロググループを作成します。これは、付随するPythonスクリプトで更新する必要があります。
岩盤のガードレールに関連するPythonスクリプトを実行するには、岩盤ガードレールを作成する必要があります。 AWS管理コンソールを使用して、Amazon Bedrock Serviceに移動し、GuardRailsセクションを選択します。 Create guardrailを選択します。名前を付けて、デフォルトまたは好みのオプションで設定します。ただし、 Add sensitive information filtersセクションで、 Address PIIタイプを追加し、GuardRailの動作としてMaskを選択することを確認してください。これにより、ガードレールがこのプロジェクトのPythonスクリプトで実証されることを意図した動作を再現することが保証されます。
srcディレクトリのMarkdownファイル、画像、およびPythonコードファイルは、番号付けスキームで指定された順序で表示および実行することを目的としています。次のように、これらのコードサンプルに伴うプレゼンテーションの意図を読者に導くのに役立つ各ファイルの説明があります。
これらのコードスニペットの主なポイントを提供します。これは、読みやすい非常に単純化されたPythonコードを表示し、Genaiワークロードのデータ保護に関する考慮事項をより広く強調しながら、RAGが基本レベルでどのように機能するかを示すことです。
画像は、データを使用しているデータと組織を導入するために使用されます。データは意図的に不条理であるため、LLMSはこの想定製品または組織に関連するトレーニングデータを誤って持っていません。ただし、この添付のリポジトリはオープンソースであるため、LLMが最終的にこのリポジトリをトレーニングデータソースとして使用できる可能性があり、最終的にはこの仮定を破る可能性があります。
ソースデータを含むAmazon S3バケットの内容を単に表示するだけです。また、S3のこのデータの暗号化タイプを強調して、安静時の暗号化の重要性を強調します。
Amazon Kendraインデックスに関する基本情報の一部を印刷して、Kendraの概念と、データソースに対してセマンティック検索を実行する方法を紹介します。
Kendraインデックスに対する単純なretrieve APIコールを示します。これは、質問に基づいてコンテキストを取得します。
Amazon Bedrockを呼び出し、当社の想定的な独自のデータとは関係のない質問をします。これは、LLMが公開されたインターネットから削られた大量のデータに対して訓練されることが多いため、LLMが公開されているものについて多くの質問にどのように答えることができるかを示すことを目的としています。
Bedrockに電話して、私たちの独自のデータについて質問します。 LLMが独自のデータに関する質問に答えることができず、トレーニングデータセットの一部ではないことを示しています。
最初にKendraに電話をかけて独自のデータから関連するコンテキストを取得し、Amazon BedrockでLLMを呼び出すときにそのコンテキストを使用します。このパターンは、検索拡張生成またはぼろと呼ばれます。
Amazon Kendraへの呼び出しのアクセス制御リストに追加します。 「マーケティング」グループはケンドラからの技術仕様のドキュメントにアクセスすることは許可されていないため、私たちの答えには、マーケティングが閲覧することが許可されていないコンテンツに関する詳細は含まれていません。これは、RAGベースのアプローチを使用する際にドキュメントレベルの承認を達成する方法を示しています。代わりに独自のデータを使用して微調整または継続的なトレーニングを実行してLLMをカスタマイズする場合、ドキュメントレベルで微調整された承認を行う能力が失われることに注意してください。ユーザーは、そのカスタマイズされたモデルにアクセスできるか、そうではありません。
特定のアドレスを含むラグクエリを実行します。しかし、おそらく私たちは、私たちのチャットボットに含まれるアドレスや他の種類のPIIまたは敏感な/有害なコンテンツを望んでいません...
以下のステップで使用する、前処理されたAmazon Bedrock Guardrailの属性のいくつかをリストするだけです。具体的には、Guardrailがアドレスデータ型を編集していることがわかります。
09_rag_address.pyと同じRAGベースの呼び出しを実行しますが、Bedrockへの呼び出しの一部としてBedrock Guardrailに追加されます。これにより、応答から特定のアドレスPIIデータが編集されます。
岩盤を呼び出すという最近の3つのクラウドトレールインスタンスをリストします。これは、Amazon Bedrockサービスの使用を監査するためにCloudTrailがどのように使用できるかを単に示しています。他のAWSサービスもCloudTrailイベントを生成します。このデータは、AWSリソースの監査と保護に使用できます。
最近の3つのCloudWatchモデルの呼び出しログをリストします。これは、データをCloudWatchモデルの呼び出しログにどのように含めることができるかを示しています。したがって、モデルの呼び出しログを有効にする場合、データソース自体を保護するのと同じレベルのケアでそれらを保護する必要があります。
Pythonスクリプトを実行した後、生成AIワークロードのデータ保護に関する考慮事項を示すいくつかの例をガイドされます。重要な持ち帰りのいくつかは次のとおりです。
データ保護の基本は引き続き適用されます。
生成AIは、いくつかの新しい考慮事項を紹介します
詳細については、貢献を参照してください。
このライブラリは、MIT-0ライセンスに基づいてライセンスされています。ライセンスファイルを参照してください。