Graph Serialization for LLMs: How You Write Down the Links Drives Accuracy, but Only When the Model Has to Count, Not Extract

The paper has no single prompting technique. It's a set of findings plus one more advanced trick (a format selector). Below is a blueprint for putting the findings to work.

STEP 1: Identify the task type
        → "extract facts against a schema" → format barely matters, use anything readable
        → "count/traverse the links" → format is critical, keep going

STEP 2: Pick 2–3 candidate formats (adjacency list, JSON-LD, plain-language description)
        → same graph, same questions

STEP 3: Run 15–20 questions with known answers through each format
        → a "format × accuracy" table

STEP 4: Choose the format for your model and reasoning mode
        → weak model: more verbose; reasoning model: more compact

(Optional, needs code) STEP 5: Selector: 5 parallel judgments of "which format fits this question," then 1 answer
        → +9.5 points over the best fixed format, but cost ×3.7

The method shines where the question requires walking the links and counting. Pure extraction or summarization isn't a fit: format doesn't affect those.

Task: You're running the launch of an online store on Amazon. The plan has 14 tasks with dependencies: product listings, a photo shoot, a fulfillment contract, ad setup and so on. Your manager asks: “If the fulfillment contract falls through, how many tasks are at risk, directly and down the chain?” That's a reachability question. Here, the graph format can swing accuracy several-fold.

Prompt:

Below is the dependency graph for the tasks involved in launching a store on Amazon.
An entry of the form "A: B, C" means: tasks B and C start after A
(B and C depend on A).

Graph:
Fulfillment_contract: Ship_inventory_to_warehouse, FBA_setup
Ship_inventory_to_warehouse: Publish_listings
FBA_setup: Publish_listings, Test_order
Photo_shoot: Product_listings
Product_listings: Publish_listings
Publish_listings: Launch_ads, Opening_promo
Launch_ads: First_sales_report
Test_order: Launch_ads
Opening_promo: First_sales_report

Question: if the "Fulfillment_contract" task falls through, how many other
tasks will be at risk, directly and through dependency chains?
List all tasks by level, then state the total.
Check that no task is missed or counted twice.

Result: The model lists the tasks by level: direct dependencies first, then second-level, then third-level. At the end it gives a total with a self-check. Then take the same graph in another format (say, “Task → Task” one per line, or a plain-language description) and ask the same question. If the answers differ, format matters, and you should choose by checking against your own manual count.

The LLM's weakness. The model reads a graph as a sequence of tokens, not as a diagram. To answer “how many nodes are reachable,” it has to keep every vertex's neighbors “in its head.” In one format the neighbors sit side by side; in another they're scattered across the text. If the model has to hunt for neighbors across the whole edge list, misses and counting errors pile up. That's why format strongly affects structural questions. Extracting a fact from a sentence doesn't need the graph structure, so there's almost no difference.

The LLM's strength. Reasoning mode lets the model walk the graph step by step and double-check itself. That's why gpt-5.4 with high reasoning shows a small spread across formats, while fast models without reasoning show a big one. Reasoning “patches” an awkward notation, but not for free: you pay in tokens and time.

How to use it. Match the format to the “model + question type” pair and verify with an experiment. Don't cling to one “best” format. If the model is strong, use a compact notation: it's cheaper and still accurate. If it's weak, verbose formats (JSON-LD, SHACL-style descriptions) pay for themselves in accuracy.

Control levers: - Notation format → the main lever. Change it when counting and reachability start failing. - Reasoning mode → crank it up (thinking, high) if you can't change the format. The spread across formats shrinks. - Graph size → the more nodes, the bigger the format effect. In the “hard” tests the spread grew to 28 points. - The “list it step by step and double-check” requirement → my own addition: it forces the model to walk the links explicitly instead of guessing.

The paper has no ready-made prompt: the authors used a fixed instruction to keep the comparison fair. Below is a wrapper template for A/B-testing formats, modeled on their design: one graph, one question, only the notation changes.

Below is a graph in the "{format_name}" format.
How to read it: {how_to_read_notation}.

Graph:
{graph_in_this_format}

Question: {structural_question}
Write out your solution step by step, then give the final answer on one line.
Check that nothing is missed or counted twice.

What to fill in: - {format_name}: for example, “adjacency list,” “edge list,” “JSON-LD,” “plain-language description.” - {how_to_read_notation}: one sentence. For example, “A: B, C means A has links to B and C.” - {graph_in_this_format}: the same set of facts, written out in different ways. - {structural_question}: a counting or reachability question whose answer you already know.

