re:Invent 2025: Amazon NovaモデルのTool Calling機能強化のためのカスタマイゼーション手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Customize Amazon Nova models for enhanced tool calling (AIM380)
この動画では、Amazon Novaモデルのtool calling機能を強化するためのカスタマイゼーション手法が解説されています。HarshとAnupamが、Synthetic Data Toolkitを用いた合成データ生成から、LoRAベースのSupervised Fine-Tuning、Reinforcement Fine-Tuningまでの実装を実演します。SEC規制準拠を確認する法律アシスタントエージェントをユースケースとし、ベースモデルの精度44%からSFT後74%、RFT後90%まで向上させる過程を示します。Nova Lite 2とNova Premierを使用し、SageMaker training jobsでのトレーニング、Lambda関数による報酬関数の設計、最終的なBedrockへのデプロイメントまで、エンドツーエンドのワークフローが詳細に説明されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
モデルカスタマイゼーションの全体像：プロンプトエンジニアリングからpre-trainingまで
皆さん、こんにちは。このセッション、AIM380、Customize Amazon Nova Models for Enhanced Tool Callingにご参加いただきありがとうございます。お時間を割いていただき感謝いたします。お手元には、このセッションで扱うファインチューニング技術とモデルの種類についての情報シートがございます。
私の名前はHarsh Asnaniです。AWSのGenerative AIのWorldwide Specialist Solutions Architectをしております。そして私と一緒にAnupamが参加しています。こんにちは、Anupamです。私はNovaチームのSenior Solutions Architectです。今回リリースしたカスタマイゼーション機能をご紹介できることを嬉しく思います。素晴らしいですね。それでは、アジェンダを簡単に説明します。モデルカスタマイゼーションとは何か、特にtool callingにおけるモデルカスタマイゼーションの主要な考慮事項は何か、どのような技術が利用可能で、私たちが何を使用したかについて、少し概念的なところに入っていきます。また、Novaに関する最近のre:Inventでの発表についても簡単に触れ、そこからコードのウォークスルーに深く入り込んでいきます。このセッションで開発したコードをお見せして、Amazon Novaモデルを使用してtool calling機能をどのように強化できるかをご紹介します。
さて、なぜモデルカスタマイゼーションなのか、ということですよね。Novaのカスタマイゼーション機能に入る前に、利用可能なカスタマイゼーション技術のスペクトラムについて見ていきましょう。 これはNovaだけでなく、一般的にfoundation modelsで利用可能なものです。まず、モデルのweightsを変更する必要があるかどうかを選択することから始まります。左から右に向かって、モデルのweightsを変更しようとすると、カスタマイゼーションのレベルと労力が増加していくのがわかります。左側はライトタッチな技術です。prompt engineeringのようなものを試すことができます。これは、特定のフォーマットでモデルに応答してほしい方法を伝えるものですが、基本的にモデルは訓練されてきた概念を保持したままです。ですので、組織のデータや慣れ親しんだスタイルに特有の新しい概念がある場合は、prompt engineeringのテキストといくつかの例でそれを提供し、基本的には既製のモデルを使ってどのように機能するかを確認することができます。
RAGも使用できます。これはRetrieval Augmented Generationの略で、これが可能にすることは、モデルのweightsを変更することなく、推論時に組織固有のデータを提供することです。つまり、モデルが訓練された後に学習していないことがあっても、それが組織のコーパスにあれば、それを拾い上げて適切に応答します。これらのアプローチでは飽和状態になることがあります。応答のスタイルが必要なものと完全に一致しないことがあるでしょう。そこで右側に移ります。これらの技術はモデルのweightsを変更します。post-trainingとpre-trainingに分かれています。一番右がpre-trainingで、pre-trainingで行うことは、基本的にユースケースとして、組織内にモデルで学習されていない概念がある場合、pre-training技術を使用できます。しかし、特定のフォーマットでの応答のスタイルのためだけにモデルを変更したい場合は、post-trainingのようなものを使用できます。これもモデルのweightsを変更しますが、それほど集中的ではなく、モデルを訓練するために多くのリソースや専門知識を必要としません。
Amazon Novaモデルファミリーの発表とNova Forgeの価値提案
それでは、カスタマイゼーション技術の進展を理解したところで、特にNovaモデルについて、AWSでこれをどのように行うことができるかに入っていきましょう。私たちには2つの提供方法があります。Amazon SageMaker fully managed training jobsとAmazon SageMaker HyperPodです。SageMaker training jobsが可能にすることは、宣言的な構文とPython SDKsを通じてトレーニングワークロードを定義することです。カスタムトレーニングスクリプトとデータを提供すれば、Dockerコンテナの起動、停止、可観測性、スケーラビリティなど、すべてを処理してくれます。しかし、Amazon EKSのバックグラウンドから来ていて、EC2インスタンスに入ってSSHで接続するなど、より多くのコントロールを好み、コントロールの最大化が必要な場合は、SageMaker HyperPodも使用できます。
それでは、Anupamにバトンタッチして、いくつかのローンチについて説明してもらいます。ありがとう、Harsh。それでは、今年のキーノートで発表されたいくつかのローンチについて見ていきます。 まず第一に、私たちが追加したさまざまなモデルについてです。昨年リリースされた第一世代のモデル、Micro、Lite、そしてProが見えますね。
皆さんがこれらを使って遊んだり、実際に使用していることを願っています。第二世代は一昨日ローンチしたもので、Nova Lite 2です。これは新しい世代のモデルで、ゼロから構築され、新しいトレーニングデータ、改善された多言語機能、よりエージェント的なユースケース、そしてより優れたコーディング能力を備えており、これらの分野で優れた性能を発揮します。公開レポートが利用可能ですので、技術レポートを読んでいただければ、他のモデルとの明確なベンチマークや比較が確認できます。
そして、2つのアーリーアクセスモデル、私たちがプライベートプレビューと呼んでいるものもリリースしました。Nova 2 Proは、Liteの兄貴分のようなもので、より大きなモデルですが、知識と知性の面でより優れています。そしてOmniは、画像とテキストのモデルで、つまり任意のモダリティを入力でき、テキストまたは画像で応答を返します。例えば、Nova ProとCanvasを組み合わせたようなものです。ベースモデルのローンチに加えて、 Nova Forgeと呼ばれるものもリリースしました。これは基本的にオープントレーニングのコンセプトで、ベースモデルやカスタマイズのためのレシピだけでなく、カスタマイズを始めるために使用できるNovaの中間チェックポイントも取得できます。
これまでは、最終チェックポイント、つまり誰もがアクセスできる本番モデルしか使用できませんでしたが、これにより、事前にトレーニングされた中間の、Continued Pre-Trainingのみでトレーニングされたチェックポイントを取得できるため、さまざまな他のチェックポイントからも開始できるようになります。チェックポイントに加えて、Nova dataも追加しました。これは、トレーニング時に自分のデータとNovaのデータを混合できることを意味します。科学的な証拠により、トレーニング時に自分のデータと、ファウンデーションモデルがトレーニング中に見たデータを混合すると、モデルの学習能力が向上することが示されています。
そうですね、これらがNova Forgeの主要な価値提案とメリットのいくつかです。最後のチェックポイントだけでなく、 複数の異なるチェックポイントにアクセスできます。独自のデータをAmazon Novaがキュレーションしたデータとブレンドできます。また、独自の環境を持ち込むことで強化学習を使用することもできます。つまり、報酬関数の計算を行う独自の環境を構築しているお客様と協力しており、彼らはその環境全体をAWSに移行したくないという場合があります。なぜなら、その環境全体に投資して作成してきたからです。そこで、これにより、VPC内でモデルをトレーニングしながら、報酬関数を計算している外部環境を接続するだけで済むようになります。
利用可能なファインチューニング技術とReinforcement Fine-Tuningの仕組み
そして、はい、プッシュボタンレシピが付属しています。つまり、複数のハイパーパラメータに対して最適な値が設定された事前構築済みのレシピが利用でき、それを使うことができます。そして最後に、Responsible AIツールキットも提供されていますので、セキュリティのユースケースやコンテンツモデレーションのユースケースがある場合は、Novaの責任あるAIレイヤーを活用して、修正またはカスタマイズすることもできます。はい、ということで、これがローンチの内容です。この表は、1.0のオファリングと2.0のオファリングについて、さまざまなテクニックの観点から高レベルの概要を示しています。
Harshが述べたように、これらはポストトレーニングです。Parameter-Efficient Fine-Tuningを見ていただくと、これはモデルのアダプターのみを変更するタイプのファインチューニングですが、それに加えて、モデルの実際の重みを変更するFull Fine-Tuningも、1.0と2.0の両方で利用可能です。DPOは別の種類のポストトレーニングで、サムズアップ、サムズダウンのフィードバックを取得して、良いものがどのようなものか、悪いものがどのようなものかをモデルに教えることで、モデルがあなたの好みや人間の好みに向かって舵を切れるようにするものです。これも1.0で利用可能で、同様にPPOも、DPOと非常に似ていますが、人間のフィードバックからの強化学習の別のクラスのテクニックです。
そして、Reinforcement Fine-Tuningがあります。これは現時点で最先端の人間のフィードバックからの強化学習で、2.0で利用可能です。これが2.0でのみ提供されている理由は、人間のフィードバックからの強化学習、つまりReinforcement Fine-Tuningは、推論モデルでより良く機能するためで、Nova Lite 2は推論モデルだからです。そういうわけで、その組み合わせになっています。それでは、ユースケースに移りまして、今日何をするのかについて簡単にご説明します。プレゼンテーションに時間をかけすぎるよりも、今からコードに移りましょう。
今日取り上げるユースケースのアーキテクチャは、Security Agreement Legal Assistant Agentです。このエージェントは、複数のドキュメントを調べる責任を持ち、質問を与えると、適切な情報にアクセスするために適切なツールを呼び出し、適切なパラメータを選択して、そこから進めていく必要があります。カバーするさまざまなモジュールでは、まず、Synthetic Data Generatorがどのように機能するか、または独自のデータを生成する方法をお教えします。
独自のデータを生成する方法をお見せします。というのも、カスタマイゼーションに関して、最初からデータを持っていないお客様が多く見られ、それがP0つまり前提条件だからです。この特定のデモで使用してきた合成データジェネレーターをちょっとお見せします。それから、ベースモデルの評価を行い、カスタマイゼーションなしのベースモデルだけで、どの程度のレベルにあるかを把握します。
それでは、Supervised Fine-Tuningに移ります。これがプロンプトとレスポンスのペアを使ったファインチューニングで最初に使うものです。そのpost-SFTチェックポイントで評価を行い、ベースモデルからどれだけ改善したかを確認します。次に、Reinforcement Fine-Tuningに移ります。これはSFTチェックポイントの上に位置するものです。つまり、反復的なファインチューニングアプローチということです。そして、post-RFT評価を行って、その結果を確認します。最後に、Bedrockへのデプロイメントを行い、推論を実行します。今日のコードトークでは、これらすべてのモジュールをカバーします。1時間しかありませんが、カバーすべきモジュールが多すぎるので、うまくいくことを願っています。
SFTが何なのか、もしご存じない方のために説明すると、すべてはadapter trainerから始まります。LoRAベースのテクニックやパラメータ効率的なアプローチを使う場合です。これが今日お見せするものです。限られたリソースでできる最も軽量なSFTです。素早く、あまりコストをかけずに、最初の試行でまともな結果が得られます。少なくとも、そのモデルがあなたのユースケースで学習できるかどうかの良いシグナルが得られます。Adapter trainingは基本的に、データベースからデータを取得します。この場合はS3になります。レシピからベースモデルを取得し、そして基本的には、提供するデータとベースモデルを使って順伝播と逆伝播を行い、trainerを取得します。それからベースモデルを取得し、adapterをベースモデルと融合させて最終的なモデルを得るfusionを行います。これが本質的にSFTが行うことです。SFTのadapterベースのトレーニングは、基本的には軽量なadapterをトレーニングして、それからfusionを行うだけです。
RFTはもう少し複雑です。トレーニングVPCとカスタマーVPCがあります。トレーニングには2つの主要なモジュールがあります。rolloutとtrainerです。カスタマーアカウントには、報酬関数であるLambda関数があります。繰り返しになりますが、プロンプトデータにアクセスできます。これはRFTテクニックを使ってモデルをトレーニングしたいデータセットです。そしてベースモデルを取得します。rolloutから両方をロードし、trainerもベースモデルをロードします。それから予測を計算するためにLambda関数を呼び出します。rolloutが行うことは、任意の数の答えを生成するシステムのようなものだと考えてください。rolloutはN個の生成、つまりN個の予測のようなもので、それらすべての予測をLambdaに渡して、評価メトリックに基づいてスコアを計算します。レスポンスを受け取ります。これは基本的に報酬です。つまり報酬を受け取り、それからそれらの報酬をtrainerにフィードバックして、trainerがそれらの答えやフィードバックから学習し、さらに改善できるようにします。それからtrainerで順伝播と逆伝播を行って学習を得て、そこでrolloutに戻って重みポリシーを更新します。このサイクルが続きます。より多くのrolloutが生成され、Lambda関数が報酬を計算してtrainerに返します。trainerが重みを更新し、新しいrolloutが生成され、このサイクルがレシピで定義したステップ数だけ続きます。これがモデルが学習を始める方法で、今日は実際の例でそれがどのように起こるかを見ていきます。
合成データ生成：Security Agreement Legal Assistant Agentのためのデータ準備
さて、それではコードサンプルに移ります。切り替えますね。では、早速コードに飛び込みましょう。これはコードトークです。ユースケースを実演するために開発したコードがたくさんあります。1時間ですべてを終わらせる予定ですが、密度が濃くなる可能性があります。重要なコードブロックをお見せして、ユーティリティヘルパー関数の一部は隠すか、さっと見る程度にする予定です。各ノートブックの最後に質問を受け付けます。おそらく2、3個です。簡単に時間をチェックして、もっと質問があれば、廊下で受けることもできます。これはデモではなく、このセッションを教育的でインタラクティブなものにしたいので、ノートブックの最後に質問があればお知らせください。
最初はデータ準備のステップです。ここで興味深いのは、既存のデータセットを使う代わりに、サンプルユースケースのために基盤モデルをファインチューニングするためのデータを生成したことです。基本的には無から引き出しているだけです。アイデアは、インターネット上のどこかにあるサイロから、構造化されたデータ、非構造化されたデータ、またはその組み合わせのデータを生成し、ハイパーパーソナライズされたエージェンティックアプリケーションを作成できるなら、組織のサイロに存在するデータでも同じことができるということです。
それでは、ここで扱っているユースケースに戻りましょう。私たちが使用するデータソースは3つあります。エンドユーザーが弁護士、パラリーガル、あるいは私募株式売却や公募などの証券取引がSEC規制に準拠しているかを確認しようとしている人物だと想像してください。
Novaモデルは様々なユースケースで使用できることを指摘しておきたいのですが、特に法律や医療のユースケースについては、ご自身の判断で使用してください。また、その他の規制対象や機密性の高いユースケースについても同様です。さて、ここには3つのデータソースがあります。まず、SECに提出された実際の契約書であるEDGARファイリングがあります。つまり、弁護士がフォームに記入して、SECのレビューのために提出したものですね。次に、それらの契約書に含まれるべき法的文言を示すSECの正式な言語規制があります。そして最後に、提出された契約書に対する連邦判事や裁判所による司法解釈があります。
つまり、モデルはこれらの相互接続されたデータセットを使用して、文書間の分析を可能にし、契約書を検証することができます。必要とされるテキスト、提供されたテキスト、そしてそのテキストがどのように解釈されたかに対して検証するわけです。これらの機能のいくつかを簡単に見ていきます。これらはまもなくGitHubリポジトリで公開する予定ですので、ここでカバーした内容やそれ以上のものにアクセスできるようになります。しかし、これらは基本的にオープンソースのウェブサイトからデータをクローリングしているだけです。これらは簡単に修正できます。例えば、ダウンロードしたいフォームの種類に合わせて変更できます。
次に、実際の合成データジェネレーターが登場します。生データが手元に揃ったら、Novaが消費できる形式でデータを生成し始めることができます。私たちが使用するNovaモデルですね。形式は使用するモデルによって異なります。Novaの使用を推奨しますが、BedrockやSageMakerで利用可能な他のモデルでも試すことができます。重要なのは、データを生成する際に提供すべきプロンプトエンジニアリングです。これにより、モデルはどの形式で生成すればよいかを理解します。
簡単なアニメーションで、それがどのように行われているかをお見せします。30秒ほど再生させますね。ご覧のように、左側にデータ生成キットがあります。そして、ここで起こっていることは、基本的にデータをチャンキングしているということです。実は静止画に移ることもできますね。データを事前定義された文字数制限にチャンキングしています。これが行われる理由は、一般的に、サイロ内のデータはギガバイトやテラバイト単位で存在しており、これによってモデルのコンテキストサイズが膨れ上がり、データを生成できなくなってしまうからです。そこで、データをチャンクに分割します。チャンクサイズは、選択したモデルのコンテキストウィンドウに依存します。繰り返しになりますが、Mがそのパラメータです。
もう一つのパラメータはNです。Nが行うのは、これらのチャンク間で重複する文字数を定義することで、モデルが意味的な連続性があるかどうか、つまり、文章が途中で切れているかどうかを認識できるようにします。モデルはプロンプトの中で、データのチャンクを受け取ることになる、これがコンテキストである、意味的な類似性を維持するように努めてください、と指示されます。各チャンクは実際にプロンプトに供給され、それがteacherモデルへの単一の呼び出しとなります。私たちのユースケースでは、Nova Premierを使用しています。つまり、100個のチャンクがあれば、100回の呼び出しが行われ、最終的に合成データが生成されます。
Nova形式のデータ生成とツール選択のためのプロンプトエンジニアリング
これをstudentモデル、つまりNova Liteが消費できる形式にして、ファインチューニングを行います。これについては後のノートブックで見ていきますが、エンドユーザーが利用できるようにします。Novaの形式がどのように見えるかを簡単に見てみましょう。すべてのNovaファミリー、特にSFTについてです。システムプロンプトがあり、そこでモデルやエージェントアプリケーションに何をしてほしいかを定義します。ここでは例えば、あなたは親切な法律アシスタントです、私の契約書が要点を押さえているか確認するのを手伝ってください、といったことを言います。生成後にそれがどのようになるかの例を見ることができます。
Reinforcement Fine Tuningの場合は少し異なりますが、コンセプトは同じです。システムプロンプトがあり、実際にクエリを供給するユーザープロンプトがあり、そしてモデルによって生成される回答があります。これらはすべてJSONオブジェクトなので、その形式で生成するようにモデルに明示的に指示しますが、皆さんご存知の通り、私たちのfoundation modelsはある程度非決定的です。そのため、これらが基盤となるモデルで消費できることを保証するための検証ループを提供しています。
最終的に、私たちの目標はこのモデルが入力クエリに対して適切なツールを選択することです。そこで、選択したツールに関するいくつかのメトリクスを測定することで、何が良いかを測定します。つまり、クエリが与えられたとき、正しいツールを選択したか？複数のツールが必要な場合、正しい順序で選択したか？ツールは本質的にPython関数なので、パラメータを取ります。クエリを実行するために必要な正しいパラメータをツールに提供したか？これらが私たちが追跡しているメトリクスの一部です。これらはカスタマイズ可能です。独自のメトリクスを提供することもできます。これについてはすぐにコードで見ていきます。
しかし今は、合成データジェネレーターに提供するプロンプトを見てみましょう。ここにいくつかのアノテーションが表示されます。ダブルハッシュ、ガイドライン、そして大文字が見えます。各foundation modelにはプロンプティングのベストプラクティスがあります。Amazon Novaの場合、このように見えます。そして、それをここに組み込んでいます。これらのアノテーションを通じて、プロンプトの中でモデルが何をする必要があるかを伝えます。どのツールにアクセスできるか、そして各ツールがパラメータとして何を必要とするかを伝えます。
また、各クエリを8つの事前に定義されたカテゴリに分類するようモデルに指示します。これらは最終的に使用するツールにマッピングされます。これがどのように機能するかを示す簡単な表がありますので、それを見ていきましょう。基本的に、規制の定義であれば、このツールを使用すべきです。規制コンプライアンス分析であれば、2つのツールをこの順序で使用すべきです。
そして最後に、この構造に準拠した厳密なJSONスキーマが必要であることを伝えます。また、いくつかの定義例を提供し、基本的にはデータがどのように見えるべきかのfew-shotプロンプティングを行っています。そして最後に、Synthetic Data Toolkitによって生成されたチャンクを挿入します。このセッションで使用したツールキットは、Metaによるオープンソースのツールキットです。Synthetic Data Toolkitと呼ばれています。繰り返しになりますが、これにはどんなオープンソースフレームワークでも使用できますが、基本的にこのコードで行ったことは、BedrockとSageMakerモデルをツールキットで使用してこのデータを生成する機能を提供したということです。
そこから、ツールキットを起動し、システムチェックを試みます。BedrockでホストされているAmazon Novaモデルを使用します。単に「hi」と言うだけの入力プロンプトを提供し、モデルが呼び出しリクエストを受け取る準備ができていることが確認できます。その後、基本的にデータをファイル解析してから、プロンプトの生成を開始します。
それが完了したら、それがどのように見えるか、ちょっと覗いてみましょう。これをJSONL、JSON Linesファイルに結合します。なぜなら、それがAmazon NovaがSupervised Fine-Tuningのために提供することを期待している形式だからです。また、3つのセットに分割します。例えば、Amazon Novaはこのクエリと適切な回答がどのようなものであるべきかを生成しました。そこで、これをさらにstudentモデルに供給し、実際のユーザークエリでこれを行う方法を学習させます。
実際のファインチューニングを行う方法を確認するためにSupervised Fine-Tuningノートブックに進む前に、ここで一旦停止して、質問を受け付けたいと思います。すみません、GitHubは公開されていますか、それとも非公開ですか？それがご質問ですか？まだ公開されていませんが、今日中には公開される予定です。はい、Nova SamplesのGitHubで利用可能になります。他に質問はありますか？
Mike、Nova Sonicにも同様のプロセスを適用できますか、それとも今後の話でしょうか？Nova Sonicのカスタマイズのことですか？いいえ、それは現時点では利用できません。将来的には、ユースケースがあれば、どのようなカスタマイズをお考えなのか話し合うことができます。わかりました。他に質問がなければ、Supervised Fine-Tuningに移りましょうか。
Supervised Fine-Tuning（SFT）の実装：LoRAを使ったパラメータ効率的なトレーニング
完璧です。それでは、AnupamがSupervised Fine-Tuningについてお話ししたように、LoRAとSFTの魔法は、adapter trainerを使用する際に、これはパラメータ効率的なファインチューニング技術なのですが、基本的にモデルの重みの1～2%を取り出して、モデル全体ではなくそれらだけをファインチューニングしようとするため、インフラ、トレーニング時間、コスト、すべてが削減されます。私たちが確認したところでは、適切なデータを与えれば、完全なsupervised fine-tuningと比較して最大90%の精度パフォーマンスが得られます。つまり、基本的にadapterとは、LoRAが抽出する重みの1～2%であり、それをトレーニングし、ベースモデルに追加して、最終的にファインチューニングされたNova Liteモデルを提供します。
その辺りはかなりカバーしたので、モデルのファインチューニングコードに入りましょう。最初に行うのは、SageMakerセッションをセットアップすることです。これにより、SageMakerクライアントとやり取りし、ローカルノートブックからジョブを送信し、必要なデータセットを提供できるようになります。必要となる特定のインスタンスを選択します。ここでは分散トレーニングも行うので、4つのインスタンスを選択して、トレーニングを高速化します。image URIを選択しますが、これはECRでホストされているDockerイメージです。これらは使用するモデルに固有のものです。つまり、Nova 2.0を使用する場合は、特定のimage URIを持つことになります。
そこから、recipesを使用します。recipesは、Anupamが先ほどお知らせしたように、設定可能なパラメータの抽象化に過ぎません。それがどのようなものかというと、例えば、トレーニングハイパーパラメータ、実行したいステップ数、学習率スケジューラー、使用したい学習率adapterの種類、LoRAを使用するかどうか、そして、LoRA固有のファインチューニングハイパーパラメータなども定義したいとします。それが完了したら、SageMakerの用語でestimatorと呼ばれるものを選択します。PyTorch estimatorを使用します。なぜなら、NovaはPyTorch Lightningフレームワークを使用してこれをトレーニングするからです。先ほど定義した変数を再度提供し、recipeを渡し、最後にimage URIを渡します。
前のノートブックで生成したデータを使ってトレーニングを開始します。これは完了したノートブックです。コンソールでどのように見えるかをお見せするためのものです。ここから、インフラの使用率に関するいくつかのメトリクスを確認したり、ログを見たりできます。トレーニングを行った各インスタンスごとに1つのログストリームが表示されます。それぞれがステータスコード200で終了しており、これはトレーニングが成功したことを意味します。
さて、トレーニングには20分から40分ほどかかります。典型的なMLワークフローでは、トレーニングが完了した後、トレーニングと検証のカーブを確認したいですよね。そこで、ファインチューニングされたデータのモデルtarballをダウンロードして展開します。その中にはマニフェストファイルとトレーニングロスファイルが含まれていて、モデルがどのように収束したかを教えてくれます。ステップから見てわかるように、100ステップを指定しましたが、ステップ0から100にかけて、70から10まで収束しています。これはトレーニングセットのみでかなり良いパフォーマンスですね。
ここで覚えておいていただきたいのは、この評価メトリックは実際には、モデルをテストしたい評価メトリックとは異なるということです。
私たちがモデルをテストしたいのは、特定の例に対してです。なぜなら、実際にどのツールを選択したのか、どの順序で選択したのか、そしてそれがJSONとしてパース可能だったかどうか、といったことを確認したいからです。つまり、トレーニングカーブは、トレーニングデータにあった同じ出力とマッチしたかどうかを示しているだけなんです。これは基本的にアシスタントが応答する内容です。テキスト対テキストのマッチングですね。マッチした場合、トレーニングロスが収束します。
そこから、ツール選択の精度をいくつかのメトリックで測定しています。いくつかは従来の古典的な精度メトリックです。ツールに対するprecision、recall、F1が見えますね。これはツール選択が適切に行われた回数、偽陽性が何回あったか、そしてAUROCカーブがどのように見えるか、F1がどのように見えるかを示しています。また、ツールに提供されたパラメータ、選択されたツール、そしてそれらが選択された順序に基づいて重み付けされた総合スコアもあります。これらはカスタマイズ可能です。トレーニングループで行われる評価と評価ループで行うこととの違いの一つは、ベースモデルに送信されたテストスプリットがあり、それがファインチューニングされたモデルにも送信されるということです。これらのメトリックを評価する方法は、Lambdaにロードされた事前定義された関数を使用します。ベースモデルの各呼び出しで、左側に見えるように、答えがLambda関数に送られます。Lambdaはカスタマイズ可能な関数でそれを評価し、それらのメトリックをベースモデルに送り返します。ファインチューニングされたモデルに対しても同じことを行い、最後に両方を比較するだけです。
ベースモデルの評価とファインチューニングされたモデルの評価は、トレーニングジョブと非常に似ています。インスタンスタイプ、カウント、イメージURIを選択します。これはトレーニングループとは異なります。再びレシピを設定して、先ほど設定したLambdaのLambda ARNを指定します。以前と同じようにestimatorを定義します。テストスプリットを提供して、評価ジョブを開始します。約20分かかります。そこから、再びtarballをダウンロードして、結果を視覚的に確認したいと思います。これらはベースモデル自体のメトリックです。ファインチューニングされていません。ファインチューニングされたモデルについても同様のメトリックがあり、大幅に上昇しています。そして比較します。総合スコアがSupervised Fine-Tuningループで44%から75%に跳ね上がったことがわかります。
Reinforcement Fine-Tuning（RFT）による精度向上：報酬関数の設計と反復学習
ここでSFTサイクルを終了します。このSFTファインチューニングされたモデルを取り、さらにReinforcement Fine-Tuningを行うことで精度を向上させようとします。カスタマイズされたadapterができたので、次はRFTに移りましょう。これがクールな部分です。RFTでは、説明したように、基本的にrolloutを行います。これは複数のレスポンスを生成し、そしてtrainerが、Lambdaであるreward functionから来るフィードバックを受け取り、そのreward functionからのフィードバックを使って重みを更新し、自身を改善し、そのサイクルを複数回実行します。繰り返しますが、複数回というのはstepsで定義でき、これはrecipeパラメータです。必要なrolloutの数もrecipeパラメータで定義できます。つまり、これらは設定可能なハイパーパラメータです。
まず、基本的なところから：IAM roleのセットアップ、importの実行、前のnotebookから2つの主要なものを取得します。それはSFT後のcheckpointです。なぜならそれがその上でRFTを実行するために必要だからです。そして、data frameにキャプチャされた結果が表示されます。data prepについては、これがRFTのフォーマットです：system、user、そしてreference answerです。Reference answerは基本的に何でも構いません。モデルに学習させたい、気にかけている任意のランダムなものを渡すことができます。
reference answerはground truthだけである必要はありません。thinking notesでも、持っているものなら何でも構いません。なぜならReinforcement Fine-Tuningの本質は、渡したものから学習するだけだからです。Supervised Fine-Tuningがやるような、ground truthだけを記憶するわけではありません。そして、そのフォーマットでdatasetsを作成し、S3に保存し、それからLambda functionを作成します。これがreward functionです。これが良いRFTを得るための重要な部分、良いreward functionを得ることです。もしreward functionがbiasedだったり、簡単にhackできるものだったりすると、RFTはreward functionをhackしようとします。hackというのは、つまりrewardを最大化するためにreward functionの抜け穴を見つけようとするということで、そうするとモデルはあまりうまく学習しません。ですからreward functionをどのように作成したかを見ることが重要です。
まず、Lambda handlerとLambda graderがあります。Lambda graderでは、このような入力を受け取ります。この場合、user prompt、予測の1つから来たassistant response、そしてreference answerを渡しています。これは一種のground truthです。どのタイプの情報が必要か、どのtoolを呼び出すべきか、そのtoolにどのパラメータを使うべきか、そしてそのtoolを選んだ理由を渡します。そして、aggregated reward scoreを返します。これは、RFTは数値的なreward functionで動作するので、最終的には最適化しようとする数値を返さなければなりません。
aggregate reward functionは現在、Hershが言及したように、私たちが気にかけているすべてのmetricsの加重平均です。正しいtoolが呼び出されているか、正しいパラメータが使われているか、toolのsequenceが正しいか、JSON schemaがparsableかなどです。そして、この加重平均を通じてそれを集約します。はい、これらがmetricsです。何かエラーが起きたりした場合はデフォルト値はゼロですが、正しければより高い値になります。そして、すべてのmetricsをここでキャプチャし、最後にaggregate scoreもキャプチャして、結果を返します。これがreward functionがやっていることのほぼすべてです。重要なのは、reward functionに勾配を持たせるべきだということです。プラスマイナスやtrue falseのようなbinaryであってはいけません。これは良い、これは平均的、これは良いに近い、というような勾配を持つべきで、その情報を使って良いに近いものを最良の答えにより近づけるように最適化します。
そして次に、Lambdaを作成し、それをプッシュして、AWSにLambdaをデプロイし、その後RFTをキックオフします。これがすべての核心部分です。ここでは、トレーニングされたチェックポイントを渡しています。レシピを渡しています。公開されているイメージURIを渡しています。P5.48xlargeを使用しており、RFTを実行するために必要な最小インスタンス数は4つです。ベースモデルとしてNova Lite 2を使用します。そしてRFTジョブをキックオフします。繰り返しになりますが、PyTorchのestimatorコールで、SFTと非常に似ています。トレーニングを定義し、トレーニングデータ、検証データを定義し、dot fitコマンドを開始します。これが基本的にトレーニングをキックオフするものです。そしてログを見ることができます。ノートブックでログを出力することもできますし、コンソールに行くこともできますが、ログを見ることができ、トレーニングしているステップや、キャプチャしているさまざまなメトリクスを確認し始めることができます。
そしてこれはコンソールがどのように見えるかのスクリーンショットです。トレーニングが開始され、イメージがダウンロードされ、その後トレーニングが始まるのが見えます。次に、トレーニング結果をキャプチャします。なぜなら、RFT後にメトリクスがどのように見えるかを確認する必要があるからです。ここでは、結果を取得します。これはステップごとのトレーニングメトリクスで、トレーニングがどのように進んでいるかを確認します。そしてこれは以前に私が実行したもののスクリーンショットです。55ステップの代わりに、どこまで伸ばせるか見るために150ステップを実行しました。そして、train reward function、train reward metricを見ました。これがRFTで見るべき重要なメトリクスです。つまり、報酬がどのように改善しているか。低い値から徐々に増加し、1に近い高い値まで上がっていくのを見たいのです。これは、サイクルが進むにつれてモデルが学習しており、報酬が改善していることを示しています。
ここでは、0.81または0.82から0.8586への適度な上昇が徐々に見られます。場合によっては0.9に達することさえあります。そしてこれは評価メトリクスと密接に相関しています。つまり、SFTで見ていた74、75あたりだったものが、RFT後には88、89あたりに達しています。これにより、報酬関数が増加しているという確信が得られ、エントロピーも
減少していることがわかります。つまり、より決定論的になっているということです。次に評価ですが、再び2つの評価を行います。1つはベースモデルのRFTに対して、そして2つ目はpost-SFT post-RFT evalです。繰り返しになりますが、RFT evalのレシピはこのようになります。推論パラメータを定義できます。クールなことの1つは、log probabilitiesもサポートしていることです。つまり、予測されているトークンの確率を実際に取得でき、それを使って答えをキャリブレートしたり、分類器がある場合は、それを使って精度と再現率の境界をキャリブレートすることができます。
そして、RL環境では、ここで評価にも使用されるLambda関数を渡しています。これは報酬関数と同じものです。基本的にPyTorchジョブをキックオフします。これらのパラメータを上書きします。なぜなら、現時点では報酬関数は単なるランダムな文字列なので、Lambda関数の実際のもので上書きし、取得した最終チェックポイントを渡しています。これはpost-SFT evalで、先ほどお見せしたものと似ています。そしてこれがpost-RFT evalです。
次に、私たちが行うのは、再びpost-evalの結果を展開することです。これは辞書形式で提供され、JSONファイルになっています。そこから、報酬関数で計算していたカスタムメトリクスを取得し、辞書を作成します。これにより、前回の呼び出しから読み込んだデータフレームを使用して、matplotlibで比較できるようにします。これが表示される様子です。ベースモデルはこのタスクで0.44でした。ファインチューンで74になり、RFTで約90になりました。この進展は、RFTがSFTよりも後のサイクルで導入された場合に改善していることを示しています。
また、これを入れ替えてみました。つまり、SFTを先に行うのではなく、ベースモデルに対してRFTのみを行ってみたのですが、良い結果は得られませんでした。これは、SFTが実際にRFTに役立っていることを示しています。なぜなら、SFTは基本を正しく理解し、フォーマットを正しく、JSONスキーマを正しく、といったことを行い、その後RFTが予測されるパラメータの品質を向上させているからです。これは異なるvalidに関するさらなる結果です。つまり、異なるメトリクスです。これは全体的なスコアのみで、これが私たちが気にしているものですが、これらはサブメトリクスであり、最も失敗している箇所を確認できます。または、引き続き失敗分析を行い、RFTデータを改善して、必要に応じてさらなる改善を確認することができます。
Bedrockへのデプロイメントと推論：カスタマイズされたモデルの実運用
しかし、これはどのように行うべきかについて良い指標を与えてくれます。つまり、ベースモデルのeval、SFT、そしてpost-SFT RFTから始めるということです。しかし、良い点は、これらの反復ループを継続できることです。つまり、前のチェックポイントの上に構築し続け、そのチェックポイントを保存し、評価し、その上に構築することができます。最後にお見せしたいノートブックはデプロイメントです。最終的なチェックポイントができたので、最終的なチェックポイントはS3 URIとして提供されます。つまり、モデル自体は取得できず、S3 URIのみを取得します。ここで例を見つけられれば、お見せします。
これが読み込まれるチェックポイントのS3バケットですが、見つけられるか見てみましょう。ええ、例えば、これがチェックポイントがどのように見えるかの例です。これはアクセスできないバケットです。サービス側のバケットですが、そのチェックポイントは使用するIAMポリシーを通じてアクセスできます。このチェックポイントが、今私たちのタスクは、RFT後のこの最終的なS3チェックポイントを取得し、何らかの方法でBedrockに移動して、推論呼び出しを行えるようにすることです。そして、それは2つのBedrock関数を通じて行われます。
基本的に、最初に行うことは、S3チェックポイントからBedrockにモデルをエクスポートすることです。そのために、create custom model APIを使用して、モデルをBedrockに移動します。そのステータスを監視します。それがアクティブになったら、モデルがBedrockにデプロイされたことを意味します。そして、2回目の呼び出しを行います。これはcreate custom model deploymentを使用します。これでオンデマンド推論を使用し、基本的にBedrockでヒットを開始するためのカスタムモデルの推論エンドポイントを作成します。そして、これは再び全体を通してLoRAを使用したためです。つまり、パラメータ効率的にSFTを行い、パラメータ効率的にRFTも行いました。すべてがアダプターのみで行われたため、オンデマンド推論を使用できます。そのため、同じハードウェアを再利用できます。そして最後に
Bedrockでモデルを確認できます。これは現在ホストされており、AWSアカウントを通じて公開アクセス可能にすることができます。
では、推論呼び出しを行う際にコードをどのように変更するのでしょうか？基本的には1行の変更です。これは皆さんもご存知かもしれませんが、Converse APIです。ここでは、モデルIDをベースモデルとして渡しています。これはNova Lite 2で、説明のようなランダムな結果が得られますが、これは私にとっては役に立ちません。なぜなら、構造化された出力を求めていたからです。
それから同じ呼び出しを行いましたが、今回はデプロイされたモデルIDを渡しました。これは前の呼び出しから取得したオンデマンド推論のARNです。ここでは、statute retrievalやcompliance checkerのような適切なツールが呼び出された、より構造化された回答が得られます。これは、モデルが学習し、ベースモデルから精度を向上させていることを示しています。
以上です。データ準備からSFT、RFT、そしてデプロイメントまで、エンドツーエンドでカバーしたかった内容は以上になります。もし質問がある方がいらっしゃれば、お受けします。また、時間がありますので、皆さんのユースケースについてもぜひお話ししたいと思います。もしご希望があれば、それらについて議論しましょう。素晴らしい。いいですね。
これ以上質問がなければ、スキャンして無料評価、CAと呼ばれるものですが、それを付けていただけます。ご参加いただきありがとうございました。この辺りにいますので、もし質問があれば、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion