Machine Learning Basics

Machine learning (ML) is a branch of artificial intelligence in which software learns patterns from data instead of relying entirely on rules written by developers. A trained model can use those patterns to classify inputs, predict values, rank alternatives, detect anomalies, or support automated decisions.

For software engineers, machine learning introduces a different development model: behavior depends not only on application code but also on training data, features, model parameters, evaluation metrics, and production feedback. Understanding these pieces is essential before integrating ML into a reliable software system.

Table of Contents

• How Machine Learning Works
  • Features, Labels, and Predictions
  • Training and Inference
• Main Types of Machine Learning
  • Supervised Learning
  • Unsupervised Learning
  • Reinforcement Learning
• Common Machine Learning Tasks
• From Data to a Trained Model
  • Training, Validation, and Test Data
  • Underfitting and Overfitting
• Evaluating Model Quality
• Machine Learning in Production
  • Online and Batch Inference
  • Data and Model Drift
• When Machine Learning Is the Right Tool
• Conclusion
  • More Articles to Read

How Machine Learning Works

Traditional software converts explicitly written rules into output. Machine learning instead uses examples to estimate a function that maps inputs to useful outputs.

Consider delivery-time estimation. A manually implemented system might use fixed rules based on distance:

def estimate_delivery_hours(distance_km: float) -> float:
    if distance_km < 100:
        return 6

    if distance_km < 500:
        return 24

    return 72

This implementation is predictable and easy to understand, but it ignores many factors that influence actual delivery time.

A machine-learning model could instead learn from historical deliveries using distance, carrier, warehouse, destination, dispatch time, package type, weather conditions, and other signals. The relationship between those inputs and delivery duration is discovered from data.

Features, Labels, and Predictions

Features are values supplied to a model. They describe the information available when a prediction is made.

For delivery estimation, features might include:

{
  "distance_km": 315,
  "carrier": "carrier_a",
  "package_weight_kg": 4.2,
  "dispatch_hour": 14,
  "destination_region": "central_texas"
}

During supervised training, each example also contains a label or target: the correct value that the model should learn to predict. If the package actually arrived after 19.7 hours, that duration becomes the training label.

After training, new features are passed to the model and it produces a prediction:

{
  "estimated_delivery_hours": 20.4
}

The difference between the predicted and actual result becomes one way to measure model error.

Training and Inference

Training is the process of adjusting a model based on data. An optimization algorithm repeatedly evaluates predictions, measures their error with a loss function, and changes model parameters to reduce that error.

Inference uses the trained model without changing its parameters. A production service supplies new input and receives a prediction.

The two phases have different system requirements. Training may process terabytes of data over hours using distributed CPU or GPU infrastructure, while online inference may need to return a prediction within 50 milliseconds.

This separation also means that deploying application code and deploying a model are different operations. A production system should be able to identify which model version generated each prediction.

Main Types of Machine Learning

Machine-learning techniques are commonly grouped according to the information available during learning. The three major categories are supervised, unsupervised, and reinforcement learning.

Supervised Learning

Supervised learning trains a model using examples where the desired output is already known.

A fraud dataset might contain transaction features together with a historical outcome:

Transaction features → Known fraud outcome → Model training

Common supervised-learning tasks include spam detection, credit-risk prediction, delivery-time estimation, image classification, demand forecasting, and customer-churn prediction.

Supervised learning works well when enough representative labeled data exists. The difficult part is often obtaining reliable labels. Incorrect, inconsistent, or biased labels teach the model the wrong behavior regardless of the algorithm used.

Unsupervised Learning

Unsupervised learning operates without known target labels. Instead, the model identifies structure or relationships inside the data.

Clustering is a common example. An e-commerce platform could group customers according to purchasing behavior without defining the groups beforehand.

A clustering algorithm might discover that customers A and C behave similarly even though no developer explicitly created a rule connecting them.

Other applications include anomaly detection, dimensionality reduction, pattern discovery, and representation learning.

