0:00This video is about putting a language model on top of a knowledge graph, so that its answers can be checked against recorded facts.
0:08There are two ways to give graph structure to a language model. Here is the first.
0:13Hand it the schema and the question, and ask it to write a query. That schema is the ontology, the entity types that exist and the relationships allowed between them.
0:25That is all the ontology does here. It says what is askable. It does not contain the answer, and the model is not being asked to remember one.
0:35And this is what comes back. It is a valid query and it will run.
0:40But look at what it decided on the way. Top customers became the five highest by revenue, and depend on became buys from. The question said neither of those things.
0:51A valid query can answer the wrong question perfectly. So what you check before executing is not whether the syntax is right. It is whether that interpretation is the one you meant.
1:03So the interpretation gets confirmed, and then the query runs. Three steps, and it is worth naming them separately.
1:10Translate. The model turns the question into a query, using the schema it was given.
1:16Validate. Somebody checks the intent, and checks that the query only does what it is allowed to do. Read-only access, no deletes, bounded cost.
1:27Execute. And this is the part people skip past: the query runs against the graph, under whatever access restrictions you set.
1:36These are the facts it returned, with the identifiers on them so you can go back and check any of it.
1:42The model translated the question. It did not execute the database, and it did not answer from memory.
1:48That division is what makes the answer checkable at all.
1:52The second method does not ask the model to query anything. It hands the model the facts.
1:58Three relationships, written out as text. Globex buys from Volt, Volt is based in Northland, and Globex has an open ticket.
2:06Then the question, with an instruction not to use anything outside those facts.
2:11And notice the identifiers survived. S seven is the object of the first fact and the subject of the second. That is what makes those two a path rather than two unrelated sentences.
2:23So keep the I-Ds and the relationship types intact. Every claim the model writes can then be traced back to one specific edge, and checked against it.
2:34The example ends with a promise, and it is worth reading carefully.
2:38It says every claim in the answer maps to an edge above, and can be verified against the graph rather than trusted.
2:45That is what the technique is for. It is not what the technique does on its own. Putting facts in a prompt does not make a model's sentences map onto them.
2:56Here is a claim that might come back. Globex has an open ticket, and Globex buys from Volt, so the ticket is about Volt's quality.
3:04Nothing in those three facts says that. The ticket has a status and nothing else. So this is not contradicted, and it is not supported either.
3:12It is not established. And somebody still has to do the work that turns a citation into a verification, because the citation on its own does not do it.
3:22Those three facts were a choice. Somebody selected them.
3:26Here they are as a picture. Globex buys from Volt, and Volt is based in Northland.
3:31And Globex has an open ticket.
3:33That is everything the model was given. A boundary around three relationships out of a graph that has more.
3:40Initech also buys from Volt. That relationship is in the graph, it is true, and it was not in the prompt.
3:47A larger neighbourhood would have caught it, but it competes with the schema and the question for room in the prompt. You have to stop expanding somewhere, and something relevant can fall outside.
3:59One more thing grounding does not buy you.
4:02Take one assertion from that prompt. Volt is based in Northland, and it is the fact the sanctions conclusion rested on.
4:09Now suppose it is out of date. Volt moved, and nobody updated the graph.
4:13The edge looks exactly the same. It did not change colour when it stopped being true, and an answer citing it would still cite it correctly.
4:21So a perfectly grounded, perfectly cited answer can still be wrong. Grounding tells you which fact an answer rests on.
4:29Whether that fact is still true is a different question, about your ingestion and your validation, and it has to be answered separately.
4:37So here's where that leaves you.
4:38You can have a model translate a question into a graph query, and you know the thing to check is the interpretation, before the query ever runs.
4:47And you can hand a model the facts themselves, identifiers and all, so every claim traces back to an edge. You also know what grounding leaves open: unsupported claims, facts left out, and facts gone stale.
5:01One thing to carry out of this. Grounding tells you which fact an answer rests on, and whether that fact is true is a question you still have to answer.

Grounding an LLM in a Knowledge Graph

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 5 min 14 sec

0 views

About this video

A language model can sit on top of a knowledge graph in two ways. Given the schema, it translates a question into a query, and the thing to check before running it is the interpretation, not the syntax. Given the facts themselves, with identifiers kept, every sentence it writes can be traced to an edge. The video then reads the grounding promise carefully: a claim the facts never supported, a relevant fact the selection left out, and a cited fact that went stale are all still possible.

You'll learn how to:

Separate translate, validate and execute, so the model never answers from memory
Hand a model facts with their identifiers and relationship types intact
Tell a supported claim from one that is merely not contradicted
See why a perfectly cited answer can still be out of date, and whose job that is

For developers building question answering over a graph with an LLM.

What changed

v103 Oct 2026abhydesai5 min 14 sec21ba95b

First published version.

0 views0 likes on this version