A Local LLM and RAG Agronomy Assistant: PlantFarm AI Operator
Why an Assistant?
PlantFarm Scan produces a lot of numbers after each flight: which tree's NDRE dropped, how many trees are getting worse, where the ground looks different. The agronomist's real question is not a number, though: "What could be happening to this tree, and what should I check in the field?"
The AI Operator is the chat panel we added to answer that. It is not a general chatbot; it grounds its answer in two sources: the project's own measurements and curated walnut disease literature.
How It Works
When the user asks a question, the backend gives the model two things:
- Measurement context: the project's trend summary (counts of rising and falling trees, the 15 worst performers). If a tree is selected on the map, its full NDVI, NDRE and GCI series across all flights. This data is read from the same services the interface uses, so the number on screen and the number the model sees can never differ.
- Corpus passages: the literature is split into chunks and turned into vectors (embeddings). The 6 chunks closest in meaning to the question are added to the prompt. This is RAG (Retrieval-Augmented Generation).
The answer streams back; the user sees the first words within seconds.
Why a Local Model?
Farm data is commercially sensitive: the state of each orchard, yield estimates, parcel information. So we built the assistant to run in-house on Ollama:
| Component | Choice | Note |
|---|---|---|
| Chat model | Qwen3 4B | ~2.5 GB, runs on a single mid-range GPU |
| Embeddings | bge-m3 | Multilingual; Turkish and English sources in one index |
| Server | Ollama | Comes up with the application via Docker Compose |
On first setup the models (~3.7 GB) are pulled by a separate one-off service. The application does not wait for it; the map works immediately and the assistant panel shows a notice until the model is ready.
Pitfalls We Hit
Putting everything into the corpus
In the first attempt we also added a general pest guide covering every crop. The result: a question about walnuts was answered with an unrelated pest, a bramble mite, because the symptom description looked similar. In RAG, more documents does not mean better answers. Restricting the corpus to walnut-focused sources clearly improved accuracy.
The model's "thinking" output
Qwen3 can produce an internal monologue before answering. The obvious way to turn it off is sending think: false to the API; in the version we used, that wove the monologue into the answer instead of dropping it. Not sending the parameter and keeping the thinking block in its own field was the right fix. Details like this only surface in real user testing.
Reindexing time on an older GPU
Re-indexing the corpus takes minutes on an older-generation GPU. We added a hint to the interface so users do not keep pressing the button.
Applying It to Industry
The same structure works outside agriculture. In a factory, the measurement context could be sensor data from ZMA and GDT, and the corpus could be machine manuals and maintenance logs. When an operator asks "why did the load curve of press 3 change?", the assistant answers by looking at both the data and the manual.
Conclusion
A good RAG assistant depends less on a big model than on the right context: the model seeing the same numbers as the screen, and reading only relevant sources. For an assistant that works with your own data, see our Industrial AI solution.