Beyond Chunks: How Knowledge Graphs Answer What Documents Can't

1. What is a knowledge graph?

A knowledge graph stores things, and the relationships between them, as data you can query. The things are called nodes: a film, a person, a company, a genre. The relationships are edges, and every edge has a type: DIRECTED,ACTED_IN, COMPOSED. One edge is one fact:

S. S. Rajamouli —DIRECTED→ Magadheera

That three-part shape — subject, relationship, object — is called a triple, and it's the atom of every knowledge graph. Here is the same information in the three shapes data usually comes in:

Each shape has a strength. A table is perfect when every record has the same fields. A sentence carries nuance and context. A graph wins when the interesting part is how things connect — because the connections are first-class data, not something you reconstruct by joining tables or reading between the lines.

Edges carry details too

In the graph built here, an ACTED_IN edge records the actor's billing position (1 for the lead), and every edge records which source asserted it (wikipedia, wikidata, or both). That's the property graph model: nodes and edges are both little records with fields.

Zoom out from one film and you see a neighbourhood. This is Magadheera's:

A knowledge graph is millions of these neighbourhoods stitched together, because the same M. M. Keeravani node that appears here also hangs off every other film he scored. That shared node is the whole trick: walk from one film to its composer and on to all of his other films, and yo're following connections no single document lists.

The schema: the kinds of things and relationships

Every graph has a schema (sometimes called an ontology): the list of node types and edge types it allows. This one is small: five kinds of node (Film, Person, Company, Genre, Community) and about ten kinds of relationship. Small and explicit is good. when nobody defines the relationships in advance, they multiply until nobody can query them.

In one line: a knowledge graph is data about things and their typed relationships, so that the relationships can be searched, counted and followed.

2. Where it came from, before LLMs

Knowledge graphs are about sixty years older. The term became popular in 2012, but the idea — represent knowledge as things joined by labelled links — goes back to the earliest days of artificial intelligence.

The AI years: networks of meaning

In the 1960s, researchers modelling human memory drew concepts as nodes and meanings as labelled links — a canary IS-A bird, a bird HAS wings. These semantic networks are recognisably knowledge graphs. A decade later, Peter Chen's entity–relationship model gave database designers the same vocabulary for business data. And from 1984 the Cyc project tried to hand-write all of common sense as logical facts — an effort that taught everyone how expensive it is to build knowledge by hand.

The web years: a web of data

Around 2000, the idea moved to the web. The W3C standardised the triple as RDF, and Tim Berners-Lee and colleagues described a Semantic Web in which pages would carry data machines could read, not just text for people. The full vision never arrived, but its building blocks did: shared IDs for things, and triples as a common format. In 2007 DBpedia started pulling structured data out of Wikipedia's infoboxes, and Freebase built a crowd-edited graph of things.

The industry years: things, not strings

In 2012 Google announced its Knowledge Graph with a phrase that stuck:

“Things, not strings.”

A search for a film stopped being just a list of pages that contain its name. It became an entity, with a director, a cast and a release date shown right on the results page. The same year, Wikimedia launched Wikidata, a free knowledge graph that gives every thing a stable ID. (Those IDs are how this project knows that “NTR Jr” and “N. T. Rama Rao Jr.” are the same person — more on that in Part 3.) Meanwhile graph databases such as Neo4j made it practical to store and query graphs with ordinary engineering tools, and the Cypher query language used throughout this article grew out of that world.

Why organisations built them

Long before anyone paired them with language models, knowledge graphs earned their keep in a handful of jobs:

• Search and answers. Showing facts about the thing you searched for, not just pages that mention it.
• Data integration. Joining records from many systems by agreeing that this ID is that customer, product or molecule.
• Recommendations. “People connected to what you liked” is a graph walk.
• Fraud and risk. Rings of accounts are invisible row by row and obvious as a graph.
• Science. Linking genes, proteins, diseases and drugs across thousands of papers and databases.

The hard part was always the same: getting knowledge into the graph. Either someone mapped existing databases into it, carefully, or someone wrote rules and trained models to pull facts out of text, expensively. That bottleneck is exactly what large language models changed — but before that, it helps to see the two routes clearly.

In one line: knowledge graphs predate LLMs by decades; they were built for search, integration, recommendations, fraud and science, and the hard part was always filling them.

3. What LLMs changed

Large language models made the expensive part of knowledge graphs — reading text into facts — cheap.

LLMs made extraction cheap. They did not make it correct, and they did not make identity easy.

What didn't change: knowing who is who

The hardest step in building a knowledge graph was never extraction. It's entity resolution: deciding that two mentions are the same thing, and that two similar mentions are not. Telugu cinema makes this vivid:

