路线选择与适用边界¶
本章所属：跨层（路线选择与适用边界）
阿斯利华的会上三套方案同时出现：产品团队两周内要聊天 Demo；数据平台主张先补契约、身份和证据；采购在评估「买一套本体平台是否能自动长出世界模型」。三个方向都不全错，同时推会得到三套口径。本章不问哪套技术更先进，而问资源有限时，六层加闭环建到哪一档、哪些层可缓、自建和采购怎么拼。
前七章走完从落湖到闭环的完整回路。本章是收束：不必每层上满；选型错了和不上线一样昂贵。
问题¶
为什么不能每层都上满？每一层都是持续投入：契约、本体共建、证据黄金集、审校权责。PoC 阶段就铺完整 Ontology 和全链路闭环，跟误用 Text-to-SQL 或另建 AI 沙箱一样危险。
路线多半落在数据工程师肩上。业务方常默认「上了大模型就能问一切」；采购常默认「买了平台 Ontology 就齐」。你需要一套能拿去辩护的分阶段路径。
传统方案¶
极端一：AI 外挂。复制化合物与试验数据到沙箱，接通用模型，两周出 Demo。传递链在沙箱入口重新断裂。
极端二：采购空心本体。假设买了平台，业务世界会自动出现。湖仓里仍是散落字段名，平台对象没有可靠绑定。
极端三：永久 Text-to-SQL。表少、人复核时能运转；多消费方、监管零幻觉同时出现后，口径不可控。
为什么失效¶
共同根因：没先诊断语义不可靠的类型和严重度，就选了不匹配的路线。
沙箱再造影子产品。采购空心化把平台能力当成数据前提。过早全套基座：在通用医学概念上铺满规则，维护成本压过价值。过早闭环：没有生产流量和审校权责，管道空转，最后被当成又一个 ETL 丢掉。
过晚收契约：仓外系统已经直连裸库，债固化后再收，成本翻倍。
flowchart LR
subgraph wrong [常见误选]
W1[AI沙箱] ~~~ W2[采购空心本体]
W2 ~~~ W3[过早全套]
W3 ~~~ W4[永久TextToSQL]
end
subgraph root [共同根因]
R[未诊断传递vs时效]
end
wrong --> root图：四种误选与共同根因（跨层：路线选择与适用边界）
新的设计思想¶
先诊断，再分档，再选型。
第一步：诊断。
- 传递不可靠为主：多消费方数字对不上、公开 ID 当主键、CSR 与数仓对不齐 → 优先契约、身份、上下文接口。
- 时效不可靠为主：SOP 旧版仍被引用、别名缺新通用名、第三月停滞 → 优先证据版本、闭环、人审写回。
- 两者兼有：先加固传递链最小闭环，再开时效回流。
第二步：三档成熟度。
| 档位 | 包含 | 典型场景 |
|---|---|---|
| 轻量 | 湖仓契约 + 目录 + 人审 Text-to-SQL | PoC、单域分析、核心表很少 |
| 标准 | 轻量 + MVO + 身份级联 + 证据索引 + Context Pack | 单消费方生产、监管问答 |
| 完整 | 标准 + 公开层挂载 + 全链路闭环 + 领域扩展 | 多消费方、业务高频变化 |
第三步：自建、采购或混合。映射能力，不比较厂商谁更聪明。目录、图库、向量库可买；身份纪律、extracted/validated、Data-for-Agent 契约买不来。
架构设计¶
flowchart TB
START[项目启动] --> Q1{主要症状}
Q1 -->|数字对不上| T1[传递不可靠]
Q1 -->|答案过时| T2[时效不可靠]
Q1 -->|两者兼有| T3[先传递后时效]
T1 --> Q2{消费方}
Q2 -->|人复核| L1[轻量]
Q2 -->|机器生产| L2[标准]
T2 --> Q3{有黄金集与审校权责}
Q3 -->|否| L2
Q3 -->|是| L3[完整]
T3 --> L2
L2 --> Q4{要不要发现应用}
Q4 -->|要| STOP[超出本书_另立应用项目]
Q4 -->|不要| KEEP[继续基座]图：先分型，再分档；发现应用不在基座范围（跨层）
工程实践¶
决策表¶
| 决策 | 选择 | 放弃 |
|---|---|---|
| 默认目标 | 多数团队先到标准档 | PoC 强上完整闭环 |
| 本体范围 | 模型稀疏的企业概念 | 均匀铺通用医学 |
| Text-to-SQL | 仅人复核、少表、无多消费方争口径 | 作为生产主契约 |
| 采购 | 买存储与目录产品 | 指望平台自动长出企业世界 |
| 领域 | 药 / 靶 / 病 → 临床与安全性 claim → 基因 xref | 一次铺成组学或影像平台 |
| 应用 | 基座到 Context Pack 为止 | 靶点预测、仓内 Copilot、报告自动生成 |
阿斯利华可走通的例子¶
何时 Ontology 过度。「化合物有分子量」用契约字段即可。「Phase I 是什么」用公开标准引用即可。ASH-001 ↔ savolitinib 必须进本体。Phase I 失败后的内部状态机必须进规则。判定：行业标准加契约能解决的，降为 MVO。
何时 Text-to-SQL 够用。早期分析师查在研清单、人复核、核心表很少、没有「答案必须与报表一致且可引用」。一旦要挂 CSR 段落或对多消费方负责，必须上身份与证据。
何时闭环不划算。PoC 无稳定流量；域季度才变；无人批准本体变更。最小回流：引用评测 + 显式纠错，暂不自动演进审批。
领域路线。现网只把药、靶、病做深。下一期补 IB/CSR 文档型与不良反应 claim，仍是文档与断言，不是替换 CTMS。再下一期把基因 mention 映射到靶点或 HGNC xref，不做全基因组平台。
失败模式¶
- 用发现应用倒逼基座：还没有稳定身份，先上靶点排序模型，两套实体对不齐。
- 买平台替代共建：对象类型有了，别名仍靠猜。
- 标准档没到就上完整闭环：审校队列空转，最后关掉。
- 把阿斯利华写成阿斯利康内部产品路线：读者去学 Research Assistant，而不是学 FAIR 与分层。
自建 vs 采购¶
| 能力 | 自建 | 可采购 | 买不来 |
|---|---|---|---|
| 对象存储 / 表格式湖 / SQL 引擎 | 可以 | 常见 | — |
| 元数据目录 | 不建议自研 | 常见 | 登记纪律 |
| RDF 图库 / 向量索引 | 可以 | 常见 | 命名图与许可纪律 |
| 身份级联与企业主键 | 必须自持规则 | 工具可辅助 | 与业务共建的别名 |
| extracted ≠ validated | 必须自持 | — | 审校组织 |
| Context Pack | 必须自持 | 通道可买 | 缺失声明与版本 |
操作层写回（终止试验同步 ERP）是另一类项目。需要时评估操作本体平台或自建写回，不要把它定义成本书的 Ontology。
最佳实践¶
先诊断再选型。从症状起手，不从 Demo 起手。
标准档是多数团队的务实目标。
采购前先有契约和主键纪律。
MVO 验证后再扩域。一个高价值域跑通，再复制。
闭环从评测与纠错起步。
发现应用另立项。基座不负责变聪明，负责可变厚、可引用、可追责。
延伸阅读¶
- FAOS 与建模预算：把资源投在模型知识稀疏区。
- FAIR 与领域分期：头部药企公开的 Drug / Target / Disease / Clinical / Safety 分层，按基座能力分期，不一次铺成组学平台。
- 成熟度与 RACI：见附录。
Checklist¶
- 是否先诊断了传递 vs 时效，而非从工具起手？
- 是否明确了轻量 / 标准 / 完整，避免 PoC 强上完整闭环？
- Ontology 是否优先覆盖企业特定概念？
- Text-to-SQL 是否仅在人复核场景使用？
- 采购是否只覆盖存储与目录，而未指望平台自动长出世界模型？
- 领域路线是否按药靶病 → 临床安全性 → 基因 xref 分期？
- 是否把发现应用划出基座范围？
资源有限，不能每层上满。从默认全套，改成诊断后分档。能辩护分档，比能画出完整架构图更有用。