原文链接：https://mp.weixin.qq.com/s/Q3srAO784NsU0NBGXWgvQw

✨ 知识架构进化论

前文：

从 Description Logic 到 Leiden 社区发现，从 OWL 推理到 tree-sitter AST——知识表示的两条路线终于要合流了。

💡 写在前面

2026 年 4 月，Andrej Karpathy 在一条推文里描述了一种他称为 LLM Wiki 的个人知识管理方法——让大模型像编译器一样，把杂乱的原始文档「编译」成一本结构化、可查询、能自我修复的百科全书。几天后，开源项目 Graphify 将这个”推特灵感”做成了工程化实现。

但如果你做过企业级知识图谱，你一定会追问一个关键问题：这些自动抽取出来的知识没有 Schema 约束，怎么在严肃的业务场景（合规、审计、权限管理）中使用？

答案藏在一个古老而强大的学科里——本体论 (Ontology)。

👀 Part 01.

本体论：知识世界的宪法

在哲学中，「本体论」(Ontology) 研究的是「存在」本身——什么东西是真实的？事物的本质是什么？它们之间有何种关系？

在计算机科学中，这个概念被 Tom Gruber 在 1993 年精炼为一句经典定义：

「本体论是对一个共享概念体系的
形式化、明确的规格说明。」
— Tom Gruber, 1993

翻译成人话就是：在写任何代码之前，我们先要像制定宪法一样，明确定义这个领域里有哪些「概念」（Class），它们有什么「属性」（Property），概念之间允许什么「关系」（Relation），以及什么推理规则是合法的。

这套理论落地后就是 OWL (Web Ontology Language)，它的底层是 Description Logic (描述逻辑)——一种专门为知识表示设计的形式逻辑。举个例子：

💻 OWL 描述逻辑示例

# 定义一个"车辆项目"类 Class: VehicleProject   SubClassOf: Project   HasProperty: targetPlatform (xsd:string)   HasProperty: sopDate (xsd:date)  # 定义一个约束：每个 VehicleProject 必须关联至少一个 Task VehicleProject ⊑ ∃hasTask.Task  # 推理：如果 A 是 VehicleProject 的子类， # 那么 A 自动继承 hasTask 约束 ElectricVehicleProject ⊑ VehicleProject ⟹ ElectricVehicleProject ⊑ ∃hasTask.Task  ✅ 自动推导

关键优势在于：OWL 配合推理器（如 Pellet、HermiT）可以自动发现隐含知识。你只需要定义规则，推理器就能帮你检查一致性、推导新的事实。这在合规场景（如”某个项目是否缺少了必要的审批节点”）中至关重要。

但它的致命弱点也很明显：

❌ 知识获取瓶颈 (Knowledge Acquisition Bottleneck)

构建和维护一个精确的 OWL 本体需要领域专家 + 本体工程师的大量手工劳动。现实中团队往往等不起。

❌ 脆弱性 (Brittleness)

任何不在预定义 Schema 中的新概念都是”看不见”的。当代码库快速变化时，本体永远在追赶现实。

💡 Part 02.

LLM Wiki：知识世界的进化论

Karpathy 提出的 LLM Wiki 完全走向了另一个极端。它的核心理念用一句话概括：

「Obsidian 是 IDE，LLM 是 Programmer，
Wiki 是 Codebase。」
— Andrej Karpathy, 2026

也就是说：把你的知识当作一个「代码库」来管理。原始文档（论文、代码、会议记录）是「源文件」，大模型是「编译器」，输出的结构化 Wiki 是「编译产物」。这个过程 Karpathy 称之为 Knowledge Compilation（知识编译）。

开源项目 Graphify 把这套理念做成了真正可跑的工程实现。它的 7 阶段流水线是这样的：

💻 Graphify 处理流水线

Stage 1 → Detect   : 扫描项目结构，识别代码/文档/图片 Stage 2 → Extract  : 🔑 关键步骤   ├─ 代码文件 → tree-sitter AST 零成本解析（本地确定性）   └─ 文档/图片 → Claude 子代理并行语义抽取 Stage 3 → Build    : 将实体和关系注入 NetworkX 图 Stage 4 → Cluster  : Leiden 算法进行社区发现 Stage 5 → Analyze  : 识别架构模式和核心依赖 Stage 6 → Report   : 生成 GRAPH_REPORT.md Stage 7 → Export   : 输出 graph.json + 交互式 graph.html

