Zenn
📖

re:Invent 2024: SageMaker MLOpsとFMOpsで生成AIの本番運用を加速

2024/01/01に公開
AWS
reinvent2024sessio
tech

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

📖 AWS re:Invent 2024 - Accelerate production for gen AI using Amazon SageMaker MLOps & FMOps (AIM354)

この動画では、Generative AIのユースケースを本番環境にデプロイする際の課題と解決策について解説しています。SageMaker MLOpsの機能を活用したFine-tuningパイプラインの構築方法や、MLflowによる実験管理、Llama Guardを用いたセーフガード実装など、具体的な実装手法を詳しく説明しています。また、Rocket Mortgageの事例では、SageMakerとBedrockを活用して200以上のAIモデルを本番環境で運用し、年間6,200万件の文書処理の65%を自動化、データポイントの80%を正確に抽出するなど、具体的な成果を上げた実例を紹介しています。Foundation ModelのFine-tuningからデプロイまでの一連のプロセスを、実践的なデモを交えながら包括的に解説しています。
https://www.youtube.com/watch?v=-3Otl7GVeCc
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！

本編

Generative AIの最新トレンドと本セッションの概要

皆様、ようこそ。このセッションは、Generative AIのユースケースを迅速かつ確実にプロダクション環境にデプロイしたいData ScientistやMachine Learning Engineerの方々向けです。まずはGenerative AIに関する3つの重要なトレンドについて見ていきましょう。Generative AIへの顧客支出は1年足らずで2.5倍に増加し、年間700万ドルから1,800万ドルになりました。また、顧客は increasingly Generative AIアプリケーションの構築に複数のモデルプロバイダーを活用するようになってきています。そして最後に、高品質なオープンソースのFoundation Modelの登場により、顧客は独自のFoundation Modelを構築するのではなく、事前学習済みのFoundation Modelを利用してその振る舞いをカスタマイズする方向に向かっています。これは、これから60分のプレゼンテーションを進めていく上で重要なポイントとなります。

私はSageMaker AIops GovernanceとResponsible AIのシニアプロダクトマネージャーのAhmed Modiです。一緒にいるのは、GenAI ML Specialist Solution ArchitectでData Science LeaderのShelbyと、お客様の一人であるRocket MortgageのDirector of EngineeringのDianeです。まず最初に、MLOpsとは何か、現在利用可能なSageMaker MLOpsの機能について2分程度で概要を説明し、その後FMOpsとGenAIOpsの定義、FOpsとGenAIOpsを実装する際の主要な課題、そしてそれらの課題を克服してアプリケーションをデプロイする方法について説明していきます。

MLOps、FMOps、GenAIOpsの基礎と課題

運用段階のAI/MLワークロードの基盤となるのは、AWSサービス、データモデル、そしてアプリケーションにまたがるガバナンスです。これには、開発からデプロイ、モニタリング、リスク監査に至るまでの全ライフサイクルを通じたモデルの管理が含まれます。同様に、データに関しては、トレーニングデータの精度、結果の出力、およびプライバシーを制御できるよう、データへのアクセスを制御・管理することを意味します。MLOpsはガバナンスの上に構築され、スケーラブルで再現性が高く、信頼性のあるワークロードを構築するために、人、プロセス、テクノロジーにわたるプラクティスをもたらします。これは、GenAIやFMOpsでも共通するテーマとなっています。

現在SageMakerで利用可能なMLOps機能について簡単に見ていきましょう。SageMakerには、信頼性の高い自動化された実験追跡、最初のモデルから数千のモデルまでスケールする際のモデル管理、トレーニングやファインチューニングのための自動化されたビルドパイプラインの構築機能、そしてモデルのデプロイとパフォーマンスモニタリングの機能が既に用意されています。AI/MLワークフローを標準化しCI/CDを組み込むための事前設定された機能も備えています。さらに、ガバナンス、リスク、コンプライアンスのためにユースケースやリスクを文書化できる機能も提供しています。

では、FMOpsとは何かを見ていきましょう。FMOpsはMLOpsの上に構築され、Foundation Modelの選択と評価、プロンプトを使用したモデルの動作の変更と管理、あるいは機密データ、有害なコンテンツ、プロンプトインジェクションをフィルタリングするためのセーフガードの実装など、FMOps特有の側面を取り入れています。GenAIOpsはFMOpsの上に構築され、エンドツーエンドのGenAIソリューションを構築するために必要な独自の側面を取り入れています。GenAIの台頭により、エージェントを構築する機能、Foundation Modelを二次情報源で補強する機能、GenAIアプリケーションを追跡しプロダクション環境での動作を観察するための特殊な機能など、新しいパターンが進化してきています。簡単に振り返ると、実験の追跡、モデルとアプリケーションの統合、プロダクションにデプロイした後のモデルの動作モニタリング、人間の反応に基づくフィードバックループの組み込みなど、MLOps、FMOps、GenAIOpsに共通する機能があります。また、モデルのトレーニングやファインチューニング、あるいはモデルのデプロイに関連するため、MLOpsとFMOpsの間でのみ共通する側面もあります。

モデルのデプロイに関して、Foundation ModelやGenOpsに特有の側面がいくつかあります。例えば、モデルの動作を調整するためのPrompt管理などがそれにあたります。概念的にはMLOps、FOps、GenOpsで共通していますが、実装の詳細は異なる場合があり、これについては次のセクションで詳しく説明します。

SageMakerを活用したGenerative AIの実装手法

この1年間のお客様とのディスカッションを通じて、私たちは頻繁に出てくる8つの共通テーマを特定しました。これらは課題として認識されており、このセクションではそれらの課題と、それを克服するための具体的な推奨事項について説明します。その後、これらの機能の一部を実際にデモンストレーションでご紹介します。

最初の課題から見ていきましょう：高品質な結果を得るためには、Foundation Modelの Fine-tuningが必要になることが多いということです。Fine-tuningにおける大きな課題の一つは、人間のアノテーターを必要とする高品質なトレーニングデータの確保です。なぜこれが難しいのか、例を見てみましょう。特定のタスクやドメインに対してSupervised Fine-tuningを使用してモデルを調整する場合、モデルの動作を学習させるためのPromptと期待される出力を提供する必要があります。あるいは、人間の選好を使用してモデルの動作を導く場合、人間に応答を評価してもらい、そのフィードバックを使用してReward Modelを学習させ、それをFoundation Modelのファインチューニングにフィードバックします。

Foundation Modelのファインチューニングには、フィードバックを簡単に提供できるインターフェースと、自動化されたパイプラインの一部として人間のフィードバックを組み込めるツールが必要です。SageMaker Ground Truthはこれら両方の機能を提供します。ここで示している通り、使いやすいインターフェースの視覚的な側面と、モデル開発パイプラインを構築できる機能を備えています。

次は実験とモデル管理です。FOpsやGenOpsアプリケーションを構築する際には、再現性やトレーサビリティのために、使用したモデルや評価指標などの実験と関連メタデータを追跡する必要があります。Fine-tuningジョブには、実験の一部として追跡する必要のある多くのモデル入力とアーティファクトがあります。これらのアーティファクトやモデル入力を手動で追跡するのは面倒で間違いが起きやすいため、信頼性を確保するには自動化された実験追跡が必要です。

お客様からは、実験の追跡にオープンソースのMLflowが気に入っているという声をよくいただきます。しかし、MLflowのインフラ管理の負担を負うことは好ましくないと考えています。MLflowは急速に進化する製品であるため、お客様はバージョンアップグレードや最新バージョンへの適応を自身で行う必要があります。また、適切なデータサイエンティストのみが好みの開発環境からTracking Serverにアクセスし、実験指標を記録できるよう、IAMパーミッションや様々なSageMaker機能を統合する必要があります。これらの課題に対応するため、6月にSageMaker上でマネージドMLflowをリリースしました。今では数回のクリックだけで、SageMaker機能が事前設定されたMLflow Tracking Serverを立ち上げることができます。Studio内のノートブック、トレーニングジョブ、Hyperparameter Tuningクラスター、さらにはローカルのIDEから実験を記録し、IAMパーミッションを使用して適切なユーザーにTracking Serverへのアクセス権を設定できます。モデルの評価が完了したら、開発環境からステージング環境に移行する最適なモデルを選択し、MLflow Model Registryに登録することができます。

このMLflow Model Registryは自動的にSageMaker Model Registryと同期されます。これにより、SageMaker Inference Endpointへのモデルのデプロイが容易になります。EKSやBedrockなど他のインフラでモデルをデプロイする場合でも、MLflow Model Registryから直接実行することができます。これにより、MLOpsやGenAI Opsのための自動化された信頼性の高い実験追跡システムを構築することができます。

Prompt管理からSafeguardまで：Generative AIの実践的アプローチ

Promptの管理は比較的新しい概念で、その台頭に伴い、Foundation Modelの動作を調整したいと考える新しいペルソナが出現しています。これらの新しいペルソナは、ツールに関して異なる好みを持っています。事前にホストされたFoundation ModelとAPIを通じて対話できるPlayground形式のツールを好む人もいれば、JumpStartのような従来型のModel Hubを好み、モデルEndpointをホストしてノートブックを通じてモデルと対話することを好む人もいます。Prompt管理に使用するツールに関係なく、2つのベストプラクティスに従うことが重要です：Promptをテンプレートとデータとして保存すること、そしてPromptと評価結果を組み合わせることで、これらのPromptと結果を追跡できるようにすることです。

これらのベストプラクティスに従うことで得られる全体的なメリットは3つあります。第一に、Promptの管理パターンやデータを他のモデルにも活用できるため、異なる実験間でのコストを削減できます。第二に、Promptテンプレートとデータにバージョンを付けることで、実験の再現性とトレーサビリティを確保できます。最後に、異なるチーム間のコラボレーションが容易になり、Foundation Modelとのプロンプティングで特定された最適なパターンを他のメンバーも活用できるようになります。

ここまでで、モデルのファインチューニング方法、実験の抽出方法、そしてPromptを通じた動作の管理方法について説明してきました。次は、繰り返し可能なワークロードの構築と、人間のフィードバックを取り入れたファインチューニングパイプラインやRAGアプリケーションを構築するために、これらの要素をどのように組み合わせるかについて詳しく見ていきましょう。SageMaker Pipelinesは、これらのモデル開発のエンドツーエンドパイプラインを構築するためのツールです。SageMaker Pipelinesは、ドラッグアンドドロップインターフェースまたはSDKを通じてアクセスできます。すでにノートブックにコードがある場合は、@stepデコレータを使用してコードをラップするだけで、パイプラインステップに変換でき、重労働の手間を省くことができます。

Pipelineのステップが以前に正常に実行されている場合、それらのステップはスキップされ、冗長性が減少してPipelineをより速く実行できるようになります。Pipelineには、モデル開発に必要な一般的なSageMaker機能（トレーニング、プロセッシング、モデルの登録など）が事前に統合されているため、追加のロジックを書くことなく、これらの機能を簡単に呼び出すことができます。これらの機能以外の統合が必要な場合は、簡単に拡張できるコールバック関数が用意されています。PipelineはEventBridgeと統合されているため、特定の時間やイベント（S3に新しいデータが到着した時のFine-tuningジョブの起動など）でスケジュールを設定できます。最も重要な点は、Pipelineがサーバーレスであり、エンドツーエンドのワークフローを実行するためのインフラストラクチャを管理することなく設定できることです。

GenAIとFoundation Modelでは、評価指標の必要性がより広範になっているため、GenAIアプリケーションの重要な考慮事項を見ていきましょう。まず、モデルのパフォーマンスとそれに関連するリスクを測定できるモデル評価が必要不可欠です。また、ライフサイクル全体にわたるデータ評価も必要です。トレーニング前には、トレーニングに関連する高品質なデータであることを確認するためのデータ評価指標が必要であり、Foundation Modelを二次的な情報源で補強する場合は、データの関連性を測定できることを確認する必要があります。

モデルが期待通りに動作していることを確認するため、モデルのレスポンスに基づくユーザーフィードバックを取り入れる必要があります。また、Generative AIアプリケーションやワークフロー全体を考慮する場合、より複雑になる可能性のあるAgentの測定方法についても考える必要があります。さらに、デプロイされたモデルがパフォーマンスとコスト効率の両面でリソースを効率的に活用していることを確認するためのシステムメトリクスも必要です。

次のスライドでは、これらの課題についてより深く掘り下げ、SageMaker、MLflow、Clarifyを使用してこれらの課題をどのように解決できるかを探っていきましょう。SageMakerでは、MLflowを通じてモデル評価を開始し、従来型モデルとGenerative AIモデルの両方についてMLflowライブラリを通じて評価にアクセスできます。また、SageMaker Clarifyのようなネイティブ機能を使用して、自動化された、あるいは人間のフィードバックによるモデル評価を行うこともできます。最も重要な考慮事項は、評価指標をPipelineに統合して、スケーラブルで再現性が高く、信頼性のあるワークロードを構築できることです。

Agentの構築は、従来のMLとは異なり、大量のインタラクションとモデル出力の分析を必要とする反復的なプロセスです。高品質なAgentを構築しようとする場合、このアプローチはスケーラブルではなく、自動化されたPipelineでAgentを運用する方法についても疑問が生じます。これに対処するため、Q BedrockやSageMakerサービスと事前に統合されているオープンソースのAgent Evaluatorを使用できます。このEvaluatorには、Evaluator LMと呼ばれるコンポーネントが含まれており、対象のAgentと対話し、レスポンスを評価して、意思決定のためにPipelineに統合できるメトリクスを提供します。

デプロイ後のモデルの動作追跡や継続的な可観測性、モニタリングについては、AWSサービスを活用してログの記録、収集、測定、主要メトリクスのアラート設定が可能です。これらのAWSサービスは、Open Telemetryなどのオープンソースツールと連携して、適切なインフラを確保することができます。

モデルを開発環境からテストや本番環境に移行する際、リスクコンプライアンスとガバナンスが重要な課題となります。SageMaker Model Registryは、すべてのモデルに関する単一の信頼できる情報源を提供することで、これらの課題に対応します。トレーサビリティ、コンプライアンス、監査の目的で、トレーニングジョブや評価結果からの情報を自動的に取得します。環境間でモデルを共有することで、テスト済みの全く同じモデルを本番環境にデプロイすることができます。複数のAWSアカウントを持つエンタープライズのお客様向けには、SageMaker Model Registryが包括的なモデル管理とモニタリングのために、すべてのアカウントにまたがる一元化されたモデルレジストリの構築をサポートします。

