跳转至

前言

本章所属：跨层

本书写给做了五到十五年数据工程的人。SQL、ETL、数仓、湖仓、Spark、Flink、Airflow、治理、元数据、血缘，默认你会，后文不再讲。

那还写一本给数据工程师看的 AI 书，图什么？

过去十年，数仓和看板的消费方是人。人能忍 T+1，口径糊了可以打电话，字段名也能猜个八成。机器不会猜。它要可读的语义、稳定的契约、能指回原文的出处。消费方一换，设计前提就换了。

所以这是思维怎么转，不是再学一个框架。视角从「数据服务人」转到「数据服务机器」，重新想企业数据怎么组织。

这个判断不是从模型能力推出来的。头部药企公开谈科研数据时，反复出现同一组层：湖仓、元数据目录、科学知识图谱、证据索引、本体服务、给 AI 的上下文接口。阿斯利康把 FAIR 和受控词表写进数据产品；Open PHACTS 把公开药理空间做成身份解析、映射和 Core API，应用坐在 API 上面。本书学栈怎么切，不学他们的发现产品或仓内助手。

多数企业这套治理还没建起来。以前质量问题藏在报表脚注里，现在直接出现在答案里。全书案例是虚构药企阿斯利华（Asliva）。它不是阿斯利康。真公司只出现在对照段落。

AI-ready：把数据做成产品，别另挖沙箱

企业谈 AI-ready，常见两条岔路。一条是另起一套 AI 数仓，跟现网并行。另一条是先吵选哪个模型和向量库。本书不走这两条。AI-ready 是把数据产品的标准加码，在创新药语境里叫 AI 原生科研数据基座（AI-Ready Scientific Data Foundation）。

Data Mesh 早就说数据要有负责人、契约、SLA 和明确消费者。现在消费者多了仓外 Agent 和检索系统，交付也不能只剩「表加字段名」。全书六层可以看成产品往上叠：湖仓定单元，目录登记资产，Ontology 定语义，图谱存已验证事实，证据索引管原文，上下文接口对外交货。

后面各章会反复用到四条：

  1. 公开层提供生物医学世界，企业 Ontology 提供公司的世界。公开 ID 只做映射。
  2. Knowledge ≠ Truth。文档产出证据和候选断言；人审过的事实才进知识图。
  3. 仓外消费方只用四种形态：Document、Evidence、Claim、Context Pack。
  4. 闭环要的是知识层变厚，不是模型权重更新。

全书要对付什么

做分布式系统的人，默认时钟和网络不可靠。DDA（Data-Driven AI）用同一套习惯看业务语义：它也不可靠。多半不是模型笨，也不是向量库小。企业里往往没有一份机器可读、能追责的业务共识。

两件事会反复出现。

语义传递不可靠。含义散在表名、字段、ETL 注释、BI 口径、文档库里。数据还在，意思对不上，或者根本传不到。湖仓契约、Ontology、图与证据分工、引用和推理包，都在补这一段。

语义时效不可靠。新化合物、新通用名、SOP 换版、试验规则改了，定义没跟上。当时没错，过一阵就过时。Scientific Data Loop 主要管这个。

读每一章可以问：这一层在补传递，还是在补时效？交出去的是产品栈里哪一块？

本书写给谁

数据工程师、数据平台工程师、数据架构师、分析工程师、技术负责人。经验按五到十五年估。

如果你在想数据平台下一步怎么走、数据团队在 AI 项目里到底管什么、为什么要本体和证据分层，后文就是为这些问题写的。

本书不写什么

  • ChatGPT、Prompt、模型 API 教程。
  • 工具说明书。正文围着 Ontology、Scientific KG、Evidence、Data-for-Agent、Scientific Data Loop 转。对象存储、Iceberg、RDF 图库、向量索引、MCP 只在工程实践里当例子，并标明只是一种实现。
  • 模型排行榜。
  • 发现应用：靶点预测、图神经网络、假设生成、自动写报告、仓内 Copilot。
  • Agent 编排。仓外 Agent 是买方，本书卖的是它能依赖的数据契约。
  • 换行业讲故事。案例始终是创新药，公司始终是阿斯利华。
  • 某个实现仓库的源码、包名、命令行。

如何阅读本书

按主线读：

flowchart LR
    A[传统数据平台] --> B[Lakehouse]
    B --> C[MetadataCatalog]
    C --> D[OntologyServices]
    D --> E[ScientificKG]
    E --> F[EvidenceIndex]
    F --> G[AIContextAPIs]
    G --> H[ScientificDataLoop]
    H -.循环.-> D

图：全书主线

先让科研数据落湖并登记资产，再定义 Ontology，把企业世界和公开药理空间分开。科学知识图谱只存已验证事实。证据索引回答原文怎么说。上下文接口把四种数据形态交给仓外。闭环里科学家审过的知识写回 Git，再回到 Ontology。

Ontology 管机器怎么理解企业世界。Scientific Data Loop 管知识层怎么变厚。其余各层是支撑。

每章结构一样：问题、传统方案、为什么失效、新的设计思想、架构设计、工程实践、最佳实践、Checklist。工程实践里会有决策表、阿斯利华能走通的例子、以及常见翻车。先讲为什么，再讲怎么做。

六层和闭环读完，看第 8 章。人月和分工见附录。

一个提醒

数据在中间，模型不在。某一章如果从「模型能做什么」起笔，或者架构图把 LLM 画在中心，就偏了。这不是轻视模型。数据工程师能留下的，多半是语义怎么被驯服成可交付的产品。

延伸阅读

  • Dehghani《Data Mesh》，数据作为产品。
  • Open PHACTS：身份解析、映射服务、Core API。
  • 阿斯利康等头部药企关于 FAIR、持久标识、受控词表的公开讨论。学栈，不学发现应用。