AI 智能体的图工程：知识图谱什么时候值得做？

当 AI 系统必须跨越许多步骤或会话保存关系、依赖与证据时，图工程才有意义。大多数一次性 prompt、相互独立的任务和单文档问答都不需要它。商业问题不是图有没有能力，而是关联推理是否重要到足以承担建模、实体消歧、溯源、评测与维护成本。

本文明确区分目前搜索结果经常混在一起的三个概念：协调 AI 智能体的执行图、保存实验谱系的有向无环图，以及维护共享事实的知识图谱。这一角度面向架构与采购决策，也不会与现有的 Graphify 代码库知识图谱评测、Meterless 智能体记忆评测和多智能体编排的人类注意力瓶颈争夺同一搜索意图。

什么是面向 AI 智能体的图工程？

面向 AI 智能体的图工程，是把节点、关系与状态转换显式设计出来，让系统的工作或知识能够查询。执行图控制下一个行动者；实验图记录结果的来源；知识图谱保存带类型的实体与关系，供多个智能体和不同会话复用。

这个术语仍在形成，因此边界必须说清楚。图形工作流不等于知识图谱，图数据库也不会自动产生可靠记忆。图只能外部化其 schema、抽取流程与更新规则真正捕获的内容。

为什么图工程现在成了严肃的 AI 架构问题？

过去分开的几类实践正在汇合。Andrej Karpathy 的 autoresearch 给智能体一套小型训练环境，让它修改代码，执行五分钟训练，判断保留或丢弃结果，然后重复。循环把迭代外部化，实验日志则保留比较各代结果所需的证据。

Anthropic 的有效智能体构建指南介绍 prompt chaining、routing、并行、orchestrator-workers 和 evaluator-optimizer。它给出的建议很克制：先找最简单的方案，只有当性能收益能够抵消延迟与成本时，才增加智能体复杂度。

生产系统的取舍已有量化案例。在 Anthropic 多智能体研究系统中，多智能体方案在其内部研究评测上比单智能体基线高 90.2%，但 token 用量约为普通聊天的 15 倍。Anthropic 认为它适合价值高、可大量并行、工具多或信息超出单一上下文窗口的任务，不适合所有智能体必须共享同一上下文且依赖密集的任务。

与此同时，Anthropic 官方的知识图谱构建 cookbook已经开始教授带类型实体抽取、主谓宾关系、实体消歧、多跳查询以及 precision-recall 评测。这个模式已经具体到可以教学，但并不代表它应当成为默认架构。

知识图谱什么时候能赚回成本？

以下条件中，如果至少两项是高价值流程的核心，就值得试点。满足四到五项时，知识图谱通常是强候选：

1. 关联查询很重要。问题需要经过两条或更多关系，例如哪个供应商支持受某次事故影响、并由受监管团队负责的组件。
2. 关系持续变化。归属、权限、依赖、合同、事故或产品版本会变，答案取决于相关时间点。
3. 溯源本身就是答案的一部分。审核者必须看到哪份来源断言了这条关系、何时抽取、怎样转换，以及是否通过人工审核。
4. 多个智能体需要共享世界状态。研究、支持、合规与运营智能体必须引用同一组实体，而不是重复生成互不兼容的摘要。
5. 知识会跨会话复利。一次实体消歧或关系验证应改善之后的工作，而不是在上下文窗口关闭后消失。

这里最重要的限定是“高价值流程的核心”。即使图设计得很漂亮，如果只回答低价值问题，仍然是一笔差投资。

哪些情况不该使用图？

还要考虑人的约束。节点、智能体和分支越多，监督与评测工作越多。如果团队已经超过智能体编排上限，增加图运行时只会移动复杂度，不会消除它。

知识图谱、向量 RAG 与 SQL，智能体该用哪一个？

多数时候应当组合，而不是选唯一赢家。标准 RAG 检索语义相似的段落，SQL 回答结构化表格上的明确问题，知识图谱遍历具名关系，GraphRAG 则结合图结构、检索与生成。

微软的 GraphRAG 研究面向大型私有语料上的全局理解问题。它抽取实体图，为实体社区生成摘要，再合并多个局部答案。研究报告称，在这类问题上，答案完整性与多样性优于传统 RAG。这并不证明 GraphRAG 在每种查找、延迟目标或语料上都更好。

生产级知识图谱架构需要什么？

1. 范围明确的业务问题集。从 20 到 40 个昂贵且答案可验证的问题开始，不要从通用企业本体开始。
2. 最小可行 schema。只定义这些问题需要的实体和关系类型，并写明方向、基数与可接受证据。
3. 带审核的实体消歧。合并别名时不能把不同实体压成一个。Anthropic cookbook 明确提醒遗漏名称与过度合并两类风险。
4. 每条重要边都有溯源。保存来源 ID、来源版本、抽取时间、抽取方法、置信度、租户或权限范围与审核状态。
5. 混合检索。用图遍历寻找关系，用语义检索找文本，再回到原始来源验证。
6. 评测与刷新循环。用 gold set 测实体和关系的 precision-recall，同时监测答案正确性、时效、延迟与每次成功结果的成本。

溯源不是装饰性元数据。W3C PROV-O 标准描述实体、活动与主体，以及使用、由其生成、派生自和归因于等关系。你不必实现全部术语，但可以用它做检查：系统能否说明哪项活动产生了这个事实，以及谁或什么对此负责？

技术选型也应从小开始。Anthropic cookbook 的示例完全在内存中运行，并说明日后可以迁移到 Neo4j、Neptune 或 Postgres 邻接表。只有查询量、遍历深度、更新频率与运维要求证明有必要时，才选择专用图数据库。

图工程的真实成本是什么？

数据库许可证通常不是全部账单。预算还应覆盖来源连接器、schema 设计、抽取、实体消歧、人工裁决、权限、时间更新、图存储、检索、可观测性、评测与事故响应。最容易漏算的是语义维护：业务变化时，必须有人决定一条关系现在意味着什么。

指标必须对应企业真正购买的结果。可以测量获得带来源答案的时间、任务成功率、关系 precision 与 recall、过期边比例、每个案例的审核分钟数、延迟和每次成功行动的成本。节省 token 只有在改善业务结果时才是 ROI。

如何运行最小可行图试点？

1. 选择一个决策，不要先选技术。选择一个反复出现、成本高且涉及关联数据的问题。
2. 记录 baseline。用现有搜索、SQL 或向量 RAG 回答，测量正确性、时间、成本与审核工作量。
3. 建立最小有用图。第一版只包含问题集需要的实体、边与时间语义。
4. 构建引用证据包。每个答案都返回经过的边和支持它们的原始段落或记录。
5. 测试失败情形。包括别名、冲突来源、删除记录、过期权限、缺失边和图无法回答的问题。
6. 在 demo 前设定停止规则。如果已验证答案时间、任务成功率或审核成本没有足够改善，就停止。

好的试点可以得出“不做图”的结论，这能避免维护一个没有长期买方的数据产品。如果试点成功，Wavect 的 RAG 与 AI 架构团队可以继续完成权限、评测、可观测性与生产集成。你也可以查看 Twinsoft AI 案例、比较更上层的 MVP 技术栈选择，或预约图可行性沟通。

怎样让 LLM 更容易引用图答案？

应返回紧凑的证据包，而不是倾倒整片图邻域。每个答案包含规范实体名、带类型关系、方向、有效时间、来源标题、稳定 URI 或记录 ID、来源片段、抽取方法与审核状态。然后要求回答模型引用原始来源，而不是只引用图中的边。

职责因此分开：图负责找到路径，来源负责证明主张，模型负责解释结果。如果路径含有推断或过时的边，系统也能明确回答“证据不足”。

CTO 应当向图工程供应商问什么？

• 现有搜索或 RAG 无法回答的具体问题类型是什么？
• 能回答它的最小本体是什么？
• 别名、冲突、时间事实与删除如何处理？
• 每条关键边能否指向原始来源和权限范围？
• 哪些 precision、recall 与端到端任务指标决定试点成败？
• 刷新成本是多少，上线后谁负责语义变化？
• 能否导出图与证据，避免供应商锁定？