Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works.

Right now anyone can build an AI system that answers complex questions with 18% better accuracy and 85% lower costs than regular RAG. No PhD. No million dollar budget. No team of researchers.

The only thing standing between you and that result is one concept that Microsoft, Stanford and Anthropic all independently discovered - and which most developers still haven't caught up with.

Regular RAG finds text. Graph Engineering finds relationships. Here's the full system behind it.

Bookmark This and follow

- I'm Sprytix, a developer who builds AI systems and automation pipelines that turn technology into real income. DMs open.

Why regular RAG hits a ceiling

Regular RAG works like this:

1Question
2↓
3Search documents for matching text
4↓
5Return most relevant chunks
6↓
7Model generates answer from chunks

This works well for simple questions. It breaks completely for complex ones.

Ask "why did our product sales drop in March?" and RAG finds documents with the words "sales" and "March." It finds fragments. It does not find the chain of causation.

1RAG answer:
2Here are 5 documents mentioning sales in March.
3
4Graph Engineering answer:
5Sales dropped because of a release delay
6caused by a supplier dependency
7triggered by a warehouse problem
8which generated negative reviews
9which reduced conversion by 23%.

Same model. Same data. Completely different result - because one system searches text and the other searches reality.

This is what Microsoft, Stanford and Anthropic all independently discovered. And it's why all three of them moved to Graph Engineering.

Document 1 - Microsoft GraphRAG

1. github.com/microsoft/graphrag
2. github.com/microsoft/graphrag/blob/main/docs/index/architecture.md

Microsoft built GraphRAG and open-sourced it. The results from their research are the most concrete numbers available on what Graph Engineering actually delivers versus regular RAG.

The architecture converts unstructured text into a full knowledge graph:

1Load Documents
2↓
3Chunk Documents
4↓
5Extract Entities and Relations
6↓
7Build Graph
8↓
9Detect Communities
10↓
11Generate Community Reports
12↓
13Embed Entities and Reports
14↓
15Local Search / Global Search

The key insight Microsoft documented: regular RAG answers local questions well - find me information about this specific entity. It fails on global questions - what are the main themes across this entire dataset, what patterns connect these 10,000 documents.

Graph Engineering answers both.

1Local Search   |  what happened with supplier X in March
2               |  finds specific node and its connections
3
4Global Search  |  what are the main risk patterns across
5               |  all our supplier relationships
6               |  finds patterns across entire graph

Practical results from Microsoft's GraphRAG research:

1Accuracy improvement    |  18% higher than raw document approach
2Token cost reduction    |  85% lower than loading structured files directly
3Cost per task           |  approximately $0.004 in tested configuration

arxiv.org/abs/2603.22528

These numbers come from the ChatP&ID paper - GraphRAG applied to industrial engineering diagrams. The same principles apply across domains.

Document 2 - Stanford DSPy and the graph connection

1. github.com/stanfordnlp/dspy
2. arxiv.org/abs/2310.03714

Stanford's DSPy paper established that the model is a node in a graph - not the center of the universe. This is the theoretical foundation that connects directly to Graph Engineering.

DSPy treats the AI pipeline as a graph of modules:

1Question
2↓
3Retriever      - finds relevant information
4↓
5Reasoning      - processes and connects
6↓
7Verifier       - checks the result
8↓
9Answer

The connection to Graph Engineering is direct: DSPy optimizes the pipeline graph, GraphRAG optimizes the knowledge graph. Both treat the model as one component in a larger structure rather than the entire solution.

Stanford's STORM paper goes further:

1. github.com/stanford-oval/storm
2. arxiv.org/abs/2402.14207

STORM builds knowledge from scratch through a structured graph of research steps before writing a single word. Research, source collection, outline, writing, verification, revision - each step informed by the relationships discovered in the previous one.

The shared insight across all Stanford research: complex tasks need a system of connected steps, not a single model call. The graph is the system.

Document 3 - Stanford scaling laws for knowledge graphs

arxiv.org/abs/2505.16276

This paper compared 26 open-source models on knowledge graph engineering tasks. The conclusion is one of the most important in the field:

1Larger model + bad graph   |  worse results
2Smaller model + good graph |  better results

The right graph beats the bigger model. Every time.

This is the same conclusion Microsoft reached with GraphRAG and Anthropic reached with Claude Code - the system around the model determines the output more than the model itself. Graph Engineering is the most concrete implementation of that principle.

Document 4 - MIT Press research on relational memory

direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476

Published in Transactions of the Association for Computational Linguistics.

