Apply for AI Grants India

What this project should predict

Bareilly weather prediction using Hugging Face models is best treated as a supervised time-series forecasting problem, not a generic language-model task. Start with a narrow operational target and a defined forecast horizon:

• Next-hour or next-six-hour temperature and humidity
• Rain probability or rainfall amount over the next 6, 12, or 24 hours
• Maximum and minimum temperature for the next day
• Heat-index or wet-bulb-risk alerts during hot, humid periods
• Wind speed, pressure, and visibility forecasts for local operations

Bareilly’s forecast quality will depend less on choosing a fashionable model and more on station coverage, timestamp consistency, monsoon-season representation, and leakage-free testing. A model that performs well on average but misses intense rainfall or prolonged heat is not production-ready.

Build a Bareilly-specific dataset

Use several data sources, while recording the source and quality of every observation. IMD data should be your reference where access and licensing permit. Supplement it with nearby station observations, satellite or reanalysis products, and a reliable weather API for comparison. Reanalysis is useful for filling spatial gaps, but it should not be presented as equivalent to an observation from Bareilly.

Useful input columns include:

• Timestamp in UTC and India Standard Time, with daylight-saving assumptions avoided
• Temperature, relative humidity, dew point, surface pressure, wind speed, wind direction, and rainfall
• Cloud cover, visibility, solar radiation, and soil or surface variables when available
• Station latitude, longitude, elevation, sensor identifier, and missing-data flags
• Calendar features such as hour, day of year, month, and monsoon-season indicators

Keep a data dictionary and preserve raw files. Weather feeds are often revised, interrupted, or silently changed. Store ingestion time separately from observation time so that backtesting only uses information that would genuinely have been available at prediction time.

For a first version, use hourly data over multiple years and create a validation period containing at least one complete monsoon season. Bareilly’s seasonal shifts, pre-monsoon thunderstorms, winter fog, and heat waves make random row-level splits misleading.

Prepare features without leaking the future

Sort by observation time, remove duplicate records, standardise units, and inspect impossible values such as negative rainfall or humidity outside the 0–100% range. Do not automatically delete every extreme: severe weather is often the event the model must learn.

Create lagged and rolling features from past observations only. Examples include temperature three and six hours earlier, 24-hour rainfall totals, rolling pressure change, and recent humidity trend. Encode wind direction as sine and cosine components rather than treating degrees as a linear number. For cyclical time features, use sine and cosine transformations for hour and day of year.

Missing data needs explicit treatment. Short gaps may be interpolated for selected variables, while rainfall and event labels usually require more conservative handling. Add missingness indicators so the model can distinguish a measured zero from an absent observation. If you use multiple stations, include station identity and distances, then test whether the system still works when one station drops out.

Choose an appropriate Hugging Face model

BERT and GPT-2 are designed for text and are poor default choices for numeric weather sequences. Use a time-series architecture available through the Hugging Face Hub or integrate a compatible forecasting model with the Transformers ecosystem. Candidate approaches include:

• Transformer-based forecasting models for multivariate sequences and multiple horizons
• Patch-based time-series models that process windows of observations efficiently
• Probabilistic forecasting models that produce prediction intervals, not only point estimates
• A simple persistence, seasonal baseline, XGBoost, or linear model for comparison

Your input should be a numeric tensor or structured time-series window, not tokenised weather prose. A typical training example contains the previous 24–168 hourly observations and asks the model to forecast the next 6–24 hours. For rainfall, consider a two-stage setup: first predict whether rain occurs, then estimate amount conditional on rain. This handles the large number of zero-rain observations better than a single ordinary regression loss.

A practical environment might include:

pip install torch transformers datasets pandas numpy scikit-learn accelerate

The exact model and configuration depend on the checkpoint. Confirm its expected tensor shape, frequency, context length, target scaling, and supported prediction horizon before writing the training loop. Use AutoConfig and the model documentation rather than assuming a text-classification interface.

Train and evaluate honestly

Use chronological splits, for example:

• Training: earliest observations
• Validation: the following months, including a seasonal transition
• Test: the most recent untouched period

For robust results, add rolling-origin evaluation: repeatedly train on the past and forecast a future block. Report metrics by season, horizon, and event intensity. Useful measures include MAE and RMSE for temperature, mean absolute error for pressure and wind, Brier score or calibration error for rain probability, and precision-recall metrics for heavy-rain alerts.

Always compare against meaningful baselines. Persistence may be difficult to beat for very short temperature horizons; a seasonal average may be competitive for some variables. If the Transformer does not improve on these baselines, simplify the system or improve the data before increasing model size.

For rainfall and extreme events, report recall and false-alarm rates separately. A forecast that avoids false alarms by predicting no rain every time is operationally useless. Prediction intervals should also be checked for coverage: a nominal 90% interval should contain the observed value close to 90% of the time, subject to sampling variation.

Deploy the forecast service

Package preprocessing, scaling, model inference, and post-processing together so training and production use identical transformations. A FastAPI service can accept the latest observation window and return forecasts, timestamps, units, confidence intervals, and model version. Validate inputs and reject stale or incomplete windows rather than silently producing a forecast.

For a lightweight prototype, CPU inference may be sufficient. For scheduled batch forecasts, run a job every hour, save outputs to a database, and expose the latest forecast through an API or dashboard. If you need cloud deployment, compare the operational trade-offs in how to deploy ML models on AWS Lambda in India; for larger always-on workloads, a container platform may be more suitable. The deployment pattern should support logs, health checks, retry handling, and rollback to the last known-good model.

Monitor drift and communicate uncertainty

Monitor missingness, sensor ranges, feature distributions, inference latency, and forecast errors after observations arrive. Create separate alerting for data failure and model degradation. A model can appear healthy while receiving stale data.

Retrain on a schedule only after evaluating whether new data improves rolling-origin performance. Keep model versions and training datasets reproducible. For public users, show forecast time, valid time, units, source coverage, and uncertainty. Avoid presenting an experimental local model as an official warning system; cross-check high-impact alerts with authoritative India Meteorological Department guidance.

A weather system may eventually need edge or local inference. The engineering principles are similar to those used when deploying deep learning models on GKE, but the weather application adds strict timestamp, data-quality, and monitoring requirements. If your interface serves Hindi-speaking users, pair numerical forecasts with carefully reviewed translations; model deployment and language support are separate quality problems, as the discussion of open-source small language models for Hindi illustrates.

A sensible 2026 roadmap

Start with one station, hourly temperature and rain probability, and a strong baseline. Then add nearby stations, probabilistic outputs, radar or satellite features, and event-specific evaluation. Publish a reproducible data pipeline and a model card describing coverage, limitations, metrics, and failure cases.

The goal is not to claim perfect Bareilly forecasts. It is to build a measurable, auditable system that improves on simple baselines, exposes uncertainty, and remains useful when monsoon conditions, fog, heat, or sensor outages challenge the model.