图工程在微软、斯坦福和 Anthropic 取代了 RAG，这是它的原理

图工程（Graph Engineering）取代了 RAG：微软、斯坦福和 Anthropic 都在用，这里是它的工作原理 2026年7月19日 · 12分钟阅读 · 查看原文 ↗ Claude AI MCP Automation  现在，任何人都能构建一个 AI 系统，它回答复杂问题的准确率比普通 RAG 高 18%，成本却低 85%。不需要博士学位。不需要百万美元预算。不需要研究团队。 你和这个结果之间唯一的障碍，是微软、斯坦福和 Anthropic 各自独立发现的一个概念——而大多数开发者至今还没跟上。 普通 RAG 找到的是文本。图工程找到的是关系。下面是它背后的完整系统。 > **收藏并关注**——我是 Sprytix，一名开发者，构建能把技术变成真实收入的 AI 系统和自动化流水线。欢迎私信。 **为什么普通 RAG 会撞上天花板** 普通 RAG 是这样工作的： ``` Question ↓ Search documents for matching text ↓ Return most relevant chunks ↓ Model generates answer from chunks ``` 这对简单问题很有效。对复杂问题则完全失效。 当你问"为什么我们 3 月份的产品销量下降了？"时，RAG 只会找到含有 "sales" 和 "March" 这些词的文档。它找到的是片段，而不是因果链条。 ``` 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%. ``` 同一个模型。同样的数据。结果却完全不同——因为一个系统搜索文本，另一个系统搜索现实。 这正是微软、斯坦福和 Anthropic 各自独立发现的东西。也是它们三家都转向图工程的原因。 **文档 1——Microsoft GraphRAG** 1. github.com/microsoft/graphrag 2. github.com/microsoft/graphrag/blob/main/docs/index/architecture.md  微软构建了 GraphRAG 并开源了它。他们的研究结果是关于图工程相比普通 RAG 究竟能带来什么的最具体数字。 该架构将非结构化文本转化为一个完整的知识图谱： ``` Load Documents ↓ Chunk Documents ↓ Extract Entities and Relations ↓ Build Graph ↓ Detect Communities ↓ Generate Community Reports ↓ Embed Entities and Reports ↓ Local Search / Global Search ``` 微软记录下的关键洞见是：普通 RAG 擅长回答局部问题——帮我找到关于某个具体实体的信息。它在全局问题上会失败——整个数据集的主要主题是什么，这 10,000 份文档之间由什么模式连接。 图工程两者都能回答。 ``` 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 ``` 来自微软 GraphRAG 研究的实际结果： ``` 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  这些数字来自 ChatP&ID 论文——将 GraphRAG 应用于工业工程图纸。同样的原理适用于各个领域。 **文档 2——Stanford DSPy 与图的联系** 1. github.com/stanfordnlp/dspy 2. arxiv.org/abs/2310.03714 斯坦福的 DSPy 论文确立了一个观点：模型是图中的一个节点——而非宇宙的中心。这是直接连接图工程的理论基础。 DSPy 把 AI 流水线视为一个由模块构成的图： ``` Question ↓ Retriever - finds relevant information ↓ Reasoning - processes and connects ↓ Verifier - checks the result ↓ Answer ``` 它与图工程的联系是直接的：DSPy 优化的是流水线图，GraphRAG 优化的是知识图谱。两者都把模型视为更大结构中的一个组件，而不是整个解决方案。 斯坦福的 STORM 论文走得更远： 1. github.com/stanford-oval/storm 2. arxiv.org/abs/2402.14207 STORM 在动笔写一个字之前，就通过一个结构化的研究步骤图从零构建知识。研究、资料收集、大纲、写作、验证、修订——每一步都受前一步发现的关系所启发。 贯穿所有斯坦福研究的共同洞见是：复杂任务需要一个由相互连接的步骤组成的系统，而不是一次单一的模型调用。图就是那个系统。 **文档 3——斯坦福关于知识图谱的缩放定律** > arxiv.org/abs/2505.16276 这篇论文在知识图谱工程任务上比较了 26 个开源模型。其结论是该领域最重要的结论之一： ``` Larger model + bad graph | worse results Smaller model + good graph | better results ``` 正确的图胜过更大的模型。每一次都是如此。 这正是微软通过 GraphRAG、Anthropic 通过 Claude Code 得出的同一个结论——模型周围的系统对输出的决定作用，大于模型本身。图工程是这一原则最具体的实现。 **文档 4——MIT Press 关于关系记忆的研究** direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476 发表于《计算语言学协会会刊》（Transactions of the Association for Computational Linguistics）。 这项研究展示了当你把一个语言模型连接到关系记忆——一个由关系构成的知识图谱，而不仅仅是文本块——时会发生什么。 ``` Text Context ↓ Retrieve Relevant Relations from Graph ↓ Relational Memory ↓ Language Model ↓ More coherent, more accurate generation ``` 关键发现是：能够访问显式关系结构的模型，比仅从文本工作的模型生成更连贯的文本、犯更少的逻辑错误。 这就是图工程为什么有效的科学解释。模型不必从文本中推断关系。关系在图里是显式的。模型直接使用它们。 **文档 5——KEPLER** 1. direct.mit.edu/tacl/article-abstract/doi/10.1162/tacl_a_00360/98089 2. github.com/THU-KEG/KEPLER KEPLER 将语言模型训练与知识图谱嵌入结合起来。它没有把语言理解和事实知识当作两个独立的问题——而是同时优化两者。 ``` Language Model + Knowledge Embeddings + Knowledge Graph = Model that understands both language and facts ``` 实际意义在于：一个能够访问结构良好的知识图谱的模型，不必去猜测实体之间的关系。它直接查询。在事实性问题上的准确率差异是显著的。 **文档 6——图中的 Anthropic 与 Claude** 1. [www.anthropic.com/customers/graph](http://www.anthropic.com/customers/graph) 2. github.com/anthropics/anthropic-cookbook 3. github.com/modelcontextprotocol Anthropic 并没有一个叫 "Graph Engineering" 的产品。他们有的是三层架构，Claude 在其中直接融入图架构。 **第 1 层——Claude 从文本中提取图** ``` Documents ↓ Claude extracts entities and relationships ↓ JSON triples: { "subject": "Anthropic", "relation": "created", "object": "Claude" } ↓ Knowledge Graph ``` Claude 负责实体提取、关系提取、去重、归一化和本体起草。过去需要专门 NLP 流水线的任务，现在一次 API 调用就能完成。 **第 2 层——Claude 查询图** ``` User Question ↓ Claude ↓ Cypher / SPARQL query ↓ Knowledge Graph ↓ ## Result ↓ Claude explanation in plain language ``` Claude 把自然语言翻译成图查询，针对 Neo4j 或任何图数据库执行，并解释结果。用户无需任何查询语言知识。 **第 3 层——MCP 把 Claude 连接到图** github.com/modelcontextprotocol ``` Claude ↓ MCP Protocol ↓ Graph Database ↓ Entities + Relationships ↓ Claude with full graph context ``` MCP 是传输层，它让 Claude 永久访问任何知识图谱，而无需在每个会话中重新建立连接。 **LaunchNotes 案例——真实的生产数据** [www.anthropic.com/customers/graph](http://www.anthropic.com/customers/graph)  LaunchNotes 构建了一个名为 Graph 的产品，把 GitHub、Jira 和 Linear 连接起来。Claude 分析这三个系统之间工程工作的关系。 ``` GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ Claude ↓ Incident Detection + Project Insights ``` 来自 Anthropic 案例研究的结果： ``` Incident detection | up to 5x faster Meeting time | approximately 50% reduction Release notes | generated automatically in seconds ``` 这些数字来自连接结构化的关系数据——而不仅仅是搜索文档。 **知识图谱到底是什么** 在构建之前——先了解基本概念。 知识图谱以三元组的形式存储信息： ``` Subject → Relation → Object ``` 示例： ``` Anthropic → created → Claude Claude → supports → MCP MCP → connects → external tools Microsoft → built → GraphRAG GraphRAG → reduces token cost by → 85% ``` 每一条信息都是两个实体之间的一种显式关系。不是一段可能包含该信息的文本——而是一个显式的、结构化的、可查询的事实。 ``` 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 ``` 图不只是存储事实。它存储事实之间如何相互连接。这才是让复杂推理成为可能的东西。 **完整的图工程流水线** ``` 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 ``` arxiv.org/abs/2307.06917 上的《LLM 辅助知识图谱工程》论文基准测试了语言模型处理其中每一步的表现。诚实的结论是：LLM 在提取和归一化方面是出色的助手，但在模式（schema）和去重步骤上如果没有人工审核，零样本图生成目前还不足以可靠地用于生产环境。 **驱动整条流水线的五个提示词** 图工程并不消除提示词。它在图流水线的每一个具体阶段使用它们。 **提示词 1——提取** ``` 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 ``` **提示词 2——归一化** ``` 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. ``` **提示词 3——图查询** ``` 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. ``` **提示词 4——有依据的回答** ``` 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 ``` **提示词 5——图维护** ``` Compare new facts with the existing graph. Classify each fact as: - new - duplicate - contradiction - update - uncertain Do not overwrite existing facts without evidence. ``` 正如微软的 GraphRAG 文档所示——提示词在内部负责提取、关系识别、摘要和社区报告生成。提示词工程是图工程内部的机制，而不是它的竞争对手。 **你可以基于知识图谱构建的五种业务** **1——尽职调查平台** ``` Corporate reports + founders + investors + legal cases + subsidiaries + transactions ↓ Knowledge Graph ↓ Claude ↓ Risk analysis + hidden connections + conflict of interest detection ``` 客户：投资基金、律师事务所、银行、并购顾问。每个客户每月 $2,000-10,000 的顾问费。 **2——销售情报** ``` 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——工程情报** ``` GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ 5x faster incident detection 50% less meeting time Automatic release notes ``` LaunchNotes 已经在卖这个了。市场是每一个使用不止一个项目管理工具的工程团队。 **4——研究情报** ``` 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——个人知识操作系统** ``` 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 ``` **连接微软、斯坦福和 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 懂得词语。知识图谱懂得关系。当两者协同工作时，最强大的 AI 系统便会出现。 微软用 GraphRAG 在生产环境中证明了这一点——准确率提高 18%，成本降低 85%。斯坦福用 DSPy、STORM 和缩放定律论文在研究上证明了这一点。Anthropic 用 LaunchNotes 案例证明了这一点——事件检测快 5 倍，会议时间减少 50%。 三个组织。三条独立的路径。一个结论。 模型找到的是文本。图找到的是现实。去构建图吧。 大多数开发者会继续打磨他们的提示词，然后纳闷为什么复杂问题仍然给出糟糕的答案。少数人会花一个周末构建他们的第一个知识图谱，从此再也不回去搜索文档。 / 如果这对你有用——请关注，下一篇会先在这里发布。 标签：# X # Claude # AI # MCP # Automation # Guide 相关文章 斯坦福和 Anthropic 发现了一个比任何 AI 模型都更强大的系统。 收藏并关注——我是 Noryxx，一名牛津学生，构建 AI 系统和自动化流水线。我分享项目、实验以及把技术转化为真实价值的实用方法。欢迎私信。 Claude AI MCP Automation 如何构建你自己的 JARVIS：个人 AI 操作系统 如果你仍然把 AI 当作一个只是去提问要答案的聊天机器人，你就把大部分杠杆都留在了桌上。有一种不同的搭建方式：一个不只是回答问题的 AI 系统…… AI Claude Automation MCP 大多数人把 Claude Code 当成聊天机器人用。它其实是 AI 智能体的完整操作系统。 我看过一位开发者在直播中用 Claude Code 构建了整个项目。没有幻灯片，没有理论。只有终端。然后在某个时刻我意识到：六个月来，我大概只用到了这个工具 15% 的功能。 Claude MCP AI Automation