The research shows what happens when you connect a language model to relational memory - a knowledge graph of relationships rather than just text chunks.

1Text Context
2↓
3Retrieve Relevant Relations from Graph
4↓
5Relational Memory
6↓
7Language Model
8↓
9More coherent, more accurate generation

The key finding: models with access to explicit relationship structures produce more coherent text and make fewer logical errors than models working from text alone.

This is the scientific explanation for why Graph Engineering works. The model doesn't have to infer relationships from text. The relationships are explicit in the graph. The model uses them directly.

Document 5 - KEPLER

1. direct.mit.edu/tacl/article-abstract/doi/10.1162/tacl_a_00360/98089
2. github.com/THU-KEG/KEPLER

KEPLER combines language model training with knowledge graph embeddings. Instead of treating language understanding and factual knowledge as separate problems - KEPLER optimizes both simultaneously.

1Language Model
2+
3Knowledge Embeddings
4+
5Knowledge Graph
6=
7Model that understands both language and facts

The practical implication: a model that has access to a properly structured knowledge graph doesn't have to guess at relationships between entities. It looks them up. The accuracy difference on factual questions is significant.

Document 6 - Anthropic and Claude in the graph

1. www.anthropic.com/customers/graph
2. github.com/anthropics/anthropic-cookbook
3. github.com/modelcontextprotocol

Anthropic doesn't have a product called "Graph Engineering." What they have is three layers where Claude integrates directly into graph architecture.

Layer 1 - Claude extracts the graph from text

1Documents
2↓
3Claude extracts entities and relationships
4↓
5JSON triples:
6{
7  "subject": "Anthropic",
8  "relation": "created",
9  "object": "Claude"
10}
11↓
12Knowledge Graph

Claude handles entity extraction, relation extraction, deduplication, normalization and ontology drafting. The tasks that used to require specialized NLP pipelines now run through one API call.

Layer 2 - Claude queries the graph

1User Question
2↓
3Claude
4↓
5Cypher / SPARQL query
6↓
7Knowledge Graph
8↓
9Result
10↓
11Claude explanation in plain language

Claude translates natural language into graph queries, runs them against Neo4j or any graph database and explains the results. No query language knowledge required from the user.

Layer 3 - MCP connects Claude to the graph

github.com/modelcontextprotocol

1Claude
2↓
3MCP Protocol
4↓
5Graph Database
6↓
7Entities + Relationships
8↓
9Claude with full graph context

MCP is the transport layer that gives Claude permanent access to any knowledge graph without rebuilding the connection for every session.

The LaunchNotes case - real production numbers

www.anthropic.com/customers/graph

LaunchNotes built a product called Graph that connects GitHub, Jira and Linear. Claude analyzes the relationships between engineering work across all three systems.

1GitHub commits
2+
3Jira tickets
4+
5Linear tasks
6↓
7Graph of Engineering Work
8↓
9Claude
10↓
11Incident Detection + Project Insights

Results from the Anthropic case study:

1Incident detection     |  up to 5x faster
2Meeting time           |  approximately 50% reduction
3Release notes          |  generated automatically in seconds

These numbers come from connecting structured relationship data - not just searching documents.

What a knowledge graph actually is

Before building one - the fundamental concept.

A knowledge graph stores information as triples:

1Subject → Relation → Object

Examples:

1Anthropic → created → Claude
2Claude → supports → MCP
3MCP → connects → external tools
4Microsoft → built → GraphRAG
5GraphRAG → reduces token cost by → 85%

Every piece of information is an explicit relationship between two entities. Not a paragraph of text that might contain this information - an explicit, structured, queryable fact.

1Regular database:
2Table of companies
3Table of products
4No explicit relationships between them
5
6Knowledge graph:
7Company → created → Product
8Product → competes with → Other Product
9Other Product → owned by → Other Company
10Company → invested in → Other Company

The graph doesn't just store facts. It stores how facts connect to each other. That's what makes complex reasoning possible.

The full Graph Engineering pipeline

1Step 1  |  Collect raw documents
2        |  PDFs, emails, reports, database exports
3
4Step 2  |  Extract entities
5        |  people, companies, products, events, concepts
6
7Step 3  |  Extract relationships
8        |  who did what to whom, when, why, how
9
10Step 4  |  Build schema
11        |  define entity types and relationship types
12
13Step 5  |  Deduplicate and normalize
14        |  "Microsoft Corp" and "MSFT" are the same entity
15
16Step 6  |  Store in graph database
17        |  Neo4j, Amazon Neptune, PostgreSQL with graph extension
18
19Step 7  |  Build retrieval layer
20        |  local search for specific entities
21        |  global search for patterns across entire graph
22
23Step 8  |  Connect model
24        |  Claude queries graph via MCP or direct API
25
26Step 9  |  Update continuously
27        |  new documents expand the graph
28        |  contradictions get flagged for review