这套流水线中最精妙的是 Stage 2 的混合抽取策略：

🌳 tree-sitter：确定性的骨架

对代码文件使用 tree-sitter 进行 AST 解析。这一步不调用任何 LLM，不消耗任何 token，运行在本地，产出的函数调用关系、类继承层级、模块导入等都是100% 确定性的。

🧠 LLM 子代理：语义的血肉

对文档和图片使用 Claude 子代理做并行语义抽取。这一步的产出带有置信度标签：EXTRACTED (1.0)、INFERRED (0.6-0.9)、AMBIGUOUS (0.1-0.3)。每条边都标记了来源，可审计、可追溯。

特别值得注意的是 Leiden 社区发现算法的使用。Graphify 刻意没有使用向量数据库和余弦相似度这种「泛语义匹配」，而是选择了基于图拓扑的社区检测——它根据节点间的边密度来发现自然聚类。这种方式更尊重代码本身的结构关系，而不是让嵌入空间的”距离错觉”扭曲理解。

✏️ 图：刚固知识 (本体论) vs 流动知识 (LLM Wiki) 的核心差异

🔬 Part 03.

深层对比：两种知识观的哲学根源

这两套体系的分歧，本质上是计算机科学中 符号主义 (Symbolic AI) 和 连接主义 (Connectionist AI) 数十年争论的延续：

📊 核心维度对比

维度

本体论 (OWL/DL)

LLM Wiki (Graphify)

哲学立场

理性主义：世界可以被完整定义

经验主义：知识从数据中涌现

构建方向

自上而下 (Top-Down)

自下而上 (Bottom-Up)

推理方式

演绎推理（逻辑蕴涵）

归纳/归因（统计模式匹配）

精度

极高（形式逻辑保证）

可变（受幻觉影响）

可扩展性

低（需手工维护 Schema）

高（基于文档增量更新）

可解释性

极高（每条推理可溯源）

中等（依赖带标的抽取置信度）

维护成本

高（知识获取遭遇瓶颈）

低（自动化抽取管道）

一个直觉性的比喻：本体论是城市规划图——在建造之前就精确定义了每条道路、每个区域的功能。LLM Wiki 是自然生长的村落——居民（实体）自发聚居，逐渐形成集市、广场和小径。

前者精确但僵化，后者灵活但混乱。一个成熟的城市，往往两者兼具。

🎯 Part 04.

融合方案：让 LLM 做苦力，让本体做风控

真正的工程突破不在于选择其中一种，而在于设计二者的接口协议。在我们最近构建的 Neo4j 本体管理系统的实践中，已经验证了一种分层融合架构：

✏️ 图：大模型知识抽取流水线——从散乱文档到结构化图谱

第一层：本体骨架层 (Ontology Skeleton)

在 Neo4j 中预定义核心业务元数据字典。例如：VehicleProject → hasPhase → DevelopmentPhase、Task → requiredApproval → ApprovalNode。这一层是「宪法」，只有人类领域专家才能修改。它定义了允许存在的节点类型、关系类型、属性约束和推理规则。

第二层：LLM 抽取层 (LLM Extraction Layer)

运行 Graphify 风格的流水线，自动扫描 Confluence、JIRA Comment、PR Review、错误日志等。LLM 抽取出的关系都必须映射到本体骨架层预定义的关系类型中。如果 LLM 发现了一种本体中不存在的新关系类型，它不能直接写入图数据库，而是将其放入一个 Staging Area（暂存区），等待人类审核。

第三层：置信度审计层 (Confidence Audit Layer)

所有 LLM 生成的边都携带 Graphify 式的三级置信度标签：EXTRACTED (1.0) 来自 AST 确定性解析，INFERRED (0.6-0.9) 来自 LLM 语义推理，AMBIGUOUS (0.1-0.3) 来自 LLM 的低确信度猜测。业务查询时可以按置信度过滤——合规场景只看 EXTRACTED + INFERRED 阈值以上的边，探索性分析可以放宽到全部。

