从 Markdown、Wiki 到 AI 知识库：本体与知识图谱到底处在哪一层？

很多团队建设"企业 AI 知识库"时，会把飞书文档导入一个向量数据库，再接上大模型，就宣布知识库已经建成。

这套方案当然能工作，但它也留下了一系列容易混淆的问题：

• Markdown 文件和 Wiki 是什么关系？
• 飞书是不是 Wiki？
• Wiki 和 AI 知识库有什么区别？
• 向量数据库是不是知识库？
• 已经做了 RAG，为什么还会谈本体和知识图谱？
• 本体、知识图谱与数据库 Schema 又有什么不同？

这些概念之所以容易混在一起，是因为它们都与"知识"有关，却分别解决不同层次的问题。

本文不把它们当作一组孤立术语，而是放进一套六层架构中辨析。需要说明的是，这六层是本文为了澄清概念而采用的分析框架，并非强制性的行业标准：

内容载体层：Markdown、飞书文档、PDF
       ↓
知识组织层：Wiki、飞书知识库、Confluence
       ↓
机器检索层：全文索引、向量数据库、RAG
       ↓
语义建模层：分类体系、元数据模型、本体
       ↓
事实关联层：知识图谱、规则与约束
       ↓
AI 应用层：语义搜索、Graph RAG、智能问答、Agent

先给出全文的核心结论：

Markdown 负责表达内容，Wiki 负责人类知识的组织与协作，RAG 负责让 AI 找到相关文档，本体负责定义领域语义，知识图谱负责记录具体事实，AI 应用则负责利用这些知识回答问题或执行任务。

一、Markdown 是格式，.md 是文件，Wiki 是系统

Markdown 是一种轻量级标记语法，用来表达标题、段落、列表、表格、链接和代码块等内容结构。.md 是这类内容常用的文件扩展名。

例如：

# 订单系统

## 负责人

交易研发团队

## 依赖

- 支付系统
- 库存系统

这只是一个 Markdown 文档。它易于阅读、编辑、版本管理和自动处理，但并不天然具备完整的知识库能力。

Wiki 解决的是另一个问题：如何把大量内容组织成可浏览、可链接、可搜索、可协作维护的知识空间。

一个基于 Markdown 的 Wiki 可能具有如下结构：

docs/
├── index.md
├── architecture.md
├── deployment.md
└── troubleshooting.md

Wiki 工具读取这些文件，再提供目录、页面链接、全文搜索、版本记录和网页展示。

因此，二者并不是替代关系：

概念	本质	主要解决的问题
Markdown	文本标记语法	内容如何书写
.md 文件	内容载体	内容如何保存和迁移
Wiki	知识组织与协作系统	大量内容如何连接、发现和维护

一组 .md 文件可以成为 Wiki 的内容源，但零散的 .md 文件不自动等于 Wiki。同样，Wiki 也不一定使用 Markdown：有些产品将内容保存在数据库中，并使用自己的编辑模型。

二、飞书不是 Wiki，但飞书知识库是 Wiki 的一种实现

把一个产品和它提供的某项能力混为一谈，是第二个常见误区。

飞书整体是一套协作办公平台，包含即时消息、在线文档、云空间、多维表格、会议和知识库等能力。它整体不能简单等同于 Wiki。

但飞书知识库具备典型的 Wiki 特征：

• 用层级节点组织内容；
• 支持页面间跳转和引用；
• 提供搜索、权限和协作；
• 适合维护团队的长期知识。

飞书文档与飞书知识库的关系，可以简化为：

飞书文档 = 单篇内容的创作与协作载体
飞书知识库 = 对大量内容进行组织和治理的 Wiki 系统

一篇飞书文档可以独立存在，也可以被加入知识库，成为其中的一个节点。

研发知识库
├── 新人指南             ← 文档
├── 系统架构
│   ├── 总体架构         ← 文档
│   └── 数据库设计       ← 文档
└── 运维手册
    ├── 发布流程         ← 文档
    └── 故障处理         ← 文档

这与基于 Markdown 的 Wiki 在目标上相似，但内容存储和协作方式不同：

维度	飞书知识库	基于 Markdown 的 Wiki
内容载体	平台在线文档	普通 .md 文件
编辑方式	所见即所得、实时协作	文本编辑器或专用工具
版本管理	平台历史记录	通常依赖 Git
权限管理	组织、成员和文档权限	取决于仓库或部署系统
可移植性	受平台导入导出能力影响	通常较强
自动化处理	依赖开放 API	文件天然便于脚本处理

所以，"飞书是不是 Wiki"更准确的回答是：

飞书不是 Wiki 产品的同义词；飞书知识库是飞书提供的一种平台型 Wiki 实现。

