本体服务：Ontology Services¶

本章所属 DDA 层：Ontology Services

问题¶

通用大模型的预训练语料里有互联网常识，没有阿斯利华的业务规则。它不知道 ASH-001 和通用名 savolitinib 是同一个药，不知道 c-Met 抑制剂的试验要按 CDISC SDTM 一类标准提交，也不知道「活性化合物」在阿斯利华指通过初筛的候选物。这些共识散在系统里，也散在人脑子里。

前两章给了落湖原料和资产登记。原料自己不会解释该怎么理解。本体服务补这份说明：有哪些实体、实体之间什么关系、遵守什么规则、一段文本怎么落到企业主键。

没有它，下游各自猜口径。有了它，还要守一条边界：公开药理空间提供生物医学世界，企业 Ontology 提供公司的世界。公开 ID 只做映射，不替换企业主键。

传统方案¶

业务语义以前没有单一来源。表名扛实体，字段名扛属性，ETL 注释扛口径，BI 语义层扛指标。

阿斯利华早期就是这样。研发表叫 compound，临床表叫 trial，监管文档叫 submission。同一个化合物三套编号：研发用 ASH-001，临床用 savolitinib，合作方档案用 AZD6094。要问「savolitinib 现在在哪个阶段」，得靠人去三个系统里对齐。

公开库（ChEBI、HGNC、MONDO）常被当成「更权威的主键」。谁先接到哪个源，谁就用那个 ID 当主档。

为什么失效¶

AI 读不到散落的语义。数据进来了，「这个字段、这个编号、这个状态在业务上是什么意思」却没有一份机器可读的答案。

同一个「活性化合物」，研发、临床、BI 各定义一遍。机器不知道该信哪一个。

企业规则也进不了机器。「Phase I 失败则化合物状态转为 suspended」写在流程文档里，不在任何数据系统里。

主键选错更麻烦。用公开 ID 当企业主键，合作方代号、内部管线号、尚未公开的候选物会对不齐。文档若再自动 mint 新实体，世界模型会按 PDF 增长速度膨胀，没法发版。

flowchart LR
    subgraph 散落语义
        T[表名] ~~~ F[字段名]
        F ~~~ E[ETL注释]
        E ~~~ P[公开ID当主键]
    end
    CON[仓外消费] -.读不到统一含义.-> 散落语义
    ONT[OntologyServices] -->|企业主键加xref| CON

图：散落语义与本体服务单一来源的对比（DDA 层：Ontology Services）

新的设计思想¶

机器理解企业世界，不能靠模型猜，得显式定义。Ontology 定义四样东西：实体、关系、规则、约束。

Ontology 不是知识图谱，也不是 RDF、OWL 或某家图库的产品特性。那些可以是实现。Ontology 回答「机器如何理解业务世界」；图谱是其中一种运行时投影。

本体服务还要提供身份级联：一段文本如何落到 ASH:ENT:*。公开源经精确映射挂上，不接管主键。

文档不自动创造企业实体。挂不上就进入闭环信号，等人决定要不要在 Git 里新增概念。

建模预算不要均匀铺。优先覆盖模型不熟悉的内部代号、企业状态机、跨系统对齐，别重复「Phase I 是什么」这类通用医学知识。

架构设计¶

flowchart TB
    TXT[文本或别名] --> ID[身份级联]
    ID --> ENT[ASH_ENT企业主键]
    PUB[公开源] --> XREF[精确映射]
    XREF --> ENT
    ENT --> RULE[规则与约束]
    ENT --> BIND[绑定湖仓资产]
    DOC[文档] -.不mint.-> ENT

图：企业主键居中，公开层只 xref，文档不自动造实体（DDA 层：Ontology Services）

三层 ID 必须分开：企业主键、公开概念 ID、证据 ID。检索、图谱、目录、上下文接口对外优先用企业主键。

工程实践¶

决策表¶

决策	选择	放弃
主键	`ASH:ENT:*`	用 UMLS / ChEBI / BIOS ID 当企业主键
公开源	进公开层 + 精确映射	把公开层写成企业本体
文档	挂已有实体，失败则 unmapped	读 PDF 自动 mint 概念
身份	单一入口，词典只装配一次	检索一套词典、解析另一套
指标口径	受控词表随本体发版	抽取器私写「ORR」
建模预算	内部代号与企业规则优先	均匀铺满通用医学

阿斯利华可走通的例子¶

化合物实体用 YAML 声明，重点处理别名与分层 ID：

entity: DrugCandidate
enterprise_id: ASH:ENT:DC:savolitinib
research_code: ASH-001
preferred_label: savolitinib
status_values: [discovery, preclinical, phase1, phase2, phase3, marketed, withdrawn]
aliases:
  - {type: research_code, value: ASH-001}
  - {type: generic_name, value: savolitinib}
  - {type: partner_code, value: AZD6094}
xrefs:
  - {system: ChEBI, value: CHEBI:XXXXX, match: exact}
  - {system: ChEMBL, value: CHEMBL2108683, match: exact}
relations:
  - {type: has_target, target: ASH:ENT:TG:met}
metric_vocab:
  - {code: ORR, definition: 客观缓解率，口径随 ontology_release_id}

身份级联按阶段收紧，不要「模型猜一个最近的」：

文本
  → 已是企业 ID？
  → 公开 xref 能唯一落到企业 ID？
  → 词典别名（带 scope）？
  → 模糊对齐（可阻断）？
  → NER 词典回退？
  → unmapped（进入闭环信号，不编造）

ASH-001、savolitinib、AZD6094 必须落到同一 ASH:ENT:DC:savolitinib。问「HMPL-504」若目录没有对应实体，结果是 unmapped，而不是自动新建一个候选药节点。

「在研」是否包含 preclinical，写在本体与指标词表里，随发版号变更。抽取器不得在提示词里另写一份 ORR 定义。

失败模式¶

检索用目录别名命中 A，解析用另一份词典命中 B：消费方无法追责。
文档自动 mint ASH:ENT:*：发版无法审，图随 PDF 增长。
公开 CUI 当主键：内部未公开候选物没有合法身份。
别名无 scope：基因符号与疾病缩写撞车时静默选错。
不确定时猜 top-1：监管场景不可接受；应保留 alternatives 或 abstain。

业界路线对照¶

Open PHACTS 把身份解析和身份映射做成独立服务，公开药理空间经 Core API 对外，应用不直连各源。阿斯利康公开材料强调受控词表和持久标识要嵌进数据产品。身份服务是本体层的工程入口；公开层是挂载，不是企业世界。

商业操作本体平台（对象、链接、可写回的 Action）能覆盖「终止试验并同步 ERP」一类运营动作。那是操作层，不是科学语义基座。阿斯利华若只需查询理解与证据挂靠，描述层加身份级联就够，不必把写回源系统当成 Ontology 的定义。

最小可行本体（MVO）可以只做化合物别名、试验状态枚举和一两条可校验规则。分档见第 8 章。

最佳实践¶

Ontology 即产品：有负责人、版本、消费者、衰减监控。

优先覆盖模型知识稀疏区：内部代号、企业状态机、跨系统对齐。

绑定真实资产。每个实体能指回湖仓或目录里的对象，否则是悬空概念。

标准编码优先作 xref，不作主键。

规则可程序校验。约束语言是一种实现选择，不是 Ontology 本身。

文档不 mint。新概念走 Git 与发版。

延伸阅读¶

本体工程：知识表示基础；企业本体与操作本体的职责差异。
公开药理空间：Open PHACTS 身份解析、映射与 Core API。
FAIR 与持久标识：头部药企将 GUPRI / 受控词表嵌入数据产品的公开讨论。
行业编码：UMLS、RxNorm、CDISC、MeSH、ChEBI、HGNC、MONDO 各自覆盖不同维度，组合做映射，不组合当主键。

Checklist¶

是否显式定义了核心实体、关系、规则、约束？
企业主键与公开 ID、证据 ID 是否分层，公开层是否只 xref？
身份是否经单一入口级联，词典是否只装配一次？
文档是否禁止自动 mint 企业实体？
指标口径是否进受控词表并随本体发版？
建模是否优先覆盖内部代号与企业规则，而非通用医学常识？
实体是否绑定到湖仓或目录中的真实资产？

散落语义收拢为企业主键加 xref。文档不再发明概念。机器理解企业业务，靠这份定义，不靠猜测。