Most AI demos are built for people who already know what AI is. They assume high-speed internet, a standard keyboard, and a user who will patiently read an onboarding screen. When I started building KrishiBot, I had to unlearn all of that.
The target user: a Bangladeshi farmer with a basic Android phone, unreliable mobile data, and a crop disease problem that's costing them money right now. Not next week. Today. The language they're most comfortable in isn't English — it's Bengali, often spoken more than written, and frequently mixed with agricultural terms that don't appear in standard NLP training data.
Building something genuinely useful for this person required rethinking almost every default assumption in the standard LLM application stack.
The language problem is not what you think it is
The obvious challenge with bilingual Bengali-English support is translation. But that's actually the easy part — LLMs handle Bengali reasonably well, especially for common conversational queries. The harder problem is how real users type.
Bangladeshis who are bilingual don't write Bengali in pure script. They write in a mixture of Bengali Unicode, Romanized Bengali (called Banglish — "ami tomake valobaashi" instead of "আমি তোমাকে ভালোবাসি"), and English technical terms. A farmer asking about crop disease might write: "amar dhaner pata te brown spot hoyeche, ki korbo?" — mixing Romanized Bengali with English agricultural terminology in the same sentence.
The solution I landed on was prompt engineering rather than fine-tuning. I structured the system prompt to explicitly instruct the model to accept queries in "Bengali, Romanized Bengali, English, or any mixture," and to respond in whichever language the question was asked in. For most agricultural Q&A tasks, a well-prompted Llama 3 8B handles this without a dedicated bilingual model — though the quality of Banglish responses is noticeably weaker than pure Bengali or pure English.
The honest answer is that a fine-tuned model on agricultural Banglish would be better. That requires a dataset I don't have. This is a known gap in the current system.
Crop disease detection: what "offline" actually costs you
The crop disease detection feature takes a photo of a plant and identifies the disease. This is a computer vision problem, and it's the part of KrishiBot where the offline constraint hurts most.
Cloud-based solutions like Google Vision or AWS Rekognition are fast, accurate, and require minimal setup. An offline model has to run on the device or on a local server, which on the target hardware means a small, quantized model with limited accuracy on edge cases.
I used a fine-tuned MobileNet variant for the image classification step — small enough to run on-device, accurate enough on the 38 plant diseases it was trained on. The catch: it was trained on PlantVillage, a dataset of clean, well-lit, isolated leaf photographs. Real field photos are dirty, partially occluded, shot at odd angles, and often include the background soil or neighboring plants.
My mitigation was to add confidence thresholds with explicit uncertainty messaging. When the model's confidence is below 70%, the UI doesn't show a single disease name — it shows the top 3 candidates with their confidence scores and recommends consulting a local agricultural extension officer. Better to show useful uncertainty than false confidence.
Making offline actually work
The offline requirement shaped everything. No API calls, no cloud fallback, no continuous connectivity assumption. The LLM backend runs on Ollama on a local device or shared community server. The image model runs in-app. All of this has to work when the nearest town with reliable 4G is 20 kilometers away.
The architecture that emerged: a FastAPI backend running on a low-cost shared server (could be a Raspberry Pi 5 or a cheap refurbished laptop in a village community center), the React Native app connecting over local WiFi or a local hotspot. The server handles LLM inference; the phone handles the camera and UI.
This model has real deployment friction — someone has to set up and maintain the local server. That's a solvable problem with the right community partners, but it's not a problem I can solve in code.
What I learned that surprised me
The hardest constraint wasn't technical. It was response length. When I first tested the chatbot with actual farmers in my network, the responses were too long. A 200-word explanation of bacterial leaf blight, its causes, treatment options, and prevention strategies — written in excellent Bengali — got scrolled past immediately. People wanted one sentence: "This is X disease. Spray Y. Stop watering for Z days."
I restructured the system prompt to produce a three-part response format: diagnosis, immediate action, prevention. Each part is 1-2 sentences maximum. Engagement with responses went up dramatically. The most technically impressive output is worthless if the user closes it before reading.
The gap between what impresses an ML engineer and what's useful to a farmer trying to save a crop is wider than you expect until you watch someone use your system for the first time.
Key takeaways
- Real users mix languages in ways that don't appear in benchmark datasets — design for that input
- Confidence thresholds with explicit uncertainty are more useful than confident wrong answers
- Distribution shift between training data and real-world photos is the biggest accuracy gap in vision models
- Response length and format matter as much as response quality — optimize for the moment of use
- Offline deployment shifts the hard problem from ML to logistics; someone has to maintain the server