セーフガードの実装に関して、MLOpsやGenOpsに特有の重要な側面は、ユーザーがプロンプトを通じてFoundation Modelとやり取りすることです。ユーザーがFoundation Modelと対話する際には、プロンプトインジェクション攻撃を防ぎ、ハルシネーション、有害なコンテンツ、その他の望ましくない動作を避けるために、その対話を管理する必要があります。

ライフサイクル全体でこれらの潜在的な問題に対処するために、さまざまなツールを使用してプロセスを保護することができます。プロセスの初期段階では、ライセンスポリシーや企業ポリシーに応じて、特定のモデルへのアクセスを制限することができます。モデルのデプロイ時には2つのオプションがあります。SageMaker推論エンドポイントを使用してモデルをデプロイする場合、コンテンツのフィルタリング、特定のトピックの拒否、個人情報の制限など、一般的なシナリオに対してより良いガードレールを使用できます。また、LlamaGuardを使用して独自のセーフガードを構築し、必要に応じて動作をカスタマイズしてSageMaker推論エンドポイントでホストすることもできます。

本番環境でのモデルのデプロイを考える際、重要な側面の一つは、モデルが高いパフォーマンスを発揮し、かつコスト効率が良いことを確保することです。生成AIアプリケーションは高コストになる可能性があるためです。AWSは各レイヤーで異なる機能を提供し、最適なコストパフォーマンスのモデルを実現できるようにしています。例えば、AWSはモデルのトレーニング用に最適化されたコンピュートや、推論のホスティング用にInferentiaのような最適化されたコンピュートを提供しています。このセクションでは、サービスレイヤーで利用可能なそのような機能の1つについて説明し、最後に他の機能を探索するためのリソースを提供します。

モデルのFine-tuningで最もよく使われる手法の1つは、ベースモデルを凍結（Freeze）し、特定のAdaptive層を修正してFoundation Modelを微調整する方法です。このアプローチは非常にコスト効率が高いのが特徴です。つまり、Foundation Modelを取得し、人事部門用、法務部門用、マーケティング部門用のAdapterを用意することができます。推論エンドポイントをデプロイする際には、適切なAdapterを呼び出してレスポンスを返すことができます。ただし、Adapterの数が増えるにつれて、複雑さが増していきます。SageMaker推論エンドポイントは、マルチAdapterの推論エンドポイントをネイティブにサポートしています。推論エンドポイントと一緒にAdapterを登録するだけで、SageMaker推論エンドポイントが適切なAdapterを読み込んでクエリに応答し、数ミリ秒以内にサービスを提供します。

Rocket MortgageのAI活用事例：住宅所有の革新

ここで、これらの機能を実際に体験していただくために、Shelbyにデモをお願いしたいと思います。先ほど触れた3つの側面、つまり信頼性の高い実験の追跡、Fine-tuning用の信頼性の高い反復的なワークフローの作成、そしてセーフガードの実装について見ていきます。まずは、Q&Aチャットボットを構築するという単純なユースケースから始めます。シンプルなプロンプトを使って1つのベースモデルを試し、その後、Q&Aチャットボットのパフォーマンスを向上させるためにFine-tuningができるかどうかを検討します。

これを実現するために、人間によって注釈付けされた高品質なオープンデータセットを使用します。そのデータセットをベースモデル（この場合はLlama 3）と組み合わせます。まず、プロンプトエンジニアリングを行って、ベースモデルだけでどの程度のパフォーマンスが得られるかを確認し、その後Fine-tuningを行って結果を比較します。このために、Studioの実験機能、特にノートブック環境を使用します。プロンプト実験とFine-tuning実験の両方で、評価用データセットを使用して評価を行います。セットアップの一部をスキップして、候補モデルを選択します。Llamaモデルを使用し、実験用にノートブックに読み込みます。

JupyterLab内のノートブックに不慣れな方のために説明すると、ノートブック自体の基盤となるコンピュートとストレージを調整することができます。これは小規模な実験の一例で、一方で大規模な実験には通常、エフェメラルコンピュートを使用します。今回は、JupyterLab環境の基盤となるコンピュートを使用するだけにします。

この前提条件として、MLflowトラッキングサーバーのセットアップが必要です。先ほど申し上げたように、Studio Consoleで数回クリックするだけです。基本的にMLflowをクリックし、トラッキングサーバーに名前を付けると、約20分程度でトラッキングサーバーが起動します。その後、実験を行うすべてのData ScientistやML Engineerが利用できるようになります。今回は、MLflowトラッキングサーバーの起動を待つ20分の時間がないため、事前に準備しておきました。

起動すると、他のAWSリソースと同様にARN（一意の識別子）が表示されます。次に実験に名前を付けます。今回は「QA Chatbotモデル評価」としました。その後、実験自体のセットアップを行います。MLflowには実験という概念があり、その中にRunが存在します。Runは実験の個々の実行を表します。今回の場合、Prompt管理だけのRunを1つ作成し、その後Fine-tuningのRunを数回実行して、これらの異なるモデルカスタマイズ方法に基づく評価指標を比較します。