• The same star is credited as Jr. NTR, NTR Jr and N. T. Rama Rao Jr. The graph has exactly 1 node for him, because all three spellings point to one Wikidata ID.
• Mononyms are everywhere — Sunil, Raja, Krishna, Srikanth — and several of them belong to different actors. 47 names in this corpus map to more than one person, and the graph deliberately refuses to merge them by name.
• One Wikipedia cast cell links the name “Jagapathi Babu” to Prakash Raj's page. Trust the link and one actor silently loses a credit to another.

An LLM can help with each of these, but it can also confidently get them wrong. What works best is boring: stable IDs, explicit rules for when two records are the same, and validation that refuses to continue when the numbers look wrong.

In one line: LLMs turned extraction into a prompt; identity, validation and schema design are still engineering work.

5. What kind of data suits a graph

A graph pays off when your questions are about connections. A useful test: read your users' real questions and count how many contain words like with, between, linked to, depends on, most, how many, who else*. Those are graph questions.

Films are a textbook case: a small number of entity types (films, people, companies) joined by a large number of relationships. Many serious domains have the same shape.

A few sketches of how that plays out:

• Law. Judgments cite earlier judgments and interpret statutes. A graph of CITES and OVERRULES edges turns “is this precedent still safe to rely on?” into a path question: does anything I cite lead, through citations, to an overruled decision?
• Pharma and biomedicine. A drug TARGETS a protein, the protein is ASSOCIATED_WITH a disease, the drug was TESTED_IN a trial. Drug repurposing is the question “which drugs reach this disease in two hops but have never been tested for it?”
• Finance and fraud. One account looks innocent. Twenty accounts sharing three phones and an address look like a ring — and you only see it by following shared edges.
• Enterprise knowledge. Systems depend on systems, teams own systems, documents describe them. “What breaks if this goes down, and who do I call?” is a graph walk.
• Supply chains. A product depends on parts, which depend on suppliers, which sit in regions. Concentration risk lives two or three hops down.

When a graph isn't worth it

If your questions are answered by a passage of text (“explain our refund policy”), use document search. If they're about one table (“total sales by month”), use SQL. If your relationships are few and rarely change, a couple of database joins will do. A graph earns its cost when relationships are many, varied, and the actual subject of the questions.

In one line: use a graph when the questions are about how things connect — credits, citations, targets, dependencies — not when the answer is a paragraph or a single table.

1. How a graph helps retrieval

Retrieval-augmented generation (RAG) means: before the model answers, fetch some relevant material and put it in front of it. The model then answers from that material instead of from memory. The usual way to fetch is to split documents into chunks and find the chunks most similar to the question — by shared keywords, or by meaning (vector search).

That works beautifully when the answer is written down in a chunk. Whether it is depends on the shape of the question:

Lookups and relationships are often written somewhere. Paths and aggregates almost never are — the answer is spread across thousands of records. Descriptive questions are the reverse: no name to look up, just a description to match.

Three ways to retrieve from a graph

1. Walk the neighbourhood. Find the people and films named in the question, collect every fact within two hops, and hand those facts to the model. Precise, but only as good as the step that matches names in the question to nodes in the graph.
2. Write a query. Show the model the graph's schema and let it write a database query , run it safely read-only, and answer from the rows. This is the only approach that can compute an answer: count, rank, find a path.
3. Summarise communities (the “GraphRAG” pattern). Cluster the graph into groups of closely connected nodes, have a model write a summary of each group in advance, then answer from the summaries. Built for broad questions about themes.

In one line: ordinary RAG finds text that looks like the question; a graph can also follow relationships and compute answers that no text contains.

2. Where it improves RAG answers, and where it doesn't

A graph doesn't make every answer better. It makes specific kinds of answer possible, and others more trustworthy.

• Computed answers. Counts, rankings and “most” questions. Writing a graph query can get majority of the aggregate questions right
• Facts about who did what. A plot summary says what happens in a film, not who made it. Typed edges hold the roles: the neighbourhood walk found that Pawan Kalyan wrote, directed and starred in Johnny.
• Grounding and provenance. Every edge records its source, so an answer can say where a fact came from — and a dubious fact stays visible. Wikidata alone says S. S. Rajamouli directed Rajanna (S. S. Rajamouli (wikidata); Vijayendra Prasad (wikipedia)); in reality he directed its action sequences. The graph keeps that as a single-source claim instead of silently trusting or dropping it.

And where it might not:

• Descriptive questions. “Which film is about a man who can't recognise faces?” has no name to start from. Keyword search can get answers right; the neighbourhood walk will not.
• Fuzzy names. When the query matched “Deverakonda” loosely, it found the wrong Deverakonda. A graph is precise only if you land on the right node.

The graph doesn't replace document search. It answers the questions document search can't, and the best systems route each question to the right one.

In one line: graphs add computed answers, typed facts, long-tail coverage and provenance; they add nothing for questions that describe content instead of naming it.

1. The Seven steps of building and using a graph

Every knowledge-graph project, whatever the domain, runs roughly the same pipeline. Here it is for this one, with what each step produced:

Here's what each step does — and, because this is where projects actually go wrong, what went wrong at each one here.

1. Source: decide what the graph is of

The corpus is Wikipedia's List of Telugu films of 2000 through 2025: 2,000+ film articles for the plot, the lead paragraph, and the budget and box office from the information box.

2. Parse: turn pages into records

Each year page has tables of releases, month, day, title, director, cast, production company etc. Turning those into clean records sounds trivial but it isn't. The layout changes from year to year, and each change has to be understood and coded for.

3. Identify: give every thing an ID

Every film, person and company that Wikipedia links has to be identified & given an ID. Looking those up turned names into identities: 2,006 films, 1,791 people and 107 companies resolved. This is the single most valuable step in the pipeline, because from here on, “are these the same person?” is a comparison of two IDs, not a guess about two spellings.

4. Resolve: decide who is who

Each credited person is matched by the strongest evidence available: their own Wikidata ID, a name match within the same film, or a name that is unique across the whole corpus. Anyone else stays a separate node rather than being merged on a guess.

5. Load: one fact, one edge

Everything goes into Kuzu, an embedded graph database (a single file, no server).

6. Index: make it searchable

A full-text index over titles and plots powers keyword search. A community-detection algorithm (Louvain) groups actors who often work together into 78 clusters, and a model writes a short summary of each, for the GraphRAG-style method.

7. Query: answer questions

Finally, questions go in and answers come out . Text-to-Cypher produced a runnable query for 19 of 19 questions; when the first attempt failed, the database's error message was fed back and the model fixed its own query.

In one line: source, parse, identify, resolve, load, index, query — and validate at every step, because the worst errors don't crash.

8. Where the data comes from

Three free sources, used for three different jobs.

1. Wikipedia's year lists — the spine. 26 pages, each listing a year's Telugu releases with release date, director, cast and production company, plus a top-ten box-office table (198 box-office rows in all). Snapshotted 2026-11-07.
2. Wikidata — the IDs, plus genre, music director, writer, producer and IMDb ID.
3. Each film's Wikipedia article — 2,004 articles, for the plot summary (searched by keyword search, read by the language model) and infobox budgets.

9. The graph

Here's what came out: 10,714 nodes and 63,224 relationships, in a single 56 MB database file.

Explore it

Below are two views of the graph you can play with. Sample is the box-office top ten of each year, topped up to fifteen films a year, with their directors and leading actors. Full graph is every film, person, company, genre and community, and every relationship between them. Click a node to see its neighbourhood — exactly what the neighbourhood-walk method hands the model. Connect two names to find the shortest chain of credits between them.

What the graph knows that no page says

Each of these took one short query.

Conclusions

Knowledge graphs aren't a replacement for RAG. They're the part of it that handles connections. Put together, the results make a simple routing table:

Five things to take away

1. A graph is for connections. If your users ask “who else”, “how many”, “linked to” and “depends on”, a graph answers what document search can't.
2. Let the database do the arithmetic. A model writing a query and reading the result beats a model reading documents and trying to count.
3. LLMs made graphs cheap to fill, not correct. Extraction cost cents; identity, validation and provenance still decide whether the answers can be trusted.
4. Constrain the vocabulary. A fixed list of relationship types keeps a graph queryable; free-form extraction produced 201 relationship names, most used once.
5. Route by question shape. Keep a text index beside the graph and send each question to the one that can answer it.

Sources for the history

• 1960s — Semantic networks: https://en.wikipedia.org/wiki/Semantic_network
• 1976 — The entity–relationship model: https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
• 1984 — Cyc: https://en.wikipedia.org/wiki/Cyc
• 1999 — RDF: https://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
• 2001 — The Semantic Web: https://www.scientificamerican.com/article/the-semantic-web/
• 2007 — DBpedia and Freebase: https://en.wikipedia.org/wiki/DBpedia
• 2010 — Property-graph databases: https://en.wikipedia.org/wiki/Cypher_(query_language)
• 2012 — Google's Knowledge Graph: https://blog.google/products/search/introducing-knowledge-graph-things-not/
• 2012 — Wikidata: https://www.wikidata.org/wiki/Wikidata:Introduction
• 2022→ — Large language models: https://en.wikipedia.org/wiki/Large_language_model
• 2024 — GQL and GraphRAG: https://arxiv.org/abs/2404.16130
• ISO/IEC 39075:2024, GQL: https://www.iso.org/standard/76120.html
• Freebase: https://en.wikipedia.org/wiki/Freebase_(database)
• Neo4j: https://en.wikipedia.org/wiki/Neo4j

Film data from Wikipedia (CC BY-SA 4.0) and Wikidata (CC0). Every figure about films, the graph and the evaluation is generated from the pipeline's own artifacts at build time.