🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Democratizing Whirlpool's Virtual Product Development with AWS (IND331)
In this video, AWS and Whirlpool demonstrate how they democratized virtual product development using AWS cloud services. Whirlpool's Axel presents their multi-physics optimization workflow that handles 134 design factors across multiple requirements including energy, capacity, cooling robustness, and cost. The solution leverages AWS SageMaker for machine learning model training and tuning, and AWS Elastic Beanstalk for democratizing access across the enterprise. Using validated simulation models, surrogate modeling, and multi-objective genetic algorithms, Whirlpool reduced architecture definition time by 95% and model training time by 70%. The presentation includes detailed cloud architecture diagrams showing serverless orchestration with Lambda, API Gateway, and containerized deployments, plus a demonstration of their optimization tool that can evaluate 10,000 product iterations in 5 minutes, enabling rapid decision-making in early product development stages.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Industry Trends Reshaping Product Engineering: Connectivity, Complexity, and Cost Pressures
Good afternoon everybody. I hope everybody is having fun at re:Invent. I'm extremely excited to be here and share the stage with Axel, who will come here shortly to talk about how Whirlpool is democratizing virtual product development with AWS. Before Axel comes in, I will take a few minutes to talk about what AWS is doing in the product development, simulation, and product engineering space, and how we are helping our customers transform their product engineering landscape.
If you look at the industry trends from a product engineering perspective, there are three major trends that are right now impacting the industry. The first one is that most industrial manufacturing companies and discrete manufacturing companies are no longer just manufacturing or designing traditional discrete products that are disconnected. These days, all these products are connected and smart, which means you are not just selling a product, but you are selling a product and a service with it because these are connected products.
Second, because these are connected products, the entire engineering landscape is becoming increasingly complex. What I mean by that is you are no longer just doing mechanical design or electrical design or electronics design, but you are also doing a lot of embedded software design and looking at connectivity as well. Hence, the entire engineering landscape is becoming very complex, and that leads to longer lead times to design and engineer new products.
Third, and last but not the least, given that the market is so competitive, there is a lot of pressure to reduce your cost of developing a new product. You really want to make sure that to be competitive, you are continuously focused on optimizing your cost, not just to develop the product, but also to optimize your cost of quality. This is what every single customer I talk to every single day is going through these three trends.
AWS Solutions for Breaking Down Silos in CAD, CAE, PLM, and EDA Systems
So what does this mean and how is AWS helping our customers solve some of this and accelerate their journey? From an AWS perspective, we offer 200 plus services across multiple use cases. From a product engineering perspective, if you look at these four boxes across CAD, CAE, PLM, and EDA, typically what you would see in any manufacturing customer is that these are very disconnected, siloed systems. What AWS is doing with customers is to really help bridge that gap so that you are no longer disconnected, but you are unlocking your data silos by leveraging AWS to not just migrate these different applications and platforms to AWS, but also modernize them because that is where you start unlocking real value in terms of faster time to market and reducing the total time it takes to design new products.
More importantly, once you start leveraging AWS as a platform to design new products, you can start using a lot of AWS generative AI capabilities. For example, you can start using Bedrock as a platform to build new generative AI applications, which could be around digital threads and digital twins, and I could go on and on. So why AWS? What makes AWS so unique and different in this space? It really starts with the fact that if you are designing new products and if you are in the simulation space, you need flexibility to really scale up and scale down your infrastructure. Because as you are testing new products, doing performance testing, and doing load testing, you need that flexibility. You may not need high infrastructure across all twelve months in a year. You may need it for two months, but for those two months to be able to scale up, do all the testing, and then scale down so that you are not incurring unnecessary cost is what makes AWS so unique.
Second, once you are leveraging AWS for your product development, you have access to a lot of AWS unique capabilities across HPC and AI/ML. You can really start leveraging the power of the data which you have now unlocked and start using that data to build more and more additional capabilities and additional use cases. Third, it is really about the fact that AWS offers you so many different options in terms of how you can configure your infrastructure.
This really gives you more flexibility in terms of various ways you can optimize your cost to run your simulation scenarios and engineering scenarios. And last but not least, it really helps you unlock your data silos, because at the end of it, data is what helps you do more modernization, more transformation, and really makes you unique in the market.
Whirlpool's Journey: Democratizing Virtual Product Development with Machine Learning
With that, I would request Axel to come in and talk about the Whirlpool story. Thank you. I believe I'm audible to everyone. Thumbs up. Good, thank you. Thanks everyone for being here for the opportunity to be here and share a little bit about our story, our journey in terms of virtual product development, the way we democratize the knowledge within models so that you can expedite product development with excellence.
This is a brief agenda on what we are going to talk about today. There will be an introduction to the company. Then we are going to delve into one of the categories, refrigeration. We're going to talk about how we create the right architecture for an appliance, in this case a refrigerator, in terms of purpose, scope, scoping, and implementation. We are going to delve into virtual simulation capabilities and system requirements. How do we do that in a virtual world in order to expedite this whole process.
Solution space exploration is the way that we obtain the data using simulation so that we can use that data to produce machine learning models and do optimizations up front. The core of this talk is going to be the cloud architecture diagrams and then a video demonstration to wrap everything up. At the end, we'll discuss the benefits.
About Whirlpool, Whirlpool is a leading home appliance company in constant pursuit of improving life at home. Those are our iconic brands, as you can see: Whirlpool itself, KitchenAid, Jennaire, Maytag, Amana, Brastemp, and Insinkerator with iconic products such as built-in refrigerators, wall ovens, dishwashers, fully automatic coffee makers, and espresso machines. In terms of value, last year we reported 17 billion in annual sales or revenue, and we have around 44,000 employees across the globe with around 40 manufacturing plus product development and technology research centers.
Building the Foundation: Systems Engineering and Simulation Model Validation Framework
In terms of purpose, scope, and implementation, the challenge is that it's very hard to get the translation of system optimization in terms of system level requirements and to really harmonize all those requirements and deliver an emergent type of appliance that is best in terms of performance, which translates into the least cost and the best performance. Traditional methods are fragmented. We could do this manually without surrogate models, without machine learning, without Six Sigma, but there will be suboptimal solutions being delivered based on that, and therefore the company is going to lose because that's not a winning architecture.
The what here is a multi-objective or multi-criteria type of optimization framework across multiple requirements. I have energy, capacity, cooling robustness, noise, vibration, harshness, and also structural manufacturing simulations. I'm going to go into more details in the next slide. The how involves a lot of systems engineering, model-based systems engineering, and design for Six Sigma because we want to have a robust architecture. How can we be resilient and robust in terms of the architecture definition? That's the foundation and the core that we have, even for strategic sampling plans.
We use the FSS approach here with validated simulation models. I'm going to show what validation stands for, which is different from verification, a very important concept. Surrogate modeling is essentially an equation or a regression model that's based on simulation work. The last two bullets are about how to expedite this whole process in terms of model fitting and training plus tuning within AWS SageMaker, and last but not least, how to democratize this using AWS Elastic Beanstalk.
This is not data governance medallion type of governance. This is the way that we assess the maturity or fidelity of simulation models. First of all, we have developed developmental models where we are trying to understand if something can be simulated. Can I do fluid dynamics and airflow distribution inside a refrigerator? Yes, we can. Can I simulate taste and odor from ice and water? Maybe not using specific software. There are a lot of talks about intractable physics as well. They are deemed to not be simulatable. So we have this distinction. Whenever we pass this gate and determine that this is simulatable, we have the right assets in terms of software to do that.
So what we're going to do is create the models, starting with the bronze layer, which is directional. From a simulation perspective, we're creating a well-crafted simulation in computer software. We run a sensitivity analysis, which means we're playing with different design parameters while following physics. If you change the thickness from A to B, the stiffness will change, and the deflection will change for a fully supported beam, for instance. It follows first principles of physics.
The next layer is the silver layer, which is quantifiable. Quantifiable is a bridge to get into the validated stage. I'm saying this because from the quantifiable stage onward, we're socializing the simulation models with physical test data. We collect a lot of data from physical testing in order to cross-pollinate that data back to the simulation models, update the simulation models, and then see if there's a good degree of accuracy. However, the quantifiable stage is for a limited inference space. It's not for all the architecture or all the product variants. We get one or a couple of product families and we do this quantifiable checking.
When you reach the validation stage, it's for all the architectures and all the underlying complexity of our systems or appliances. This is not only for the sake of delivering this, but for the sake of obtaining good accuracy as per our rules. We need to pass this threshold in terms of accuracy between simulation and physical tests to have a match with good accuracy. We must also have high agreement with all the affected stakeholders for this process because validation is about making the right things from a systems engineering standpoint. What's the right thing here? Simulation must replace physical test. That's the ground rule.
Multi-Objective Optimization: Balancing Energy, Capacity, Robustness, and Cost in Refrigerator Design
Simulation is good enough to replace physical testing, and if you do that, everything is going to flow naturally because we can create our own data proactively. I no longer need physical testing, and I can use some strategic sampling plans to really allow us to expedite the construction of machine learning models up front. I'm going to talk about multiple requirements here and how we crafted this whole inference space that's multi-objective. This is pretty much translated to multiple response variables, or big Ys, that we call at the system level or voice of engineering.
The first one is as simple as internal capacity. You measure the volume inside those enclosed liners or the interior compartments of the fridge and freezer. In a refrigerator like this side-by-side model, we have on the left-hand side the freezer and there's a vertical divider that, by the way, you can vary the position, which is a design parameter. On the right-hand side, we have the refrigerator compartment. The model has to deliver and show exactly that the measured capacity is matching the physical measurement. That's a validation for this, and while it's very trivial, it's very useful because it makes the difference in the trade space whenever you want to understand how you can boost internal capacity and deliver energy and other response variables accordingly.
The next one is an intertwined connection between the coefficient of performance from a refrigeration circuit standpoint. In this ratio about performance, we have the design of an evaporator versus all the heat gain that must be taken out from the system. Heat gains are formed and composed by a lot of insulation walls, the presence of what we call vacuum insulated panels, and the footprint or size of the product. All of this affects the heat gain. Energy is pretty much how we orchestrate the system in order to remove that heat and deliver food freshness with the right temperatures and so on to the system. It's an intertwined connection between heat gain and energy because heat gain makes a contribution to the energy equation.
This point is very important. Heat gain quantifies how much heat enters into the system, while energy quantifies how much work the system performs to remove it. There's a balance here. Moving forward, heat gain is not only about the construction of the product itself in terms of wall thicknesses. We have some insulation layers inside those A, B, C, and D walls, which is polyethane foaming, that's what we have in terms of insulation in the product. So the product dimensions matter, but on top of that, we also have the type of blowing agents and the formulation of the foam that goes inside this enclosed volume. We can either use cyclopentane or HFO. What's the difference? One is more efficient than the other. HFO is more efficient, about 30 percent more than cyclopentane, but it costs more.
It's all about the entrapment of those gases into this kind of cellular structure from the foaming. This is what gives HFO such a lower thermal conductivity and therefore better insulation performance. Additionally, the way we pack the foaming matters. The underlying process allows us to have a single port foam, where we inject the foaming from the bottom deck of the product and the foam grows to the top, or multi-port, where we inject foam from several ports in the product.
Last but not least, there's the presence of VIPs, which stands for vacuum insulated panels. We use these to boost the insulation in some walls where we need very thin walls so that we can increase capacity. However, as you might guess, this comes with a cost. VIPs are likely to be ten times more efficient in terms of insulation than regular foaming, so you can see the benefit, but they are expensive.
Now, moving to more details about the energy itself from a system level perspective, let's talk about heat gain. There's a physical test that we use to validate the heat gain model called reverse heat leak. That's the way we collect physical test data to validate the simulation model through this reverse heat leak test. Heat gain is one of the input variables for energy. On top of that, the second part is the COP ratio from a refrigeration standpoint. We have control boards and software with control logic. We can have multiple types of compressors, which are the heart of the system. We can have multiple fan motors to deliver temperature distribution so that we can deliver food freshness in a very stratified way to both compartments. And last but not least, we have heat exchangers, in this case the condenser. Think about all the different types of components and all the different parameters that we can take into account from a control logic perspective. All of those things together deliver the system level performance.
One very important requirement is that we can deliver capacity at the right energy consumption. It can be Energy Star compliant, but we cannot penalize what we call robustness. I don't want external sweating on the walls. I always want to have a positive delta between the surface temperature and the dew point, otherwise there will be external sweating, as you can see in that picture from a water dispensing portion. Imagine if that's happening in your house—you don't want that. Robustness is very important. There are other robustness requirements from a refrigeration standpoint like frost formation or internal condensation. External condensation is one of the biggest challenges for us.
Of course, this cannot be ignored. We always want to minimize it. You can have a lot of VIPs everywhere, but can we pay for that? Can we make this product competitive? That's always a challenge. So we have the cost of insulation and the cost of cooling components. We call this compounding costs, which is the sum of both of them as the architecture cost. The architecture cost must be minimized with a given weight in terms of penalizing the objective functions so that we can optimize the whole system.
Moving forward, there are other things that we are working on that can also be taken into account for the model. We want internal distribution for the airflow, right, air delivery to the product or airflow management. There's structural stiffness. Imagine your product is fully loaded with a lot of food storage on the door beams. The cabinet should be withstanding all that load without any distortion so that you don't lose insulation and the gaskets can compensate. There will be some trade-off in the heat gain that's going to affect energy. Everything is connected here.
And then there's NVH, which is noise, vibration, and harshness—both airborne and structural borne noises. There's foaming simulation. As you can see in this picture, this is a single port foaming injection through the bottom deck of the product as an example. That's a simulation model. We want to pack the whole foam in. If you have very thin walls, the foam is going to be very obstructed to go smoothly, and therefore there's going to be a trade in terms of filling. This is going to create some kind of internal voids, and therefore there's likely to be external condensation. Everything is traded and intertwined here.
And then there's packaging. We want to deliver products to the customers without damages from transportation or handling. There are a lot of voice of engineering or system level requirements that must be harmonized. They are highly dependent on several response variables or several input variables. This is the trade space of input variables. This is real. This is exactly what we've been doing more recently.
Whirlpool Tester Recommender: Tackling 5.5 Trillion Combinations with Orthogonal Arrays and Genetic Algorithms
We've done more recently with one product using this type of approach. We have 134 factors with two levels. What is that? I can have thickness with thickness A and thickness B, two levels for that factor, or the presence of a vacuum insulated panel, foaming or VIPs. That is like a two-level setting for factors, but I don't have only one or two, which makes four runs overall. I have 34 factors. There are 3 factors with 4 levels: control boards, condensing systems, or type of foaming properties. In one factor with five levels, if we try to account for all the possible combinations, we are talking about 55, 55 times more than all the stars in the galaxy, 5.5 trillion combinations. It's a lot. Can we handle this even with HPCs or high-performance computing? It's not something we can handle. That's why we come up with this kind of approach which is called Whirlpool Tester Recommender, founded on or grounded in Six Sigma, where we use a design of experiments approach or Taguchi arrays.
It's an application that is running in AWS using Elastic Beanstalk where we have R and Python at the back end. You have this type of test recommender so that there are two questions that we need to answer and it is going to come up with the right recipe that we have to start with in terms of priority. Why is that important? Orthogonal arrays. Because this is the most efficient way of collecting the data in a pairwise, balanced, and independent way in the trade space. Undoubtedly, that's the best way to collect the data. You can do space-filling design, random sampling, whatever, but this is still the best way because it's fully balanced and orthogonal. That means there are no correlations across the input variables, no collinearity issues.
What's pairwise here? One level setting for any given factor will at least be crossed with all the level settings for all the other factors in pairwise combinations. It's going to cover the whole trade space. There are some techniques that we use here in order to have the initial coded design. We do some wrangling on that, some automatic techniques that we have embedded to this approach here, and we come up with what we call an initial encoded array. We use that to fit the machine learning model.
As a machine learning learner, what we normally do is use a lot of regression models. We start with the most simple model because this is an orthogonal array. I can use linear regression because multicollinearity is not affecting us a lot. Even though I have this holdout sample from the test set, we start with linear regression in this case. If the model is not good enough in terms of accuracy for the cross-validation of the training set, we do what we call augmentation. We run more runs that are easier to run. Energy runs take seconds to run or one minute to run. An energy run, I can produce thousands of runs in a few hours. Heat gain models take hours to run. So I can do augmentation on the energy side and rely on the groundwork given the orthogonal arrays for the heat gain runs. That's the data augmentation if needed.
I can tell you that I still didn't see a sampling plan using this technique that was surpassing 1000 runs. Compare 1000 versus 5.5 trillion. It's covering the inference space. It's allowing us to do the CI/CD for the model, checking the accuracy of the model with accuracies above 95% for all those response variables. Efficient data sampling reduces the manageable design space into a tractable and effective data set used to train machine learning models. We make this tractable to run.
Once we have all those models in place, we can now do inferencing. We can do predictions using those machine learning models because they passed all those safeguards in terms of accuracy for the held-out set, which is the test set, but also they were optimized for the cross-validated training set. Now they are available to run what we call optimization. Optimization is a very effective and efficient type of approach here that is based on multi-objective genetic algorithms. You can see multi-objective. The MOG here, multi-objective is because we have energy cost, capacity, cooling, and robustness. There are multiple response variables to be tackled here.
Those are the key steps we have in place: constrained population generation. That's the first step. What is that? Not all the runs are feasible. Some runs inherently are not going to survive from the beginning to collect the data. Sometimes I cannot even calculate the energy because I'm not delivering the minimum temperature that must be delivered to the product. So those runs are eliminated. Those are voids that we have in the data set itself.
There are some other linear constraints we have in this data set. For example, if there's a marketing requirement, the wall thicknesses from both sides must be the same, or door flushiness. I can have a door depth from the freezer as a parameter which is different from the door depth from the refrigerator. If you look at the product, you can see a lack of flushiness. Is this something desirable from a market standpoint? No. So we had a lot of linear constraints or variable linkages here. That's what makes the constrained population generation. We only generate the population for whatever is feasible.
Step number two is performance prediction. Remember, before we had all those machine learning models that were working well with a good degree of accuracy, and now they can be used to pick out that initial sampling and do inferencing, calculate the predicted results. Step number three is evolutionary selection. Think about the way it works in genetics. If we have a gradient descent, it's going to very likely give you a local optimum. Why? Because it's all about the way you start collecting the data. It's going to converge to a local optimum, but you don't know whether there are some other optimums in your infinite space that could be further explored.
This is addressed with this approach here because genetic algorithms are going to exploit locally and explore away from the infinite space on other portions of the parameter space. Exploiting is an analogy for crossover. Exploring is an analogy for mutations. That's why they are called genetic algorithms because of this inherent nature to exploit and explore, and do this several times until you find something that's really delivering what it takes to converge from a Pareto front perspective with the best balance across all those desired outputs with a given set of weights or importance.
That's a way to penalize the objective function by setting up some weights. Because cost can be more important than capacity depending on the marketing needs, you can always balance that with a given set of weights. When you get that, you have the final weighted composite score that we use to define the best solutions. So again, feasible runs, do the inferencing for that initial population, do crossover mutations, find the optimum from a well-balanced perspective here.
Cloud Architecture Deep Dive: Serverless Model Training, Tuning, and Deployment on AWS
Now I'm going to go into details about the diagrams here. This is a very important thing to talk about. How we do that in AWS. I'm going to spend a few more minutes here on this one to go into exactly the details of this structure. Think about that. The first element you see right there is an API gateway, very modular. There's an API call that can be used in any applications we have in production. Using Elastic Beanstalk, you can consume this diagram in terms of an API call so that we can use this to do optimizations or model fitting or tuning here. This is fully orchestrated by API gateways and Lambda. That means it's a serverless approach, right? You can use as needed with zero overhead, very modular.
One core element, as you can see, is the piece that's called ECR there. Look at that. It's all the way to the right-hand side. It's an Elastic Container Registry with a container image. That's taking into account an entry point from the container. Of course, within the ECR there's a Dockerfile, a requirements.txt, and a dynamic loader. Why am I not using here a prepacked training job from SageMaker container? Because they are limited to either scikit-learn or deep learning. I want all of them plus optimization. So that's what it takes to build a customized container for this approach because it's going to fulfill all the needs for this workflow here, right?
You can see that's an S3 bucket pointing to the ECR image there. It's a dynamic loader. That S3 bucket contains a file that's called Training that routes all the instantiations for the SageMaker training jobs within the entry point that belongs to this ECR.
Therefore, it will subsidize the Lambda to trigger the SageMaker training as needed. After the Lambda is triggered, there is a key indicator that you can see in yellow color: the operation type. This is an environmental variable within the Lambda function that orchestrates the whole system and can distinguish whether it will perform model training or model tuning, as you can see on the top flowing through model training and at the bottom flowing to model tuning.
If the user at the front end clicks on model training, it will orchestrate the Lambda by parsing all those parameters and the ECR with the container image to trigger the SageMaker job so that we fit the models and create pickle files for the model fitting itself. We want this to be front-loaded because we do not want the user to experience model fitting when opening the application, as it would take considerable time. Very importantly, there is another file within this model training called Shapley for model explainability, because it is part of the application to have explainable AI. Years ago, we used to say that neural networks and models were black boxes, but Shapley values came to rescue us in terms of AI explainability.
When I say Shapley values, I am talking about feature importance and partial dependence plots that show the direction of change. If you change from thickness A to B, what will be the heat gain impact? You can see all those explainable AI graphs in these two files that you can see in the top right corner in the output S3 bucket for training. Now talking about model tuning, we can trigger Optuna, which is the library I use to train all those models and to do genetic algorithms, the same algorithms we use to create the optimum architecture and for hyperparameter tuning as well.
This is a way to instantiate different design factors and hyperparameters for a given model. There is a bucket that points to the tuning process containing all the tuning configurations in a JSON file that takes into account whether it is deep learning, the number of neurons from the first layer, the number of neurons from the second layer, whether there is dropout, whether we have batch normalization, and many others like the learning rate. All those things are going to be taken into this model tuning standpoint, and the tuning itself will create the best balance in terms of tuning results as a pickle file in the bottom S3 bucket.
Once the tuning is processed and done, the user can see on the application exactly the test set accuracy. If the user is satisfied with that, they can click the button to train the model. Then we are going to front-load the model training file plus the explainable AI file that we call Shapley creation pickle file. This is pretty much the architecture for this backend for doing all these orchestrations. I know that is quite complex, but this is very useful and flexible. You call it, consume it, and it does a job on demand. You are going to call SageMaker to do the job, and you can pick whatever instance within SageMaker as you want.
If it is deep learning, you are going to require a more powerful computing instance. There are eleven or twelve different regressors in this approach. I have CatBoost, I have deep learning, I have XGBoost, I have Kriging or Gaussian process regression, support vector machine, and everything is there prepacked. You can add more by simply changing the S3 bucket for the training code. It is just a matter of adding more, and whenever you add more because it is an S3 bucket with versioning, you are going to see that this API is going to reflect that accordingly. That is the beauty of this flexibility.
Before I show the video, I want to explain a little bit. We showed the whole diagram for the training and tuning process in a modular way with this dynamic loader for the container itself. But how about the front end application, which is serverless and uses Elastic Beanstalk? It is a Beanstalk app which runs within a VPC, a virtual private cloud, which can only be accessed through a VPN if you are using it remotely. It takes into account what we call auto-scaling and load balancer.
This is deployed using a Docker container. If you remember from the previous slide, the output from the model training becomes the input for this diagram. As you can see in the bucket at the bottom, the trained models and the Shapley creation outputs from the previous slide become inputs for this Elastic Beanstalk application because they will be consumed by the Beanstalk application front end. Additionally, because there is a lot of explainable AI and exploratory data analysis in the front-end application, we have the data and app resources.
App resources is very interesting here. When you deploy an Elastic Beanstalk application using a container, you need just three files: an application file, a Docker file, and a requirements.txt file. These are the necessary files to deploy a Beanstalk application very easily. The app.py file is one of those three files that are zipped and used to deploy the Beanstalk application. It orchestrates all the calls for the data and app resources. This is like a microservice architecture that we have in the S3 bucket with all those packages, and they can be dynamically called from the app.py file that resides within Beanstalk and orchestrates the entire front end.
This means that if we change any files within the S3 bucket, your Beanstalk application at the front end will see that change. If you restart the Beanstalk, that is all you need to do. You do not need to redeploy. Just restart the server, because whenever you restart, it will retrieve whatever is new in S3.
So we have a private VPC hosted application with an internal load balancer, auto-scaling EC2 instances, and application code. The data and trained model artifacts are stored in S3, as you can see in this top S3 bucket. This is Docker-based because we want this to be prevalent and truly containerized for the sake of functionality in a robust way. That is the front end of this Elastic Beanstalk application.
Results and Impact: 70% Efficiency Gains in Model Training and 95% Faster Architecture Definition
Now I am going to showcase a video that will give you some practical insights on how everything we discussed here was wrapped up and put together to deliver an optimal architecture. Our strategy is to continually improve our products. We are now showcasing our innovative in-house multi-physics optimization workflow, which seamlessly integrates Virtual Product Development and artificial intelligence. Our advanced model incorporates more than 50 design factors to identify optimal combinations across multiple key performance metrics, including energy, capacity, robustness, and cost. It enables smart trade-off decisions among these often competing factors, ensuring balanced and optimal solutions. This powerful yet user-friendly engineering tool allows for real-time adjustments to various parameters, such as product dimensions, height, depth, and width, insulation wall thicknesses, vacuum insulated panels, mullion position, compressor type, and many more, with real-time predictions. We can also run optimizations by setting appropriate targets and weights for all requirements and establishing constraints on the input variables. For instance, 10,000 product iterations within the design optimization loop can be completed in approximately 5 minutes. With this cutting-edge technology, we can significantly accelerate our decision-making process in the early stages of product development.
Innovation is always in constant pursuit of improving life at home. I hope it was useful to see exactly how we encompass all those different ways that we can visualize the data from an exploratory data analysis standpoint. Another way to check how machine learning models make sense is not only by looking at the accuracy from a cross-validated training set, but also at the accuracy of the test set itself and whether the models are delivering what they must be delivering to you. How do we do that?
When you look at the correlogram, if there's a correlation between one response variable and one x variable, and you see that's a more pronounced effect in the explainable AI partial dependence plot, that means this is making sense. The model is giving you the partial dependence plots based on the Shapley values that were created upfront from the architectural diagram. The raw data is also giving the same signal to you, so we normally look at that.
Correlations across the axes are not a big deal for deep learning, but they may turn into a big deal for linear regression. We always look at the exploratory data analysis part with correlograms and parallel coordinate plots, histograms with the actual model results. We use a two-layer approach: exploratory data analysis plus explainable AI, and also some other layers for prediction and inference from a prediction standpoint. Last but not least is design optimization.
Design optimization takes into account the genetic algorithm. You're going to set up a lot of different weights across all the response variables. You can select which variables you want to optimize. For example, if you don't want to optimize heat gain because heat gain is an input for energy, we can have this election about not caring about heat gain and not optimizing it, but caring a lot about energy. We can either optimize to minimize, maximize, or reach a given target.
For internal capacity, we want to be very strict to the target. We want that given capacity with such a very high weight, so we're going to force the genetic algorithm to really explore because it takes more emphasis into account, more weight. For robustness regarding external condensation, we don't want to have external condensation, but we want to have at least a delta from the surface temperature to the dew point that's one degree or greater. So it can be greater than the target, straight to the target, do not optimize, maximize, or minimize.
You can select exactly which factors at their respective levels that you want to optimize. There was a study that was done where we didn't want to optimize the product with vacuum insulated panels. We just unflagged them because they are categorical variables with discrete level settings. We just unflag them and force the exploration space to only look at what you want. This is fully democratized and deployed as a stock solution available to use across the enterprise.
For Whirlpool as an AWS SageMaker user, we estimated up to 70% efficiency in terms of model training and tuning time, with much better effectiveness in terms of model training and tuning, such a modular architecture that can be consumed in any applications. Because you can pick whatever instance makes sense to you, you can expedite a lot, even very complex machine learning models like deep learning ones. We see up to 70% benefit for model training and tuning time and up to 95% for architecture definition.
Imagine doing all this massive work manually. Try to come up with a sequential approach to multiple design of experiments with only a few levels set and try to incrementally do all this exploration and come up with an optimal solution. If you don't do the right algorithm, you're going to converge to a local optimum that's going to be suboptimal. With this approach, you can explore and exploit and converge with the right emphasis or weight for whatever makes sense in terms of desirability for your design.
This is giving us a lot of leverage in terms of effectiveness and efficiency for product development. That's what it takes to really define a winning architecture. Because from a systems level perspective, architecture drives behavior. If you have the right architecture, everything is going to flow naturally. It's going to be more resilient. Your life cycle or digital thread is going to be more sustainable upfront.
With that being said, that ends the presentation. I thank you so much for being here to listen to us today, and I appreciate that we can have some offline conversations. We are more than glad to really answer any questions that you may have.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)