三、Wiki 面向人，AI 知识库面向机器利用

传统 Wiki 的第一目标是服务人：让人编写、阅读、查找和共同维护知识。

AI 知识库则进一步要求机器能够检索和利用这些内容。最常见的技术路径是：

飞书知识库 / Wiki / Markdown / PDF
                  ↓
              解析与清洗
                  ↓
                分块
                  ↓
           Embedding 向量化
                  ↓
              向量索引
                  ↓
       检索相关片段并交给大模型
                  ↓
          生成答案并引用来源

例如，员工在飞书中维护《差旅报销制度》。AI 系统同步文档并建立索引后，用户可以询问："一线城市住宿费上限是多少？"系统先检索相关原文，再由大模型组织答案并返回出处。

此时各部分的职责是：

• 飞书知识库负责知识生产、协作与治理；
• 文档解析器负责把平台内容转成机器可处理的文本；
• 向量数据库负责召回语义相近的片段；
• 大模型负责理解问题和组织自然语言答案；
• 来源链接负责把答案追溯回原始文档。

因此，Wiki 可以是 AI 知识库的重要数据源，但二者不能画等号。

四、大多数"AI 知识库"，其实是 RAG 文档检索库

"AI 知识库"并不是一个边界非常严格的术语。在今天的产品语境中，它通常指的是面向大模型的 RAG 文档库。

RAG，即检索增强生成。它的基本思路不是要求模型凭参数记住企业知识，而是在回答前动态检索相关材料，再让模型依据材料生成答案。

这类系统通常保存：

• 文本片段；
• Embedding 向量；
• 文档标题与来源地址；
• 作者、时间、标签和权限等元数据。

它非常适合处理以下问题：

• 某份制度是如何规定的？
• 某个接口应该如何调用？
• 某次故障的处理过程是什么？
• 多篇文档对同一主题分别说了什么？

但它不天然擅长表达以下内容：

• "系统""应用"和"服务"分别是什么类型；
• 某个团队与某个系统之间究竟是负责、使用还是协作关系；
• 一个服务故障会沿依赖关系影响哪些系统；
• 某个对象是否违反了企业规则；
• 某条结论是否能通过明确规则推导出来。

向量检索回答的是"哪些文字与问题相似"，而不是"领域中有哪些确定的对象、关系和约束"。

所以应当谨慎对待这个常见等式：

向量数据库 ≠ 完整的知识库

更准确的说法是：

向量数据库是 AI 知识库的一类检索基础设施；RAG 文档库是知识库的一种实现，但不是知识表达的全部。

五、本体建模：给企业知识建立语义骨架

当团队不只想"搜索文档"，还想统一业务概念、识别对象关系、执行规则校验时，就会进入本体建模的范围。

知识工程中的本体，可以粗略理解为：

对一个领域中的概念、属性、关系和约束作出明确、共享且可计算的定义。

以企业研发领域为例，本体首先定义有哪些概念：

员工、团队、系统、服务、接口、数据库、故障、文档

然后定义概念间允许存在的关系：

员工 --属于--> 团队
团队 --负责--> 系统
系统 --包含--> 服务
服务 --调用--> 接口
服务 --依赖--> 数据库
故障 --影响--> 服务
文档 --描述--> 系统

还可以定义属性和约束：

系统具有：名称、编码、重要等级、生命周期状态
故障具有：发生时间、严重级别、恢复时间

每个生产系统必须至少有一个责任团队
每个生产故障必须关联至少一个受影响系统
已废弃接口不能成为新服务的依赖

这与文档目录有本质区别。

Wiki 中的两个页面互相链接，只能说明它们存在某种关联；本体则要求把模糊的"相关"变成明确的语义：

《订单系统》页面 → 《支付系统》页面

这个链接究竟表示：

• 订单系统调用支付系统；
• 订单系统依赖支付系统；
• 支付系统属于订单系统；
• 两个系统由同一个团队负责？

只有将其明确为：

订单系统 --调用--> 支付系统

机器才可能稳定地查询、校验和推理。

因此，本体的价值不是让文档"看起来更有结构"，而是建立跨文档、跨系统共享的领域语义。

六、本体、知识图谱与数据库 Schema 不是一回事

本体和知识图谱经常一起出现，但二者也不能混为一谈。

本体定义"允许如何表达"：

团队是一类对象
系统是一类对象
团队可以通过"负责"关系连接系统

知识图谱记录"具体发生了什么"：

交易研发团队 --负责--> 订单系统
订单系统 --包含--> 订单服务
订单服务 --调用--> 支付服务
故障 A --影响--> 支付服务
架构文档 A --描述--> 订单系统

可以把它们近似类比为模型和实例：

