Yield prediction (agriculture & production processes)

How much will this field, this region or this batch produce? Farmers, cooperatives, food processors, traders, insurers and agricultural agencies plan around harvest volumes that are only known at the end of the season. Plants plan around titers and line yields that are only known after the batch. Yield prediction combines remote sensing, weather, soil and management data (or process sensor data) with machine learning and, where available, mechanistic crop or process models. The result is an in-season forecast with an uncertainty band that improves as the season or batch goes on. The value comes from earlier, better-informed decisions on inputs, contracts, logistics and interventions, not from the model itself.

Problem & value

• Today (agriculture): farmers estimate from experience and field walks. Cooperatives and processors (sugar, potatoes, vegetables) run sample harvests. Agencies combine surveys, crop models and expert judgement. The EU's own MARS Crop Yield Forecasting System (MCYFS) has run since 1992 and combines satellite data, weather observations and forecasts, crop-growth modelling, statistics and expert knowledge. It publishes monthly national yield forecasts for the EU and its neighbourhood in the JRC MARS Bulletin [1].
• Today (production): plants learn the yield at the end of the batch or after final test.
• AI value: earlier and more granular forecasts (field or zone instead of country, mid-season instead of post-harvest). These support selling forward, contract volumes, harvest and transport logistics, input decisions (nitrogen, irrigation) and insurance/loss assessment. In production, forecasting the batch or lot outcome while it is still running allows corrective action or early scrapping.
• Evidence is mixed, not magic: in a peer-reviewed study for wheat, barley, sunflower, sugar beet and potatoes in NL, DE and FR, a generic ML baseline matched MCYFS early in the season for many crop–country pairs (e.g. NRMSE 8.21 vs. 8.79 for sugar beet in Germany). For others it was about twice as bad (e.g. soft wheat in Germany), and by the end of the season it was worse than MCYFS in DE and FR [2]. The JRC's own work on ML with small data reaches the same conclusion: the gains depend on the crop and the region [3]. Plan for the hybrid approach (crop model + ML + expert), not "AI replaces agronomy".

Variants

• Farm / field level (SMB): zone maps and in-season yield potential from satellite biomass inside farm-management software, used for variable-rate seeding and fertilising (with OPT-014).
• Contract farming & processors: sugar, potato, vegetable and wine processors forecast the delivery volume from contracted fields to plan factory campaigns and logistics.
• Regional / national (public sector): ministries, statistics offices and the EU JRC produce official crop forecasts. Development agencies run food-security early warning (see PRED-040).
• Commodity trading & finance: traders and banks build country-level supply forecasts (feeds PRED-008). Agricultural lenders and parametric/index insurers use yield models for risk and loss assessment (PRED-010, PRED-036).
• Grassland & greenhouse: forage yield (e.g. LINGRA model [5]) for dairy farms; greenhouse yield from climate-computer and camera data for sales commitments.
• Production processes: batch titer/yield prediction in bioprocessing and fermentation, chemical batch yield, food-line yield (trim, giveaway), and semiconductor die/wafer yield. Wafer-map pattern analytics belongs to VIS-056. Continuous quality prediction (soft sensors) belongs to PRED-014. Setpoint optimisation belongs to OPT-009.
• Private use: not sensible beyond free apps.
• Out of scope: breeding-value and variety performance prediction is a separate use case (SCI-020).

How it works

1. field boundaries + crop type/calendar (e.g. ESA WorldCereal)
2. satellite time series (Sentinel-2/HLS optical, Sentinel-1 SAR)
3. cloud masking
4. indices/embeddings
5. weather (observed + forecast/seasonal), soil, management data
6. features up to the forecast date (no look-ahead!)
7. model: crop simulation (WOFOST/PCSE) and/or ML (gradient boosting, TabPFN, temporal deep nets, EO foundation-model embeddings)
8. calibrated forecast + prediction interval, aggregated field
9. farm
10. region
11. agronomist/analyst review
12. update monthly/weekly until harvest
13. compare with actuals, retrain

• Ground truth is the bottleneck. You need regional yield statistics (Eurostat, national offices), combine yield-monitor maps (cleaned) or a processor's delivery records. Without several seasons of these, no model can be validated.
• Mechanistic vs. ML: crop models (WOFOST via PCSE [5]) encode physiology and extrapolate to unusual weather better. ML models learn local patterns and correct systematic bias. Common hybrids feed crop-model outputs into an ML model, or use ML to estimate crop-model parameters.
• Production variant: batch sensor trajectories + recipe + raw-material attributes → multivariate (PLS/MSPC) or gradient-boosting/time-series model → predicted end-of-batch yield + contributions. This runs in real time during the batch, with operator alerts (e.g. Sartorius SIMCA-online [11]).
• Human-in-the-loop: agronomists or process engineers review forecasts before they drive contracts, official statistics or batch decisions. Experts adjust forecasts after extreme events (hail, flooding) that the data has not captured yet.

