第21章 知识工程：本体、抽取与知识图谱¶
RAG 擅长从文档中找到证据，但很多企业问题还需要沿着实体关系继续追问：供应商质量事件影响哪些合同和产品线，某个指标异常关联哪些报表和流程，某条合同责任又对应哪些附件和审批意见。单纯把材料切成 chunk，只能找到局部相似片段，难以稳定表达这些关系链。
知识工程的作用，是把隐藏在文档、业务系统和人员经验中的实体、概念、关系、约束和证据显式化。它听起来像“建知识图谱”，但生产难点并不在图数据库语法，而在本体怎么定义、事实从哪里来、同名实体如何消歧、抽取结果谁复核、权限怎样从原文传到节点和边，以及历史版本怎样保留。
图谱不是为了把文档变成节点，而是为了显式表达稳定的企业实体、关系和约束，并让每条关系都能回到证据。
21.1 知识工程边界：什么时候真正需要图谱¶
RAG、语义层、知识图谱和 GraphRAG 服务的是不同对象。
表21-1：RAG、语义层与知识图谱的边界。来源：本书整理。
| 能力 | 主要对象 | 擅长问题 | 不擅长问题 |
|---|---|---|---|
| 文档 RAG | chunk、文档、引用 | “制度怎么说”“合同条款在哪里” | 复杂关系、全局聚合、实体消歧 |
| DataAgent 语义层 | 指标、维度、表字段、SQL | “指标怎么计算”“查哪些表” | 非结构化关系和开放文本证据 |
| 知识图谱 | 实体、关系、事件、规则 | “哪些对象相互影响”“关系链是什么” | 无证据文本的开放生成 |
| GraphRAG | 图结构 + 文本证据 | 跨文档、跨实体综合回答 | 本体和抽取差时会放大错误 |
表21-2：平台负责人知识工程决策要点。来源：本书整理。
| 决策问题 | 推荐判断 |
|---|---|
| 是否现在做知识图谱 | 问题需要实体关系、影响分析、跨文档综合和长期治理时值得做；普通制度问答先用 RAG |
| 是否上 GraphRAG | 本体、抽取、链接、权限和证据链稳定后再上 |
| 谁维护本体 | 必须同时有业务 Owner 和平台 Owner |
| 安全边界在哪里 | 节点、边、证据和社区摘要都要有权限 |
| 最小上线门槛 | 每条事实有来源、证据、置信度、抽取器版本和复核状态 |
图21-1：企业知识工程技术栈。来源：本书自绘。Alt text：自下而上分层，数据源、信息抽取、本体/实体链接、知识图谱存储、GraphRAG 检索、上层应用，箭头表示文本逐层加工为可推理的知识资产。
图21-2：集团型企业知识资产地图。来源：本书自绘。Alt text：地图按业务域（销售、供应链、财务、人事等）划分，标出各域的核心实体与跨域关系，展示集团知识资产的整体分布与连接点。
普通制度问答、简单定义查询通常不需要图谱；指标口径优先进入语义层；只有问题真正依赖客户、合同、供应商、风险事件、指标和流程之间的关系时，图结构才产生独立价值。
GraphRAG 的前提不是“有图数据库”，而是本体、事实、实体链接、权限和证据已经可治理。否则它只会让错误更有结构、更有说服力。
21.2 本体建模：从业务问题反推实体、关系和约束¶
本体是知识工程的骨架。早期不应追求“大而全”，而应从一个真实问题反推：为了回答这类问题，业务人员会沿着哪些对象和关系查下去？
表21-3：企业本体最小对象。来源：本书整理。
| 对象 | 示例 | 关键字段 |
|---|---|---|
| Entity Type | 客户、合同、产品、指标、服务、工单、风险事件 | 名称、别名、业务主键、来源系统 |
| Relation Type | 签署、归属、依赖、影响、违反、相似 | 方向、基数、置信度、证据来源 |
| Attribute | 合同金额、客户等级、服务负责人 | 数据类型、单位、有效期 |
| Constraint | 一个合同必须归属一个客户 | 校验规则、异常处理 |
| Evidence | 文档片段、SQL、系统记录、人工标注 | source、page、span、timestamp |
合同风险场景可以先定义合同、客户、产品、条款、审批意见和风险类型；DataAgent 场景可以先定义指标、字段、表、报表、业务对象和血缘关系。只有这些对象和关系能被业务解释、系统记录和审计复核，才适合进入本体。
表21-4：本体建模取舍表。来源：本书整理。
| 方案 | 优势 | 代价 | 适用场景 | mini-platform 选择 |
|---|---|---|---|---|
| 文档驱动抽取 | 冷启动快、覆盖历史材料 | 本体容易漂移、事实一致性弱 | 早期探索、知识库增强 | 作为冷启动输入 |
| 业务对象驱动本体 | 结构稳定、便于权限和治理 | 需要业务专家参与 | 合同、客户、指标、服务等核心资产 | 默认路线 |
| 关系优先建模 | 适合依赖和影响分析 | 容易忽略属性与证据 | 运维、供应链、风险传播 | 场景扩展 |
| OWL/RDF 标准建模 | 语义表达严谨、标准生态完整 | 学习和工程成本更高 | 合规、跨组织数据交换 | 按需引入 |
图21-3：企业本体建模工作坊白板。来源：本书自绘。Alt text：白板上用便签和连线标注核心实体（客户、合同、产品）及其关系（签订、包含、关联），体现业务与技术共同梳理本体的协作过程。
本体变更要像数据模型一样版本化。新增实体、修改关系方向、合并概念都会影响抽取器、权限、GraphRAG 查询、语义层和评测样本。
知识图谱的结构不是算法团队闭门设计出来的 Schema，而是业务 Owner、数据 Owner 与平台团队共同维护的语义契约。
21.3 信息抽取与实体链接：事实必须带证据¶
从文档和系统中生成图事实，可以组合规则、传统 NER/RE、LLM、VLM 和人工审核。
表21-5：信息抽取路线。来源：本书整理。
| 路线 | 优势 | 风险 |
|---|---|---|
| 规则和词典 | 可解释、稳定、成本低 | 覆盖率有限、维护成本上升 |
| 传统 NER/RE | 固定实体类型和批量文本稳定 | 需要标注，跨领域迁移有限 |
| LLM 抽取 | 启动快、能处理复杂语义 | 幻觉、格式漂移、成本和一致性问题 |
| VLM 抽取 | 适合票据、截图和页面布局 | 视觉误判需复核 |
| 人工审核 | 高风险事实质量高 | 成本高、吞吐有限 |
事实至少应保留 subject、predicate、object、evidence、confidence、extractor、review status 和生命周期。
{
"subject": {"type": "Contract", "id": "contract-2026-001"},
"predicate": "belongs_to",
"object": {"type": "Customer", "id": "customer-8842"},
"evidence": {
"source_id": "contract-2026-001",
"page": 1,
"span": "甲方：华东分公司"
},
"confidence": 0.91,
"extractor": "llm-extractor-v2",
"review_status": "approved"
}
实体链接比抽取更容易制造高影响错误。阿里云、Alibaba Cloud、aliyun 可能是一个供应商，也可能存在同名主体；业务别名在不同部门里也未必等价。链接应综合别名、业务主键、来源系统、上下文和人工确认。
图21-4：实体链接与消歧流程。来源：本书自绘。Alt text：流程从文本中识别实体提及，到候选实体生成、上下文消歧、链接到知识库唯一 ID，箭头标出同名实体如何被消歧到正确节点。
错误实体合并往往比漏掉一条关系更危险：漏掉关系只是少回答一部分，错误合并会把无关事实串成一条完整的错误路径。 高风险实体应先生成候选，再由规则或人工确认。
21.4 GraphRAG：图结构负责路径，文本和系统记录负责证据¶
GraphRAG 可以组合 Local Search、Global Search、Vector + Graph、Graph + Text Evidence。
表21-6：GraphRAG 检索模式。来源：本书整理。
| 模式 | 做法 | 适合问题 |
|---|---|---|
| Local search | 从实体出发找邻居、路径和证据 | 某客户、合同、服务的局部关系 |
| Global search | 基于社区摘要或全局主题回答 | 跨部门、跨文档整体问题 |
| Vector + Graph | 向量定位候选实体，再沿图扩展 | 表达模糊但实体可定位的问题 |
| Graph + Text evidence | 图路径给结构，文本 chunk 给证据 | 高风险、需要引用的综合问题 |
图21-5：GraphRAG 检索架构。来源：本书自绘。Alt text：查询同时走向量检索找相关片段和图谱遍历找关联实体，两路结果融合后送入生成，箭头表示 GraphRAG 把语义相似与关系推理结合。
图和向量是互补关系。向量适合找到语义候选，图谱适合扩展关系，文本/系统记录再提供最终证据。
这里必须区分三种表达：
- 图中存在某种关系；
- 文本或系统记录支持某个事实；
- 模型基于关系做出了进一步推断。
图路径说明结构，不自动证明因果。高风险结论必须回到可引用文本、系统事实和生效时间，不能把“图里连着”直接翻译成“业务上导致”。
图谱不完整、关系低置信或权限不足时，应降级到普通检索、澄清或人工复核，而不是让模型补齐一条“合理路径”。
21.5 与语义层、权限和业务流程协同¶
知识图谱和 DataAgent 语义层解决不同问题：语义层定义“指标怎么算、查哪些字段”，图谱解释“指标、对象、流程和风险之间怎样关联”。两者可以共享实体、Owner、版本和血缘，但不能互相替代。
本体变化应做跨层影响分析：指标口径是否同步、GraphRAG 路径是否变化、报告模板和评测样本是否受影响。历史报告则要保留当时的 ontology version，而不是自动映射到今天的关系定义。
权限也不能只继承文档 ACL。一个“客户—风险事件”关系本身可能比原文片段更敏感，因此节点、边、图路径和社区摘要都要参与授权。
表21-7：知识资产治理检查项。来源：本书整理。
| 治理项 | 要求 |
|---|---|
| 本体版本 | entity/relation type、属性和约束可版本化 |
| 事实来源 | 每条事实有 source、evidence、extractor、reviewer |
| 权限边界 | 节点和边继承或定义业务 ACL |
| 生命周期 | 新增、更新、失效、合并、拆分都有审计 |
| 质量评估 | 抽取、链接、冲突、孤立节点可观测 |
| Agent 使用 | 哪些工具、RAG、DataAgent 使用了图谱可追踪 |
图21-6：GraphRAG 知识图谱构建报告。来源：本书自绘。Alt text：报告页展示抽取的实体数、关系数、消歧准确率、孤立节点比例等指标，并列出低置信关系待人工复核，体现图谱构建质量可量化。
业务流程变化也应触发知识变更。合同审批、产品线、组织结构和指标口径调整后，对应本体、关系、权限和回归样本要同步更新。
21.6 发布、回滚与运营：事实要有生命周期¶
知识图谱发布会同时改变实体、关系、路径和 GraphRAG 答案，应先在影子图中运行。同一批问题比较新旧图的实体命中、路径、权限裁剪、证据和最终回答，再决定切流。
回滚最好按事实批次或关系粒度完成，而不是只恢复整个数据库快照：
- 抽取器异常 → 回滚
fact_batch； - 实体错误合并 → 拆回实体和相关边；
- 本体关系方向错误 → 回退 schema 版本并重跑；
- 过期事实 → 标记
inactive/retired，停止参与新回答但保留历史审计。
知识运营台账至少记录：ontology version、fact batch、extractor、review status、ACL、上线/下线时间、影响问题集和 Owner。用户反馈实体错误或关系过期时，应该定位到具体实体、边、证据和版本，而不是只生成一个产品工单。
图谱扩张也要受控。新增实体和关系前应明确服务哪些问题、由谁复核、错误如何回滚；没有明确问题和 Owner 的关系可以留在实验图，不应直接进入生产 GraphRAG。
知识图谱越大不代表价值越高。能被真实业务问题稳定使用、被证据支撑、被权限控制并能安全回滚的事实集合，才是生产资产。
本章小结¶
知识工程把企业实体、关系、约束和证据显式化，补足文档 RAG 在关系推理和实体消歧上的不足。语义层负责指标和字段口径，图谱负责实体关系和影响链，两者应协同而非互相替代。
本体应从业务问题反推；抽取事实必须带来源、置信度和复核状态；实体链接尤其要谨慎处理错误合并；GraphRAG 可以用图路径组织复杂问题，但最终结论仍需文本或系统事实支撑。
知识工程真正的生产能力，不是建出一张漂亮的图，而是让每条重要关系知道自己从哪里来、谁确认、谁能看、何时失效，以及出了问题如何撤回。
参考文献¶
- Microsoft GraphRAG: https://microsoft.github.io/graphrag/
- Neo4j GraphRAG documentation: https://neo4j.com/docs/neo4j-graphrag-python/current/
- NebulaGraph documentation: https://docs.nebula-graph.io/
- W3C RDF: https://www.w3.org/RDF/
- W3C OWL: https://www.w3.org/OWL/
- DataHub Glossary: https://datahubproject.io/docs/glossary/