📚 课程目录第2章分子数据基础

2. 分子数据基础

在药物研发数据整合工程中，分子数据是最基础也最容易出问题的一类数据。同一个化合物，在采购目录里可能写作 CC(=O)Oc1ccccc1C(=O)O，在内部登记系统里是 InChI，在对接软件里是 MOL 文件，在机器学习特征表里又变成一串 2048 位的 0/1 指纹。如果这些表示之间没有统一的转换与校验规则，后续的活性预测、相似性搜索、结构聚类都会建立在错误的对齐关系上。本节围绕“一个分子如何被机器准确表达”展开，讲清 SMILES、InChI、MOL 三类格式的定位，以及分子指纹和描述符在其中的角色。

一、三类结构格式的分工

SMILES 是线性字符串表示，用原子符号、键符号和括号描述连接关系，例如阿司匹林的 SMILES 为 CC(=O)Oc1ccccc1C(=O)O。它的优点是紧凑、易写入数据库字段、便于做子结构匹配；缺点是同一分子可以有多种合法写法（如 O=C(O)c1ccccc1 与 OC(=O)c1ccccc1），因此必须经过规范化（canonicalization）才能作为唯一键使用。工程上通常要求存储“规范化 SMILES”，并保留原始输入 SMILES 作为溯源字段。

InChI 是由 IUPAC 推动的标准表示，设计目标是跨数据库唯一、可分层解析。它由若干层组成，例如 InChI=1S/C9H8O4/c1-6(10)13-8-5-3-2-4-7(8)9(11)12/h2-5H,1H3,(H,11,12)，其中 1S 表示标准 InChI，后续层分别描述化学式、连接、氢原子、电荷、立体化学等。InChI 的优势是标准化程度高，适合做跨库去重；代价是字符串长、生成依赖软件版本，且对互变异构、盐型、立体层的处理需要明确配置。

MOL 文件（MDL Molfile）是二维或三维坐标加连接表的格式，包含原子块、键块和属性块，常见于 ChemDraw、OpenBabel、RDKit 等工具之间交换。它保留坐标和手性标记，适合做结构可视化、构象输入和反应物记录，但不适合直接作为数据库主键，因为同一分子在不同软件导出的 MOL 文本可能不同。

二、分子指纹：把结构变成可比较的位向量

分子指纹是把结构编码为固定长度位串的方法，最常用的是 Morgan 指纹（又称圆形指纹）。其生成过程是：以每个原子为中心，按设定半径向外扩展，把每一层邻域的子结构哈希到固定区间，置位对应比特。例如半径 2、2048 位的 Morgan 指纹，能同时捕捉原子类型、连接方式、环环境和部分官能团信息。两个分子的相似度通常用 Tanimoto 系数衡量：交集位数除以并集位数，取值 0 到 1，越接近 1 越相似。

工程上必须固定指纹参数并写入元数据，因为半径从 2 改为 3、位数从 2048 改为 1024，都会改变相似度排序。若同一项目内混用不同参数，聚类结果将不可比。常见做法是：在特征表旁维护一张 fingerprint_config 表，记录 fp_type、radius、n_bits、use_features、generator_version，任何模型训练前先校验配置一致。

三、描述符：可解释的数值特征

描述符是直接从结构计算出的数值，如分子量（MW）、脂水分配系数（LogP）、拓扑极性表面积（TPSA）、氢键供体数（HBD）、氢键受体数（HBA）、可旋转键数（RotB）等。它们与指纹互补：指纹擅长相似性搜索，描述符擅长构建可解释的定量模型和类药性过滤。例如 Lipinski 五规则常用 MW ≤ 500、LogP ≤ 5、HBD ≤ 5、HBA ≤ 10 作为初筛条件。需要注意，不同工具计算的 LogP 实现不同（如 Crippen 法与 XLogP），同一分子可能相差 0.3 至 0.8，因此描述符也必须记录计算工具与版本。

四、标准化流程与可执行示例

下面给出一段基于 RDKit 的标准化示例，输入为原始 SMILES，输出为规范化 SMILES、标准 InChI、InChIKey 及关键描述符。示例参数为教学假设，实际项目需按内部规则调整。

from rdkit import Chem
from rdkit.Chem import Descriptors, inchi

raw = "CC(=O)Oc1ccccc1C(=O)O"          # 阿司匹林原始 SMILES
mol = Chem.MolFromSmiles(raw)
if mol is None:
    raise ValueError("SMILES 解析失败")

# 去盐：保留最大片段
frags = Chem.GetMolFrags(mol, asMols=True)
parent = max(frags, key=lambda m: m.GetNumAtoms())

canonical = Chem.MolToSmiles(parent, isomericSmiles=True)
std_inchi = inchi.MolToInchi(parent)
inchikey  = inchi.InchiToInchiKey(std_inchi)

print("canonical_smiles:", canonical)
print("standard_inchi  :", std_inchi)
print("inchikey        :", inchikey)
print("MW   :", round(Descriptors.MolWt(parent), 2))
print("LogP :", round(Descriptors.MolLogP(parent), 2))
print("TPSA :", round(Descriptors.TPSA(parent), 2))
print("HBD  :", Descriptors.NumHDonors(parent))
print("HBA  :", Descriptors.NumHAcceptors(parent))

运行后应得到规范化 SMILES、以 InChI=1S/ 开头的标准 InChI，以及 27 位 InChIKey（形如 BSYNRYMUTXBXSQ-UHFFFAOYSA-N，前 14 位对应连接层哈希，后段对应其余层）。若同一分子从不同来源解析出的 InChIKey 不一致，说明盐型、电荷或立体层未对齐，需要回到标准化规则排查，而不是直接覆盖数据。

建议在数据入库时同时保存：原始 SMILES、规范化 SMILES、标准 InChI、InChIKey、MOL 文本、指纹配置、描述符计算工具版本。这七类字段构成分子记录的完整溯源链，后续任何模型或检索结果都能回溯到具体表示。

不要把 InChIKey 当作绝对唯一键。InChIKey 对互变异构、部分立体化学差异不敏感，不同分子可能共享同一 InChIKey 前段；去重时应结合标准 InChI 全文与项目自定义规则，避免误合并。

五、常见问题与判断依据

实际整合中最常见的问题有三类。第一类是“同物异码”：同一化合物因盐型、水合物或互变异构写法不同，被登记为多条记录。判断方法是比较标准 InChI 的连接层与氢层，若仅电荷层或立体层不同，则按项目规则决定是否合并。第二类是“异物同码”：不同分子因指纹碰撞或 InChIKey 前段相同被误判为同一物，需用标准 InChI 全文复核。第三类是“参数漂移”：指纹半径或描述符工具版本变化导致特征不可比，需通过元数据校验拦截。

把这三类问题控制在入库阶段，比在建模阶段补救成本低得多。分子数据基础做扎实，后续的活性数据关联、相似性搜索和机器学习建模才有可靠起点。