行业知识图谱应用

小象实战讲义 · 知识图谱

前面的章节把知识图谱的通用技术——表示、抽取、存储、推理、问答——逐块拆开讲透了。本章把视角从「技术本身」拉到「行业落地」：当知识图谱走进银行、医院、图书馆和一个个垂直领域，问题就从「能不能建出来」变成「准不准、全不全、敢不敢拿去支撑决策」。本节先建立行业知识图谱的概念坐标，再巡览金融证券、生物医疗、图书情报等典型应用，剖析企业全量数据融合的五大挑战与知识图谱六阶段生命周期，最后用两个从零构建的领域案例，把方法论落到具体的三元组、融合规则与问答 pipeline 上。

💡 核心导读

• 概念坐标：行业知识图谱面向特定领域，强调知识的深度与完备性、准确度与严格丰富的数据模式；它与强调广度、面向搜索推荐问答的通用知识图谱形成互补，而不是替代。
• 应用形态：金融证券是行业图谱落地最深的领域——企业风险评估、最终控制人追溯、企业间路径发现、辅助信贷审核与组团骗贷识别，本质都是「关联 + 推理（图计算）」两件事；生物医疗、图书情报、农业、政府、客服各有自己的图谱形态。
• 落地挑战：从数据库时代走到大数据时代（DB→BD），企业要融合使用全量数据，面临多源异构难融合、模式动态变迁、非结构化难理解、使用门槛高、分散数据难统一消费五大挑战，知识图谱给出了一一对应的解法。
• 工程主线：行业知识图谱有一条清晰的生命周期——知识建模、知识获取、知识融合、知识存储、知识计算、知识应用，底层以 W3C 的 RDF/OWL/SPARQL 语义网标准为技术规范。
• 案例方法：佛学领域图谱与农业领域问答两个案例，完整走通「知识收集 → 主语/谓语/宾语三层融合 → 规则补全 → 智能问答」的链路，是理解领域图谱构建最具体的抓手。

一、从通用知识图谱到行业知识图谱

1.1 先有通用：Things, not strings

谷歌在 2012 年提出知识图谱时，口号是 “Things, not strings”——搜索不再匹配字符串，而是理解字符串背后的事物及其关联。这套面向全领域的图谱很快支撑起一整代人工智能应用：

• 语义搜索：Google、Bing、百度，把查询词链接到实体，给出知识卡片而非十条蓝链；
• 私人助理：Siri、Google Now、微软小娜、百度度秘，依赖背景知识理解指令；
• 聊天机器人：微软小冰、公子小白，用知识维系多轮对话的话题连贯性；
• 智能硬件：Apple Watch、Ticwatch 等可穿戴设备，以及智能家居、智能厨房；
• 计算知识引擎与决策支持：IBM Watson Health 这类系统，把知识计算直接用于专业判断。

这类图谱就是通用知识图谱（Generic Knowledge Graph）。它面向全领域，主要服务互联网场景下的搜索、推荐、问答；强调的是广度，强调更多的是实体，覆盖面越宽越好，因此很难生成一个完整的、全局性的本体层来统一管理所有知识。代表性项目分两类：

1.2 再有行业：Palantir 给出的另一条路

通用图谱追求「什么都知道一点」，但在反恐、金融风控、政府情报这类场景里，「知道一点」远远不够。硅谷大数据公司 Palantir 是行业知识图谱的代表：它的核心思想是动态本体（Dynamic Ontology）——数据模型不预先写死，而是随着数据接入和分析深入不断演化，让分析人员能够把人、机构、事件、账户、地点快速织成一张可推理的关系网。

课件给行业知识图谱（Domain-specific / Industry Knowledge Graph）下的定义包含四层含义：

1. 面向特定领域，而不是全领域；
2. 用户目标对象要覆盖行业中各种级别的人员（IT 部门、业务部门、管理部门，同一部门不同层级），不同人员的操作和业务场景不同，因而要求知识具备一定的深度与完备性；
3. 对准确度要求非常高，图谱通常用于辅助各种复杂的分析应用或决策支持，一条错误的持股关系可能导致错误的风控结论；
4. 拥有严格而丰富的数据模式（schema），实体的属性通常比较多，而且每个属性都具有明确的行业意义。

准确度的量级差异值得单独强调（讲师课上给出的量级对比）：学术关系抽取评测里，准确率 80% 多、召回率 70% 多已算不错，优化到 90% 就是很好的论文；而金融落地系统往往要求 99% 量级——差的不是几个百分点，而是一个数量级的工程难度。这正是行业图谱必须在模式层投入大量人工校验、在数据层严格融合的根本原因。

1.3 行业数据的四个特点

行业知识图谱面对的数据，和百科式的通用数据有明显区别：

• 数据来源多：企业内部数据（业务库表、涉密部门数据）、互联网数据（新闻、论坛、微博）、第三方数据（征信、工商），缺一不可；
• 数据类型多：结构化、半结构化、非结构化并存，而且半结构化与非结构化的占比越来越大；
• 数据模式无法预先确定：传统数据仓库「先有模式后有数据」；行业场景里事先不知道表会建成什么样、属性会增加到多少、表间会产生什么关联，模式只能在数据出现之后逐步确定，并随数据增长不断演变；
• 数据量大：大数据背景下，行业应用的数据量通常以亿级实体计算，存储规模常在 TB、PB 级别甚至更多（例如电商平台的商品知识图谱）。

行业知识图谱的应用面已经很广：生物医疗、电商、出版、农业、政府、电信、图书情报、金融证券。OpenKG 等开放社区上也能看到一批行业项目：生物医药领域的 Linked Life Data、地理领域的 GeoNames、有色行业产业链图谱、中医医案知识图谱、华人家谱关联数据集、开放政府数据（Open Government Data）等。

1.4 通用图谱与行业图谱：一张对比表

用三元组看两者的差异最直观。通用图谱里的三元组长这样，属性宽泛、结构松散：

<北京>   <位于>   <中国>
<北京>   <人口>   "2189.3万"
<北京>   <别称>   "北平"

金融行业图谱里的三元组则带有强烈的行业语义——有方向、有比例、有时间、有证据来源，且必须精确：

<甲公司>      <持股>            <乙公司>            # 持股比例 85%（比例另行建模）
<张三>        <任职>            <甲公司>            # 职务：董事长，任期：2019-至今
<乙公司>      <被列为失信被执行人>  <失信记录#2023-017>
<丙招投标项目> <中标方>          <乙公司>            # 公告日期：2024-03-12

1.5 二者互补：广度做底，深度做尖

通用图谱和行业图谱不是竞争关系，而是相互补充、双向流动：

• 通用知识是行业构建的基础（种子）：行业冷启动时实体从哪来？以农业为例，病虫害、动植物实体很难靠封闭专业书籍穷举，可先从百科类通用图谱取出相关实体集合，作为 NER 与实体链接的初始词典（种子实体），再到行业语料里扩展；
• 行业知识再回补通用：行业图谱在垂直领域挖得深、建得密，经过校验的实体和关系可反过来融合进通用图谱，填补其在专业领域的稀疏地带。

一句话：通用知识图谱的广度 + 行业知识图谱的深度，相互补充，才能形成更加完善的知识图谱。

二、行业知识图谱的典型应用

2.1 金融证券（一）：企业知识图谱

企业知识图谱围绕「企业」这一核心实体组织数据。课件给出的数据维度有九类：企业基础数据、投资关系、任职关系、企业专利数据、企业招投标数据、企业招聘数据、企业诉讼数据、企业失信数据、企业新闻数据。用 Turtle 片段表示一个最小模式：

@prefix ex:   <http://example.org/finance/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:甲公司 a ex:Company ;
    ex:统一社会信用代码 "91110000XXXXXXXX1A" ;
    ex:持股 [ ex:标的 ex:乙公司 ; ex:比例 "0.85" ] ;        # 投资关系
    ex:高管 [ ex:人物 ex:张三 ; ex:职务 "董事长" ] ;          # 任职关系
    ex:拥有专利 ex:专利_ZL01 ;                              # 专利数据
    ex:中标   ex:招投标项目_0312 ;                          # 招投标数据
    ex:涉诉   ex:诉讼案_2023_045 ;                          # 诉讼数据
    ex:失信记录 ex:失信_2023_017 ;                          # 失信数据
    ex:相关新闻 ex:新闻_2024_0501 .                         # 新闻数据

在这套数据之上，长出六类典型应用。

（1）企业风险评估。 基于企业基础信息、投资关系、诉讼、失信等多维度关联数据，用图计算构建科学、严谨的风险评估体系，规避潜在的经营与资金风险。用户群体是银行、担保、投行、政府等；应用环节包括客户资源分类管理、信贷前期风险评估、采购企业风险审核、招投标企业资质评级等；商用产品通常输出信用等级、综合信用评价，或直接给出风险低/中/高。

（2）企业社交图谱查询。 基于投资、任职、专利、招投标、涉诉这五类关系，以目标企业为核心向外层层扩散，形成一张网络关系图，直观、立体地展现企业关联；再结合社区发现（Community Detection）等社交网络分析方法，可以挖出潜在关系和隐性群体——例如通过共同的董监高、共同的专利合作人识别出一组表面无关、实则同一控制人的企业群。

                    专利合作人
                       │
   涉诉 ── 甲公司 ── 投资 ── 乙公司 ── 招投标 ── 丙公司
              │                    │
            任职 ── 张三        任职 ── 李四
              │                    │
            戊公司 ── 投资 ───── 己公司
   （以甲公司为核心，沿五类关系层层扩散；社区发现把虚线内企业识别为同一群体）

（3）最终控制人查询。 基于股权投资关系，从目标公司出发，逐层寻找持股比例最大的股东，沿持股链反向（向上）追溯，最终落到自然人或国有资产管理部门。注意持股边的方向是「股东 → 公司」，而追溯方向与之相反：

张三（自然人，最终控制人）
  │ 持股 70%
  ▼
甲公司 ──持股 85%──> 乙公司 ──持股 60%──> 丙公司（目标公司）
  # 查询时从丙公司出发，沿持股边反向逐层上溯到链条顶端的张三

（4）企业之间路径发现。 在股权、任职、专利、招投标、涉诉关系构成的网络中，查询两家企业之间的最短关系路径，用路径长度衡量企业之间联系的密切程度——路径越短、路径上的关系越强，关联越紧密。

（5）初创企业融资发展历程。 按投融资事件发生的时间顺序，记录一家初创企业从天使轮、A 轮到后续各轮的融资发展历程。融资事件本质是带时间的多元组（N-ary）事件，不是简单三元组，需要把「时间、轮次、金额、投资方」整体建模为一个事件节点。

（6）上市企业智能问答。 面向上市企业数据做自然语言问答。讲师特别指出：这类业务问答逻辑复杂，纯靠算法端到端生成难以保证准确，工程上通常在后台定制大量模板，把高频问题的查询逻辑固化下来，用模板换取准确率。

2.2 金融证券（二）：金融交易知识图谱

企业知识图谱刻画的是企业之间的关系；金融交易知识图谱 = 企业知识图谱 + 交易侧四类数据：交易客户数据、客户之间的关系、金融交易数据、交易行为数据。

（1）辅助信贷审核。 客户信息原本散落在信用卡、储蓄卡、信贷等不同系统里，彼此孤立：同一个人在 A 系统的负债，B 系统审核时看不到，就可能造成信用重复使用、信息不完整。基于图谱的统一查询让一笔申请进来时，客户在本行的全部资产、负债、关系一次拉齐。

（2）反欺诈之一：不一致性验证。 思路类似交叉验证。例如借款人 A 和借款人 B 填写的是同一个公司电话，但 A 填写的供职公司和 B 填写的供职公司完全不一样——电话与公司的对应关系出现了矛盾，这就是一个风险点，需要审核人员格外注意。用三元组描述这条规则：

借款人A ──填写公司电话──> 电话T
借款人A ──供职公司─────> 公司X
借款人B ──填写公司电话──> 电话T
借款人B ──供职公司─────> 公司Y（X ≠ Y）
⇒ 触发「不一致性验证」风险点

（3）反欺诈之二：组团骗贷识别。 组团欺诈的成员会用虚假身份分别申请贷款，但部分信息是共享的。贷款人 A、B、C 之间表面上没有任何直接关系，但在图谱上可以清楚看到三者共享着同一电话、同一地址或同一担保人，形成一个高密度的子图模式——这就是组团骗贷的典型信号：

        电话T / 地址D / 担保人G          ← 共享信息节点
        ╱      │      ╲
      申请人A  申请人B  申请人C          ← 三人之间无直接关系，却被共享信息织成一团