Reinforcement Learning

Reinforcement learning trains an agent through interactions with an environment. Actions produce rewards or penalties, and the system learns a strategy that attempts to maximize long-term reward.

This approach is useful when decisions influence future states rather than producing only an immediate prediction. Examples include robotics, game-playing systems, resource allocation, and some optimization problems.

Reinforcement learning can be difficult to deploy safely because experimentation itself affects the environment. A strategy that learns through trial and error is acceptable in a simulation but potentially dangerous when actions involve real money, infrastructure, or customers.

Common Machine Learning Tasks

The learning category describes how a model learns, while the task describes what the model is expected to produce. Several tasks appear repeatedly in production systems.

Classification does not have to return only a category. Production systems often benefit from probabilities:

{
  "fraud": 0.91,
  "legitimate": 0.09
}

Application logic can then define thresholds based on business cost. A payment platform might block extremely high-risk transactions while sending uncertain cases to manual review.

This is an important separation of responsibilities: the model estimates; the application decides what to do with the estimate.

From Data to a Trained Model

Model quality depends heavily on the data pipeline. Selecting an advanced algorithm does not compensate for missing, incorrect, leaked, or unrepresentative training data.

A typical supervised-learning dataset can be represented as rows of features and labels:

Data preparation may include removing invalid records, handling missing values, normalizing numerical values, encoding categories, constructing useful features, and preventing information unavailable at inference time from entering training.

The last issue is known as data leakage. For example, including the actual delivery timestamp as a feature when training a delivery-time predictor would make evaluation appear excellent while producing a model that cannot operate on real shipments.

Training, Validation, and Test Data

Evaluating a model on the same examples used for training does not show whether it can generalize to new data. Datasets are therefore commonly separated into training, validation, and test portions.

• Training data is used to adjust model parameters.
• Validation data helps compare models, tune hyperparameters, and select configurations.
• Test data provides a final evaluation using data that was not used to optimize the model.

The split must respect the structure of the problem. Randomly splitting every dataset is not always correct.

For a delivery model intended to predict future shipments, a time-based split can provide a more realistic evaluation: train on older deliveries and test on newer ones. Otherwise, closely related historical records may leak information across the split and make performance appear better than it will be in production.

Underfitting and Overfitting

Underfitting occurs when a model is too limited to capture useful patterns. It performs poorly even on training data.

Overfitting occurs when a model learns training examples too specifically and fails to generalize to unseen data. Training performance may look excellent while validation and production performance remain poor.

A model that memorizes historical fraud cases, for example, is less useful than one that learns characteristics that generalize to new fraudulent behavior.

Common controls include regularization, simpler models, more representative training data, early stopping, data augmentation, and careful validation. The correct response depends on why generalization is failing.

Evaluating Model Quality

A single metric rarely describes whether a model is useful. The appropriate evaluation depends on the business consequences of different errors.

For binary classification, four outcomes are possible: true positive, true negative, false positive, and false negative. From these values, metrics such as precision and recall can be calculated.

Precision answers: when the model predicts a positive result, how often is it correct?

Recall answers: of all actual positive cases, how many did the model find?

Consider fraud detection. Aggressively flagging transactions may increase recall because more fraud is detected, but it may reduce precision because more legitimate transactions are incorrectly blocked.

The correct balance is determined by business impact. Missing a fraudulent payment and blocking a legitimate customer have different costs.

Regression models use different metrics, such as mean absolute error or root mean squared error. Ranking systems may use metrics designed to measure whether relevant candidates appear near the top.

Model metrics should ultimately connect to application outcomes. Improving an offline accuracy score from 94% to 95% has little value if latency doubles, infrastructure cost triples, or the additional accuracy does not improve a meaningful product metric.

Machine Learning in Production

A notebook that successfully trains a model is far from a complete production system. Production ML requires data pipelines, reproducible training, model versioning, deployment mechanisms, inference infrastructure, observability, and a way to detect when model behavior degrades.