这三层架构的关键设计在于：本体提供写入约束(Write Constraint)，LLM 提供读取发现(Read Discovery)。

💻 Cypher 查询示例：带置信度过滤的架构探索

// 找到所有与"底盘模块"相关的高可信度依赖 MATCH (a:Module {{name:"ChassisControl"}})       -[r:DEPENDS_ON]->(b:Module) WHERE r.confidence >= 0.7   AND r.source IN ["tree-sitter", "claude-inferred"] RETURN a.name, r.confidence, r.source, b.name ORDER BY r.confidence DESC  // 发现本体中未定义的新关系类型（暂存区审查） MATCH (a)-[r:STAGING_RELATION]->(b) WHERE r.proposed_type IS NOT NULL RETURN r.proposed_type, count(*) AS frequency ORDER BY frequency DESC

🧬 Part 05.

理论深度：开放世界假设与封闭世界假设

这里有一个容易被忽略但极其关键的理论层面的问题：本体论和 LLM Wiki 对世界的基本假设不同。

🔒 封闭世界假设 (Closed World Assumption, CWA)

传统数据库（包括大多数 Neo4j 用法）遵循 CWA：**如果一个事实不在数据库中，则认为它是假的。**如果图中没有”模块 A 依赖模块 B”这条边，就默认它们不依赖。这在业务系统中很合理——未记录的权限就是没有权限。

🌍 开放世界假设 (Open World Assumption, OWA)

OWL 本体论和 LLM Wiki 都遵循 OWA：**如果一个事实不在知识库中，只能说”不知道”，不能说”不是”。**LLM 抽取出的关系可能不完整，但不代表现实中这些关系不存在。这正是 Graphify 的置信度模型和”暂存区”设计哲学的根基。

融合架构的设计诀窍在于：业务规则层用 CWA（未授权即禁止），知识发现层用 OWA（未发现不代表不存在）。两个假设共存于同一个图数据库中，通过置信度阈值和关系类型来区分。

2 ≠ 1

两种世界观在同一个图里共存，通过置信度阈值分割边界

🚀 Part 06.

面向智能体时代的知识架构

当我们把视角拉高到 AI Agent 的层面，这套融合架构的战略价值就更清晰了：

🤖 智能体需要什么样的知识库？

① 精确的业务规则——智能体执行审批流时，绝不能幻觉出一个不存在的审批节点。这需要本体论的形式化约束。

② 丰富的上下文关联——智能体回答”为什么这次测试失败了？”时，需要知道”测试模块 X 依赖的底盘通信库在昨天被重构了”。这种隐性关联只有 LLM 抽取才能高效捕获。

③ 可审计的推理链——每条推荐/决策都能追溯到原始证据。Graphify 的置信度标签 + 本体公理的推理轨迹，共同构成了一条完整的可解释性链路。

这三个需求，单独靠本体论或单独靠 LLM Wiki 都无法同时满足。只有分层融合，才能做到既不幻觉、又不僵化。

最终的架构画面是：Neo4j 图数据库作为统一存储层，OWL 约束作为写入时的 Schema Validator，Graphify 流水线作为持续运行的知识注入引擎，Leiden 社区检测定期重新发现模块边界，智能体通过 Cypher 查询结合自然语言理解来服务上层业务。

🌟

Talk & Takeaway

① Karpathy 的 LLM Wiki 不是对本体论的替代，而是它最好的互补。
LLM 负责「发现」，本体论负责「约束」。

② 置信度标签是双方对接的接口协议。
EXTRACTED/INFERRED/AMBIGUOUS 这套三级体系，本质上是用工程手段量化了开放世界假设下的认知不确定性。

③ 下一代企业知识库 = Ontology Skeleton + LLM Extraction + Confidence Audit。
纯大模型太飘，纯本体论太累。三层融合才是智能体时代的最终解法。

— END —

🔗 Graphify：github.com/safishamsi/graphify
📄 Karpathy LLM Wiki Gist：gist.github.com/karpathy/442a6bf
📖 OWL 2 规范：w3.org/TR/owl2-overview

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。

当 Karpathy 的 LLM Wiki 遇上本体论：一场知识表示的终极融合

前文：