What Structure Buys You: Knowledge Graphs in the Age of Language Models

On 16 May 2012 Google announced that search would start understanding "things, not strings", backed by a knowledge graph of more than 500 million objects and more than 3.5 billion facts about and relationships between them (Singhal, 2012, Google blog). Seven years later a masked language model with no graph at all answered cloze-style factual queries on T-REx with 32.3% precision at one, against 33.8% for a relation extractor handed an oracle entity linker (Petroni et al., 2019, Language Models as Knowledge Bases?, arXiv:1909.01066). A later paper put the obvious question in its subtitle: Will LLMs Replace Knowledge Graphs? (Sun et al., 2024, Head-to-Tail, arXiv:2308.10168).

As of September 2026 the answer is no, but not for the usual reason. Graphs survived not because they hold more facts than a model, but because a graph computes something retrieval over text cannot, an exact join, and because the part language models made cheap (writing the query) is not the part that decides whether the answer is right. That part, whether the needed edges exist and point at the right nodes, costs what it always did.

Why this matters: Teams choose between vector RAG, LLM-extracted "GraphRAG" and curated graphs with text-to-query front ends, usually from demos. Their cost curves and failure signatures differ, and knowing which questions each answers exactly or confidently wrongly separates an index that pays for itself from one that burns hundreds of thousands of tokens per book before the first query.

TL;DR

• A graph wins on composition, not recall. On an \(h\)-hop question retrieval multiplies per-hop recalls and a graph multiplies edge coverages fixed at build time, so the gap compounds with \(h\).
• LLMs made the query cheap, not reliable. GPT-4 on an enterprise insurance schema scored 16.7% execution accuracy over raw SQL and 54.2% over a knowledge-graph layer (Sequeda et al., 2023); the best CypherBench model reached 61.58% (Feng et al., 2024).
• Extracted graphs miss a third of the answers. Only about 65.8% of HotpotQA answer entities appeared in an LLM-built graph; triplet-only retrieval scored 25.02 F1 to plain RAG's 60.04 (Han et al., 2025).
• The long tail is where structure earns its keep. GPT-4 was right on 40.3% of head-entity questions and 19.0% of tail-entity ones; a graph lookup does not care about fame.
• GraphRAG-style indexing is expensive both ways. Indexing a 56k-token book with Microsoft's GraphRAG took 654,673 tokens; its local search averaged 38,707 prompt tokens to vanilla RAG's 879 (Xiang et al., 2026).
• Curation is the real bill. Manual curation is estimated at $2 to $6 per triple, automation one to two orders of magnitude cheaper and noisier (Paulheim, 2018).

At a Glance

flowchart LR
    Q["User question"] --> R{"Question shape?"}
    R -->|"join, count, constraint"| L["Entity linking"]
    L --> T["Text-to-query"]
    T --> KG[("Knowledge graph")]
    KG --> A["Answer with triple provenance"]
    R -->|"detail, prose, single hop"| V["Vector retrieval"]
    V --> C[("Chunk index")]
    C --> A
    B["Build: extract, resolve, map ontology"] -.-> KG
    E["Build: embed chunks"] -.-> C

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    classDef amber fill:#b45309,stroke:#fbbf24,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0

    class Q blue
    class R,L,T,V purple
    class KG,C slate
    class A teal
    class B amber
    class E emerald

The dotted arrows are where the paths differ: the vector index is one cheap embedding pass, while the graph needs a pipeline that never really finishes.

From the Semantic Web to Things, Not Strings

The graph idea was designed for a different consumer. In May 2001 Berners-Lee, Hendler and Lassila described a Semantic Web in which software agents would read machine-interpretable statements and chain them into inferences for their users (Berners-Lee, Hendler & Lassila, 2001, Scientific American 284(5)). The agents never arrived; the data model did. In 2006 Berners-Lee reduced the practical part to four rules: use URIs as names for things, make them HTTP URIs, return useful information in standard formats (RDF, SPARQL) when one is looked up, and link to other URIs (Berners-Lee, 2006, Linked Data). They solve identity: once two datasets agree that a URI denotes Paris the city rather than Paris, Texas, their facts join without an integration project.