Every prediction should be traceable to the model version and relevant input version or feature definition when the domain requires debugging or auditability.

Online and Batch Inference

Online inference generates predictions during a request. Fraud detection during payment authorization is an example because the application needs the result immediately.

Online inference creates a latency-sensitive dependency:

from dataclasses import dataclass


@dataclass
class FraudResult:
    probability: float
    model_version: str


def evaluate_transaction(transaction: dict) -> FraudResult:
    prediction = fraud_model.predict(
        transaction,
        timeout_seconds=1,
    )

    return FraudResult(
        probability=prediction.probability,
        model_version=prediction.model_version,
    )

The model service now participates in the request's latency and availability budget. Timeouts, concurrency limits, fallback behavior, and capacity planning become necessary.

Batch inference processes many records asynchronously. A recommendation system might calculate product recommendations for millions of customers overnight and store the results for fast retrieval.

Batch processing can provide higher throughput and lower cost because predictions can be grouped efficiently. The trade-off is freshness: stored predictions may become stale between runs.

The choice should follow the product requirement rather than an assumption that machine learning must operate in real time.

Data and Model Drift

Production data changes. Customer behavior evolves, new products appear, fraud strategies change, carriers modify delivery networks, and application workflows introduce new traffic patterns.

Data drift occurs when the distribution of production inputs changes relative to the data used for training. Concept drift occurs when the relationship between inputs and the desired output changes.

A delivery model trained before a carrier restructures its network may continue running successfully while its prediction quality gradually deteriorates. CPU utilization and HTTP error rate will not reveal the problem.

Monitoring therefore needs both infrastructure and model signals. Useful metrics can include:

• Inference latency. Track p50, p95, and p99 latency for model-serving requests.
• Error and timeout rate. Detect serving failures and capacity problems.
• Feature distributions. Compare production inputs with expected ranges and training distributions.
• Prediction distributions. Detect unexpected shifts in scores or classes.
• Model quality. Measure accuracy, precision, recall, prediction error, or domain-specific metrics once actual outcomes become available.
• Business outcomes. Monitor metrics such as fraud loss, recommendation conversion, or delivery-estimate error.

Retraining should not automatically happen merely because time has passed. A safer pipeline detects degradation, evaluates a candidate model against existing baselines, and promotes it only when acceptance criteria are satisfied.

When Machine Learning Is the Right Tool

Machine learning is valuable when useful behavior is difficult to express as explicit rules but can be learned from sufficient representative data. Classification, prediction, ranking, language understanding, computer vision, and anomaly detection frequently fit this pattern.

It is usually a poor choice when the requirement is already deterministic. Calculating sales tax from defined rules, checking whether an email field is present, enforcing an authorization policy, or retrieving an account by ID does not become better merely because a model is involved.

ML also introduces operational costs that ordinary business logic may avoid: collecting training data, maintaining features, evaluating models, serving inference, monitoring drift, retraining, and debugging probabilistic behavior.

A useful engineering question is therefore not simply Can machine learning solve this? It is Does learned behavior provide enough value to justify the additional uncertainty and operational complexity?

Modern deep-learning systems extend these principles using large neural networks capable of learning complex representations directly from data. Neural Networks and Deep Learning explains how those models work and why they became the foundation of modern generative AI.

Conclusion

Machine learning replaces some explicitly programmed behavior with patterns learned from data. Features become model inputs, training adjusts model parameters, inference produces predictions, and evaluation measures whether those predictions generalize to unseen cases.

Production success depends on much more than model accuracy. Data quality, realistic evaluation, latency, availability, versioning, drift detection, and business impact all matter. The model should remain one controlled component inside a larger deterministic software system, with application code responsible for business rules, validation, authorization, and failure handling.

More Articles to Read

• Artificial Intelligence Basics
• Neural Networks and Deep Learning
• Large Language Models (LLMs)
• AI Model Training and Fine-Tuning