LLM Wiki + Ontology：让企业知识从“可检索”走向“可行动”

很多企业已经把内部文档接入大模型，也做了 RAG。员工问制度、查产品资料，系统基本能回答。

可一旦问题变成：

“帮我看看华东区上个月毛利为什么掉了，顺便找出影响最大的三个客户。”

系统往往就卡住了。

它可能搜到《经营指标口径说明》，也可能知道公司有订单查询、客户分析、财务报表等工具。但“华东区”对应哪些组织编码，“上个月”按自然月还是财务月，“毛利”指毛利额还是毛利率，该调用哪个工具、参数怎么填，这些问题仅靠文档相似度解决不了。

这也是不少企业知识库接入 Agent 后暴露出来的短板：资料很多，知识却没有被组织成一个机器能够理解、查询和行动的业务世界。

LLM Wiki 提供了一种值得关注的知识管理方式；Ontology 则进一步定义这个业务世界中的实体、关系和约束。两者结合，才能让 Agent 从“会搜索资料”走向“理解业务并正确调用工具”。

一、企业缺的往往不是知识，而是知识结构

设想一下，新员工第一次听到“华东大客户毛利”。他需要逐步弄清楚：

• “华东”是销售区域、交付区域，还是客户注册地；
• “大客户”按照合同额、年度收入，还是客户等级判断；
• “毛利”采用哪个财务口径，是否包含渠道返利和售后成本；
• 数据来自订单系统、财务系统，还是经营分析平台；
• 哪个接口能查，调用时需要传什么参数。

这些知识散落在指标文档、组织架构、接口说明、会议纪要和员工经验里。传统知识库通常把它们切成片段、生成向量，再等用户提问时召回。

问题是，相关片段不等于完整答案。系统可能同时召回三份“毛利”定义，却不知道哪一份适用于当前业务；也可能找到一个接口说明，却无法把用户口中的“华东”映射成接口要求的 region_id。

💡 关键洞察：Agent 的上限不只由模型决定，也由企业是否整理清楚“有哪些业务对象、它们如何关联、哪些工具可以操作它们”决定。

二、LLM Wiki：知识不是临时检索，而是提前编译

Karpathy 在 2026 年提出的 LLM Wiki 思路，核心不是换一种知识库界面，而是改变知识处理的时机。

普通 RAG 在收到问题后，临时从原始文档中检索片段，再由模型拼出答案。下一次遇到相似问题，检索和归纳过程还要重来。

LLM Wiki 会先让模型阅读新资料，把内容编译进一个持续维护、相互链接的 Wiki：

• 新的组织文件进入后，更新“华东区”“销售区域”和相关负责人页面；
• 新的财务口径发布后，更新“毛利率”页面，并标记旧口径已被替代；
• 一次高质量分析得到确认后，可以沉淀为新的知识页面；
• 定期检查孤立页面、冲突说法、失效链接和过期结论。

Karpathy 给出的基础架构有三层：

这套方式最有价值的地方，是把每次阅读和分析留下来。新资料不是简单增加几个向量，而是可能更新多个已有页面，补充关系，指出冲突，让知识逐步积累。

不过，原始 LLM Wiki 中的 Schema 更像 Wiki 的维护规范，不等于严格的 Ontology。企业如果想让这些知识参与工具调用，还要补上一层清晰的业务语义模型。

三、企业海量数据如何构建进知识库

讲到这里，一个更现实的问题出现了：企业有数据仓库、业务数据库、上万份文档、几百个 API，还有持续增长的日志和会议记录，难道要把它们全部写进 Wiki？

答案是否定的。

LLM Wiki 不是新的数据湖，也不应该复制所有业务明细。订单流水仍留在数据库，实时库存仍由业务系统管理，日志仍进入日志平台。知识库保存的是这些数据的语义抽象、使用规则和来源指针：这张表代表什么、字段采用什么口径、实体之间如何关联、什么工具能查询、结果是否有权限限制。

3.1 先把数据源分层

不同数据不能用同一种方式摄取。