（4）其它场景：异常分析（异常交易、异常客户发现）、失联客户管理（通过关系网找回失联人）、精准营销、智能投研、智能公告等。

2.3 生物医疗

医疗知识图谱由两类东西相加而成：医疗数据 + 知识图谱。医疗数据包括医疗专业知识、医疗文献、医疗常识、电子病历大数据、医案、现有医疗资源、疾病库、指南与规范。医疗是对准确度要求最苛刻的领域之一，也是行业图谱价值最直接的领域，课件给了三个代表性方向：

• 中医药知识平台（http://www.tcmkb.cn）：针对中医药知识体系做系统梳理、建模和展示，以图形可视化方式展示核心概念之间的关系，辅助中医专家厘清学术发展脉络、浏览中医知识、发现知识点之间的联系；与逐篇翻阅文献相比，可以大幅度节约知识检索与获取的时间。
• Watson 辅助诊断与治疗：安德森癌症中心曾联合 IBM Watson 开展「终结癌症」的任务，用计算知识引擎辅助癌症的诊断与治疗方案推荐。
• Open PHACTS 新药发现：欧盟重大联合攻关项目，开发面向药物研发的开放数据访问平台，核心技术就是语义技术——用 RDF/本体把分散在各数据库里的药物、靶点、通路、文献链接起来，研究人员一次查询即可跨源获取原本要在几十个数据库间手工拼接的数据。

2.4 图书情报

图情资源知识图谱 = 图书情报资源 + 行业知识图谱。资源侧包括：图书馆分类学体系与特定方向的知识体系，图书、期刊、论文、专利、报刊，百科数据，以及行业网站数据。典型应用有三类：

• 知识导航与资源展示：用图谱中的知识体系做导航，引导用户沿着学科体系学习，并通过实体链接把概念节点关联到具体的图书、论文等资源；
• 知识点推荐与搜索：以知识点而非关键词为单位做推荐和检索；
• 图情资源统计：在统一的本体上做学科分布、资源增长、引用网络等统计分析。

2.5 其它行业

• 农业：识别作物危害（病虫害诊断），本节第五部分的农业案例会展开；
• 政府：政府大数据管理，把跨部门数据用图谱统一组织；
• 客服系统：基于知识图谱的智能客服，用行业知识替代通用闲聊，回答产品、政策、流程类问题。

三、行业知识图谱的落地挑战与解决思路

3.1 从 DB 到 BD：时代变了

企业希望融合使用全量数据，但从数据库时代（DB）走到大数据时代（BD），数据的四个基本面全变了：

3.2 五大挑战逐条拆解

挑战 1：多源异构数据难以融合。 同一个人的信息散落在企业内部数据库、新闻网站、论坛帖子、微博里。课件的例子是「顾军，生于 1963 年，江苏南通人，中国核工业」——这几条信息分别躺在不同源头，不融合就拼不出一个完整的人物画像。信息聚合、数据融合的需求极其迫切。

挑战 2：数据模式动态变迁困难。 传统关系库里，客户一个新需求、业务一个新认知，程序员就要痛苦地修改数据结构和业务逻辑：加字段、改表、改关联、改上层代码，带来响应速度慢、人员投入大、数据结构难改动、扩展性差、维护成本高一连串问题。行业需要的是可自由扩展的数据模式。

挑战 3：非结构化数据计算机难以理解。 Web 的主体是文档（Web of Document），计算机无法直接理解非结构化文本的语义，企业迫切需要把非结构化数据结构化，走向以事物为中心的 Web of Data。

挑战 4：数据使用专业程度过高。 业务人员不会写 SQL、更不会做多表 join，数据都在，但只有工程师能取到。行业智能问答可以大幅降低数据使用门槛——业务人员用自然语言提问，系统翻译成图查询返回答案。

挑战 5：分散的数据难以统一消费利用。 企业内业务系统繁多、使用方式各异、难以全局把握。需要一个基于知识图谱的，集存储、融合、分析于一体的统一平台，为用户提供统一的消费入口，以检索、可视化、分析等不同形态把数据交付出去。

3.3 知识图谱给出的解法

课件把五个挑战与技术方案做了一一映射：

• 挑战 1 → 本体统一建模：用知识图谱（本体）对各种类型的数据进行抽象建模，基于可动态变化的「概念—实体—属性—关系」数据模型，实现各类数据的统一建模；
• 挑战 2 → 模式可演化的存储：使用支持数据模式动态变化的知识图谱存储，支撑大数据与模式动态变化（加一类实体、加一个属性，不必改表结构）；
• 挑战 3 → 信息抽取：利用信息抽取技术，对半结构化与非结构化数据进行抽取和转换，形成知识图谱形式的知识；
• 挑战 4、5 → 统一知识服务平台：在知识融合的基础上，基于语义检索、智能问答、图计算、推理、可视化等技术，提供统一的数据检索、分析和利用平台。

从业务视角看，语义理解、数据关联探索、业务动态扩展、智能检索与问答这些业务需求，分别对应数据结构化、数据融合、自由扩展数据模式、行业智能问答这些技术方案，去解决五个数据挑战。归根到底，知识图谱在行业里就两大作用：第一是关联，第二是推理——关联靠图模型把散落数据织成网，推理靠图计算与本体推理在网上发现新知识、支撑决策。

四、行业知识图谱的生命周期与技术标准

4.1 六阶段生命周期

行业知识图谱的构建与运营是一个首尾相接、循环迭代的环，包含六个阶段：

        知识建模（定模式/schema）
            │
            ▼
知识获取（D2R/包装器/信息抽取）──► 知识融合（模式层+数据层）
                                        │
                                        ▼
知识应用（语义搜索/问答/可视化）◄── 知识计算（图挖掘/本体推理/规则推理）◄── 知识存储

（1）知识建模：建立知识图谱的数据模式，对整个图谱的结构进行定义，因此必须保证可靠性。两条路径：

• 自顶向下：由领域专家手工编辑形成数据模式；
• 自底向上：基于行业现有的标准进行转换，或从现有的高质量行业数据源（如业务系统数据库表）中映射得到。

建模环节的关键技术难点包括：支持多人在线协同编辑并实时更新；能导入集成现有的结构化知识；支持大数据量；能支撑事件、时序等复杂知识表达；能与自动算法结合，避免全人工操作。

（2）知识获取：从不同来源、不同结构的数据中提取知识，形成 RDF 三元组、多元组事件、Infobox、时序信息等存入图谱。不同数据源对应不同技术：

（3）知识融合，分两层：

• 数据模式层融合：概念合并、概念上下位关系合并、概念的属性定义合并；
• 数据层融合：实体合并、实体属性融合、冲突检测与解决。

行业图谱的模式通常自顶向下与自底向上结合、且经人工校验，可靠性有保证，因此融合的关键任务落在数据层。融合还涉及跨语言融合（如中文医学体系、英文医学体系与 ICD 国际疾病编码对齐）。开放域经典参照有 DBpedia Mapping（维基模板到本体的映射，http://mappings.dbpedia.org/ ）与 sameAs 识别（依据标签、摘要、信息框、主题等信号判断两个 IRI 是否同一实体）。Google 的 Knowledge Vault 是自动化融合代表：以 Gmail、Google+、YouTube 等互联网信息为来源，算法自动搜集整编，到 2014 年入库 16 亿条，其中约 2.7 亿条是真实性 90% 以上的「事实」，并可建立历史和社会模型。融合四难点：不同来源形态的融合、海量高效融合、新增实时融合、多语言融合。

（4）知识存储。基本存储对象包括：三元组知识、事件信息、时态信息、用知识图谱组织的数据；上层应用还要求存储层支持知识推理、知识快速查询、图实时计算。对应难点是：大规模三元组存储、图谱组织的大数据存储、事件与时态信息存储、快速推理与图计算支持。

（5）知识计算，三条技术路线：

• 图挖掘计算：基于图论算法对图谱做探索和挖掘（路径、社区、中心性等）；
• 本体推理：用本体推理做新知识发现或冲突检测；
• 基于规则的推理：用规则引擎编写业务规则（如「担保人失信则被担保贷款降评级」），通过推理辅助业务决策。

难点在于：大规模图算法的效率、大数据量下的快速推理、增量知识和规则的快速加载。

（6）知识应用，三类出口：

• 语义搜索：解决关键字的语义多样性与语义消歧难题，通过实体链接实现知识与文档的混合检索；
• 智能问答：理解用户输入的自然语言，从知识图谱或目标数据中给出答案；
• 可视化决策支持：提供统一的图形接口，结合可视化、推理、检索，成为用户获取信息的入口。

应用侧的难点同样具体：语义检索要处理自然语言的表达多样性与歧义；智能问答要做准确的语义解析、正确理解真实意图、做好答案确定与排序；可视化要辅助模式快速发现、支持高效缩放导航，并解决大图环境下底层图挖掘算法的效率问题。

4.2 技术底座：RDF、OWL 与 SPARQL

行业知识图谱的基础技术规范是 W3C 推荐的语义网标准栈，三块基石必须掌握。

RDF（Resource Description Framework）是语义网标准的第一层：Resource 是任何具有 URI 标识符的资源（页面、图片、视频），Description 是资源的属性、特征与资源间关系，Framework 是描述它们的模型、语言与语法。RDF 是三元组模型，每份知识都可分解为 (subject 主, predicate 谓, object 宾)，在图里对应 (顶点, 边, 顶点)，三元组即图中的一条弧，因此 RDF 本质是链接资源描述的图模型。除最常用的 Turtle 外，还有 TriG、N-Triples、N-Quads、JSON-LD（基于 JSON 的 RDF 序列化，课件原文简写为 JSON）、RDFa 等序列化语法。

OWL 是 RDF Schema 的扩展，提供更强的模式表达能力：复杂类（交集、并集、补集）、属性约束（存在量化、全称量化）、基数约束（最大/最小基数）、属性特征（函数式 Functional、逆函数式 InverseFunctional、传递 Transitive、对称 Symmetric、非对称 Asymmetric、自反 Reflexive、非自反 Irreflexive）、属性链（Property Chain）。另有一类属性间公理，如逆属性 owl:inverseOf。需要澄清：「不相交（disjoint）」也是类与类之间（owl:disjointWith）或两个属性之间（owl:propertyDisjointWith）的公理，并不是单个属性的特征——课件页把「不相交」与属性特征并列，属于简化表述。以金融风控为例，用 OWL 可以直接定义「高风险企业」这个复合概念和「间接持股」这条传递链：

@prefix ex:  <http://example.org/finance/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

# 复杂类（交、并）：高风险企业 = 有失信记录 且（有重大涉诉 或 股权高度集中）
ex:高风险企业 a owl:Class ;
    owl:equivalentClass [
        owl:intersectionOf (
            ex:有失信记录的企业
            [ owl:unionOf ( ex:有重大涉诉的企业 ex:股权高度集中的企业 ) ]
        )
    ] .

# 属性链：甲持股乙、乙持股丙 ⇒ 甲间接持股丙（最终控制人追溯的逻辑基础）
ex:间接持股 a owl:ObjectProperty ;
    owl:propertyChainAxiom ( ex:持股 ex:持股 ) .

SPARQL（SPARQL Protocol and RDF Query Language）是 RDF 的查询语言，基于 RDF 数据模型，可以对不同数据集撰写复杂的连接（joins），被所有主流图数据库支持。它的查询方式是画「图模式」：课件的经典示例是查披头士（The Beatles）的专辑——数据里 dbpedia:The_Beatles --foaf:made--> 专辑IRI（MusicBrainz）--dc:title--> 专辑名，图模式里把专辑 IRI 换成变量 ?album、专辑名换成 ?title，匹配结果就得到 “Help!”、“Let It Be”、“Abbey Road”。

本体的价值，是填充知识与查询之间的语义间隙：用户说「老板」，本体知道它可能映射到「董事长」「总经理」「实际控制人」；有了这一层，关键字查询才升级成语义查询。

下面用一个最小可运行示例，把 RDF 建模与 SPARQL 查询落到地上（对应 2.1 节的持股链追溯场景；持股比例用空白节点另行建模，而 OWL 属性链则用直接的对象属性表达，二者是工程中两种常见建模取舍）：

from rdflib import Graph, Namespace

# 行业知识图谱最小示例：企业股权网络（对应「最终控制人追溯」场景）
EX = Namespace("http://example.org/finance/")
g = Graph()
g.bind("ex", EX)

# Turtle 内联数据：持股是一条到「持股关系节点」的边，比例挂在关系节点上
data = """
@prefix ex:  <http://example.org/finance/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ex:张三 ex:持股 [ ex:标的 ex:甲公司 ; ex:比例 "0.70"^^xsd:decimal ] .
ex:甲公司 ex:持股 [ ex:标的 ex:乙公司 ; ex:比例 "0.80"^^xsd:decimal ] .
ex:乙公司 ex:持股 [ ex:标的 ex:丙公司 ; ex:比例 "0.60"^^xsd:decimal ] .
ex:丙公司 ex:行业 ex:新能源 .
ex:李四 ex:任职 ex:甲公司 ; ex:职务 "董事长" .
"""
g.parse(data=data, format="turtle")

# 查询1：一跳直接持股（SPARQL 本质是图模式匹配 + 连接 join）
q1 = """
PREFIX ex: <http://example.org/finance/>
SELECT ?holder ?target ?ratio WHERE {
  ?holder ex:持股 ?h .
  ?h ex:标的 ?target ; ex:比例 ?ratio .
} ORDER BY ?holder
"""
print("== 直接持股 ==")
for r in g.query(q1):
    print(f"{r.holder.split('/')[-1]} -> {r.target.split('/')[-1]}，持股 {r.ratio}")

# 查询2：本例把持股物化为关系节点（?h ex:标的 ?公司），故路径为 (ex:持股/ex:标的)+；
#       若持股直接建模为「公司→公司」对象属性，则等价路径写作 ex:持股+
q2 = """
PREFIX ex: <http://example.org/finance/>
SELECT ?holder ?target WHERE {
  ?holder (ex:持股/ex:标的)+ ?target .
} ORDER BY ?holder ?target
"""
print("== 持股链可达（多跳追溯） ==")
for r in g.query(q2):
    print(f"{r.holder.split('/')[-1]} 控制链可达 {r.target.split('/')[-1]}")

print("三元组总数:", len(g))

运行输出（节选）：张三直接持股甲公司，并沿持股链一路可达乙公司、丙公司；甲公司可达乙、丙；乙公司可达丙——这正是最终控制人追溯的图查询原型。

4.3 套装工具与五种建设方式

业界有两类成熟的企业级套装工具，了解它们的能力边界，比记住操作更重要：

• LOD2：目标是构建结构化链接数据的企业级管理工具和方法学，提供搜索、浏览和生成链接数据的平台，侧重链接数据的生命周期管理；其它类型的数据需要先转换成链接数据才能接入；没有中文处理支持。
• Stardog：企业级知识图谱平台，把数据转换成知识并用图谱组织，对外提供查询、检索、分析服务。主要特点：能把关系数据库映射成虚拟图（数据不必搬家）、支持 OWL2 推理、支持 Gremlin 图遍历；但它只处理结构化数据（RDBMS、Excel 等），既没有非结构化数据的知识抽取，也不包含知识融合功能。

由此，课件总结了行业中使用知识图谱的五种方式，选型取决于数据形态、团队能力与交付时效：

1. 直接使用现有套装工具（如 LOD2、Stardog）；
2. 在现有套装工具基础上进行扩充；
3. 组合使用各生命周期阶段的相应工具；
4. 针对性开发或扩展生命周期中的特定工具；
5. 完全从零开始构建。

行业知识图谱的九大关键技术——知识抽取、知识存储、实体链接、知识建模、语义搜索、图挖掘、知识融合、可视化、知识推理——最终带来三样东西：更加规范的数据表示、更强的数据关联、更深邃的数据价值。

五、领域构建案例：从百科到可用的领域图谱

最后一部分用两个完整案例，把前面的生命周期「走一遍」。领域图谱构建的总框架是：以非结构化的 Web 文本（如 Zhishi.me 汇聚的中文维基、百度百科、互动百科）为原料，经过知识收集（Collection）、开发模块（Development Modules）、链接开放数据（Linking Open Data）、创建链接（Creating Links）、知识融合（Knowledge Fusion）、知识补全（Knowledge Completion）等环节，最终产出领域专用知识图谱（domain-specific KG）。

非结构化Web文本（zhwiki / baidubaike / hudongbaike，经 zhishi.me 汇聚）
        │  知识收集 → 开发模块 → 链接开放数据 → 创建链接
        ▼
   知识融合 → 知识补全
        ▼
   领域知识图谱（domain-specific knowledge graph）

5.1 案例一：佛学领域知识图谱（工程流程案例）

说明：该案例由东南大学认知智能研究所漆桂林教授团队公开，本讲义只把它作为「领域知识图谱如何从零构建」的工程教学案例，关注其数据处理流程与技术方法。

（1）规模与定位。 KG-Buddhism V1.0 是首个中文佛教知识图谱，包含 3,152 个人物类型实体、136,162 条三元组、12 类属性、15 种 Infobox 属性，并与外部开放图谱建立了 1,486 条中文 DBpedia 链接、3,822 条 Zhishi.me 链接，在线数据访问地址为 http://www.kg-buddhism.com 。

（2）知识收集：两种实体发现方法。

• Category 方法：人工观察百科中与目标领域人物相关的分类（在领域子类树中观察），抽取该分类下所有文章对应的实体；
• 命名规则方法：用实体名的构词模式批量发现，例如模式 .+菩萨、.+禅师；此外还包括维基百科「佛教头衔」分类下的所有实体，以及从已抽取出的实体名中挖掘高频公共字符串再反哺扩充。

（3）主语融合（实体对齐）之一：人物。 把每个来源实体的「别名」属性和重定向页收集为别名集合（Alias Sets）；不同来源的两个实体，只要存在一个完全匹配的别名，就认为是同一实体；对于映射到同一实体的来源数多于三个的情况，再安排人工检查。以班禅额尔德尼·确吉坚赞为例，三套别名集被合并到同一个 IRI：

百度百科：{确吉坚赞，班禅额尔德尼·确吉坚赞，罗桑赤烈伦珠}
互动百科：{班禅额尔德尼·确吉坚赞，额尔德尼·确吉坚赞，罗桑赤烈伦珠确吉坚赞}
维基百科：{十世班禅，班禅额尔德尼·确吉坚赞，第十世班禅额尔德尼}
        ▼ 别名集合存在交集（完全匹配别名）
<http://www.kg-Buddhism.com/entity/额尔德尼·确吉坚赞>   # 融合后的唯一实体

（4）主语融合之二：寺庙，两类棘手问题。

• 同名不同实体：百度百科的「龙泉寺」别名集是 {龙泉寺、北京龙泉寺}，而中文维基的「龙泉寺」别名集是 {龙泉寺、南京龙泉寺}——名字相同，显然是两座庙，不能合并；
• 同实体不同名：百度百科「龙泉寺」、互动百科「龙泉禅寺」（别名含北京凤凰岭龙泉寺）、维基百科「龙泉寺_(海淀区)」，三个条目名不同，实则都是北京凤凰岭那座龙泉寺。

解决方案是双条件判定：先看是否存在多个相同别名（而不是只有一个恰好撞名），再看「地址」「建造时间」这类硬核属性是否冲突。例如三祖寺在三个来源中的别名集分别为 {三祖寺，山谷寺}、{三祖寺，山谷寺，乾元禅寺}、{三祖寺，三祖山谷乾元禅寺，山谷寺，乾元禅寺}，地址表述虽各不相同（「安徽省潜山县城西北 9 公里处的谷口凤形山上」「安徽省潜山县天柱山风景区」「安徽省安庆市天柱山南」），但指向同一地点、互不冲突，于是融合为 <http://www.kg-Buddhism.com/entity/三祖寺>。

（5）宾语融合（属性值对齐）。

• 单值属性（一个实体只能有一个值，如出生日期、地址）：冲突时遵循两条原则——精确性原则：日期、地点类属性选择表述最精确的一个；大多数原则：选择在多个来源中出现次数最多的值；
• 多值属性（如弟子、代表作）：直接合并后去重。

（6）谓语融合（模式对齐）。 Infobox 属性侧，保留人工选定的 15 个佛学人物子属性与 9 个佛学寺庙子属性，并人工总结每个属性在现有各知识图谱中存在的谓语形式，做归一映射；其余非核心属性，则直接替换谓语的命名空间（例如把 Zhishi.me 的谓语命名空间统一替换为 kg-Buddhism 自己的命名空间）。

（7）知识补全（Knowledge Completion）。 百科 Infobox 的覆盖率天然不足，补全的做法是：人工编写规则，从非结构化文本中抽取属性值，再依照知识融合方法把「属性—值」对转换为三元组。例如李叔同（弘一法师）词条正文写着「出家后法名演音，号弘一」，用如下模式即可抽出「法名 = 演音」：

文本 Text：李叔同，谱名文涛……出家后法名演音，号弘一，晚号晚晴老人。
模式 Pattern：.*(法名|法号)(为|曰|称|叫|即){0,1}([\S]+?)(字|祖籍|，|。){0,1}.*
属性值对：法名 = 演音
三元组 Triple：
<http://www.kg-buddhism.com/entity/李叔同>
    <http://www.kg-buddhism.com/property/法名>  "演音"@zh .

生卒年这类规整模式则用日期规则抽取，如 ((\d+年)－(\d+)年)。补全的杠杆效应非常明显（拥有该属性的实体数，补全前→补全后）：法名 107→536、弟子 10→615、宗派 126→898、国籍 233→1891、出生日期 394→936、俗名 542→1261。覆盖率统计表里也能看到图谱的构成比例，例如 Labels 3152/3152（每个实体都有标签）、Infobox Properties 覆盖 2632 个实体共 17540 条三元组、Internal Links 2446 个实体共 34887 条、Related Pages 1220 个实体共 45067 条。

（8）在线访问 API。 图谱以 Web 服务方式开放，两种查询方式：查询给定实体的全部知识 …/cnschema/entities/[label]；查询给定实体的特定属性值 …/cnschema/entities/[label]&[property]。返回 JSON-LD 风格的结果，并带标准响应码：

{ "200 成功示例": {"@id": "李叔同", "s:alternateName": "弘一法师", "cns:student": "丰子恺"},
  "404 未找到": {"error": "Entity doesn't exist"},
  "401 未授权": {"error": "You are unauthorized to make this request."} }

（9）上层应用：佛学考试机器人 QA-Buddhism。 它对标的是国际上三个「机器参加考试」项目：日本 Todai Robot Project（2014）、美国 Project Aristo（2015）、中国 863 课题的高考地理考试机器人；佛学院入学考试被认为是更具挑战性的任务。机器人依托 863 国家重点科研项目的高考机器人技术团队，语料包括人物知识图谱与术语知识图谱、11 个类目的佛学词典、3200 条佛学百科知识、14 部佛学教材、上千条高质量问答对、25 部重要佛经的原文—译文对。

题型按两个维度分类：按内容/答案类型分四类——人物类（如「佛陀在世时，印度最忠诚拥护佛法的国王是谁」）、地名类（如「中国佛教四大名山中，观音菩萨的道场是哪座山」）、佛经名类（如「善财童子五十三参出自哪部经典」）、术语类（如「十善业分身、口、意三类，意善业有三是指什么」）；按提问方式分三类——直答类、解释类、列举类，外加选择题特有的句式（如「以下何部经典不是谈般若空性」）。

V1.0 框架的流程是：问题输入 → 预处理 → 从互联网检索并抽取问题证据、提取问题模式 → 模式匹配得到问题类别 → 证据评分 → 候选答案提取、评分、排序 → 输出 TopN 答案及其置信度，并给出支持证据。

V2.0 框架把选择题做成了分类型的流水线，用一道选择题走完全程：「《心经》中的观自在菩萨又称为（）？A 弥勒菩萨 B 地藏菩萨 C 观音菩萨 D 文殊师利菩萨」。

问题 + 四个选项
   │ ① 借助佛学人物词典/书籍词典，做分词、词性分析、命名实体识别（NER）
   ▼
识别出实体与关键词
   │ ② 到知识资源中取证：人物知识图谱、佛学百科、常见问答对、佛学教材
   ▼
