Atlassian's Graph-RAG Numbers, Decoded

In late 2025, Atlassian published an internal evaluation comparing graph-shaped retrieval against vector RAG on their AI assistance workloads. The headline numbers:

• 44% higher accuracy on grounded factual queries
• 48% fewer tokens consumed per response

These numbers got circulated. Most of the circulation flattened them into "graphs beat vectors" — a true summary but a shallow one. The actual result is more specific and more useful. Let's unpack it.

What was measured

The evaluation compared two retrieval architectures backing the same downstream LLM:

• Vector RAG baseline. Standard pipeline: document chunks embedded with a strong off-the-shelf embedding model, stored in a vector database, retrieved by cosine similarity.
• Graph-RAG variant. Entities and relationships extracted from the same corpus, stored in a graph store with typed edges. Retrieval combines lexical, semantic, and graph traversal channels.

The evaluation set was grounded factual queries from real Atlassian product workloads — questions where there's a verifiable correct answer derivable from the source corpus.

Why accuracy improved

The accuracy gain isn't because graphs are "smarter." It's because graphs preserve information the embedding pipeline throws away.

Three specific failure modes that graph-RAG avoids:

Multi-hop reasoning failures. Vector RAG retrieves chunks one at a time. A question like "Who owns the system that depends on the auth service?" requires hopping from auth service → dependent systems → owners. Vector retrieval gets one of these hops right at best and tries to compose them from independent retrievals. Graph traversal does the hop natively.

Entity disambiguation failures. Two people named "Alex" in your corpus. Vector RAG returns chunks mentioning Alex without distinguishing which one. A graph with people as first-class entities distinguishes them explicitly, with each chunk linked to a specific person node.

Recency / supersession failures. A decision made in March superseded a decision made in January. Vector RAG happily returns both as similar; the model has to figure out which one's authoritative from text cues. A graph with explicit "supersedes" edges returns only the current one (or both, but labeled).

Each of these is a category of error that adds up across queries.

Why token usage dropped

The 48% token reduction is, in some ways, the more interesting number. It comes from two effects:

Sharper retrieval. Graph retrieval returns the connected context, not the similar context. The connected context is usually smaller and more focused. Less filler, less off-topic material, fewer tokens in the response.

Less reconstruction overhead. When the model has to reason about relationships that the retrieval layer didn't surface explicitly, it spends output tokens hedging, qualifying, and reconstructing. When the relationships are surfaced directly, the model can answer concisely.

The token reduction matters financially (inference costs scale with tokens) and operationally (smaller responses are faster, easier to audit, less likely to overflow the context window in downstream agentic loops).

What the result does and doesn't generalize to

The Atlassian evaluation was on their internal corpus and their query distribution. The numbers shouldn't be read as "44%/48% is the universal gain from graph-RAG." Different corpora and different query types will produce different numbers.

But the direction is robust, and the explanation generalizes:

• If your queries are mostly "find me passages similar to this concept," vector RAG is fine.
• If your queries involve relationships, entities, recency, or authority — which most real work queries do — graph-shaped retrieval will outperform.

For AI memory specifically, the query distribution is overwhelmingly the second category. People don't ask their AI memory "find me prose similar to this idea." They ask "what did we decide about X?" or "who owns Y?" or "what's the current state of Z?" These are relational questions, and graphs are the right substrate for them.

What we took from this for Memplex

The Atlassian result is part of the reason we built Memplex on a graph substrate from day one. It's also part of the reason we built three retrieval channels rather than just graph traversal — the lexical and semantic channels still matter for specific query types, and the hybrid approach is more robust than any single channel.

The specific implementation choices it influenced:

• Entity extraction as a first-class ingestion step. Memories are connected to typed entities, not just chunked into a vector store.
• Typed edges with explicit relationship semantics. "Supersedes," "depends on," "decided by" — not just "related to."
• Graph traversal weighted higher for relational task hints. The router knows "what was decided about X" is a graph-heavy query.

The result also gave us a defensible technical argument we cite in conversations with technical buyers: the architecture isn't a stylistic preference; the published numbers favor it.

What other teams should take from this

If you're building an AI memory system in 2026 and you're still defaulting to vector-only RAG, you're choosing path-of-least-resistance over architectural fit. The numbers are public. The reasoning is published. The libraries for graph stores exist.

The migration cost is real — vector RAG to graph-aware retrieval is not a trivial swap. But the destination is clear, and the longer the codebase stays single-channel, the more painful the eventual migration. Better to plan for hybrid retrieval now than to retrofit it later.