re:Invent 2025: Amazon Nova Foundationモデルによるカスタムエージェント構築とfine-tuning手…
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Build more effective agents through model customization (AIM383)
この動画では、Amazon Nova Foundation モデルを使用したカスタムAIエージェント構築について解説しています。AIエージェントを「目標達成のためにループ内でツールを呼び出すLLM」と定義し、reasoning modelsの登場により複雑なタスクの分割や並列実行が可能になったことを説明します。モデルカスタマイゼーションの必要性として、エージェント型AIにおける複合的なミスのリスク削減、ドメイン固有の知識への適応、ツール呼び出しの精度向上を挙げています。カスタマイゼーション手法として、prompt engineering、RAG、context engineeringから、fine-tuning、model distillation、Direct Preference Optimization、Continuous pre-trainingまで幅広く紹介し、Amazon BedrockとSageMaker AIでの実装方法をデモを交えて具体的に解説しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：Amazon Novaを活用したカスタムAIエージェント構築の全体像
AIM383、モデルカスタマイゼーションを通じてより効果的なエージェントを構築する、にお越しいただきありがとうございます。私は2人のホストのうちの1人を務めさせていただきます、Davide Gallitelliと申します。SageMaker AIチームのWorldwide Senior Specialist Solutions Architectです。本日、ステージ上でご一緒させていただくSamをお迎えできて光栄です。Samさん、自己紹介をお願いできますか? 皆さんこんにちは、Sam Palaniと申します。AWSでNovaのgo-to-marketチームをリードしています。素晴らしい、ありがとうございます。
これはサイレントセッションですので、セッション後にご質問がありましたらお気軽にお越しください。コンテンツがかなり盛りだくさんですので、たくさんお話しすることがあります。それでは、これ以上お待たせせずに、早速始めていきましょう。 アジェンダですが、先ほど申し上げた通り、かなり盛りだくさんです。お話しすることがたくさんあります、新しいことがたくさん登場します。昨日と火曜日の時点で多くの新しいことが発表されました。皆さん、基調講演はご覧になりましたよね。
本日は、Amazon Nova Foundationモデルを使用してカスタムAIエージェントを構築する方法についてお話しします。Amazon Novaファミリーについて話すとき、利用可能なFoundationモデルはいくつあるでしょうか? そして、皆さんには独自のユースケースがあり、タスクを解決する方法にも独自の特性があることを理解していますので、Amazon Novaモデルをカスタマイズする方法をお見せします。オープンソースコミュニティの観点からも、BedrockやSageMaker内で皆さんにできることの具体的な内容からも、さまざまなテクニックがあります。それについてお話ししていきます。
もちろん、これはAWSのテックトークですので。デモなしでは終わりません。ですので、デモの一環として、Amazon SageMakerを使用したモデルカスタマイゼーションの例をご紹介します。そして最後にまとめます。皆さんのユースケースにNovaを使用する方法について、始めるためのリソースや詳しく学ぶためのリソースをご提供します。それでは、これ以上お時間を取らせません。残りのトークはSamにお任せします。ありがとうございます。
AIエージェントの基本概念とreasoning modelsがもたらした変革
ありがとう、Davide。それでは、サイレントセッションに参加されたことがある方はどれくらいいらっしゃいますか? なるほど。参加されたことがない方、私も同じです。これが私にとっても初めてのサイレントセッションですので。どうなるか見てみましょう。 基本から始めましょう。AIエージェントとは何でしょうか? さて、AIエージェントが何であるかについては、かなり多くの定義がありますが、業界の大部分も支持しているシンプルな定義は、目標を達成するためにループ内でツールを呼び出すLLMとして考えることです。
それでは、もう少し詳しく見ていきましょう。エージェントは、モデル、一連のツール、そして非常に具体的な目標にアクセスできます。そして、これらのツールを使用して、環境内で特定のアクションを実行します。環境とは、Webブラウザ、コンピュータのターミナル、あるいはエンタープライズアプリケーションのようなものです。そして、これらのアクションの結果を分析して、目標が達成されたかどうかを検証します。目標が達成されれば、ループは終了します。達成されていなければ、エージェントは目標が達成されるまで、さらにアクションを実行し続けます。つまり、モデルがツールを呼び出してループを回し、目標を達成するということです。
しかし、このエージェントAIにおける変曲点を引き起こしているものについても見ていきましょう。まずはreasoning modelsからです。さて、昨年のある時期、フロンティアモデルのインテリジェンスが壁にぶつかったという認識がありました。これらのモデルをトレーニングするために利用可能なすべてのデータを消費してしまったように見え、ほとんどのモデルリリースは、フロンティアインテリジェンスの根本的なシフトというよりも、むしろ段階的なアップデートのように見えました。また、スケーリング則も機能しなくなったように見えました。
簡単におさらいすると、スケーリング則は有名な法則で、より多くのデータを追加し、より長くトレーニングを続け、モデルサイズを増やし続ければ、最終的にはより高性能なモデルが得られるというものでした。それがもはや真実ではないように見えたのです。reasoning modelsが登場したとき、すべてが変わりました。突然、焦点は純粋なトレーニングからtest time computeとinference time computeへと移りました。何が起こったかというと、これらの新しいモデルは、すぐに考えて行動できるようになり、以前は困難だったエージェントAIの新しい機能を解き放ったのです。
reasoning modelsのもう一つの利点は、エージェントを大規模かつコスト効率の良い方法でデプロイできるようになったことです。例えば、複雑で長時間実行されるタスクを小さなタスクに分割し、それらを大規模に並列実行できるようになりました。また、タスクの複雑さに基づいて、より小さく効率的なモデルのバリアントにルーティングすることもでき、よりコスト効率が高くなりました。
さて、すべてのインテリジェンスと推論能力を備えたモデルでも、特定のコンテキストにアクセスできなければ、できることは限られています。そこで、この時期に見られたのは、組織がこれらの強力なモデルに独自のデータを接続できるようにする、安全なデータインフラストラクチャの構築にも投資したということです。そして最後になりますが、Model Context Protocol、agent-to-agentプロトコル、モデルレベルのスキル、さらにはtool callingなどの専門的なツールやテクノロジーの出現により、これらのエージェントの構築とデプロイのプロセスがさらに合理化されました。
エージェント型AIの現状とモデルカスタマイゼーションの必要性
しかし、これは私たちだけの話ではありません。これは、皆さんのようなお客様、皆さんのようなビルダーの方々が私たちに伝えてくださっていることなのです。
Gartnerによると、2028年までに全エンタープライズアプリケーションの3分の1が生成AIまたはエージェント型AIによって動作するようになり、日々のビジネス上の意思決定の15%がAIエージェントによって自律的に行われるようになるとされています。これらを視野に入れると、昨年の同時期には、この数字は1%に近いものでした。また、これらすべてのAIインタラクションのうち、少なくとも3分の1は、タスク完了のためにアクションモデルまたはAIエージェントを呼び出すことになると予測されています。しかし、これは未来のロードマップではありません。これは今まさに起きていることなのです。
このセッションはカスタマイゼーションに関するものですが、カスタマイゼーションは本番環境への道のりにおける一つのステップに過ぎず、他にも構築、デプロイメント、テストといったステップがあることを理解することも重要です。ただし、今回はカスタマイゼーションに焦点を当てます。
では、なぜエージェント向けのモデルカスタマイゼーションの文脈でカスタマイゼーションについて話すのでしょうか？フロンティアモデルのインテリジェンスは向上していますが、特にエージェント型AIにおいては脆弱な動作も示します。エージェントは目標を達成するために一連のステップを踏むことをご覧になりました。これにより、複合的なミスと呼ばれる独特のリスクが生じます。これは、あるステップでのエラーが他のステップに伝播し、複合的に影響を与えるというものです。例えば、モデルが単一のステップで95%の精度を達成するシナリオを考えてみてください。10ステップの過程で、これが実際には約60%まで低下するリスクがあり、高性能なモデルが非常に信頼性の低いエージェントになってしまう可能性があります。カスタマイゼーションは、ステップレベルでも、ステップ全体でも、これらのエラーを直接削減するのに役立ちます。
次のポイントはエージェント型AIに特有のものではありませんが、ここでも非常に適用可能です。皆さんのドメイン固有の略語、分類法、ビジネスプロセスの知識は、インターネット上の平均的なものではありません。カスタマイゼーションは、モデルを皆さん特有のビジネスセマンティクスに合わせて調整し、誘導するのに役立ちます。また、エージェントの文脈でツールについても話しました。これらのモデルが最初の試行でこれらのツール呼び出しを完璧に行うためには、基礎となるスキーマや、これらのツールを呼び出すために必要なパラメータをしっかりと理解していることが重要です。カスタマイゼーションは、まさにそれを実現するのに直接役立ちます。
さて、ミスの複合化という問題に関連して、カスタマイゼーションはエージェント型ワークフロー内の長時間実行されるチェーンを圧縮するのに役立ちます。モデルは各ステップのマイクロポリシーを学習します。その結果、軌跡が短くなり、バックトラックが減り、行き止まりも減少します。ディスティレーションなどのカスタマイゼーション技術は、P50およびP90のレイテンシとステップあたりのコストを直接削減するのに役立ちます。しかし、カスタマイゼーションとは何を意味するのでしょうか？
モデルカスタマイゼーションの技術スペクトラム：プロンプトエンジニアリングからcontinuous pre-trainingまで
ここで考えたい基本的な定義として、カスタマイゼーションとは、モデルの動作を変更するためにモデルに対して行うあらゆることです。ここでご覧いただけるように、シンプルなものから始まり複雑さが増していく、幅広い選択肢があります。高いレベルでは、これを2つのカテゴリーに分類するのが好ましいと考えています。それは、出力を最適化することと、基礎となるモデル自体を変更することです。言い換えれば、重みの更新を行わずに出力を最適化することと、実際にモデルに重みの更新を行ってモデルを変更することです。
スペクトラムの最もシンプルな端には、プロンプトエンジニアリングのような技術があります。これは、シンプルなfew-shotの例から、より複雑なchain-of-thoughtの例、そして効率的なシステムプロンプトやユーザープロンプトの作成など、その間のすべてを説明するために使用する包括的な用語です。次に、Retrieval Augmented Generation、つまりRAGがあります。これらのモデルのコンテキストサイズは過去数年で指数関数的に増加していますが、RAGは特に実行時にモデルに追加のコンテキストを提供する非常に効果的な方法であり続けています。
コンテキストエンジニアリングは、特にエージェント型AIに対してモデルを最適化する最も効果的な方法として登場しました。さて、物事をシンプルに保つというテーマに沿って、コンテキストエンジニアリングを、適切な情報を適切な形式で適切なタイミングでモデルに提供することと考えることができます。考えてみれば、モデルにはプロンプトだけでなく、アクセスできるツールの十分な理解、RAGパイプラインの一部として取得された追加のコンテキスト、そして以前のすべてのインタラクションのメモリも必要です。
さて、離散的なプロンプトを扱うプロンプトエンジニアリングとは対照的に、コンテキストエンジニアリングは、LLMへのパスが行われるたびにキュレーションが行われる反復的なプロセスです。
それでは、基盤となるモデル自体を修正する手法に移りましょう。これはさらに2つのサブカテゴリーに分けることができます。ポストトレーニング手法とプレトレーニング手法です。このブレイクアウトセッションの残りの時間は、この部分に焦点を当てていきます。ポストトレーニング側では、ファインチューニングまたは教師ありファインチューニング、モデル蒸留、そしてDirect Preference Optimization、DPO、PPOなどの強化学習手法があります。そしてプレトレーニング側では、継続的プレトレーニングなどの手法があります。これらの手法については、進めていく中でさらに詳しく説明していきます。
まずはファインチューニングから始めましょう。では、挙手をお願いしたいのですが、この中でファインチューニングを試したことがある方はどのくらいいらっしゃいますか?いいですね。さて、ファインチューニングについて話すとき、これには基盤モデルの重みを修正するフルファインチューニングと、パラメータ効率的ファインチューニング、つまりPEFTの両方が含まれます。PEFTでは、基盤レイヤーを凍結し、追加された低ランクパラメータのセット、つまりアダプターのみをトレーニングします。これらが低ランクと呼ばれるのは、基盤モデルの重みと比較して、より低い次元またはランクだからです。
比較的小さなラベル付きデータセットを使用して、特定のタスクにモデルを適応させることから始めます。そのため、これは教師ありファインチューニングとも呼ばれます。Direct Preference Optimization、つまりDPOは、報酬モデルをトレーニングすることなく、非常に特定のユーザー選好にモデルを整合させたい場合に使用します。DPOは、上で説明したようにパラメータ効率的な方法で行うこともできますし、フルDPOを行うこともできます。
Proximal Policy Optimization、つまりPPOは、ライブフィードバックに基づいてモデルを改善する方法です。そのライブフィードバックはどのように得るのでしょうか?タスクの完了、ツールの実行、またはより一般的には、直接的な人間のフィードバックを通じて得ることができます。ここで覚えておくべき重要なことがいくつかあります。強化学習の完全なサイクルが必要になるため、報酬モデルと関数が必要になります。これはよりコストがかかり、時間もかかりますが、非常に特定のユースケースに対して本当に良い結果を得ることができます。
モデル蒸留は、教師モデルと呼ばれる大規模で高性能なモデルから、生徒モデルと呼ばれる小規模でより効率的なモデルへ、複雑な振る舞いを蒸留する手法です。先ほど見たように、蒸留はタスクレベルでレイテンシーとコストを直接削減するのに役立ちます。
Continuous pre-trainingは、その名前が示す通り、ベースモデルの事前学習チェックポイントに対して、大規模なラベルなしデータのコーパスを使用して学習を継続する事前学習テクニックです。ここで重要なポイントは、大規模なラベルなしのドメイン固有データのコーパスが必要になるということです。また、過学習やカタストロフィック・フォーゲッティングといったリスクにも注意する必要があります。これらのリスクを軽減するために、早期停止やインテリジェントなデータミキシングの実装といった追加のテクニックを使用することができます。そして、Davidが SageMaker のカスタマイゼーションについて詳しく説明する際に、この点について多くをカバーします。
Amazon Novaファミリーの全容とBedrockでのカスタマイゼーション機能
では、Amazon Novaに移りましょう。皆さんの中で、Novaを使ったことがある方はどのくらいいらっしゃいますか?かなり多いですね。実は、ほんの数日前に大きなリリースがありました。このスライドはそれらすべてのリリースをカバーするように更新されていませんが、喜んですべてについてお話しします。一番上には、理解と推論のモデルがあり、Nova Microから始まります。これは私たちの最速かつ最も効率的なtext-to-textモデルです。多くのお客様が、レイテンシーに敏感なエージェンティックワークフローでMicroを使用しているのを見ています。
次に、マルチモーダルな理解と推論のモデルがあります：Lite、Pro、そしてPremiereで、それぞれインテリジェンスが向上しており、Premiereは2日前まで私たちの最もパフォーマンスの高いモデルでした。なぜなら、2日前にNova 2 Proをリリースしたからです。これが現在利用可能な最もパフォーマンスの高いモデルです。多くのお客様が過去にPremiereを蒸留パイプライン内のティーチャーモデルとして使用していました。
今後は、おそらくProを使用することになるでしょう。次に、クリエイティブコンテンツ生成モデルがあります。Nova Canvasから始まり、これは私たちのtext-to-image生成モデルで、Nova Reelは私たちのtext-to-video生成モデルです。2日前には、Nova 2 Omniも発表しました。これは最先端でより高性能なtext-to-image生成モデルです。
次に、Amazon Nova Sonicがあります。これは業界初のリアルタイムspeech-to-speechモデルで、自動話者認識、話者ダイアライゼーション、ポリグロット音声、そして多言語サポートといったフロンティア機能を提供します。Nova Actも2日前に一般提供が開始されました。これはエージェンティックなブラウザ使用モデルで、ブラウザ内で動作するエージェントを構築するために特別に設計されています。私たちは、エージェントが環境内でアクションを取ることについて話しましたが、そのアクションの1つがWebブラウザである可能性があります。ですから、Webブラウザ内で動作するように設計されたエージェントを構築している場合、Nova Actはそれを行うために特別に設計されたモデルです。
さて、皆さんご存知の通り、エンベディングはあらゆる生成AI アプリケーションやエージェンティックAI アプリケーションの基盤となるものです。ごく最近、実際には数ヶ月前ですが、Nova マルチモーダルエンベディングモデルをリリースしました。これは業界で利用可能な唯一のエンベディングモデルで、テキスト、動画、画像、音声といったすべてのマルチモーダルデータに対して、同じベクトル空間内でエンベディングを生成します。これが重要な理由は、セマンティック検索やエージェンティックRAG を活用した非常に強力なアプリケーションを構築できるようになるからです。
最後になりますが、Nova の公式ウェブサイト、nova.amazon.com では、これらのモデルを無料で、またはAWS アカウントなしで試すことができます。さて、ここのチャートは少し複雑に見えますが、見ていただくと、Nova はAmazon Bedrock とSageMaker AI の両方で幅広いカスタマイズオプションを提供しています。これらのオプションのほとんどは、フルランクオプションとしても、先ほど説明したパラメータ効率的なローランクオプションとしても利用可能です。選択するオプションに応じて、Bedrock でカスタマイズを行うか、SageMaker AI でカスタマイズを行うかを選択できます。
完了したら、このモデルをAmazon Bedrock 上でサーバーレスな方法でデプロイできます。例えば、モデルディスティレーションを選択する場合、Amazon Bedrock で素早く実行することも、SageMaker AI で独自のディスティレーションパイプラインを構築することもできます。完了したら、ディスティルされたモデルをAmazon Bedrock にインポートし、オンデマンド推論またはプロビジョンドスループットを使用してデプロイできます。これらのデプロイオプションについては、さらに進めていく中で詳しくお話しします。
Amazon Bedrockにおけるファインチューニングとモデルディスティレーションの実践
しかし今は、Amazon Bedrock で利用可能なNova のカスタマイズオプション、特にファインチューニングについて見ていきましょう。さて、ファインチューニングについてお話ししました。また、ベースモデルの重みを変更するフルファインチューニングと、追加されたローランクパラメータのセットを訓練するパラメータ効率的なファインチューニングについても取り上げました。Bedrock では、パラメータ効率的なファインチューニングを行い、わずか数クリックでモデルをデプロイできます。
これは教師ありファインチューニングの一種なので、ラベル付きデータのセットをアップロードすることから始めて、ファインチューニングジョブを開始します。ジョブが完了すると、モデルは他のBedrock モデルと同様にBedrock プラットフォーム上で評価とテストに利用できるようになります。スケールやデプロイを決定する前に、Bedrock モデルプレイグラウンドでモデルを試すこともできます。このタイプのファインチューニングでよく見られるエージェンティックAI のユースケースの1つは、ツール呼び出しとスキーマスティッキネスで、モデルに非常に特定のJSON スキーマを一貫して出力させたい場合です。
もう一つの良い例としては、ペルソナスイッチングがあります。これは、agentic AIワークフロー全体で同じベースモデルを使用しながら、セールスやサポートなど複数のペルソナを切り替えたい場合です。さて、簡単におさらいしますと、モデルディスティレーションとは、より大きく高性能なモデルから複雑な動作を、より小さく効率的なモデルへと蒸留する技術です。では、ここにいらっしゃる皆さんの中で、モデルディスティレーションを実施したことがある方はどれくらいいますか？素晴らしいですね。あちらに一人の方がいらっしゃいますね。
もしモデルディスティレーションを実施したことがあれば、モデルディスティレーションにおける最大の課題の一つは、ディスティレーション用の堅牢なデータパイプラインを構築することだとお分かりでしょう。
Bedrockを使えば、モデルディスティレーションもまた、わずか数クリックで実行できます。考えてみてください、ディスティレーションとは、ループ内にティーチャーモデルを含むファインチューニングの一種に過ぎません。つまり、Bedrockでこれを行う場合、まずティーチャーモデルとスチューデントモデルを選択することから始めます。タスク固有のプロンプトのセット、プロンプトだけをアップロードします、レスポンスではありません。Bedrockは自動的にティーチャーモデルを使用して、アップロードしたプロンプトに対するレスポンスを生成します。そして、ティーチャーモデルによって生成されたプロンプトとレスポンスを使用して、スチューデントモデルをファインチューニングします。
ここでの良い例は、高性能なプロトタイプを本番環境に移行することです。例えば、プロトタイプが高性能なモデルでしか動作しない場合、本番環境にデプロイしてスケールする際に、それらの特定の動作をモデルのより小さなバリアントに蒸留することを選択できます。さて、デプロイメントについてですが、Bedrockは2つのデプロイメントモードを提供しています：オンデマンド推論、これはトークンベースの従量課金制の価格設定です、そしてプロビジョンドスループット、これは保証されたスループットに対して事前に固定価格を支払うものです。
SageMaker AIによる高度なモデルカスタマイゼーション：HyperPodとレシピの活用
それでは、カスタマイゼーションのSageMaker側に移りましょう。Davidが喜んで説明してくれます。ありがとう、Sam。皆さん、以前のNovaをカスタマイズするさまざまな技術についてのマインドマップを見ましたか？あれはSamが作成した作品だということを強調したいと思います。私がこの会社で過去7年間に見た中で最高のマインドマップの一つだと思います。ですから、彼が行った仕事、そして彼が戻ってから行うであろう仕事に対して、本当に称賛したいと思います。なぜなら、私たちは今、新しい技術をリリースしたからです。ですから、彼が戻ってきて月曜日に最初にすることは、あのスライドを更新することになるでしょう。
しかし、ここで少し他のカスタマイゼーション技術に焦点を当てましょう。これまでAmazon Bedrockを使用してファインチューニングやモデルディスティレーション機能でカスタマイゼーションを実行する方法をご覧いただきましたが、もう少し深く掘り下げてみましょう。もしあなたが少し上級者で、ファインチューニングプロセスをもう少しコントロールしたい場合、Bedrockは依然として多くの機能や調整可能なパラメータを提供してくれます。しかし、トレーニングプロセスに対してより低レベルの理解と低レベルの影響を与えたい場合は、SageMakerがあなたの頼りになるツールでなければなりません。
これはエンドツーエンドの機械学習プラットフォーム、機械学習エンジン、もちろんAIプラットフォームであり、ファインチューニングしたいモデルを選択することができます。お好みのオプションを使用してファインチューニングを実行でき、ここに2つの例があります：フルマネージドでサーバーレスなモデルファインチューニングのためのtraining jobs APIです。サーバーレスファインチューニングは昨日の朝発表したばかりですので、ぜひチェックしていただくことを強くお勧めします。または、SageMaker HyperPodの形で、完全に自分自身で管理する完全なオーケストレーションを行うこともできます。
HyperPodはEKSまたはSlurmのいずれかに基づくマネージドクラスターで、トレーニングワークロードのためのインフラストラクチャを管理して、本当にもう一段階深いレベルに進むことができます。先ほど申し上げたように、SlurmやKubernetesを通じて、どのようなオーケストレーションを行いたいかを本当にカスタマイズすることができます。また、実際に支払っているリソースを最大限に活用できるように、ワークロードをスケジュールすることもできます。しかしそれだけではなく、SageMakerは最適化されたレシピも提供しており、トレーニングが成功し、初回からうまく機能することを確実にします。
ですから、あなたが焦点を当てるべきことは、トレーニングループのためにどのような最適なコードを書く必要があるかを考え出すことではありません。ほとんどの場合、お客様がデータサイエンスプロセスに焦点を当て、データがない場合はデータを生成し、すでにデータがある場合はそのデータをクリーニングし、そしてこのデータをすでによく知られているスクリプトに提供しているのを目にします。そこで私たちがバックエンドで行ったことは、それらのスクリプトを取得し、それらのスクリプトの一部をカスタマイズして、私たちのアーキテクチャで最高のパフォーマンスを発揮するようにし、それらをレシピの形でパッケージ化したということです。
現在、私たちはそれらをHyperPodレシピと呼んでいますが、これらはSageMaker training jobsでも機能します。ですから、モデルのトレーニングに対してよりサーバーレスまたはマネージドなアプローチを好む場合は、ぜひSageMaker training job、つまりSMTJを使用してください。あるいは、より低レベルのカスタマイゼーションとオーケストレーションを行いたい場合は、これらはHyperPodにも互換性があります。それでは、これらのレシピがどのように機能するかをより詳しく見ていきましょう。
まず最初に、Novaレシピを選択します。そしてSageMakerコントロールプレーンにAPIコールを行います。すると、SageMakerで利用可能なランチャーの一部を活用して、HyperPodインスタンス上で適切なトレーニングジョブを起動し、ECRトレーニングイメージをデプロイされたインスタンスに直接ダウンロードし、最後にデータをロードします。
お持ちのさまざまなデータソースから、それがS3であろうと、FSxであろうと、EFSであろうと、データをロードします。この画像は少し速いことは承知していますが、これは公開されているブログの一つから取ってきた画像です。ですので、SageMaker Recipesを使ってSageMakerでモデルをトレーニングする方法を理解し、簡素化する方法についてもっと学びたい場合は、右側に表示されているQRコードをスキャンしてみてください。このインフラストラクチャを紹介するブログ記事に直接アクセスできます。多くの方が写真を撮っているようですので、画像全体が表示されるまで少し待ちますね。素早く撮る必要がありますよ。さあ、今が写真を撮る瞬間です。完璧です。
さて、これらのスライドはオフラインでも送付しますので、その写真をできるだけ速く撮れなくても心配しないでください。すべてオンラインで利用可能です。繰り返しになりますが、ブログが皆さんの最良の友となるでしょう。では、これから私が行うのは、先ほどアーキテクチャでお見せしたすべてのことを実際にStudioコンソールで行う方法について、簡単なデモをお見せすることです。デモを始める前に一つお伝えしておきたいのは、ご存知の通り、今週は多くのものをリリースしており、SageMaker Studioのコンソールへのマイナーアップデートも含まれています。ですので、今ご覧いただいているものは2日前までは正しかったのですが、スライドを事前に準備しなければならなかったため、まだ新しいビデオに更新する時間がありませんでした。しかし、これからお話しする概念については、UIがどのように見えるかに関係なく、まったく同じになります。
では、SageMaker AIでNovaモデルを使ってDirect Preference Optimizationを行う方法を始めましょう。どのように機能するのでしょうか？SageMaker Studioに入り、解決したいユースケースがあり、すでに頭の中にユースケースがあるので、どこから始めるかを考える必要があります。この場合、出発点は常にJumpStartハブです。なぜなら、NovaはJumpStartモデルハブの一部として利用可能だからです。現在はModelsと呼ばれています。使用したいモデルを選択します。Samは以前Nova Microについて話していましたが、今はNova 2.0 Liteなども使用できます。そして、一番上にあるTrainボタンを選択すると、適切なトレーニングオプションを選択できるようになります。どうやらここで止まってしまったようなので、もう一度素早くやり直しますね。ライブデモの良いところは、録画でさえも時々壊れることがあるということです。PowerPointは必ずしも私たちの味方ではありません。
でも、まあ、おさらいしましょう。JumpStartに行って、モデルハブから適切なモデルを選びます。そこには多くのモデルがあります。今はNovaに焦点を当てていますが、Llamaモデル、Qwenモデル、Mistralモデルもあります。本当に、選択の問題です。ユースケースに適したものを選んでください。それらの中にはトレーニング可能なものもあるので、一番上にあるTrainを選択できます。そして、Supervised Fine-TuningなのかDirect Preference Optimizationなのか、使いたい適切なテクニックを選択できます。必要なコンピュートが何か、必要なデータのフォーマットが何かを教えてくれるので、ジョブを開始する前に適切なフォーマットでデータを用意してください。ノートブック自体のコードも表示されるので、UIを通じて何かをする必要はありません。コードが提供されます。この例では、SageMaker HyperPodでレシピを使用する方法を説明しますが、トレーニングジョブを使用することもできます。
トレーニングクラスターが利用可能であることを確認してください。つまりHyperPodクラスターが利用可能であることを確認します。この場合、SageMaker HyperPodのRestricted Instance Groupクラスタータイプになります。そして、あとはそのクラスターを選択して、ボタンをクリックしてHyperPodクラスター上で動作している適切なJupyterLab空間でノートブックを開くだけです。もちろん、これらのノートブックは公開されています。GitHubリポジトリで利用可能です。ですので、HyperPodクラスターを用意したくない場合は、ウェブから直接ノートブックを取得することもできます。ノートブックには多くの情報が含まれており、通常の前提条件、通常のインストール、さまざまなコードの実行が含まれています。実際にトレーニングジョブを開始するためのコードが何であるかを示しており、私たちがレシピを指定していることがわかります。そして、HyperPodクラスターから実際のトレーニングジョブを開始すると、すべての情報がSageMaker HyperPodの利用可能なタスクで確認できるようになります。
モデル評価からデプロイメントまで：LLM as a judgeとBedrock推論の実装
では、モデルのカスタマイゼーションとエージェント作成のためのエンドツーエンドのパスに戻りましょう。これまでカスタマイゼーションについて説明してきましたが、次のステップはモデルの評価です。では、LLMの評価をどのように行うのでしょうか？さまざまな技術があり、さまざまなメトリクスがあり、評価を正しく実行するための銀の弾丸はありません。さまざまな技術があります。一般的なメトリクスがあります。例えば、perplexityやaccuracyを使用して、モデルの品質を統計的に評価することができますが、もう少し深く掘り下げて、例えば、タスク固有のメトリクスを考慮することもできます。
これは特にエージェントの世界では非常に関連性が高く、エージェントが実際に問題を正しい方法で解決する軌跡に従っていることを確認したい場合です。結果は同じかもしれませんが、あるモデルやエージェントは10ステップかかるのに対し、別のものは2ステップで済むかもしれません。ですので、ステップ数である可能性もありますし、その間に実行されるステップの品質である可能性もあります。もちろん、ハルシネーション、バイアス、毒性のメトリクスについても忘れてはいけません。ですので、これらすべての種類のメトリクスを、モデルを正しい方法で評価するために考慮する必要があります。
では、モデルの評価をどのように実行できるでしょうか？古典的には、ルールベースのヒューリスティックを使用します。例えば、これは公開されている、または一般的に知られているメトリクス、例えばF1、ROUGE、またはその他のよく知られたメトリクスを使用することだけを気にする場合に最適です。本当に良い例としては、例えばSQLクエリの生成やSQLクエリの実行といった問題を解決している場合もあります。生成したSQLクエリは実際に実行されるでしょうか？SQLクエリから出てくる結果は、実際に正しいのでしょうか、それとも間違っているのでしょうか？このようなルールベースのアプローチを活用して、モデルトレーニング自体を改善するために使用できます。RLVRのような技術、つまり検証可能な報酬を用いた強化学習について考えています。その場合、クエリを実行して結果を得ます。結果は正しいでしょうか？モデルトレーニングに報酬を与えましょう。正しくない場合は、負の報酬を与えるだけです。
しかし、一部のユースケースでは、モデルを評価するためのヒューリスティックやルールを正しく定義する方法が必ずしもあるわけではありません。そのため、LLM as a judgeまたはLLMベースのcritiqueを使用します。これは非常に柔軟な技術であり、非常にカスタマイズ可能な技術です。なぜなら、より大きなモデル、教師モデルと呼びたければそう呼んでもいいですが、むしろ審査モデルと呼ぶべきものを通じて評価できる特定のプロンプトを定義できるからです。これにより、別のモデルからのテキスト出力を評価することができます。では、例えば、Samが以前言っていたように、Nova Proがあります。これは素晴らしいモデルで、非常に大きなモデルで、さまざまなユースケースで非常に優れたパフォーマンスを発揮しますが、Nova Microが私が望むユースケースを解決できることを確認したいとしましょう。
では、私ができることは、先ほどお見せしたように、Nova Microをファインチューニングして、その後、例えばNova Proを活用してファインチューニング後のNova Microの出力と推論を評価することです。これにより、例えばベースのパフォーマンスとファインチューニング後のパフォーマンスを比較できるようにします。結果は良くなっているのか？どの程度良くなっているのか？例えば、SQLクエリのユースケースに戻ると、セマンティックな正確性というのは、実際には数値として計算できるものではありません。誰かがあなたのSQLクエリのセマンティクスを見て、このようにSQLクエリを書くことが、実際にこの別の書き方と同等なのかを判断しなければなりません。そして、LLMはこの種のタスクを実行するのが得意なんです。
LLMをジャッジとして使用する評価のための異なるメトリクスについてもっと知りたい場合は、いくつかの例の全リストがあります、しかし、繰り返しになりますが、私が通常提案するのは、あなたのユースケースに最も適したメトリクスを評価し、場合によっては作成することです。私の場合は、セマンティックな正確性またはセマンティックな同等性でした。あなたの場合は、まったく異なるものかもしれません。
さて、あなたはHyperPodまたはSageMakerトレーニングジョブを使用してモデルをファインチューニングし、モデルのパフォーマンスを評価しました。では、その後は何をするのでしょうか？次のステップは、そのモデルを取得して、クエリと推論に利用できるようにすることです。さて、Novaモデルを取得して、カスタムモデルインポートを使用してBedrock inference上にデプロイできます。そのモデルのオンデマンドプロビジョニングを使用できます。つまり、そこにあって、実際に呼び出すまではオフラインになっています。起動するのに1秒かかりますが、その後は好きなだけ推論に利用できます。これはSFT、DPO、Direct Preference Optimization、そしてdistillationなどの技術で利用可能です。
または、プロビジョンドスループットを通じて利用できます。つまり、常に利用可能で、常にそこにあり、呼び出すだけでクエリを実行できますが、これはすべての技術で利用可能です。一方で、そのモデルを取得してSageMaker上にデプロイすることもできます。リアルタイム推論エンドポイント、つまり実質的には仮想マシン、SageMakerコントロールプレーンによって管理されるインスタンスでも可能です。イメージをロードし、モデルイメージをロードすれば、24時間365日、好きなだけクエリを実行できます。または、HyperPodを使用することもできます。最近、HyperPodで推論エンドポイントを実行する機能を導入しましたので、推論エンドポイントを実行している分単位で支払うか、高度にスケーラブルなクラスターで利用可能にしておくかを選択できます。
ただし注意点として、現在、Amazon NovaモデルをSageMaker上にデプロイすることはできません。エンドポイントでもHyperPodでもできませんが、ただ待っていてください。これ以上は何も言えないのですが。
それでは、評価とデプロイメントがどのようなものか見ていきましょう。モデルをトレーニングした後、上部にあるevaluateを選択することができます。GitHubには評価用のレシピも用意されています。先ほどと同じように、実行したいレシピを選択できます：general text benchmark、question and answering用の独自データセットの持ち込み、またはLLM as a judgeレシピです。この例ではquestion answerを実行します。常にview the formatというボタンがあり、もう一度言いますが、HyperPodを使用する場合は、HyperPod start jobでレシピへのパスを指定するだけで簡単です。
もう一度言いますが、これはHyperPodクラスター管理のタスクになります。HyperPod task managerがあれば、すべてが表示され、評価メトリクスを出力して、Streamlitアプリで、または直接ノートブックで、お好みの方法で利用することができます。その後、モデルを推論のためにBedrockにデプロイできます。文字通り2つの呼び出しだけです：create a custom model importまたはcreate provision model throughputです。
これだけで完了です。そして質問をすることができます。What is the weather in Rome, Italy?もちろん、エージェントにツールを提供することを忘れないでください。そうしないと、この時点でRomeの天気がどうなっているか、どうやって知ることができるでしょうか?そしてお気づきかもしれませんが、はい、私もイタリア人なんです。だからこのデモではRome, Italyについて話しているんです。私はRome出身ではありませんが、美しい街です。もし行ったことがなければ、ぜひ行ってみてください。
エージェントの本番環境展開とまとめ：オープンソースフレームワークからBedrock Agent Corpまで
素晴らしいですね。モデルをカスタマイズし、そのパフォーマンスを評価し、エンドポイントで、またはこの場合はBedrock custom model inferenceで、モデルを本番環境にデプロイしました。では、どうやって本番環境に移行するのでしょうか?つまり、実際にエージェントをどうやって構築するのでしょうか?この会場で既にエージェントを構築したことがある方はいらっしゃいますか?いいですね。多くの方がエージェントを構築されているのが見えます。
そして、これらのオープンソースフレームワークのいずれかを使用されたかもしれませんね?私たちの心はStrauss Agentsにあります。なぜなら、これはAWSテクノロジーを使ってシンプルな方法でエージェントを構築するための、私たちが持っている意見のある方法の1つだからです。そして必ずしもAWSテクノロジーだけではありません。Strauss AgentsはOllama、OpenAI、Gemini、Anthropicに接続できるフレームワークであることがわかるでしょう。本当に、どんな種類のモデルプロバイダーにも接続できます。私たちはこれがエージェントを構築する最も簡単な方法だと考えていますが、皆さんには皆さんの意見のある見方があることも知っています。ですから、LangGraph、LangChain、OpenAI Agents SDK、CrewAI、Google ADK、LlamaIndexを使いたい場合、そしておそらく私が存在すら知らない他の多くのフレームワークがあると思いますが、そこにあるほとんどのフレームワークはBedrock custom model inferenceと互換性があります。推論を生成するためのSageMakerエンドポイントとも互換性があります。
そして、エージェントを構築し、エージェントを作成するためのコードを書いたら、次のステップはそのエージェントを本番環境に投入することです。私たちは、エージェントのデプロイメント、管理、そして実行のためのエンドツーエンドのマネージドプラットフォームを作成しました。それがAmazon Bedrock Agent Corpです。もしAgent Corp専用のセッションに参加されていない方は、今日から明日の間にぜひAgent Corpのセッションに行かれることを強くお勧めします。非常に興味深いサービスだと思いますので、ぜひチェックしてみてください。また、このサービスには多くの異なるサブサービスが含まれており、私たちが「プロダクション・キャズム」と呼んでいるものにおける様々な問題を解決してくれます。
では、エージェントを開発から本番環境まで持っていくために何が必要でしょうか。エージェントをどこで実行するのか？メモリを持つのか持たないのか？エージェントにはメモリを使ってください。アイデンティティ：異なるリソースにアクセスするための権限をどのように持つのか？企業内で利用可能なAPIにどのように接続するのか？例えば、code interpreterやbrowserのようなツールを使って、効果的にコードを実行したりウェブに接続したりするにはどうすればよいのか？そして最後に、おそらく最も重要なのは、オブザーバビリティの観点から、エージェントがどのように動作しているかをどのように理解するのか、ということです。
もう十分話しましたね。2つのデモを見て、エージェントの機能についてカバーし、モデルのカスタマイズ方法についてもカバーしましたので、少しまとめていきましょう。この後、家に帰られたら、もちろんまず今夜のリプレイを楽しんでから、それから帰ってください。生成AIのユースケースを解決するために必要なことは、まず第一に、既に利用可能なモデルを試してみることでしょう。世の中には多くの優れたモデルがあります。Samがcontext engineering、RAG、prompt engineeringといったテクニックを紹介してくれましたが、これらはすでにあなたの問題をそのまま解決するのに役立つでしょう。
もしあなたの問題が本当にカスタムなものであれば、モデルのカスタマイゼーションを評価したいと思うかもしれません。よりシンプルな方法としては、Bedrockを使って行うことができます。始めるのは本当に簡単です。もう少しコントロールが必要な場合は、SageMakerで利用可能なテクニックを使ってモデルをカスタマイズすることができます。
ファインチューニング後は必ずモデルのパフォーマンスを評価してください。なぜなら、実際にベースモデルよりも良いパフォーマンスを発揮しているかどうかを理解したいからです。あるいは、追加のテクニックを試したいと思うかもしれません。そして、そのモデルはクエリに対応できるようにする必要がありますので、Bedrock Custom Model InferenceまたはSageMaker inferenceでデプロイします。エンドポイントでもHyperPodでも構いません。最後に、お好みのオープンソースフレームワークでエージェントのコードを書いてください。改めて、LangChainとAgentsに感謝を。そして、Amazon SageMakerやAmazon Bedrock Agentsのようなツールを使って、それを本番環境に持っていきましょう。
いつカスタマイズが必要になるのか？これは最初の段階で自分自身に問いかけるべき、非常に妥当で興味深い質問です。繰り返しになりますが、私にとって最も簡単な方法は、まずベースモデルをそのままテストして、そこからより高いパフォーマンスが必要か、ビジネスにより適合させる必要があるか、よりコスト効率的にする必要があるかを判断することです。多くのお客様が、大規模言語モデルを使用するのではなく、より小規模な言語モデルに移行しているのを見てきました。なぜなら、それらははるかにコスト効率が高く、カスタマイズが可能で、大規模モデルのコストのほんの一部で1つのタスクを非常にうまく解決できるからです。しかし、これは技術的な問題でもあります。おそらくすでにトレーニングデータを持っているかもしれません。それによってモデルのカスタマイズが非常に簡単になります。あるいは技術的な専門知識を持つチームがいるかもしれません。そのチームはモデルのファインチューニングのための強化アルゴリズムとして効果的に機能することができます。
ファインチューニングに利用可能なテクニックをまとめると、BedrockはLoRAとinstruction tuningをサポートしています。SageMakerはさまざまな異なるテクニックの全範囲をサポートしているので、あなたにとって最も意味のあるものを選択することができます。 そして、ここから持ち帰っていただきたいことの1つは、1つのファインチューニングテクニックだけに落ち着かないでください、ということです。ファインチューニングはスペクトラムです。プロンプトエンジニアリングから、continued pre-training、LoRA、full rank、そして他のすべての異なるテクニック、Direct Preference Optimizationなどまで続きます。ですから、モデルのカスタマイズプロセスにどれだけの時間と労力をかけたいか、このプロセスをどれだけ複雑にしたいか、そして異なるテクニックからどのような結果を期待するかを、本当によく評価してください。
そしてもちろん、Amazon Novaについて、そして一般的にAWSテクノロジーについてもっと学びたい場合は、 Skill Builderポータルがあることを覚えておいてください。これはより実践的に学ぶための素晴らしい方法です。まず第一に、ドキュメントを読む必要がありますが、もう少し実践的に学びたい場合や、いくつかのテクニックの特殊性についてもっと学びたい場合は、Skill Builderプロセスに進むことができます。そこにはNovaのためのすべてのトレーニングと、他の多くのテクニックのためのトレーニングが用意されています。
それでは、お礼を申し上げたいと思います。この長い時間、私たちの話を聞いていただきありがとうございました。もし何か質問があれば、私たちはこの部屋のすぐ隣にいますので、お気軽に来て質問してください。そして、お帰りの際には、アプリでアンケートに記入するために少し時間を取っていただけることを覚えておいてください。私たちはフィードバックは贈り物だと言っています。SamとDavidは素晴らしいプレゼンターだったと言っていただけると、いつも嬉しいです。そうすれば、次のセッションを楽しみにしています。どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion