re:Invent 2025: Met OfficeがAmazon Novaで実現した気象予報自動生成システムの構築事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Architecting AI solutions for mission-critical systems w/ UK MetOffice (ARC406)
この動画では、Met OfficeとAWSが協力し、100年の歴史を持つShipping Forecastの生成にAmazon Nova Foundation modelを活用した事例が紹介されています。Ed SteeleとDinesh Maneが、気象モデルから出力される45GB以上の複雑なデータを厳格なフォーマットのテキストに変換する技術的課題に取り組みました。わずか4週間のプロトタイピングで、専門気象予報士が数時間かけて作成する予報を5分未満で52%から62%の精度で生成することに成功しています。LLMとVLMの両アプローチを比較し、LoRAとフルファインチューニングの実験を通じて、単語ベースのF1スコアによる厳格な評価手法を確立しました。SageMaker、Bedrock、ECSを組み合わせたスケーラブルなアーキテクチャ設計により、新しいモデルへの切り替えもコード1行で可能な柔軟性を実現しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
世界最古の海上予報「Shipping Forecast」の歴史と文化的意義
ありがとうございます。それでは、7月4日金曜日の5時5分に、海上保安庁を代表してMet Officeが発表した海上予報をお伝えします。Fitzroy、Shannon、Rockwall、Malin、Hebridesで強風警報が出ています。真夜中の総観概況です。大西洋低気圧997、かなり速く東に移動中、今夜の真夜中までにPharaos、998に達する見込みです。低気圧、Iberia、1016、ゆっくり移動でほとんど変化なし。今後24時間の海域予報です。Viking、南または南西、4から6、後に低気圧性3から5に変わる見込み。雨または時々雨、良好、時々不良。North Utsira、South Utsira、南または南西、4から6。雨または時々雨、良好、時々不良。Forties、Cromarty、Forth、Tyne、Dogger。西、4から6、南西に転じて5から7。時々雨、良好、時々並。Fisher、German Bight、西または南西、4から6。時々雨、後に雨、良好、後に時々並。
皆さんこんにちは、おはようございます。このセッションにご参加いただきありがとうございます。私の名前はEd Steeleです。Met Office、つまりイギリスの国立気象サービスでData ScienceのIT Fellowを務めています。そして今お聞きいただいたのは、世界最古で最も長く続いている予報であるshipping forecastです。今回のケースでは、今年初めに放送開始100周年を迎えた記念のものです。 これは地域の海上安全の要であり、イギリスの文化的な制度でもあります。Met OfficeがMaritime and Coastguard Agency、つまりMCAを代表して発表しており、1日4回、NAVTEXとBBC Radio 4を通じて船員に放送されています。今抜粋をお聞きいただいた予報は、31の異なる海域の予測される状況で構成されており、これは人間の気象学者が分析し、非常に厳格で特定のルールに従って、非常に特定の長さとフォーマットのテキスト文に凝縮しなければなりません。
さて、shipping forecast自体は、実は気象情報の伝達における先駆者なんです。そのルーツは1859年10月まで遡ることができます。蒸気クリッパー船のRoyal Charterが、イギリス西海岸沖の激しい嵐で沈没しました。この船だけで450人以上の命が失われ、嵐自体はさらに少なくとも800人の命を奪い、133隻の船が失われ、さらに90隻が大きな損傷を受けました。Met Officeの創設者であるAdmiral Robert Fitzroyは、この直接の結果として、1861年2月にイギリス初の海運向け暴風警報サービスを導入しました。そして、船舶から受信した無線報告による気象サービスからの貴重な支援に感謝して、Weather Shippingと呼ばれる気象速報が開始され、これが今日私たちが知るshipping forecastとなったのです。
Met Officeの組織的価値とAI活用への挑戦
さて、現在に早送りしますと、Met Officeは科学技術の限界を押し広げ続けており、急激に変化する世界において最も信頼される気象と気候のインテリジェンスを提供することで、人々がより良い意思決定を行い、安全を保ち、繁栄できるよう支援しています。私たちは、世界でも数少ない、もしかしたら唯一の、非常に多様な境界を越える組織です。すべての時間スケールにわたって気象と気候をカバーし、科学とサービスの間を橋渡しし、政府と産業の両方に、民間と軍事の両方に、国内と国際的に、そして気象学を予測し、今ではこれを災害にまで拡張しています。そしてこれらすべてが一つの場所で行われています。しかし実際にこれらをまとめると、昨年発表された独立分析による最近のレポートでは、Met Officeが今後10年間でイギリス経済と社会に560億ポンドの利益をもたらす態勢にあることが示されました。これは、イギリスの納税者からの公的資金に対する投資収益率が19対1であることを意味します。つまり、非常に重要な組織でありサービスなのです。
しかし、100年前の予報が AIと何の関係があるのでしょうか？さて、この講演では、DineshさんとI私が気象予報の入門をお話しします。気象予報における ラストマイルについてお話ししてから、実際にこれらの重要なサービスを提供できるようにするために、どのようにこれらのソリューションをアーキテクトするかについてお話しします。
私たちはAmazon Nova Foundationモデルのファインチューニングに関するいくつかのユニークな実験を実施してきました。これから初期結果をいくつかご紹介し、これらの評価について少しお話しします。これにより、他の関心のあるグループにも採用していただけるようになります。
気象予報の仕組みと機械学習による革命
では、Met Officeはどのように天気予報を行っているのでしょうか？まず、現在の天気がどうなっているかを理解することから始まります。世界中から観測データを取り込んでいます。実際、私たちは毎日約2150億もの観測データを取り込んでおり、これらが数値モデルの初期条件となります。このモデルを実行して、気象条件がどのように変化していくかを予測します。これはスーパーコンピューター上で行われ、運動方程式を使用してこれらの条件の変化を計算し、数学的方程式を用いて気象条件の予測を行います。
このデータは一部のユーザーには直接提供されますが、運用気象学者にも渡され、彼らがこれらの複雑なフィールドを解釈することでさらなる価値を付加し、この情報を一般向けの付加価値サービスに落とし込みます。そして最終的に、正確な気象および気候情報がより広く共有され、私たちが協力しているすべての異なるステークホルダー、防衛から航空、海洋、その他に至るまで、すべての方々に利益をもたらします。
さて、一歩下がって考えてみると、天気予報は実に驚くべき成果なのです。長年にわたって、私たちは天気を予測する能力において、いわゆる静かな革命を遂げてきました。物理ベースの数値モデルは、10年ごとに約半日から1日の精度向上を見せてきました。例えば、2013年の5日先の予報は、2003年の4日先のリードタイムの予報と同じくらい正確だったのです。
これらの改善は、観測データとそのデータ同化のアップグレード、数学における力学と物理プロセスの表現、そしてこの期間を通じて継続的に行われてきたモデル解像度の向上によって推進されてきました。そして、これらの物理ベースのモデルは、私たちの予報アプローチにおいて依然として不可欠な要素であり続けています。しかし、もちろん機械学習と、それに伴って私たちが経験してきたAI革命について触れないわけにはいきません。
さて、Met Officeは常にビッグデータ組織であり、AIや機械学習の活動も長年にわたって継続的に行われてきました。ただし、これらは必ずしもその特定のラベルで認識されてきたわけではありません。しかし、紛れもなく、特にディープラーニング技術の進歩は、産業全体のルールを本当に書き換えつつあり、天気予報の方法も含まれています。そして、私たちをこの地点に導いたのは、前例のない量のデータ、その一部は観測から、一部は数値予測から得られるもの、AWSのようなサービスを含む強力な計算能力の利用可能性の向上、そして私たちの専門科学者にこれらの洞察や情報を本当に活用できるデータサイエンスツールを提供することです。
データ駆動型気象モデルの台頭と「ラストマイル」の重要性
そして、機械学習気象モデルの台頭は比較的顕著なものでした。ここでお見せしているのは、データ駆動型モデルの特定の指標のパフォーマンスをY軸に、それが発表されたリードタイムの関数として示したグラフです。そして、私たちが注目している重要な閾値は、この青い線で、これは物理ベースの最先端モデルの基準レベルです。そして、2017年9月以降、完全にデータ駆動型のプロセス、つまり運動方程式を直接解くのではなく、実質的にパターン認識を含むプロセスを使用して、パラメータのサブセットについて気象条件を予測する能力が着実に向上していることがわかります。
この頃、Met Officeでは、データサイエンスフレームワークの策定を開始していました。つまり、これらの開発のいくつかに注目していましたが、同時に、物理ベースのアプローチを補完するために、このディープラーニング空間で独自の能力をどのように開発するか、またパートナーとどのように協力し、これをサポートするために人材をどのように進化させるかについても計画していました。
しかし、2022年12月に世界は変わりました。そして、私の上司はこれを「失われたクリスマス」とよく呼んでいます。なぜなら、気象予測におけるデータ駆動型アプローチに関する本当にエキサイティングな能力についての一連の論文が、文字通り12月20日頃からクリスマス期間の間に発表されたからです。そして、ここで重要なのは、これらのパラメータのいくつかについて、初めてこれらのデータ駆動型アプローチのパフォーマンスが私たちの物理ベースのモデルを上回り始めていることです。
ここでいくつかの参考文献を見てみると、これらのエキサイティングな開発は、主にDeepMind、Nvidia、Huaweiなどからの進歩によって推進されていたことがわかります。つまり、典型的なプレーヤーではありませんが、これらのデータサイエンス能力を活用できたのです。しかし、予報は実際には、ユーザーがそこから何らかの意思決定上の利益を得られる場合にのみ価値があります。そして、天気がどうなるかを異なる方法で予測するための基盤となる機会において、このような本当にエキサイティングな発展があった一方で、実際には天気が何をするかについては、著しく注目が少なかったのです。
そして、配送における最後の1マイルと同様に、天気予報におけるこの最後の1マイルは、実際には価値を付加し、ユーザーに利益をもたらす機会という点で、さらに重要である可能性があります。なぜなら、これによってさらにパーソナライズされたサービスを提供できるようになるからです。データ配信のためのさらにマルチモーダルなアプローチを提供できるようになり、データと付随する説明文を提供しながら、現在これらのプロセスが人間の解釈に依存している負担の一部を軽減することができます。ですので、私たちはこれらの取り組みに非常に興奮しており、これを説明するために、単一の製品例を使って、この場合は冒頭でお聞きいただいたShipping Forecastを例として使用します。
複雑な気象データをテキストに変換する技術的課題とAmazon Novaの活用
私たちは、気象モデルから出力される複雑なデータを取得し、これを大規模にテキストに変換する必要があります。そして、これは必ずしも簡単な問題ではありません。なぜなら、私たちが扱っているのは非常に大きなデータ配列であり、空間と時間の両方を含む複数の次元にまたがっているだけでなく、複数のパラメータにもまたがっているからです。例えば、ここで示した気圧だけでなく、海況、視界、天候、風速、風向などについても聞きましたが、これらすべてをShipping Forecastの非常に特定的で厳格な文言とフォーマットの中で表現しなければなりません。これが、ここでより詳しく探求していくユースケースでした。
さて、これに関連する技術的課題の観点からこれを表現すると、これは実際には、これらの技術を使用して変革しようとしている製品やサービスのタイプの例示デモンストレーターに過ぎません。Shipping Forecastが選ばれた理由は、その象徴的な地位もありますが、実際には様々な異なる側面と様々な異なるデータ特性をテストできるからです。予報自体とその基盤となるデータは、大気と海洋の両方のモデル出力で構成されています。例えば、風速だけでなく波高なども含まれます。
このデータのフォーマットは、どのモデルのどの変数が考慮されたかによって、確率的なものと決定論的なものの両方があります。そして多次元であり、空間領域、つまり緯度、経度、そして時間を考慮しています。そして、これについて特に興味深いのは、実際に関与するデータ量です。私たちの数値気象予測モデルの1つからの単一の予報実行からの出力だけを考えると、通常、大気モデルからの個別の予報ごとに45ギガバイト以上のデータを生成し、海洋モデルからの個別の予報ごとに約5ギガバイトのデータを生成しています。
そして、Shipping Forecastを考慮すると、いくつかの効率化を図ることができ、必要な特定の変数と考慮している特定の領域、つまり北西ヨーロッパ大陸棚地域にこれを切り取ることができます。その結果、大気データについては約152メガバイト、海洋データについては約7メガバイトになります。しかし、それでも
かなり大規模なものです。特に、基盤モデルのファインチューニングを検討する際には、3ヶ月間で約85ギガバイトのデータになります。データサイエンスの観点から見た追加の課題は、ここで使用しているフォーマットの一部がNetwork Common Data Formに基づいているということです。これは主に大気と海洋の規約です。これを読み込むための非常に優れたライブラリがありますが、気象コミュニティ以外の多くの人々が必ずしも遭遇したことのある典型的なフォーマットではありません。しかし、これは非常に便利な形式です。なぜなら、メモリ内ではpandasやX-array型のフォーマットと実質的に同じだからです。
そこで私たちが探求していた解決策は、気象モデルからの出力としてこの情報を提供し、それを大規模言語モデルに提供して実際にこのテキストを書くことができるか、というものでした。私たちはAmazon Nova LiteとAmazon Nova Pro 1.0モデルの両方を組み合わせて使用していました。バージョン2はまだリリースされていませんでした。このタスクの枠組みを説明すると、通常、専門の気象予報士がこの予報を作成するのに1日数時間かかります。そして、Amazonのチームとわずか4週間のプロトタイピングで、私たちはAmazon Novaに5分未満で52%から62%の精度でこれを行うことを教えました。
LLMとVLMの2つのアプローチとファインチューニング戦略
Dineshに引き継ぐ前に、私たちがどのようにこれに取り組んだか、そしていくつかの背景、私たちが実施したいくつかの実験について少しお話ししたいと思います。私たちが探求した2つの異なるアプローチについてお話しします。どちらも気象センサーデータを取得することから始まり、それが私たちのモデル、決定論的モデルと確率的モデルの両方で実行され、出力を生成します。これらの出力は、私が言ったように、通常非常に大きな配列であり、生のグリッドデータで構成されています。つまり、緯度、経度、時間を扱っているということです。
大規模言語モデルの実装では、テキスト中間層を通じてこれらを解釈しました。つまり、冒頭で聞いたShipping Forecast自体の異なる地域に対応する統計を抽出し、それらを要約してからNova LLMに渡しています。そして、これは本当に私たちにベンチマークを提供してくれます。また、私たちが探求したこと、そして私たちの実験の焦点の多くは、これらのタイプのモデルのビデオ機能の使用に関するものでした。つまり、同じグリッドデータを最初にビデオに変換してエンコードしました。これは、ほとんどのパラメータについて、通常は海域ごとに行われました。
そして、私たちの気象予報士が以前に発行した速報を使用してこれをファインチューニングし、これらを入力として解釈できるようにしました。そして、それをホストして、リアルタイムで推論を実行できるようにしました。しかし、このアーキテクチャについてより深く掘り下げるために、Dineshに引き継いでそれについて話してもらいます。ありがとうございました、Ed。こんにちは。おはようございます。私の名前はDinesh Maneです。ルクセンブルクを拠点としており、Worldwide Specialist Teamで働いています。そこでapplied scientistとして働いています。
本題に入る前に、質問させてください。re:Playに参加された方はどれくらいいらっしゃいますか?手を挙げていただけますか?素晴らしいですね。朝のセッションに参加できたんですね。私のマネージャーは、re:Playから私を押し出してセッションに来させたんですよ、ほら、ちゃんと夜はよく寝なさいって感じで。さて、それでは詳しく見ていきましょう。では、ファインチューニングされたモデルのデプロイメント戦略とプロビジョニングについてお話しします。アーキテクチャの詳細についてお話しします。主に2つのモジュールがあります。1つは大規模言語モデル基盤で、もう1つはビジョン言語モデルです。そして3つ目は、ノートブックサンプルの1つについてお話しします。そこでは実際にコードを見ることができます。特に機械学習エンジニアの方々は、モデルのファインチューニングがどれだけ簡単かを見たいと思っているでしょう。では、それをやってみましょう。
SageMakerを活用したモデルトレーニングとデプロイメントアーキテクチャ
Novaモデルをファインチューニングするには、2つの選択肢、2つのフレーバーがあります。1つはSageMaker Training Jobsで、2つ目はSageMaker HyperPodです。どちらを選ぶかは、ユースケースと、どれだけのデータ量があり、どれくらいの期間ジョブをトレーニングするかによって決まります。私たちの実験では、トレーニングジョブはP5.48xlargeのGPUで4つのGPUを使用して3時間実行されていました。
クラスターは使いたくありませんでした。素早く、ざっくりとした実行を超高速でやりたかったので、SageMaker Training Jobsを使用しました。しかし本番環境で、5年分のデータがあり、数百のGPUで数週間トレーニングしたい場合は、SageMaker HyperPodが適切なツールです。1つ小さな違いがあります。PPOをサポートしているのはSageMaker HyperPodのみで、それ以外はすべてSageMaker Training Jobsでサポートされています。
Aidが説明したように、簡単に振り返ると、この大規模優先アプローチで、基盤モデルを使用した予測にどのように取り組んだかについてです。2つのLLMを使用しました。1つ目はClaude Sonnet 3.7で、その出力をNova Pro 1モデルと比較しました。Nova Pro 1はこの気象予測においてより高い精度を示し、ファインチューニングはされていませんでした。単純なプロンプトとデータ処理を行っただけです。ここでお見せすると、気象センサーデータが取得されています。生の入力グリッドデータ、これが私たちにとって何を意味するかというと、XとYが緯度と経度を表す多次元配列があります。1つの値は、おそらく振幅のような値を持つ気象属性の1つになります。つまり、海の波の高さですね。特定の地理的位置で、緯度、経度、そしてその波の高さが表示されます。これが生のグリッドデータの一例です。さまざまな側面がありますが、それに絞って説明しましょう。
そのデータ準備は、Edwardが述べたように行われ、その生の処理済みデータを基盤モデルに渡しています。もう1つあります。海域に風向きのような気象属性があり、この特定の海域で90%の風が北方向に流れ、10%が北東に向かっている場合、その地域全体を北方向として選択します。つまり、それが生データからデータ準備への流れで、それを基盤モデルに渡しているのです。
それではアーキテクチャについて深く掘り下げていきましょう。このアーキテクチャはプロトタイピングフェーズの4週間以内に構築されました。まず生のインプットグリッドデータがS3バケットに保存されています。Edwardが言ったように、1回の実行は約45GBでしたが、私たちはそのサブセットを使用していて、3ヶ月分のデータで約86GBの数値データでした。たったそれだけです、3ヶ月分でサブセットであっても86GBです。私たちは実際にECSを使って並列処理で処理しました。なぜなら、もし誰かが86GBの処理をシングルコアで実行したら、数ヶ月かかってしまいます。この2つのオプション、EKSまたはAWS Batchは、この3つのうちの1つを選択することでデータ並列処理が可能であることを示すためのものです。データが処理されると、Bedrockのfoundation modelを呼び出し、出力をS3バケットに保存します。
ここで強調したいのは、このアーキテクチャは大量の履歴データを処理するのに非常に優れているということです。Bedrockを通じたfoundation modelsは主にバッチ推論をサポートしていますが、どのモデルがサポートしているかを確認する必要があります。Claudeファミリーはサポートしていますし、Novaファミリーもサポートしています。これにより多くの時間を節約でき、コストも大幅に削減できます。ファインチューンされたモデルを使用する場合には1つ小さな注意点がありますが、それについてはVLMのところで説明しますので、メモしておいてください。これは非常に柔軟性があります。なぜならECSを使用していて、その裏側でどれだけの計算能力を与えたいかに基づいてEC2インスタンスまたはFargateを使用できるからです。このアーキテクチャには1つ欠けているものがあります。それはオーケストレーションが手動であることです。これはプロトタイプだったので、非常に迅速な実行を行う必要があり、それが本番環境用に提案したものです。そしてもちろん、顧客ごとに変わります。
このユースケースでは、ここにS3バケットがありました。はい、ポインターを使いたかったんです。S3バケットにはデータがあります。AWS Glue CatalogとAWS Lake Formationがあります。組織が成長するにつれて、チームがデータにアクセスしたいと考えるようになり、データへのきめ細かいレベルのアクセスを提供するために、このデータプレーンはAWS Lake FormationとGlue Catalogで非常に役立ちます。Glue Catalogは、XからYまでの特定の時間枠のデータのサブセットを取得したい場合に非常に優れています。クエリを実行すれば、非常に簡単にデータを取得できます。Amazon SQSを使用してこのアーキテクチャを分離しています。本番環境では分離が非常に重要です。なぜなら、何か問題が発生した場合はどうでしょうか?どのデータが失敗したのか、どの予測が処理されていないのかを知る必要があります。
このSQSは非常に重要です。デッドレターキューも接続できるので、レコードが失敗した場合、それはキューに追加され、チームがさらに調査できます。データ前処理ブロックは同じで、ECS、EKS、Batchです。ニーズに応じてこれらのいずれかを使用できます。一部の顧客はワークロードをほとんどEKSで実行しているため、EKSで処理を実行することを好みます。ECSを使用する顧客もいます。
他にも説明したいアーキテクチャがあります。ユースケースがストリーミングデータを使用する場合はどうでしょうか?Amazon Kinesis Data Streamsを使用できます。処理のためにLambda関数が接続されています。いくつのLambdaを使用するかによります。1つのLambdaの出力が別のLambdaに依存する異なる処理の場合、Batchを使用するかもしれません。データが処理されてfoundation model用にフォーマットされたら、モデルを呼び出すだけです。結果をAmazon DynamoDBとOpenSearchに保存します。リアルタイム分析も行いたい場合にこれを使用しています。最後はサーバーレスイベント駆動型アーキテクチャです。これでは、すべてがサーバーレスです。データがアップロードされてS3で利用可能になると、Lambdaがトリガーされます。AWS Step Functionsを使用して処理を行い、その後Amazon Bedrockに送られ、データが保存されます。
VLMによる動画データ処理とBedrockを使った本番環境構築
さて、2つ目のモジュールであるVLMは、はるかに面白いものです。データがどのように見えるかをお話しします。毎日、31の海域に対して4回予報が生成されます。最初の予報では、31の海域があり、各海域には4つまたは5つの属性、気象属性があり、それに対して動画を作成する必要があります。1時間ごとにセンサーデータのスナップショットを取得しています。つまり、24時間で24フレームになります。生のグリッドデータは画像に変換されます。したがって、1日分のレコードに対して24枚の画像があり、それらを次々に追加して、24フレームの1秒間の動画を作成しています。これが私たちのトレーニング用の入力データです。
その後、アーキテクチャ図を見ていきます。この生の入力グリッドデータはS3バケットに保存されます。同様のロジック、データ並列処理を使用して処理されます。86ギガバイトの生のグリッドデータ、数値データから、3ヶ月分のデータで56ギガバイトの動画が作成されました。また、データのクリーニングも行う必要がありました。2つの海域の予報が結合されているケースがいくつかありました。それは専門家がそのように行っているからです。そのため、トレーニング目的ではそれをスキップする必要がありました。このアーキテクチャでは、トレーニングデータが入っている生のトレーニングバケットデータがあります。そして、Amazon SageMaker AIを使用してファインチューニングジョブを送信します。トレーニングジョブが完了すると、モデルの重みが入った出力バケットが得られ、それをAmazon Bedrockを使用してホスティングしています。
では、私たちが実験した2種類のファインチューニングについてお話ししたいと思います。1つ目はLoRAです。LoRAで行うことは、基盤モデルがあり、アダプターのように重みを追加し、そのアダプターだけをファインチューニングします。それだけです、他には何もありません。しかし、基盤モデルのフルファインチューニングを行う場合は、各レイヤーの重みを更新します。これには時間がかかりますが、モデルがより多くを学習するという追加のメリットがあります。LoRAを使用している場合は、オンデマンド推論を使用できます。LoRAのオンデマンド推論とはどういう意味でしょうか？実際のモデルの重みはサービスバケットにあります。LoRAアダプターの重みは、あなたのバケット、あなたのアカウントにあり、デプロイする際に、LoRAの重みが追加されてモデルがデプロイされます。したがって、オンデマンド推論を使用できます。入力トークンと出力トークンがどれだけ生成されたかに対してのみ支払います。
しかし、フルファインチューニングを使用している場合、何が起こるかというと、モデルの重み全体が更新されることになります。そのため、そのモデルの重みは、元の基盤モデルとは異なる場所に保存されることになります。そこにある新しいモデルの重みは、インスタンス上で24時間ホストされる必要があります。
そのため、プロビジョンドスループットを選択する必要があります。デプロイできるように、プロビジョンドスループットを購入する必要があります。これが私が強調したかった重要な違いです。この場合、LoRAを使用しているときは、オンデマンド推論を使用できましたが、フルファインチューニングを使用する場合は、プロビジョンドスループットを使用する必要がありました。
このアーキテクチャは、プロトタイプのために4週間で構築されました。非常にシンプルです。本番環境で使用できる多くの機能が欠けています。それでは、本番環境のアーキテクチャに移って、どのように見えるか確認しましょう。異なるプレーンがあります。データプレーン、コンピュートプレーン、そしてSageMaker training jobプレーンもあります。データプレーンでは、ここでもAmazon FSx for Lustreに注目していただきたいと思います。これは、低レイテンシーが必要な要件がある場合に、超高速アクセスのために追加されています。Amazon FSx for Lustreクラスターはキャッシング目的で使用でき、LLMアーキテクチャで示したものと同様のロジックを使用しています。
コンピュートプレーンはSQSで分離されており、ECSまたはEKSまたはAWS Batchでコンピューティングを行っています。データが処理されると、すべてのビデオが保存されます。1つの予測に戻ると、24時間分の記録データがあるので、24枚の画像を作成しています。24枚の画像から1秒のビデオを作成し、31の地域があります。つまり、1つの気象属性と1日について31本のビデオがあります。これはかなりのビッグデータ、大量のデータです。SageMaker AIを使用しています。この場合、必要に応じて本番環境ではSageMaker HyperPodとSageMaker training jobsの両方を使用できます。本当にSageMaker HyperPodを使う必要があるのでしょうか?
モデルがトレーニングされたら、重みはAmazon S3に保存され、それからBedrockにデプロイします。なぜBedrockにデプロイするのでしょうか?最初の質問は、なぜか、そして何を追加で提供してくれるのか、ということです。なぜなら、モデルがBedrockにあると、Bedrockで利用可能なほぼすべての機能をそのモデルで使用できるからです。何も変更せずにBedrock Converse APIを使用できます。モデルのIDを変更するだけで動作します。ガードレールを使用したい場合は、それも使用できます。つまり、差別化されない重労働を軽減してくれるのです。
代替アーキテクチャがあります。それらについて説明したいと思います。最初のものはモデルのファインチューニングです。シンプルです。データはS3バケットにあります。なぜすべてをS3バケットに入れるのでしょうか?非常にスケールしやすく、EKSとECSでは実際にかなり高速にプルできるからです。データがそこにあると、データが処理され、再びS3バケットに保存され、SageMakerまたはHyperPodを使用してトレーニングします。そして推論のためにデプロイします。
2つ目は、そのモデルをどのように呼び出すかです。なぜなら、VLMでは膨大な量のデータ処理があるからです。例えば、データが入ってくると、ビデオを作成するために処理するのに少なくとも1分はかかります。なぜなら、生のグリッドデータを取得し、クリーニングする必要があり、それから画像に変換され、そしてビデオになるからです。つまり、少し時間がかかります。そして、それが完了したら、Amazon Bedrockを呼び出して推論を取得します。
最も簡単な質問は、なぜAmazon SageMakerエンドポイントでホストしないのか？なぜBedrockを使っているのか、あるいはなぜAmazon EKSでホストできないのか？ということです。もしHugging Faceのようなオープンソースモデル、例えばLlama V3があれば、それができます。そのモデルをファインチューニングして、SageMaker Endpointでホストすることもできますし、Amazon EKSでホストすることもできます。
LLMとVLMの部分がありました。さて、これをUIでどのように表示したかったかを簡単に説明します。アプリケーションがホストされていてパブリックインターネットからアクセス可能な場合、CloudFrontとAPI Gateway、AWS Lambdaを使用し、SQSでアーキテクチャを疎結合にして、Amazon BedrockやSageMaker、EKSを呼び出します。もう一つのアプローチは、CloudFrontを配置し、Application Load Balancerを持ち、静的ウェブサイトまたはAmazon Container Serviceのウェブサイトをその背後に置き、それを通じてSageMaker AIやEKS、Bedrockを呼び出して処理を行います。
ノートブックで見るファインチューニングの実装とデプロイの実際
Amazon App RunnerやAmazon Amplifyを使ってウェブサイトをホストすることもできます。では、ノートブックに入っていきましょう。ここで非常に難しい質問をします。大規模言語モデルや何らかのファウンデーションモデルをファインチューニングしたことがある方は何人いますか？手を挙げてください、恥ずかしがらないで。さて、難しい質問です。最初の試みでファインチューニングができましたか、それともできませんでしたか？いいですね、それだけです。では、これをお伝えします。私は25回ほど実験を行い、1、2回失敗しました。なぜなら、私の側でトレーニングデータが不足していたため、停止しなければならなかったからです。非常にスムーズに動作します、いいですか？
では、トレーニングデータがどのように見えるか。ここに注目していただきたいと思います。システムはシステムプロンプトです、いいですか。これは、あなたはイギリスの海事に特化した気象学の専門家です、と言っています。さて、これが私たちのユーザープロンプトです。この1秒の動画を分析して、これとこれとこれをしてください、と。そしてこれが私たちの入力データです。Biscayが海域で、これが気象属性の一つです。これが私たちの入力動画で、これがグラウンドトゥルース、私たちの出力です。それだけです。このような例が3,000個あれば、3,000行の1つのJSONファイルが作成され、これが1行にフラット化されます。これが私たちのトレーニングデータです。モデルをファインチューニングする際には、トレーニングデータセットと検証データセットを作成します、いいですか。
モデルのファインチューニングをどのように設定するか、これは何でしょうか？レシピファイルとは何でしょうか？知らない方のために説明すると、レシピファイルはハイパーパラメータの設定のようなものです。これを見ると、どのモデルをファインチューニングしたいかを指定します。レプリカは、何個のGPUでトレーニングしたいかということです。トレーニング設定、何エポックか、正則化パラメータを制御したい場合などを指定します。オプティマイザーは、すぐに使える多くのオプティマイザーが用意されています。それをそのまま使うことができ、これがLoRA設定アダプターです。それだけです。このYAMLファイルとトレーニングスクリプトが必要です。では、トレーニングスクリプトがどれだけ難しいか見てみましょう。いいですか？私にとっては非常に難しかったですが、見てみましょう。
いいですね。とてもシンプルです。ここでYAMLファイルを定義します。入力データですが、お話ししたように、train.jsonファイルがあります。例えば、1つのファイルから3,000行を選択しました。出力バケットは、モデルの重みを保存したい場所です。バリデーションはvalidation.jsonです。ここでバリデーションについて少し注目していただきたいと思います。モデルをファインチューニングする際は、バリデーションデータセットを使用してください。なぜでしょうか?モデルはトレーニングデータセットで最適化しようとするからです。トレーニングロスは常にどんどん下がっていきますが、実際のデータでは上がってしまうかもしれません。ですから、トレーニングデータ、トレーニングロス、そしてバリデーションロスの両方が下がっているスイートスポットを見つける必要があります。しかし、バリデーションロスが上がり始めたら、トレーニングを停止する必要があります。これを覚えておいてください。
そしてこちらはimage URIです。これはDockerイメージです。そして非常にスムーズに動作します。ライブラリの設定に問題はありません。可能な限りスムーズに動作します。それからインスタンスタイプはP5.48xlargeです。Amazon Novaのファインチューニングには、P5とP6も使用できます。推奨されているインスタンス数は4から8、そして16です。モデルをファインチューニングする際にTensorBoardの出力を追加することもできます。次にestimatorを作成します。これは単に、そこにあったすべての情報を与えるだけです。そしてここで入力、トレーニング入力、バリデーション入力を取得し、モデルをfitします。3時間以内にモデルがトレーニングされます。これが私たちのデータに対するものでした。
では、そのモデルをどのようにデプロイするか。ここにBedrock clientのcreate custom modelがあります。これによってカスタムモデルが作成され、モデルの重みが取得されます。そしてこのcreate custom deploymentは、Bedrock上にデプロイすることを意味します。すべてを行うのに1時間ほどかかります。ですから、custom deployment ARNに注目していただきたいと思います。これはモデルARNまたはモデルIDのようなものです。では、どのように推論を取得するか。これがマジックコードです。Bedrock runtimeのconverse APIがあります。モデルIDを与えます。これがcustom deployment ARNです。
システムプロンプトは「あなたはイギリスの気象学の専門家です」で、ユーザープロンプトは「その12秒の動画を分析してください」でした。これにはS3バケットからの入力動画URIが含まれており、それだけです。モデルが出力を出し、これがグラウンドトゥルースです。ですから、これに非常に近いものになっています。ここで私たちは多くの実験を行いました。約2,025回の実験を実施し、LoRAと完全なファインチューニング、つまりモデル全体をファインチューニングする実験を行いました。そこで実験とモデル評価はEdwardが実行しますので、彼にバトンタッチします。どうもありがとうございました。
実験結果の分析：結合モデル vs 個別モデル、LoRA vs フルファインチューニング
はい、ありがとうございます。素晴らしいです。ありがとう、Dinesh。アーキテクチャについて議論したところで、foundation modelへの情報の提示をさらに最適化するために実施したいくつかの実験と評価について簡単にお話しします。Novaファインチューニングにおけるこれらの実験は、4つのことに集約されました。まず、結合モデルと個別モデルを検討しました。連続データとカテゴリカルデータの提供方法を検討しました。過学習とアーリーストッピングのシミュレーションを検討しました。そして最後に、Dineshも言及したように、フルランクファインチューニングとLoRAアプローチを検討しました。
それでは改めて要約しますと、私たちのLLM実験では、ファインチューニングなしでNova Proモデルを使用していました。VLMアプローチについては、Nova Liteモデルを使用し、Dineshが先ほど説明したようなファインチューニングを行いました。それでは、これらの実験についてお話しします。まず最初に、これらの動画をどのようにフォーマットするかを検討しました。すべての気象属性に関する情報を含む単一の動画を提供するというのは、表面的には魅力的に見えます。つまり、風速、風向、視程、天気の種類、海況といった関心のある各パラメータをまとめて、単一の5秒間の動画にするということです。
しかし実際には、これらを個別の属性ごとに分解し、それぞれに対してモデルをトレーニングする方が、はるかに良い結果が得られることがわかりました。個別のモデルは、結合されたモデルを平均で約27.3%上回るパフォーマンスを示しました。これは、提供するプロンプトの機会が増え、実行方法に関する制御が向上し、コンテキストスイッチングがそれほど発生しないためです。次の問題は、実際にこの気象データをモデル自体にどのように提示するかということでした。
例えば、通常、海況のフィールドを考えます。つまり、波高は実質的に波の高さを示すマップであり、その高さは数値で表現されます。しかし、Shipping Forecastの特定の言語を考慮すると、実際にはこれらをこの特定の用語に対応する特定のバンドに分類する機会があります。そして再び、提供される動画の連続的なカラースケールから、Shipping Forecastの特定の用語に対応するこれらのバンド化されたカテゴリ値にカラースケールを変更することで、さらなる改善を達成することができました。カテゴリデータモデルは、連続モデルを平均で約25.4%上回るパフォーマンスを示しました。
そして、これをもう少し深く掘り下げてみると、実際に最も大きな改善が見られるのは天気の種類などの領域です。以前は数値のテキストラベルには実際の意味がありませんでした。しかし実際に、これを変換し、提供する動画のy軸やカラースケールにラベル付けすることで、この追加情報を提供して支援することができます。多くの点で非常に直感に反する結果だったのは、過学習と早期停止の実験において、過学習が早期停止を上回るパフォーマンスを示したことです。これは検証損失が高いにもかかわらずです。
そして、これを遡ってみると、これはトレーニングで使用していたトレーニング目標と評価アプローチの間の不一致によるものです。そして実際には、過学習はShipping Forecastに特有の正確な単語パターンの記憶を強化しており、したがってより確信度の高い出力を生成します。つまり、単語ベースのF1スコアが向上し、より正確で完全な予報が得られるのです。
しかし、この埋め込み確率やperplexityを最適化するearly stoppingは、こうした種類のニュアンスを捉えることができません。 そして、これからお話しする最後の実験は、このfull rank fine-tuningとlow rank adaptationに関するものです。私たちが確認したのは、通常、full rank fine-tuningがこれらの実験においてadapterの使用を約6.2%上回るパフォーマンスを示したということです。Dineshが説明したように、LoRAアプローチは基本的に事前学習済みの重みにadapterを適用することで、これらの調整を可能にするものです。
しかし、これらのアプローチの特性について、特にこれらのアプローチを使用する際の注意点について、もう少し深く掘り下げる価値があります。特にfull weight fine-tuneと比較してですね。基本的に、モデルが単一の狭いタスクのみを実行する必要がある場合、full model trainingは依然としてパフォーマンス上の優位性を持つことができます。その非常に特定の動作を学習するために、非常に密接に最適化しているわけです。対照的に、LoRAは学習量が少なくなります。これについてはDan Bidermanらによる論文を参照していただきたいのですが、そこで詳しく説明されています。
しかし、LoRAは学習量が少ない一方で、忘れることも少ないのです。full model fine-tuningでは、トレーニングデータセットに含まれていない他の機能を壊滅的に忘れてしまうリスクがあります。注意しないと、これを壊滅的な影響とともに効果的に上書きしてしまう可能性があるのです。ただし、この領域にはある程度の妥協点があり、Dineshが言ったように、私たちはこのLoRA adapterをモデルの最終層にのみ適用していました。
しかし、最終層だけに適用するのではなく、ネットワークの各層にLoRA adapterを適用することで、レイテンシの増加というコストはかかるものの、パフォーマンスを大幅に向上させることができるという最近の証拠があります。ただし、これによりLoRAベースの手法を使用してこれらのアプローチを調整する際の、より後悔のないアプローチが提供されることになります。そして、full fine-tuningとは対照的に、学習率も上げることで、その領域でもパフォーマンスの同等性を達成できる可能性があります。また、今週の発表のいくつかの文脈で言及する価値があるのは、Amazon Novaの機能の一部も、将来的にこれらのタイプのアプローチを包括的に調整できる追加の機会を提供する可能性があるということです。
さて、いくつかの実験とそれらの最適化について少しお話ししましたが、評価についても触れる価値があると思います。例えば、私たちが使用したF1ベースのメトリクスについて言及しましたが、最終的なモデル比較を提示する前に、これらについてもう少し深く掘り下げていきたいと思います。
評価手法の選択：単語ベースF1スコアとBERTスコアの比較
さて、私たちの実験全体を通して、単語ベースのF1スコアリングを使用しました。冒頭でお聞きになったように、Shipping Forecastのテキストは非常に特殊で、その性質上構造化されているため、創造的な文章を書く余地はあまりありません。そのため、直接比較できるメトリクスを使用したいと考えました。つまり、生成されたテキストと期待されるテキストの間で、一致する単語の数、欠落している単語の数、余分な単語の数をカウントしています。そして、ここにその例を示しています。
例えば、風の特性に関する期待されるテキストがnortheast veering southeast 3 to 5で、生成されたテキストがeast or northeast, 3 to 5だった場合、4つのtrue positives、2つのfalse negatives、2つのfalse positivesがあり、全体的なF1スコアは67%となります。さて、他の人が検討したかもしれない別のアプローチとしては、例えばBERTスコアを使用する方法があります。
これは単語ベースのprecision recallの代替手段ですが、単語間のマッチングがはるかに柔軟になるため、Shipping Forecastのような極めて高い精度が求められるアプリケーションでは、パフォーマンスの印象が過度に寛容になってしまいます。例えば、私たちが使用した単語ベースのF1スコアで先ほどお見せしたのと同じケースを使うと、BERTベースのスコアだった場合、私たちが測定した67%の精度ではなく、約86%のパフォーマンスという結果になり、これは少し誤解を招くものです。
そして、なぜこのようなアプローチが非常に誤解を招くのかを本当に掘り下げるために、例えば単語の
northとsouthを考えてみましょう。明らかに、地理的な方向は気象システムがどこから来ているかを伝える上で基本的なものです。しかし、期待される単語northと期待される結果northを生成し、生成された単語がsouthだった場合、実際にはこれはBERTスコアで82%という結果になります。これは完全に逆の地理的意味を持っているにもかかわらずです。これは、スコアにおいて単語対単語のレベルではなく、埋め込みレベルで動作しているためです。これらのタイプのアプローチを評価する際の注意点として、これについて言及しておこうと思いましたが、同時に私たちがこれらの実験に適用した厳格さと堅牢性を示すためでもあります。なぜなら、私たちは文字通り、専門の気象学者が発行した速報と比較し、その基準で単語をカウントしているからです。
さて、Dineshも触れましたが、LLMの比較として、Nova ProモデルとClaude 3.7 Sonnetモデルの比較を検討しました。そして繰り返しになりますが、Dineshが述べたように、パフォーマンスには差があり、Nova Proは平均Word F1スコアで62%を記録したのに対し、Claude 3.7 Sonnetは57%でした。そして重要なのは、運用面から見て、より低コストで実現できたということです。ただ、ここで実際の数値にあまりこだわりすぎないようにしたいと思います。なぜなら、ご存知の通り、この分野では基盤モデルが常にリリースされており、これは増加の一途をたどっているからです。
ですので、ここで重要なポイントは、そして冒頭でDineshが話したアーキテクチャに関連することですが、Bedrockでこれをアーキテクトした素晴らしい点は、実際に新しいモデルがリリースされた際、例えばClaude 4.5 Sonnetのような場合でも、コード内のたった1行の変更だけで、新しいモデルでテストできるということです。そしてアプリケーションによっては、パフォーマンスが良くなったり悪くなったりするかもしれませんが、この基盤の上で、リリースされる新しいモデルを活用できる完全な柔軟性を持っているということです。
また、ここでLLMとVLMの比較についても少し触れておく価値があります。さて、LLMベースのアプローチでは、テキストの中間表現を通じて情報を提供していました。そして、実験のフォーマット方法により、少し追加の情報を提供することができ、Nova LiteモデルではなくNova Proモデルを使用していました。一方、VLMアプローチでは、例えば確率的情報のよりシンプルな表現を使用しており、これは大幅に改善できる余地があります。それでも、人間の気象予報士が書いた速報と比較して52%から62%のスコアを得ており、特にVLM分野でこれを進化させる機会は非常に大きいです。そして、これが今後の鍵になると考えています。テキストの中間段階を通じてLLMに情報を提供することに伴う情報のボトルネックを軽減する上で重要になるでしょう。
プロジェクトの成果と今後の展望：4週間で達成したスケーラブルなAIソリューション
それでは要約しますと、ここから得られた主な学びについてです。基本的に、私たちはスケーラブルなAIソリューションをアーキテクトするためのパターンを進化させました。代替案、利点、欠点を考慮したもので、Met Officeで提供している多くの製品やサービスに適用されるこのタイプのデータからテキストへの変換に適用できます。また、これは迅速な実験と改善のためのフレームワークを提供します。Dineshが述べたように、この作業はすべて4週間という期間内で実施されました。環境の立ち上げから評価と査定の実施まで含めてです。ですので、これらの中で、そしてAmazonチームからの作業慣行とサポートを得て、どのような速度で作業できるかを示しています。
基本的に、私たちはLLMベースのアプローチとVLMベースのアプローチの比較を見ていました。そして述べたように、LLMの方が優れたパフォーマンスを示しました。なぜなら、追加のドメイン知識を適用でき、入力を簡素化できたからです。しかし、これらのテキストデータの記述は情報のボトルネックを表しています。ですので、将来的には、VLMが実際にこのタスクでLLMを上回るパフォーマンスを発揮すると予想しており、これを前進させるために実装すべきエキサイティングなステップがあります。
最後に、実施されたファインチューニング実験について、特にLoRAとフルファインチューニングの使用について詳しくお話ししました。LoRAは学習量が少ないため、特化したアプリケーションの場合、実際にはフルモデルトレーニングの方がパフォーマンス上の利点がある可能性がありますが、忘却も少ないため、破滅的忘却のリスクを軽減できます。
先ほど申し上げたように、現在非常に注目されている研究の一部では、これをモデルの各レイヤーに適用することで、後悔のないアプローチが得られる可能性があることが示唆されており、Nova Forgeフレームワークに関連するさらなる考慮事項と機会があり、これが追加の基盤を提供する可能性があります。
これをここにしばらく表示しておきますので、本当にすべてをまとめたものになります。左側にはプロトタイプに使用した完全なアーキテクチャ図があります。右側には、インターフェースの一部を表示しており、LLMベースのアプローチのインターフェースを記録しています。これにより、一部のユーザーにこれを公開する手段が提供されました。非常にエキサイティングなことに、これらの出力の一部を気象学者による評価のために実際に提供できるように前進しています。Shipping Forecastだけでなく、同様のワークフローにも適用されます。ですので、これを本当に楽しみにしています。
ちなみに、ここで左側に見えているのは、Shipping Forecastの速報を読み込んだところです。これは評価用です。ここでLLMタスクを実行しており、実行中に関連する進捗状況を確認できます。この場合はLLMタスクです。そして右側では、LLMから返された結果が表示され始めます。これはShipping Forecastに対応しており、これにより評価の機会が得られます。
これで右側に生成されたのが確認できます。これを気象学者が書いた速報と直接比較できますが、これらの比較に基づいてスコアリングを適用することもできるため、実際にこれのパフォーマンスを評価できます。これは下部のタスクに表示されます。この同じインターフェース内で、このような関心のあるユーザーとこの基盤の上で関わり始めることができます。
そして最後に、一番下の方ですが、翻訳の機会をいくつか生成しているところです。明らかに、国立気象サービスとして、異なる言語でデータを提供したり、異なる言語で入力を受け付けたりできることは、この種のモデルの標準的な機能です。そして、そこで生成された人間参照用の出力を見ることができます。
最後に、ご参加いただきありがとうございました。Dineshが言ったように、re:Playの後にもかかわらず本当に感謝しています。しかし、特に感謝したいのは、AWSのスペシャリストプロトタイピングチームの皆さんです。彼らのサポートは本当に素晴らしく、これを実現するために絶対に不可欠なものでした。Dinesh、そして本日ここに来られなかったEmilioとLuisとAmir、そしてチームリーダーのGovindarajanにも感謝します。
最後に、モバイルアプリのアンケートを通じて、ぜひフィードバックをお寄せください。大変ありがたく思います。そして、もし後でさらにお話ししたい方がいらっしゃいましたら、私たちは後ろにおりますので、喜んでご質問をお受けします。また、arXivで今週、これらの実験のいくつかをより詳しく説明した論文を公開しましたので、ご興味がありましたら、Dineshまたは私にお声がけください。リンクを喜んでお知らせします。どうもありがとうございました。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion