Apply for AI Grants India

Why SVM can help Bihar’s litchi growers

Litchi production in Bihar is highly sensitive to weather during flowering, fruit set, irrigation, and harvest. A useful forecast can help growers, aggregators, processors, and government programmes plan labour, cold storage, transport, procurement, and market supply. Support Vector Regression (SVR)—the regression version of Support Vector Machines (SVM)—is a practical starting point when datasets are relatively small but contain several interacting variables.

The objective should be defined before choosing a model. You might predict yield per hectare, total orchard output, or district-level production. Yield per hectare is often the most useful target because total production also depends on planted area. If you are designing a wider forecasting system, pair this project with guidance on implementing scalable ML pipelines for predictive analytics.

Define the prediction unit and target

Choose one consistent observation, such as an orchard-season, block-season, or district-season record. Mixing these levels creates misleading results. For each record, specify:

• Target: tonnes per hectare, kilograms per tree, or total tonnes.
• Forecast date: before flowering, after fruit set, or several weeks before harvest.
• Geography: district, block, village, or GPS-linked orchard.
• Season: year and, where relevant, cultivar and orchard age.

A production forecast should be operationally useful. For example, a forecast issued after fruit set can include observed weather and irrigation data, while an early-season forecast may need to rely more heavily on historical climate and orchard characteristics.

Assemble Bihar-specific data

Build a data dictionary before collecting records. Useful features include:

• Historical litchi yield and production, ideally from the same orchards or administrative units over multiple seasons.
• Temperature, rainfall, humidity, wind, sunshine, and heat or cold-stress indicators during flowering and fruit development.
• Irrigation frequency, water availability, fertiliser use, pruning, pest management, cultivar, tree age, spacing, and orchard density.
• Soil texture, pH, organic carbon, drainage, and nutrient measurements.
• Satellite or geospatial indicators such as vegetation indices, orchard area, elevation, and distance to water sources.
• Harvest timing, crop damage, disease incidence, and the share of fruit meeting market-grade standards.

For Bihar, local variation matters. Muzaffarpur and neighbouring litchi-growing areas may not share the same soil, irrigation access, or microclimate. Keep district and block identifiers, but avoid using an identifier as a shortcut for the target. Data from the Directorate of Horticulture, Bihar, agricultural universities, IMD or other validated weather sources, remote sensing platforms, and carefully designed field surveys can be combined—but record the source and measurement period for every variable.

Clean and prepare the dataset

Agricultural data is rarely ready for modelling. Start with a quality review:

• Standardise units, dates, district names, and area measurements.
• Check whether “missing” means zero, not measured, or not applicable.
• Investigate impossible values such as negative rainfall or yields that exceed plausible orchard capacity.
• Keep a log of corrections rather than silently deleting records.
• Aggregate weather into agronomically meaningful windows, such as rainfall in the 30 days before flowering or mean temperature during fruit development.

SVR is sensitive to feature scale. Use a pipeline that imputes missing numeric values and standardises features before fitting the model. Do not calculate scaling parameters on the full dataset: that leaks information from the test period into training.

Categorical variables such as cultivar or irrigation type can be one-hot encoded. If the dataset is small, avoid creating hundreds of sparse variables. Feature selection should be guided by agronomy and cross-validation, not by repeatedly testing the test set.

Use a time-aware validation strategy

A random 80/20 split can make performance look better than it will be in practice because neighbouring orchards or future weather patterns may appear in both sets. For seasonal forecasting, train on earlier years and test on later years. With enough observations, use rolling validation—for example, train on 2018–2021, validate on 2022, then train on 2018–2022 and validate on 2023.

If records come from many orchards, also consider a group-based split that keeps each orchard in only one fold. This tests whether the model generalises to new farms rather than memorising repeated orchard histories. Report the number of seasons, locations, and observations in every split.

Train an SVR model in Python