🚀 Quick start: paste this into the chat:

Here's a template for testing graph notation formats. Adapt it to my task: [your task with relationships between entities].
Ask me questions to fill in the fields.
Then rewrite my graph in 3 formats (adjacency list, edge list, plain-language description)
and prepare 5 structural questions with answers that I'll check by hand.

[paste the template above]

The LLM will ask what your entities and relationships are, what questions you'll be asking and how big the graph is. It needs this to match formats to your question type and to build control questions with verifiable answers. Without verifiable answers, picking a format turns into guesswork.

⚠️ Fact extraction: if the task is “pull relationships out of text against a schema,” format changes almost nothing. The difference is a few points, and accuracy comes down to how powerful the model is.

⚠️ No universal format: the best format changes from model to model and from task to task. Even within one model family, the mini, standard and “high” versions have different favorites. There's no ready-made “always use X.”

⚠️ Results depend on the graph type: on synthetic graphs, compact notations led (adjacency list, “structured”). On real Wikidata subgraphs, the adjacency list landed among the worst for one of the models, and JSON-LD came out on top.

⚠️ The format selector requires code: automatically choosing a format per question (5 judgments + 1 answer) costs 3.7 times more than a fixed format and was tested on only one set of 105 questions of the same type. The authors didn't show it transfers to other data.

⚠️ Narrow testing: graphs, ontologies and Wikidata. Transferring this to tables, JSON from a CRM or other structures is a hypothesis the paper didn't test. The authors didn't evaluate a full real-world graph RAG, retrieval, or very large contexts. The Wikidata test ran on two models.

The Oracle team took 15 ways to write down the same graph: RDF formats (Turtle, JSON-LD), SHACL-style constraint descriptions, tables, Mermaid and DOT diagrams, adjacency and edge lists, and plain-language descriptions. They tested on nine configurations of current models (GPT-5.4 in two reasoning modes, GPT-5.4-mini, o3, Claude Sonnet 4.6 with and without “thinking,” Haiku 4.5, Grok-4-fast with and without reasoning). Within a given test, only the notation changed: same facts, same node order, same question wording.

There were two groups of tasks. The first was extracting “subject–relation–object” triples from 2014 sentences against ontologies (Text2KGBench). The second was structural questions on synthetic graphs (GraphQA): node degree, paths, cycles and so on, plus harder variants (diameter, maximum clique, centrality). Separately, they checked 110 questions on real Wikidata subgraphs.

The result is a surprise for anyone who feared that “format is everything”: for extraction the spread is just 1–4 points, but for structural tasks it goes up to 28 points. Even more interesting is the dependence on “reasoning strength”: a strong model in high mode shows a spread of about 0.6 points, while a fast model without reasoning swings up to 17 points on simple tasks. In other words, reasoning mode partly compensates for a bad format. Finally, the authors tested the “selector”: the model itself judges which of five formats will suit the question best. It scored 76% versus 67% for the best fixed format and 71% for majority voting over five answers. The gain is real, but on a small sample and at the price of roughly triple the spend.

🔧 Technique: a manual “selector” across two chats → a cheap format check

The automatic selector requires code. For a one-off task, keep it simple: have the same model in two separate chats answer one question about the graph in two formats. If the answers match, format doesn't matter. If they don't, check against a manual count and pick the format that got it right.

[Chat 1] Graph as an adjacency list + question
[Chat 2] Same graph as a plain-language description + the same question
Compare the numbers. A mismatch = format matters, check by hand.

🔧 Technique: add reasoning mode → less dependence on format

If changing the format is a hassle (the graph arrives from a system already formatted), turn on reasoning mode or add “list the steps level by level and double-check” to the prompt. In the paper, it's precisely the increase in reasoning that shrinks the spread across formats.

Extrapolation (hypothesis, not tested in the paper): the same rule may hold for any linked data in a prompt: an org chart, approval chains, a competitor map. If the question requires walking the links, test two notations (a “who → whom” list and a plain-language description) and compare against a manual answer.

• Graph Serializations for Reasoning LLMs: A Study Across Knowledge Extraction and Structural Reasoning — Julien Yu, Mihaela Bornea, Avirup Sil, Katrin Kirchhoff, Oracle.
• Foundational work: Text2KGBench (Mihindukulasooriya et al., 2023), Talk Like a Graph / GraphQA (Fatemi et al., 2024), KG-LLM-Bench (Markowitz et al., 2025), Sclar et al., 2024 (model sensitivity to prompt formatting).