Data preparation

Two data worlds meet here. Agricultural use needs satellite time series, weather, soil and crop maps, which are mostly public (Copernicus, AgERA5) and need no cleaning by the SMB itself. The hard part is your own ground truth: harvester yield maps, field boundaries, sowing dates, varieties and fertiliser records. In a farm or cooperative these live in farm-management software, machine terminals (ISOXML exports), Excel sheets, paper field books and the accountant's files. For production yield, the sources are the historian, MES, LIMS and ERP batch records.

Typical gaps: yield maps with sensor errors and outliers, field boundaries that changed, free-text crop names, missing sowing dates, batch data without a shared batch ID across systems, and several years of history that are too short.

Steps: collect and export the records (PREP-005), enter or digitise paper field books (PREP-006), unify crop and variety names (PREP-015), reconcile field and batch IDs, clean harvester outliers, and build a back-test set of past seasons (PREP-018). Tools: QGIS, Python (pandas, rasterio), Excel Power Query, or a farm-management export. Readiness: see GUIDE-003 and DATA-007.

Expect roughly half to two thirds of the total effort in data collection and cleaning; the model itself is the smaller part. Buying a platform (Path A) shifts much of this to the vendor, but you still deliver field boundaries and history.

Implementation paths

Which path for whom

• smb (farms, cooperatives, mid-size processors): A. Mature agri platforms with EU hosting sell field-level forecasts per hectare, and the process is standard.
• enterprise (traders, insurers, large plants): B. The forecast must flow into your own pricing, risk and planning systems, so you combine EO platforms and cloud ML with your own history.
• developer: C. Open data (Copernicus, ERA5) and open benchmarks such as CY-Bench make a self-hosted baseline cheap and transparent.
• public (agencies, ministries): C. Sovereignty, procurement rules and reuse of public EO data favour open-source models on sovereign EU or German cloud.

Path A — Buy (off-the-shelf) — recommended for farms, cooperatives, mid-size processors

• Farm-management & precision-ag platforms: xarvio FIELD MANAGER (BASF Digital Farming, DE), CLAAS connect (DE). Note that 365FarmNet will be discontinued on 30 Nov 2026 and its users are being moved to CLAAS connect [9]. Also John Deere Operations Center and Climate FieldView (Bayer), plus OneSoil (productivity zones, VRA maps, NDVI) [10]. These offer zone/biomass maps and yield data handling. Check whether they give a true yield forecast or only vegetation indices.
• Data & analytics providers: Planet Planetary Variables, e.g. daily 10 m Crop Biomass and 1 km Soil Water Content [8]. Regional and commodity forecasters serve traders and insurers. EU Copernicus-based service companies are listed in the Copernicus ecosystem registry [7].
• Production: Sartorius SIMCA / SIMCA-online for batch monitoring and outcome forecasting in bioprocesses [11]. PDF Solutions Exensio for semiconductor manufacturing analytics (ML-based escape prevention, predictive quality screening, data feed-forward) [12].
• Choose A when: you need field-level decisions, not your own forecasting product. Ask the vendor for validation results on your crops and region.

Path B — Build on cloud APIs / EO platforms

• Data access: the Copernicus Data Space Ecosystem gives free Sentinel data with STAC, openEO, Sentinel Hub APIs and hosted JupyterLab (EU-operated) [7]. Commercial imagery and biomass APIs come from Planet [8]. The ESA WorldCereal processing system and its 10 m global crop-type maps provide crop masks [6].
• Modelling: managed ML on EU cloud regions (Azure ML, Vertex AI, SageMaker in Frankfurt; STACKIT, OVHcloud, IONOS for EU-sovereign hosting) with gradient boosting or AutoML. Time-series foundation models with covariate support (Chronos-2, Apache-2.0 [14]) work for regional series-style forecasting.
• LLMs are only a reporting layer (forecast narrative), not the forecasting model.
• Choose B when: you are a cooperative, agency, insurer or trader building your own forecast across many fields or regions.

Path C — Self-host (open source)

• Data & processing: openEO (self-hostable), STAC tools, odc-stac/xarray, Sentinel-2 L2A with cloud masks.
• Models: LightGBM/XGBoost, and TabPFN v2 (Prior Labs GmbH, Freiburg). Newer TabPFN 2.5–3.5 weights are under non-commercial licences, so check terms before production use [13]. Also Chronos-2 for time series [14], and the PCSE/WOFOST and LINGRA crop models [5].
• Geospatial deep learning: TorchGeo (MIT, multispectral pretrained weights) [15]. Prithvi-EO-2.0 (IBM/NASA/Jülich, Apache-2.0, 300M–600M parameters, multi-temporal HLS input, with a crop segmentation fine-tuning example) [4].
• Reference code: JRC ml4cast-ml (regional yield forecasting from ASAP satellite and meteorological time series) [3]. CY-Bench with its cybench library and baselines [16].
• Hardware: HW1 (CPU server) is enough for tabular/GBM and crop-model pipelines at regional scale. HW2 (one 24–32 GB GPU) is needed for fine-tuning EO foundation models or running pixel-level deep nets over large areas. Storage and EO data handling usually cost more effort than compute.

