Machine learning replaces some hand-written decision rules with patterns learned from data. Instead of programming every characteristic of an unwanted email, an engineer can train a model using examples of unwanted and legitimate messages. The resulting model estimates how a new message should be classified. Machine learning is part of artificial intelligence; deep learning is a subset of machine learning that uses multilayer neural networks. Generative AI commonly uses deep learning models to produce text, images, audio, or other content.
Training and inference are different activities. Training adjusts a model's parameters using data and an optimization process. Inference applies a trained model to new inputs, such as estimating delivery time for an order. A model does not necessarily keep learning when an application sends it requests. Updating its behavior generally requires a separate training, fine-tuning, or model-replacement process.
Different learning approaches suit different problems. Supervised learning uses examples with known answers, such as historical transactions labeled fraudulent or legitimate. Unsupervised learning finds structure in data without those target labels, such as grouping customers by purchasing behavior. Reinforcement learning learns action-selection behavior through rewards from interactions with an environment. Not every business problem needs machine learning: a deterministic rule is often simpler and more reliable when the required behavior is already well defined.
In the cloud, teams can rent compute for custom training, use managed model-development platforms, or call pretrained AI services through APIs. A custom demand-prediction model offers control over training data and evaluation but requires engineering and operational work. A managed document-extraction API can return text and form fields without requiring the application team to train its own recognition model. Managed infrastructure reduces server administration; it does not transfer responsibility for choosing an appropriate use case or validating results.
A practical workflow starts with defining a measurable objective, collecting authorized data, and preparing representative examples. Engineers separate training, validation, and test data so that evaluation measures performance on examples not used to fit the model. Data leakage, such as including information that would not exist when a real prediction is made, can create misleadingly high scores. Accuracy alone can also be misleading: a fraud model that labels every transaction legitimate may appear accurate when fraud is rare. Precision, recall, and the business cost of mistakes are often more useful.
Cloud deployment introduces trade-offs among latency, throughput, cost, and control. Real-time inference supports interactive applications but may incur charges for provisioned resources even during quiet periods. Batch inference is useful when results can wait, such as scoring a customer dataset overnight. Training costs depend on compute type, runtime, and experimentation, while API-based services commonly charge by usage units. Sensitive training data and inference inputs require access controls, encryption, and review of service-specific retention and data-use terms.
Production models need monitoring because input data and real-world relationships can change. Track prediction quality where outcomes become available, investigate performance differences across relevant populations, and define review or fallback paths for consequential decisions. A confidence score is not a guarantee of correctness. For AWS exam scenarios, distinguish custom model development with Amazon SageMaker AI from ready-made capabilities such as image analysis with Amazon Rekognition, language analysis with Amazon Comprehend, and access to foundation models through Amazon Bedrock.