3. 实验数据基础

药物研发中的数据整合，第一步不是写代码，而是把“数据长什么样”这件事说清楚。生物活性、ADMET、毒理和药代四类实验数据，虽然都服务于“判断一个分子能不能成为药”，但它们的测量对象、量纲、实验条件、时间结构和不确定性来源差异极大。如果把它们都当成一张“分子—数值”表来处理，后续的建模、比较和决策就会在源头失真。

四类数据的本质差异

生物活性数据回答的是“分子与靶点相互作用有多强”。常见终点包括 IC50、EC50、Ki、Kd，单位通常是 nM 或 μM。它高度依赖实验体系：同一化合物对同一靶点，在不同细胞系、不同底物浓度、不同孵育时间下，数值可能相差数倍。因此活性数据的最小完整单元不是“分子+数值”，而是“分子+靶点+实验体系+终点类型+数值+单位+不确定度”。

ADMET 数据覆盖吸收、分布、代谢、排泄和毒性倾向，常见终点有 Caco-2 渗透性、血浆蛋白结合率、肝微粒体清除率、CYP450 抑制率、hERG 抑制等。它的特点是终点离散、量纲不统一，且很多是体外替代指标，与体内行为之间是相关性而非等价关系。ADMET 数据必须携带实验模型来源，例如“人肝微粒体+NADPH 再生系统”，否则清除率数值无法解释。

毒理数据关注安全性，典型形式包括 NOAEL、LOAEL、LD50、Ames 试验结果、染色体畸变结果等。毒理数据往往带有明显的分级和判定语义，例如“阳性/阴性”“观察到/未观察到”，并且与给药途径、剂量、种属、暴露时长强绑定。把毒理数据简化为一个连续数值，会丢失关键的判定逻辑。

药代数据描述药物在体内的时程变化，核心是浓度—时间曲线，派生参数包括 Cmax、Tmax、AUC、t1/2、CL、Vd。药代数据天然是时间序列，且受给药方式（静脉、口服）、剂量、采样时间点、生物基质（血浆、全血、组织）影响。药代数据的格式必须能表达“时间点—浓度—个体—给药事件”的结构。

格式选择：从表格到结构化记录

在实操层面，四类数据最常见的载体是 CSV/Excel、JSON 和关系型数据库表。CSV 适合扁平、同质的活性数据，但难以表达药代的时间序列和毒理的多级判定。JSON 能嵌套表达“一个实验包含多个时间点、多个重复”，适合作为交换格式。关系型数据库则适合长期积累和跨实验查询，通常需要“化合物表—实验表—测量表—元数据表”的分层设计。

一个常见的错误是把所有终点塞进同一张宽表，列名如“IC50”“Caco2”“NOAEL”“AUC”并列。这样做在数据量小时看似方便，但一旦需要按靶点筛选活性、按种属筛选毒理，就会陷入大量空值和语义混淆。更稳妥的做法是按“测量记录”组织：每条记录包含化合物 ID、实验类型、终点名称、数值、单位、条件摘要和溯源 ID。

元数据标准：让数据可被机器理解

元数据不是“附加说明”，而是数据能否被正确使用的先决条件。对于生物活性，推荐对齐 ChEMBL 的字段习惯，至少保留 target_chembl_id、assay_type、standard_type、standard_value、standard_units、pchembl_value。对于 ADMET，可参考 PubChem BioAssay 的 assay 描述结构，明确 assay format 和 detection method。毒理数据可参考 OECD 测试指南编号和 GLP 报告结构。药代数据则建议采用 CDISC SDTM 中 PC（药代浓度）域的思路，保留 USUBJID、PCTEST、PCORRES、PCSTRESN、PCTPT 等字段语义。

一个可落地的记录示例

假设某实验室测得一化合物对 EGFR 的抑制活性，同时做了肝微粒体清除率和 hERG 抑制。可以按如下 JSON 结构组织，既保留各自特异性，又共享公共锚点：

{
  "compound_id": "CMPD-0042",
  "inchikey": "ABCXYZ...",
  "assays": [
    {
      "type": "bioactivity",
      "target": "EGFR (P00533)",
      "endpoint": "IC50",
      "value": 12.5,
      "unit": "nM",
      "system": "enzyme assay, 4PL fit",
      "n_replicates": 3,
      "source_file": "egfr_run_2024-03-11.csv"
    },
    {
      "type": "admet",
      "endpoint": "microsomal clearance",
      "value": 28.0,
      "unit": "mL/min/kg",
      "species": "human",
      "system": "HLM + NADPH",
      "source_file": "hlm_clearance_batch7.xlsx"
    },
    {
      "type": "tox",
      "endpoint": "hERG inhibition",
      "value": 45,
      "unit": "% inhibition @ 10 uM",
      "judgement": "moderate risk",
      "source_file": "herg_screen_2024-03-15.csv"
    }
  ]
}

这个结构的关键在于：每个 assay 块内部保留自己的专业字段，而 compound_id 和 inchikey 作为跨实验的连接键。后续无论做活性预测、ADMET 过滤还是毒理预警，都可以从同一份记录中抽取对应子集，而不需要反复人工对齐列名。

数据质量检查的优先顺序

在整合前，建议按以下顺序检查：第一，化合物标识是否唯一且可解析，SMILES 是否能被 RDKit 正确读入；第二，单位是否统一，nM 与 μM 是否已换算，% inhibition 是否标注了测试浓度；第三，实验条件是否足以复现，至少包含体系、种属、时间、温度中的关键项；第四，数值是否带有不确定度或重复次数；第五，溯源文件是否可访问且版本明确。这五项检查通过后，数据才具备进入整合管线的资格。

四类数据的整合难点，不在于把它们放在一起，而在于保留各自的语义边界。生物活性的“强”与毒理的“安全”不是同一种量纲，药代的“暴露量”也不能直接换算成活性。元数据标准的作用，正是让这些差异被显式记录，而不是在合并时被悄悄抹平。