用 LLM 维护组织知识图谱：Planet Arkency 的工程实践

Arkency 团队近日在工程博客中分享了他们名为「Planet Arkency」的组织知识图谱系统，核心思路是用 LLM 从会议记录、Slack 讨论、邮件、RSS 等多源非结构化输入中持续抽取实体与关系，并借助一个封闭的本体（ontology）保证图谱结构可控。这是一篇典型的「LLM 应用于内部知识管理」工程实践复盘。

问题的起点：组织记忆的天然流失

作者在开篇点出一个普遍痛点：组织的关键决策和洞见散落在电话会议、Slack 消息、GitHub 提及与邮件里，几个月后几乎无人记得「事情为什么是这样」。Arkency 自身也无法靠人力整合这些分散信号。两条外部契机促成了该项目落地：一是 2026 年 3 月在克拉科夫举办的 Ruby Community Conference 上 Obie Fernandez 展示了其 NEXUS 系统；二是 Andrej Karpathy 随后发表的「LLM Wiki」笔记，提出让 LLM 增量维护一个由相互链接的 Markdown 页面构成、源数据保持不可变的持久化知识库。作者意识到自己正在做同一方向的事情，于是加快了开发节奏。

核心架构：单点摄入 + LLM 抽取

系统对所有数据源都使用同一个摄入端点，包括被专用 emoji 标记的 Slack 线程、桥接邮箱收件、RSS 订阅、日历邀请和个人笔记。集成层不再写代码，而是用 Zapier 或 n8n 等工具把外部信号推送到这一端点。每条内容随后进入关键的「抽取」步骤：LLM 读取文本，识别其中涉及的实体、关于实体的属性，以及实体之间的有类型关系。这一步是整篇文章聚焦的核心环节。

为什么选择图而非 Wiki

人物、项目、客户、工具、决策这些节点在对话中反复出现，变化的只是关于它们的属性和相互关系，这与图结构天然契合。图与 Wiki 的关键区别在于：「person --works_on--> project」是一条可被查询、遍历、统计的数据，而在 Wiki 中同样的事实只是一句话加一个超链接，必须由读者在阅读时自行拼合。Planet Arkency 把图存储在 PostgreSQL 中，使用 nodes 表、edges 表（带唯一 (source, target, relation) 三元组）以及 jsonb 属性。作者承认，对深度的多跳遍历等场景，专用的图数据库或三元组存储（如 NEXUS 使用的方案）可能更合适，但当前 schema 足够通用，替换底层存储不会带来太多迁移成本。

封闭本体与多租户隔离

图谱的节点类型与关系类型由一份 YAML 文件定义的「封闭本体」管控：模型只能使用列表中允许的 kind 与 relation。作者曾尝试开放本体让 LLM 自由引入新类型，结果「混乱以惊人的速度出现」，因此最终选择在抽取前就把可用词汇明确告知模型，并把本体同时渲染到抽取提示词的 Markdown 表格和数据库的枚举约束中。另一个关键设计是「不是一个图，而是许多图」：每个租户拥有独立的本体（即各自的「通用语言」），通过多租户架构隔离不同边界上下文，例如 Arkency 内部图谱关注人员、项目、决策，而作为 Rails Event Store 维护方运行的图谱关注发布、已知问题与社区内容，两套词汇共享同一套底层机制。

总结与定位

Planet Arkency 本质上是 Karpathy「LLM Wiki」思路在企业场景下的一种工程化变体：以受控的本体让 LLM 在一个可被查询、可被审计的图结构上持续沉淀组织记忆。它不是一项新的模型突破，而是一种值得关注的落地模式：在封闭本体、事件溯源与多租户边界之间取得平衡，把分散的非结构化信号沉淀为可被检索的内部知识资产。