这一步很容易被忽略。把一亿条订单都做成向量没有意义，Agent 真正需要的是“订单是什么、在哪里查、按什么字段关联客户、查询结果采用哪个时间口径”。

3.2 再做实体抽取、消歧和关系对齐

数据进入后，系统需要完成一轮知识加工：

1. 从文档、数据目录和接口说明中识别客户、产品、区域、指标、工具等候选实体。

2. 把“华东”“东区”“East China”归并到同一个实体 ID，同时保留别名和适用范围。

3. 对齐关系，例如客户归属哪个区域、指标依赖哪些字段、工具能够查询哪些实体。

4. 记录来源、版本、生效时间、负责人和可信状态，避免把旧制度与新口径混在一起。

LLM 很适合做候选抽取、别名发现和关系建议，但实体合并、指标口径、权限规则不能完全自动发布。企业需要审核队列，让业务负责人确认高风险变更。

3.3 把知识编译成多种可查询形态

知识构建完成后，不应该只得到一个向量库。更实用的系统通常同时保留五种入口：

一次查询可以先读 Wiki 目录确定主题，再通过实体索引完成消歧，沿关系拓扑找到数据集和工具，最后用 RAG 补充原始证据。检索不是单一路径，而是一套逐步收窄的路由机制。

3.4 增量更新，而不是定期推倒重建

企业知识每天都在变化。组织和客户主数据可以通过 CDC 或定时同步更新；接口发布时刷新工具 Schema；新制度进入后触发 Wiki 编译；数据负责人确认后再变更指标版本。

每次更新都要回答三个问题：新增了什么实体，影响了哪些旧页面，哪些缓存和索引需要失效。原始证据不覆盖，旧版本不直接删除，查询时按照生效时间选择正确版本。

这才是可长期运行的知识构建流程。一次性导入文档，只能做出一个很快过期的问答库。

四、Ontology 管的不是文档，而是业务世界

Ontology 常被翻译成“本体”。这个词有些抽象，可以把它理解为一套业务世界说明书。

W3C 对 OWL 的说明是：用机器可处理的方式表达事物、事物集合以及它们之间的关系。落到企业场景，Ontology 通常要回答四类问题：

1. 有哪些类型：客户、区域、组织、产品、订单、指标、工具。

2. 有哪些实例：华东区、客户 A、毛利率、订单明细查询工具。

3. 它们如何关联：客户归属区域，订单属于客户，指标依赖数据字段，工具能够查询某类实体。

4. 有哪些约束：毛利率必须指定口径版本；财务数据需要权限；自然语言地区名必须先解析成组织编码。

比如“华东区”可以被维护为一张实体页：

id: region.east_china
type: SalesRegion
name: 华东区
aliases:
  - 华东
  - East China
  - 东区
contains:
  - org.shanghai
  - org.jiangsu
  - org.zhejiang
valid_from: 2026-01-01
source: 2026版销售组织架构
status: verified

“毛利率”也不是文档中的一个词，而是有定义、有版本、有依赖关系的指标实体：

id: metric.gross_margin_rate.v3
type: BusinessMetric
name: 毛利率
formula: （不含税收入 - 可归属成本）/ 不含税收入
time_basis: 财务月
dimensions:
  - region
  - customer
  - product
data_source: finance_mart.profit_detail
replaces: metric.gross_margin_rate.v2
effective_from: 2026-04-01

有了这些实体，系统才知道用户说的词对应什么业务对象。更重要的是，工具、参数和权限也可以进入同一套 Ontology，而不是继续藏在几十份 API 文档里。

五、一套知识如何被多个场景复用

很多企业按项目建设知识库：客服有一套客户库，经营分析再建一套客户库，风控项目又维护一份客户名称映射。项目上线了，知识也被锁在各自的应用里。半年之后，同一个客户在三个系统里出现三个 ID，同一个“收入”指标有四种解释。

要让知识被复用，需要把公共语义层和场景应用层分开。

