re:Invent 2025: WhirlpoolのAWS活用による製品開発の最適化とsurrogate modeling
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Democratizing Whirlpool's Virtual Product Development with AWS (IND331)
この動画では、WhirlpoolがAWSを活用してバーチャル製品開発を民主化する取り組みが紹介されています。製品エンジニアリングにおける3つの業界トレンド（接続製品の増加、エンジニアリング環境の複雑化、コスト削減圧力）に対し、AWSのCAD、CAE、PLM、EDAサービスを統合し、データサイロを解消する方法を解説。Whirlpoolは冷蔵庫開発において、134個の設計要因と5.5兆の組み合わせから、Taguchi配列を用いた戦略的サンプリングで1000回以下の実行に削減。AWS SageMakerとElastic Beanstalkを活用した機械学習モデルと遺伝的アルゴリズムによる多目的最適化により、エネルギー、容量、堅牢性、コストを同時に最適化。検証済みシミュレーションモデルとsurrogate modelingを組み合わせ、モデルトレーニング時間を最大70%、アーキテクチャ定義時間を最大95%削減した具体的な成果が示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
製品エンジニアリングを取り巻く3つの業界トレンド
皆さん、こんにちは。re:Invent を楽しんでいただけていると思います。本当に嬉しいです。間もなく登壇する Axel と一緒にステージを共有できることに非常に興奮しています。Axel は Whirlpool が AWS を使ってバーチャル製品開発を民主化している方法についてお話しします。Axel が登壇する前に、 私は数分間、AWS が製品開発、シミュレーション、製品エンジニアリングの領域で何をしているのか、そして顧客の製品エンジニアリング環境の変革をどのようにサポートしているのかについてお話しします。
製品エンジニアリングの観点から業界トレンドを見ると、現在業界に影響を与えている 3 つの大きなトレンドがあります。1 つ目は、ほとんどの産業用製造企業と離散型製造企業は、もはや従来の接続されていない離散製品を単に製造または設計しているだけではないということです。最近では、すべての製品が接続されており、スマートです。つまり、単に製品を販売しているのではなく、製品とサービスを一緒に販売しているということです。これらは接続された製品だからです。
2 つ目は、これらが接続された製品であるため、エンジニアリング環境全体がますます複雑になっているということです。私が言いたいのは、もはや機械設計や電気設計、電子設計だけをしているのではなく、組み込みソフトウェア設計も多く行っており、接続性も考慮しているということです。したがって、エンジニアリング環境全体が非常に複雑になり、その結果、新製品の設計とエンジニアリングにかかる時間が長くなります。
3 つ目で最後になりますが、市場が非常に競争的であるため、新製品の開発コストを削減するというプレッシャーがあります。競争力を持つために、製品を開発するコストを最適化するだけでなく、品質コストも最適化することに継続的に焦点を当てる必要があります。これは毎日お話しするすべての顧客が経験している 3 つのトレンドです。
AWSによるデータサイロの解放と製品開発の加速
では、これはどういう意味で、AWS はどのようにして顧客がこれを解決し、 彼らの取り組みを加速させるのを支援しているのでしょうか。AWS の観点から、複数のユースケースにわたって 200 以上のサービスを提供しています。製品エンジニアリングの観点から、CAD、CAE、PLM、EDA の 4 つのボックスを見ると、通常、製造顧客で見られるのは、これらが非常に分断された、サイロ化されたシステムであるということです。AWS が顧客と一緒にしていることは、その隔たりを埋めるのを本当に支援することです。つまり、もはや分断されていないのではなく、AWS を活用してデータサイロのロックを解除しているのです。これは、これらの異なるアプリケーションとプラットフォームを AWS に移行するだけでなく、それらを最新化することです。なぜなら、それが市場投入までの時間を短縮し、新製品の設計にかかる総時間を削減するという観点から、本当の価値のロックを解除し始めるところだからです。
さらに重要なことに、AWS をプラットフォームとして活用して新しい製品を設計し始めると、AWS の生成 AI 機能をたくさん活用し始めることができます。例えば、Bedrock をプラットフォームとして使用して新しい生成 AI アプリケーションを構築し始めることができます。これは digital threads や digital twins などに関するものになる可能性があり、まだまだ例を挙げることができます。では、なぜ AWS なのでしょうか？この分野で AWS を独特で異なるものにしているのは何でしょうか？それは本当に、新しい製品を設計していて、シミュレーション分野にいる場合、インフラストラクチャを本当にスケールアップしたり、スケールダウンしたりする柔軟性が必要だという事実から始まります。新しい製品をテストしたり、パフォーマンステストを実施したり、ロードテストを実施したりしているため、その柔軟性が必要です。1 年間の 12 ヶ月すべてにわたって高いインフラストラクチャが必要ない場合があります。2 ヶ月間必要な場合もありますが、その 2 ヶ月間にスケールアップして、すべてのテストを実行してからスケールダウンして、不要なコストを負担しないようにすることが、AWS を独特にしているのです。
次に、AWS を製品開発に活用し始めると、HPC と AI/ML 全体にわたって AWS の多くのユニークな機能にアクセスできます。今アンロックした データの力を本当に活用し始めて、そのデータを使用してますます多くの追加機能と追加ユースケースを構築し始めることができます。3 番目は、AWS がインフラストラクチャをどのように構成するかについて、非常に多くのオプションを提供しているという事実についてです。
これにより、シミュレーションシナリオとエンジニアリングシナリオを実行するためのコストを最適化するさまざまな方法に関して、より多くの柔軟性が得られます。そして最後になりましたが、データサイロをアンロックするのに本当に役立ちます。結局のところ、データはより多くの最新化、より多くの変革を行うのに役立つものであり、市場であなたをユニークにするものです。
Whirlpoolのバーチャル製品開発への取り組み
それでは、Axel に Whirlpool のストーリーについて話してもらうようお願いしたいと思います。ありがとうございました。皆さんに聞こえていると思います。サムズアップです。良いですね、ありがとうございます。皆さん、ここにいてくれてありがとうございます。このような機会をいただき、私たちのストーリー、バーチャル製品開発における私たちのジャーニー、モデル内の知識を民主化して製品開発を加速させることについて、少しお話しする機会をいただきありがとうございます。
これは今日お話しする内容についての簡単なアジェンダです。まず会社の紹介があります。その後、カテゴリの 1 つである冷凍に深く掘り下げます。この場合は冷蔵庫ですが、目的、スコープ、スコーピング、実装の観点から、家電製品、つまり冷蔵庫に適切なアーキテクチャをどのように作成するかについて話します。バーチャルシミュレーション機能とシステム要件について深く掘り下げます。このプロセス全体を加速させるために、バーチャルワールドでどのようにそれを行うかについてです。
Solution space exploration というのは、シミュレーションを使ってデータを取得する方法で、そのデータを使って機械学習モデルを作成し、事前に最適化を行うことができます。このトークの中核となるのは、クラウドアーキテクチャ図と、最後にまとめるビデオデモンストレーションになります。最後に、メリットについて議論します。
Whirlpool についてですが、Whirlpool は家庭用電化製品の大手メーカーで、常に家庭生活の改善を追求しています。ご覧の通り、これらが私たちのアイコニックなブランドです：Whirlpool 自体、KitchenAid、Jennaire、Maytag、Amana、Brastemp、Insinkerator で、ビルトイン冷蔵庫、ウォールオーブン、食器洗い機、全自動コーヒーメーカー、エスプレッソマシンなどのアイコニックな製品があります。価値という観点では、昨年は 170 億ドルの年間売上または収益を報告しており、世界中に約 44,000 人の従業員がいて、約 40 の製造施設と製品開発およびテクノロジー研究センターがあります。
システム最適化フレームワークとシミュレーションモデルの成熟度評価
目的、スコープ、実装という観点では、課題は、システムレベルの要件の観点からシステム最適化の変換を得ることが非常に難しく、すべての要件を本当に調和させ、パフォーマンスの観点から最高の、つまり最もコストが低く最高のパフォーマンスを持つ新興型の電化製品を提供することです。従来の方法は断片化されています。surrogate モデルなし、機械学習なし、Six Sigma なしで手動でこれを行うことができますが、それに基づいて最適でないソリューションが提供されることになり、したがって会社は損をすることになります。それは勝つアーキテクチャではないからです。
ここでの「what」は、複数の要件にわたる多目的または多基準の最適化フレームワークです。エネルギー、容量、冷却ロバストネス、ノイズ、振動、ハーシュネス、そして構造製造シミュレーションがあります。次のスライドでもっと詳しく説明します。「how」には、多くのシステムエンジニアリング、モデルベースシステムエンジニアリング、Design for Six Sigma が含まれます。なぜなら、堅牢なアーキテクチャを持ちたいからです。アーキテクチャ定義の観点で、どのようにレジリエントで堅牢になることができるでしょうか？それが基盤であり、戦略的サンプリング計画のためにも持っている中核です。
ここでは、検証済みのシミュレーションモデルを使用した FSS アプローチを使用しています。検証が何を意味するのかを示すつもりです。これは検証とは異なり、非常に重要な概念です。Surrogate modeling は本質的には、シミュレーション作業に基づいた方程式または回帰モデルです。最後の 2 つの箇条書きは、AWS SageMaker 内でのモデルフィッティングとトレーニング、そしてチューニングという観点からこのプロセス全体を加速する方法についてです。そして最後になりますが、AWS Elastic Beanstalk を使用してこれを民主化する方法についてです。
これはデータガバナンスのメダリオンタイプのガバナンスではありません。これはシミュレーションモデルの成熟度や忠実度をどのように評価するかという方法です。まず第一に、私たちは何かがシミュレーション可能かどうかを理解しようとする開発モデルを開発しました。冷蔵庫内の流体力学と気流分布をシミュレートできるか？はい、できます。氷と水の味と臭いをシミュレートできるか？特定のソフトウェアを使ってはおそらくできません。また、扱いにくい物理学についても多くの議論があります。これらはシミュレート不可能だと考えられています。ですから、私たちはこのような区別を持っています。このゲートを通過して、これがシミュレート可能であると判断したら、それを行うための適切なソフトウェア資産を持っています。
それでは、bronze層から始めてモデルを作成していきます。これは方向性があるものです。シミュレーションの観点から、私たちはコンピュータソフトウェアで十分に作られたシミュレーションを作成しています。感度分析を実行します。これは、物理学に従いながら異なる設計パラメータを試してみることを意味します。例えば、完全に支持されたビームの場合、厚さをAからBに変更すると、剛性が変わり、たわみが変わります。これは物理学の第一原理に従っています。
次のレイヤーはsilver層で、これは定量化可能なものです。定量化可能というのは、検証段階に入るための橋渡しです。定量化可能な段階からは、シミュレーションモデルを物理テストデータと共有し始めるということを言っています。物理テストから大量のデータを収集して、そのデータをシミュレーションモデルに逆流させ、シミュレーションモデルを更新してから、精度が良いかどうかを確認します。しかし、定量化可能な段階は限定された推論空間のためのものです。すべてのアーキテクチャやすべての製品バリアントのためのものではありません。1つか2つの製品ファミリーを取得して、この定量化可能なチェックを行います。
検証段階に到達すると、それはすべてのアーキテクチャと私たちのシステムまたは家電製品のすべての基礎となる複雑さのためのものです。これは単にこれを提供するためだけではなく、私たちのルールに従って良い精度を得るためのものです。シミュレーションと物理テストの間で精度の観点からこのしきい値を通過する必要があり、良い精度で一致する必要があります。また、このプロセスについてすべての影響を受けるステークホルダーとの高い合意を持つ必要があります。なぜなら、検証はシステムエンジニアリングの観点から正しいことを行うことについてだからです。ここで正しいこととは何か？シミュレーションが物理テストに取って代わる必要があります。これが基本的なルールです。
冷蔵庫の複雑なシステムレベル要件とトレードオフ
シミュレーションは物理テストに取って代わるのに十分であり、そうすれば、すべてが自然に流れていくでしょう。なぜなら、私たちは積極的に独自のデータを作成できるからです。もう物理テストは必要ありません。そして、戦略的なサンプリング計画を使用して、本当に機械学習モデルの構築を前もって加速させることができます。ここで複数の要件について話し、そしてこの多目的な推論空間全体をどのように設計したかについて話します。これはかなり複数の応答変数、つまり私たちがシステムレベルまたはエンジニアリングの声と呼ぶ大きなYsに変換されます。
最初のものは、内部容量と同じくらいシンプルです。密閉されたライナーの内部、または冷蔵庫と冷凍庫の内部コンパートメントの体積を測定します。このサイドバイサイド型の冷蔵庫のような場合、左側に冷凍庫があり、ちなみに位置を変えることができる垂直の仕切りがあります。これは設計パラメータです。右側には冷蔵室があります。このモデルは、測定された容量が物理的な測定値と一致していることを正確に示して提供する必要があります。これはその検証ですが、非常に些細なことですが、非常に有用です。なぜなら、内部容量をどのようにして向上させることができるか、そしてそれに応じてエネルギーおよび他の応答変数を提供する方法を理解したいときに、トレードスペースで違いを生み出すからです。
次のものは、冷凍回路の観点からの性能係数との相互に絡み合った接続です。この性能比では、evaporator の設計と、システムから取り出す必要があるすべての熱ゲインがあります。熱ゲインは、多くの断熱壁、vacuum insulated panels と呼ぶものの存在、および製品のフットプリントまたはサイズで形成および構成されます。これらすべてが熱ゲインに影響を与えます。エネルギーは、本質的には、その熱を除去し、システムに適切な温度で食品の鮮度を提供するなどのために、システムをどのように調整するかです。これは熱ゲインとエネルギーの間の相互に絡み合った接続です。なぜなら、熱ゲインはエネルギー方程式に寄与するからです。
この点は非常に重要です。熱ゲインはシステムに入る熱の量を定量化し、エネルギーはそれを除去するためにシステムが実行する仕事の量を定量化します。ここにバランスがあります。先に進むと、熱ゲインは製品自体の壁の厚さという観点での構造だけではありません。 A、B、C、D の壁の内側に断熱層があり、これはポリエチレンフォーミングです。これが製品の断熱に関して持っているものです。製品の寸法は重要ですが、それに加えて、このような密閉体積の内部に入るフォームのブローイングエージェントの種類とフォーミュレーションもあります。 cyclopentane または HFO のいずれかを使用できます。違いは何ですか？一方がもう一方より効率的です。HFO はより効率的で、cyclopentane より約 30 パーセント効率的ですが、コストがかかります。
それはこの種の細胞構造へのそれらのガスの閉じ込めについてのすべてです。フォーミングから。 これが HFO にそのような低い熱伝導率を与え、したがってより良い断熱性能を与えるものです。さらに、フォーミングをパックする方法が重要です。基礎となるプロセスにより、単一ポートフォームを持つことができます。ここでは、製品の底部デッキからフォーミングを注入し、フォームが上部に成長します。または、製品内の複数のポートからフォームを注入するマルチポートです。
最後になりましたが、VIP の存在があります。これは vacuum insulated panels の略です。 これらを使用して、非常に薄い壁が必要な壁の断熱を向上させ、容量を増やすことができます。ただし、ご想像の通り、これにはコストが伴います。VIP は通常のフォーミングと比較して、断熱という観点で約 10 倍効率的である可能性があるため、利点を見ることができますが、高価です。
では、システムレベルの観点からエネルギー自体についてさらに詳しく説明していきましょう。熱ゲインについて話します。 熱ゲインモデルを検証するために使用する物理テストがあり、それを reverse heat leak と呼んでいます。このリバースヒートリークテストを通じて物理テストデータを収集し、シミュレーションモデルを検証する方法です。熱ゲインはエネルギーの入力変数の1つです。それに加えて、2番目の部分は冷凍の観点からの COP 比です。 制御ロジックを備えた制御基板とソフトウェアがあります。システムの心臓部であるコンプレッサーは複数のタイプを使用できます。温度分布を提供するために複数のファンモーターを使用でき、両方のコンパートメントに非常に階層化された方法で食品の鮮度を提供することができます。そして最後になりますが、この場合はコンデンサーである熱交換器があります。制御ロジックの観点から考慮できるさまざまなタイプのコンポーネントとすべての異なるパラメータについて考えてみてください。これらすべてのものが一緒にシステムレベルのパフォーマンスを提供します。
非常に重要な要件の1つは、適切なエネルギー消費で容量を提供できることです。Energy Star に準拠することはできますが、私たちが robustness と呼ぶものにペナルティを与えることはできません。 壁の外部結露は望みません。表面温度と露点の間に常にプラスのデルタを持ちたいのです。そうでなければ、この画像の給水部分のように外部結露が発生します。もしこれがあなたの家で起こっていたら、あなたはそれを望まないでしょう。Robustness は非常に重要です。冷凍の観点からは、霜の形成や内部結露など、他の robustness 要件があります。外部結露は私たちにとって最大の課題の1つです。
もちろん、これは無視することはできません。常にそれを最小化したいのです。どこにでも VIP をたくさん配置することはできますが、それに対して支払うことができますか？このプロダクトを競争力のあるものにすることができますか？それは常に課題です。ですから、断熱材のコストと冷却コンポーネントのコストがあります。私たちはこれを compounding costs と呼んでいます。これは両者の合計であり、アーキテクチャコストです。 アーキテクチャコストは、目的関数にペナルティを与える重みを考慮して最小化する必要があり、システム全体を最適化できるようにします。
先に進むと、モデルで考慮することもできる他のことに取り組んでいます。 気流の内部分布、つまり製品への空気供給または気流管理が必要です。構造的な剛性もあります。プロダクトがドアビームに多くの食品を保管して完全に満杯になっていることを想像してください。キャビネットはすべての負荷に耐えることができ、歪みがなく、断熱材を失わず、ガスケットが補正できるようにする必要があります。熱ゲインにはトレードオフが生じ、それがエネルギーに影響を与えます。ここではすべてが繋がっています。
そして NVH があります。これは noise、vibration、harshness のことで、気中音と構造伝播音の両方です。 フォーミングシミュレーションがあります。この画像でわかるように、これは例として製品の底部デッキを通じた単一ポートのフォーミング注入です。これはシミュレーションモデルです。フォーム全体を詰め込みたいのです。壁が非常に薄い場合、フォームはスムーズに流れるのが非常に困難になり、したがって充填に関してトレードオフが生じます。これは何らかの内部空隙を作成し、したがって外部結露が発生する可能性があります。 ここではすべてがトレードオフされ、相互に関連しています。
そして、パッケージングがあります。私たちは、輸送や取り扱い中の損傷なく、顧客に製品を届けたいと考えています。 エンジニアリングやシステムレベルの要件がたくさんあり、それらは調和させる必要があります。これらは複数の応答変数、つまり複数の入力変数に大きく依存しています。これがこの入力変数のトレードスペースです。これは実際のものです。これはまさに私たちが最近やってきたことです。
直交配列と遺伝的アルゴリズムによる効率的な設計最適化
最近、このようなアプローチを使って1つの製品で実施しました。134個の要因があり、それぞれ2つのレベルを持っています。それは何かというと、厚さAと厚さBという2つのレベルを持つ厚さを設定できます。あるいは、真空断熱パネルの有無、フォーミングまたは VIP があります。これは要因の2レベル設定のようなものですが、1つか2つだけではなく、全体で4回の実行になります。34個の要因があります。3つの要因は4つのレベルを持っています。制御基板、凝縮システム、またはフォーミング特性のタイプです。1つの要因が5つのレベルを持っている場合、可能なすべての組み合わせを考慮しようとすると、銀河系のすべての星よりも55倍、つまり5.5兆の組み合わせについて話しています。それは膨大です。これを HPC、つまりハイパフォーマンスコンピューティングでも処理できるでしょうか？それは処理できるものではありません。だからこそ、私たちはこのような Whirlpool Tester Recommender と呼ばれるアプローチを考え出しました。 これは Six Sigma に基づいており、設計実験アプローチ、つまり Taguchi 配列を使用しています。
これは AWS で Elastic Beanstalk を使用して実行されているアプリケーションで、バックエンドに R と Python があります。このようなテスト推奨システムがあり、答える必要がある2つの質問があり、優先順位の観点から、私たちが開始する必要がある正しいレシピを提案してくれます。それはなぜ重要なのでしょうか？直交配列です。なぜなら、これはトレードスペースにおいて、ペアワイズで、バランスの取れた、独立した方法でデータを収集する最も効率的な方法だからです。疑いなく、これはデータを収集する最良の方法です。空間充填設計、ランダムサンプリング、何でもできますが、これはまだ最良の方法です。なぜなら、完全にバランスが取れており、直交しているからです。つまり、入力変数全体に相関がなく、多重共線性の問題がありません。
ここでペアワイズとは何かというと、任意の要因に対する1つのレベル設定は、少なくともペアワイズの組み合わせで他のすべての要因のすべてのレベル設定と交差します。トレードスペース全体をカバーします。初期コード化設計を得るために、ここで使用するいくつかの技術があります。それに対して何らかのデータラングリングを行い、このアプローチに組み込まれた自動技術を使用して、初期エンコード配列と呼ぶものを得ます。それを使用して機械学習モデルをフィットさせます。
機械学習の学習者として、私たちが通常行うことは、多くの回帰モデルを使用することです。最も単純なモデルから始めます。なぜなら、これは直交配列だからです。多重共線性が私たちに大きな影響を与えていないため、線形回帰を使用できます。テストセットからのこのホールドアウトサンプルがあっても、この場合は線形回帰から始めます。モデルが訓練セットのクロスバリデーションの精度の観点から十分に良くない場合、私たちは拡張と呼ぶことを行います。実行しやすいより多くの実行を行います。エネルギー実行は数秒で実行されるか、1分で実行されます。エネルギー実行では、数時間で数千の実行を生成できます。熱ゲインモデルは実行に数時間かかります。したがって、エネルギー側で拡張を行い、熱ゲイン実行の直交配列によって与えられた基礎に依存できます。必要に応じて、これがデータ拡張です。
このテクニックを使ったサンプリング計画で1000回を超えるものはまだ見たことがありません。1000と5.5兆を比較してみてください。これは推論空間をカバーしています。モデルのCI/CDを実行することができ、すべてのレスポンス変数に対して95%以上の精度でモデルの精度をチェックしています。効率的なデータサンプリングは、管理可能な設計空間を機械学習モデルの訓練に使用される扱いやすく効果的なデータセットに削減します。これを実行可能にしています。
これらのモデルがすべて揃ったら、推論を実行できます。これらの機械学習モデルを使って予測を行うことができます。なぜなら、テストセットであるホールドアウトセットの精度に関するすべてのセーフガードに合格し、クロスバリデーション訓練セットに対して最適化されているからです。今、私たちはoptimizationと呼ぶものを実行する準備ができています。Optimizationは非常に効果的で効率的なアプローチで、マルチオブジェクティブ遺伝的アルゴリズムに基づいています。マルチオブジェクティブが見えますね。ここのMOGはマルチオブジェクティブです。なぜなら、エネルギーコスト、キャパシティ、冷却、そしてロバストネスがあるからです。ここで対処する必要があるレスポンス変数が複数あります。
これらが私たちが実施している重要なステップです。constrained population generation、これが最初のステップです。これは何か？すべての実行が実行可能なわけではありません。いくつかの実行は本質的に最初からデータを収集するために生き残ることはありません。時には、製品に配送する必要がある最小温度を配送していないため、エネルギーを計算することさえできません。これらの実行は排除されます。これらはデータセット自体にある空白です。
このデータセットにはいくつかの他の線形制約があります。例えば、マーケティング要件がある場合、両側の壁の厚さは同じである必要があります。あるいはドアのフラッシュネスです。冷凍庫のドア深さをパラメータとして持つことができ、これは冷蔵庫のドア深さと異なる場合があります。製品を見ると、フラッシュネスの欠如が見えます。これはマーケットの観点から望ましいことですか？いいえ。ですから、ここに多くの線形制約または変数リンケージがありました。これがconstrained population generationを構成するものです。実行可能なものに対してのみ、母集団を生成します。
ステップ2はperformance predictionです。思い出してください、以前は良い精度で機能していたすべての機械学習モデルがあり、今それらを使って初期サンプリングを選び出して推論を行い、予測結果を計算することができます。ステップ3はevolutionary selectionです。遺伝学でどのように機能するかを考えてみてください。gradient descentがある場合、それは非常に可能性が高いローカルオプティマムを与えるでしょう。なぜか？それはデータ収集を開始する方法についてのすべてです。ローカルオプティマムに収束するでしょう。しかし、さらに探索できる無限空間に他のオプティマムがあるかどうかはわかりません。
遺伝的アルゴリズムはローカルで活用し、パラメータ空間の他の部分の無限空間から探索していくというアプローチでこれに対応しています。活用というのはクロスオーバーの類似表現で、探索というのはミューテーションの類似表現です。これが遺伝的アルゴリズムと呼ばれる理由は、この活用と探索の固有の性質があり、これを何度も繰り返して、与えられた重みや重要度のセットで、すべての望ましい出力にわたって最良のバランスを取りながら、Pareto フロントの観点から収束するのに本当に必要なものを見つけるまで続けるからです。
これは目的関数に重みを設定することで、ペナルティを与える方法です。マーケティングのニーズによっては、コストが容量よりも重要になる場合があるため、常に与えられた重みのセットでそれをバランスさせることができます。それを得たら、最良のソリューションを定義するために使用する最終的な重み付き複合スコアが得られます。つまり、実行可能な実行を行い、その初期集団に対して推論を行い、クロスオーバーとミューテーションを行い、ここからよくバランスの取れた観点から最適値を見つけるということです。
AWS上のモジュラーアーキテクチャとサーバーレス実装
では、ここのダイアグラムについて詳しく説明していきます。これは非常に重要な ことについて話す必要があります。AWS でそれをどのように行うかについてです。この構造の正確な詳細について説明するために、ここでもう少し時間を費やすつもりです。それについて考えてみてください。右側に見える最初の要素は API Gateway で、非常にモジュール化されています。本番環境にあるアプリケーションで使用できる API 呼び出しがあります。Elastic Beanstalk を使用すれば、このダイアグラムを API 呼び出しの観点から利用できるため、最適化やモデルフィッティング、チューニングを行うために使用できます。これは API Gateway と Lambda によって完全にオーケストレーションされています。つまり、サーバーレスアプローチですね。必要に応じて使用でき、オーバーヘッドはゼロで、非常にモジュール化されています。
1 つのコア要素として、右側にある ECR と呼ばれるピースが見えます。それを見てください。それは Elastic Container Registry でコンテナイメージです。これはコンテナのエントリーポイントを考慮に入れています。もちろん、ECR 内には Dockerfile、requirements.txt、および動的ローダーがあります。ここで SageMaker コンテナからのプリパックされたトレーニングジョブを使用していない理由は何ですか？それは scikit-learn またはディープラーニングのいずれかに限定されているからです。私はそれらすべてに加えて最適化が必要です。だからこそ、このアプローチのためにカスタマイズされたコンテナを構築する必要があるのです。なぜなら、このワークフロー全体のすべてのニーズを満たすことになるからです。
S3 バケットが ECR イメージを指しているのが見えます。これは動的ローダーです。その S3 バケットには Training というファイルが含まれており、このコンテナに属するエントリーポイント内で SageMaker トレーニングジョブのすべてのインスタンス化をルーティングします。
したがって、Lambda をサブシディーして、必要に応じて SageMaker トレーニングをトリガーします。Lambda がトリガーされた後、黄色で表示されている重要な指標が見えます。それが operation type です。これは Lambda 関数内の環境変数で、システム全体をオーケストレーションし、モデルトレーニングを実行するのか、それともモデルチューニングを実行するのかを区別することができます。上部ではモデルトレーニングへと流れ、下部ではモデルチューニングへと流れているのが見えます。
フロントエンドのユーザーがモデルトレーニングをクリックすると、すべてのパラメータと ECR のコンテナイメージを解析して Lambda をオーケストレーションし、SageMaker ジョブをトリガーして、モデルをフィットさせ、モデルフィッティング自体のための pickle ファイルを作成します。これをフロントロードしたいのは、ユーザーがアプリケーションを開く際にモデルフィッティングを経験してほしくないからです。なぜなら、それはかなりの時間がかかるからです。非常に重要なことに、このモデルトレーニング内には Shapley という別のファイルがあります。これはモデルの説明可能性のためのもので、アプリケーションの一部として説明可能な AI を持つことが必要だからです。数年前は、ニューラルネットワークとモデルはブラックボックスだと言われていましたが、Shapley 値は AI の説明可能性という点で私たちを救ってくれました。
Shapley 値について言うと、私は特徴量の重要度と部分依存プロットについて話しており、これらは変化の方向を示しています。厚さ A から B に変更した場合、熱ゲインへの影響はどうなるのか。これらすべての説明可能な AI グラフは、右上隅の出力 S3 バケット内のトレーニング用のこれら 2 つのファイルで見ることができます。次にモデルチューニングについて話すと、Optuna をトリガーすることができます。これは私がすべてのモデルをトレーニングし、遺伝的アルゴリズムを実行するために使用するライブラリです。これは最適なアーキテクチャを作成するために使用するのと同じアルゴリズムであり、ハイパーパラメータチューニングにも使用されます。
これは、特定のモデルに対してさまざまな設計要因とハイパーパラメータをインスタンス化する方法です。チューニングプロセスを指すバケットがあり、JSON ファイルにすべてのチューニング設定が含まれています。これは、ディープラーニングであるかどうか、最初のレイヤーのニューロン数、2 番目のレイヤーのニューロン数、ドロップアウトがあるかどうか、バッチ正規化があるかどうか、そして学習率などの多くの他の要因を考慮に入れています。これらすべてのことがこのモデルチューニングの観点から考慮されます。そしてチューニング自体は、下部の S3 バケットに pickle ファイルとしてチューニング結果の最適なバランスを作成します。
チューニングが処理され完了すると、ユーザーはアプリケーション上でテストセットの精度を正確に見ることができます。ユーザーがそれに満足している場合、ボタンをクリックしてモデルをトレーニングすることができます。その後、モデルトレーニングファイルと説明可能な AI ファイル、つまり Shapley 作成 pickle ファイルをフロントロードします。これが基本的にこのバックエンドのアーキテクチャで、これらすべてのオーケストレーションを行うためのものです。これはかなり複雑だと思いますが、これは非常に有用で柔軟です。呼び出して、それを消費して、オンデマンドでジョブを実行します。SageMaker を呼び出してジョブを実行し、SageMaker 内で好きなインスタンスを選ぶことができます。
ディープラーニングの場合は、より強力なコンピューティングインスタンスが必要になります。このアプローチには11個か12個の異なるリグレッサーがあります。CatBoost、ディープラーニング、XGBoost、Kriging、つまりガウス過程回帰、サポートベクターマシン、そしてあらゆるものがプリパックされています。S3バケットのトレーニングコードを変更するだけで、さらに追加することができます。追加するのは単純な問題で、追加するたびに、S3バケットにはバージョニングがあるので、このAPIがそれに応じて反映されるようになります。これが柔軟性の素晴らしいところです。
ビデオを見せる前に、少し説明したいことがあります。トレーニングとチューニングプロセス全体を、コンテナ自体の動的ローダーを使ってモジュール方式で示しました。しかし、フロントエンドアプリケーションはどうでしょうか。それはサーバーレスで、Elastic Beanstalkを使用しています。これはBeanstalkアプリで、VPC、つまり仮想プライベートクラウド内で実行され、リモートで使用している場合はVPNを通じてのみアクセスできます。これはオートスケーリングとロードバランサーと呼ばれるものを考慮に入れています。
これはDockerコンテナを使用してデプロイされます。前のスライドを覚えていれば、モデルトレーニングからの出力がこのダイアグラムの入力になります。ご覧の通り、下部のバケットでは、前のスライドからのトレーニング済みモデルとShapley作成出力がこのElastic Beanstalkアプリケーションの入力になります。なぜなら、それらはBeanstalkアプリケーションのフロントエンドによって消費されるからです。さらに、フロントエンドアプリケーションには多くの説明可能なAIと探索的データ分析があるため、データとアプリリソースがあります。
アプリリソースはここで非常に興味深いものです。コンテナを使用してElastic Beanstalkアプリケーションをデプロイする場合、必要なファイルは3つだけです。アプリケーションファイル、Dockerファイル、そしてrequirements.txtファイルです。これらはBeanstalkアプリケーションを非常に簡単にデプロイするために必要なファイルです。app.pyファイルはこれら3つのファイルの1つで、圧縮されてBeanstalkアプリケーションをデプロイするために使用されます。これはS3バケット内にあるすべてのパッケージを持つマイクロサービスアーキテクチャのようなもので、Beanstalk内に存在するapp.pyファイルから動的に呼び出すことができ、フロントエンド全体をオーケストレーションします。
これは、S3バケット内のファイルを変更すると、フロントエンドのBeanstalkアプリケーションがその変更を認識することを意味します。Beanstalkを再起動すれば、それで十分です。再デプロイする必要はありません。サーバーを再起動するだけで大丈夫です。なぜなら、再起動するたびに、S3内の新しいものを取得するからです。
では、プライベートVPCでホストされたアプリケーションがあり、内部ロードバランサー、オートスケーリングのEC2インスタンス、そしてアプリケーションコードがあります。データと学習済みモデルアーティファクトはS3に保存されており、このトップのS3バケットで見ることができます。これはDocker ベースです。なぜなら、機能性と堅牢性の観点から、これを普及させ、真の意味でコンテナ化したいからです。これが Elastic Beanstalk アプリケーションのフロントエンドです。
デモンストレーションと導入効果：最大95%の効率化を実現
では、ここで議論したすべてのことがどのようにまとめられ、最適なアーキテクチャを提供するために組み立てられたかについて、実践的な洞察を与えてくれるビデオを紹介します。 私たちの戦略は、継続的に製品を改善することです。今、私たちは仮想製品開発と人工知能をシームレスに統合した、革新的な社内マルチフィジックス最適化ワークフローを紹介しています。 私たちの高度なモデルは、50以上の設計要因を組み込んでおり、エネルギー、容量などの複数の主要なパフォーマンス指標全体で最適な組み合わせを特定します。 堅牢性、そしてコストを含みます。これにより、これらの競合することが多い要因間でスマートなトレードオフの決定が可能になり、バランスの取れた 最適なソリューションを確保します。この強力でありながらユーザーフレンドリーなエンジニアリングツールにより、製品の寸法、 高さ、奥行き、幅、断熱壁の厚さ、真空断熱パネル、マリオン位置、 コンプレッサータイプなど、多くのパラメータをリアルタイムで調整でき、リアルタイムで予測を行うことができます。また、適切なターゲットと重みを設定し、 すべての要件に対して制約を入力変数に設定することで、最適化を実行することもできます。例えば、設計最適化ループ内の10,000個の製品イテレーションは、 約5分で完了することができます。この最先端のテクノロジーにより、製品開発の初期段階での意思決定プロセスを大幅に加速させることができます。
イノベーションは常に家庭での生活を改善することを追求しています。探索的データ分析の観点から、データを視覚化できるさまざまな方法をすべて網羅する方法を見ることが有用だったことを願っています。機械学習モデルが意味をなすかどうかを確認するもう1つの方法は、クロスバリデーションされた訓練セットからの精度を見るだけでなく、テストセット自体の精度と、モデルがあなたに提供しなければならないものを提供しているかどうかを見ることです。どのようにしてそれを行うのでしょうか？
相関図を見ると、1つの応答変数と1つのx変数の間に相関があり、説明可能なAIの部分依存プロット内でそれがより顕著な効果を見ると、これは意味をなしているということです。モデルは、アーキテクチャ図から事前に作成された Shapley 値に基づいて、部分依存プロットを提供しています。生データもあなたに同じシグナルを与えているので、通常はそれを見ます。
軸全体の相関はディープラーニングにとっては大したことではありませんが、線形回帰では大きな問題になる可能性があります。私たちは常に相関図と平行座標プロット、ヒストグラムと実際のモデル結果を含む探索的データ分析の部分を見ます。私たちは2層のアプローチを使用しています。探索的データ分析と説明可能なAI、そして予測の観点から予測と推論のための他のいくつかのレイヤーです。最後になりますが、設計最適化があります。
デザイン最適化は遺伝的アルゴリズムを考慮に入れています。すべての応答変数にわたって、たくさんの異なるウェイトを設定することになります。最適化したい変数を選択することができます。例えば、熱ゲインは energy のインプットなので熱ゲインを最適化したくない場合、熱ゲインについては気にしないで最適化しないという選択ができますが、energy については非常に気にすることができます。最小化、最大化、または与えられたターゲットに到達するように最適化することができます。
内部容量については、ターゲットに対して非常に厳密にしたいです。与えられた容量を非常に高いウェイトで設定したいので、遺伝的アルゴリズムに本当に探索させることになります。なぜなら、より多くの重点、より多くのウェイトを考慮に入れるからです。外部結露に関する堅牢性については、外部結露を持ちたくないですが、表面温度と露点の間に少なくとも 1 度以上のデルタがあることを望みます。つまり、ターゲットより大きくすることも、ターゲットに直接することも、最適化しないこともできますし、最大化または最小化することもできます。
最適化したい要因とそれぞれのレベルを正確に選択することができます。真空断熱パネルで製品を最適化したくないという研究が行われました。カテゴリ変数で離散的なレベル設定なので、単にフラグを外しました。フラグを外して、探索スペースを自分が望むものだけを見るように強制します。これは完全に民主化されており、エンタープライズ全体で使用できるストック ソリューションとしてデプロイされています。
AWS SageMaker ユーザーである Whirlpool については、モデル トレーニングとチューニング時間の効率性で最大 70% の改善を見積もっており、モデル トレーニングとチューニングの効果性がはるかに優れています。モジュラー アーキテクチャにより、任意のアプリケーションで使用できます。自分に合ったインスタンスを選択できるため、ディープ ラーニングのような非常に複雑な機械学習モデルでも、多くの処理を迅速化できます。モデル トレーニングとチューニング時間で最大 70% のメリット、アーキテクチャ定義で最大 95% のメリットが見られます。
これをすべて手動で行うことを想像してみてください。複数の実験計画に対して順序立ったアプローチを考え出そうとして、設定されたレベルが少ないだけで、すべての探索をインクリメンタルに行い、最適なソリューションを考え出そうとします。正しいアルゴリズムを使用しない場合、局所最適値に収束してしまい、それは準最適になります。このアプローチを使用すれば、デザインの望ましさという観点から意味のある、正しい重点またはウェイトで探索と活用を行い、収束することができます。
これは製品開発の有効性と効率性の観点から、私たちに大きなレバレッジをもたらしています。これが本当の意味で勝つアーキテクチャを定義するために必要なことなんです。なぜなら、システムレベルの観点からすると、アーキテクチャが振る舞いを駆動するからです。正しいアーキテクチャを持っていれば、すべてが自然に流れていきます。より回復力が高くなります。ライフサイクルやデジタルスレッドは、最初から持続可能になります。
そういうわけで、プレゼンテーションはここまでとなります。本日は ここに来てお話を聞いていただき、本当にありがとうございました。また、オフラインでいろいろとお話しできる機会があれば幸いです。ご質問があれば、喜んでお答えさせていただきます。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion