Graph engineering explained simply: the tutorial for anyone who already knows RAG

If you have built anything with RAG, you already know the disappointment: your assistant answers easy questions beautifully and then falls apart on the one question that actually mattered. Graph engineering is the discipline that grew up around fixing exactly that failure — and since July 2026 it has been the loudest phrase in AI engineering. This tutorial explains it from first principles, with no graph-theory background assumed.

1. The question your RAG can't answer

Here is a real shape of question, using an online seller as the example. Someone new joins the team and asks:

The answer lives in three separate places, and no single document contains it:

• An incident report from March: a spike in chargebacks on one product category.
• A policy note from April: the marketplace changed its returns window to 100 days.
• A decision record from May: "pause DE listings", which quietly replaced an earlier decision to expand there.

Ask a vector-based RAG system this question and it will retrieve the chunks that sound most like the words "stop", "selling", "German marketplace". It might surface the decision record. It will almost certainly miss the chain — because similarity ranks each chunk on its own, and the reason lives in the links between them. The model gets three unrelated-looking paragraphs and writes something confident and incomplete.

This is called a multi-hop question: answering it requires following two or more relationships. Multi-hop is where flat retrieval structurally cannot help you, no matter how good your embeddings are. And multi-hop questions are exactly the ones people ask when the stakes are high.

2. What a graph actually is (no maths required)

A knowledge graph is a graph built out of the facts in your business, where each edge is a small sentence: subject → predicate → object. "Incident #412 triggered Policy Review DE." "ADR-019 supersedes ADR-004." "Priya decided ADR-019."

Compare that to how RAG stores the same knowledge today: as paragraphs of prose, converted into long lists of numbers, with all the structure dissolved. Embeddings are wonderful at fuzzy meaning and hopeless at precise structure. A graph is the opposite. That is why they combine so well.

3. The one idea that makes the whole thing work: typed edges

This is the part beginners skip and then wonder why their graph is useless. There is an enormous difference between an edge that says "these two are related" and an edge that says "this one replaced that one."

An untyped link carries one bit of information: connected. A typed edge carries a verb. Watch what happens to our example when you strip the verbs out:

# untyped — the chain survives, the meaning dies
ADR-019  —  ADR-004        # which one replaced which? unknowable
INC-412  —  ADR-019        # did the incident cause it, or follow from it?

# typed — now a machine can reason, not just wander
ADR-019  supersedes   ADR-004
INC-412  triggered    ADR-019
ADR-019  decided_by   Priya
ADR-004  valid_until  "2026-05-14"

With verbs, an agent can answer "what is our current position on Germany?" by following supersedes to the end of the chain, and "why?" by following triggered backwards. Without verbs, it can only tell you these documents are somehow about each other — which is roughly what vector search already told you, at ten times the cost.

A good starter vocabulary looks like this:

supersedescauseddepends_ondecided_byownsmentionspart_ofcontradictsvalid_fromvalid_until

4. Three different things people mean by "graph engineering"

The term went viral in July 2026 and, as usually happens, immediately fragmented. When someone says "graph engineering", they mean one of three things. Knowing which saves you a lot of confused conversations.

Meaning 2 deserves a note, because it fixes something vector stores genuinely cannot do. A temporal knowledge graph keeps two timelines on every edge: when the fact was true in the world, and when your system found out. When a new fact contradicts an old one, you don't delete the old edge — you close its validity window. That single design choice is what lets one graph answer both "where does she work?" and "where did she work in 2024?"

Meaning 3 is really the next chapter of the story we told in loop engineering: once one agent's loop becomes several agents' work, the loop becomes a graph. The rules that matter there are simple — draw an edge only where real work flows through it, fan out in parallel then merge at one owned place, and put the human approval gate exactly where a mistake is expensive to undo.

5. Building one: the nine stages

Here is the pipeline, in the order that actually works. The single most common mistake is starting at stage 4.