Path D — Custom training

This path is worth it for agencies, large processors, insurers and agritech vendors with multi-year ground truth. Examples: fine-tune Prithvi-EO-2.0 or a temporal network on Sentinel time series, with your own field-level yields as labels. Or train hybrid crop-model + ML systems per crop and region. You need at least 5–10 seasons of regional statistics, or several thousand field-seasons of cleaned yield-monitor data, plus management records. For production yields, train per process family on hundreds of historical batches with complete sensor trajectories. Retrain every season, because varieties, climate and practices drift.

State of the art (2026)

• Benchmarks: CY-Bench (AgML/AgMIP, v1.0 2026) standardises subnational maize and wheat yield forecasting across the EU and 10+ other countries. Predictors are AgERA5 weather, GLDAS soil moisture, FAPAR, NDVI and WISE soil, with crop masks from ESA WorldCereal. Forecasts are made in-season and evaluated with NRMSE, MAPE and R² [16].
• Foundation models: EO foundation models (Prithvi-EO-2.0, TorchGeo-pretrained backbones) give strong embeddings with little labelled data [4][15]. Tabular foundation models (TabPFN) and time-series foundation models with covariates (Chronos-2, released Oct 2025) are serious baselines for small-data regional forecasting [13][14].
• Operational practice: official systems such as the JRC MARS MCYFS remain hybrid. Statistical and crop-model forecasts are reviewed by analysts, and AI/ML is being tested and phased in [1].
• Limits & failure modes: extreme years (drought, hail, flooding), which matter most, are rare in training data. Cloud cover gaps in optical imagery occur exactly in critical growth phases. Yield statistics are noisy and lag by a year. Harvester yield maps need heavy cleaning. Spatial and temporal leakage in validation makes many published accuracies too optimistic, so always validate leave-one-year-out. Models trained in one region transfer poorly to another.

Shared resources & combinations

• Same EO stack (remote-sensing + Sentinel pipeline + crop masks): VIS-021 satellite imagery analysis, VIS-005 crop health detection, OPT-014 irrigation & fertilisation optimisation, PRED-036 physical climate risk. One Copernicus/openEO data pipeline and one GPU (HW2) can serve all of them.
• Same weather inputs: PRED-017 AI weather forecasting supplies the forecast covariates. PRED-007 (renewables) uses the same weather/time-series infrastructure.
• Same tabular/time-series stack: PRED-001 demand forecasting (processors plan intake and sales from forecast yields), PRED-008 commodity price forecasting, PRED-010 insurance pricing, PRED-044 livestock and forage.
• Production side: PRED-014 soft sensors and HLTH-029 GMP batch review share the process historian and batch data. OPT-009 uses predicted yield as the objective for parameter optimisation. VIS-056 covers wafer-map defect patterns. PRED-006 predictive maintenance shares the sensor pipeline.
• Adjacent: ROBO-007 harvesting robots; SCI-020 genomic prediction (variety priors).

Effort, cost & KPIs

• Path A: days to weeks to onboard fields. Costs are typically per hectare or per farm subscription. Value depends on agronomic follow-up.
• Path B/C: 3–9 months for a first regional system. Most effort goes into collecting and cleaning ground truth, building the EO pipeline and back-testing over several past seasons. Running costs are low: Copernicus data is free and CPU/GBM models are cheap.
• Path D: 6–18 months with EO/ML and agronomy specialists.
• KPIs: forecast error (NRMSE, MAPE) vs. naive trend and vs. existing expert forecast, at each forecast date (early, mid and late season). Prediction-interval coverage. Bias in extreme years. Decision KPIs: contract volume accuracy, logistics cost, nitrogen use per tonne, and for production batches the scrap or rework avoided and early-abort accuracy.

People & change

Start with management (budget, goal) and the department lead (farm manager, plant manager) as process owners. Involve end users such as agronomists, farmers or process engineers from the first workshop, because their field knowledge defines the useful forecast. IT and the data owners (farm-management software, historian, ERP) clarify exports and access. Suppliers or contract farmers must agree if their data is used.

Works council: usually no, because the system forecasts crops or batches and does not monitor people. §87(1) no. 6 BetrVG becomes relevant only if operator IDs or shift data are in the dataset, or if results are used to assess staff. Even then, §90(1) no. 3 requires timely information when work processes are planned with AI. A company with an elected works council should simply inform it early. Public bodies involve the Personalrat.