基本的に、実験を開始し、その実験のRunを開始しているわけです。ここで、以前に作成した評価データセット（Fine-tuningにも使用する予定のもの）を使用して、再度評価を実行します。実験を開始するにあたり、入力用のデータセットを指定します。また、MLflowのネイティブな評価機能も使用します。MLflowには、様々なタイプのモデルやタスクに使用できる評価ライブラリが用意されています。今回はQAチャットボットなので、Q&Aタスク特有のメトリクスを出力する質問応答用のビルトインモデルタイプを使用します。

セットアップが完了したら、評価関数を実行します。これはMLflowライブラリと、入力として与えたTracking Server ARNを使用して評価を実行します。まず入力評価データセットから最初の質問と回答のペアを表示し、その後評価を実行します。質問応答に特化したメトリクスが出力されるのが分かります。これには、ToxicityやExact Matchが含まれます。Exact Matchは、LLMモデルの応答が入力評価データセットに基づいて完全一致したかどうかをチェックするものです。Toxicityは不適切なコンテンツのレベルを測定します。

これらは一部のメトリクスに過ぎません。通常、より包括的な評価フレームワークでは、複数の側面から評価を行います。これらのメトリクスに加えて、要約用のROUGEやBLEUスコアなどの追加メトリクス、さらにはパフォーマンスに関するコストやレイテンシーなどの側面を評価することも一般的です。このデモでは簡略化のため、これらの標準メトリクスのみを使用します。これがPromptingのみの結果なので、Fine-tuningを行ってさらに最適化し、より良いパフォーマンスが得られるかどうかを確認したいと思います。

今回は、Fine-tuningパイプラインをセットアップします。Fine-tuningに必ずしもパイプラインが必要というわけではありませんが、複数の反復にわたって大規模な実験を行う場合、パイプラインをセットアップする利点の1つは、ランタイムパラメータを渡せることです。これらは、LoRA（パラメータ効率の良い手法）を使用する際のRankなど、Fine-tuningに使用する様々なパラメータです。このために、既に説明したSageMaker Pipelinesを使用します。今回は非常にシンプルな、いくつかのステップを持つパイプラインになります。入力データセットは、人手による注釈付きのオープンデータセットで、非常に質の高い人手による質問と回答のペアが含まれています。データ準備としては、そのデータのカテゴリでフィルタリングを行うだけです。このデータセットには、様々なタスクに使用できる異なるカテゴリが含まれています。

次に、Pipeline全体を通してSageMaker Training Jobを使用してFine Tuningを行います。これは本質的に一時的なコンピュートリソースで、非常に強力な一時的なコンピュートが特定のステップの実行中にスピンアップし、そのステップが完了すると自動的にスピンダウンします。その後、モデル評価ステップでMLflow Evaluation Libraryを使用し、先ほどのPromptingの例と同様に、すべての実験をMLflow Tracking Serverにログとして記録します。

この例で特にコードをお見せしたい理由は、これが300レベルのコンテンツであり、通常の場合、皆さんは背後にあるコードを実際に見たがるからです。Pipelineにはドラッグ＆ドロップ機能があり、それを強調しておきたいと思います。Visual Editorの中で、基本的にドラッグ＆ドロップで、まったく同じワークフローを作成することができます。データステップを取り込んで、異なる入力パラメータでデータセットをアップロードすることができます。その後、Fine Tuningステップを持ってきて、JumpStartから自動的にモデルを選択してFine Tuningを行い、さまざまなパラメータを設定できます。カスタムコードで評価ステップを実行し、これらをPipelineとしてまとめることができます。

300レベルのセッションでは通常コードを見たがる方が多いので、コードに戻って、Remote Functionを使用してこのPipelineを具体的に作成していきましょう。セットアップの一部はスキップします。Training Configurationでは、使用したいModel IDを指定します - この場合はLlama 3です。Fine Tuningに使用したいインスタンスサイズ（この場合はG5 12xlarge）や、データ処理用のインスタンスタイプなども指定します。Pipeline内の各ステップで異なるインスタンスタイプを使用できるのが非常に強力な機能です。特定のステップに対してコンピュートリソースを過剰にプロビジョニングしたくないからです。ステップごとにこれを個別に設定できることは非常に重要です。

Tracking Server URIとExperiment Nameを含むTraining Configを渡します。Tracking Server URIは私たちのTracking Serverの一意の識別子です。これを先ほどのPromptingのみのワークフローと同じExperimentにログとして記録します。人手でアノテーションされたオープンデータセットを使用しています。ここでランタイムパラメータを渡すことができます。この場合、Parameter-efficient Fine Tuning、具体的にはLoRAを実行しています。素晴らしいのは、他の何も変更することなく、RankやAlpha、Dropoutなどの異なる設定で実験できるように、これらをランタイムで渡せることです。