公共语义层：
  - Ontology：客户、产品、区域、指标、事件等统一类型
  - 实体中心：唯一ID、别名、主数据映射和版本
  - LLM Wiki：定义、规则、关系、经验和来源
  - 工具目录：MCP、CLI、API的能力与参数
  - 检索服务：关键词、向量、实体和图关系查询

场景应用层：
  - 经营分析：查询收入、毛利和客户贡献
  - 客户服务：识别客户、合同、工单与产品
  - 风险管理：查询主体关系、规则和异常事件
  - 采购管理：关联供应商、物料、价格和合同

场景不再复制知识，只声明自己需要哪些实体、关系、工具和权限。例如“华东区”这个实体由公共语义层维护，经营分析用它查毛利，客服用它分派区域服务团队，风控用它聚合区域风险。组织调整后只更新一次，所有场景都读取新版本。

复用不意味着所有应用拥有相同权限。知识定义可以共享，实体属性和工具调用仍要经过租户、部门、字段和行级权限过滤。Agent 能知道“有这个数据”，不等于它可以读取具体数值。

六、把工具也纳入知识管理

不少平台接入了上百个工具，却把每个工具的完整定义一次性塞进模型上下文。工具越多，Token 越贵，模型也越容易选错。

更合适的做法是分两级暴露。

第一级只给 Agent 一份轻量能力目录，例如：

tool_id: finance.query_profit
name: 查询经营毛利
capability: 按区域、客户、产品和月份查询毛利额与毛利率
entity_types:
  - SalesRegion
  - Customer
  - BusinessMetric
risk_level: read_only

当 Agent 判断这个工具可能适用时，再调用统一的 help 工具取得完整说明：

tool: help
arguments:
  tool_id: finance.query_profit

returns:
  description: 查询已关账月份的经营毛利数据
  required_parameters:
    region_id: 标准销售区域ID
    start_period: YYYY-MM格式的财务月
    end_period: YYYY-MM格式的财务月
    metric_id: 已生效的指标口径ID
  optional_parameters:
    customer_level: 客户等级
    top_n: 返回数量，范围1到100
  preconditions:
    - 用户拥有经营分析数据权限
    - region_id必须先经过实体解析
  output:
    - revenue
    - gross_profit
    - gross_margin_rate

这类 help 工具，本质上是工具知识库的查询入口。它让 Agent 在需要时才展开参数、示例、限制和返回结构。

MCP 的官方设计也采用类似思想：通过 tools/list 发现工具定义，通过 tools/call 执行工具；工具输入由 JSON Schema 描述。企业可以在此基础上再增加 Ontology，把“自然语言中的业务实体”与“工具要求的参数类型”连接起来。

💡 关键洞察：工具说明不是开发文档的附属品，而是 Agent 的运行时知识。只要工具可被模型调用，它的名称、能力、参数、约束、权限和示例就应该进入统一知识管理。

七、一次自然语言查询，如何串联多个 MCP 和 CLI

回到最初的问题：

“帮我看看华东区上个月毛利为什么掉了，顺便找出影响最大的三个客户。”

这句话背后可能涉及实体解析服务、财务查询工具、客户主数据和归因分析工具。它们可能来自不同的 MCP Server，也可能是已有 CLI、内部 API 或数据平台查询服务。

是否每次都要把所有 MCP 和 CLI 调一遍？不需要。

如果平台有几百个工具，让模型逐个运行 --help，成本高，也会把大量无关参数塞进上下文。更合理的是两级发现：平台先维护一份轻量能力索引，模型根据用户意图筛出几个候选工具，再按需调用 --help、tools/list 或统一 help(tool_id) 取得完整参数。

整条链路可以拆成六步。

7.1 第一步：查看有哪些工具和参数

CLI 通常通过 --help 暴露子命令、参数和示例；MCP 通过 tools/list 返回工具名称、描述和输入 Schema。平台可以把两者统一成一个能力目录：

查询诉求: 华东区上月毛利下降原因

