starmountain1997

Graph Engineering

11分钟阅读

Graph Engineering

Graph Engineering 目前没有统一定义。以下文章代表了两种主要用法：

这说明“Graph Engineering 包含执行图和知识图”是本文为了统一讨论采用的上位分类，并非行业已经形成的标准定义；在阅读其他资料时，需要先确认作者说的是执行图还是知识图。

两者使用相同的图概念，但解决不同问题：

执行图知识图
描述对象Agent 如何工作Agent 知道什么
节点代码、LLM 调用、工具调用或完整 Agent文档、chunk、实体、事件或决策
边下一步、条件分支、重试、暂停和恢复相邻、包含、引用、依赖、替代和因果
运行方式状态沿节点和边流转从命中节点出发遍历关联知识
主要目标约束行为，提高可控性、可恢复性和可预测性找回跨文档、多跳或时序相关的上下文
典型实现LangGraph知识图谱、GraphRAG、图结构 Agent 记忆

因此，Graph Engineering 可以暂时理解为：使用显式图来设计 Agent 的执行过程或上下文结构。

核心关系

Graph Engineering 包含两个主要方向：执行图和知识图。DAG 是执行图的一种具体实践，GraphRAG 是知识图的一种具体实践，但它们都不是唯一选择。

Graph Engineering
├── 执行图：描述 Agent 如何工作
│   ├── DAG
│   ├── 状态机
│   ├── 有环图
│   └── 动态图
└── 知识图：描述 Agent 知道什么
    ├── GraphRAG
    ├── 知识图谱
    ├── 文档图
    └── 时序记忆图

选择哪种图模式取决于问题，而不是统一使用 DAG 或 GraphRAG：

图模式所属方向适用场景
DAG执行图任务依赖、并行计划和固定流水线
状态机执行图条件路由、审批和明确的状态转换
有环图执行图重试、反思、验证和人工反馈
动态图执行图运行时创建任务或决定下一步
GraphRAG知识图用图关系增强检索和回答
文档图知识图章节、chunk、引用和前后文关联
时序图知识图事实更新、事件演化和版本替代
知识图谱知识图实体关系、事实查询和多跳推理

工程闭环

执行图和知识图回答“图用在哪里”，Graph Engineering 还要回答“图如何被持续构建、验证和改进”。它不是选择一种图数据库或画出节点与边就结束，而是一个从问题出发、由评测反馈到建模的闭环：

flowchart LR
    Q["问题与查询模式"] --> M["节点、边、状态与语义设计"]
    M --> B["构建与增量更新"]
    B --> V["身份解析与约束校验"]
    V --> R["查询、遍历与混合检索"]
    R --> E["质量、延迟与成本评测"]
    E --> M

这个闭环同时适用于两个方向：

工程环节执行图知识图
问题优先先确定需要哪些固定路径、分支、并行和恢复先确定要回答哪些单跳、多跳、因果或时序问题
建模定义节点职责、边条件和共享状态定义实体、受控关系词表、属性、时间和证据
校验检查不可达节点、无界循环、状态漂移和失败传播检查实体重复、悬空边、未知关系和时态冲突
评测衡量成功率、重试次数、延迟、成本和人工介入率比较向量、图和混合检索的召回、答案质量与可追溯性

图的结构指标和应用任务指标需要一起评测。图本身没有悬空边，不代表回答一定更好；答案更流畅，也不代表关系和路径正确。

与相邻领域的边界

Graph Engineering 会使用数据工程、知识图谱工程和数据库工程的能力，但不等同于其中任何一个：

领域主要关注点
数据工程数据采集、转换、存储和可用性
数据库工程模式、索引、事务、一致性、性能和恢复
知识图谱工程实体、关系、本体、身份解析和语义互操作
Graph Engineering让关系、路径或状态转移成为系统的主要组织原则

判断是否进入 Graph Engineering，不取决于是否使用图数据库，而取决于系统是否需要显式设计、遍历、验证和维护关系或执行路径。

执行图

在 LangGraph 的定义中，节点负责执行工作，边决定下一步，状态在图中流动。节点既可以是确定性代码，也可以是一次 LLM 或工具调用，甚至是拥有内部循环的完整 Agent。

DAG 是执行图最直接的实践，适合表达任务依赖和可并行的固定步骤，但执行图不一定是 DAG。生产 Agent 需要重试工具调用、补充信息、反复验证、等待人工审批并从检查点恢复，因此循环和动态转移也是正常结构。它适合具有可预期阶段、必须遵守固定路径或需要人工介入的工作流；如果任务无法预先描述合理路径，强行画成固定图反而会限制 Agent。

执行图需要同时设计三个对象：

对象作用
节点执行一种明确工作，可以是代码、工具、LLM 或完整 Agent
边定义顺序、条件分支、并行展开、结果汇合和循环返回
共享状态在节点间传递任务、上下文、中间结果、验证结论和错误信息

单 Agent 循环是最小的有环执行图。只有任务出现明确的专业分工、并行后汇合、不同工具或模型、独立验证、显式审计路径或故障隔离时，才值得拆成多节点图；否则保留一个带停止条件和验证器的循环更简单。

知识图

知识图描述的是可检索的上下文。节点保存文档、实体、事件和决策，带类型的边说明它们如何关联，例如 supersedes、depends_on、decided_by 和 caused。

GraphRAG 是知识图的一种具体实践：向量检索找到语义相似的内容，图遍历找到与答案存在结构联系的内容，再由 LLM 根据这些证据生成答案。知识图还可以用于事实查询、文档导航和 Agent 记忆，并不都需要组成 RAG。它更适合跨 chunk、多跳关系、时间变化和全局归纳，但实体消歧、关系类型、证据追踪、冲突处理和图校验会直接影响结果可信度。

与我们的 GraphRAG 的关系

我们的 GraphRAG 属于知识图方向：

用户问题
→ 向量召回 chunk
→ 沿文档图和知识图扩展
→ Reranker
→ LLM 生成答案
知识图工程关注点我们当前的实现
节点与边Chunk、Entity、NEXT、MENTIONS、RELATED_TO
有类型的关系NEXT 和 MENTIONS 类型明确；实体关系由 kind 表示
混合检索向量检索确定起点，再沿图扩展
可追溯证据evidence_chunk_id 指回关系的原文
实体消歧尚未系统处理同名、别名和一词多义
图规则与校验尚未校验未知关系、悬空节点和冲突关系
时间有效性尚未表示关系的生效、失效与被替代时间
按问题路由当前总是执行图扩展，尚未区分简单查询与多跳查询

GraphRAG 使用的文档图和知识图是数据结构；向量召回、图扩展、排序和生成构成处理流程。当前流程即使画成流程图，也不等于采用了 LangGraph 式的执行图。只有当我们把各步骤实现为带状态、条件转移、重试和检查点的节点时，它才同时属于执行图工程。

Graph Engineering
├── 执行图：编排我们的 GraphRAG 如何运行
└── 知识图：为我们的 GraphRAG 提供什么上下文

对当前实现，先完善关系词表、实体消歧和图校验；只有流程确实需要条件路由、重试、暂停恢复或人工审批时，再引入执行图。

关系图谱