Pipelineに名前を付け、その後各ステップを設定します。基本的にはRemote Functionを取り込んでいます。既に作成しているスクリプトやPythonコードを、Pipelineの中にカプセル化できるようにステップ内のRemote Functionでラップします。最初のステップでは、Q&A用に最適化されたものをフィルタリングしてオープンデータセットを処理します。これは前処理用のコードであるPreprocessを呼び出すことで行います。Fine Tuningステップも同様で、Fine Tuningコードを指定します。ステップ自体以外にも多くの要素があるため、Training Scriptを用意しています。評価ステップではMLflowのEvaluationを使用します。すべてのコードの中にMLflowが組み込まれているので、ワークフロー全体を通じて結果を追跡またはログとして記録し、データの系統、トレーニング、モデル評価に関するメタデータを取得します。その後、すべてのステップを指定してPipelineを作成し、Upsertで基本的にPipelineを作成して初期化します。

これらのステップはすべて事前に実行されています。というのも、ライブデモ環境では時間がかかることがあるためです。まずは先ほどお見せしたRank AlphaとDropoutのデフォルトパラメータから始めます。その後、これらのパラメータを変更して2回目の実行を行い、ハイパーパラメータが評価指標にどのような影響を与えるか比較します。今回は特に、MLflowのQuestion-Answer用の組み込み評価指標である、ToxicityとExact Matchのみに注目します。パイプラインの実行を2回行いますが、それぞれの実行には約40分かかります。

すべての実行が完了すると、Studio内でパイプラインを可視化できます。各実行では、データの前処理、モデルのファインチューニング、そしてモデルの評価というコードで作成したステップを実行します。実行後は、信頼性の高い一貫した実験追跡と管理のために使用しているMLflowで、実行結果を確認し比較することができます。これが私たちの実験「QA Chatbotモデル評価」で、Promptingのみの実験と2つのファインチューニング実験が含まれています。

パイプライン内にすべてがカプセル化されているため、データセットの情報もここに記録されています。サイドバーを見ると、ファインチューニングに使用したパラメータが表示されています。Learning Rate、Alpha、Dropoutは自動的に記録され、評価指標やトレーニング指標も同様です。評価指標としてはToxicityとExact Matchがありますが、Grade Levelなどの追加のトレーニング指標もあります。Grade Levelは応答の米国の学年レベルを示すもので、理想的には応答が複雑すぎず、7年生程度のレベルであることが望ましいです。

指標の比較は簡単に行えます。データサイエンティストやMLエンジニアが特に気に入っているのが可視化機能です。これらの指標が一貫して記録されるだけでなく、異なる実行間で指標を視覚的に比較することもできます。ここに示されているのは2つのファインチューニングの例で、Promptingの例は既製のモデルを使用しているため、トレーニング指標があるのはこの2つだけです。異なるモデル間で結果を視覚的に簡単に比較できます。

これらのモデルを本番環境へのデプロイや、追加のセーフガード、エージェント、より広範なアプリケーションへの統合のために展開したい場合は、これらのモデル実験のいずれかにアクセスできます。これらの指標はすべて自動的に記録されるため、手動で行う場合に起こりがちな人的エラーを防ぐことができます。さらなる実験や本番環境への展開のためにモデルをデプロイしたい場合は、モデルを登録することができます。MLflowにはModel Registryが関連付けられており、SageMakerのMLflowの場合、モデルを登録すると、SageMakerのModel Registryに自動的に同期されます。これはSageMakerのModel Registryが持つ特にデプロイメントに関する機能によるものです。必要に応じて、この同期を無効にすることもできます。

Fine-tuningを行った後、モデルをデプロイして、SafeguardやAgentなどの実験を進めたい場合について、ここではSafeguardを例に説明します。Safeguardの実装方法はいくつかあります。SageMakerモデルをBedrockにインポートして、Bedrockに組み込まれているGuard Railsを利用する方法がありますが、これが最も簡単なので強くお勧めします。ただし、異なるモデルを使用したい場合や、Llama Guardモデルをファインチューニングしたい場合もあるでしょう。Llama Guardは、生成AIモデルの入出力をフィルタリングするSafeguardです。Llama Guardの仕組みとしては、デプロイされたモデルの前段に配置され、安全でないコンテンツを検出してブロックします。安全でないコンテンツを検出してLLMモデルに到達するのを防ぎ、アプリケーションにデフォルトの応答を返します。

Llama Guardには組み込みの検出機能がありますが、独自の安全でないコンテンツの検出やカスタマイズのために、Llama Guardをファインチューニングすることもできます。モデルがデプロイされると、まずLlama Guardモデルにアクセスして、入力が安全か安全でないかを判断します。安全な場合は、先ほどファインチューニングしたLlamaモデル（LLM）に進みます。安全でない場合は、アプリケーションやユーザーにブロックメッセージを送り返します。

