课程笔记：吴恩达 Building Agentic Knowledge Graph
课程笔记：吴恩达 Building Agentic Knowledge Graph
知识图谱RAGGraphRAGAgentAndrew Ng
Building Agentic Knowledge Graph
最近翻到一份材料，主题是"怎么用多 Agent 系统把企业的结构化数据和非结构化数据合并成一张图，再用来做检索增强"。这份材料配套的实操基于一家图数据库厂商的产品，演示比较完整，但本文想把背后的概念和架构思路整理出来——只保留与"图"这个抽象概念有关的部分，不展开产品名，也不复刻具体代码。
这篇能给你什么：
一套从关系表到图的认知升级路径
一份 AI 时代"为什么 RAG 仍然不够用"的拆解
一个把结构化业务、非结构化文本、抽取事实拼成同一张图的三层方案
一份多 Agent 怎么分工、哪些工作交给 LLM、哪些工作交给确定性工具的设计框架
一、为什么关系表开始跟不上 AI
要谈"图"为什么会出现，先要回答一个老问题：关系表里"关系"是什么？
构造一个最朴素的例子：一张 Person 表、一张 Product 表、一张 Person-Product 关联表。想问"ABK 买过哪些产品"，就要从 Person 找 ABK，连一次关联表，再连 Product，得到椅子、灯和桌子。一次 JOIN，能搞定。
接着问"还有谁买过 ABK 买过的产品"，要从 ABK 连到产品，再经关联表反向连到其他人。两次 JOIN，也能搞定。
再问"应该向 ABK 推荐什么新产品"——这就是协同过滤了：先找 ABK 买过的产品，再找也买过这些产品的人，再找这些人还买过、但 ABK 没买过的产品，把差集推给他。三步要走多次 JOIN，问题越深、步数越多。
问题不是"算不出来"。问题是：关系表里"人购买产品"只是 Person-Product 关联表里的一行。它是查询时拼出来的实现细节，不是数据本身。 问题越深，需要的 JOIN 越多，查询语句越长，可读性越差，调试和改写的成本都跟着涨。
关键判断
：当一个系统的核心价值变成"沿关系做判断"，把关系作为隐藏的关联表是不合适的。
图的处理方式不一样——它把"人购买产品"这种关系直接升成结构里的一等数据：
<span leaf="">(ABK:Person)-[:PURCHASED]->(Chair:Product) (E:Person)-[:PURCHASED]->(Chair:Product) (E:Person)-[:PURCHASED]->(Couch:Product)</span>
“ABK 买过椅子"不再是某个查询要现拼的产物，它就是图里一条带类型的边。
查询语言也跟着换。Cypher（或任何等价的图查询语言）被设计成"如果 SQL 具有图模式匹配能力”：圆括号表示节点，方括号和箭头表示有方向、有类型的关系。一个推荐查询可以写成：
<span leaf="">MATCH (abk:Person {name: 'ABK'})-[:PURCHASED]->(common:Product) <-[:PURCHASED]-(other:Person)-[:PURCHASED]->(candidate:Product) WHERE NOT (abk)-[:PURCHASED]->(candidate) RETURN candidate</span>
这段查询同时表达了三件事：
必须存在的路径：ABK 买过某产品，另一个人也买过它
继续存在的路径：另一个人还买过候选产品
必须不存在的路径：ABK 没买过该候选产品
一个观察
：Cypher 的结构化模式很接近自然语言，所以适合跟 LLM 结合——LLM 可以更自然地把用户问题翻译成节点和关系模式，而不是硬挤出 SQL。这也是后来 GraphRAG 路线能跑通的语言学基础。
关系表里"关系"是 JOIN 时拼出来的实现细节，图里"关系"是一等数据
一句话总结：关系表把"关系"藏在 JOIN 里；图把"关系"作为一等数据，路径是结构本身。
二、RAG 为什么仍然不够用
关系表是上一代系统的事。AI 时代主流的检索方案是 RAG——文档分块、计算 embedding、存进向量库、按相似度召回，再交给 LLM 生成答案。
RAG 在很多问答场景里有效，但它的天花板也很明显：召回给 LLM 的是"相似文本"，不是"结构化路径"。
举一个具体例子。用户问"这把椅子腿为什么总松"。
理想回答：沿着 产品 → 部件 → 物料记录 → 供应商 追到根因。
传统 RAG 给的：跟"椅子腿松动"语义最像的几段评论。
这几段评论能告诉 LLM"确实有这个问题"，但告诉不了 LLM"这个问题跟哪个供应商的那批次椅腿有关"。
核心矛盾
：在准确性要求高、需要追溯根因的场景里，“相似"和"相关"经常不是一回事。
GraphRAG 就是冲着这个问题来的。它在传统 RAG 之上加了三层能力：
1. 从 chunk 中抽取产品、订单、交付问题、产品缺陷等实体
2. 把 chunk 和这些实体用关系连接起来
3. 把文本里的实体继续连接到 CSV 等结构化数据中的业务实体
一个能同时存四样东西的图：原始文本 chunk、chunk 的向量表示、结构化的业务节点和关系、从文本里抽出的实体和事实。查询时既可以走向量相似度，也可以走结构化模式匹配，两种召回方式可以组合。
升级后的能力
：给 LLM 的上下文，从"相似文本片段"升级为 “相似文本 + 结构化路径”。在准确性要求高、需要追溯根因的场景里，这个差别很大。
传统 RAG 只召回相似文本片段，GraphRAG 同时召回文本和结构化路径
一句话总结：传统 RAG 召回"相似文本”，根因分析时缺一条能沿着走的路径；GraphRAG 把这条路径补回来。
三、AI 真正需要一张什么样的图：把结构和文本拼起来
理解了关系表的局限和 RAG 的不足，下一步就是回答那个真正难的问题：一张能用的图到底长什么样？
如果只能记一个观察，我会记这个——最终的图不是单一结构，而是三层相互连接的子层：
| 层级
|
名字
|
承载内容
| Domain 层 |
业务
|
已知结构（产品、部件、供应商）
| | Lexical 层 |
文本
|
原始文档、分块、嵌入
| | Subject 层 |
事实
|
主-谓-宾 抽取结果
|
三层是相互连接的——这才是跟"只用一种结构"的关键区别。
Domain 层（业务）
由 CSV 等结构化数据构建，表达企业已知、结构明确的业务事实。比如产品、部件、供应商之间的关系：
<span leaf="">(Product)-[:HAS_PART]->(Part)-[:SUPPLIED_BY]->(Supplier)</span>
它适合用确定的模式匹配查询。它代表的是"我们已知并能直接做模式匹配的结构化数据"。
Lexical 层（文本）
由 Markdown 评论构建，保留原始文本和分块结构。它包含：
Document 节点
Chunk 节点
文档和分块的从属关系
分块之间可能的次序关系
每个分块的 embedding
Lexical 层的目的不是把文本强行变成固定业务 Schema，而是保留文档、分块和语义检索的基础。
Subject 层（事实）
是连接结构化和非结构化世界的桥。系统从 chunk 中抽取出实体和事实，以"主语-谓语-宾语"形式表达，比如：
<span leaf="">ABK --LOVES--> Table User123 --REPORTS_DEFECT_IN--> ChairLeg</span>
从评论抽出的 Table 或 ChairLeg 还可以链接到 Domain 层里真实的 Product 或 Part 节点。
三层贯通
三层贯通之后的完整路径是：
<span leaf="">Document -> Chunk -> 抽出的实体 -> Product -> Part -> Supplier</span>
关键洞察
：一条"椅子腿松动"的评论，沿着这条路走——
从 Document 到 Chunk，从 Chunk 抽出 ChairLeg 这个实体，ChairLeg 链接到 Domain 层里的 Part 节点，Part 又通过 SUPPLIED_BY 关系链到具体的 Supplier。
一段文本就这样变成了一个可追溯的根因链路。
Domain / Lexical / Subject 三层图 + 从 Document 沿贯通路径追到 Supplier
一句话总结：关系表只表达一类数据，传统 RAG 只召回一类相似性，图把这两类接成同一张可查询的结构，让查询同时跨层走。
四、这张图怎么造：Agent 做判断，工具做执行
知道了图长什么样，下一个问题是：怎么造？
这个问题的答案很反直觉——造图这件事不适合一次性自动化，适合让 Agent 提议、用工具执行。下面把"为什么"和"怎么分工"拆开讲。
Agent 是什么
从工程角度把 Agent 定义为"一种新的、较高级的控制流操作符"。其本质循环是：
<span leaf="">用户/环境输入 -> 调用 LLM 做判断 -> LLM 选择动作或工具 -> 程序中的 dispatcher 执行动作 -> 执行结果回到上下文 -> LLM 再判断 -> 直到产生最终响应</span>
关键边界
：推理由 LLM 完成，真正产生外部效果的动作由代码执行。
这条边界决定了 Agent 系统的成本、可靠性和可调试性。模糊这条边界的系统，多半会出问题。
优点：LLM 能做推理、工具能执行任何代码能做的事、主要靠自然语言指令定义行为
代价：远程 LLM 调用慢、行为不确定、生产规模下 token 成本会迅速累积
多 Agent 蓝图
要造一张图，单 Agent 撑不住完整流程。多 Agent 是必要的，因为造图涉及多个判断：
哪些文件值得导入？
业务该用什么节点和关系？
文本里要抽哪些实体类型和事实类型？
不同判断之间怎么对齐？
一份合理的蓝图是这样的：
顶层协调 Agent：介绍系统能力、引导用户走完整流程、判断当前处于哪个工作流、把具体任务委派给下面的工作流 Agent
结构化数据工作流：把 CSV 从"用户想做什么"推到"形成模型构建计划"
非结构化数据工作流：把 Markdown 从"用户想做什么"推到"形成知识抽取计划"
GraphRAG 工作流：在结构构建完成后帮用户基于模型回答问题
每条工作流内部再分三个 Agent：
| Agent
|
职责
| User Intent Agent |
澄清业务目标
| | File Suggestion Agent |
根据目标挑出真正相关的文件
| | Schema Proposal / Entity-Fact Proposal Agent |
提出结构方案
|
还有一个关键技巧是 critic pattern：不是只用一个 Agent 提方案，而是用一对 Agent——Proposal 提方案、Critic 挑问题，两者循环迭代。这能显著提高方案质量，因为单一 Agent 容易陷入"自我合理化"。
计划 vs 执行
所有这些 Agent 的输出都汇聚成两份计划：
结构构建计划（怎么把结构化数据转成节点、关系和属性）
知识抽取计划（怎么从文本里抽实体和事实）
然后由一个确定性工具接收这两份计划，遍历文件、分块、计算 embedding、执行查询、创建节点和关系。这个工具不调 LLM，按计划批量执行。
顶层协调 Agent 分发任务到三条工作流，最终由确定性工具按计划执行
最重要的设计思想
：Agent 做开放式理解、选择、提议和批评；确定性工具按已经批准的计划批量执行数据搬迁。
两类角色的边界划清楚，单个 Agent 的复杂度、整个系统的成本、可靠性和可调试性都好控制。
把这条边界反过来——让 Agent 直接搬数据——通常会同时撞上成本失控、结果不可复现、调试无从下手三面墙。
实施时需要把控的几个细节
不管用什么 Agent 框架（Google ADK、LangGraph、Autogen 等），实施时都绕不开这几件事：
工具 docstring 要写得像接口文档：在 Agent 系统里，docstring 不是给开发者看的，是给 LLM 看的工具说明
外部查询必须用参数化：Cypher、SQL 都不能字符串拼接，必须用参数化查询，否则就是注入漏洞
必须看事件轨迹，不能只看最后答案：只读 final response 看不到是否委派给了正确 Agent、参数是否正确抽取、状态是谁写入的
会话状态不等于可信知识：状态字典解决"跨 Agent 跨轮次保留信息"，但不解决来源、准确性、冲突——典型表现就是 LLM 从用户话语里猜错姓名并把猜测写进共享状态，下一个 Agent 再从状态里读出来用
七条带走的原则
1. 业务目标先于图的 Schema。先想清楚要回答什么问题，再决定哪些节点和关系值得构建。
2. 结构化数据和非结构化数据不能用同一种导入方法。
3. Subject 层是两类数据的语义桥梁——只做文本向量化不能自然追到业务主数据，只做业务模型又用不上评论里的自然语言事实。
4. Agent 做判断，工具做执行。LLM 负责开放式理解，代码负责确定性搬迁。
5. 多 Agent 的接口约定。description 决定其他 Agent 什么时候把工作交给它，instruction 决定它接手以后怎么完成工作，tool docstring 决定它如何理解和调用工具。
6. 必须看事件轨迹，不能只看最后答案。
7. 记忆是共享状态，不等于可信知识。
收尾
回头看这四个核心问题：
关系表为什么跟不上 AI？——因为关系是 JOIN 拼出来的，不是数据本身
RAG 为什么不够用？——因为召回"相似文本"不够支撑根因分析，需要"相似文本 + 结构化路径"
AI 真正需要什么结构？——Domain / Lexical / Subject 三层图，三层贯通
怎么造这张图？——Agent 做开放式判断，工具按批准的计划执行数据搬迁
这四个问题合在一起，构成了我对这份材料的核心理解。具体怎么从 CSV 走到最终的三层图谱、怎么调 embedding 模型、怎么对齐文本实体和业务实体、怎么评估 GraphRAG 召回质量——这些问题在原始材料里也只是方案层面，没有具体到能直接落地的细节。要真正造出生产可用的图，需要在这些架构骨架上继续往里填工程实现。
【延伸阅读】
相关阅读
RAG vs 微调 vs 本体：企业知识管理三条路，该走哪条？
近期新文
经典热文
- 原文作者：知识铺
- 原文链接：https://index.zshipu.com/ai001/post/20260817/%E8%AF%BE%E7%A8%8B%E7%AC%94%E8%AE%B0%E5%90%B4%E6%81%A9%E8%BE%BE-Building-Agentic-Knowledge-Graph/
- 版权声明：本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，非商业转载请注明出处（作者，原文链接），商业转载请联系作者获得授权。
- 免责声明：本页面内容均来源于站内编辑发布，部分信息来源互联网，并不意味着本站赞同其观点或者证实其内容的真实性，如涉及版权等问题，请立即联系客服进行更改或删除，保证您的合法权益。转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com
