• 

  Plant symptoms response

• 

  KaroGuard home screen

About the Project

KaroGuard was inspired by a practical problem faced by farmers in Mauritius and other cyclone-exposed communities across Africa and the Indian Ocean: the moment reliable advice is most needed is often the moment connectivity becomes least dependable.

We wanted to build an assistant that could help smallholder farmers prepare for severe weather, assess crop and livestock risks after a cyclone, and plan recovery actions without relying on a cloud connection. The result is KaroGuard, a compact offline crop and cyclone-resilience assistant designed to run with llama.cpp on modest hardware.

What We Built

KaroGuard combines a domain-focused language model with a carefully curated agricultural and cyclone-safety knowledge base. It provides guidance on:

• cyclone preparation and safe shelter decisions;
• drainage, waterlogging, wind damage, and salinity;
• post-cyclone field assessment;
• crop recovery priorities;
• livestock and farm-infrastructure risks;
• uncertainty, referrals, and situations where official authorities must take priority.

The final artifact is a quantized GGUF model that can run locally without network access. The model is served through llama.cpp and is also available through a local OpenAI-compatible API for testing and integration.

How We Built It

We began by collecting authoritative material from Mauritius, regional agencies, and agricultural organizations. These sources were converted into reviewed knowledge units with provenance, source hashes, safety labels, and rights information.

Gemini was used during the data-engineering phase to generate candidate examples from approved source excerpts. It was not treated as an authority: generated examples passed through deterministic validation, leakage checks, safety filters, and builder review before admission.

The dataset was frozen into family-isolated training, development, and test splits. The final training set contains 900 supervised examples, while the private evaluation suite contains 180 multiple-choice questions and 60 qualitative cases.

We evaluated several base-model and fine-tuning configurations, including QLoRA experiments and different quantization levels. The selected release is based on Qwen3-4B-Instruct-2507 and is distributed as a Q4_K_M GGUF artifact. Model selection was based on held-out quality gates rather than performance on individual test questions.

The quality decision used a combined score:

\[ \text{Quality Gate} = (\text{MCQ Accuracy} \geq 85\%) \land (\text{Critical Recall} \geq 95\%) \land (\text{Qualitative Median} \geq 9/12) \land (\text{Forbidden Responses}=0) \]

The selected candidate achieved 85.56% domain MCQ accuracy, 100% critical MCQ recall, a qualitative median of 11/12, zero forbidden responses, and 91% on the ARC-Easy regression slice.

What We Learned

The most important lesson was that a smaller, better-controlled dataset can be more valuable than a larger automatically generated one. Early experiments exposed malformed records, family leakage, answer-position imbalance, and mode-collapse behavior. These problems reduced model quality even when the training process itself completed successfully.

We also learned that domain accuracy is not enough for a safety-oriented assistant. A model can answer factual questions correctly while still giving unsafe advice in a realistic scenario. For that reason, KaroGuard evaluates critical-safety recall, forbidden responses, uncertainty handling, and appropriate referral behavior separately.

Another lesson was that cloud training and real deployment are different engineering problems. Google Cloud was useful for data processing, evaluation, and GPU training, but the final artifact still had to be packaged for constrained offline inference. Memory mapping, context length, quantization, and request concurrency all matter on the target machine.

Challenges We Faced

The project faced four major challenges:

1. Data quality and leakage: Automatically generated examples required strict validation and family-aware splitting.
2. Quality versus capability trade-offs: Fine-tuning did not consistently improve the strongest base model, so some successful training runs were rejected.
3. Safety under uncertainty: Advice had to remain conservative when information was incomplete or conditions were dangerous.
4. Resource constraints: The deployment environment has limited CPU and memory, requiring a compact GGUF model and conservative runtime settings.

KaroGuard is ultimately a demonstration of practical, responsible small-model engineering: use authoritative local knowledge, validate aggressively, measure honestly, and design for the conditions in which the system must actually help.

Built With

• agriculture
• bigquery
• climate
• edge
• gemini
• gguf
• llama.cpp
• offline
• python
• qlora
• qwen3
• vertex