Building agriculture knowledge graphs from messy multilingual data

Models get launch posts and benchmark threads. Knowledge graphs mostly get maintenance tickets, even though much of the engineering behind a useful agricultural answer lives there.

A language model has to generate a clear response in the farmer’s language. Before it does that, the system has to work out what the farmer is actually talking about. Which crop? Which growth stage? Which pest or symptom? Which region? Which practice or product record is relevant? Those connections are the graph.

Why vector search is not enough

A basic retrieval system turns a question into an embedding, finds similar passages, and sends them to a language model. That is useful, but similarity alone does not capture the relationships that determine an agricultural answer.

Take a cotton question about bollworm. The farmer may use a local pest name, omit the crop stage, and ask for a product using a retailer’s vocabulary rather than an active ingredient. A text search can find documents about bollworm. A graph can connect the phrase in that region to the pest entity, connect the pest to cotton, connect cotton to its current stage, and then retrieve the relevant agronomy and product context.

We still use text retrieval. The graph narrows and organizes what gets retrieved before the model writes an answer.

What we have connected

The graph is growing, so these are approximate working counts rather than permanent release numbers.

Crops. Roughly 200 crop entities, expanding to more than 1,800 varieties and related leaf nodes. Crops connect to growth stages, seasonal calendars, water needs, common stresses, and regional vocabulary.

Pests and diseases. Roughly 1,400 entities connected to host crops, visible symptoms, growth stages, and control concepts.

Agricultural products. Roughly 8,000 product records. We track active ingredients and collect official registration or label information where it is publicly available. Coverage varies because public product material is not equally complete or accessible for every record in India. We store what we can verify instead of pretending every product has the same depth.

Regions and practices. Agro-climatic zones, states, districts, crop calendars, irrigation patterns, and agronomic practices connect the general knowledge to the conditions in which it may apply.

Sources. The source layer includes ICAR material, state agricultural university and extension publications, government and regulator pages, research papers, and reviewed internal curation. Provenance is attached where available so the retrieval system can preserve where a fact came from and how much confidence to place in it.

Node counts are easy to publish and not terribly informative by themselves. The useful part is the connection. A question about irrigation timing for groundnut in Saurashtra during a delayed monsoon touches crop stage, water need, regional conditions, and current weather. The graph assembles the slow-changing agronomic context. A separate tool brings in the live weather at query time.

Turning messy documents into entities

Most source material was never written for a machine. It comes as scanned extension books, multi-column PDFs, tables, research papers, regulator pages, and documents that use different names for the same thing.

Our pipeline does five jobs:

1. extract the text and tables, using layout-aware OCR where necessary;
2. normalize units, crop names, active ingredients, and regional names;
3. resolve synonyms and multilingual terms to stable entity IDs;
4. connect the entities to crops, stages, regions, practices, products, and sources; and
5. send uncertain or conflicting connections through review.

Normalization is where much of the work sits. One source may describe a disease by scientific name, another by an English common name, and a farmer may use a district-specific term. The graph has to recognize that these terms may point to the same entity without flattening important regional differences.

From a graph to a conversation

A farmer does not speak in database fields. They say something like, “The leaves are curling and there are small insects underneath. What should I do?”

The conversation layer uses the words already exchanged with the farmer to build a small context graph. It may know the crop and district from earlier turns, but still need to ask about crop stage or request a photograph. Once those missing pieces are available, the system can retrieve a connected neighborhood rather than a pile of vaguely similar paragraphs.

That context graph also helps the assistant stay consistent across turns. If the farmer calls the same pest by two different local names, both terms can resolve to the same entity. If the farmer changes the crop, the system can avoid carrying over context that no longer applies.

This is especially important in multilingual conversations. The underlying crop or pest entity does not change when the farmer switches from Marathi to Hindi or mixes both in the same sentence. The language layer maps the conversation to the same graph and then renders the response in the form the farmer understands.

What stays outside the graph

Some data should not be stored as slow-changing domain knowledge.

Live weather, market prices, and sensor readings are called from operational tools when the question is asked.

Farmer and customer history stays in isolated customer stores rather than entering the shared agricultural graph.

Unverified material stays in a review queue until it can be connected to a reliable source or approved through internal curation.

What changes in production

In production retrieval workflows, the graph reduces the amount of irrelevant context sent to the model and makes missing context easier to detect. It gives the assistant a way to ask a better follow-up question, connect regional words to stable concepts, and explain which part of the available evidence informed the response.

Models change quickly. The connected domain context survives those changes. Every normalized source, reviewed synonym, and verified relationship makes the next conversation easier to ground, even after the model underneath has been replaced.

My practical advice to another team building this: assign entity IDs earlier than feels necessary. Retrofitting clean relationships onto years of unstructured documents is much harder than preserving them as the corpus grows.