Data protection: field data of individual farmers can be personal data. Check legal basis and an AVV with each platform vendor (GUIDE-005) and involve the DPO. AI literacy: support staff with a short training on forecast uncertainty, since the AI Act Art. 4 requires measures to support AI literacy (GUIDE-006).

Pilot with a few fields or one line for one season, compare forecast and outcome openly, and let experts override. Typical concern: "the model does not know my field". Answer it by showing back-tests and uncertainty bands, and keep the human decision on sowing, purchasing and sales. See GUIDE-009 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: minimal risk in the typical form. Yield forecasting is not an Annex III category, and a forecast of field or batch output is not a safety component under Annex I. AI-literacy duty (Art. 4) applies. It becomes high-risk only by downstream use: e.g. when the forecast is a main input to creditworthiness assessment of natural persons (a farmer as sole trader, Annex III 5(b)) or to risk assessment and pricing in life or health insurance. Crop insurance is not listed. Public bodies using forecasts to allocate subsidies or aid should check Annex III 5(a) [17].
• GDPR: satellite data on a field and yield maps of a family farm can be personal data, because the field is linked to an identifiable farmer (cadastral/IACS parcels). Use a legal basis, data processing agreements with platforms, and purpose limitation when cooperatives or lenders reuse data. Production data is usually not personal, except operator IDs in batch records.
• Data Act (Reg. (EU) 2023/2854, applicable since Sept 2025): farmers have a right to access and share the data their connected machines (tractors, combines) generate. This eases yield-map collection across brands [18].
• Sector rules: GMP (EU GMP Annex 11, data integrity) applies when yield predictions influence pharmaceutical batch decisions. Validate the model as a computerised system. Official statistics follow statistical quality codes. Never let a model replace the measured yield in reporting.
• Risks: overconfidence in extreme years (publish uncertainty), market sensitivity of national forecasts, vendor lock-in of farm data.

Getting started

1. Collect ground truth: at least 5 past seasons of yields per field or region (or 100+ batches for a process), with sowing dates and crop types.
2. Define the decision and forecast dates (e.g. contract volume at flowering, factory campaign plan one month before harvest) and a naive baseline (trend or last-3-years average).
3. Pilot a Path A platform on a subset of fields, or back-test an open baseline: CY-Bench or ml4cast-ml models on Copernicus data, validated leave-one-year-out [3][16].
4. Add weather forecasts and, where relevant, crop-model outputs (PCSE/WOFOST). Report forecasts with intervals.
5. Run in parallel with the expert forecast for one full season before relying on it.

Sources

1. European Commission JRC — Crop monitoring and yield forecasting (MARS, MCYFS, MARS Bulletin) — https://joint-research-centre.ec.europa.eu/scientific-activities/crop-monitoring-and-yield-forecasting_en
2. Paudel et al. (2021), Machine learning for large-scale crop yield forecasting, Agricultural Systems 187 — https://ideas.repec.org/a/eee/agisys/v187y2021ics0308521x20308775.html
3. EC JRC — ml4cast-ml: ML regional yield forecasting ("Yield forecasting with machine learning and small data: what gains for grains?") — https://github.com/ec-jrc/ml4cast-ml
4. IBM / NASA / Jülich — Prithvi-EO-2.0 model card — https://huggingface.co/ibm-nasa-geospatial/Prithvi-EO-2.0-600M
5. Wageningen — PCSE Python Crop Simulation Environment (WOFOST, LINGRA) — https://github.com/ajwdewit/pcse
6. ESA WorldCereal — global crop type & cropland maps and processing system — https://esa-worldcereal.org/en
7. Copernicus Data Space Ecosystem — https://dataspace.copernicus.eu/
8. Planet — Planetary Variables (Crop Biomass, Soil Water Content) — https://www.planet.com/products/planetary-variables/
9. 365FarmNet — discontinuation notice and migration to CLAAS connect — https://www.365farmnet.com/en/
10. OneSoil — precision-agriculture platform — https://www.onesoil.ai/en
11. Sartorius — SIMCA / SIMCA-online data analytics software — https://www.sartorius.com/en/products/process-analytical-technology/data-analytics-software
12. PDF Solutions — Exensio analytics platform — https://www.pdf.com/exensio/
13. Prior Labs — TabPFN (versions, limits, licences) — https://github.com/PriorLabs/TabPFN
14. Amazon Science — Chronos forecasting (Chronos-2) — https://github.com/amazon-science/chronos-forecasting
15. TorchGeo — https://github.com/torchgeo/torchgeo
16. WUR-AI / AgML — CY-Bench crop yield benchmark — https://github.com/WUR-AI/AgML-CY-Bench
17. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
18. Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj