1. 药化和药理为什么总是“两张皮”做创新药研发的朋友应该都有同感药化团队和药理团队明明在同一个项目里却常常像两个星球的人。药化同事天天盯着SMILES式、合成路线、溶解度嘴里念叨的是PlogP和合成可及性药理同事则守着酶活实验、细胞实验和动物PK数据整天讨论的是IC50、暴露量和剂量换算。两边各说各话项目推进往往卡在“化合物明明活性很好怎么动物实验就是不行”或者“药理反馈了一堆数据药化却不知道下一步该改哪里”这种尴尬局面上。这些年大家都在提“数智融合”尤其是药物研发领域这个话题已经从概念炒作阶段进入到了必须落地实操的阶段。但真要把药化和药理这两个学科的数据、逻辑、决策链路融在一起绝不是简单买套软件、上个数据库、跑几个深度学习模型就能解决的。我在项目里踩了很多坑之后才慢慢摸清所谓“真正融合”的门道——它本质上不是技术问题而是数据和机制的双重“翻译”问题。1.1 两种思维方式两套数据语言先说个最直观的矛盾。药化学科的底层逻辑是“结构决定性质”一个分子好不好先看结构能不能合成、稳不稳定、有没有专利风险药理学则更关注“剂量决定效应”一个分子活不活要看在什么浓度下产生什么反应、作用持续时间多长。这两套逻辑天然存在时间尺度的错配药化看的是毫秒级的分子构象和微摩尔级的结合能力药理看的是小时级的代谢过程和天级的体内分布。数据语言也不统一。药化留下的数据往往是化合物结构式的集合字段可能是“批号”“纯度”“MS/ NMR结果”药理生成的数据则是一堆实验曲线和统计学参数字段是“实验ID”“批次”“测定方法”“重复次数”。两边没有统一的“主键”化合物结构式和活性数据之间根本没有系统性的映射关系。我见过最典型的情况是同一批化合物药理结果在Excel里找得到但对应到结构式时要靠人工对照编号一不留神就会串号。这样的数据语言指望AI“自己学会”是不现实的。模型再强喂进去的也是两堆无法对齐的碎片信息。所以做数智融合第一步必须像建“巴别塔”一样先统一语言。不是让药化去学统计学也不是让药理去学合成化学而是让两边的数据先在同一个标准下可计算、可比较、可追溯。这一步是融合的真正基石也是绝大多数项目容易忽略的地方。1.2 融合的真正难点在于时间尺度与评价标准不一致第二个难点比数据格式更隐蔽就是两边的评价标准和时间节奏完全不在一个维度上。药化的周期以周计一个化合物从设计到合成出来顺利的话一两个星期药理的评价周期却受限于实验排期一个完整的数据反馈往往要一个月甚至更久。这就导致药化常常在没等到药理反馈的时候就基于“经验感觉”迭代了一轮等到药理数据终于出来药化已经多合成了好几个类似的分子。这种脱节不是认不认真做事的问题而是两个学科本身的生物钟不一样。评价标准也不一致。药化觉得“溶解度7 μg/mL已经很好了”药理却觉得“这个溶解度做成口服制剂根本不行”。药化觉得“选择性体外数据差3倍可以接受”药理却会告诉你“这个比值在体内基本等于没有选择性”。这些评价冲突靠人开会能解决一部分但长期看必须把标准沉淀成可执行的规则和模型。比如把“可成药性评价”固化成一套包含活性、选择性、渗透性、代谢稳定性、溶解度等多个维度的评分体系让药化和药理在同一个尺度上讨论问题。所以真正的“数智融合”在我看来就是让两个学科的数据流、知识流和决策流在统一框架里协同起来。它可以不完美但必须让每一步迭代都有据可查、有理可依。这个思想打通了后面所有技术手段才有意义。2. 数智融合不是喊口号三个关键落地层次理解了矛盾在哪再来看融合具体该落在哪里。我习惯把药化-药理的数智融合分成三个层次数据层、模型层和决策层。很多项目做不下去是因为一上来就奔着模型层去忽略了数据层的基础也有项目堆了一堆数据和模型却在决策层完全断档AI变成了“花瓶”。2.1 数据层让分子与活性数据真正“对齐”数据层是一切融合的底座。核心工作就两件事一是把药化的分子结构标准化二是把药理的活性数据归一化并且让两者在同一个“化合物ID”下关联起来。分子结构标准化的坑很多。同一个分子有人用SMILES时带盐有人不带盐有人保留了立体化学信息有人直接把三维结构存成MOL2文件。这些细节如果不统一后续计算描述符、指纹、分子相似度时都会出错。我常用的方案是统一用RDKit对SMILES做标准化清洗去盐、中和、优选规范SMILES把立体信息单独保存这样既保留化学准确性又让计算可重现。药理活性数据归一化更关键。不同实验室、不同批次的IC50值差异可以大到几倍直接拿原始值建模型噪声会淹没信号。实操中我习惯把IC50换算成pIC50负对数因为它近似正态分布更符合统计建模的假设也方便后续做回归任务。同时二值化的“活性/无活性”标签不能随便设阈值要根据不同靶点的历史数据和实验窗口来定。数据清洗规范看起来琐碎但决定了后面模型的上限。2.2 模型层从“预测活不活”到“解释为什么活”数据通了之后才轮到模型层。这一层的主要任务是用机器学习方法建立化合物结构到药理活性之间的可解释模型。初期不要一上来就上大模型。分子集就几百个化合物深度学习图网络很可能过拟合。我常用的组合是用分子指纹如ECFP4或RDKit描述符作为特征训练随机森林、XGBoost或SVM效果稳定且可解释。如果数据量超过几千个再考虑图神经网络或预训练分子模型这时候深度学习的优势才体现得出来。真正让模型层“智能”的不只是预测精度而是可解释性。我在项目里用SHAP值来分析特征贡献让药化同事可以直观看到“苯环上哪个位置取代对活性影响最大”“哪个官能团对代谢稳定性的贡献是负数”。当模型能回答“为什么”时药化团队才愿意真正把它当成设计工具。模型预测活不活只是结果解释为什么才能产生知识而知识才能积累成团队的决策资产。2.3 决策层多目标联合优化让AI能当“军师”数据通了、模型建了最终还要落到决策层。传统流程里药化设计完一批化合物送药理去筛活性好的再回头改结构相当于一轮一轮“试错”。“数智融合”的决策层要做出改变设计之初就把药理的约束条件放进来做多目标联合优化。多目标联合优化的典型场景是给定一个靶点需要同时在活性和ADMET性质吸收、分布、代谢、排泄、毒性之间寻找最优折中。我用过遗传算法、贝叶斯优化来生成“推荐设计”约束条件包括预测pIC50 阈值、预测肝微粒体稳定性 某个值、预测hERG毒性风险低于某个概率、合成可及性评分在可接受范围内。这样生成的推荐清单不再只是“活性最高的分子”而是“在活性和成药性之间平衡最好的候选集合”。决策层还有一个被低估的作用把专家经验固化下来。药化主任看分子时心里有本账“哪个位点容易被代谢”“哪个基团容易导致毒性”这些经验很难口口相传却可以通过规则或模型逐渐显性化。当AI能把专家经验变成可量化、可复现的规则时团队的决策水平就不会因为换人而波动。3. 实操搭建一套药化-药理联动的数智工作流理论框架说得再多不如拿一套可以抄作业的工作流来落地。下面是我在真实项目中总结的一套流程不需要巨额投入用开源工具加少量工程开发就能跑起来。3.1 第一步统一数据记录与标准化处理这一环节的目标是建立一个“唯一数据源”Single Source of Truth。所有药化和药理数据都必须进入统一数据库禁止各自维护Excel。我推荐的数据表结构至少包含这些字段字段示例说明compound_idCP-00132全局唯一化合物编号structure_smilesCc1ccc(C(O)Nc2ccccc2)cc1标准化后的无盐SMILESprojectPD-L1所属项目targetPD-L1靶点名称assay_typebinding_ic50实验类型pIC506.83归一化活性值experiment_batchB2024-031实验批次号selectivity_index12.5选择性指数可选result_date2024-05-11数据日期结构标准化用RDKit一段简洁的代码就能跑from rdkit import Chem from rdkit.Chem import CanonicalSmiles, RemoveHs def standardize_smiles(smiles): mol Chem.MolFromSmiles(smiles) if mol is None: return None # 移除溶剂等不必要部分这里示意中和微笑结构 mol RemoveHs(mol) return CanonicalSmiles(mol)活性数据统一换算成pIC50def ic50_to_pIC50(ic50_nM, hill_slope1.0): # 将IC50(nM)转换为pIC50 import math if ic50_nM 0: return None return round(-math.log10(ic50_nM * 1e-9), 2)注意换算pIC50之前一定要确认IC50的单位。不同实验室可能用μM或nM搞错一个数量级模型学到的规律就全乱了。3.2 第二步构建可追溯、可解释的活性预测模型数据清洗完毕就可以建模型了。我建议先从可解释性强的模型开始。下面是一个极简但完整的随机森林建模流程可以直接作为基线baselineimport pandas as pd from rdkit.Chem import AllChem from rdkit import Chem from sklearn.ensemble import RandomForestRegressor from sklearn.model_selection import GroupKFold from sklearn.metrics import r2_score, mean_squared_error import numpy as np # 读取统一数据表 df pd.read_csv(unified_bioactivity_data.csv) # 计算ECFP4指纹作为特征 def morgan_fp(smiles, radius2, nbits1024): mol Chem.MolFromSmiles(smiles) if mol is None: return np.zeros(nbits) fp AllChem.GetMorganFingerprintAsBitVect(mol, radius, nBitsnbits) arr np.zeros((0,), dtypenp.int8) arr np.zeros((nbits,), dtypenp.int8) from rdkit.DataStructs import ConvertToNumpyArray ConvertToNumpyArray(fp, arr) return arr X np.array([morgan_fp(s) for s in df[structure_smiles]]) y df[pIC50].values # 分组交叉验证保证同一骨架的化合物不会同时出现在训练集和测试集 groups df[scaffold_group].values rf RandomForestRegressor(n_estimators300, random_state42) cv_preds np.zeros_like(y, dtypefloat) gkf GroupKFold(n_splits5) for train_idx, test_idx in gkf.split(X, y, groups): rf.fit(X[train_idx], y[train_idx]) cv_preds[test_idx] rf.predict(X[test_idx]) print(R2: %.3f % r2_score(y, cv_preds)) print(RMSE: %.3f % mean_squared_error(y, cv_preds, squaredFalse))这里我用“骨架分组”scaffold_group做交叉验证而不是随机的随机切分原因是随机切分会让分子结构与活性高度相似的同系列化合物同时出现在训练和测试集里导致预测分虚高。这一点是活性预测项目里最高频的坑。3.3 第三步让药理数据反向驱动药化设计模型建完不是终点真正的“融合”体现在药理数据能主动反哺药化设计。这一环节我建议搭建一个“AI推荐 专家审核”的闭环。具体操作是将活性预测模型、ADMET预测模型和合成可及性评分串成一个流水线。每次药化团队要设计新一批化合物先用生成算法比如遗传算法或基于片段的组合库枚举产出候选结构再逐个通过流水线打分最后输出带推荐理由的Top-50列表。药理团队在这个列表上叠加自己的经验规则比如避开特定官能团、考虑体内暴露量匹配形成最终合成清单。我把这套流水线的评分逻辑简化成一个大致的环节物化性质过滤不满足Lipinski类规则的分子直接过滤预测活性过滤预测pIC50低于项目阈值的分子排除ADMET风险过滤预测hERG风险高、代谢不稳定的分子标记风险合成可及性过滤按逆合成复杂度打分一分内可合成的优先多样性选择按分子骨架聚类兼顾结构多样性避免生成一堆相似物。整个流水线不需要全自动我坚持保留“人在回路”human-in-the-loop。AI负责批量处理和初筛专家负责最终决策。这样既提升效率又让一线科学家对AI推荐的结果有掌控感团队接受度高很多。4. 常见问题与避坑心得流程搭建过程中团队一定会遇到各种问题。我把项目里真实踩过、也帮其他团队排过的坑整理成几个高频项供大家排查参考。4.1 数据泄漏模型分数虚高的头号杀手做活性预测项目第一只拦路虎就是数据泄漏。简单说就是训练集和测试集之间混入了不该有的信息导致模型在验证阶段表现极其漂亮一到真实外部数据就崩盘。最隐蔽的泄漏形式是“相似骨架跨集”。假设你有一系列基于同一个核心骨架修饰的化合物随机划分数据集时这些相似化合物会同时出现在训练集和测试集。模型可以靠记忆骨架和活性的大致关系蒙对结果R2看起来0.8实际泛化能力可能只有0.3。解决办法就是我上面代码里用的骨架分组交叉验证。“多批次噪音泄漏”也很常见同一化合物做过多批次实验如果不按“批号”分组而按“样本”随机划分同一种化合物的两次重复实验可能被拆到训练和测试集两边模型等于在做重复实验均值回归真实能力当然被高估。应对方式是按化合物ID分组任何重复测量都归到同一组。4.2 跨团队“语言不通”融合失败的隐形原因技术问题往往容易发现团队协作的“语言不通”才是融合失败的深层原因。最典型的表现是药理团队反馈的活性数据药化团队根本不知道怎么解读而药化团队提出的修饰策略药理团队又觉得“这不是我们关心的”。我在项目里推动了一个很简单却很有效的做法每周开一次“数据复盘会”药化和药理团队坐在一起把最近一轮实验的分子结构、活性数据和PK数据对着看。会上不讨论谁对谁错只回答三个问题这个结果说明了什么跟我们的预测模型差在哪下一步改哪里这个习惯坚持了两个月两边不仅磨合出了统一的“数据结构”还一起改进了实验设计比如增加对照化合物、补充同一批次的重复实验。4.3 避坑速查表一线实操总结问题现象排查方法解决方案活性值不统一模型训练loss异常高检查单位nM vs μM、重复实验方差统一换算pIC50保留实验批次字段蛋白质晶体构象不符分子对接结果和药理实验矛盾比较docking pose vs SAR数据使用构象集合对接用MD模拟二次确认数据量太少模型过拟合严重比较训练/测试R2差异用简单模型、加强正则化、引入外部数据预训练hERG预测过度保守大批分子被误杀用单批验证hERG预测错误率调整风险阈值增加hERG实验复核药化/药理字段语义不匹配数据合并后大量空值检查字段定义文档建立统一词典用代码强制校验5. 我的几点个人体会做了一轮又一轮项目我最大的体会是药化与药理实现“数智融合”真正的难点不在于算法有多先进而在于团队愿不愿意把数据习惯改过来。数据治理是最不性感却是回报率最高的工作前期投入一个月做标准化后面每次建模、每轮项目讨论都会受益。另外AI模型在项目里最适合的定位不是“取代科学家”而是“放大科学家的判断力”。药化同事对SHAP贡献度图里的“意外正贡献”往往最感兴趣药理同事则特别喜欢看“体内PK预测”和“体外数据验证”的对比曲线。当模型能帮他们验证直觉、指出盲区融合就自然发生了。最后分享一个实用小技巧给每个化合物ID关联一张“数据画像卡”一页汇总这个分子的结构、合成路线、体外活性、ADMET预测值、体内PK值和相关专利信息。药化和药理开会时以画像卡为讨论载体效率提升不是一点半点。这个习惯我建议所有做药化-药理协同的团队都用起来。 药化与药理数智融合：从数据对齐到多目标优化的实践指南
1. 药化和药理为什么总是“两张皮”做创新药研发的朋友应该都有同感药化团队和药理团队明明在同一个项目里却常常像两个星球的人。药化同事天天盯着SMILES式、合成路线、溶解度嘴里念叨的是PlogP和合成可及性药理同事则守着酶活实验、细胞实验和动物PK数据整天讨论的是IC50、暴露量和剂量换算。两边各说各话项目推进往往卡在“化合物明明活性很好怎么动物实验就是不行”或者“药理反馈了一堆数据药化却不知道下一步该改哪里”这种尴尬局面上。这些年大家都在提“数智融合”尤其是药物研发领域这个话题已经从概念炒作阶段进入到了必须落地实操的阶段。但真要把药化和药理这两个学科的数据、逻辑、决策链路融在一起绝不是简单买套软件、上个数据库、跑几个深度学习模型就能解决的。我在项目里踩了很多坑之后才慢慢摸清所谓“真正融合”的门道——它本质上不是技术问题而是数据和机制的双重“翻译”问题。1.1 两种思维方式两套数据语言先说个最直观的矛盾。药化学科的底层逻辑是“结构决定性质”一个分子好不好先看结构能不能合成、稳不稳定、有没有专利风险药理学则更关注“剂量决定效应”一个分子活不活要看在什么浓度下产生什么反应、作用持续时间多长。这两套逻辑天然存在时间尺度的错配药化看的是毫秒级的分子构象和微摩尔级的结合能力药理看的是小时级的代谢过程和天级的体内分布。数据语言也不统一。药化留下的数据往往是化合物结构式的集合字段可能是“批号”“纯度”“MS/ NMR结果”药理生成的数据则是一堆实验曲线和统计学参数字段是“实验ID”“批次”“测定方法”“重复次数”。两边没有统一的“主键”化合物结构式和活性数据之间根本没有系统性的映射关系。我见过最典型的情况是同一批化合物药理结果在Excel里找得到但对应到结构式时要靠人工对照编号一不留神就会串号。这样的数据语言指望AI“自己学会”是不现实的。模型再强喂进去的也是两堆无法对齐的碎片信息。所以做数智融合第一步必须像建“巴别塔”一样先统一语言。不是让药化去学统计学也不是让药理去学合成化学而是让两边的数据先在同一个标准下可计算、可比较、可追溯。这一步是融合的真正基石也是绝大多数项目容易忽略的地方。1.2 融合的真正难点在于时间尺度与评价标准不一致第二个难点比数据格式更隐蔽就是两边的评价标准和时间节奏完全不在一个维度上。药化的周期以周计一个化合物从设计到合成出来顺利的话一两个星期药理的评价周期却受限于实验排期一个完整的数据反馈往往要一个月甚至更久。这就导致药化常常在没等到药理反馈的时候就基于“经验感觉”迭代了一轮等到药理数据终于出来药化已经多合成了好几个类似的分子。这种脱节不是认不认真做事的问题而是两个学科本身的生物钟不一样。评价标准也不一致。药化觉得“溶解度7 μg/mL已经很好了”药理却觉得“这个溶解度做成口服制剂根本不行”。药化觉得“选择性体外数据差3倍可以接受”药理却会告诉你“这个比值在体内基本等于没有选择性”。这些评价冲突靠人开会能解决一部分但长期看必须把标准沉淀成可执行的规则和模型。比如把“可成药性评价”固化成一套包含活性、选择性、渗透性、代谢稳定性、溶解度等多个维度的评分体系让药化和药理在同一个尺度上讨论问题。所以真正的“数智融合”在我看来就是让两个学科的数据流、知识流和决策流在统一框架里协同起来。它可以不完美但必须让每一步迭代都有据可查、有理可依。这个思想打通了后面所有技术手段才有意义。2. 数智融合不是喊口号三个关键落地层次理解了矛盾在哪再来看融合具体该落在哪里。我习惯把药化-药理的数智融合分成三个层次数据层、模型层和决策层。很多项目做不下去是因为一上来就奔着模型层去忽略了数据层的基础也有项目堆了一堆数据和模型却在决策层完全断档AI变成了“花瓶”。2.1 数据层让分子与活性数据真正“对齐”数据层是一切融合的底座。核心工作就两件事一是把药化的分子结构标准化二是把药理的活性数据归一化并且让两者在同一个“化合物ID”下关联起来。分子结构标准化的坑很多。同一个分子有人用SMILES时带盐有人不带盐有人保留了立体化学信息有人直接把三维结构存成MOL2文件。这些细节如果不统一后续计算描述符、指纹、分子相似度时都会出错。我常用的方案是统一用RDKit对SMILES做标准化清洗去盐、中和、优选规范SMILES把立体信息单独保存这样既保留化学准确性又让计算可重现。药理活性数据归一化更关键。不同实验室、不同批次的IC50值差异可以大到几倍直接拿原始值建模型噪声会淹没信号。实操中我习惯把IC50换算成pIC50负对数因为它近似正态分布更符合统计建模的假设也方便后续做回归任务。同时二值化的“活性/无活性”标签不能随便设阈值要根据不同靶点的历史数据和实验窗口来定。数据清洗规范看起来琐碎但决定了后面模型的上限。2.2 模型层从“预测活不活”到“解释为什么活”数据通了之后才轮到模型层。这一层的主要任务是用机器学习方法建立化合物结构到药理活性之间的可解释模型。初期不要一上来就上大模型。分子集就几百个化合物深度学习图网络很可能过拟合。我常用的组合是用分子指纹如ECFP4或RDKit描述符作为特征训练随机森林、XGBoost或SVM效果稳定且可解释。如果数据量超过几千个再考虑图神经网络或预训练分子模型这时候深度学习的优势才体现得出来。真正让模型层“智能”的不只是预测精度而是可解释性。我在项目里用SHAP值来分析特征贡献让药化同事可以直观看到“苯环上哪个位置取代对活性影响最大”“哪个官能团对代谢稳定性的贡献是负数”。当模型能回答“为什么”时药化团队才愿意真正把它当成设计工具。模型预测活不活只是结果解释为什么才能产生知识而知识才能积累成团队的决策资产。2.3 决策层多目标联合优化让AI能当“军师”数据通了、模型建了最终还要落到决策层。传统流程里药化设计完一批化合物送药理去筛活性好的再回头改结构相当于一轮一轮“试错”。“数智融合”的决策层要做出改变设计之初就把药理的约束条件放进来做多目标联合优化。多目标联合优化的典型场景是给定一个靶点需要同时在活性和ADMET性质吸收、分布、代谢、排泄、毒性之间寻找最优折中。我用过遗传算法、贝叶斯优化来生成“推荐设计”约束条件包括预测pIC50 阈值、预测肝微粒体稳定性 某个值、预测hERG毒性风险低于某个概率、合成可及性评分在可接受范围内。这样生成的推荐清单不再只是“活性最高的分子”而是“在活性和成药性之间平衡最好的候选集合”。决策层还有一个被低估的作用把专家经验固化下来。药化主任看分子时心里有本账“哪个位点容易被代谢”“哪个基团容易导致毒性”这些经验很难口口相传却可以通过规则或模型逐渐显性化。当AI能把专家经验变成可量化、可复现的规则时团队的决策水平就不会因为换人而波动。3. 实操搭建一套药化-药理联动的数智工作流理论框架说得再多不如拿一套可以抄作业的工作流来落地。下面是我在真实项目中总结的一套流程不需要巨额投入用开源工具加少量工程开发就能跑起来。3.1 第一步统一数据记录与标准化处理这一环节的目标是建立一个“唯一数据源”Single Source of Truth。所有药化和药理数据都必须进入统一数据库禁止各自维护Excel。我推荐的数据表结构至少包含这些字段字段示例说明compound_idCP-00132全局唯一化合物编号structure_smilesCc1ccc(C(O)Nc2ccccc2)cc1标准化后的无盐SMILESprojectPD-L1所属项目targetPD-L1靶点名称assay_typebinding_ic50实验类型pIC506.83归一化活性值experiment_batchB2024-031实验批次号selectivity_index12.5选择性指数可选result_date2024-05-11数据日期结构标准化用RDKit一段简洁的代码就能跑from rdkit import Chem from rdkit.Chem import CanonicalSmiles, RemoveHs def standardize_smiles(smiles): mol Chem.MolFromSmiles(smiles) if mol is None: return None # 移除溶剂等不必要部分这里示意中和微笑结构 mol RemoveHs(mol) return CanonicalSmiles(mol)活性数据统一换算成pIC50def ic50_to_pIC50(ic50_nM, hill_slope1.0): # 将IC50(nM)转换为pIC50 import math if ic50_nM 0: return None return round(-math.log10(ic50_nM * 1e-9), 2)注意换算pIC50之前一定要确认IC50的单位。不同实验室可能用μM或nM搞错一个数量级模型学到的规律就全乱了。3.2 第二步构建可追溯、可解释的活性预测模型数据清洗完毕就可以建模型了。我建议先从可解释性强的模型开始。下面是一个极简但完整的随机森林建模流程可以直接作为基线baselineimport pandas as pd from rdkit.Chem import AllChem from rdkit import Chem from sklearn.ensemble import RandomForestRegressor from sklearn.model_selection import GroupKFold from sklearn.metrics import r2_score, mean_squared_error import numpy as np # 读取统一数据表 df pd.read_csv(unified_bioactivity_data.csv) # 计算ECFP4指纹作为特征 def morgan_fp(smiles, radius2, nbits1024): mol Chem.MolFromSmiles(smiles) if mol is None: return np.zeros(nbits) fp AllChem.GetMorganFingerprintAsBitVect(mol, radius, nBitsnbits) arr np.zeros((0,), dtypenp.int8) arr np.zeros((nbits,), dtypenp.int8) from rdkit.DataStructs import ConvertToNumpyArray ConvertToNumpyArray(fp, arr) return arr X np.array([morgan_fp(s) for s in df[structure_smiles]]) y df[pIC50].values # 分组交叉验证保证同一骨架的化合物不会同时出现在训练集和测试集 groups df[scaffold_group].values rf RandomForestRegressor(n_estimators300, random_state42) cv_preds np.zeros_like(y, dtypefloat) gkf GroupKFold(n_splits5) for train_idx, test_idx in gkf.split(X, y, groups): rf.fit(X[train_idx], y[train_idx]) cv_preds[test_idx] rf.predict(X[test_idx]) print(R2: %.3f % r2_score(y, cv_preds)) print(RMSE: %.3f % mean_squared_error(y, cv_preds, squaredFalse))这里我用“骨架分组”scaffold_group做交叉验证而不是随机的随机切分原因是随机切分会让分子结构与活性高度相似的同系列化合物同时出现在训练和测试集里导致预测分虚高。这一点是活性预测项目里最高频的坑。3.3 第三步让药理数据反向驱动药化设计模型建完不是终点真正的“融合”体现在药理数据能主动反哺药化设计。这一环节我建议搭建一个“AI推荐 专家审核”的闭环。具体操作是将活性预测模型、ADMET预测模型和合成可及性评分串成一个流水线。每次药化团队要设计新一批化合物先用生成算法比如遗传算法或基于片段的组合库枚举产出候选结构再逐个通过流水线打分最后输出带推荐理由的Top-50列表。药理团队在这个列表上叠加自己的经验规则比如避开特定官能团、考虑体内暴露量匹配形成最终合成清单。我把这套流水线的评分逻辑简化成一个大致的环节物化性质过滤不满足Lipinski类规则的分子直接过滤预测活性过滤预测pIC50低于项目阈值的分子排除ADMET风险过滤预测hERG风险高、代谢不稳定的分子标记风险合成可及性过滤按逆合成复杂度打分一分内可合成的优先多样性选择按分子骨架聚类兼顾结构多样性避免生成一堆相似物。整个流水线不需要全自动我坚持保留“人在回路”human-in-the-loop。AI负责批量处理和初筛专家负责最终决策。这样既提升效率又让一线科学家对AI推荐的结果有掌控感团队接受度高很多。4. 常见问题与避坑心得流程搭建过程中团队一定会遇到各种问题。我把项目里真实踩过、也帮其他团队排过的坑整理成几个高频项供大家排查参考。4.1 数据泄漏模型分数虚高的头号杀手做活性预测项目第一只拦路虎就是数据泄漏。简单说就是训练集和测试集之间混入了不该有的信息导致模型在验证阶段表现极其漂亮一到真实外部数据就崩盘。最隐蔽的泄漏形式是“相似骨架跨集”。假设你有一系列基于同一个核心骨架修饰的化合物随机划分数据集时这些相似化合物会同时出现在训练集和测试集。模型可以靠记忆骨架和活性的大致关系蒙对结果R2看起来0.8实际泛化能力可能只有0.3。解决办法就是我上面代码里用的骨架分组交叉验证。“多批次噪音泄漏”也很常见同一化合物做过多批次实验如果不按“批号”分组而按“样本”随机划分同一种化合物的两次重复实验可能被拆到训练和测试集两边模型等于在做重复实验均值回归真实能力当然被高估。应对方式是按化合物ID分组任何重复测量都归到同一组。4.2 跨团队“语言不通”融合失败的隐形原因技术问题往往容易发现团队协作的“语言不通”才是融合失败的深层原因。最典型的表现是药理团队反馈的活性数据药化团队根本不知道怎么解读而药化团队提出的修饰策略药理团队又觉得“这不是我们关心的”。我在项目里推动了一个很简单却很有效的做法每周开一次“数据复盘会”药化和药理团队坐在一起把最近一轮实验的分子结构、活性数据和PK数据对着看。会上不讨论谁对谁错只回答三个问题这个结果说明了什么跟我们的预测模型差在哪下一步改哪里这个习惯坚持了两个月两边不仅磨合出了统一的“数据结构”还一起改进了实验设计比如增加对照化合物、补充同一批次的重复实验。4.3 避坑速查表一线实操总结问题现象排查方法解决方案活性值不统一模型训练loss异常高检查单位nM vs μM、重复实验方差统一换算pIC50保留实验批次字段蛋白质晶体构象不符分子对接结果和药理实验矛盾比较docking pose vs SAR数据使用构象集合对接用MD模拟二次确认数据量太少模型过拟合严重比较训练/测试R2差异用简单模型、加强正则化、引入外部数据预训练hERG预测过度保守大批分子被误杀用单批验证hERG预测错误率调整风险阈值增加hERG实验复核药化/药理字段语义不匹配数据合并后大量空值检查字段定义文档建立统一词典用代码强制校验5. 我的几点个人体会做了一轮又一轮项目我最大的体会是药化与药理实现“数智融合”真正的难点不在于算法有多先进而在于团队愿不愿意把数据习惯改过来。数据治理是最不性感却是回报率最高的工作前期投入一个月做标准化后面每次建模、每轮项目讨论都会受益。另外AI模型在项目里最适合的定位不是“取代科学家”而是“放大科学家的判断力”。药化同事对SHAP贡献度图里的“意外正贡献”往往最感兴趣药理同事则特别喜欢看“体内PK预测”和“体外数据验证”的对比曲线。当模型能帮他们验证直觉、指出盲区融合就自然发生了。最后分享一个实用小技巧给每个化合物ID关联一张“数据画像卡”一页汇总这个分子的结构、合成路线、体外活性、ADMET预测值、体内PK值和相关专利信息。药化和药理开会时以画像卡为讨论载体效率提升不是一点半点。这个习惯我建议所有做药化-药理协同的团队都用起来。