如果把过去一年 AI 应用层最明显的演化压成一句话大概可以这么说Prompt engineering 解决“怎么问”RAG 解决“去哪里找”Graph engineering 开始解决“这些东西到底怎么连起来”这篇文章想讲的就是为什么越来越多复杂问答系统已经不满足于“找到最相关的几段文本”而是开始往 graph 走。作者的原话有点营销味但核心判断我觉得是成立的普通 RAG 擅长找文本Graph Engineering 擅长找关系。这两个看起来只差一个词实际差的是系统能不能处理复杂因果链、跨文档模式和结构化推理。为什么普通 RAG 很快会撞到天花板先把普通 RAG 说清楚。它的经典流程是问题 ↓ 在文档里搜索相似文本 ↓ 取回最相关的 chunks ↓ 模型根据 chunks 生成答案这个模式在很多场景里已经很好用了• FAQ• 文档问答• 已知术语查找• 单实体信息提取但它一碰到复杂问题问题就开始暴露。比如你问为什么我们 3 月份产品销量下降了一个普通 RAG 往往会找出• 提到 sales 的文档• 提到 March 的文档• 提到 campaign、release、review 的几个片段它能找到“相关词”但不一定能找到“关系链”。真正难的从来不是找出几个相关片段而是把这条链拉出来• 销量下降• 因为版本延期• 版本延期• 因为供应商依赖出问题• 供应商依赖出问题• 又触发了仓储问题和负面评价• 最终转化率下降了 23%这不是“关键词相似度”问题而是“关系结构”问题。这也正是作者想强调的RAG 找的是文本邻近性图系统找的是现实中的连接路径。Graph Engineering 到底多了什么很多人一听 graph会以为只是“把向量库换成图数据库”。其实核心并不在数据库本身而在于你不再只存文档而是显式存实体与关系。也就是把信息写成一种结构Subject → Relation → Object比如• Anthropic → created → Claude• Claude → supports → MCP• Microsoft → built → GraphRAG和普通文档存储的差异在于• 文本里“可能包含这个关系”• 图里“明确声明这条关系存在”前者靠模型从片段里再去猜后者直接把关系作为可查询对象暴露出来。这就是为什么复杂推理时两者体验完全不一样。微软 GraphRAG把“全局问题”从文本搜索里解放出来文章引用的第一条主线是微软的 GraphRAG。它的核心流程非常典型加载文档 ↓ 切分文档 ↓ 抽取实体和关系 ↓ 构建图 ↓ 做社区检测 ↓ 生成社区报告 ↓ 嵌入实体和报告 ↓ 本地搜索 / 全局搜索这里最关键的不是“图比 chunk 高级”而是微软把问题拆成了两类1. Local Search适合问• 某个供应商 3 月发生了什么• 某个实体有哪些直接相关事件也就是围绕一个节点及其邻域展开。2. Global Search适合问• 这一整批文档里最主要的风险模式是什么• 这些供应商网络里重复出现了哪些结构性问题这类问题普通 RAG 很难做因为它不是找一个最相似 chunk而是要从大范围关系中抽主题、找模式、做归纳。文章里还提到微软论文里给出的数据• 准确率提升约 18%• token 成本相比某些原始结构化文件直接加载方案下降约 85%这些数字当然有具体实验前提不能拿来无脑外推但它至少说明了一件事当问题从“找文本”升级到“找结构关系”GraphRAG 不是小修小补而是换了搜索对象。斯坦福模型不是宇宙中心模型只是图里的一个节点文章第二条主线是斯坦福的 DSPy、STORM 和相关 scaling law 研究。我觉得最值得带走的不是某个具体框架而是一个系统观模型只是系统中的一个模块不是整个系统本身。这和 graph engineering 的精神非常一致。DSPy 那类管线本质上就已经是一个图• Retriever• Reasoning• Verifier• Answer也就是说真正有价值的不是“模型一次回答得多漂亮”而是• 信息怎么被取回来• 中间怎么被处理• 结果怎么被验证而 STORM 更进一步甚至在正式写作前先组织研究步骤• research• source collection• outline• writing• verification• revision每一步都建立在前一步形成的关系结构上。这和 GraphRAG 优化知识图谱是同一方向的两个面• 一个在优化“知识的结构”• 一个在优化“任务流程的结构”共同点都是复杂任务不能靠一次模型调用解决必须依赖一个有结构的系统。更大的模型不一定打得过更好的图文章引用的一类研究结论我觉得特别值得记住Larger model bad graph worse resultsSmaller model good graph better results这句话不该被理解成“大模型不重要”而是模型能力不是唯一决定项系统结构会强烈影响最终表现。这和我们最近看到的很多 agent、loop、workflow 文章其实是同一个结论• 不是模型单点更强就够了• 周围的结构决定了它能不能稳定输出Graph engineering 只是这个原则在“知识组织与检索”上的一个非常具体的落地。为什么“关系型记忆”会让模型更稳文章还引用了 MIT Press 那类关于 relational memory 的研究。这部分背后的逻辑其实不复杂如果模型拿到的只是文本块它必须自己在上下文里推断• 谁和谁有关• 因果链在哪里• 哪些是同一个实体的不同写法而如果系统提前把这些关系显式建好模型就不用再靠模糊推断去“猜连接”而是直接利用这些连接。这通常会带来两个好处生成更连贯逻辑错误更少因为关系不再隐藏在段落里而是变成可查询、可验证的结构。Anthropic 那条线不是叫 Graph Engineering但本质已经是图系统文章第三条主线放在 Anthropic我觉得这个角度挺有意思。Anthropic 并没有推出一个名字就叫 “Graph Engineering” 的产品但它的很多能力实际上已经非常接近这套思路。作者拆成了三层1. Claude 从文本里抽图也就是• 实体抽取• 关系抽取• 去重• 归一化• ontology 草拟这些以前需要一整条 NLP pipeline 的工作现在经常可以用一次或少数几次模型调用完成。2. Claude 查询图自然语言问题进来后模型把它翻译成图查询• Cypher• SPARQL然后再把结果解释回人话。这里真正值钱的是用户不需要懂图查询语言但系统可以沿着关系图拿答案。3. MCP 让 Claude 和图的连接变成长期能力MCP 在这里像运输层• Claude• 通过 MCP• 连接图数据库或外部关系系统于是模型不是每次临时读一批文本而是持续拥有对图结构的访问能力。这点特别像我们最近在 agent 系统里反复看到的演化真正强的系统不是每轮都重新解释世界而是把世界结构接成长期上下文。什么才叫“知识图谱”而不是“几张表”文章后半段有个很基础、但很容易被忽略的提醒。普通数据库和知识图谱的区别不只是存储方式而是关系是否被显式建模。比如普通数据库• company 表• product 表• case 表有时候这些东西也能 join但系统中心并不天然放在“关系”上。知识图谱• Company → created → Product• Product → competes_with → Other Product• Other Product → owned_by → Other Company这时候图不只是“存事实”而是在存事实彼此怎么连接而复杂问答真正要用的往往正是这层东西。一条比较稳的 Graph Engineering 流水线长什么样文章给了一个挺完整的 pipeline我觉得可以压成 9 步理解收集原始文档抽实体抽关系设计 schema去重和归一化存进图数据库建 retrieval 层把模型接进来持续更新并处理矛盾这里我最同意的一点是文章引用研究时说得比较诚实LLM 很适合做抽取和归一化的助手但 zero-shot 全自动图生成在生产里还不够可靠尤其 schema 和 dedup 这些步骤仍然需要人工审查这点很重要。如果有人把 graph engineering 讲成“丢给模型一次跑完”那基本就又回到另一种营销文了。Prompt 没消失它只是被塞进图流水线的每个位置这篇文章有个我很喜欢的提醒graph engineering 并没有淘汰 prompt它只是把 prompt 从“总控制台”拆成了“分工明确的局部工具”比如• extraction prompt抽实体和关系• normalization prompt判断是不是同一实体• graph query prompt把自然语言翻成查询• grounded answer prompt只沿着检索出的图路径回答• maintenance prompt判断新事实是新增、重复、矛盾还是更新这其实和我们最近处理的 graph / workflow / loop 文章完全一致真正成熟的系统不是少了 prompt而是 prompt 被嵌进结构里、各司其职。这套东西最适合哪些业务文章最后列了几类业务我觉得虽然带点“到处都能创业”的味道但方向上是对的。真正适合 graph 的通常不是简单 FAQ而是那些“关系本身就是价值来源”的场景比如1. 尽调 / 风险分析• 创始人• 投资人• 法律案件• 子公司• 交易关系这种场景里隐藏连接本身就是答案。2. 销售信息系统• 联系人• 公司• 角色• 历史邮件• objections• case studies这里价值在于谁影响决策、交易卡在哪、该拿哪条证据去推进。3. 工程情报系统• GitHub• Jira• Linear一旦把这些系统之间的关系建图你问的就不只是“有多少 ticket”而是• 这个 incident 跟哪批提交相关• 哪个 release note 应该自动生成• 哪些任务之间存在依赖4. 研究情报• 论文• 作者• 机构• 方法• 数据集• 结论与矛盾这是 graph 非常自然的舞台。5. 个人知识系统• 笔记• 邮件• 日历• 联系人• 任务当你开始问“我之前和谁聊过这件事”“这个任务依赖谁回复”“这个决定和过去哪次承诺冲突”图结构就会明显比文本搜索更自然。我对这篇文章的结论这篇文章最值得带走的不是某个具体产品名而是它帮你把三件事分清了1. Prompt engineering 解决“怎么提问”2. RAG 解决“去哪找文本”3. Graph engineering 开始解决“这些实体与事实之间到底怎么连”当问题只是找一段相关说明时RAG 完全够用。但当问题开始跨实体、跨文档、跨时间、跨因果链时普通 RAG 就会越来越像“把很多相关片段堆给模型希望它自己拼出来”。而 graph system 的核心优势就在于它先把关系显式建出来再让模型沿着关系去找答案。我会把它理解成一种更高一层的检索与推理结构而不是对 RAG 的简单替换。所以更准确的说法也许不是graph engineering 取代了 RAG而是在复杂问题上graph engineering 正在接管普通 RAG 不够用的那一层。这也是为什么微软、斯坦福和 Anthropic 虽然走法不同却在同一个方向上会合了模型擅长语言图擅长关系。真正强的系统往往是让两者一起工作。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】