图工程替代 RAG：微软、斯坦福与 Anthropic 的实践与收益

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:

Question
↓
Search documents for matching text
↓
Return most relevant chunks
↓
Model 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.

RAG answer:
Here are 5 documents mentioning sales in March.

Graph Engineering answer:
Sales dropped because of a release delay
caused by a supplier dependency
triggered by a warehouse problem
which generated negative reviews
which 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.

问题
↓
在文档中搜索匹配文本
↓
返回最相关的片段
↓
模型根据片段生成答案

RAG答案：
以下是5份提到三月销售的文档。

图工程答案：
销量下降是因为发布延迟
由供应商依赖引发
被仓库问题触发
产生了负面评论
导致转化率降低23%。

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:

Load Documents
↓
Chunk Documents
↓
Extract Entities and Relations
↓
Build Graph
↓
Detect Communities
↓
Generate Community Reports
↓
Embed Entities and Reports
↓
Local 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.

Local Search   |  what happened with supplier X in March
               |  finds specific node and its connections

Global Search  |  what are the main risk patterns across
               |  all our supplier relationships
               |  finds patterns across entire graph

Practical results from Microsoft's GraphRAG research:

Accuracy improvement    |  18% higher than raw document approach
Token cost reduction    |  85% lower than loading structured files directly
Cost 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.

加载文档
↓
分块文档
↓
提取实体与关系
↓
构建图
↓
检测社区
↓
生成社区报告
↓
嵌入实体与报告
↓
本地搜索 / 全局搜索

本地搜索   |  供应商X在三月发生了什么
          |  找到特定节点及其连接

全局搜索  |  所有供应商关系中的主要风险模式
          |  在整个图中寻找模式

准确率提升    |  比纯文档方法高18%
Token成本降低  |  比直接加载结构化文件低85%
单任务成本    |  约$0.004（在测试配置下）

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:

Question
↓
Retriever      - finds relevant information
↓
Reasoning      - processes and connects
↓
Verifier       - checks the result
↓
Answer

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:

Larger model + bad graph   |  worse results
Smaller 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.

Text Context
↓
Retrieve Relevant Relations from Graph
↓
Relational Memory
↓
Language Model
↓
More 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.

Language Model
+
Knowledge Embeddings
+
Knowledge Graph
=
Model 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

Documents
↓
Claude extracts entities and relationships
↓
JSON triples:
{
  "subject": "Anthropic",
  "relation": "created",
  "object": "Claude"
}
↓
Knowledge 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

User Question
↓
Claude
↓
Cypher / SPARQL query
↓
Knowledge Graph
↓
Result
↓
Claude 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

Claude
↓
MCP Protocol
↓
Graph Database
↓
Entities + Relationships
↓
Claude 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.

GitHub commits
+
Jira tickets
+
Linear tasks
↓
Graph of Engineering Work
↓
Claude
↓
Incident Detection + Project Insights

Results from the Anthropic case study:

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

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

文档
↓
Claude提取实体与关系
↓
JSON三元组：
{
  "subject": "Anthropic",
  "relation": "created",
  "object": "Claude"
}
↓
知识图谱

用户问题
↓
Claude
↓
Cypher / SPARQL查询
↓
知识图谱
↓
结果
↓
Claude用通俗语言解释

Claude
↓
MCP协议
↓
图数据库
↓
实体 + 关系
↓
拥有完整图上下文的Claude

GitHub提交
+
Jira工单
+
Linear任务
↓
工程工作图
↓
Claude
↓
事件检测 + 项目洞察

事件检测      |  快至5倍
会议时间      |  减少约50%
发布说明      |  秒级自动生成

What a knowledge graph actually is

Before building one - the fundamental concept.

A knowledge graph stores information as triples:

Subject → Relation → Object

Examples:

Anthropic → created → Claude
Claude → supports → MCP
MCP → connects → external tools
Microsoft → built → GraphRAG
GraphRAG → 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.

Regular database:
Table of companies
Table of products
No explicit relationships between them

Knowledge graph:
Company → created → Product
Product → competes with → Other Product
Other Product → owned by → Other Company
Company → 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.

主体 → 关系 → 客体

Anthropic → 创建 → Claude
Claude → 支持 → MCP
MCP → 连接 → 外部工具
微软 → 构建 → GraphRAG
GraphRAG → 降低token成本 → 85%

常规数据库：
公司表
产品表
它们之间没有明确关系

知识图谱：
公司 → 创建 → 产品
产品 → 与...竞争 → 其他产品
其他产品 → 属于 → 其他公司
公司 → 投资 → 其他公司

The full Graph Engineering pipeline

Step 1  |  Collect raw documents
        |  PDFs, emails, reports, database exports

Step 2  |  Extract entities
        |  people, companies, products, events, concepts

Step 3  |  Extract relationships
        |  who did what to whom, when, why, how

Step 4  |  Build schema
        |  define entity types and relationship types

Step 5  |  Deduplicate and normalize
        |  "Microsoft Corp" and "MSFT" are the same entity

Step 6  |  Store in graph database
        |  Neo4j, Amazon Neptune, PostgreSQL with graph extension

