当 AI 帮你整理知识库时，LLM 突然变得很能"打配合"——本体论框架设计的一些思考

一、先从一个真实的困惑说起

不知道你有没有这种感觉：

用 LLM Wiki 这类知识库工具的时候，LLM 回答问题确实挺准的——你问它"这个项目涉及哪些关键系统"，它能给你一个像样的答案。

但当你打开它的 index 文件，想自己看看知识库里有什么的时候……

一堆扁平的标签：组织、系统、流程、文档。 没有了。没了。就这些。

你盯着看了半天，心里冒出一个问号："系统？什么系统？核心业务系统？支撑系统？基础设施？它们之间什么关系？"

LLM 知道。但你看不懂。

这就是我今天想聊的核心问题——为什么 LLM 能理解的东西，对人类来说像一本用密码写的书？以及怎么解决这个问题。

二、问题的根源：扁平标签 ≠ 可导航的知识结构

2.1 你看到的 vs LLM 脑里想的

拿业务连续性管理（BCM）举例。假设你的知识库里有一堆 BCM 相关的文档，LLM 提取出来的实体列表可能是这样的：

- 组织

系统
流程
文档

四个字，扁平排列。

但 LLM 在回答"这个 BCM 方案涉及哪些关键系统"的时候，它脑子里想的其实是这样的隐含结构：

组织
├── 公司
├── 部门
├── 供应商
└── 监管机构

系统
├── 业务系统（核心）
├── 支撑系统
└── 基础设施

流程
├── 关键业务流程
├── 恢复流程
└── 连续性程序

LLM 的"脑内结构"是有层级的，但这个层级从来没有被显性化——它只存在于 LLM 的上下文理解里，用户看不到。

2.2 本体论出场：给知识库一个"骨架"

解决这个问题的方法，其实几十年前知识管理领域就已经想过了——本体论（Ontology）。

"本体论"这个词听起来很学术，但它的核心思想很简单：

"在这个领域里，有什么东西存在？它们之间是什么关系？"

用一个更直白的词来形容，就是"概念骨架"——就像一个人有骨骼系统，知识库也需要一个骨架，来组织所有的概念和它们之间的关系。

2.3 分层本体：骨架 → 器官 → 组织 → 细胞

我最认可的分层方式是四个层级，像一个完整的有机体：

🟢 骨架层（Skeleton）
   └── 这是这个知识库领域的"顶层骨骼"
       例如：资产 / 过程 / 角色 / 风险

🟢 器官层（Organ）
   └── 骨架下的大类
       例如：资产 → 人员 / 系统 / 设施 / 供应商

🟢 组织层（Tissue）
   └── 大类下的细分
       例如：系统 → 核心业务系统 / 支撑系统 / 基础设施

🟢 细胞层（Cell）
   └── 具体的实例
       例如："核心业务系统" → "订单管理系统"（具体名字）

为什么分层这么重要？

因为不同的使用者看到的东西不一样：

三、消歧：一件 LLM 在偷偷做但你完全不知道的事

3.1 什么是消歧？

消歧的意思是：同一个词，在不同语境里指不同的事物。

举例来说，"系统"这个词：

这就是"隐性消歧"。LLM 做了判断，但判断过程不透明。

3.2 为什么消歧优先级最高？

在我的设计思考里，消歧是 P1 级别——出现就必须立即处理，不能等。

原因是：

1. 消歧错了，后面全错。 如果"系统"被错误消歧成"软件系统"，那么所有涉及业务系统的关系推理都会跑偏。

1. 消歧不是一劳永逸的。 知识库在增长，新的文档进来，新上下文出现，原来消歧过的词可能再次产生歧义——就像感冒好了还会再得一样。

1. 消歧必须让用户参与。 因为判断这个词在这个语境里是什么意思，只有两种人有资格：业务专家（懂业务）和文档本身（文本上下文）。LLM 可以提建议，但最终拍板必须是人类。

3.3 一个实际场景

假设我们的 BCM 知识库已经运行了一段时间，以下是某天的场景：

[Agent 收到新文档：某供应商变更通知]

Agent 分析文档，发现其中提到了"系统"这个词

Agent 检查"已消歧词表"：
  → "系统"在 BCM 语境中 = "业务系统" ✓

[继续分析]

Agent 发现新问题：
  → 文档提到"系统A是系统B的备份"
  → 但"系统A"这个名字在现有知识库中没有明确分类
  → 需要确认为什么它既是"核心业务系统"又是"备份系统"？

→ 生成歧义标记：
    "系统A 同时具备 核心业务系统 + 备份系统 属性？
     还是有两种'系统A'指代不同实体？"

然后 Agent 主动找用户确认：

"我在新文档里看到一个词'系统A'，它同时出现在两个不同的语义上下文里，你帮我确认一下：这是同一个系统，还是两个不同的系统？"

这就是强引导型 Agent 的核心特征——Agent 发现问题，立即找用户确认，而不是等问题积累到无法收拾。

四、强引导型 Agent：不是让用户填表，是让用户参与讨论

4.1 为什么现有的 LLM Wiki 工具不够"引导"？

市面上现有的 LLM Wiki 工具（比如 llm_wiki 这个 14k stars 的开源项目）已经做得很好了：

• 有异步 Review 机制，让人类审核 LLM 的输出
• 有 4-Signal 知识图谱，评估关系的可靠性
• 有 Purpose.md，定义知识库的目标和范围

但它们都有一个共同的问题：引导用户的方式是"让你做选择题"或"让你审核"，而不是"和你讨论"。

用户的体验更像是："填表"——工具列出一堆问题，用户逐个回答，流程僵硬。

4.2 真正的强引导是什么样的？

我理想中的 Agent 应该是这样的：

用户只是某个领域的专家，他不懂 AI、不懂 LLM、不懂知识库建设的流程——但 Agent 能主动引导他，给他的每一步都是他熟悉的具体业务问题，而不是 AI 相关的术语。

具体来说，一个强引导型 Agent 的工作流是这样的：

第一步：用户简单描述领域（三两句话）
  例如："我想做一个机器学习模型管理的知识库，团队里有数据科学家和 ML 工程师"

Agent 并不需要用户懂什么是本体论、什么是实体提取
  Agent 只需要知道：用户的业务是什么

第二步：用户提供文件（PDF、Word、Markdown 都可以）
  这是必须的启动条件——内部知识库和互联网搜索不一样，
  必须以内部文档为主

第三步：Agent 开始增量分析
  每当有新文件进来，Agent 就会触发一次 LLM Wiki 分析
  生成实体、概念、关系，写入知识库

第四步：Agent 维护一个"困惑清单"（IdeaPad）
  当 Agent 发现不确定的地方——比如某个词可能有歧义、
  分层结构可能不合理、某个关系可能有问题——
  它会记在 IdeaPad 里，不打断用户的正常工作

第五步：用户有空时说"评估一下知识库状态"
  Agent 基于 IdeaPad 的记录，主动展示它发现的那些未决问题
  用业务语言和用户讨论，而不是用 AI 术语

第六步：用户确认后，Agent 消化反馈，更新知识库
  用户提供的业务判断，其优先级高于文件本身
  ——因为业务专家脑子里装着文件里没有的隐性知识

4.3 核心原则

在整个设计里，有几条核心原则：

五、五环节工作流：方法论固化的具体实现

把上面的设计落到具体操作层面，整个知识库建设分成 5 个环节：

P0 —— 实体/概念提取
  │ 触发：每次新文件 ingest
  │ 主体：Agent 完全自主
  ▼
P1 —— 消歧处理（最高优先级）
  │ 触发：发现歧义词 → 立即触发
  │ 主体：Agent 提方案，用户拍板
  │ 机制：每次 ingest 检查"已消歧词表"
  ▼
P2 —— 结构审议
  │ 触发：用户说"评估知识库状态"
  │ 或：每天半夜（如果当天有 >=3 轮有意义对话）
  │ 主体：Agent 提议，用户审议
  │ 内容：分层是否合理？新的概念层级？
  ▼
P3 —— 一致性检查
  │ 触发：定期或用户手动
  │ 主体：Agent 自动 lint，用户审阅结果
  ▼
P4 —— 本体迭代优化
  │ 触发：P2/P3 发现需要调整
  │ 主体：Agent 提出优化方案，用户批准后执行

六、和现有工具的区别

有人可能会问："你说的这个，和 llm_wiki 有什么区别？"

区别挺大的：

强引导型 Agent 是一个助手，它在配合用户工作。

七、一个有趣的副产品：知识库成了"两个人的共同语言"

在设计这个 Agent 的过程中，我发现了一个有意思的现象：

当业务专家和 Agent 共同维护一个知识库的时候，知识库实际上变成了两个人（业务专家 + Agent）的共同语言。

业务专家不需要学 AI，Agent 不需要学业务——他们通过知识库的本体结构来对齐认知。

业务专家说"核心业务系统"，Agent 知道指哪个分层下的哪个具体实例。

Agent 说"我在 P2 环节发现了分层冲突"，业务专家知道自己需要确认哪两个概念的边界。

八、展望：本体编辑器是下一个难题

我在研究过程中还发现了一个高价值但暂时没想清楚的方向——本体编辑器。

具体来说：如何让业务人员可视化地编辑和查看分层结构？

难点在于：本体结构比文件目录树复杂得多——它有横向关系（不只是上下级包含关系），传统树形 UI 不够用。

可能的方向：

• 拖拽式编辑（类似思维导图）
• 自然语言交互（"把这个概念移到那个层级下"）
• 模板 + 自定义混合

这个问题值得专门研究，这里先列出来，作为未来的演进方向。

总结

1. 问题：LLM Wiki 的扁平结构，Agent 懂但人类看不懂
2. 解法：给每个知识库设计分层本体（骨架 → 器官 → 组织 → 细胞）
3. 关键：消歧要显性化、优先级最高，且会反复出现
4. 设计原则：Agent 引导用户做业务判断，而不是让用户学 AI
5. 工作流：5 环节固化的方法论，用户只需在正确的时机做正确的判断
6. 核心洞察：知识库的终极价值是建立"两个人的共同语言"