timeline
    title Knowledge graphs and language models
    2001 : Berners-Lee, Hendler and Lassila publish The Semantic Web
    2006 : Linked Data design note sets four rules for URIs and links
    2012 : Google Knowledge Graph launches with 500M objects and 3.5B facts
         : Wikidata launches in October as a collaborative knowledge base
    2015 : Freebase goes read-only with about 3 billion triples
    2019 : Petroni et al. probe BERT as a knowledge base
    2023 : Head-to-Tail measures LLM factuality by entity popularity
         : Sequeda et al. report 16.7 to 54.2 percent with a KG layer
    2024 : Microsoft GraphRAG builds graphs from text with an LLM
         : Pan et al. roadmap appears in IEEE TKDE
    2026 : GraphRAG-Bench at ICLR asks when graphs help RAG at all

Industry adopted the model without the agents. Freebase, a public source behind Google's 2012 graph, went read-only on 31 March 2015 with 2,997 million triples, of which only 442 million were "useful" facts once labels, identifiers and bookkeeping were stripped (Pellissier Tanon et al., 2016, From Freebase to Wikidata, WWW). One useful fact per seven stored triples is the first hint that structure has overhead. Its migration to Wikidata then ran into references, which Wikidata's editors wanted and Freebase mostly lacked.

Wikidata, launched in October 2012, is now the largest open general-purpose graph: 123,376,874 items and 42,742 active users in September 2026, with scholarly articles 39.7% of items in its (self-described outdated) class breakdown (Wikidata:Statistics).

