re:Invent 2025: SageMaker AIとBedrockでエージェンティックAIモデルをカスタマイズ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Customize models for agentic AI at scale with SageMaker AI and Bedrock (AIM381)
この動画では、SageMakerを使用したエージェンティックAIアプリケーション構築のための新機能が紹介されています。Serverless model customizationにより、foundation modelsをドメイン固有データでカスタマイズでき、reinforcement learningを含む多様なfine-tuning技術が利用可能です。Serverless MLflowは実験ログ、評価メトリクス、エージェントトレースを統一的に管理し、追加料金なしで提供されます。SageMaker Pipelinesの新しいステップにより、モデルのカスタマイズからBedrockやSageMakerエンドポイントへのデプロイまでを自動化できます。Serverless Model Evaluationでは、AI as a judgeなどの業界標準ベンチマークを使用してモデル評価が可能です。推論最適化では、speculative decodingにより最大2.5倍のレイテンシー削減を実現し、複数のfoundation modelを同じエンドポイントにデプロイすることで最大50%のコスト削減が可能です。デモでは、医療トリアージエージェントの構築を通じて、Qwen 2.5モデルのfine-tuningから評価、Agent Core runtimeへのデプロイまでのend-to-endワークフローが実演されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
エージェンティックAIアプリケーション構築における4つの課題
皆さん、ようこそ。このセッションは、モデルをカスタマイズして大規模にデプロイし、高品質でコスト効率の良いエージェンティックアプリケーションを構築したいデータサイエンティストと AI 開発者向けです。本日のセッションでは、AI キーノートで発表されたばかりの新しいローンチについても取り上げます。では、始めましょう。
市場では 2 つのトレンドが出現しています。まず、エンタープライズソフトウェアアプリケーションにおけるエージェンティック AI の急速な採用が見られており、この採用は 2024 年の 1% から 2028 年の 33% に増加すると予想されています。これはわずか 4 年間で 33 倍の増加です。また、組織は 2028 年までにこれらの決定の 15% がエージェントによって自律的に行われると予想しており、これには高品質でコスト効率の良い、そして高速な推論を実現するために使用できる多くのコンピュートとモデルが必要になります。
顧客はこれらのアプリケーションを構築するために、ますますオープンソースモデルに依存しています。しかし、大きな機会と、これらのアプリケーションを構築する方法についての明確な見通しがあるにもかかわらず、これらのアプリケーションの大多数は本番環境に到達することはありません。 これらのアプリケーションが本番環境へのデプロイをブロックしている 4 つの主要な課題を見てみましょう。
まず、顧客はモデルをカスタマイズするための標準化されたツールを欠いているため、これらのワークフローを構築するのに時間を費やしてしまいます。これらのワークフローを本番環境に持ち込む時が来ると、グルーコードで組み立てられているため、繰り返し可能でスケーラブルなワークロードを構築するのに役立つパイプラインを構築するために、これらのワークフローを本番化されたツールで書き直す必要があります。これはしばしばプロジェクトを遅延させ、多くの手作業につながります。
次に、顧客はモデルとエージェントの可観測性の統一されたビューを提供するツールを欠いています。断片化されたツールでは、障害の根本原因をデバッグしたり、エージェントやモデルの動作が逸脱した場合に対応したりすることがはるかに難しくなります。第 3 に、モデルのカスタマイズにより、ML アセットの追跡の必要性が進化しています。以前は、顧客はモデルを監視、追跡、バージョン管理し、適切な場所にカタログ化されていることを確認して、ガバナンスとコンプライアンスの要件を満たすことができました。現在、彼らは強化学習で使用される報酬関数、プロンプトなども考慮する必要があり、これはしばしばさらに追加のツールまたは統合の構築につながり、タイムラインを遅延させます。
最後に、お客様は費用対効果の高い、高品質な推論が必要です。推論スタックを構築するのは非常に複雑です。適切なインスタンスを見つけて、異なるインスタンスタイプに対してベンチマークを実施し、適切なコスト対パフォーマンス比を確保する必要があります。その後、使用しているコンテナまたは異なるフレームワークに対しても同じことを行う必要があり、これはしばしば多くの手作業と本番環境へのアプリケーション展開の遅延につながります。推論が高すぎるため、ROI が適切に見えないこともあります。
Serverless Model Customizationの発表：完全マネージド型のファインチューニング体験
SageMaker がこれらの課題に対処するために提供する主要な機能を見てみましょう。私は Amit Modi で、Model Operations and Inference のシニアマネージャーです。そして私と一緒に Shelbee がいます。彼女は Gen AI の Worldwide Specialist シニアマネージャーです。今日は、これらの課題に対処するのに役立つ SageMaker の主要な機能をカバーし、その後 Shelbee がこれらすべての機能をデモンストレーションして、実際に動作させます。
本日、私たちは serverless model customization の立ち上げを発表しています。 Serverless model customization は、組織のドメイン固有またはプロプライエタリなデータに基づいてカスタマイズできる、最も幅広い選択肢の foundation models を提供します。この幅広いモデルの選択肢に加えて、これらのモデルをカスタマイズするために使用できる、さまざまな fine-tuning 技術への幅広いアクセスも提供します。これには reinforcement learning も含まれます。このエクスペリエンスは完全に serverless なので、キャパシティを予約したり GPU がどこにあるかを調べたりする心配はありません。ジョブを開始するだけで、インフラストラクチャはすべて私たちが対応します。
SageMaker Studio に移動して、models を見つけることができます。 Models の下に、すべてのパブリック foundation models のリストが表示され、3 つの異なるエクスペリエンスが見えます。UI、SDK、またはエージェントエクスペリエンスを通じてこれらのモデルをカスタマイズできます。今日のトークでは主に UI に焦点を当てますが、デモではもう少し詳しく見ていきます。UI をクリックすると、 マネージドエクスペリエンスに移動します。ここでは、ベースモデルと、モデルをカスタマイズするために使用したい fine-tuning 技術を選択できます。
それを選択したら、データセットをアップロードできます。ここでデータセットをアップロードするか、SageMaker で既に追跡されているデータセットがある場合は、単にそのデータセットを選択できます。その後、カスタマイズに使用したい reward function を選択できます。
様々なリワード関数から選択することができますし、コードを持ち込むこともできます。コードを手動で入力することもできますし、リワード関数を実行するラムダを持ち込むこともできます。その後、既に登録済みのラムダの中から1つを選択して、ファインチューニングを始めることができます。バックグラウンドでは、SageMakerが定期的にジョブのチェックポイントを保存してくれます。これにより、ジョブを実行しているクラスタ内のノードに障害が発生した場合でも、そのノードを健全なノードに置き換えて、最後のチェックポイントからジョブを再開することができるため、コンピュートを無駄に使うことなく、必要な分だけ使用できます。ジョブが何らかの理由で失敗した場合でも、常に最後のチェックポイントが得られるため、それを使ってトレーニングジョブを再開することができます。
SageMaker PipelinesとServerless MLflowによる統合可観測性
これらのワークフローを構築したら、SageMaker Pipelinesを使用して、さらなるカスタマイズを行い、これらのアプリケーションを本番環境にデプロイできます。本日、モデルのカスタマイズとデプロイ用に特別に設計された新しいパイプラインステップを発表しています。デプロイは SageMaker エンドポイントだけでなく、Bedrock を推論技術に使用している場合は Bedrock へのデプロイも可能です。これらの新しいパイプラインステップにより、既に用意されている目的別に設計されたパイプラインステップを使用するだけで開発を加速できるため、Serverless EMR とのデータ処理統合、Bedrock へのデプロイ、または SageMaker 内のトレーニングジョブのための統合コードを書く必要がありません。ノートブックで実験用に既に書いたコードがある場合は、そのコードに @step デコレータで注釈を付けるか、UI を使用してこのコードをアップロードし、完全に機能するパイプラインに変換することができます。パイプラインはサーバーレスなので、インフラストラクチャを管理する心配はありません。すべてのメトリクスを CloudWatch にログしているため、そこに行って問題をデバッグできます。
次に、昨日発表した Serverless MLflow の立ち上げについても紹介します。Serverless MLflow は、先ほど説明した断片化された可観測性の問題を解決します。モデルをカスタマイズする際に、実験をログに記録することができ、また評価メトリクスとデプロイ後のエージェントトレースもログに記録できます。Serverless MLflow は完全にマネージドされています。サーバーをセットアップする必要はありません。推論またはトレーニングのトラフィックが増えるにつれて、コンピュートをセットアップするのは私たちが行います。Serverless MLflow はトラフィックに応じてスケールアップし、インフラストラクチャが不要になるとスケールダウンします。また、MLflow に対する追加料金はありません。SageMaker を使用して、価格への影響を心配することなく、すべてのメトリクスを Serverless MLflow にログすることができます。
Serverless MLflow はまた、エクスペリエンスに深く統合されています。ファインチューニングのエクスペリエンスを見ると、ジョブをキックオフしたら、ジョブが完了するか実行が開始されると、モデルの詳細に、パフォーマンスメトリクスが表示され始めます。MLflow がここに深く組み込まれているため、ここから MLflow にナビゲートして、より詳しく見たい場合はより豊富なメトリクスを確認できます。また、他のワークフローで活用したい場合は、Applications の下で簡単にアクセスできます。特定の実行の下で、異なるファインチューニングジョブで実行したすべての実験を確認できるようになりました。これらのメトリクスを比較対照して、より詳しく見てから、自分に合ったファインチューニングモデルを選択できます。ここでファインチューニングモデルを選択した後、そのモデルの評価を開始できます。
Serverless Model Evaluationとパートナーアプリケーション連携
本日、Studio 内でのServerless Model Evaluation の立ち上げを発表しています。このエクスペリエンスの一部として、モデルを評価するために使用できる業界で人気のあるベンチマークを提供しています。このエクスペリエンスも完全にサーバーレスなので、インスタンスタイプを管理する心配はありません。評価ジョブをキックオフするだけで、実行は代わりに行われます。このエクスペリエンスがどのように機能するかを見てみましょう。評価エクスペリエンスでは、テクニックの1つを選択するだけです。この場合、AI as a judge を選択します。使用したいメトリクスを定義することもできるため、適切な品質メトリクスを選択できます。これらは業界で最も一般的に使用されているベンチマークです。
責任あるAIが今やモデルをリリースする際の重要な側面となっているため、私たちはコンテンツを測定し、ガードレールを設定できるようなメトリクスをそのまま提供しています。評価メトリクスを立ち上げる際には、プロンプトテンプレート も提供できるので、選択したモデルがこれらのリクエストをどのように評価するかを正確に把握できます。これらのメトリクスを実行すると、 ファインチューニングされたモデルだけでなくベースモデルについても、品質メトリクスと責任あるAIコンテンツの両方の結果が表示されます。これにより、モデルが両方の側面で実際に改善されているかどうかをより簡単に判断できます。
これらのモデルを本番環境にデプロイした後、その上にエージェンティック アプリケーションを構築している場合、またはエージェンティックアプリケーションを構築しているだけの場合でも、エージェント観測可能性はすでにCloudWatchに統合されているため、トレースを監視するためのすべてのダッシュボードを持つことができます。ただし、モデルカスタマイズも活用している場合は、AgentCore観測可能性を使用してOpenTelemetry形式のメトリクスをマネージドMLflowまたはパートナーAIアプリに送信できます。
マネージドMLflowとパートナーAIアプリでこれらのメトリクスをどのように使用できるかを簡単に見てみましょう。こちらはマネージドMLflowでの体験がどのようなものかのスクリーンショットです。 左側には、エージェントの呼び出しから始まり、ワークフロー構築プロセスを通じてドリルダウンし、各LangChain操作をキャプチャし、ツール呼び出しと複数のアシスタント相互作用（アシスタント1、アシスタント2）への呼び出しを表示する完全なトレースツリーが表示されます。この階層的なビューにより、エージェントの各ステップについて完全な可視性が得られます。
私たちはまたSageMaker上でパートナーアプリケーションをマネージド機能として提供しているため、 単に起動して始めることができます。Comet MLを使用して実験を追跡し、モデルを評価することを選択する顧客の中には、これらのメトリクスをComet MLにログして、その情報をエージェントとMLの両方に使用して根本原因をデバッグすることもできます。Cometはまた、目標を与えてプロンプトを最適化する機能や、エージェントを最適化する機能など、特定の重要な機能も提供しています。最終的な目標を取得し、評価を実行し続け、最適なプロンプトが得られるまでプロンプトを最適化します。
私たちはまたDeepChecksを有効にしており、これによってLLMマップとエージェントをテスト、評価、監視できます。これはより 包括的なビューを提供します。LLMとのすべての相互作用を手動および自動でアノテーションし、より包括的なレポートを取得することもできます。これにより、問題をより簡単に根本原因を特定し、デバッグできます。そして最後に、私たちはまたFiddlerを持っており、これによってエージェント観測可能性を実行し、その後、すべての単一のモデルカスタマイズ体験に根本原因を遡ることができます。
推論最適化とSpeculative Decodingによるレイテンシー削減
SageMaker はモデルをデプロイするための機能も提供しており 、本日は Bedrock との簡単な統合を発表しています。SageMaker Studio から直接ジョブを開始して、モデルを Bedrock にデプロイできるようになります。それに加えて、SageMaker エンドポイントを引き続き活用して、複数のアダプターを同じエンドポイントにデプロイできます。この機能についてはすぐに詳しく説明しますが、コストを削減するのに役立ちます。また、モデルのパフォーマンスをさらに最適化するためにさまざまなテクニックを使用できます。提供されているテクニックはいろいろありますが、アプリケーションのレイテンシーを最小化するための重要なテクニックの 1 つである speculative decoding について、少し詳しく説明します。
では、SageMaker エンドポイントの最初の主な利点を見てみましょう。複数の foundation model を同じエンドポイントにデプロイできます。これにより、1 つのエンドポイントを持つことができ、ユースケースが増え続けても、1 つのエンドポイントを使い続けるだけです。これにより、コストを大幅に削減できます。トラフィックが増えると、SageMaker は各 foundation model のメトリクスを発行する機能を提供しているため、すべてのモデルに対してオートスケーリングポリシーを構築でき、トラフィックが増えると、その特定の foundation model が他のインスタンスにスケールして、コストが最小化されるようにします。これにより、コストを最大 50% 削減できます。また、最近、モデルの重みをキャッシュできる機能が起動されており、これによってオートスケーリングがはるかに高速になります。
次に、アプリケーションのレイテンシーを最適化するのに役立つ、最近起動した主要なテクニックの 1 つを見てみましょう。通常、推論に対する顧客の期待は高速であることですが、foundation model は一度に 1 トークンずつ生成するため、推論が遅くなります。speculative decoding の仕組みは、foundation model とドラフトモデルがあります。ドラフトモデルは通常、より小さいモデルです。 ドラフトモデルは foundation model がレビューするためのいくつかのトークンを生成します。Foundation model はこれらのトークンをレビューし、確率を割り当ててから、特定のトークンを受け入れたり拒否したりします。
ここで、それがどのように機能するかの例を見てみましょう。プロンプトをここに置きましょう。ドラフトモデルはそのトークンの応答を生成します。Foundation model はこれらのトークンを評価し、その一部を受け入れます。これは単純化されたビューです。ドラフトモデルを使用して実際に複数のバリエーションを生成することができ、最近起動した機能により、これらのトークンを生成するだけでなく、トラフィックに対してドラフトモデルを微調整することができ、これによってドラフトモデルからより高品質の応答を得られます。
その機能がどのように機能するかを見てみましょう。これにより、最大 2.5 倍のレイテンシー削減が実現されます 精度を失うことなくスループットが向上します。トラフィックに対してドラフトモデルを微調整できるため、精度を失うことはありません。では、それがどのように機能するかを見てみましょう。独自のデータセットを持ち込むか、SageMaker のキュレーションされたデータセットの 1 つを使用できます。 ドラフトモデルで微調整ジョブを開始できます。これはバックグラウンドで実行される非同期ジョブです。ジョブが完了すると、評価メトリクスが公開されます。評価メトリクスをレビューして、ドラフトモデルを同じエンドポイントにデプロイすることを選択できるため、コストへの影響はありません。
ドラフトモデルは同じエンドポイントにデプロイされます。ドラフトモデルがこれらのトークンを生成して、ファウンデーションモデルが評価して受け入れることができるので、精度を失うことなく、このレイテンシの改善を継続して見ることができます。
最後に、モデルを追跡するだけでなく、データセットやリワード関数のような生成 AI アセットも追跡できる新しい機能もローンチしました。モデルと同様に、すべてのデータセットと Shelby がデモで説明するバリデータも追跡できるようになりました。これらのアセットを追跡できるだけでなく、リネージも追跡できるので、すべてのアセットの各バージョンとリネージを追跡できます。
医療トリアージエージェントのデモ：モデルカスタマイズから評価まで
では、Shelby にこれらすべての機能を説明してもらいます。では、皆さんご参加ありがとうございます。おそらく皆さんはお昼の時間の間にいるか、もしくはすでにお昼を食べ終わっているかもしれませんが、それでもご参加ありがとうございます。
このデモでは、いくつかのことを見ていきます。エンドツーエンドのデモになっていて、モデルのカスタマイズを見てから、そのモデルをエージェントに統合します。医療トリアージエージェントという非常にシンプルなユースケースを使用します。オープンソースモデルを取得して、それを特定のタスク用にカスタマイズまたは適応させます。この場合、患者が予約を取るか、オンコール医師にページを送る前に医療症状をトリアージできるエージェントになります。
デモは 2 つのパートに分かれています。まずモデルカスタマイズから始めて、新しいモデルカスタマイズエクスペリエンスに焦点を当てます。その後、第 2 部では、それを AgentCore というエージェントと統合する方法を見ていきます。このデモでは、エンドツーエンドの機能に焦点を当てます。今後数日間にわたって、新しいモデルカスタマイズエクスペリエンスのさまざまな詳細、異なるテクニックや異なる評価テクニックを深掘りするセッションがたくさんあることに注意してください。では、始めましょう。
Assets は、実験の一部である様々なアセットを追跡・管理できる新機能です。Datasets は重要なアセットです。Datasets をクリックすると、アップロードした全てのデータセットが表示され、異なる fine-tuning ワークロードで利用できます。また、異なる実験にわたって複数のバージョンを管理していることが確認できます。fine-tuning ジョブへの入力として利用する処理済みデータの複数の異なるバージョンを持つことができます。
データセットをアップロードするには、upload dataset をクリックして、わかりやすい名前を入力し、ローカルコンピュータから直接アップロードするか、S3 の場所からアップロードするかを選択できます。 データが既に S3 にある場合は、S3 からアップロードできます。 この場合は、コンピュータからローカルアップロードを行います。 その後、save をクリックすると、データセットがアップロードされます。 実験を進める中で新しいバージョンをアップロードでき、それが model customization ジョブへの入力として使用されます。
もう一つお伝えしたいのは、新しい serverless MLflow です。インターフェースに慣れている場合、MLflow 内に新しい apps servers タブが表示されるようになり、ここに全ての serverless MLflow app servers が配置されます。 ここにデフォルトのものがありますが、このデモ用に作成したカスタムのものもあるので、それを使用します。model customization のデモを通じて見ることになりますが、全てのモデルパフォーマンスメトリクスが自動的に MLflow にログされ、fine-tuned モデルに対して実行する全ての評価メトリクスもログされます。これにより、実験全体での比較と可視化が非常に簡単になり、最終的にどのモデルをデプロイしてエージェント統合でテストするか、または本番環境にデプロイするかを理解できます。
では、新しい customization エクスペリエンスに進みましょう。 ここには、以前の既存モデルを含む、カスタマイズできる様々なモデルが表示されます。
これは全ての機械学習およびディープラーニングモデルに適用されます。全てが一箇所にあります。カスタマイズした全てのモデルは My Models ここに表示されます。 My Models でカスタマイズを行った全てのモデルが表示され、それらの詳細情報を取得できます。これについては後で詳しく説明します。では、model customization ジョブを開始しましょう。
ご想像の通り、これらのジョブは実行に少し時間がかかるので、料理番組のようなやり方で、あらかじめ用意したモデルとあらかじめ用意したバージョンを使用します。まず基本的には、customize をクリックするだけです。UI を通じてカスタマイズできます。これが今回のデモで行うやり方ですが、AI Agent を通じてカスタマイズすることもできます。これは今朝発表されたもので、プレビュー段階ですが、自然言語を使用してファインチューニングカスタマイズのためのガイド付きワークフローを開発する機能を提供します。コードを通じてカスタマイズすることもできます。これらすべてについて SDK が利用可能で、プログラマティックな体験を好む方向けです。とはいえ、UI を通じたカスタマイズに進みましょう。
基本的には、モデルの説明的な名前を入力するだけです。私は単に medical triage と呼んでいます。ここにいくつか入っています。ここで異なるカスタマイズ技術を見ることができます。先ほど述べたように、今日と明日の異なるセッションを通じて、これらの異なるカスタマイズ技術の多くについてより詳しく説明します。 今日すぐに利用可能なものは、Supervised Fine-Tuning、DPO、Reinforcement Learning with Verifiable Rewards、および Reinforcement Learning with AI Feedback です。この場合、今日は単に Supervised Fine-Tuning を行うだけです。使用したいカスタマイズ技術をクリックします。
ここでデータセットをアップロードできます。または、この場合は、前にアップロードしたばかりのデータセットを指すだけです。 その後、使用したいバージョンを選択します。この場合、バージョンは 1 つだけです。ここで異なるトレーニング実験全体でハイパーパラメータと設定を変更できます。この場合、すぐに利用可能なデフォルトパラメータを使用するつもりですが、ここで異なるハイパーパラメータを変更できます。
その後、使用したい MLflow App も指します。ここで作成されたデフォルトのものが見えます。そして、ここが今日のこのセッション用に私が作成した特定のものです。もちろん、experiment name を調整して、MLflow 内でより意味のあるタイトルを付けることで、見つけやすくすることができます。ここはセキュリティ設定を調整できる場所でもあります。内部では serverless training ですが、VPC 内で実行するように指定することもでき、ボリュームで使用したい暗号化のタイプを指定することもできます。その後、送信するだけです。
基本的にはこれが serverless training ジョブをキックオフします。ここで進行中のものが見えます。キックオフして開始すると、ここにログがあります。まだ利用可能ではありませんが、ログはそこにあり、early stopping などのようなことをしたい場合は、できます。 とはいえ、あらかじめ用意したバージョンを見てみましょう。ここに行ってこれを見るつもりです。これは完全なデータセットでトレーニングされたものです。この場合、オープンデータセットを使用しているだけで、医学的症状と医学的診断でトレーニングされています。
最新バージョンを見てみましょう。ここで、すべての異なるバージョンを確認できます。バージョン間や異なるタブを移動できます。パフォーマンスがあり、この場合、少し暴走してしまったのが見えます。おそらく少し過学習しているんでしょう。監視していれば、早期停止ができたんですが、ハイパーパラメータを少し調整して、それを避けることもできます。 また、評価もあります。ここで評価ジョブを確認できます。多くの異なる評価が利用可能です。この場合、すぐに使えるベンチマークと別の完全な評価を実行しました。
評価を実行したい場合、基本的に評価をクリックして、説明的な名前を設定するだけです。そして、3つの評価タイプがあります。LLM as a Judge があり、その中で、ジャッジモデルとして使用したいモデルを指定できます。 それに加えて、評価したいメトリクスを指定し、カスタムメトリクスを持ち込む機能もあります。もう一つのタイプは Custom Score です。 ここで、カスタムスコアリングコードを持ち込むことができます。また、いくつかの組み込みメトリクスも使用できます。具体的には、コード実行と数学の回答に関するものがあります。 この場合、デモンストレーション用にすぐに使えるベンチマークを使用するつもりです。具体的には、Multitask Language Understanding を使用し、それをさらに絞り込んで、微調整しようとしているタスク、つまり医療ドメイン内のタスクに特化させます。
もう一つクリックするのは、ベースモデルと比較するオプションです。これは、ベースモデルに対して評価し、微調整を行うことが理にかなっているかどうかを確認したい場合に重要です。ベースモデルに対してすべての評価メトリクスを比較して、より微調整されたモデルを持つことで実際に進歩しているかどうかを確認したいのです。この場合、Qwen 2.5 を使用しているので、すべての評価メトリクスをそのベースモデルと比較したいのです。この場合、10 の科目にわたってテストします。 私たちのユースケースではそれほど有用ではないので、それを臨床知識に絞り込みます。評価内で advanced configuration parameters を指定することもできます。例えば、top P、top K、およびセキュリティ設定などです。 これらの評価ジョブを実行する機能は、バックグラウンドで実行されることを意味しますが、それでも VPC 内でそれらを実行し、暗号化のタイプを指定する機能があります。では、送信をクリックするだけです。
MLflowでの実験比較とモデルデプロイメント
送信すると、自動的にバックグラウンドで評価パイプラインが作成されます。作成されるパイプラインを処理する必要はありませんが、データを渡す、データを取り出す、そしてそれらのメトリクスを MLflow に公開するというステップを処理します。トレーニングを完了し、評価も実施したと仮定しましょう。MLflow に自動的に流れてくるいくつかのメトリクスを見てみましょう。
まず、モデルパフォーマンスメトリクスを見ます。これらは、実際のトレーニングパフォーマンス自体から持っている事前に焼き込まれたバージョンです。持っている 4 つのバージョンと比較しましょう。トレーニングサイクル中にキャプチャされたメトリクスの異なるバージョンとテーブル形式が表示されます。例えば、実行したエポック数、損失、検証損失、テスト損失、およびそれらのすべての異なるメトリクスなどです。 また、同じモデルに入って、より視覚的な比較を行うこともできます。これは互いに評価するのに役立ちます。
ここにあるのは、ファインチューニングの異なるイテレーション全体で損失を比較して可視化できるビジュアライゼーションです。これはモデルのパフォーマンス自体で、その後に先ほど見た評価メトリクスがあります。ここでは MMLU clinical knowledge ベンチマークを使用してベンチマークを行っています。ここの中でもそれらのメトリクスを比較することができます。モデルのパフォーマンスメトリクスを非表示にして、評価結果を強調しようと思います。
ここがモデルのパフォーマンスメトリクスで、ベースモデルも強調していることに気づくと思います。というのは、このモデルが実際に解決しようとしている特定のタスクに対して、ベースモデル、つまりベースの Qwen モデルよりも実際に良いパフォーマンスを発揮しているかどうかを理解したいからです。この場合、clinical custom を使用しています。ここには LLM as a judge があり、MMLU college knowledge もあります。実際には、このモデルを多くの異なるパフォーマンスメトリクス全体で見ることになります。これはこれらの評価メトリクスの 1 つを基本的に実行している 1 つの例に過ぎません。この特定のケースでは、この最初のモデル、最初のバージョンがその特定のベンチマーク、clinical knowledge ベンチマークに対して最も良いパフォーマンスを発揮しています。そうすることで、異なるメトリクスと異なる評価全体でそれを実行して、最終的にどのモデルをエージェントワークフロー内でもう少し詳しくテストしたいか、または本番環境に移行したいかを決定することができます。
評価が完了したので、モデルに戻ってデプロイメントに進みましょう。これをデプロイしてエージェントと統合したいと仮定すると、ここのデプロイメントに移動して deploy をクリックします。ここは SageMaker または Bedrock のいずれかにデプロイできる場所で、これは非常に素晴らしい機能です。このケースでは Bedrock は custom model import を通じてだと仮定しましょう。SageMaker を通じては、新しいエンドポイントを作成しようと仮定します。ここで名前を入力するだけで、インスタンスタイプを選択するか、デフォルトの推奨を受け入れることができます。
高度なオプションが利用可能です。最大インスタンス数、セキュリティ設定、およびそれらのすべての異なるアイテムに関して。その後、deploy をクリックするだけです。それが行うことは、バックグラウンドで SageMaker エンドポイントをデプロイすることで、これは現在利用可能で、エージェントワークフローへの統合または直接アプリケーション統合に対して準備ができています。
指摘する別のことは、Emmett が話した lineage タブです。これらのすべての異なるタスクとそれに至るステップの良い点は、トレーニングから発生する必要があるすべての評価まで、見ることができるように多くの動く部分があるため、完全な lineage を追跡および維持することができるということです。例えば、最初のものをクリックすると、model artifacts、この場合はベース Qwen モデルです。このファインチューニングに使用された Qwen モデルの正確なバージョンを確認できます。進むにつれて、使用されたトレーニングジョブを確認でき、完全な lineage を含むすべてのメタデータが保存および収集されます。
ご覧の通り、1870年まで遡ってパイプラインの実行とデプロイメント全体を追跡できます。この場合、デプロイメントはまだ完全には終了していませんが、デプロイメント全体を通じて追跡できるので、トレーサビリティとエンドツーエンドのリネージを維持するのに本当に素晴らしいですね。そういうわけで、デプロイされたと仮定して、これをエージェントワークフローと統合していきます。これらは、すべての実験を行い、最終的に SageMaker AI にデプロイするまでのステップです。もちろん、Bedrock にデプロイすることもできます。それはあなたが何を探しているかによって異なります。アダプタベースの推論の一部は、特にファインチューニングに関して、本当に素晴らしいコスト効率の機能ですが、Bedrock にインポートすることもできます。
Agent Coreランタイムへの統合と本番環境デプロイメント
この場合、私たちがやることは、医療ドメイン内で探している特定のタスク用に適応されたファインチューニングされたモデルをホストしている SageMaker エンドポイントを取得することです。この時点では実験だと仮定して、Strands SDK を使用します。これを進める際に念頭に置いておくべきことは、AgentCore でサポートされている他のフレームワーク、LangGraph や Crew AI など、どれでも同じように使用できるということです。私は単に Strands で紹介しているだけです。ここで私たちがやることは、エージェントを作成し、バックエンドにいくつかのダミーツールを作成して、エージェントがこれらの症状が緊急かどうか、そして潜在的にオンコール医師に連絡する必要があるか、または緊急ケアに行く必要があるか、またはそれほど緊急ではない予約をさせるかについて、より賢い判断を下すことができるかどうかを確認します。また、バックエンド側で MLflow を見て、エージェントトレースを確認します。
念頭に置いておくべき一つのことは、MLflow はエージェントトレースとエージェント評価の両方を行うということです。Bedrock AgentCore にも優れた組み込みの可観測性機能と、昨日発表された評価機能があるため、状況によって異なります。つまり、モデルとエージェントの両方を扱う場合は MLflow が良い選択肢かもしれませんが、エージェントのみを扱う場合は、AgentCore のネイティブな組み込み機能を使用する方があなたのユースケースに適しているかもしれません。そうは言っても、多くの依存関係とインストールがありますが、私が示したいのは、これは Strands SDK を使用したモデル設定です。Bedrock API エンドポイントと同じように、SageMaker エンドポイントに基づいたモデルも作成できます。ここで見ていただけるように、少し拡大してみましょう。
Strands との特定の統合である SageMakerAIModel があり、ここでエンドポイント名と、アダプタベースの推論を活用している場合の推論コンポーネント名を指定します。その後、バックエンドにツールがない非常にシンプルなエージェントを作成して、タスクに対するモデルのパフォーマンスを確認するだけです。これはツールなしのファインチューニングされたモデルです。ここでは、予約を取りたいと言うだけです。それは合理的な応答をしていますが、実際に何かをするために、実際に可用性を確認したり、オンコール医師に連絡したりするなど、実際に行動を起こすための知識は必ずしもありません。
そこで、会話管理を実装します。これは単に Strands SDK の一部です。会話管理とストリーミング用の非同期オペレータを用意して、これらの会話を維持します。その後、バックエンドのエンドポイントにアクセスしようとすると、最寄りの救急車で行くなど、そのような応答が得られます。しかし、繰り返しになりますが、実際に何かに対してアクションを起こすための実際のツールはありません。
では、これを修正するために、いくつかのツールを追加します。 ご覧いただけるように、これらはツールのダミー実装です。予約可能性ツール、予約ツール、そしてオンコール対応ページツールがあります。ただし、本当に見たいのは、提供されたインプットに基づいて、エージェントが十分にスマートにツールを選択できるかどうかです。 ツールの追加により、それに関連した追加のプロンプトエンジニアリングがあります。
その後、実際にエージェントを構築します。その前にやることの一つは、より高度なプロンプトを使用して、システムプロンプトを登録することです。 顧客からよく聞く一般的な課題の一つは、アプリケーションの一部として使用されるプロンプトを共有および管理する能力です。MLflow にはプロンプト管理機能があります。テストサイクルに使用する合理的なプロンプトが決まったら、そのシステムプロンプトを MLflow 内で設定できます。 ここのコードは基本的にそのプロンプトを MLflow に登録しているだけです。ここでプロンプト名が見えますし、MLflow の中を見に行くと、 これはテストプロンプトです。バージョンは1つだけですが、複数のバージョンを保持することになります。 これの良いところは、時々チームで何かを構築しているときに、みんなが Slack やその他の方法でプロンプトを共有しているだけですが、これを使うと実際にバージョン管理できますし、チーム全体でより簡単に共有できます。
本番環境の場合、系統の追跡にとって非常に重要です。この場合、テストプロンプトと言っているだけで、バージョン管理をしています。では、これを行ってプロンプトを作成したので、今度はツールを使ってエージェントを作成します。 この場合、作成したダミーツールを取得して、エージェントで利用可能にします。エージェントはバックエンドのファインチューニングされたモデルによってサポートされています。そうするために、ここでツールを利用可能にするだけです。これは予約可能性、予約、そしてオンコール対応のページングです。その後、今回はツールを使ってエージェントを呼び出します。
この場合、予約を取る必要があり、ここがエージェントの応答です。プロンプトで直接指示されています。患者が実際に予約を進める前に、症状を確認する必要があることを伝えています。これで良い応答が得られるようになりました。MLflow でできることの一つは、エージェントのトレーシングで、ツールが呼び出されていることを確認できることです。 これは今日エージェントを構築する際に本当に重要です。思考プロセスをトレースでき、ツールを呼び出しているとき、呼び出していないとき、呼び出しているふりをしているときを知ることは本当に重要です。
では、MLflow 内のエージェントトレーシングの一部を見てみましょう。 ここで、数日間それを経験しているようですね。医学的な問題です。 ここで、これはそれへの出力です。異なるケースで予約可能性がどこかにあります。 申し訳ありません、間違った実験にいます。 これですか？はい、そうです。ここでオンコール対応を実行しているのが見えます。医学的な緊急事態があるので、ツールが実際に呼び出されたのが見えます。そしてここでは、バックエンドでモデルと相互作用しているのが見えますが、ツールが実際にバックエンドで呼び出されているところが見えます。トレーシングはデバッグに本当に価値があり、ツールがいつ呼び出されているのか、呼び出されていないのか、そしてアプリケーションの実際のロジックフローが何であるかを知ることができます。
そして、先ほど申し上げたように、Agent Core observability などもこれまでリリースされてきたので、そういったものも使用できます。 これは、モデル実験のメトリクスをモデルとエージェント間で一緒にマージする必要がある場合に本当に便利です。そういったわけで、私たちは最初に Strands で開発しました。これは開発としてはかなり一般的なのですが、今度はそれをデプロイしてスケーラブルにしたいと考えています。そこで Agent Core runtime を使用して、実際にそのエージェントをホストします。 この場合、やることは前のものと非常に似ていますが、Agent Core では runtime agent を使用してエージェントをホストし、また Agent Core identity を使用してユーザーインタラクションを管理します。
そのためには、単にエージェントコードを書き出すだけです。 つまり、エージェントコードの Python ファイルです。そして、先ほど見たように SageMaker endpoint name を使用しています。 実際には、バックエンドの SageMaker モデルを指しています。ダミーツールも利用可能にしています。 そして、Cognito ユーザープールと認証を設定しています。ここが本番用のシステムプロンプトを登録する場所です。これは信頼性の観点からも、どのプロンプトバージョンがどのエージェントに付属しているかを把握する観点からも、確実にお勧めします。 そこでプロンプトを再度登録しますが、 この場合は本番プロンプトとして登録します。ここで見ると、バージョンは1つだけですが、複数のバージョンを保持することができます。 ご覧のように、これはその特定のエージェントに紐付けられたエージェントプロンプトです。
次に、エージェントを Agent Core runtime にデプロイします。この場合、ヘルパーツールを使用してエージェントを起動しています。 ここでは、Python コード内のエントリーポイントを指しています。また、エージェント名も指しており、これは Agent Prod medical triage agent Prod になります。そして authorization config を使用しています。ここが実際に起動している場所です。
実際に起動したら、エンドポイントをテストできます。トレーサビリティの観点からお勧めすることの1つは、ほとんどの場合、これは実際にはバックエンドの CD パイプラインにデプロイされるということです。本番環境に移行する準備ができたときにノートブックからデプロイするのではなく。 SageMaker エンドポイントに agent ARN と返ってくる agent ID でタグを付けることをお勧めします。そうすることで、そこにあるどのエンドポイントについても、そのエンドポイントを使用または依存しているエージェントがわかります。これらの依存関係は、このレベルの追跡がないと保守が難しいからです。ここでは、エンドポイントに agent ARN と agent ID でタグを付けています。
タグ付けした場所を示すタグのリストが表示されます。その後、エージェントを使用するだけです。前と同じように、invoke agent code と invoke endpoint code でエージェントを呼び出します。 前と同じようにプロンプトを送信しますが、今回はスケーラブルな Agent Core runtime compute で実行されています。 MLflow をエージェントトレーシング用に設定したので、MLflow に戻って本番レベルのトレースも確認できます。
異なるツールを呼び出している時と呼び出していない時が見えて、そういったことが全部自動的に収集されます。これは何度も反復処理をしていて、呼び出すべき時に呼び出して、呼び出すべきでない時に呼び出さないようにしています。例えば、鼻づまりは本当は緊急の電話ではないはずです。この場合、基本的には今日は利用できないと言っているだけで、医学的な緊急事態ではないので別の時間に予約することができます。
これは基本的に、特定のタスクに適応した fine-tuned モデルを使用して、より良いパフォーマンスを得るとともに、それをエージェント ワークフローと統合する end-to-end の例を示しています。念頭に置いておくべきことの一つは、lineage と traceability について話しました。モデルのカスタマイズで見たものは、自動的にキャプチャされる素晴らしい lineage を持っています。ただし、エージェント ワークフローで念頭に置くべき追加のことは、今日はノートブックで示しましたが、これは実験には素晴らしいです。実際には、ご存知の通り、本番環境へのデプロイメント時にエージェント用の continuous delivery、continuous deployment パイプラインに含める可能性が高いです。
考慮すべき異なるバージョンがたくさんあります。素晴らしい点は、左側の画像は全てモデルのカスタマイズで処理されるようになったということで、その完全な end-to-end lineage があります。右側は、CD デプロイメント パイプラインで念頭に置くべきことで、エージェント全体でそれらの異なるバージョンをキャプチャすることです。非常にシンプルなエージェントを実行しましたが、それだけでなく multi-agent orchestration ワークフローもあります。それらのバージョンと依存関係をキャプチャして、例えば一つの例として endpoint にタグを付けたように、そのエンドポイントに依存する複数のエージェントがあることを知ることができます。
短い時間で多くのことを説明しましたが、皆さん本当にありがとうございました。Amit に戻します。実は、もう一つ：コード例が欲しい場合、このミーティング前にプッシュできませんでした。別のミーティングがあったからです。今日プッシュします。新しいローンチのものが入っているので、プッシュできませんでした。申し訳ございません。スクリーンショットを撮ってくれれば、今日の終わりまでにコードをポストします。では Amit にお返しします。
Chaubli ありがとうございました。簡単に要約して、その後、ご質問があればお答えします。SageMaker は現在、トレーニングから評価、そしてモデルのデプロイまで、モデルをカスタマイズするための完全にマネージドでサーバーレスな体験を提供しています。SageMaker AI inference 機能を使用すると、同じエンドポイント上で複数のモデルをホストでき、簡単に自動スケーリングでき、最適化技術を使用してコスト効率を高めることができます。managed MLflow、serverless MLflow、またはパートナーの AI アプリを使用して、モデルのカスタマイズとエージェントの end-to-end observability を得ることができます。
SageMaker AI Pipelines を使用して、本日ローンチした新しいステップで、スケーラブルで反復可能なワークフローを構築できます。さらに、モデルのバージョンだけでなく、モデルのカスタマイズに使用される AI アセットのバージョンも追跡・監査できるようになりました。こちらが同じストーリーボードのバーコードです。完全なデモではありませんが、この例をステップバイステップで説明するストーリーボードです。ぜひチェックしてみてください。ご質問がある場合は、部屋の中央に 2 つのマイクがありますので、お気軽にご質問ください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion