Author(s): Israel Durotoye

Originally published on Towards AI.

Building a Soil Doctor: Inside My RAG-Based Soil Advisory System

How I’m combining semantic search, BM25, and cross-encoder reranking to build an agricultural assistant that can explain its recommendations.

A sensor reading is only the beginning of a farming decision.

Knowing the soil’s moisture, temperature, or pH still leaves a harder question: What should I do with that information, and what evidence supports the action?

That question is driving my work on Soil Doctor, an agricultural advisory project that connects soil information with relevant agronomic knowledge.

The part I’m discussing here is its retrieval-augmented generation pipeline: how it searches for evidence, selects useful passages, and provides context to a language model.

The predictive engine remains a separate development task. This article describes the advisory architecture, rather than claiming validated predictions or measured improvements in farm productivity.

The engineering problem: moving from information to a justified decision

Consider this illustrative question:

“I’m growing maize. I have soil readings and want to understand what they mean for water and nutrient management.”

An assistant needs more than a fluent answer. It needs to establish which information is available, which guidance applies, and what remains uncertain.

For Soil Doctor, I think about this as three separate responsibilities:

• Observation: What do the measurements actually report?
• Interpretation: What relevant evidence helps explain them?
• Recommendation: Which actions can that evidence reasonably support?

Keeping these responsibilities separate matters. A measurement, an inference, and a recommendation should never become indistinguishable in the final response.

Why I chose retrieval-augmented generation

Retrieval-augmented generation, or RAG, combines a language model with an external source of information. Instead of relying exclusively on knowledge encoded during training, the system retrieves relevant material and uses it during answer generation. The original RAG research explored this combination of model parameters and retrievable external memory.

For Soil Doctor, this gives me a practical way to work with a defined agronomic knowledge base.

It also creates a useful debugging question:

Did the system find the right evidence before it attempted to answer?

That question is much more actionable than simply deciding that an answer “sounds wrong.”

The prototype knowledge base I’m discussing contains 312 text chunks. That number describes the indexed material; it does not establish completeness, quality, or agronomic coverage.

The stack behind the advisory pipeline

The important architectural choice is using multiple retrieval stages. Each stage addresses a different part of the evidence-selection problem.

Step 1: make the knowledge searchable

Before answering questions, the system needs a searchable representation of its reference material.

The knowledge base is divided into smaller passages, or chunks. Each passage can then be retrieved independently.

Chunk boundaries deserve careful attention. My design requirement is that a passage should retain enough context to make its meaning clear. If an instruction is separated from the conditions that qualify it, retrieving that instruction could produce an incomplete explanation.

For this application, I want a retrieved passage to make it possible to identify:

• What issue it discusses.
• Which conditions its guidance assumes.
• Where the information came from.
• What limitations accompany it.

These are also criteria for reviewing and improving the corpus. More chunks are useful only when they add relevant, trustworthy coverage.

Step 2: search by meaning and by terminology

Soil Doctor combines semantic retrieval with BM25.

Semantic retrieval represents the question and passages as numerical vectors called embeddings. It searches for passages whose representations are close to the question’s representation.

This helps when a user’s wording differs from the terminology in the reference material. Sentence Transformers describes this as a key difference between dense retrieval and literal lexical matching.

For example, I would want a question about “soil drying too quickly” to surface relevant material even when a source uses a different technical phrase. That is an intended retrieval behaviour, not a reported test result.

BM25 provides a complementary search path. Its scoring accounts for matching query terms, their frequency, their rarity across the collection, and document length.

That lexical path matters when a question includes specific terminology such as a crop name, nutrient name, or measurement method.

The reason for combining them is straightforward: I want candidate evidence to reflect both the meaning of the question and its explicit terms.

However, having two retrievers does not automatically prove better performance. Their contribution needs to be measured against a single-retriever baseline.

Step 3: rerank the candidate evidence

The first retrieval stage produces possible matches. A second stage asks which passages most directly address the question.

Soil Doctor uses a cross-encoder reranker from the MS MARCO MiniLM family.

Unlike an embedding model that represents questions and passages independently, a cross-encoder processes a question–passage pair together and produces a relevance score. Because this requires computation for each pair, it is commonly applied to a shortlist of retrieved candidates.

Conceptually, its job is:

relevance_score = reranker(question, candidate_passage)

The distinction I care about is between a passage that discusses the same broad subject and one that helps answer the specific question.

A paragraph mentioning soil moisture may be topically related to irrigation. It may still provide little support for the decision being asked about.

Reranking helps refine the context supplied to the language model. It does not certify that a passage is scientifically correct or appropriate for every farm.

Step 4: generate an answer within the evidence

Once evidence has been selected, the language model’s role is to explain it in relation to the user’s question.

The response structure I’m working toward has five parts:

1. Available information: What the user or system supplied.
2. Interpretation: What the retrieved evidence supports.
3. Possible actions: What can reasonably follow from that interpretation.
4. Missing context: What could materially change the answer.
5. Supporting sources: Which passages justify the explanation.

This structure is a design target, not a guarantee created by adding a prompt.

For example, if a user asks for a precise fertilizer quantity but provides insufficient context, I want Soil Doctor to identify the missing information. Producing an exact-looking number would not make the response more useful.

The same principle applies when the knowledge base lacks relevant evidence. The system needs a way to acknowledge that gap.

Why the sensor interface matters as much as the model

My interest in Soil Doctor sits at the intersection of embedded systems and AI.

A farm sensing node and a language-model backend solve different problems. Connecting them requires a clear data contract.

For that interface, I would require more than a bare numerical value. A useful measurement record should carry its unit, timestamp, measurement type, and an identifier linking it to the correct device or location.

That is an integration requirement I would test explicitly.

Otherwise, the advisory pipeline could receive a plausible number without enough information to interpret it. Better retrieval would not repair that missing context.

How I intend to evaluate Soil Doctor

A convincing demonstration is only the start. I want evaluation to separate failures by stage.

For retrieval, one useful measure is Recall@k: the fraction of labelled relevant passages recovered within the first k results.

For generation, I want to inspect individual claims and their supporting evidence. An answer can retrieve a relevant source and still draw an unsupported conclusion from it.

I also want to compare semantic retrieval alone, hybrid retrieval, and hybrid retrieval with reranking. Until those experiments are complete, I treat the additional stages as engineering hypotheses to evaluate.

What I’m building toward

Soil Doctor brings together several problems that interest me: collecting physical measurements, organising domain knowledge, retrieving evidence, and communicating a decision clearly.

The prototype gives me a foundation for investigating those connections. The next work is to strengthen evaluation, refine the knowledge base, develop the predictive component, and verify the interfaces between sensing and advisory software.

The standard I want Soil Doctor to meet is simple to state and difficult to achieve:

Every recommendation should make clear what was measured, what was inferred, what evidence supports it, and what is still unknown.

I’m Israel Durotoye, a mechatronics engineer working across embedded AI, machine learning, and intelligent physical systems. I share the technical decisions and lessons behind the systems I build.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI