知识图谱

实体、关系，以及这种形状为何重要。

知识图谱是一组节点（实体：人、服务、文档、公司、症状），由带类型的边（关系：owns、depends_on、authored、supersedes）连接，两端都可以挂属性。它的原子单位通常写成一个三元组——(billing-service, owned_by, platform-team)。

对比知识库可以采用的三种存储形状：

• 表回答"这一行有哪些属性？"——快、精确，但关系藏在你必须事先知道的连接键里。
• 向量索引回答"哪些文本与这段文本相似？"——对措辞宽容、对结构盲目，而且本质上只有一跳：它返回段落，而一个不包含答案的段落无法被"走"到包含答案的那一段。
• 图回答"什么与它相连，怎么连的？"——遍历是原语，所以两跳、三跳、四跳的问题花掉的是一次查询，而不是一次奇迹。

图真正的超能力并不是查找速度，而是全局性问题的答案可以被计算出来，而不是被检索出来："4000 张支持工单里反复出现的主题是什么"没有哪一段可找，却有一个社区结构可以被总结。

如今图谱到底是怎么建起来的。

纯手工策划的本体，是知识图谱昂贵名声的由来。当下的做法是让模型来做抽取：

• 抽取。把每个分块连同指令交给 LLM，让它吐出实体与关系，通常用受约束的结构化输出。这一步是花钱的地方——你是在整个语料上跑一遍模型，而不只是给它做嵌入。
• 消歧。判定"Platform Team"、"platform-team"和"平台那帮人"是同一个节点。实体消歧是最难的部分，也是质量流失的主要来源：合并不足，图谱会碎成一堆同义词；合并过度，你会把两个真人熔成一个。
• 定型。要么预先施加一个 schema（一个小本体：允许哪些实体类型与关系类型），要么让模型自由发明类型。schema 花掉设计时间，买来精确度与可查询性；自由发挥上手更快，也会随时间漂移。
• 富化。可选地预先计算社区聚类与摘要，这样全局性问题可以从摘要中作答，而不必在查询时遍历一切。

它赢在哪里，代价又是什么。

• 赢：多跳问题。任何需要顺着链条走的场景——组织架构、依赖关系图、引用链、供应链，以及跨相关实体的医学或法律推理。
• 赢：全局性与主题性问题。"总结这份语料中的主要风险"是一个关于整份语料的问题，而 top-k 检索只能用任意的 k 份文档来回答它。
• 赢：可审计性。一条边可以携带它的来源文档，于是一个答案可以被拆解成一条能摆给人看的路径。相比"这是向量空间里挨得比较近的五个段落"，这是实打实的优势。
• 赢：时间。具备时间感知的图谱可以记录某个事实在两个日期之间为真，从而让智能体能回答"三月份这东西归谁？"，而不是用最新值覆盖掉历史。
• 付出：构建价格与延迟。摄取时每个分块一次 LLM 调用，对比一次廉价的嵌入。在大语料上，这是"一个下午"与"一条预算科目"的区别。
• 付出：陈旧与变动。更新图谱比更新索引难——一份变更过的文档可能让别处的边失效，而重新抽取并不幂等，因为模型本身不是确定性的。
• 付出：它不是即插即用的替代品。对于"帮我找到写着 X 的那一段"，图谱只是一个更差更慢的向量索引。几乎每个严肃系统都是两者并存再做路由。

你会在智能体技术栈的哪里遇见它。

图谱以两种截然不同的角色出现，把它们混为一谈，正是多数工具选型困惑的来源：

• 作为文档之上的知识库——微软的 GraphRAG 让"抽取，再对社区做摘要"这一模式流行开来；LightRAG 与 Cognee 是可本地运行的开源实现，后者能从混合输入同时构建图谱与向量存储。
• 作为智能体记忆——一张关于用户与工作的事实图谱，跨会话累积，并带时间有效性，让被取代的事实退役而不是重复堆积。Zep 的 Graphiti 与官方参考实现的 memory MCP 服务器都是这个形状。

对本地搭建来说，一条实用提醒是：加一层图谱大致会让活动部件翻倍——你从此要维护一份抽取提示词、一个图存储和一个向量索引，还需要一个路由器来决定某个问题该打向哪一边。先从向量加关键词的混合检索起步，量一量它答错了哪些问题，只有当失败确实是关系型的时候才加图谱——因为那才是它真正修复的失败类别。

GraphRAG 与多跳检索深入解析详细讲了算法与成本/陈旧化启发式；本地知识库讲的是它周围的整条流水线。