候选能力:
  - entity.resolve
    来源: master-data MCP
    用途: 解析区域、客户、产品和指标实体
  - finance.query_profit
    来源: finance CLI
    用途: 按期间和维度查询收入、毛利额、毛利率
  - finance.query_profit_drivers
    来源: analytics MCP
    用途: 分析价格、销量、成本和一次性项目的影响

能力索引可以定期从 MCP Schema、CLI --help、OpenAPI 文档和数据目录中同步。只有工具版本发生变化时才重新编译，不必每次用户查询都从头扫描。

7.2 第二步：模型选择合适的工具组合

模型先判断任务需要哪些能力，而不是立即生成调用参数。这个问题至少包含三个子任务：

• 解析“华东区”“上个月”“毛利”；
• 查询本期、对比期以及客户维度的毛利数据；
• 对下降幅度最大的客户做原因分析。

因此，它可能选择一个实体解析 MCP、一个财务 CLI 和一个归因分析 MCP。简单查询则可能只需一个工具。例如“客户 A 属于哪个区域”只需要实体或主数据服务。

工具选择依赖三类知识：能力描述是否匹配用户目标，工具是否支持需要的实体与维度，当前用户是否拥有调用权限。

7.3 第三步：把自然语言转换成时间、实体和指标

这一步是 Ontology 真正参与运行的地方。模型不能把用户原话直接塞给底层接口，而要形成标准查询语义：

原始表达:
  区域: 华东区
  时间: 上个月
  指标: 毛利
  目标: 找出下降原因和影响最大的三个客户

标准语义:
  region_id: region.east_china
  current_period: 2026-06
  comparison_period: 2026-05
  metric_id: metric.gross_margin_rate.v3
  ranking_metric: gross_profit_delta
  group_by: customer
  top_n: 3

时间转换需要结合当前日期、财务日历和数据关账状态。实体转换需要处理别名、层级和生效版本。“毛利”如果存在多个合法口径，系统应根据部门默认规则选择，无法确定时再询问用户。

7.4 第四步：Agent 绑定参数并发起调用

模型已经确定语义，Agent 再根据工具的参数 Schema 绑定字段：

工具: finance.query_profit
参数:
  region_id: region.east_china
  start_period: 2026-05
  end_period: 2026-06
  metric_id: metric.gross_margin_rate.v3
  group_by: customer
权限上下文:
  user_id: user.1024
  data_scope: east_china

调用前要做类型、枚举、时间范围和权限校验。查询类工具可以自动执行；涉及写入、付款、发消息等高风险操作时，还需要审批或人工确认。

7.5 第五步：模型解析返回结果，必要时继续调用

财务工具可能只返回一张客户毛利变化表。模型从中找出 A、B、C 三个客户贡献了 78% 的降幅，但这还不足以回答“为什么”。于是 Agent 再调用归因工具，查询价格、销量、成本和一次性费用。

第一次观察:
  华东区毛利率: 下降2.1个百分点
  主要影响客户: [客户A, 客户B, 客户C]
  三家客户贡献: 毛利额降幅的78%

下一步行动:
  tool: finance.query_profit_drivers
  customer_ids: [customer.a, customer.b, customer.c]
  period: 2026-06

第二次观察:
  客户A: 折扣增加
  客户B: 原材料成本上升
  客户C: 一次性售后成本

这就是 ReAct 的作用：模型根据工具返回的观察更新判断，再决定是否继续调用。步骤二到步骤五可能循环多次，直到证据足以回答问题，或者系统发现权限不足、参数缺失、结果冲突而停止。

7.6 第六步：生成用户真正需要的结果

最终回复不应只是把工具 JSON 改写成自然语言。模型还要完成排序、对比、归因和口径说明，并保留可追溯信息：

结论:
  华东区2026年6月毛利率环比下降2.1个百分点。
  客户A、B、C贡献了78%的毛利额降幅。

原因:
  - 客户A折扣率提高，是最大影响项
  - 客户B原材料成本上升
  - 客户C发生一次性售后成本

口径与来源:
  指标: metric.gross_margin_rate.v3
  区域: region.east_china
  数据工具: finance.query_profit
  归因工具: finance.query_profit_drivers
  数据状态: 2026-06已关账