1. Scope Pick one painful, repeated question. Not "all our knowledge". The graph gets its boundary from the question, not the other way round.
2. Representation Decide what a node is. Documents? Claims? Real-world entities? A graph of documents answers "what links to what"; a graph of entities answers "what is true".
3. Ontology Write down your node types and your ten-ish edge verbs — before any extraction. This document is the highest-leverage page in the whole project.
4. Entities Extract the nodes from your sources with an LLM pass, keeping the source, offset and timestamp for every one.
5. Relations Extract the typed edges. Force the model to choose from your vocabulary; reject anything outside it rather than letting it invent.
6. Events Attach time. When did this become true, when did you learn it, and when did it stop being true? Undated facts age into lies.
7. Quality gate Validate: unknown edge types, dangling targets, missing inverses, contradiction cycles. This is the step everyone omits and every failing graph is missing.
8. Fusion Merge duplicates — the entity-resolution step. Do it before storing, not as a clean-up job later.
9. Serve to LLMs Expose traversal as a tool the agent can call, and return citations with every path.

Here is the same pipeline as code, in miniature:

# stage 3: the ontology is a hard constraint, not a suggestion
EDGES = {"supersedes", "caused", "depends_on",
         "decided_by", "mentions", "valid_until"}

def ingest(doc):
    ents  = extract_entities(doc)              # stage 4
    rels  = extract_relations(doc, EDGES)      # stage 5 — constrained
    rels  = [r for r in rels if r.type in EDGES]  # stage 7 — reject, don't repair
    ents  = resolve(ents, graph)               # stage 8 — the expensive part
    for r in rels:
        graph.add(r, source=doc.id,            # provenance on every edge
                     seen_at=doc.ingested_at,
                     valid_from=r.date)        # stage 6 — time, always

6. What actually happens when someone asks a question

A common misconception is that GraphRAG replaces vector search. In practice the good systems use both, in sequence. Vectors are excellent at one job — finding where to start — and the graph is excellent at the other: working out what else belongs in the answer.

The 2026 refinement worth knowing is agentic traversal: rather than hard-coding "expand two hops", you let the agent decide when it has enough. It stops early on a simple question and digs deeper on a tangled one — which is both cheaper and more accurate than a fixed depth.

7. The scoreboard: where graphs win, and where they lose

Marketing decks about GraphRAG only show you the wins. Here is the honest picture from published, independent evaluations. Read the bottom two rows as carefully as the top three.

Figures from independent GraphRAG benchmark evaluations published 2025–2026; exact numbers vary by benchmark and by system. Scores are comparable within a row, not across rows.

The practical conclusion the field converged on in 2026 is routing: send simple lookups to vector search, send multi-hop, historical and synthesis questions to the graph. A system that graphs everything is paying a hundred times the price for a tie on most of its traffic.

8. The cost nobody puts on the slide

Building a vector index is cheap: an embedding pass over ten thousand documents costs a few dollars. Building a knowledge graph means an LLM reads the corpus to pull out entities and relationships — the same corpus might cost fifty to a couple of hundred dollars on a small pipeline, and the original Microsoft GraphRAG design was reported to run into five figures on large enterprise datasets in 2024.

That number is what caused the most important design shift in the field. Newer approaches — the "lazy" family — flip the pipeline around:

And the licence for your graph database is the small part of the cost. The real bill is source connectors, schema design, extraction, entity resolution, human review, permissions, keeping edges current, observability and evaluation. Budget for the maintenance, not the migration.

9. The silent killer: entity resolution

If you remember one warning from this tutorial, make it this one. Entity resolution is deciding when two mentions refer to the same real thing. Is "S. Kaur", "Simran Kaur" and "simran.k@…" one person or three? Is "the DE marketplace" the same node as "Germany store"?

Get this slightly wrong and the error does not stay small — it compounds along every hop:

A "95% accurate" extractor sounds excellent until you ask a five-hop question and find that one answer in four is built on a broken link.