The LLM-assisted Knowledge Graph Engineering paper at arxiv.org/abs/2307.06917 benchmarks how well language models handle each of these steps. The honest finding: LLMs are excellent assistants for extraction and normalization but zero-shot graph generation is not yet reliable enough for production without human review on the schema and deduplication steps.

The five prompts that run the entire pipeline

Graph Engineering doesn't eliminate prompts. It uses them at each specific stage of the graph pipeline.

Prompt 1 - Extraction

1Extract all organizations, people, products and events.
2
3For each entity return:
4- canonical_name
5- type
6- description
7- source
8
9For each relationship return:
10- source_entity
11- relation_type
12- target_entity
13- evidence
14- confidence_score

Prompt 2 - Normalization

1Compare the following entities.
2Determine whether they refer to:
3- the same entity
4- related but different entities
5- unrelated entities
6
7Return canonical name and explanation.
8Do not merge entities without clear evidence.

Prompt 3 - Graph query

1Translate the user question into a Cypher query.
2Use only relationships present in the schema.
3Do not invent labels or properties.
4Return the query and a short explanation of the logic.

Prompt 4 - Grounded answer

1Answer using only the retrieved graph paths.
2For every conclusion:
3- identify the supporting nodes
4- identify the relationship path
5- state uncertainty clearly
6- do not infer causation from correlation

Prompt 5 - Graph maintenance

1Compare new facts with the existing graph.
2Classify each fact as:
3- new
4- duplicate
5- contradiction
6- update
7- uncertain
8
9Do not overwrite existing facts without evidence.

As Microsoft's GraphRAG documentation shows - prompts handle extraction, relationship identification, summarization and community report generation internally. Prompt engineering is the mechanism inside graph engineering, not its competitor.

Five businesses you can build on a knowledge graph

1 - Due diligence platform

1Corporate reports + founders + investors
2+ legal cases + subsidiaries + transactions
3↓
4Knowledge Graph
5↓
6Claude
7↓
8Risk analysis + hidden connections + conflict of interest detection

Clients: investment funds, law firms, banks, M&A consultants. Monthly retainer $2,000-10,000 per client.

2 - Sales intelligence

1Contacts + companies + roles
2+ previous emails + company problems + product
3↓
4Knowledge Graph
5↓
6Who influences the decision
7Which objections repeat
8Which case study to show this specific client
9Where the deal is blocked

3 - Engineering intelligence

1GitHub commits + Jira tickets + Linear tasks
2↓
3Graph of Engineering Work
4↓
55x faster incident detection
650% less meeting time
7Automatic release notes

LaunchNotes already sells this. The market is every engineering team that uses more than one project management tool.

4 - Research intelligence

1Papers + authors + institutions
2+ methods + datasets + results + contradictions
3↓
4Knowledge Graph
5↓
6Which GraphRAG methods use community detection
7On which datasets they were tested
8Which papers contradict each other

5 - Personal knowledge OS

1Obsidian notes + emails + calendar
2+ PDFs + contacts + tasks
3↓
4Personal Knowledge Graph
5↓
6Who did I discuss this idea with
7Which tasks depend on one person's response
8Which decisions contradict previous agreements
9What did I promise to do this month

The shift that connects Microsoft, Stanford and Anthropic

1Prompt Engineering   |  how to ask the right question
2RAG                  |  which document to find
3Graph Engineering    |  which entities exist
4                     |  how they connect
5                     |  which path leads to the answer
6                     |  what changes if one node changes

LLM knows words. Knowledge graph knows relationships. The most powerful AI systems appear when both work together.

Microsoft proved this in production with GraphRAG - 18% better accuracy, 85% lower costs. Stanford proved it in research with DSPy, STORM and the scaling laws paper. Anthropic proved it in the LaunchNotes case - 5x faster incident detection, 50% less meeting time.

Three organizations. Three independent paths. One conclusion.

The model finds text. The graph finds reality. Build the graph.

Most developers will keep improving their prompts and wonder why complex questions still give bad answers. A few will spend one weekend building their first knowledge graph and never go back to searching documents.

/ If this was useful - follow, the next one drops here first.