Retrieval is good at finding the passage that answers a question. It struggles when the answer is not in any passage but in the connections between many records. "Which suppliers share a director with this vendor?" "Which customers are affected if this component is recalled?" "Which members delivered into the grain this buyer is complaining about?" Each of these is a chain of relationships, and the chain crosses systems.
Knowledge graphs exist for this kind of question. They store entities and the relationships between them explicitly, so a question can be answered by walking from one entity to the next. Combined with a language model, a graph can turn a plain-language question into a traversal and return an answer with every step traceable.
They are also among the more expensive things a data team can take on. The CloudNala view is that a knowledge graph earns its place only where multi-hop questions are frequent, valuable and poorly served today, and that it should be built from structured records first, with language-model extraction used carefully at the edges.
Gariep Grain Co-operative is fictional, and its systems and figures are illustrative. Part 3 routed most of Gariep's questions to querying or retrieval. One class remained: traceability, which the operations team needed when a buyer reported a quality problem.
The question that started it
Late in the 2026 season, a mill reported an off-odour in a rail shipment of maize. Under its supply agreements, Gariep needed to find out quickly which members' grain could have been in that shipment, so it could check their delivery records, inspect the bin and, if necessary, contact the farms.
The answer required three hops across four systems:
The shipment record was in the logistics system. Which bin it was loaded from was in the silo management system. Which loads went into that bin, and when, was in the weighbridge records together with bin allocation logs. Which members those loads belonged to was in the member registry. The first time this happened, it took two people most of a day with exports and spreadsheet lookups. Nobody was sure the result was complete.
Vector search over Gariep's documents would not have helped. It could find documents that mentioned the complaint, the shipment number or the bin, but it could not join the records together. A language model reading those documents would have produced a plausible list of members, which is worse than no list.
How graph search works
A knowledge graph stores two things: nodes, the entities (a member, a load, a bin, a shipment, a buyer), and edges, the relationships between them (delivered by, filled, loaded from, shipped to). Each edge can carry properties: dates, quantities, and, importantly, which system it came from.
Answering a question has three parts:
- Translate the question into a traversal. A language model can turn "which members delivered into the grain in shipment R-0412?" into a graph query: start at the shipment, follow "loaded from" to bins, follow "filled by" to loads within the relevant date window, follow "delivered by" to members.
- Run the traversal. The graph database returns the matching members, with the path that connects each one.
- Write the answer from the result. The model phrases the answer, grounded in the returned paths, and can show the chain for each member.
The benefit over retrieval is that every step in the answer can be checked. A person can see that member X is linked because load 4471 went into bin 7 on 14 June, and bin 7 loaded shipment R-0412 on 2 July.
Building the graph: structured first
There are two ways to populate a graph. You can extract entities and relationships from text using a language model, or you can load them from structured records where the relationships already exist as keys and foreign keys.
Language-model extraction is the approach most demonstrations use, because it is impressive: feed in documents and a graph appears. It is also where graphs go wrong. Extraction misses relationships, invents relationships that are not there, and creates duplicate entities. Two farms named "Rietfontein" in different districts become one node, or one member appears three times under slightly different spellings.
Gariep took the opposite route. The three relationships it needed already existed in structured systems: shipment to bin, bin to loads, loads to members. These were loaded directly, with the source system and date stored on every edge. Entity resolution was simple because members already had registry numbers. Language-model extraction was used only for one additional source, free-text inspection notes written by silo staff, and each new edge from those notes was flagged for a person to confirm before it was trusted.
That decision made the graph far more reliable and far cheaper to maintain. It also meant the graph was, in effect, a well-modelled view of data Gariep already owned, which is exactly why the earlier parts of this series came first. A graph built on top of weak ownership and unclear definitions inherits every one of those problems, and adds traversal on top.
Limitations to state plainly
Extraction quality caps answer quality. Any relationship extracted from text by a model can be wrong. If those relationships are not reviewed or at least scored for confidence, the graph will return confident, traceable, wrong answers.
The schema decides what can be asked. A graph can only answer questions about relationships someone modelled. When Gariep's quality manager asked which transport contractor had carried the affected loads, the graph had no edge for it. Adding one meant a new source, new loading logic and new tests.
Graphs need maintenance. Relationships change. Members sell farms, bins are cleaned and refilled, shipments are corrected. Without a refresh process and data quality checks, the graph drifts from the systems it represents.
Not every question is relational. A team that has built a graph tends to route everything through it. Most of Gariep's questions were still better served by a direct query or by retrieval.
Personal information travels with the edges. A graph that links members to loads to complaints is a concentrated store of personal information. Access to it should match the access rules of its sources, which is why Gariep made the traceability tool available to operations staff only and kept it out of the member assistant. The same principle applies to retrieval, covered in permission-aware retrieval.
When a graph is worth it
A practical test before committing:
- Frequency. Are multi-hop questions asked weekly, or once a year?
- Value. Does a fast, complete answer matter: a recall, a fraud investigation, a regulatory request, a contamination trace?
- Current pain. How long does it take today, and how confident are people in the result?
- Structured sources. Do most of the relationships already exist as keys in systems you own?
- Ownership. Is there someone who will own the graph's schema and quality, as Part 2 described?
At Gariep, traceability passed on value and current pain, and the structured sources made it affordable. The graph was scoped to four entity types and three relationships, and that was enough.
The decision
If you are considering a knowledge graph, write down five real multi-hop questions and how long each takes to answer today. If you cannot find five, you probably do not need a graph. If you can, check whether the relationships already exist in structured systems and build from those first. Treat text extraction as a supplement that needs review, not the foundation.
Next: Part 5, Ten data engineering projects that prove real capability. All parts are on the series page.
How CloudNala can help
We help organisations test whether a knowledge graph is justified for their relationship-heavy questions, and when it is, design a scoped graph built from structured sources they already own, with provenance on every relationship and access rules that match the source systems.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Data Readiness Review or write to us at consult@cloudnala.co.za