[IMAGE: Stacked horizontal bar of Wikidata's item classes: scholarly articles 39.7%, other classes 18.9%, humans 11.8%, astronomical objects 7.3%, built structures 5.3%, small slices for the rest. Caption: "The largest open knowledge graph is two-fifths bibliographic records. Coverage reflects who curates, not the data model."]

Then language models arrived as a rival memory, strong on popular facts and weak on rare ones. On PopQA's 4,000 least popular questions GPT-J 6B scored 16% and GPT-3 davinci-003 19%, so scale barely moved tail knowledge (Mallen et al., 2023, When Not to Trust Language Models, ACL, arXiv:2212.10511). Head-to-Tail measured GPT-4 at 40.3% on head entities, 33.4% on torso and 19.0% on tail. Pan and colleagues supplied the field's vocabulary: KG-enhanced LLMs, LLM-augmented KGs, and synergised LLMs plus KGs (Pan et al., 2024, Unifying Large Language Models and Knowledge Graphs: A Roadmap, IEEE TKDE, arXiv:2306.08302).

What a Graph Computes That Retrieval Cannot

The concept on grounding language models in structured knowledge lists what structure provides. This section puts numbers on traversal and aggregation, because the numbers decide the architecture.

Composition turns recall into a product

Take a question whose answer chains \(h\) facts, each in a different passage. A retriever succeeds only if every evidence passage reaches the top \(k\), in one shot or across iterative rounds. With \(R_i(k)\) the probability that hop \(i\)'s passage makes the cut and \(q\) the probability the generator composes correctly given all the evidence,

A graph first links the question to a start entity (probability \(p_{\text{link}}\)), translates it to a query (\(p_{\text{query}}\)), and executes. Execution is deterministic, so the remaining uncertainty is whether each needed edge exists and is correct, with coverage \(c_i\):

With uniform per-hop values the graph is the better bet when

The right-hand side is a fixed tax: linking and translation can fail even on a one-hop question, so at \(h = 1\) the graph usually loses. The left-hand side compounds. With curated coverage \(c = 0.99\) and iterative recall \(R = 0.85\) the ratio is about 1.16 per hop and the advantage multiplies with each hop. With an extracted graph at \(c = 0.8\) the ratio falls below one and the graph loses more as questions get harder. Everything interesting is in whether \(c\) exceeds \(R\), and \(c\) is set at construction time.

There is a second asymmetry: \(R_i\) depends on phrasing and \(c_i\) does not. Hop three's passage typically shares no words with the question, because the bridge entity it describes is not named there until an earlier hop surfaces it. This is why HotpotQA, 113k Wikipedia questions built to need several supporting documents, is the standard stress test for graph-augmented retrieval (Han et al., 2025, RAG vs. GraphRAG, arXiv:2502.11371).

[IMAGE: Line chart of success probability against hop count h from 1 to 5 for three systems: curated graph (c = 0.99, starting at 0.86), iterative RAG (R = 0.85, starting at 0.81), extracted graph (c = 0.8, starting at 0.70), showing the curated graph pulling ahead and the extracted graph falling fastest. Caption: "Whichever per-hop factor is larger wins by more as questions get longer."]

Token accounting

Iterative retrieval spends a round per hop, each carrying \(k\) chunks of length \(L\) plus overhead \(o\) for question, instructions and the model's notes. The graph spends a schema slice \(S\) to write the query, an answer prompt \(a\), and \(r\) result rows of \(t\) tokens:

\(T_{\text{vec}}\) is linear in hops; \(T_{\text{kg}}\) is nearly flat in hops and linear in result size. That is why aggregation is the most lopsided case: "how many products use this cell?" is one row in a graph, and in text it requires retrieving every passage mentioning each product, which no top-\(k\) does.

The catch is \(S\): real schemas do not fit in a prompt. Wikidata has over 4 million entity types and 12,000 relation types, which Feng and colleagues identify as the root cause of poor LLM retrieval from modern RDF graphs (Feng et al., 2024, CypherBench, arXiv:2412.18702). Their remedy is 11 small domain-specific property-graph views over 7.8 million entities, with readable names instead of identifiers like wdt:P1034. Choosing the slice becomes a retrieval problem of its own.

The translation step is the measured bottleneck

Language models cut the cost of writing SPARQL or Cypher to an API call without making it reliable. On an enterprise insurance benchmark, zero-shot GPT-4 reached 16.7% average execution accuracy over the SQL schema and 54.2% over a knowledge-graph representation with an ontology and mappings; on high-schema-complexity questions SQL scored 0% and SPARQL 35.7% to 38.5% (Sequeda, Allemang & Jacob, 2023, arXiv:2311.07509). Two cautions: the authors work for data.world, which sells a knowledge-graph catalogue, and it is one schema in one domain. Read it as evidence that business semantics in the prompt matter.

CypherBench is larger (over 10,000 questions) and the ceiling is lower than demos suggest: Claude 3.5 Sonnet 61.58% execution accuracy, GPT-4o 60.18%, GPT-4o-mini 31.43%. That is \(p_{\text{query}}\), and at 0.6 it eats most of what near-perfect coverage buys on a two-hop question. Worse, the failure is silent: a valid query over the wrong relation executes cleanly and returns a confident, well-formatted wrong answer.

The alternative spends the model per hop. Think-on-Graph has the LLM beam-search over relations; on the multi-hop CWQ benchmark it lifted ChatGPT from 38.8% with chain-of-thought to 57.1%, and reached 67.6% with GPT-4 against 70.4% for the best fine-tuned system (Sun et al., 2024, Think-on-Graph, ICLR, arXiv:2307.07697). Stepwise choices are easier than one whole query, but they multiply like recall and cost a call per hop.

Amortisation: where the money goes

Query-time arithmetic flatters the graph because it omits construction. From Lenat's figure of $120 million for Cyc's 21 million assertions, Paulheim derives $5.71 per expert-curated statement; a Wikipedia-based estimate gives $2.25 for crowd curation; automated pipelines such as DBpedia come out near 1.85 cents per statement. He flags the assumptions as debatable, and finds costlier triples generally more likely to be correct (Paulheim, 2018, How much is a Triple?, ISWC). Treat these as orders of magnitude.

LLM extraction sits between the two and its bill is measurable in tokens. If graph indexing costs \(C_{\text{kg}}\) against \(C_{\text{vec}}\) for embeddings, and each qualifying query saves \(\Delta = T_{\text{vec}} - T_{\text{kg}}\), break-even arrives after

queries, where \(f\) is the fraction of traffic that is actually multi-hop. Teams forget \(f\). A graph built for the 10% of questions that need joins earns its build cost from that 10% alone.

Seeing It in Motion

Production systems add a fallback, because \(p_{\text{query}}\) is well short of one and an empty result is ambiguous.

sequenceDiagram
    participant U as User
    participant O as Orchestrator
    participant M as LLM
    participant G as Graph store
    participant V as Vector index
    U->>O: Question
    O->>M: Link entities, pick schema slice
    M-->>O: Start node and Cypher query
    O->>G: Execute query
    G-->>O: Rows with source ids
    alt rows returned
        O->>M: Compose answer from rows
    else empty or query error
        O->>V: Retrieve top-k chunks
        V-->>O: Passages
        O->>M: Answer from passages, flag unverified
    end
    M-->>U: Answer with provenance

"No rows" means "not recorded", so the fallback looks for what the graph never captured, and flags its answer as lacking the exact-join guarantee.

Most of the engineering lives on the build side.

flowchart TB
    subgraph Sources["Sources"]
        D["Documents"]
        S["Systems of record"]
    end
    subgraph Build["Construction pipeline"]
        X["LLM extraction"]
        ER["Entity resolution"]
        ON["Ontology mapping"]
        VA["Validation and constraints"]
    end
    KG[("Graph with provenance")]
    SV["Schema views per domain"]
    H["Human review queue"]
    D --> X --> ER --> ON
    S --> ON
    ON --> VA --> KG --> SV
    VA -.->|"rejects and conflicts"| H
    H -.-> ER

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    classDef amber fill:#b45309,stroke:#fbbf24,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0

    class D,S blue
    class X,ER,ON,VA purple
    class KG slate
    class SV teal
    class H amber

Systems of record skip extraction and map straight onto the ontology, which is why graphs over existing databases reach high coverage cheaply. The review queue's throughput caps how fast the graph absorbs change.

[IMAGE: Two panels. Left: a three-hop path through a graph, each edge labelled c = 0.99. Right: three stacked top-5 retrieval lists with the evidence chunk at rank 1, rank 3 and missing. Caption: "The graph multiplies coverages fixed at build time; the retriever multiplies recalls that depend on the wording of the question."]

By the Numbers

Sources: figures are copied from each primary page or paper's own tables. Paulheim's costs are assumption-laden estimates; the Sequeda benchmark comes from a vendor.

Two rows repay a second look. On HotpotQA "use a graph" is not one intervention: triplets alone collapse, while HippoRAG2, which uses the graph as an index over passages, edges past plain RAG. And GraphRAG-style systems cost more than vector RAG at query time: structure buys efficiency only when the answer is in the structure.

[IMAGE: Log-log scatter from Xiang et al.: x-axis indexing tokens for one 56k-token book, y-axis average prompt tokens per query. Vanilla RAG near the origin, HippoRAG2 low on both, MS-GraphRAG and LightRAG upper right. Caption: "'GraphRAG' spans two orders of magnitude in build and query cost; it is not one cost profile."]

A Concrete Example

A hardware company asks: "Which city is home to the company that makes the battery cell in the Kestrel D-40 drone?" The corpus is 20,000 chunks of 500 tokens (10 million tokens). The facts sit in three documents: the D-40 spec sheet names cell VX-C7, the VX-C7 datasheet names Voltaic Energy as maker, and Voltaic's profile puts it in Pune. Names and numbers are illustrative.

Graph path.

1. Link. A label index maps "Kestrel D-40" to node P-1182; assume \(p_{\text{link}} = 0.97\).
2. Schema slice. Three node labels and six relation types, about 400 tokens; with question and instructions the prompt is 600 tokens.
3. Generate about 50 tokens:

MATCH (p:Product {id:'P-1182'})-[:USES_CELL]->(c:Cell)
      -[:MANUFACTURED_BY]->(m:Company)-[:HEADQUARTERED_IN]->(city:City)
RETURN c.name, m.name, city.name

4. Execute. P-1182 has 37 outgoing edges, one USES_CELL; VX-C7 has 212 incoming USES_CELL edges the query never touches. With typed adjacency indexes the engine reads three edges and returns one 20-token row.
5. Answer from a 120-token prompt, 30 tokens out, citing three triples.

Total: \(600 + 50 + 120 + 30 = 800\) tokens. For an easy three-hop pattern take \(p_{\text{query}} = 0.9\), above CypherBench's average; with curated coverage \(c = 0.99\),

Vector path, one shot. The question embeds near the spec sheet (cosine 0.81, rank 1). The VX-C7 datasheet never mentions drones (0.52, rank 38); Voltaic's profile scores 0.34 (rank beyond 900). At \(k = 5\) the model sees one of three evidence chunks and cannot name the city.

Vector path, iterative. The model reads each round, extracts the bridge entity and re-queries.

That is about 8,550 tokens including generation, over three sequential round trips. With per-round recall at 5 of 0.85 and \(q = 0.95\),

Compare. The curated graph is about 10.7 times cheaper (\(8{,}550 / 800\)) and more often right (0.85 against 0.58). Now use an extracted graph at edge coverage 0.8, plausible given Han and colleagues' 65.8%:

Still cheaper, now less accurate than iterative retrieval, and failing worse: a missing edge returns no rows, which a careless system reports as "no manufacturer".

The build bill. Xiang and colleagues' ratio (654,673 indexing tokens for about 56k corpus tokens, roughly 11.7 to 1) scaled to 10 million tokens gives an estimated 117 million indexing tokens against 10 million to embed. With \(\Delta = 7{,}750\) tokens saved per multi-hop query,

If every query looked like this one, the index pays back in about 13,800 queries; if one in ten does, about 138,000. And "how many drones use VX-C7?" is one row in the graph (212), out of reach for any retrieval budget short of reading every product sheet.

Where It Breaks

Entity resolution decides coverage

Every \(c_i\) hides two questions: was the fact extracted, and was it attached to the right node? "Voltaic Energy", "Voltaic Energy Pvt Ltd" and "VOLTAIC" become three nodes unless merged; MANUFACTURED_BY lands on one, HEADQUARTERED_IN on another, and the query returns nothing without raising an error. Over-merging is the mirror image: two firms sharing a trading name become one node. As the concept on entity resolution at graph scale explains, these errors are made at build time and surface as coverage loss at query time.

The ontology drifts while the data grows

A schema written for last year's products has no relation for this year's subscription bundle. Closed-schema extraction silently drops the new facts; open-schema extraction yields a dozen surface forms for one relation. Either way coverage decays on exactly the questions users are newly asking. Repair is slow: in the Freebase migration, about 90,000 human review actions had been taken against more than 14 million uploaded statements by January 2016.

stateDiagram-v2
    [*] --> Extracted
    Extracted --> Linked: entity resolved
    Extracted --> Rejected: no confident match
    Linked --> Validated: passes constraints
    Linked --> Conflicted: contradicts existing fact
    Conflicted --> Validated: reviewer accepts
    Conflicted --> Rejected: reviewer rejects
    Validated --> Stale: source changes
    Stale --> Validated: re-verified
    Stale --> Retracted: no longer true
    Retracted --> [*]
    Rejected --> [*]

Most pipelines implement the top half of this lifecycle and none of the bottom. Stale needs a validity interval per fact and a re-check trigger, which a plain triple has nowhere to put, so the graph presents facts true at extraction as current.

Absence is not negation

A missing triple means unknown, not false (see triples, ontologies and the open world). An LLM composing from an empty result tends to say "there are none". Han and colleagues found community-level global GraphRAG scoring 19.27% on MultiHop-RAG's Null queries, which should be answered "insufficient information", against 96.01% for plain RAG.

Silent translation errors and hub fan-out

A query that joins on SUPPLIED_BY instead of MANUFACTURED_BY returns a real company in a real city, wrongly, and nothing in the output looks uncertain. Validating queries against ontology constraints and showing the query beside the answer reduce this without removing it. Hubs are the cost-side failure: the same pattern started from a country or a standard part fans out to millions of paths.

The published evaluations disagree

GraphRAG's headline results (Edge et al., 2024, arXiv:2404.16130) use LLM judges, which Han and colleagues showed are highly sensitive to presentation order. Cost claims conflict too. LightRAG's authors report retrieval using under 100 tokens against 610,000 tokens of GraphRAG community reports (Guo et al., 2024, LightRAG, arXiv:2410.05779); the independent GraphRAG-Bench measured LightRAG prompts averaging about 100,000 tokens and the slowest indexing of the systems tested. The configurations differ, which is the lesson: count your own tokens on your own corpus.

[IMAGE: A graph fragment with three near-duplicate company nodes, "Voltaic Energy", "Voltaic Energy Pvt Ltd" and "VOLTAIC", one carrying the MANUFACTURED_BY edge and another the HEADQUARTERED_IN edge, with a broken dashed path between them. Caption: "An unmerged duplicate turns a three-hop answer into an empty result without an error."]

Alternative Designs

The rows are not exclusive: Han and colleagues found RAG ahead on single-hop and detail questions, graph methods ahead on multi-hop ones, and proposed per-query selection. The composition inequality states the routing rule: send a question to the graph when \(h\) is large and the relations it needs are ones you have high coverage for.

How It Is Used in Practice

Wikidata is the reference case for curation that works: tens of thousands of active editors, a culture of referenced statements, and a public SPARQL endpoint. It also underpins many benchmarks, CypherBench included, so benchmark numbers flatter enterprise performance: public entities are well linked and documented, internal ones are not. Tellingly, Google chose in 2014 to close Freebase and offer its content to Wikidata rather than keep running a curation community.

In enterprises the productive pattern is the semantic layer: an ontology and mappings over existing databases, so coverage is inherited from systems of record rather than extracted from prose. That is the Sequeda setting, where \(c\) is near one and the schema can be described in business terms. Graphs extracted purely from documents send many questions back to text anyway.

Microsoft's LazyGraphRAG is telling: its authors state that its indexing costs are "identical to vector RAG and 0.1% of the costs of full GraphRAG", with comparable global-query quality at more than 700 times lower query cost (Edge, Trinh & Larson, 2024, Microsoft Research blog). Vendor claims, but the team that popularised LLM-built graphs moved the expensive work to query time.

Graphs that stay useful keep provenance and confidence on every triple, size the review queue to the domain's rate of change, and re-run a gold set of multi-hop questions whenever the ontology or extractor changes.

[IMAGE: Layered enterprise semantic layer: relational systems of record at the bottom, mappings and an ontology above, a SPARQL or Cypher endpoint above that, and an LLM router at the top that also reaches a document vector index. Caption: "Coverage is cheapest when the graph is a view over data that is already structured."]

Insights Worth Remembering

1. A graph is a join engine, not a bigger memory. Its edge is exact composition and aggregation, not storing more facts.

2. Coverage is the whole game, and it is set at build time. The graph wins when per-edge coverage beats per-hop recall; at 80% coverage an extracted graph loses to iterative RAG on three hops while still being cheaper.

3. LLMs moved the bottleneck without removing it. Writing the query is an API call that succeeds about 60% of the time on hard benchmarks; the human work moved to schema design and entity resolution.

4. "GraphRAG" and "knowledge graph" are different cost profiles. Community-summary GraphRAG spends heavily at index and query time; a curated graph is costly to build and nearly free to query.

5. An empty result is a claim about your pipeline, not the world. Systems that turn "no rows" into "none" convert coverage gaps into confident falsehoods.

6. Graphs over systems of record are the cheap case. A semantic layer inherits near-complete coverage; a graph extracted from prose spends most of its advantage on extraction error.

Open Questions

Can text-to-query match the reliability of the graph it queries? Measured: the best models sit near 60% on CypherBench. Unknown: whether ontology-constrained decoding, query verification and schema-specific fine-tuning close the gap on large enterprise schemas.

How can coverage be measured before deployment? Coverage has been measured after the fact on public benchmarks. No cheap standard method estimates per-relation coverage for a private graph before users find the holes.

Will cheap long context erase the token advantage? Evidence: GraphRAG-Bench shows prompt sizes differing by orders of magnitude across methods, and the arithmetic above gives a curated graph a roughly tenfold edge on multi-hop questions. Speculation: with cheap enough context, exact aggregation, provenance and temporal validity may be the graph's only durable advantages.

Where does LLM extraction sit on the cost-quality curve? Paulheim's estimates predate it. Its token cost per triple is measurable; its error rate per triple across domains is not.

Sources and Further Reading

1. Berners-Lee, T., Hendler, J., & Lassila, O. (2001). "The Semantic Web." Scientific American, 284(5), 34-43. scientificamerican.com
2. Berners-Lee, T. (2006). "Linked Data." W3C Design Issues. w3.org
3. Singhal, A. (2012). "Introducing the Knowledge Graph: things, not strings." Google blog, 16 May. blog.google
4. Pellissier Tanon, T., Vrandečić, D., et al. (2016). "From Freebase to Wikidata: The Great Migration." WWW 2016. PDF
5. Wikidata. "Wikidata:Statistics." Retrieved September 2026. wikidata.org
6. Paulheim, H. (2018). "How much is a Triple? Estimating the Cost of Knowledge Graph Creation." ISWC 2018 Blue Sky track, CEUR-WS Vol. 2180. PDF
7. Petroni, F., et al. (2019). "Language Models as Knowledge Bases?" EMNLP 2019. arXiv:1909.01066
8. Mallen, A., et al. (2023). "When Not to Trust Language Models: Investigating Effectiveness of Parametric and Non-Parametric Memories." ACL 2023. arXiv:2212.10511
9. Sun, K., Xu, Y. E., Zha, H., et al. (2024). "Head-to-Tail: How Knowledgeable are Large Language Models (LLMs)? A.K.A. Will LLMs Replace Knowledge Graphs?" NAACL 2024. arXiv:2308.10168
10. Pan, S., Luo, L., Wang, Y., et al. (2024). "Unifying Large Language Models and Knowledge Graphs: A Roadmap." IEEE TKDE. arXiv:2306.08302
11. Sequeda, J., Allemang, D., & Jacob, B. (2023). "A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases." arXiv:2311.07509
12. Sun, J., et al. (2024). "Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph." ICLR 2024. arXiv:2307.07697
13. Feng, Y., Papicchio, S., & Rahman, S. (2024). "CypherBench: Towards Precise Retrieval over Full-scale Modern Knowledge Graphs in the LLM Era." arXiv:2412.18702
14. Edge, D., et al. (2024). "From Local to Global: A Graph RAG Approach to Query-Focused Summarization." arXiv:2404.16130
15. Edge, D., Trinh, H., & Larson, J. (2024). "LazyGraphRAG: Setting a new standard for quality and cost." Microsoft Research blog, 25 November. microsoft.com
16. Guo, Z., Xia, L., Yu, Y., et al. (2024). "LightRAG: Simple and Fast Retrieval-Augmented Generation." arXiv:2410.05779
17. Han, H., et al. (2025). "RAG vs. GraphRAG: A Systematic Evaluation and Key Insights." arXiv:2502.11371
18. Xiang, Z., Wu, C., Zhang, Q., et al. (2026). "When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation." ICLR 2026. arXiv:2506.05690

Free to read, no ads, no sign-up. If it was useful you can buy me a coffee.