Knowledge graphs can ground language-model answers in facts through graph RAG, with keyword extraction used to retrieve subject-predicate-object triples.
2
Language models make knowledge-graph construction easy to prototype, but generated entities and relationships often have poor quality and weak consistency.
3
Graphs give domain experts a visual and structured way to inspect model output and contribute to human-in-the-loop systems.
Summary
Louis Guitton explains how knowledge graphs and language models can support each other. A graph can ground an answer in explicit facts, while a language model can help construct the graph from text. He compares vector RAG with graph RAG: vector systems retrieve document chunks through embeddings, while graph systems extract query keywords and retrieve related triples. Graph RAG can produce shorter answers and use fewer tokens, but it depends on the quality of the graph. Guitton shows that prompt-based graph construction creates duplicate entities, inconsistent relationships, and missing hierarchy. He argues that language models should not be the only tool used for this work. Smaller models, specialist libraries, visual inspection, and domain experts can improve control. The talk ends with graph-based interfaces for human supervision and knowledge-graph construction.
Knowledge graphs and language models can support each other
Guitton uses KG for knowledge graph and LM for language model. He describes three connections between them. Graphs can ground language models in facts through graph RAG. Language models can help build graphs from text. Graphs can also give domain experts a way to inspect model output and provide supervision. He does not frame this as a rejection of large language models. His point is that progress in language models can also help knowledge-graph work, while graphs can address some of the weaknesses of language models.
Visual graph structures help experts inspect model output
Guitton shows two examples of visual analysis. One uses UMAP on embeddings to find quality problems. The other uses a graph-database visualization. Both add context through color metadata and algorithms that give visual meaning to the displayed points or nodes. This lets people inspect a model's output rather than treating it as an opaque result. He connects this to human supervision, where domain experts can use a visual representation to understand errors and contribute corrections or decisions.
Graphs may help systems move beyond memorized answers
Guitton questions what exam performance says about machine reasoning. He refers to an analysis arguing that models can memorize solutions instead of reasoning through them, which makes exams a poor direct comparison between people and machines. He points to research on reasoning and planning as a way to go beyond memorization. In his view, graphs may help because they provide explicit structure and relationships that a system can use when answering or planning.
Production results should determine the value of language models
Guitton says the value of a language model should be judged by its results in production. He discusses a Google project that used language models to fix bugs, together with smaller, more specific AI models and two human review stages. The example shows that language models can make developers faster without making human review unnecessary. For Guitton, this combination also illustrates how specialist models and people can work around the limits of a general language model.
Graph RAG retrieves triples instead of document chunks
Guitton contrasts vector RAG with graph RAG. In vector RAG, an embedding system turns the query into a vector, compares it with vectors in a database, and retrieves chunks for the language model. In graph RAG, a system extracts keywords from the query and uses them to retrieve triples from a graph. Each triple has a subject, predicate, and object. The language model then receives those triples as context and generates a natural-language answer.
Guitton demonstrates a graph RAG system built with a local language model, a local Neo4j knowledge graph, and a graph retriever. He says that LlamaIndex can provide the higher-level APIs and that the basic system can be coded in about 10 lines of Python. A question about Peter Quill from Guardians of the Galaxy produces a short answer. The prototype shows how quickly the pieces can be connected, before examining whether the underlying graph is accurate enough.
Prompt-based graph construction creates inconsistent data
Before graph RAG can work, the knowledge graph must be built, just as vector RAG needs documents to be embedded into a vector database. Guitton describes two common approaches to extracting triples: a fine-tuned model or a language model guided by a chain of prompts. He says the results often have poor quality and offer little control. Separate prompt chains may extract entities, disambiguate them, and pass results through regular expressions, which adds more moving parts.
Generated graphs can split entities and distort relationships
Guitton uses a Guardians of the Galaxy Vol. 3 graph to show concrete errors. Peter Quill and Quill appear as separate nodes even though they refer to the same entity. The graph treats being part of the cast and playing a role as different relationships. It also places information inconsistently, including an incorrect result involving James Gunn. He contrasts this with a human-built Wikipedia graph that connects James Gunn to directing, Chris Pratt to Star-Lord, and the films and character to the Marvel Cinematic Universe.
Specialist tools and people are needed for better graph construction
Guitton concludes that language models should not be the only method for constructing knowledge graphs. He mentions Text2Graph and ZShot as open-source libraries intended to produce better entities and relationships. He also describes their connection to graph databases and human-in-the-loop workflows. His final model has three parts: graphs ground language models in facts, language models assist with graph construction despite quality limits, and graph interfaces help domain experts provide structured input.
"The quality is pretty poor that comes out and there's also a big lack of control in terms of what comes out."07:47
Who should watch
You are building a RAG system and need to decide whether vector retrieval or graph retrieval fits the facts your application must expose.
Your team is using a language model to extract entities and relationships, and you need examples of the quality problems that appear in the resulting graph.
You want a practical explanation of how domain experts can inspect model output and take part in knowledge-graph construction.