得到「知识库三元组」+「含有相关内容的文本」两类证据
   │ ③ 问题分类（不同分类走各自特定的 pipeline）
   ▼
④ 根据证据来源，以及证据对各个选项的支持力度，对选项评分
   ▼
⑤ 按选项得分确定最终答案 ⇒ C. 观音菩萨

在搜集到的 175 道佛教试题上测试，该机器人的准确率为 64%。这个数字的工程含义很清楚：领域问答的准确率同时受图谱补全质量、语料覆盖度和证据评分方法制约，这也是其后续工作（扩充人物实体、改进补全、构建寺庙与术语图谱、构建领域本体；系统收集试题、扩充语料、改进评分、走向对话系统）的由来。

5.2 案例二：农业领域知识图谱与问答

（1）模式知识构建：Taxonomy（分类体系）。 数据源的选择首先要看「结构」而不是「名气」：互动百科和中文维基百科的分类系统里有完整的农业分类分支，而百度百科没有这样的分类体系，因此不选用百度百科做 taxonomy 来源。抓取两个百科的农业分类分支后，邀请多位志愿者对概念之间的 subclass（下位/子类）关系逐条标注正确与否，多数志愿者认为错误的关系就剔除（众包校验），最后把筛选后的两套分类体系合并，得到农业图谱的分类体系。

（2）类别属性抽取：自底向上归纳 schema。 统计某一类别下所有实体出现的属性，如果大部分实体都有该属性，就认为这个类别拥有该属性——例如「农作物」类普遍具有「场地」「修剪时间」属性。具体阈值通过实验确定：某类别下拥有某相同属性的实体数量（或百分比）超过阈值，就把该属性定义到类别概念上。这与专家手工建模互补，是典型的自底向上模式归纳。

（3）主语融合。 规则与佛学案例一致：别名属性 + 重定向构成别名集，存在完全匹配别名即判同，超过三个来源映射到同一实体时人工复核。百香果的融合示例：

百度百科：{百香果、西番莲果、热情果、西番果}
互动百科：{热情果、百香果、西番果、巴西果}
维基百科：{鸡蛋果、洋石榴、紫果西番莲、百香果、藤石榴}
        ▼
<http://www.agriculture.kg/entity/百香果>

（4）Toy Knowledge Base 与系统目标。 结合已有百科知识图谱内容、百科词条与文档，经过人工审核，建立一个小规模的农业知识库（Toy KB）用于事实查询。系统背景是：互联网上海量信息分布在不同信息源、相关性稀疏，传统搜索引擎难以让人快速、准确地获得有价值信息；而问答系统能返回更明确、简练的答案。系统以开放 Web Service API 的方式提供服务，前期采用 pipeline + 模板的方法搭建框架。

（5）问题模板收集：六类文本来源。 百科知识（农业百科、百度百科）；社区问答（知乎、大众养生）；垂直网站（黔农网）；专业问答网站（WikiHow、百度知道、爱问知识人、百度经验）；专业论文网站（中国知网）；书籍、期刊、文献与 APP（搜狗微信，农业通/农管家/农医生等 APP，《广东农业科学》《贵州农业科学》等期刊）。

（6）实体识别：最长子串匹配。 先从知识图谱统计出全部实体集合；把自然语言问句与实体集（辅以图谱中的等价实体）做字符串匹配，得到 mention 集合；若一个子串包含于另一个子串，取最长子串作为识别到的实体 mention；若问句中有多个互不包含的最长子串，就是多个 mention。每个 mention 各自做实体链接，句子中抽掉实体后剩余的部分，视为待映射为谓词的句子模板。例如「阿里山高山茶分布在哪里？」中能匹配到山茶、高山茶、阿里山高山茶三个子串，取最长者：

问句：阿里山高山茶分布在哪里？
匹配子串：山茶 ⊂ 高山茶 ⊂ 阿里山高山茶（取最长）
实体：阿里山高山茶
句子模板：____分布在哪里？        # 「分布在哪里」接下来要映射为谓词

（7）实体链接与消歧：基于 PageRank 的实体关联图。 关联图含四要素：实体指称（mention）节点、候选实体节点、候选节点的顶点值（该候选是目标实体的概率）、候选间的边权值（两个候选实体间的转化概率）。顶点值初始均等，之后每轮更新为上一轮的 PageRank 得分；每轮选当前得分最高的未消歧候选作为最佳实体，删除其它候选及相连的边并更新边权，如此迭代。课件示例：篮球语境下指称「New York」应链接到 New York Knicks（纽约尼克斯队）而非 New York City（纽约市）。

（8）问题分析：五类问题，两条技术路线。

（9）模板方法与 SPARQL 生成。 「有什么/怎么做/是什么/什么时候」这四类问法句式规整，适合模板（template）方法。例如「大白菜怎么种植？」匹配模板 <$蔬菜>怎么种植，实例化为图模式 <$蔬菜> <$p> ?x（「怎么种植」映射为谓词 <$p>）；「胡萝卜什么时候种植？」同理，且答案是日期，要再加一个类型约束。对应 SPARQL（课件原例为示意写法，工程中 type、p 应替换为带前缀的完整 IRI，如 rdf:type 与具体农业谓词）：

# 问：某蔬菜怎么种植？  ?w 绑定蔬菜实体，?x 绑定答案
SELECT ?x WHERE {
  ?w type vegetable .
  ?w p ?x .
}

# 问：某蔬菜什么时候种植？ 再约束答案 ?x 的类型为 date
SELECT ?x WHERE {
  ?w type vegetable .
  ?w p ?x .
  ?x type date .
}

其中点号（Dot）表示合取（conjunction，多个图模式同时成立），?x、?w 是待绑定的变量。需要注意：课件示意里的 ?x type date 是把答案建模为「带类型的资源节点」的 toy 写法；若日期以 "…"^^xsd:date 字面量存储，rdf:type 无法约束字面量，应改用 FILTER(datatype(?x) = xsd:date)（规范写法见本节练习 4）。

（10）候选答案打分：四路召回，归一化排序。