これを実装するには、まず実験で見つかった性能要件を最もよく満たすファインチューニング済みモデルをデプロイする必要があります。この場合、Hugging Faceの組み込み推論コンテナを使用してファインチューニング済みモデルの1つをデプロイします。具体的にはSageMakerエンドポイントにデプロイし、その後Safeguardなしでエンドポイントを実装または呼び出します。これは単にSageMakerエンドポイントを通じて直接そのモデルにアクセスするだけです。ここで「銀行強盗を計画する最良の方法は何か」と尋ねると、モデルは回答しようとしますが、これは望ましい動作ではないかもしれません。そこで、犯罪アドバイスなどの問い合わせを検出するためにLlama Guardを導入します。

次にLlama Guardをデプロイします。この場合、JumpStartからすぐに使えるモデルをデプロイします。基本的には、Llama Guard用の既存のコンテナをSageMakerエンドポイントにデプロイするだけです。必要に応じて、独自のニーズに合わせてファインチューニングすることもできます。また、Llama Guard用のタスクテンプレートもフォーマットします。Llama Guardモデルと対話する際は、異なる入力フォーマットが期待されます。Llamaに特化したタスクテンプレートをフォーマットし、出力内でsafeかunsafeのいずれかを示すように指定します。また、どのカテゴリーが安全でないかも確認したいと思います。Llama Guardには、暴力と憎悪、性的コンテンツ、犯罪計画など、デプロイ前にモデルに設定したい様々なガードのカテゴリーがあります。

これは異なる入力をフォーマットするための関数コードで、推論やリアルタイムワークフロー内で異なるモデルへの入力を適切にフォーマットするためのラッパーが必要になります。では、Llama Guardを前段に配置した状態でモデルを再度呼び出してみましょう。「銀行強盗を計画する最良の方法は何か」と尋ねると、犯罪計画のカテゴリーに該当する安全でないコンテンツとして検出され、ブロックされます。基本的にアプリケーションにデフォルトメッセージが返されます。一方で、「史上最大の銀行強盗を実行したのは誰か」という異なる質問をすると、これは犯罪計画ではなく単なるQ&Aの質問なので、モデルは回答を返します。

Rocket MortgageのAI戦略がもたらした具体的な成果

短い時間枠でしたが、私は急いで説明を進めました。Emitが先ほど話した推奨事項や考慮事項を実装するために使用できるテクノロジーの例をいくつか紹介したかったのです。では、RocketのDianeに引き継ぎたいと思います。彼女がRocketのMLOpsとLLMOpsの取り組みについて詳しく説明してくれます。月曜の朝からとても刺激的なセッションですね。皆さんもう目が覚めましたか？私たちはここで想像力を高めていきましょう。RocketCompaniesが、この革新的な技術を活用して住宅所有という最も困難な課題の1つをどのように解決したのか、その物語をお話しさせていただきます。皆さんに質問です：あなたにとって「家」とは何を意味しますか？私にとって「家」とは何か？多くの人と同じように、それは安全、帰属意識、そして夢の場所を意味します。Rocketのミッションはシンプルです。私たちは誰もが住宅を所有できるようにしたいのです。1985年の設立以来、1.8兆ドルの融資を実行し、1,000万人以上のクライアントをサポートしてきました。

12年前、一世代目の移民として、私には単純な夢を持つことしかできませんでした。より良い生活を送りたいという夢です。初めての家で子供たちの笑顔を見て、家族が成長していく様子を見たとき、私の夢は叶いました。Rocketのミッションはシンプルです：誰もが家を所有できるようにすることです。ここにいる皆さんの中で何人が家を所有しているか尋ねたとき、多くの手が挙がりました。アメリカ人の92%が住宅所有を望んでいますが、その40%が住宅購入の過程と所有が現代生活で最もストレスの多いものだと考えていることがわかりました。GenZとミレニアル世代のクライアントの60%がこの経験中にフラストレーションを感じたと報告しています。私たちの目標は、それを喜びに満ちた経験に変えることです。

このミッションをどのように実現するのでしょうか？私たちはAIを活用した住宅所有戦略を採用することでそれを実現します。私たちの目標は、AIとデータを活用し、ビジネスのあらゆる場面でAIソリューションを展開して、業界を真に変革することです。Rocketでは、困難な課題から逃げません。5年の歳月と5億ドルを投資して、Rocket Logicと呼ばれる独自のローン実行システムプラットフォームを構築しました。これにより、クライアントが住宅を探す段階から、ローン実行、そして受賞歴のあるローンサービス体験の構築まで、クライアントの個人財務を改善するためのエンドツーエンドの機能を提供することができました。

私たちは独自のテクノロジーを活用して、強力なエコシステムにおけるAI機能をエンドツーエンドで展開することができ、そこから象徴的なブランドへと成長しました。私たちのAIの旅は最近始まったものではありません。AIが日常会話のトピックになる10年前から、私たちはこの旅を始めていました。現在に至り、200以上の独自AIモデルを本番環境でサポートするインフラストラクチャーを拡張することができました。その中心にあるのは、エンドツーエンドの堅牢なデータ戦略と最新化されたインフラストラクチャーです。私たちはAWSとパートナーシップを組み、すべてのデータをクラウドのS3に保存し、Redshiftをクラウドウェアハウジングとして活用し、Lake Formationなどの機能を使用して容易にスケールアップできる最新のデータ戦略を構築しました。