Step 7  |  Build retrieval layer
        |  local search for specific entities
        |  global search for patterns across entire graph

Step 8  |  Connect model
        |  Claude queries graph via MCP or direct API

Step 9  |  Update continuously
        |  new documents expand the graph
        |  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.

步骤1  |  收集原始文档
        |  PDF、邮件、报告、数据库导出

步骤2  |  提取实体
        |  人物、公司、产品、事件、概念

步骤3  |  提取关系
        |  谁对谁做了什么、何时、为何、如何

步骤4  |  构建模式
        |  定义实体类型和关系类型

步骤5  |  去重与归一化
        |  "Microsoft Corp"和"MSFT"是同一实体

步骤6  |  存储到图数据库
        |  Neo4j、Amazon Neptune、带图扩展的PostgreSQL

步骤7  |  构建检索层
        |  本地搜索特定实体
        |  全局搜索整个图中的模式

步骤8  |  连接模型
        |  Claude通过MCP或直接API查询图

步骤9  |  持续更新
        |  新文档扩展图
        |  矛盾标记待审核

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

Extract all organizations, people, products and events.

For each entity return:
- canonical_name
- type
- description
- source

For each relationship return:
- source_entity
- relation_type
- target_entity
- evidence
- confidence_score

Prompt 2 - Normalization

Compare the following entities.
Determine whether they refer to:
- the same entity
- related but different entities
- unrelated entities

Return canonical name and explanation.
Do not merge entities without clear evidence.

Prompt 3 - Graph query

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

Prompt 4 - Grounded answer

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

Prompt 5 - Graph maintenance

Compare new facts with the existing graph.
Classify each fact as:
- new
- duplicate
- contradiction
- update
- uncertain

Do 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.

提取所有组织、人物、产品和事件。

对每个实体返回：
- canonical_name（规范名称）
- type（类型）
- description（描述）
- source（来源）

对每个关系返回：
- source_entity（源实体）
- relation_type（关系类型）
- target_entity（目标实体）
- evidence（证据）
- confidence_score（置信度分数）

比较以下实体。
确定它们是否指向：
- 同一实体
- 相关但不同的实体
- 不相关的实体

返回规范名称和解释。
没有明确证据时不要合并实体。

将用户问题翻译成Cypher查询。
只使用模式中已有的关系。
不要捏造标签或属性。
返回查询和简短逻辑解释。

仅使用检索到的图路径来回答。
对每个结论：
- 识别支持的节点
- 识别关系路径
- 清晰说明不确定性
- 不要从相关性推断因果

将新事实与现有图比较。
将每个事实分类为：
- 新
- 重复
- 矛盾
- 更新
- 不确定

没有证据时不要覆盖已有事实。

Five businesses you can build on a knowledge graph

1 - Due diligence platform

Corporate reports + founders + investors
+ legal cases + subsidiaries + transactions
↓
Knowledge Graph
↓
Claude
↓
Risk 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

Contacts + companies + roles
+ previous emails + company problems + product
↓
Knowledge Graph
↓
Who influences the decision
Which objections repeat
Which case study to show this specific client
Where the deal is blocked

3 - Engineering intelligence

GitHub commits + Jira tickets + Linear tasks
↓
Graph of Engineering Work
↓
5x faster incident detection
50% less meeting time
Automatic release notes

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

4 - Research intelligence

Papers + authors + institutions
+ methods + datasets + results + contradictions
↓
Knowledge Graph
↓
Which GraphRAG methods use community detection
On which datasets they were tested
Which papers contradict each other

5 - Personal knowledge OS

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

The shift that connects Microsoft, Stanford and Anthropic

Prompt Engineering   |  how to ask the right question
RAG                  |  which document to find
Graph Engineering    |  which entities exist
                     |  how they connect
                     |  which path leads to the answer
                     |  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.

公司报告 + 创始人 + 投资者
+ 法律案件 + 子公司 + 交易
↓
知识图谱
↓
Claude
↓
风险分析 + 隐藏关联 + 利益冲突检测

联系人 + 公司 + 角色
+ 历史邮件 + 公司问题 + 产品
↓
知识图谱
↓
谁影响决策
哪些反对意见重复出现
对该客户应展示哪个案例
交易卡在哪个环节

GitHub提交 + Jira工单 + Linear任务
↓
工程工作图
↓
事件检测快5倍
会议时间减少50%
自动发布说明

论文 + 作者 + 机构
+ 方法 + 数据集 + 结果 + 矛盾
↓
知识图谱
↓
哪些GraphRAG方法使用了社区检测
在哪些数据集上测试
哪些论文相互矛盾

Obsidian笔记 + 邮件 + 日历
+ PDF + 联系人 + 任务
↓
个人知识图谱
↓
我和谁讨论过这个想法
哪些任务依赖某个人的回复
哪些决策与先前协议矛盾
我这个月承诺了什么

提示工程   |  如何提出正确的问题
RAG        |  要查找哪个文档
图工程     |  存在哪些实体
          |  它们如何连接
          |  哪条路径通向答案
          |  如果某个节点变化会发生什么