架构对象	作用
本体	定义概念、关系、属性和约束
知识图谱	按照模型记录具体实体与事实
Wiki 文档	保存解释、上下文和原始证据
图查询与知识服务	查询实体关系并向应用提供结果

它们又与数据库 Schema 有相似之处，但关注点不同。

数据库 Schema 主要关心数据如何存储、字段类型是什么、表之间如何关联。本体更强调概念在业务中的含义、类型继承、跨系统共享语义、关系约束以及可能的逻辑推理。

例如，数据库中可能有三个系统分别使用 app、application 和 system 字段。本体建模要解决的不只是字段映射，还要回答：这三个词是否表示同一个概念？如果不同，边界在哪里？

换句话说：

Schema 更接近存储契约，本体更接近语义契约。

七、Markdown 能承载本体描述，但本身不是本体语言

我们完全可以在 Markdown 中记录领域定义：

# 系统

## 定义

能够独立提供一组业务能力的软件集合。

## 属性

- 系统名称
- 系统编码
- 生命周期状态
- 重要等级

## 关系

- 由"团队"负责
- 包含一个或多个"服务"
- 可以依赖其他"系统"

也可以通过 YAML Front Matter 增加机器可读信息：

---
type: System
id: order-system
owner: order-team
depends_on:
  - payment-system
status: production
---

# 订单系统

订单系统负责订单创建、修改和状态流转。

这种方式适合轻量级知识工程，因为它兼顾了人类阅读和机器处理。但它仍可能遇到：

• 字段命名不一致；
• 关系方向不明确；
• 类型和取值缺乏校验；
• 跨文件约束难以表达；
• 多个团队对同一概念使用不同定义。

因此，Markdown 可以作为本体说明、实体档案甚至轻量结构化数据的载体，但 Markdown 语法本身并不等于本体。

更正式的语义建模可能使用 RDF、RDFS、OWL、SHACL、JSON-LD，或者企业自定义的图模型与元数据平台。选择哪种方式，应由业务复杂度决定，而不是为了"技术先进"而强行引入。

八、RAG 与知识图谱不是替代关系

只使用文档 RAG 时，处理链路大致如下：

用户问题
   ↓
按关键词或向量相似度检索文档片段
   ↓
大模型依据片段生成答案

它的优势是建设速度快、接入内容方便，并且适合解释性、总结性和流程类问题。

加入本体与知识图谱后，可以形成混合检索：

                    ┌→ 文档检索 → 原始描述与证据
用户问题 → 概念识别 ┤
                    └→ 图谱查询 → 实体、关系与规则
                               ↓
                          大模型整合回答

例如，用户询问：

支付服务发生故障，可能影响哪些系统？由哪个团队负责？有哪些处理文档？

单纯依靠向量检索，系统可能找出提到"支付服务"和"故障"的若干文档，但未必能稳定还原完整依赖链。

知识图谱则可以查询：

支付服务 ←被调用--- 订单服务 ←属于--- 订单系统
支付服务 ←负责--- 支付研发团队
支付服务 ←描述--- 支付服务应急手册

然后再从 Wiki 中检索应急手册的具体处理步骤。最终答案既包含结构化关系，也有原始文档作为证据。

这类组合常被称为 Graph RAG、Knowledge Graph RAG 或本体增强 RAG。名称并不是重点，重点是两种知识形态各司其职：

• 文档保留叙述、背景和上下文；
• 图谱保存明确对象、关系和规则；
• 大模型负责理解问题并组织结果，而不是代替事实来源。

九、用一个企业研发知识库串起完整架构

假设一家企业使用飞书维护研发知识。

1. 内容载体层

员工创建：

• 《订单系统架构》；
• 《支付服务接口说明》；
• 《生产故障处理流程》；
• 《研发团队职责》。

这些是文档，可能由飞书在线格式保存，也可能导出为 Markdown 或其他格式。

2. 知识组织层

团队把文档组织到飞书知识库：

研发知识库
├── 系统架构
├── 接口文档
├── 运维规范
└── 团队职责

这一层解决人如何找到、阅读和维护知识。

3. 机器检索层

系统同步飞书内容，完成解析、分块、向量化和权限索引。员工可以询问：

支付超时时应该如何排查？

这一层是典型的 RAG 文档知识库。

4. 语义建模层

企业统一定义：

团队 --负责--> 系统
系统 --包含--> 服务
服务 --调用--> 服务
故障 --影响--> 服务
文档 --描述--> 系统或服务

这一层解决跨团队概念不一致的问题。

5. 事实关联层

企业录入或从多个系统抽取事实：

交易研发团队 --负责--> 订单系统
订单系统 --包含--> 订单服务
订单服务 --调用--> 支付服务
故障 A --影响--> 支付服务
应急手册 A --描述--> 支付服务