用户看到的是一份分析结论，系统内部则完成了工具发现、语义转换、参数绑定、多步执行和证据整理。LLM Wiki 保存工具与业务知识，Ontology 提供统一语义，MCP/CLI 负责访问真实系统，ReAct 负责在执行中调整下一步。

八、LLM Wiki 和 RAG 到底有什么区别

RAG 与 LLM Wiki 并不是二选一。两者解决的问题不同。

RAG 的经典定义来自 Lewis 等人在 2020 年发表的论文：模型在生成答案时访问外部的非参数化知识。工程上通常表现为切分文档、建立索引、检索片段，再把片段交给模型回答。

LLM Wiki 更像一个位于原始资料和问答系统之间的“知识编译层”。模型在资料进入时就完成抽取、归并、交叉引用和冲突标记，查询时优先读取已经维护好的知识页面。

企业中的合理组合通常是：

• 原始文档继续由 RAG 提供大范围检索和证据定位；
• 高频、稳定、跨文档的知识编译进 LLM Wiki；
• Ontology 统一实体、指标、关系、权限和工具语义；
• Agent 通过 help 获取工具细节，再用 ReAct 完成任务。

换句话说，RAG 负责找证据，LLM Wiki 负责沉淀认识，Ontology 负责统一语言。

九、企业如何开始：先做一个最小可用 Ontology

不要一开始就试图给整个公司建一张完美的知识图谱。范围过大，半年后可能还停留在字段讨论。

更实际的办法，是选择一个高频、数据明确、结果容易验证的业务场景。例如经营分析、售后工单或采购询价。

9.1 选出最小实体集合

以经营分析为例，第一版可以只有区域、客户、产品、订单、指标和工具六类实体。先解决一个问题：用户说出的业务词，能否稳定映射到系统中的唯一对象。

9.2 为每类实体建立规范页面

页面至少包含唯一 ID、名称、别名、定义、关系、来源、版本、负责人和验证状态。LLM 可以协助抽取，但新增实体、合并实体和修改核心口径要有人审核。

9.3 把工具注册成知识实体

每个工具都要说明：它能解决什么问题、输入参数对应哪些实体类型、调用前置条件、权限、风险、返回结构和失败处理方式。

然后提供统一的能力检索和 help 接口。Agent 不需要提前背下所有工具，只要知道在哪里查。

9.4 建立 Wiki 的摄取、查询和巡检流程

新资料进入时，不能只新增页面，还要检查它影响了哪些旧页面。过期指标要标记替代关系，组织调整要设置生效时间，矛盾结论要保留来源并进入审核队列。

9.5 用真实任务评测，而不是只测问答

评测至少要覆盖：

• 实体解析是否正确；
• 指标口径是否匹配场景；
• 工具选择和参数填写是否正确；
• 权限不足时是否停止；
• 多步调用能否根据观察调整计划；
• 最终结论能否追溯到知识页面和工具结果。

如果只测“答案像不像”，很容易得到一个说得通、却调用错系统的 Agent。

十、知识管理的终点，是让知识能够参与行动

过去做知识库，目标常常是“让员工搜得到文档”。大模型出现后，目标开始变化：系统需要理解知识之间的关系，并据此选择工具、补齐参数、执行任务。

LLM Wiki 解决了知识如何持续沉淀的问题。Ontology 让业务对象、指标口径和工具能力拥有统一语义。RAG 保留对大规模原始资料的检索能力。ReAct 则把这些知识带入一次次真实行动。

这套体系最难的部分，不是搭建向量库，也不是给 Agent 再写一版更长的 Prompt。真正费功夫的是实体治理：同一个客户有没有多个名字，同一个指标有没有多个口径，一次组织调整从哪天生效，一个工具参数究竟对应哪个业务对象。

这些基础工作有些琐碎，却决定了 Agent 是在“猜着调用”，还是在一个清楚、可追溯的业务世界里行动。

本文由 JOTO AI 智库从已授权的 53AI 知识库同步。

原始来源：53AI FDE 知识库