This reframes where the effort goes. The glamorous work is traversal algorithms; the work that decides whether your graph is trustworthy is boring identity management — canonical IDs, alias tables, human review on ambiguous merges, and a bias toward not merging when unsure. Over-merging two distinct customers is much harder to detect later than leaving them separate.

10. Should you actually build one?

Graphs are not a free upgrade. Use this as a decision aid rather than a mandate. A pilot is worth running when at least two of these are true of a workflow that genuinely matters to your business — and it is a strong yes at four:

• Your important questions span two or more relationships.
• History matters — relations change and yesterday's answer must not erase last year's.
• Provenance is part of the answer: people need to see why, not just what.
• Several agents or teams share state and need one version of the truth.
• Knowledge should compound across sessions instead of resetting each time.

And be equally willing to say no. Skip the graph when:

• The answer lives in one document — plain retrieval is cheaper and just as good.
• The data is tabular — SQL over reviewed views beats a graph, as we covered in asking your database in plain English.
• The workflow is a fixed sequence — that is ordinary code, not a graph.
• Facts change faster than you can maintain edges — search the source at query time instead.
• It is a one-off question — a search with citations costs a rounding error by comparison.

11. Your first graph, this weekend

You do not need a graph database, a cluster, or a budget to learn this properly. Here is a genuinely useful starter project:

1. Pick one question your team asks monthly and currently answers by digging through five documents. Write the ideal answer by hand first — that is your gold standard.
2. List the node types involved. Usually four or five: Decision, Incident, Policy, Person, Product. Write them down.
3. Write ten edge verbs and stop. Resist the eleventh. supersedes, caused, owns, decided_by, depends_on, mentions, part_of, contradicts, valid_from, valid_until.
4. Extract from twenty documents, not two thousand. Store the result as plain JSON rows of {from, type, to, source, date}. Postgres, SQLite or a file is fine — you do not need Neo4j to learn whether the idea works for you.
5. Give the agent one tool: neighbours(node, edge_types, depth). Let it call that tool as many times as it wants and require it to cite every path it used.
6. Compare against your gold answer, then against plain vector RAG on the same twenty documents. If the graph doesn't win on your question, you have learned something valuable for the price of a weekend.

Every hard lesson in this article shows up at that scale: you will invent an eleventh edge verb by Saturday afternoon, discover two nodes that are secretly the same thing by Sunday morning, and realise your extractor never recorded dates by Sunday evening. Far better to learn it on twenty documents than on twenty thousand.

12. Glossary

Node

A thing in your world — a person, an order, a document, a decision.

Edge

A connection between two nodes. Useful ones carry a verb.

Typed edge

An edge whose relationship is named: supersedes, caused, owns. The difference between a machine that reasons and one that wanders.

Ontology

Your written list of allowed node types and edge verbs. The schema of your knowledge.

Multi-hop

A question that needs two or more relationships followed to answer. Where graphs earn their keep.

GraphRAG

RAG where the retrieval step traverses a graph instead of only ranking chunks by similarity.

Entity resolution

Deciding which mentions refer to the same real thing. The hardest and most under-budgeted part.

Community detection

Clustering densely-connected nodes so the system can summarise a whole region of the graph — how "what are the themes?" questions get answered.

Temporal graph

A graph where every edge records when a fact was true and when you learned it, so history survives updates.

Provenance

The source, timestamp and extraction method attached to an edge — what makes a citation possible.

Hybrid retrieval

Vector search to find entry points, graph traversal to expand from them. The pattern most production systems land on.

Frequently asked questions

Where this leaves you

Graph engineering is not a replacement for everything you have built. It is the answer to one specific, expensive failure: questions whose answers live in the connections between your documents rather than inside any one of them. If you already run RAG over your business data and keep hitting the wall on "why", "since when" and "what changed" questions, that wall has a name now — and a well-mapped route around it.

Start with one question, ten edge verbs and twenty documents. Measure it honestly. Expand only where the graph earns its cost. That discipline — knowing when not to build the graph — is what separates graph engineering from graph enthusiasm.

Talk to us about your AI project