AgbeTalk

Inspiration

Cloud-hosted AI is out of reach for a lot of the people who'd benefit from it most. A smallholder farmer in rural Nigeria, or an extension officer without reliable data access, can't lean on ChatGPT the way a Lagos tech worker can. Meanwhile, the actual knowledge needed to farm well correct fertilizer rates, planting spacing, pest management already exists in real extension-service documents from IITA, FAO, ICRISAT, and NAERLS. It's just locked in PDFs most farmers will never read. AgbeTalk exists to put that real, trustworthy knowledge in front of the person who needs it, on hardware they already own, with zero internet required.

What it does

AgbeTalk is a fully offline agricultural advisor. A farmer or extension officer asks a question in plain English "How much fertilizer do I need for maize?" and gets a specific, source-grounded answer retrieved from a real corpus of agricultural extension documents, not generated from the model's unverified internal knowledge. Every answer cites which document it came from. A Yoruba vocabulary toggle lets the system weave in common, validated Yoruba agricultural terms (àgbàdo for maize, ilẹ̀ for soil, ọ̀sẹ̀ for week) alongside the English answer. The whole system retrieval, generation, and interface runs entirely on-device on a single 8GB laptop, no cloud calls at any point.

How i built it

• Retrieval: 2,280 text chunks from 16 real agricultural extension PDFs, embedded with fastembed (all-MiniLM-L6-v2, ONNX) and indexed with faiss-cpu (IndexFlatIP) chosen specifically to avoid pulling in a full PyTorch/CUDA dependency stack on integrated-graphics-only hardware.
• Generation: Qwen3.5-2B, quantized to GGUF Q8_0, running through llama-cpp-python/llama.cpp fully CPU-based inference.
• Interface: a Gradio ChatInterface in place of a command-line tool, since the target user isn't a technical practitioner. It supports natural follow-ups ("give me more detail") without re-asking the original question, and exposes the Yoruba toggle as a simple checkbox.
• Language support: rather than relying on the model to generate Yoruba text directly (shown to be unreliable see below), a validator-reviewed glossary of agricultural Yoruba terms is applied as a deterministic substitution over the model's English output.

Challenges i ran into

The biggest challenge was Yoruba-language support, and it didn't go the way i planned. I first tested whether Qwen3.5-2B could handle Yoruba zero-shot it couldn't; it produced repetition loops and confabulated vocabulary with fabricated English glosses. I then tried fine-tuning it on a mix of hand-authored agricultural examples and general-fluency Yoruba data, but hit a confirmed, open dtype-compatibility bug between Unsloth and Qwen3.5 on T4 GPUs. Switching to Qwen2.5-1.5B fixed the training crash, but the resulting fine-tune while fluent didn't reliably surface the correct trained facts, even when i handed it the right answer directly in the prompt (verified via greedy decoding, ruling out random sampling as the cause). Rather than ship a model that sounds confident but can drift from the truth on something like fertilizer dosage, i stepped back and built a deterministic vocabulary-substitution layer instead a smaller claim, but one we can guarantee is correct every time.

I also spent real time evaluating external Yoruba datasets to shortcut this problem, and every one had a real, disqualifying flaw on inspection: one had <unk> token corruption from incomplete translation filtering, another had systematically misaligned question/answer pairs, two others used a deprecated data-loading format entirely. That process taught me not to trust a dataset's reputation over what it actually looks like when you open it.

Accomplishments that i am proud of

• A real, working, fully offline RAG pipeline that gives specific, cited, source-grounded agricultural answers not generic AI platitudes.
• Catching and fixing subtle bugs in my own Yoruba vocabulary layer before shipping a plural-matching gap, and a verb/noun collision that produced garbled output ("gbin 2 gbin per station") until i identified and removed the ambiguous term.
• Being honest, in my own documentation, about a fine-tuning effort that didn't pan out and treating that as real engineering signal rather than hiding it.

What i learned

Fluency and correctness are not the same thing, and it's easy to build something that has one without the other. A model that speaks a language beautifully but drifts from the facts is more dangerous for a farming advisor than one that's honest about what it doesn't know. I also learned to verify data and tools directly rather than trust their reputation several promising-looking Yoruba datasets and even a benchmarking tool's star count turned out different on direct inspection than they first appeared.

What's next for AgbeTalk

• Revisit Yoruba fine-tuning with context-shaped training data (matching our actual retrieval-augmented prompt structure, rather than bare question-answer pairs), which i believe was the real gap this round.
• Expand the vocabulary substitution layer with more validator-reviewed terms and extend the same approach to other major Nigerian languages (Hausa, Igbo).
• Re-benchmark on ADTC reference-class hardware (my development machine used an older CPU and HDD storage, both slower than the reference spec).

Built With

• faiss
• fastembed
• google-colab
• gradio
• huggingface
• llama-cpp-python
• llama.cpp
• onnx
• python
• qwen
• retrieval-augmented-generation
• ubuntu
• unsloth
• wsl2
• yoruba