Knowledge Graphs vs TOON Tables for LLM Facts

For feeding facts to an LLM, tables beat both knowledge graphs and JSON. A 2026 study found tabular structures delivered a 40.29% average performance gain on factual tasks. When the table format is TOON, you also cut tokens by up to 58.8% with 99.6% field retrieval — the best combination of accuracy and efficiency available for factual lookups.

Why Knowledge Graphs Fall Short for Inline LLM Facts

Knowledge graphs model the world as subject-predicate-object triples. That representation is powerful for graph traversal — finding paths between entities, detecting transitive relationships, running multi-hop queries. But when you need to inject a block of facts into an LLM prompt, the triple format pays a significant token tax.

Every triple repeats the subject and predicate as full strings. For a set of entity facts, that means the entity name and each attribute name appear once per row. A graph describing 50 products across 6 attributes results in 300 triples, each carrying its own subject and predicate overhead. The redundancy is structurally identical to repeating JSON keys on every object in an array.

The research is unambiguous on this. The paper Talking with Tables for Better LLM Factual Data Interactions (arXiv 2412.17189, updated January 2026) compared tabular structures against knowledge graphs, JSON, and text-blended formats across factual-data tasks. Tabular structures achieved a 40.29% average performance gain with better robustness and token efficiency. The authors attribute this to improved attention: tables help LLMs attend to relevant information more precisely, which directly translates into higher factual accuracy.

The conclusion from that study is direct: tabular structure is the most token-efficient and most powerful format for factual-data requests to LLMs.

Triples vs TOON: What the Same Facts Look Like

The difference is easiest to see with a concrete example. Here are four entity facts — a small subset of a product catalog — expressed as subject-predicate-object triples, then as JSON, then as a TOON table.

# Knowledge graph triples (subject-predicate-object)
product:A101  name        "Widget Pro"
product:A101  category    "tools"
product:A101  price_usd   29.99
product:A101  in_stock    true
product:A102  name        "Gadget Lite"
product:A102  category    "electronics"
product:A102  price_usd   49.99
product:A102  in_stock    false
product:A103  name        "Part X"
product:A103  category    "parts"
product:A103  price_usd   9.99
product:A103  in_stock    true
# Subject and predicate repeated on every row: 12 rows, 4 unique predicates × 3 subjects

// JSON — keys repeated on every object
[
  {"id":"A101","name":"Widget Pro","category":"tools","price_usd":29.99,"in_stock":true},
  {"id":"A102","name":"Gadget Lite","category":"electronics","price_usd":49.99,"in_stock":false},
  {"id":"A103","name":"Part X","category":"parts","price_usd":9.99,"in_stock":true}
]

// TOON — fields declared once in the header; rows contain only values
products[3]{id,name,category,price_usd,in_stock}:
  A101, Widget Pro, tools, 29.99, true
  A102, Gadget Lite, electronics, 49.99, false
  A103, Part X, parts, 9.99, true

At three rows the difference is already visible. The TOON header declares field names once; each subsequent row is pure value. At 200 rows — a typical product slice for a RAG retrieval — the savings compound dramatically. Official toonformat.dev benchmarks measured 58.8% fewer tokens for TOON versus JSON on flat uniform data (67,778 vs 164,452 tokens), with 99.6% field retrieval accuracy.

You can convert any JSON or triple export to TOON instantly using the free json2toon.co converter.

Knowledge Graphs vs JSON vs TOON for LLM Facts: A Direct Comparison

For a broader format comparison including CSV, YAML, and TONL, see the TOON format comparison guide.

When to Keep the Graph and When to Flatten

Knowledge graphs are not the wrong tool — they are the wrong tool for this specific job. The distinction matters in practice.

Keep the graph when the query is about relationships: "Which authors co-authored papers with researchers at institution X?" or "What is the shortest path between product A and supplier B through the distribution chain?" These are traversal problems. The graph topology carries the answer, and flattening to a table would destroy the information needed to answer them.

Flatten to a TOON table when the query is about attributes of a known set of entities: "What are the prices and stock levels for products in the tools category?" or "Give me the release date and author for each of these five documents." Here the relationships are not the point — the field values are. A TOON table delivers those values to the LLM with the least token overhead and the highest retrieval accuracy.

The practical workflow for hybrid systems is:

1. Store entities and relationships in a graph database (Neo4j, Neptune, or a GraphRAG index).
2. At query time, traverse the graph to identify the relevant node set.
3. Project out the factual attributes of those nodes as a flat list.
4. Serialize that list as a TOON table and inject it into the prompt context.

This pattern is also described in the context of RAG pipelines. Retrieved nodes from a vector database or graph share a schema — text plus metadata fields — making them a uniform array, exactly TOON's strongest case. See our guide to optimizing RAG pipelines with TOON for implementation details.

How Token Savings Scale with Entity Count

One important nuance from the TOON research is the prompt-tax dynamic: there is a fixed overhead for the format header and any format-instruction tokens needed to orient the model. On very small entity sets, that overhead can erode the savings. The payoff grows linearly with row count.

The toonformat.dev benchmark ran 5,016 LLM calls across 209 questions, six formats, and four models using the GPT-5 o200k_base tokenizer. The flat/uniform table dataset used 67,778 TOON tokens against 164,452 JSON tokens — a 58.8% reduction on a large realistic dataset. At that scale, TOON delivers 27.7 accuracy-points per 1,000 tokens versus JSON's 16.4, a 69% efficiency advantage.

For knowledge graph triples, the token math is even more favorable to TOON. A triple encoding of N entities with K attributes produces N × K rows, each carrying the entity identifier and attribute name. A TOON table for the same data produces N rows plus a single header line. On 100 entities with 6 attributes, that is the difference between 600 triple rows and 101 TOON lines — with each triple row consuming more characters per row than a TOON value row.

To understand why the per-token savings are so consistent, see our explainer on JSON vs TOON token differences, which walks through how Byte Pair Encoding tokenizes repeated structural characters.

GraphRAG: Combining Both Approaches

GraphRAG is an emerging 2026 pattern that combines vector search with knowledge graphs for complex multi-hop reasoning. The retrieval step uses the graph to pull semantically related subgraphs; the injection step serializes the retrieved node attributes into the prompt.

In this architecture, TOON is not a replacement for the graph — it is the serialization layer at the graph-to-prompt boundary. The graph does what graphs do best (relationship traversal, community detection, entity linking). TOON does what TOON does best (compact, accurate delivery of factual attributes to the model).

If your GraphRAG pipeline is injecting retrieved subgraph nodes as JSON objects, switching to TOON at that serialization step is a drop-in optimization. With 58.8% fewer tokens on flat entity data and a 40.29% factual accuracy advantage for tabular formats (per arXiv 2412.17189), the change compounds across every query in your pipeline.

For a worked example of encoding retrieved context as TOON, see few-shot prompting with TOON — the same uniform-array principle applies to injected context blocks.

Frequently Asked Questions