GreenAirOps delivers production-ready MLOps for real-time air quality prediction

Air pollution kills millions of people every year, yet most of the machine learning models designed to forecast it never leave the laboratory. A team of researchers in India has now built a complete, production-ready machine learning operations system—dubbed GreenAirOps—that predicts the Air Quality Index in near real time while solving the engineering problems that cause most predictive models to fail outside academic settings. The system, described in the journal Air Quality, Atmosphere & Health, combines ensemble machine learning with an end-to-end pipeline covering data versioning, experiment tracking, automated retraining, containerized deployment, and model rollback. Its authors argue that closing the gap between model development and operational deployment is just as important as improving raw predictive accuracy.

The Air Quality Index is the number most people see on weather apps and public dashboards, condensing concentrations of pollutants such as fine particulate matter into a single health-risk value. Accurate forecasting of this index underpins public health advisories, hospital resource planning, industrial emission controls, and long-term urban planning. But translating complex pollutant data into a dependable real-time forecast is notoriously difficult. Sensor networks report at irregular intervals and suffer from missing entries. Pollutant concentrations behave in strongly non-linear and non-stationary ways, shaped by weather systems, daily and seasonal cycles, and sudden events such as fires or industrial accidents. Production systems, moreover, must guarantee traceability, reproducibility, and fault tolerance—requirements that academic studies routinely ignore when they report headline accuracy figures computed on static historical datasets.

The team, led by Sahil Goyal, Vaibhav Sharma, Vivek Hotchandani, Girish Mahale, Mayur Gaikwad, and Aniket K. Shahade of Symbiosis Institute of Technology and the Symbiosis Centre for Applied Artificial Intelligence in Pune, identified three recurring failure modes in the existing literature. First, reproducibility tends to be poor because researchers work without uniform datasets, preprocessing routines, or computing environments. Second, operational robustness is lacking: most published models omit basic features such as automated retries, health checks, and fallback data sources. Third, lifecycle management is nearly absent—few systems provide automated retraining, validation gates, or version control as models age and incoming data distributions drift. GreenAirOps was designed from the ground up to address all three gaps simultaneously, pairing high-performance tree-based models with a comprehensive MLOps stack built from widely adopted open-source tools.

At the heart of the predictive engine is an ensemble that blends two efficient learners: Random Forest and XGBoost. Tree-based regressors were chosen because they capture the non-linear relationships between pollutant concentrations and meteorological variables while remaining fast enough for low-latency inference. The ensemble combines the two models’ outputs through a weighted average, with weights optimized to minimize validation mean absolute error and mean squared error, either by grid search or through stacked generalization using a linear regression meta-learner. Training is handled by a dedicated script that pulls hyperparameters, cross-validation settings, and random seeds from a configuration file, ensuring that any experiment can be rerun exactly. To avoid the subtle data leakage that plagues time-series modeling, the team uses an 80/20 time-based split or a time-aware rolling-window cross-validation scheme, along with stratified sampling by AQI category so that rare but critical severe-pollution events are adequately represented.

The data layer draws on multiple sources through modular, provider-specific connectors that poll third-party APIs at set intervals. Meteorological parameters arrive via the OpenWeather API, while pollutant concentrations come from IQAir. Each connector writes structured records—with city identifiers, geographic coordinates, timestamps, temperature, humidity, wind speed and direction, pressure, precipitation, and pollutant levels—into a staging store governed by a rigid schema. The connectors incorporate production-grade resilience patterns: rate limiting for API requests, exponential backoff for failure recovery, jitter to prevent synchronized retries, and short-term caching with a five-minute time-to-live to conserve API quota. When a primary source fails, the system falls back to alternate providers or flags records as incomplete, triggering imputation downstream. Every raw ingestion artifact is version-controlled, allowing any training dataset to be traced precisely to its origin.

Preprocessing and feature engineering are performed as fully deterministic operations. Timestamps are standardized to a central format with datatype validation; short temporal gaps of minutes to hours are filled by forward filling and linear interpolation, while anomalies are caught through domain constraints—such as capping pollutant values at physical limits—and statistical outlier detection based on interquartile ranges. Feature construction includes calendar-derived temporal features (hour, day of week, month, season), lagged and rolling statistics of PM2.5 and PM10 concentrations spanning up to 24 hours, interaction terms such as temperature multiplied by humidity, and decomposition of wind into U and V vector components for accurate directional representation. Crucially, every scaler, transformer, and imputer is saved as a versioned artifact alongside the trained model, guaranteeing that inference-time preprocessing is identical to training-time preprocessing and preventing the data skew that quietly degrades many deployed models.

Evaluation follows standard regression practice, using mean absolute error, root mean squared error, and the coefficient of determination, complemented by AQI category-specific bias analysis and prediction interval calibration. The system was validated across multiple urban environments with contrasting pollution profiles, including Vancouver, which registered an AQI of 65 in the “Moderate” category, and Beijing, which reached an AQI of 210 in the “Very Unhealthy” band, alongside Tokyo and New York. Every evaluation artifact—tables, figures, error histograms, and per-city performance breakdowns—is linked to experiment-tracking records, enabling transparent comparison of candidate models against the incumbent. Promotion policies require minimum performance thresholds and explicitly prohibit promotions that would increase class-imputed bias, ensuring that a new model cannot replace a working production model merely because it performs well on average.

The operational backbone is what distinguishes GreenAirOps from the many published AQI predictors that never run in production. Data Version Control handles versioning of datasets, model files, and pipeline configurations, with a lock file, experiment run identifiers, and Git commit hashes recorded at every model promotion so that any production model can be reconstructed exactly from the repository and remote storage. MLflow aggregates metrics, parameters, and artifacts for every training run and serves as the authoritative model registry, tracking whether each version sits in staging, production, or archived status. The prediction service itself is a FastAPI application exposing a prediction endpoint that accepts JSON input and returns AQI values, health categories, and confidence levels, plus a health-check endpoint. Models and preprocessing steps load into memory at startup, predictions are computed in small batches for low latency, and container images are preloaded with model artifacts to minimize cold-start delays.

Deployment relies on multi-stage Docker builds that separate build dependencies from runtime dependencies, keeping final images lean and containing only application code and model artifacts. Docker Compose orchestrates integrated testing of the API, the MLflow tracking server, and optional frontend components. For production, tagged images are pushed to AWS Elastic Container Registry and deployed on Elastic Compute Cloud, with rollout updates that retain previous versions for rapid rollback. GitHub Actions workflows automate linting, unit testing, container builds, and security scanning on every pull request; merges to the main branch trigger image builds and registry uploads. Automated retraining runs on a nightly schedule or upon detection of new versioned data, executing as isolated jobs that retrieve the latest data, train candidate models, evaluate them against performance guardrails and fairness constraints, and conditionally promote them—logging every promotion decision for auditability and regulatory compliance.

The authors are candid about the system’s limitations. Its dependence on third-party APIs means rate limits and outages can affect data freshness, though fallback providers and caching mitigate this. Training data comes primarily from public monitoring stations, so performance may degrade in regions with sparse sensor coverage or unusual pollution sources; transfer learning across geographies is a proposed remedy. Sudden, unanticipated events such as wildfires and industrial accidents can still produce forecast errors, and the team suggests integrating satellite-derived data and additional sensor modalities in future work. Planned extensions also include stronger drift detection, automated model selection, satellite and mobility signals, and evaluation of cost-latency trade-offs in edge and federated deployments for resource-constrained settings. For now, GreenAirOps stands as a demonstration that operational excellence—reproducibility, resilience, monitoring, and automated lifecycle management—can be engineered alongside predictive performance, offering a template for how environmental machine learning research might finally reach the dashboards, alerts, and health advisories where it matters most.