ARCHITECTURE.md¶
DDA 方法论：各层定义与章节依赖¶
本文件定义《Data-Driven AI：从数据到智能》的方法论骨架。
任何章节在开写前，必须先确认自己属于本文件的哪一层。
层的定义、层与层的关系，以本文件为准。
一、DDA 方法论总览¶
1.1 什么是 DDA¶
DDA = Data-Driven AI。
DDA 是一组以数据为起点的工程判断：AI 系统该围着什么组织。它不是框架，也不是产品。
在创新药研发语境下，DDA 落成 AI 原生科研数据基座：湖仓、目录、本体服务、科学知识图谱、证据索引、上下文接口，外加科学数据闭环。
1.2 DDA 的核心立场¶
数据是中心。
模型、Prompt、Agent 都不是中心。
AI 系统的竞争壁垒来自数据资产与数据闭环，不来自模型本身。
Knowledge ≠ Truth。文档产证据与候选断言；人审后的事实才进知识图。
1.3 DDA 与其他立场的区别¶
| 立场 | 起手点 | 核心资产 | 本书态度 |
|---|---|---|---|
| LLM-Driven | 模型能力 | Prompt | 不写 |
| Prompt-Driven | 提示工程 | Prompt 模板 | 不写 |
| Agent-Driven | Agent 编排 | 工作流 | 仅作为仓外消费方 |
| Data-Driven（本书） | 数据 | Ontology + Scientific Data Loop | 唯一立场 |
1.4 判定规则¶
如果一个章节的论证起点是"某模型能做什么"，它不是 DDA。
如果一个章节的论证起点是"数据长什么样、业务世界如何被机器理解"，它是 DDA。
二、各层定义¶
每一层采用统一格式：
- 定义
- 解决什么问题
- 为什么传统方案失效
- 工程化要点
- 与上下层的关系
2.1 Lakehouse¶
定义¶
让科研数据从「能跑批」变为「能被后续语义层可靠消费」的落湖底座。
解决什么问题¶
文档、表格、实验导出要进入可版本化、可质检、可追溯的数据产品，而不是散落在网盘和邮件里。
为什么传统方案失效¶
传统数仓面向 BI 报表。报表可以容忍 T+1 和口径模糊。入湖若无质检，证据索引会用垃圾切片冒充可引用证据。
工程化要点¶
- 数据契约
- 文档入湖阶段：Detect → Route → Parse → Clean → Standardize → IngestQA → Persist
- Evidence 腿与 Knowledge 腿并行，文档不灌爆本体
- 入湖质检与发版守门分开
- 能力剖面：入湖、抽取、图谱、索引、访问不要绑成一个胖运行时
与上下层的关系¶
上层：Metadata Catalog。
湖仓提供原料与对象；目录回答资产在哪。
2.2 Metadata Catalog¶
定义¶
企业数据上下文：资产身份、归属、血缘与术语锚点。
解决什么问题¶
回答「这张表是什么、这份 ELN 记录对应哪个候选药、谁拥有」。
为什么传统方案失效¶
把公开词表全量灌进目录，目录会变成第二套图谱。关系查询若走目录 SQL，和科学知识图谱抢职责。
工程化要点¶
- 先登记 ELN / LIMS / assay，再深挖同步
- Glossary 只锚企业术语
- 文档 Asset ≠ 知识断言
- 不自建第二套目录产品，也不把目录当图库
与上下层的关系¶
下层：Lakehouse。
上层：Ontology Services。
目录不替代本体，也不替代图。
2.3 Ontology Services¶
定义¶
Ontology 是机器理解企业业务世界的方式。
Ontology Services 把这份理解做成可解析、可映射、可发版的服务：实体、关系、规则、约束、身份级联、公开源 xref。
解决什么问题¶
让 AI 系统拥有一份与人类业务共识对齐的世界模型，并且公开药理空间不覆盖企业主键。
为什么传统方案失效¶
传统数仓的语义散落在表名、字段名、ETL 注释、BI 口径里。公开 ID 若直接当企业主键，合作方代号与内部管线会对不齐。
Ontology 不是什么¶
RDF、OWL、知识图谱、某款图库，都可以是实现。它们不是 Ontology 本身。
工程化要点¶
- 企业主键与公开概念、证据 ID 分层
- 身份级联：企业 ID → xref → 词典 → 模糊对齐 → NER 词典 → unmapped
- 文档不自动 mint 企业实体
- 指标受控词表走本体发版
- 公开源只进公开图 + 精确映射
与上下层的关系¶
下层：Lakehouse、Metadata Catalog。
上层：Scientific KG。
图谱是本体的运行时投影之一，不是本体本身。
2.4 Scientific KG¶
定义¶
已治理的科学知识运行时：身份、已验证关系、PROV、证据挂靠。
解决什么问题¶
把「公司承认的事实」与「模型刚抽出来的句子」分开存放。
为什么传统方案失效¶
把每篇 PDF 变成本体类，图会爆炸且不可治理。把抽取三元组自动写成知识边，幻觉会进入世界模型。
工程化要点¶
- 命名图分工：ontology / knowledge / provenance / biomedical
extracted≠validated；只有后者进 knowledge- 世界模型运行时只认 RDF 图库，不引入属性图双写
- 关系融合要做冲突检测，禁止自动验证
- 发版 QualityGate 看图快照，不看入湖报告
与上下层的关系¶
下层：Ontology Services。
上层：Evidence Index、AI Context APIs。
图回答「谁与谁有何已验证关系」。证据索引回答「原文怎么说」。
2.5 Evidence Index¶
定义¶
证据在哪：语义树切片、混合检索、引用坐标、许可过滤。
解决什么问题¶
让生成与推理在引用企业事实之前，先找到可还原的原文位置。
为什么传统方案失效¶
「向量库加模型」把等长切块当知识。视觉信息被拍平。许可若在检出后再裁，会泄漏无权资产的存在性。
Evidence Index 不是什么¶
这一层是证据基础设施。RAG 是消费它的一种方式。「向量库加模型」只是最小实现，不是本层定义。
工程化要点¶
- 语义树 + 类型化块，反对等长切块
- 词项 ⊕ 向量 ⊕ 图邻接，跨通道只用排名融合
- 查询改写 ≠ 图通道
- 引用优先；无接地不主张
- 许可在候选生成期过滤
与上下层的关系¶
下层：Lakehouse 入湖产物、Ontology 身份。
上层：AI Context APIs。
推理吃 Context Pack，检索吃 Evidence，不要混成一个「什么都搜」。
2.6 AI Context APIs¶
定义¶
把 Ontology、图谱与证据暴露为版本化、可发现、可追责的数据契约。
仓外 Agent 是消费方，不是本层要建造的运行时。
解决什么问题¶
让消费方依赖稳定数据形态，而不是裸湖 SQL、裸 SPARQL 或裸向量 API。
为什么传统方案失效¶
裸 SQL 脆弱。口径漂移。Agent 自造口径无法追责。把编排框架当数据层，会把不可靠语义重新引入末端。
本层不是什么¶
不替代 BI 语义层，也不做 Agent 编排或发现应用。
工程化要点¶
- 四种数据形态：Document / Evidence / Claim / Context Pack
- Context Pack：身份 + 关系 + 证据树 + 许可 +
missing[]+ 本体发版号 extracted默认不进推理包- 缺后端写 missing，不编造
- MCP 只是通道
与上下层的关系¶
下层：Ontology、Scientific KG、Evidence Index、Catalog。
上层：Scientific Data Loop。
消费结果经反馈进入闭环。
2.7 Scientific Data Loop¶
定义¶
研究系统 → 语义基座 → AI 消费 → 科学家审校 → 知识回写 Git → 同步。
Data Loop 不是什么¶
不是新的 ETL，也不是数据管道换个名字，更不是模型再训练。
解决什么问题¶
让 AI 只产候选，人审后才进图。让 Ontology 随业务与反馈受控生长。
为什么传统方案失效¶
传统数据管道是单向的。错误不反馈。文档自动改图会污染世界模型。
工程化要点¶
- 信号来自 unmapped、低置信、零结果、负反馈、多源冲突
- apply 写 Git，不直接写生产图
- 本体版本化、四 W、下游影响评估、历史兼容
- 可观测四支柱把落选候选记下来
与上下层的关系¶
下层：AI Context APIs。
闭环回到 Ontology Services，形成主线回边。
本体演进是闭环的一环，不再单独成章。
2.8 路线选择与适用边界（跨层）¶
定义¶
跨层决策框架：六层加闭环应建到哪一档、哪些层可暂缓、自建与采购如何组合。
解决什么问题¶
企业不能也不应每层都上满。误用全套基座与误用 Text-to-SQL 或 AI 沙箱同样危险。
工程化要点¶
- 按语义传递不可靠与语义时效不可靠分型诊断
- 三档成熟度（轻量 / 标准 / 完整）
- 领域路线：药 / 靶 / 病 → 临床与安全性 claim → 基因 xref
- 不做发现应用、全基因组平台、影像 foundation model
与六层的关系¶
读完 Scientific Data Loop 之后阅读。不替代任何一层的定义。
三、章节依赖关系¶
3.1 主线递进图¶
见 BOOK_CONSTITUTION.md 第三章。
3.2 前置依赖矩阵¶
| 要写的层 | 必读前置层 |
|---|---|
| Lakehouse | 无 |
| Metadata Catalog | Lakehouse |
| Ontology Services | Lakehouse, Metadata Catalog |
| Scientific KG | Ontology Services |
| Evidence Index | Lakehouse, Ontology Services |
| AI Context APIs | Ontology Services, Scientific KG, Evidence Index |
| Scientific Data Loop | AI Context APIs |
| 路线选择与适用边界（跨层） | 全部六层 + 闭环 |
3.3 反向引用规则¶
| 被引用的层 | 可被引用的层 |
|---|---|
| Lakehouse | 所有后续层 |
| Metadata Catalog | Ontology Services 及之后 |
| Ontology Services | Scientific KG 及之后 |
| Scientific KG | Evidence Index 及之后 |
| Evidence Index | AI Context APIs 及之后 |
| AI Context APIs | Scientific Data Loop |
| Scientific Data Loop | 路线选择与适用边界 |
3.4 禁止反向¶
低层章节不得引用高层概念作为自己的设计依据。
Lakehouse 可以提到下游会消费，但不能把 Context Pack 或 Agent 当作本层存在的理由。
四、章节归属判定¶
4.1 新增内容如何归属¶
回答三个问题：
- 它主要解决主线上哪一段的问题？
- 它的主要读者是谁？
- 它的核心论证起点是数据还是模型？
第一个问题的答案，就是它的归属层。
4.2 跨层主题如何拆分¶
- 把"为什么需要"放在最底层归属章节。
- 把"如何被消费"放在更高层章节。
- 不要在多个章节重复定义同一个概念。
4.3 不属于任何层的内容¶
如果一个主题不属于任何一层，它不属于本书。
不要为了"完整性"强行增设章节。
发现应用、Agent 编排、组学平台不属于任何一层。
五、本文件的修订规则¶
新增一层需要：
- 在主线图上明确它的位置。
- 在前置依赖矩阵中追加它的前置。
- 在反向引用规则中追加它的可被引用关系。
- 更新
BOOK_CONSTITUTION.md的主线图。
修订一层的定义需要同步检查：
- 它的所有下游章节是否仍成立。
GLOSSARY.md中相关术语是否仍准确。