Apply for AI Grants India

A crop-disease classifier is useful only when farmers, agronomists, or field workers can send a photo and receive a dependable result. That makes the AI plant disease detection backend code more than an upload endpoint: it must validate uncertain images, run inference consistently, return actionable metadata, and remain usable on unreliable networks.

This guide presents a production-oriented architecture with FastAPI and an image model exported for efficient serving. It also covers model versioning, confidence thresholds, privacy, monitoring, and deployment economics for Indian agriculture applications.

Define the prediction contract first

Before choosing a framework, define what the API promises. A useful response should separate the model’s prediction from agronomic advice, because a classifier is not automatically a treatment recommendation.

A practical POST /v1/predictions endpoint can accept:

• An image in JPEG, PNG, or WebP format.
• Optional crop, variety, location, language, and capture-stage metadata.
• A request or idempotency identifier for retries over weak connections.

Return:

• crop and disease labels.
• Top-k predictions with probabilities.
• A calibrated confidence value and an uncertain flag.
• model_version, preprocessing version, and request ID.
• A short next step, such as retaking the image or consulting an agronomist.

Do not present a low-confidence result as fact. If the leaf is blurred, poorly lit, occluded, or outside the model’s supported crops, return needs_review rather than inventing a diagnosis.

Recommended backend architecture

For most early and mid-stage products, use Python 3.11+, FastAPI, Pydantic, Pillow, and a dedicated inference runtime such as ONNX Runtime or TensorFlow Lite. Keep the API process responsible for authentication, validation, and orchestration; keep model execution isolated in a worker or inference service as traffic grows.

A clean layout might look like this:

app/
  main.py
  api/predictions.py
  schemas.py
  preprocessing.py
  inference.py
  settings.py
models/
  tomato_v3.onnx
  labels.json

This separation makes it possible to update preprocessing or models without rewriting the HTTP layer. Teams expecting rapid growth should also review guidance on scaling backend infrastructure for AI applications, particularly around queues, autoscaling, and GPU utilisation.

Load the model once, not per request

Model initialisation belongs in the application lifespan, not inside the route handler. Loading a model for every upload creates severe latency and memory overhead.

from contextlib import asynccontextmanager
from fastapi import FastAPI, File, HTTPException, UploadFile
from PIL import Image, UnidentifiedImageError
import io

class Predictor:
    def __init__(self, model_path: str, labels_path: str):
        self.session = load_onnx_session(model_path)
        self.labels = load_labels(labels_path)

    def predict(self, image):
        tensor = preprocess(image)
        scores = self.session.run(None, {"images": tensor})[0][0]
        return rank_predictions(scores, self.labels)

@asynccontextmanager
async def lifespan(app: FastAPI):
    app.state.predictor = Predictor("models/tomato_v3.onnx", "models/labels.json")
    yield

app = FastAPI(title="Crop Health API", lifespan=lifespan)

@app.post("/v1/predictions")
async def predict(file: UploadFile = File(...)):
    if file.content_type not in {"image/jpeg", "image/png", "image/webp"}:
        raise HTTPException(415, "Unsupported image type")

    data = await file.read()
    if len(data) > 8 * 1024 * 1024:
        raise HTTPException(413, "Image exceeds 8 MB limit")

    try:
        image = Image.open(io.BytesIO(data)).convert("RGB")
        image.verify()
        image = Image.open(io.BytesIO(data)).convert("RGB")
    except (UnidentifiedImageError, OSError):
        raise HTTPException(400, "Invalid image")

    predictions = app.state.predictor.predict(image)
    top = predictions[0]
    return {
        "status": "ok" if top["confidence"] >= 0.70 else "needs_review",
        "predictions": predictions[:3],
        "model_version": "tomato_v3",
    }

The example assumes load_onnx_session, preprocess, and rank_predictions are tested utilities. Avoid copying a framework-specific model-loading call without checking its actual API; for example, TensorFlow and PyTorch use different serialisation and inference patterns.

Make preprocessing identical to training

Many apparent “backend accuracy” problems are training-serving skew. Record and reproduce every transformation:

• Convert all images to RGB.
• Resize or centre-crop using the same strategy used during training.
• Apply the exact scale, mean, and standard deviation.
• Preserve the model’s expected tensor order, such as NCHW or NHWC.
• Reject images that are too dark, blurred, or dominated by background.

Test preprocessing with golden images whose expected tensor and prediction are version-controlled. Include field photos from different phones, lighting conditions, crop stages, and regions—not only clean PlantVillage-style images.

Confidence is not accuracy

Softmax scores can be overconfident. Calibrate thresholds on a field validation set and measure precision, recall, macro-F1, and per-class confusion. A product may need a higher threshold for recommending action than for flagging a possible issue.

Useful response states include:

• healthy: the model meets the healthy-class threshold.
• disease_detected: a supported disease passes validation.
• needs_review: confidence is low or the image is out of distribution.
• unsupported_crop: the crop is outside the model’s scope.

Store anonymised prediction events, model version, latency, and user feedback. Do not silently retrain from unverified farmer reports; label review and agronomist validation are essential.

Design for Indian connectivity and operations

A mobile client should compress images before upload, retain the original locally only when consent permits, and retry with exponential backoff. The API should support idempotency so a repeated request does not create duplicate records. For villages with intermittent connectivity, consider an on-device MobileNet or TensorFlow Lite model that synchronises uncertain cases when the network returns.

Keep advice localised by crop, state, language, and season, but source recommendations from qualified agronomists or approved agricultural institutions. A prediction API should not prescribe pesticide dosage without the required regulatory and agronomic context.

For bursty workloads, place inference behind a queue and return a job ID. For low-latency traffic, use a warm worker pool. Serverless containers can work for modest traffic, but cold starts and model size must be measured rather than assumed. Teams comparing deployment patterns can also examine serverless AI apps with Modal.

Security, privacy, and reliability checklist

• Verify file signatures, not just filename extensions or MIME headers.
• Enforce upload, decompression, request-rate, and timeout limits.
• Strip EXIF metadata unless location is explicitly required and consented.
• Encrypt data in transit and at rest; define retention and deletion policies.
• Authenticate partners and apply per-tenant quotas.
• Log request IDs without logging unnecessary farmer-identifying data.
• Add health, readiness, latency, queue-depth, and error-rate endpoints.
• Pin dependencies, scan containers, and keep model artefacts immutable.

If the product also contains recommendation or conversational workflows, keep those components separate from deterministic image inference. AI agent frameworks for developers in India can help with orchestration, but an agent should not override a model’s uncertainty or generate unsupported treatment claims.

Deployment and testing path

Start with a CPU container and a small, quantised model. Benchmark p50 and p95 latency, memory use, concurrent requests, and cost per 1,000 predictions. Move to GPU workers only when measurements justify it. Use a staging model registry, canary releases, and rollback by model version.

Your minimum test suite should include invalid files, oversized images, grayscale and RGBA inputs, adversarial filenames, timeouts, duplicate requests, and known field images. Run load tests with realistic image sizes. Monitor drift by crop, geography, device type, and season; a stable overall accuracy can hide failure for a specific farmer segment.

The strongest backend is not the one with the most elaborate model. It is the one that makes uncertainty visible, performs consistently in the field, protects user data, and gives the product team evidence for every model update.