4. 结构序列联合表征的数据工程

在药物研发场景中，结构序列联合表征的质量上限，往往不由模型结构决定，而由数据工程决定。一个分子既可能来自公开化合物库，也可能来自内部合成记录；一条蛋白序列既可能来自 UniProt，也可能来自 PDB 或企业内部表达载体。要把这些异构来源组织成可复现的数据集，需要把“采集—清洗—对齐—标准化—缺失值处理—版本管理”当作一条完整的数据流水线来设计，而不是零散地写几个脚本。

多源数据采集：先定义主键与来源边界

采集阶段最关键的不是“抓多少数据”，而是确定每条记录的主键和来源标识。对于小分子，常用主键是标准化后的 InChIKey 或 canonical SMILES；对于蛋白，常用主键是 UniProt AC 或 PDB ID 加链号。采集时应同时保留原始标识、来源库、采集时间、原始文件哈希，便于后续追溯。例如从 ChEMBL 采集活性记录时，至少保留 molecule_chembl_id、canonical_smiles、target_chembl_id、standard_type、standard_value、standard_units、assay_chembl_id 等字段；从 PDB 采集结构时，保留 pdb_id、chain_id、resolution、entity_poly_seq 等字段。采集输出建议统一为“原始层”不可变文件，例如按来源分区的 Parquet 或 JSONL，避免后续清洗直接覆盖原始数据。

清洗：处理重复、异常与单位不一致

清洗要解决三类问题：重复、异常、单位不一致。重复记录常见于同一化合物在不同文献中被多次报道，可用标准化 InChIKey 加靶点 ID 加活性类型去重，并保留最高置信度或最新记录。异常值包括活性值超出合理范围、SMILES 无法解析、序列含非标准残基等。单位不一致则更隐蔽：IC50 可能以 nM、μM、μg/mL 混合出现，必须统一换算为 nM 并记录换算因子。清洗后应输出一份“清洗报告”，记录每条规则命中数量，例如“SMILES 解析失败 37 条、单位换算 1 204 条、重复合并 512 条”，使清洗过程可审计。

对齐：让结构与序列在同一实体上相遇

结构序列联合表征的核心难点是对齐。对齐不是简单拼接，而是确保“同一个实体”的结构与序列指向同一生物学对象。对于蛋白—配体复合物，对齐键通常是 PDB ID + 链号 + 配体化学组分 ID；对于靶点—化合物活性数据，对齐键是 UniProt AC + 标准化配体 ID。若 PDB 中蛋白序列与 UniProt 参考序列存在突变或缺失，应记录序列差异位置，而不是直接丢弃。对齐结果建议以“实体表 + 关系表”的形式存储：实体表描述分子或蛋白，关系表描述“某配体与某靶点在某实验中的活性”。这样后续无论做结构编码还是序列编码，都能通过实体 ID 关联。

标准化：统一表示、统一坐标系、统一语义

标准化包括化学标准化与序列标准化。化学侧建议统一使用 RDKit 进行去盐、去电荷、中和、互变异构规范化，并生成 canonical SMILES 与 InChIKey；序列侧统一大写、去除信号肽或保留并标注、将非标准氨基酸映射为标准残基或标记为未知。对于结构坐标，应明确参照系：若使用 PDB 坐标，保持原始坐标系并记录；若做口袋对齐，则需说明对齐算法与参考结构。标准化后的字段应写入数据字典，例如 smiles_canonical、inchikey、sequence_std、pocket_center，避免同一含义在不同表中使用不同列名。

缺失值处理：区分“缺失”与“不存在”

缺失值处理不能一律填充。应区分三类：真正缺失（如未测活性）、不适用（如共价抑制剂无标准 IC50）、以及采集遗漏。对活性值缺失，可保留为 NaN 并加 missing_reason 字段；对序列缺失，若影响联合表征，应标记为不可用样本而非用零填充。若必须填充，应选择有生物学依据的策略，例如按靶点家族中位数填充活性，并记录填充来源。缺失值处理的目标是让下游模型知道“这里没有信息”，而不是制造虚假信息。

数据版本管理：让数据集可复现

可复现数据集需要版本管理。建议采用“原始层—清洗层—对齐层—特征层”四层目录，每层写入版本号与哈希。每次运行生成一个 dataset_version，记录输入文件哈希、代码提交号、依赖版本、随机种子与输出行数。例如：

dataset_version: v2025.03.1
raw_hash: 9f2c...a1
clean_hash: 3b7d...e4
align_hash: c81a...09
code_commit: 7f3e2d1
rdkit_version: 2024.03.1
random_seed: 42
rows: 128430

这样当模型效果变化时，可以快速判断是数据变化还是模型变化。版本管理不追求复杂工具，关键是“每次输出可追溯、可重建”。

面向药物研发的可复现数据集示例

假设我们要构建一个“激酶—抑制剂”联合表征数据集，用于后续结构编码与序列编码。一个可执行的流程如下：从 ChEMBL 采集 standard_type=IC50 且靶点为激酶家族的记录，保留 canonical_smiles、target_chembl_id、standard_value、standard_units；从 PDB 采集对应激酶结构，保留 pdb_id、chain_id、resolution；用 UniProt AC 将 ChEMBL 靶点与 PDB 序列对齐，若 PDB 序列与 UniProt 参考序列不一致，记录突变位点。清洗时用 RDKit 去盐并生成 InChIKey，活性值统一为 nM，去除 IC50 > 100 000 nM 的弱活性记录。对齐后生成实体表（entity_id、smiles_canonical、inchikey、uniprot_ac、pdb_id、chain_id）和关系表（entity_id、assay_id、ic50_nm、missing_reason）。最后写入 dataset_version=v2025.03.1，并记录行数与哈希。这样得到的数据集，既可用于结构图神经网络，也可用于蛋白语言模型，且每次重建结果一致。

总结来看，结构序列联合表征的数据工程，本质上是把多源异构数据转化为“可对齐、可标准化、可追溯”的实体—关系结构。采集阶段定主键，清洗阶段保质量，对齐阶段建关联，标准化阶段统一语义，缺失值处理阶段保留真实性，版本管理阶段保证可复现。这六个环节共同决定了后续表征学习的上限，也决定了药物研发中数据驱动决策的可信度。