这一层形成可查询的知识图谱。

6. AI 应用层

AI 助手同时使用：

1. 图谱查询影响链、责任团队和关联对象；
2. RAG 检索故障处理文档中的具体步骤；
3. 权限系统过滤用户无权访问的内容；
4. 大模型整合结果并附上来源。

这样得到的才是一套相对完整的企业知识架构，而不是一个孤立的聊天框。

十、企业应该建设到哪一层？

不是每个团队都需要从第一天开始建设本体和知识图谱。架构设计的关键不是层数越多越好，而是问题与投入匹配。

场景一：只需要管理和共享文档

优先建设 Wiki：

• 统一目录和命名；
• 明确文档负责人；
• 管理权限、版本和生命周期；
• 减少过期、重复和不可发现的内容。

如果文档本身无人维护，增加 AI 只会让过期知识更容易被搜索出来。

场景二：需要基于内部资料进行问答

在 Wiki 治理基础上建设 RAG：

• 接入数据源；
• 做好解析和分块；
• 保留来源引用；
• 实施权限同步；
• 建立检索与答案评测集。

这是多数企业 AI 知识库最合理的起点。

场景三：需要跨系统关联与责任追踪

引入统一元数据模型、本体或知识图谱：

• 统一"系统、应用、服务、接口"等核心概念；
• 连接组织、资产、流程和文档；
• 支持依赖分析、影响分析和责任定位；
• 将结构化事实与文档证据结合。

场景四：需要规则校验和复杂决策

进一步建设规则与约束：

• 检查生产系统是否具有责任团队；
• 判断新服务是否依赖已废弃接口；
• 根据故障影响范围识别事件等级；
• 为 Agent 提供可验证的业务边界。

可以把这条演进路径概括为：

先把文档管好
    ↓
再让 AI 找得到
    ↓
再把关键概念说清楚
    ↓
再把重要事实连起来
    ↓
最后才谈规则、推理和自动执行

十一、架构设计中最常见的五个误区

误区一：把文件格式当成知识系统

Markdown 只是内容格式。没有导航、检索、链接、治理和维护机制，一堆 .md 文件仍可能只是一堆文件。

误区二：把协作平台整体称为 Wiki

飞书是协作平台，飞书知识库才是其中的 Wiki 能力。明确产品边界有助于判断数据源、权限和集成方式。

误区三：把向量数据库当成完整知识库

向量数据库擅长相似性检索，但不自动提供稳定的领域概念、事实关系和规则约束。

误区四：认为做了知识图谱就不需要文档 RAG

知识图谱很难完整保存制度解释、故障过程、设计权衡等长文本上下文。结构化事实和非结构化文档通常需要共存。

误区五：一开始就追求复杂本体

如果核心概念尚未稳定、数据源质量很差、维护责任不清晰，复杂本体只会变成另一套无人维护的模型资产。

本体应从高价值问题出发，例如：

• 找到系统责任人；
• 分析服务依赖；
• 关联故障与资产；
• 统一跨系统的核心术语。

先建立最小可用语义模型，再随着场景逐步扩展。

十二、总结：不要用一种技术解决所有知识问题

回到开头的问题：把飞书文档导入向量数据库，算不算建成了企业 AI 知识库？

答案取决于目标。

如果目标是让员工基于内部文档进行问答，那么这已经是一套可用的 RAG 型 AI 知识库。但如果目标是统一企业概念、连接跨系统事实、分析依赖关系、执行规则校验，它还只是整个知识架构的一部分。

可以用下面这张表完成最终区分：

概念	回答的问题	最小单位	主要服务对象
Markdown	内容如何书写？	文本标记	人和文档工具
.md 文件	内容如何保存和迁移？	文件	人和程序
Wiki / 飞书知识库	文档如何组织和维护？	页面、目录、链接	人与组织
RAG 文档库	AI 如何找到相关原文？	文本片段、向量、元数据	大模型应用
本体	领域概念和关系如何统一定义？	类、属性、关系、约束	人和机器
知识图谱	具体对象和事实如何连接？	实体、关系、事实	查询与知识应用
AI 助手 / Agent	如何利用知识回答问题或执行任务？	问答、决策、动作	最终用户

最终，一个较成熟的企业知识体系通常不是单一产品，而是三个相互配合的部分：

文档层：飞书 Wiki、Markdown、PDF
作用：保存解释、上下文与原始证据

语义层：本体、知识图谱、规则
作用：保存明确的概念、关系、事实与约束

应用层：RAG、Graph RAG、AI Agent
作用：综合检索、回答问题并执行任务

真正需要做的，不是争论"哪一种才算知识库"，而是先识别当前问题属于哪一层，再选择合适的知识表达和技术方案。