The Prediction Pipeline: Start to Finish

An AI model picking an MLB game is not a single calculation. It is a multi-stage pipeline where raw data flows through a series of transformations, each one designed to extract a specific type of signal. Understanding this pipeline is essential to understanding what the model's output actually means and where its blind spots live.

The pipeline begins with data collection. Every pitch thrown, every ball put in play, every defensive shift, every bullpen usage pattern is recorded and stored. Modern baseball generates an enormous volume of structured data, far more than any human analyst could process in a lifetime. The model's first advantage is simply its ability to ingest all of this information simultaneously.

Stage 1: Data Ingestion and Cleaning

Raw baseball data is messy. Game logs contain inconsistencies, player IDs change across data providers, and statistical services occasionally report conflicting numbers for the same event. The first stage of any serious prediction pipeline is data cleaning, the mundane but critical work of standardizing formats, resolving conflicts, and filling gaps.

This stage is where many amateur models fail before they even start making predictions. A model trained on dirty data produces dirty outputs. If a player's handedness is mislabeled, every platoon-based feature derived from that data is wrong. If a game's weather data is missing and filled with a league average, the model loses a genuine informational signal about that specific contest.

Professional-grade pipelines include automated validation checks at this stage: cross-referencing box score totals against play-by-play records, verifying that game dates align with schedule data, confirming that roster transactions are reflected in lineup data. These checks catch errors before they propagate through the system.

Stage 2: Feature Construction

Raw stats are not fed directly into models. They are transformed into features, derived variables specifically designed to capture predictive signal. A pitcher's raw ERA is a fact. A pitcher's ERA minus their expected ERA based on quality of contact allowed, adjusted for park and defense, is a feature. The distinction matters because features strip away noise and isolate the components of performance most likely to persist into future games.

Feature construction is where domain expertise meets statistical methodology. Knowing that a pitcher's performance against left-handed batters in day games at altitude is meaningfully different from their overall numbers requires understanding the game. Encoding that knowledge into a computable feature requires understanding data science. The best models combine both.

Common feature categories include rolling performance windows (last 7, 15, 30 games), rest and travel indicators, matchup-specific metrics (pitcher vs. opposing lineup platoon splits), park adjustment factors, bullpen availability indices, and environmental conditions. Each feature is a hypothesis about what matters for predicting outcomes, and the model's job is to learn which hypotheses are correct.

Stage 3: Model Training

With features constructed, the model is trained on historical data. Training means adjusting the model's internal parameters to minimize prediction error on known outcomes. The model sees thousands of historical games with their associated features and results, and it learns the relationship between input features and outcomes.

The critical challenge during training is generalization. A model that perfectly memorizes historical results is useless because it cannot predict new games it has not seen before. Techniques like cross-validation, regularization, and early stopping help prevent this overfitting. The goal is not to explain the past perfectly but to extract patterns from the past that apply to the future.

Training also involves hyperparameter tuning: adjusting the model's structural settings (learning rate, tree depth, number of layers, dropout rates) to optimize out-of-sample performance. This is typically done through systematic search over parameter combinations, evaluated against held-out validation data that the model has never trained on.

Stage 4: Inference and Probability Generation

Once trained, the model is deployed to make predictions on new, unseen games. It receives the current game's feature set, including the starting pitcher matchup, recent team performance, rest and travel status, environmental conditions, and lineup composition, and outputs a probability estimate for each outcome.

The raw model output is typically a score or logit that needs to be calibrated into a true probability. Calibration ensures that when the model outputs 0.65, the corresponding outcome actually occurs approximately 65% of the time. Without calibration, the model's outputs are scores, not probabilities, and they cannot be interpreted directly as likelihoods.

Many models also produce uncertainty estimates alongside their point predictions. These estimates capture how confident the model is in its own prediction, distinct from the probability itself. A model might assign Team A a 60% win probability with high confidence (the signal is strong) or a 60% win probability with low confidence (the features are ambiguous and the prediction could easily shift with new information).

Stage 5: Output Validation

Before an AI pick is finalized, a well-designed system performs sanity checks on the output. Are the probabilities within expected ranges for this type of matchup? Is the model's prediction consistent with its recent calibration performance? Are there any data quality flags on the inputs used for this specific game?

Output validation is the last line of defense against pipeline errors. If a data feed delivers corrupted injury information and the model consequently assigns a team a 90% win probability that should be 55%, the validation layer should catch the anomaly and flag it before the pick is published.

This stage also includes comparison against market prices when available. A massive divergence between model probability and implied market probability is not necessarily wrong, but it warrants additional scrutiny. The market aggregates the information of thousands of participants, and consistent large disagreements with the market often indicate a model issue rather than a market inefficiency.

The Pipeline Is the Product

Understanding this pipeline reveals an important truth: the final probability number is only as good as the weakest link in the chain that produced it. A brilliant model architecture trained on corrupted data produces garbage. A clean dataset fed into a poorly tuned model produces mediocrity. Every stage matters, and the discipline to maintain quality at every stage, day after day and game after game, is what separates reliable AI predictions from unreliable ones.