The following example assumes one row per orchard-season and a numeric target called yield_t_ha. Replace the feature names with columns that actually exist in your dataset.

import pandas as pd

from sklearn.compose import ColumnTransformer
from sklearn.impute import SimpleImputer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.svm import SVR
from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score

train = pd.read_csv("litchi_train.csv")
test = pd.read_csv("litchi_test.csv")  # later season or held-out orchards

target = "yield_t_ha"
numeric = ["rain_flowering_mm", "mean_temp_fruit_c", "humidity_pct",
           "soil_ph", "irrigation_events", "tree_age_years"]
categorical = ["district", "cultivar", "irrigation_type"]

preprocess = ColumnTransformer([
    ("num", Pipeline([
        ("impute", SimpleImputer(strategy="median")),
        ("scale", StandardScaler())
    ]), numeric),
    ("cat", Pipeline([
        ("impute", SimpleImputer(strategy="most_frequent")),
        ("encode", OneHotEncoder(handle_unknown="ignore"))
    ]), categorical)
])

model = Pipeline([
    ("preprocess", preprocess),
    ("svr", SVR(kernel="rbf", C=10, epsilon=0.1, gamma="scale"))
])

model.fit(train[numeric + categorical], train[target])
pred = model.predict(test[numeric + categorical])

mae = mean_absolute_error(test[target], pred)
rmse = mean_squared_error(test[target], pred) ** 0.5
print({"MAE_t_ha": mae, "RMSE_t_ha": rmse,
        "R2": r2_score(test[target], pred)})

The RBF kernel can represent nonlinear relationships, but its settings must be tuned. Use GridSearchCV or RandomizedSearchCV inside the training data with time-aware folds. Tune C, epsilon, and gamma; do not tune against the final test season. Compare SVR with a mean-yield baseline, linear regression, random forest, and gradient-boosted trees. A more complex model is not automatically a better forecast.

Evaluate forecasts for real decisions

Report MAE in tonnes per hectare because it is easy to interpret, and RMSE to expose large errors. Add percentage-based metrics only when yields are not close to zero. Examine errors by district, cultivar, orchard size, and season. A model with good average accuracy may still fail in drought years or underperform for smallholders.

Plot actual versus predicted yield and inspect the largest misses. Ask whether errors came from missing pest data, unusual weather, inaccurate production records, or a genuine limitation of the model. Use permutation importance or carefully applied explainability methods to understand patterns, but present them as associations—not proof that a variable caused higher yield.

For farm decisions, provide a range or scenario rather than a single precise number. For example, combine the forecast with optimistic, central, and adverse weather assumptions. Log the forecast date, model version, input data, and uncertainty so users can audit how a recommendation was produced.

Turn predictions into an agricultural workflow

A forecast becomes valuable when it changes an action. Possible uses include:

• Planning harvest labour, crates, packhouse capacity, cold storage, and transport.
• Identifying orchards that need field inspection or irrigation support.
• Estimating procurement volumes for farmer-producer organisations and processors.
• Scheduling market outreach without encouraging premature price commitments.
• Triggering alerts when expected output falls below a local threshold.

Keep a human agronomist or extension worker in the loop. Farmers should be able to challenge a forecast, report unusual field conditions, and understand what data influenced it. If the system communicates through local-language channels, review the design principles behind automated multilingual support systems, especially around translation quality, escalation, and record-keeping.

Common mistakes to avoid

• Using future harvest information in an early-season forecast.
• Randomly splitting repeated orchard observations across train and test sets.
• Scaling data before the validation split.
• Reporting only R² and hiding the error in tonnes per hectare.
• Treating district-level averages as precise farm-level predictions.
• Deploying without monitoring drift when weather, cultivars, or farming practices change.

As of 2026, the strongest implementation is usually a modest, well-documented model connected to reliable field data—not an opaque system built on a small spreadsheet. Start with one district or a small orchard network, establish a baseline, validate across seasons, and expand only after the forecasts improve a real planning decision.