これが私たちの最新化されたデータアーキテクチャーの秘訣です。私たちはSageMakerとBedrockのシームレスな統合を活用し、データサイエンスの人材を活用して、最新のAIテクノロジーと統合しながら、データサイエンスAIソリューションの組み合わせを構築することができます。この進化がどのように始まったのか、お話しさせていただきます。初期の頃、私たちは7〜8人のMachine Learning Engineerを抱えてMLOpsデータプラットフォームを構築・確立していましたが、それではスケールできませんでした。自社ホスティングのML Flowを持っていましたが、デプロイメントに最大8週間かかり、それは受け入れられませんでした。最新のロードマップを完全に適用することで、先ほどのデモでご覧いただいたように、SageMakerとML Flowを使用できるようになり、その結果は私たちにとって大きなものでした。もはやMLOpsプラットフォームを管理するために7〜8人のエンジニアは必要ありません。代わりに1人だけ - Vankoです。彼は今日この会場に私と一緒にいますが、インフラストラクチャーのオーバーヘッドを最小限に抑えることができたため、彼の時間の半分をイノベーションに費やしています。結果は明白です：開発時間を40〜60%削減し、数十個のモデルから現在では200以上のAIおよびデータサイエンスモデルを本番環境で運用・展開するまでスケールアップすることができました。

本番環境のAIとデータサイエンスモデルにより、ビジネスにおいて37億件のAIとデータサイエンス駆動の自動化された意思決定を実現することができました。このスタックを活用することで、ビジネス全体の速度を向上させ、クライアントに必要なパーソナライズされたソリューションを提供することができました。高い精度の基準を保ちながら、効率性を向上させることができました。ここで、私たちのChatbotのクイックデモをお見せしたいと思います。これは、Gen AI技術とご紹介したプラットフォームを活用した私たちの独自のChatbot、Rocket Assistです。クライアントの80%がこのチャット体験を楽しんでいることがわかりました。従来の対話と比べて3倍高い成約率を達成することができました。

全体として、ビジネスにおいて大規模な効率化を実現しています。年間で受け取る6,200万件の文書の大部分を処理し、そのうち65%を自動化することができました。データポイントの80%が正確かつ精密に自動抽出され、年間70万時間のチームメンバーの時間を節約することができました。もう1つのデモでは、クライアントとチームメンバーをいかに大切にしているかを示しています。Rocket Navigatorを導入することで、チームメンバーが常に業界の最先端に立ち、最新のGen AI RMSにアクセスできるようになりました。導入初月には18,000件のインタラクションが観察され、チームメンバーの生産性が向上しました。

ビジネスユーザーの生産性も向上させることができました。この技術を使用し、これらのソリューションを統合して以来、オペレーションチームのメンバーは1年で31%多くのクライアントをサポートできるようになりました。バンキングチームは前年比で15%多くのクライアントをサポートできるようになりました。これらはすべて、人間が最も得意とする関係構築と、AIとテクノロジーの力を活用して人間性を拡張する意味のあるつながりを築くことができるという深い信念から生まれています。私たちの夢はここで終わりません。この旅はまだ始まったばかりです。ここで、本日のセッションの重要なポイントをまとめるために、Shelbyにバトンを渡したいと思います。

セッションのまとめと今後のリソース

予想よりも時間に余裕があるようですので、これは良いニュースですね。簡単なまとめを行い、その後5分間の質疑応答の時間を設けたいと思います。本日お話しした内容には、SageMaker Ground Truthを使用して人間のフィードバックを適用し、高品質なモデルを作成・評価することが含まれています。MLflowを使用してMLモデルと生成モデルをアプリケーション実験で大規模に管理することについて話し合いました。また、MLflowを使用したモデル評価や、FMEvalを使用したSageMaker Clarifyの活用についても触れました。さらに、SageMaker pipelinesを使用した自動ビルドワークフローの作成についても説明しました。Bedrockのガードレールや、安全でないコンテンツやモデルが扱うべきでないトピックから保護するためのホステッドモデルの前に配置するオープンソースモデルを通じて、セーフガードを実装することについても議論しました。

また、Rocketの事例も紹介しましたので、Rocketの皆様には事例と journey を共有していただき、ありがとうございました。締めくくりとして、本日お話しした多くの内容についてより深く掘り下げることができるリソースをご用意しています。その中には、最新機能を公開している一般的なSageMaker MLOpsページ、コード例、そして私たちのチームが取り組み、Fine-tuningパイプラインや実験などの様々な例を継続的に更新しているGenerative AIワークショップが含まれています。最後になりましたが、私たちのLinkedInプロフィールも公開しています。つながることを歓迎します - 私はこの分野の方々とのつながりを大切にしており、EmitとDianeも同様です。質問や話し合いたいことがありましたら、お気軽にご連絡ください。

※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。

Discussion