• 模板候选：把实体从问句中抽去，剩余部分（如「____分布在哪里？」）与模板库中的问句模板做编辑距离相似度；
• 谓词—同义词集合候选：剩余部分分词得到 tokens（如「分布、哪里」），与同义词集合（如「分布、哪里、区域、地方」）做 Jaccard 相似度，交集越大越相似；
• 百科词条候选：若是问百科词条类问题（如「白菜是什么」），识别实体后在百科词条库搜相关词条（大白菜、白菜、青菜等），对实体与返回词条做编辑距离相似度；
• FAQ 常用问答对候选：把用户问题与问答对中的问题做字符串相似度。

四路相似度统一归一化，得分最高者作为最终答案返回。

5.3 两个案例的方法论共性

把两个案例并排看，领域图谱构建的「套路」非常清晰，这也是本节最值得带走的工程方法：

1. 知识收集双驱动：分类体系（Category）自上而下圈定范围，命名规则（正则模式）自下而上批量捞取，多百科源互为补充；
2. 融合分三层做：主语融合解决「同一实体多个条目」（别名集 + 硬核属性冲突检测 + 人工复核），谓语融合解决「同一属性多种叫法」（保留核心属性人工归纳、其余替换命名空间），宾语融合解决「同一属性值多种表述」（精确性/大多数原则 + 多值去重）；
3. 补全靠规则杠杆：人工编写正则/规则从非结构化文本补 Infobox，小成本换来属性覆盖率数倍提升；
4. 模式构建上下结合：专家/志愿者标注（taxonomy 众包审核）与统计归纳（类别属性阈值抽取）结合；
5. 应用层 KG+IR 混合：知识图谱保证事实类答案精确可控，文档检索（IR）覆盖长尾与判断类问题；冷启动期用「pipeline + 模板 + 多路打分」是最务实的路线，随着语料与图谱扩充再逐步提高自动化程度。

📝 动手练一练

练习 1（三元组建模 · 反欺诈规则）：请用三元组/三元组模式描述「不一致性验证」：借款人 A、B 填写了同一公司电话 T，但供职公司分别为 X、Y（X≠Y）。写出涉及的三元组，并说明系统判定风险点的条件。

?借款人A ──填写公司电话──> ?电话T
?借款人A ──供职公司─────> ?公司X
?借款人B ──填写公司电话──> ?电话T
?借款人B ──供职公司─────> ?公司Y

练习 2（OWL 建模 · 最终控制人）：最终控制人追溯要沿持股链一直向上走到自然人或国有资产管理部门。请说明：为什么持股关系适合用 OWL 属性链（Property Chain）建模？链条的终止条件是什么？

练习 3（融合判定 · 寺庙对齐）：百度「龙泉寺」别名集 {龙泉寺、北京龙泉寺}、维基「龙泉寺」别名集 {龙泉寺、南京龙泉寺}；而百度「龙泉寺」、互动「龙泉禅寺」、维基「龙泉寺_(海淀区)」经核对都是北京凤凰岭的同一座庙。请说明两类情况的判定流程与区别。

练习 4（SPARQL 图模式 · 农业问答）：仿照课件模板，写出「查询某蔬菜种植时间」的 SPARQL 图模式：变量 ?w 绑定蔬菜实体、?x 绑定答案，并要求答案类型为日期；说明点号与变量的含义。

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ex:  <http://example.org/agri/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?x WHERE {
  ?w rdf:type ex:蔬菜 .            # ?w 是一个蔬菜实体（课件示意写作 type vegetable）
  ?w ex:种植时间 ?x .              # 「什么时候种植」映射为种植时间谓词（课件示意写作 p）
  FILTER(datatype(?x) = xsd:date)  # ?x 是日期字面量时用 datatype 过滤（课件示意写作 ?x type date）
}

练习 5（体系化简答 · 挑战与方案连线）：（1）说出行业知识图谱与通用知识图谱的三个核心区别；（2）把五个数据挑战与对应的知识图谱解法连线。

本章小结

本节先建立了行业知识图谱的概念坐标：它面向特定领域，强调深度、完备性、高准确度与严格丰富的数据模式，与强调广度的通用知识图谱在种子实体与知识回补中双向互补。随后巡览了典型应用——金融证券的企业图谱（风险评估、社交网络、最终控制人、路径发现、融资历程、上市问答）与交易图谱（辅助信贷、两类反欺诈），生物医疗的中医药平台、Watson 与 Open PHACTS，以及图书情报、农业、政府与智能客服。接着我们从 DB→BD 的时代变化出发，拆解了企业全量数据融合的五大挑战及知识图谱的一一对应解法，记住行业里图谱的两大价值：关联与推理。工程主线是六阶段生命周期（建模、获取、融合、存储、计算、应用），底座是 W3C 的 RDF/OWL/SPARQL 标准，套装工具 LOD2、Stardog 各有能力边界，落地有五种建设方式可选。最后，佛学与农业两个领域案例完整演示了「知识收集（Category + 命名规则）→ 三层融合（主语/谓语/宾语）→ 规则补全 → KG+IR 混合问答（实体识别、PageRank 消歧、模板与多路打分）」的全流程，是把通用技术组装成行业系统的最佳范本。

📋 行动清单

• 能用自己的话说清通用知识图谱与行业知识图谱在范围、模式、准确度、使用者四个维度上的区别，并各举两个代表项目
• 能默画行业知识图谱六阶段生命周期环，并说出每个阶段的核心任务与至少一个关键难点
• 能把企业风险评估、最终控制人追溯、最短路径、不一致性验证、组团骗贷五类金融应用分别对应到具体的图结构/图计算问题
• 能复述企业全量数据的五大挑战，并写出每个挑战对应的知识图谱解法
• 能手写 RDF 三元组的 (subject, predicate, object) 结构，说出 Turtle/N-Triples/JSON-LD 等常见语法，并解释 OWL 属性链、复杂类的用途
• 能写出带图模式与类型约束的简单 SPARQL 查询，理解点号（合取）与变量绑定的含义
• 能按「主语融合 / 谓语融合 / 宾语融合」三层拆解一个实体对齐任务，说清别名集、精确性原则、大多数原则、硬核属性冲突检测的用法
• 能讲清领域问答中 KG（事实精确）与 IR（覆盖长尾）的分工，以及模板 + 编辑距离/Jaccard 多路打分的冷启动思路
• 选一个你熟悉的垂直行业，画出它的实体类型、核心关系与数据来源清单，评估用套装工具、组合工具还是从零构建更合适

—— 小象教研组