首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Nat. Protoc. | AI 对接终于走向可用平台?浙大团队打造CVSP-AIE 把AI虚拟筛选做成工作流

Nat. Protoc. | AI 对接终于走向可用平台?浙大团队打造CVSP-AIE 把AI虚拟筛选做成工作流

作者头像
DrugIntel
发布2026-07-13 16:21:46
发布2026-07-13 16:21:46
3400
举报

文献来源

论文题目: Facilitating structure-based drug discovery with an artificial intelligence-driven virtual screening platform 期刊:Nature Protocols 年份: 2026 DOI: 10.1038/s41596-026-01389-z 作者: Shukai Gu, Xujun Zhang, Mengwu Xiao 等 研究类型: Protocol / 平台型工作 核心平台: Comprehensive VS Platform with AI Engine,简称 CVSP-AIE。论文明确指出,该平台集成 KarmaDock、CarsiDock 和 RTMScore 三个 AI 模型,提供网页端(https://cadd.zju.edu.cn/cvsp)与本地部署版本(https://github.com/shukai1997/HierVS),用于基于结构的虚拟筛选。


摘要

这篇文章把一组 AI 对接与打分模型封装成可执行、可部署、可交互分析的结构虚拟筛选平台。CVSP-AIE 的核心思想是:用 KarmaDock 快速处理大规模化合物库,用 CarsiDock 对高排名分子进行更可靠的构象重建,再用 RTMScore 进行精细重打分,从而在速度、构象合理性和筛选精度之间取得动态平衡。它的真正价值不只在于模型指标,而在于将蛋白准备、化合物标准化、对接、重打分、相互作用分析和化学空间可视化串成完整流程,使 AI 对接从算法演示进一步接近实际药物发现工作流。


为什么这篇论文值得关注?

过去几年,AI 对接模型发展很快。很多模型在 pose prediction、虚拟筛选 enrichment、打分相关性上都给出了不错的 benchmark 结果。但对于真正做药物发现的人来说,问题往往是:

一个具体靶点来了,应该用哪个模型? 化合物库如何清洗? 蛋白结构怎么修复? 口袋如何定义? 几十万甚至上百万分子如何跑完? 结果如何排序、解释、聚类和选分子? 模型生成的 pose 是否物理合理? 网页端、命令行、本地部署之间如何切换?

CVSP-AIE 针对的正是这个落地缺口。论文开篇指出,AI-powered docking/scoring 方法虽然已经展示出速度和准确性潜力,但具体应用中仍然存在方法选择困难、部署门槛高、预处理与后处理复杂等问题。

因此,这篇文章的重点是提供一个面向使用场景的基于结构虚拟筛选协议:让用户上传蛋白和已知配体,就可以完成从数据准备到虚拟筛选再到结果分析的完整流程。它更像是 AI-SBVS 的工程化说明书。


研究背景

基于结构的虚拟筛选的基本逻辑很直接:先获得靶标蛋白结构,再把化合物库中的分子逐个放入口袋中进行对接,随后用打分函数评估结合强弱,最后按分数排序并挑选候选分子进入实验验证。

传统 docking 工具,如 Glide、AutoDock Vina、LeDock、GOLD、Surflex 等,通常依赖构象搜索加经验或物理启发式打分函数。它们的优点是构象约束较明确,生成 pose 往往具有较好的化学与几何合理性;缺点是大规模筛选时速度有限,打分函数也经常受到简化加和假设影响,难以准确表达真实蛋白–配体结合热力学。论文在 Development of the protocol 部分也明确指出,传统方法需要在有限搜索步数内寻找合理构象,采样收敛与打分可靠性都存在固有限制。

AI docking/scoring 方法尝试解决这个问题。它们可以用深度网络学习蛋白–配体相互作用模式,在速度上通常明显快于传统物理搜索方法。但 AI 方法也带来新的问题:有些方法直接更新配体原子笛卡尔坐标,速度非常快,却可能破坏键长、键角、扭转角和分子内部几何;有些方法更重视构象合理性,但计算成本又会上升。论文将这个矛盾概括为速度、准确性和物理合理性之间的权衡。

CVSP-AIE 的设计正是围绕这个权衡展开:不是把所有分子都用最慢、最精细的方法处理,也不是只用最快模型一遍筛到底,而是分层使用不同模型。


核心思想

CVSP-AIE 的核心是三个模型的功能分工与层级组合:

KarmaDock 负责快筛。 它是一个高效率 docking 模型,使用带 self-attention 机制的 E(n)-equivariant graph neural network,直接更新配体原子的三维笛卡尔坐标,从而快速得到候选结合构象与打分。优势是速度极快,论文给出的平均单次 docking/scoring 时间为 0.017 秒;问题是直接坐标更新没有显式维护全部分子键合信息,因此 pose 的物理合理性可能不足。

CarsiDock 负责精筛构象。学习蛋白–配体原子距离矩阵,再通过平移、旋转和扭转角引导的几何优化过程,把预测距离矩阵重建成更可信的结合 pose。这种设计牺牲部分速度,但可以改善配体内部构象与蛋白–配体相对几何的合理性。

RTMScore 负责重打分。 它是一个 scoring 模型,核心思想是学习结合口袋中残基与配体原子之间距离的概率密度分布,用于评估结合 pose 和预测亲和力。论文描述 RTMScore 通过 mixture dense network 学习配体原子与口袋残基之间距离分布,并在 CASF-2016、DEKOIS2、DUD-E 等 benchmark 上取得较好表现。

因此,HierarchicalVS 的实际逻辑是:

先用 KarmaDock 对完整化合物库进行高速初筛; 再从前排候选中选择 Top N; 然后用 CarsiDock 进行更精细的 docking; 最后用 RTMScore 重打分并输出排序、pose 和相互作用分析。

论文在操作流程中明确说明,HierarchicalVS 会先用 KarmaDock 处理整个化合物库,再选择 Top N 分子进入 CarsiDock 和 RTMScore 的进一步 docking 与 scoring。

这就是 CVSP-AIE 最值得关注的地方:它没有假设单一 AI 模型可以同时解决所有问题,而是把不同模型放在不同筛选阶段,让快模型负责召回,让精模型负责构象与排序校正。

4. 方法细节

4.1 输入是什么?

CVSP-AIE 的标准输入包括三类数据:

第一,靶标蛋白结构,通常是 PDB 格式。蛋白可以来自 RCSB PDB,也可以来自 AlphaFold3、Boltz2 等结构预测模型。论文强调,如果没有已知蛋白结构或复合物结构,用户需要先借助结构预测工具获得可用构象。

第二,参考配体结构。这个参考配体用于定义结合口袋。也就是说,CVSP-AIE 当前更适合已有已知 binder、共晶配体或可信结合位点的靶点。如果只有 apo 蛋白而没有明确口袋,流程会变复杂。

第三,候选化合物库。用户可以使用平台内置商业化合物库,也可以上传自定义库。论文提到网页端提供 Clustered ChemDiv、Enamine Hit Locator Library、Specs、DrugBank 等常用库。自定义库需要符合格式要求:第一列为 SMILES,第二列为分子名称,中间用 tab 分隔,网页端单任务最多支持 100 万个分子。

如果用户只想对其他 docking 工具已经生成的 pose 进行重打分,则进入 HpRS 模块,此时输入不再是原始化合物库,而是 receptor、reference ligand 和外部 docking 工具生成的 ligand poses。


4.2 数据预处理:平台化工作的关键环节

很多 AI docking 论文容易弱化预处理,但实际虚拟筛选中,预处理常常决定任务能否顺利完成。CVSP-AIE 把预处理独立成 Preprocess 模块。

蛋白预处理主要依赖 Schrödinger 的 Protein Preparation Wizard,包括补全缺失侧链、补全 loop、加氢、设置指定 pH 下的质子化状态、优化氢键网络、移除非必要小分子但保留金属离子和辅因子,以及能量最小化。论文提醒,PDB 结构常见 missing loops 等问题,因此在虚拟筛选前进行蛋白预处理是推荐步骤。

化合物库预处理主要依赖 RDKit,包括去除显式氢、删除断裂片段、标准化分子、重新离子化、保留最大片段、中和分子、按分子量过滤、去除 PAINS、去重、剔除读取失败分子、剔除 InChIKey 生成失败分子,以及剔除构象生成失败分子。这个步骤看似工程化,但对于大规模筛选非常重要,因为少量非法 SMILES、盐形式、异常片段或构象失败分子就可能导致整个任务中断。

从实际药物发现角度看,CVSP-AIE 的一个优点正是把这些繁琐步骤放进平台,而不是要求用户自己写脚本逐一处理。


4.3 六个功能模块如何分工?

CVSP-AIE 网页端包含六个核心模块,覆盖从数据准备到筛选、重打分和分析的全过程。论文图 1 和图 2 展示了整体架构:平台同时提供 cloud services 和 on-premises services,网页端面向图形界面操作,本地端面向 Docker 与命令行部署。

Preprocess 模块 负责蛋白结构和化合物库标准化,是后续所有 VS 模块的输入准备环节。

HeVS 模块 High-efficiency VS,使用 KarmaDock 进行高效率筛选。适合大库初筛、需要快速得到候选排序的场景。

HpVS 模块 High-precision VS,使用 CarsiDock 进行更精细的 docking。适合候选数量较少、用户更关心 pose 可靠性和相互作用解释的场景。

HierarchicalVS 模块 整合 KarmaDock、CarsiDock 和 RTMScore,是平台最核心的分层筛选模式。它先用 KarmaDock 对全库排序,再对 Top N 进行 CarsiDock docking 和 RTMScore rescoring。Top N 可由用户设置,论文建议 Top N 通常为候选库的 0.5%–10%,并限制在 10 到 10,000 之间。

HpRS 模块 使用 RTMScore 对外部 docking pose 进行重打分。这个模块适合已经用 Glide、AutoDock Vina 等工具生成 pose 的用户,希望用 AI scoring 重新排序。

CvPL 模块 用于任意蛋白–配体复合物的相互作用计算和可视化,服务于结果解释和 hit 优化分析。

4.4 三个 AI 模型的技术路线

KarmaDock:直接坐标更新带来速度优势

KarmaDock 的关键在于使用 E(n)-equivariant GNN 处理三维结构信息。E(n)-equivariance 的意义是,模型对于空间平移、旋转和反射具有合理响应,不会因为整个蛋白–配体复合物在坐标系中换了方向就改变物理判断。KarmaDock 进一步引入 self-attention,提高图神经网络对远程关系和复杂相互作用模式的表达能力。它通过直接更新配体原子坐标获得 pose,因此可以极大压缩传统 docking 中昂贵的构象搜索时间。

但代价也很明显:配体不是一堆自由点,而是由键、键角、环系和扭转约束共同决定的化学对象。直接坐标更新如果没有足够强的内部几何约束,就可能得到看起来放进了口袋、但分子内部不合理的构象。论文也明确指出,KarmaDock 生成的多数分子会因直接坐标更新且未纳入键合信息而无法通过 PB-valid 检测。

CarsiDock:用距离矩阵预测连接学习与几何优化

CarsiDock 的思路更接近把 AI 预测与几何重建结合起来。模型先预测蛋白–配体原子距离矩阵,也就是估计配体每个原子与蛋白口袋相关原子之间应当保持怎样的距离关系。随后,系统不是直接接受网络输出坐标,而是通过平移、旋转和扭转角引导的几何优化,把这些距离约束转化为一个更可信的 ligand pose。

这种路线的优势是保留了更多分子构象约束,特别是扭转角层面的可控性,因此 pose 合理性优于直接坐标更新方法。缺点是计算成本更高,不适合直接对百万级分子全部进行精细 docking。

RTMScore:把相互作用打分转化为距离分布学习

RTMScore 的核心不是简单预测一个 binding score,而是学习残基–原子距离分布。可以把它理解为一种数据驱动的相互作用势:对于一个给定蛋白–配体 pose,模型评估配体原子与口袋残基之间的空间关系是否符合实验复合物中常见的结合模式。论文描述 RTMScore 学习 ligand atom 与 binding site residue 间距离的 probability density distribution,用于 binding affinity prediction。

这类 scoring 模型的价值在于,它比传统经验打分函数更容易从大量结构数据中学习复杂相互作用模式;风险则在于,它也可能学习到 benchmark 数据分布中的 shortcut,而不是真正可外推的物理规律。


4.5 推理流程:从 10 万分子到候选清单

以 HierarchicalVS 为例,用户实际会经历如下流程:

  1. 1. 上传 receptor PDB 和 reference ligand,用于确定筛选口袋。
  2. 2. 上传或选择化合物库,平台对化合物进行标准化和构象生成。
  3. 3. KarmaDock 对完整化合物库进行高通量 docking/scoring。
  4. 4. 用户设定 Top N,系统把前排分子送入 CarsiDock 进行更精细构象预测。
  5. 5. RTMScore 对 CarsiDock 结果进行重打分。
  6. 6. 平台输出候选分子排序、KarmaScore、RTMScore、CarsiDock pose、蛋白–配体相互作用图、化学空间可视化和理化性质分布。

论文给出的运行时间非常直观:网页端对 100,000 个化合物进行 HierarchicalVS,使用 KarmaDock 快筛全库并对 Top 1,000 分子进行精细 docking 和 rescoring,大约需要 34–45 分钟;HeVS 对 100,000 个化合物约需 15–20 分钟;HpVS 对 1,000 个化合物约需 19–24 分钟;本地版本对 1,000,000 个化合物进行完整流程约需 16–20 小时。

这组时间说明,CVSP-AIE 的定位不是替代所有工业级流程,而是提供一个相对轻量、可访问、可扩展的 AI-SBVS 工作流。对于学术实验室或早期项目,它能显著降低从靶点结构到候选列表的操作门槛。


5. 实验设计与关键结果:指标好看,但要读出边界

论文主要从两个角度比较 CVSP-AIE:一是嵌入模型在虚拟筛选 benchmark 上的 enrichment 和效率;二是平台功能与其他 VS 平台的差异。

在 DEKOIS 2.0 benchmark 上,KarmaDock、CarsiDock 和 RTMScore 相关组合整体优于多种传统 docking 与 AI 方法。表 1 中,Glide 的 EF_0.5% 为 13.628,ROC_AUC 为 0.742;KarmaDock 的 EF_0.5% 为 16.989,ROC_AUC 为 0.782;CarsiDock 的 EF_0.5% 为 20.460,ROC_AUC 为 0.793;Glide_RTMScore 的 EF_0.5% 为 20.990,ROC_AUC 为 0.768。

这些结果说明,AI docking/scoring 在 retrospective VS 任务中确实具备较强早期富集能力。特别是 EF_0.5% 和 BEDROC 这类指标,更关注排名前列是否富集活性分子,这与虚拟筛选实际需求高度相关:实验资源有限,真正进入实验验证的通常只是前几百或前几十个候选。

速度方面,论文表 2 给出的差异更明显:KarmaDock 平均单次 docking 仅 0.017 秒,CarsiDock 为 1.726 秒,而 Glide SP 为 23.798 秒,Glide XP 为 139.106 秒。

但作者也给出重要提醒:传统 docking 工具的时间通常来自单线程 CPU 测试,而 AI 工具依赖 GPU 加速;真实项目中,传统 docking 可以通过多核 CPU 并行显著提速。因此,不能简单把表中秒数直接转化为所有场景下的绝对优势。

更关键的是,论文没有回避 benchmark 偏差问题。作者指出,VS benchmark 的设计可能给 AI 模型提供 shortcut,使模型通过记忆训练集中特定数据分布取得高分,而不是真正学习蛋白–配体相互作用本质;当应用到新靶点或新化学实体时,预测效果可能明显下降。

这句话非常重要。它意味着 CVSP-AIE 的结果应该被理解为候选优先级建议,而不是实验活性的确定性判断。


6. 结果输出:不只是分数,还有可解释分析

CVSP-AIE 输出两大类结果。

第一类是分子排序结果。HierarchicalVS 可以输出基于 KarmaDock 的全库排序,也可以输出经 CarsiDock pose 和 RTMScore 重打分后的排序,结果可下载为 CSV 文件。

第二类是top-ranked 分子的深度分析。平台会进行蛋白–配体相互作用计算与可视化,覆盖氢键、范德华作用、疏水相互作用、π–π stacking、π–cation interaction 和 salt bridge 等作用类型。

此外,平台还提供化学空间分析。论文描述其使用 Morgan fingerprints,半径为 2,长度为 2048 bits,并通过 t-SNE 投影展示高排名分子的结构分布;点的颜色反映 docking score,点的大小反映 QED。平台还展示 QED、分子量、氢键供体数、氢键受体数和 logP 等理化性质分布。

这对药化人员很有价值。真实 hit selection 从来不是只看 docking score,而要同时考虑结构多样性、理化性质、可合成性、相互作用模式和后续优化空间。CVSP-AIE 至少把这些信息放在一个交互界面中,减少了模型输出与人工判断之间的断裂。


启发

第一,AI 对接落地的关键不只是模型精度,而是工作流完整性。 很多 AI docking 方法停留在 benchmark 层面,但实际使用需要蛋白预处理、配体标准化、异常分子处理、批量任务管理、结果可视化和候选解释。CVSP-AIE 的贡献在于把这些环节串起来。

第二,速度和物理合理性不应由单一模型硬扛。 KarmaDock 快,但 pose 合理性有风险;CarsiDock 更稳,但更慢;RTMScore 更适合重排序。分层筛选比单模型筛选更符合实际药物发现流程。

第三,AI scoring 可以提升排序,但不能代替实验验证。 DEKOIS 2.0 上的 EF 和 ROC-AUC 提升很有意义,但 retrospective benchmark 与真实靶点发现之间仍有距离。特别是新靶点、新 scaffold、柔性口袋、金属依赖体系和诱导契合场景,仍然需要谨慎。

第四,平台化会改变 AI 制药工具的使用人群。 网页端降低了湿实验研究者进入结构虚拟筛选的门槛,本地端则给计算团队提供大规模部署能力。AI 工具的传播不只依赖论文,还依赖是否能被非开发者稳定使用。


局限性

这篇论文的局限性可以分为五层。

第一,平台当前依赖明确口袋和参考配体。 CVSP-AIE 需要 known binder 或 reference ligand 来定义 binding pocket。如果用户只有 apo protein 或低置信度预测结构,就必须先借助 AlphaFold3、Boltz2 等工具建模复合物或推断口袋,这会引入额外不确定性。论文也将这一点列为平台限制。

第二,AI pose 的物理合理性仍是核心风险。 KarmaDock 的直接坐标更新带来极高速度,但可能产生不合理内部构象;CarsiDock 改善了这一点,但仍与物理 docking 方法存在差距。论文明确提到 KarmaDock 多数分子无法通过 PB-valid 检测,也指出当前 AI 模型仍存在 predicted poses 物理合理性不足的问题。

第三,模型对新靶点和新配体的泛化仍未彻底解决。 作者承认,当前 AI 模型可能对 binding pocket perturbation 不敏感,并且在 novel targets 和 ligands 上性能会显著下降。

第四,benchmark 成绩不等于真实项目成功率。 DEKOIS 2.0、DUD-E 等数据集有助于横向比较方法,但 decoy 构造、活性分子来源、靶标相似性和训练集重叠风险都会影响模型表现。论文也提醒,AI 模型可能通过数据分布 shortcut 获得高分。

第五,平台仍缺少完整闭环优化能力。 CVSP-AIE 已经支持筛选、排序、相互作用分析和化学空间可视化,但 hit-to-lead optimization、合成路线评估、ADMET 预测、反馈和不确定性估计仍不是当前核心功能。作者也指出,未来一个方向是整合 hit compound optimization models,使平台从 VS 工具进一步走向一体化 drug design platform。


对 AI 制药未来发展的意义

CVSP-AIE 代表了 AI 制药工具发展的一个重要趋势:从单一模型指标竞争,走向流程化、平台化和场景化。

在基于结构药物发现中,真正重要的不是某个模型在某个测试集上多提高几点 ROC-AUC,而是它能否进入可执行流程:输入是否清晰,错误是否可控,运行时间是否可预测,结果是否能被药化人员解释,候选是否能自然进入实验验证。

这篇文章给出的启发是,AI docking 的未来很可能不是一种模型统治所有任务,而是多模型协同:快筛模型负责大库召回,几何约束模型负责 pose 可信度,scoring 模型负责排序修正,后处理模块负责相互作用解释和化学空间选择,实验反馈再反向更新模型或筛选策略。

从更长远看,CVSP-AIE 如果进一步整合自动口袋识别、蛋白–配体共结构预测、hit-to-lead 生成、合成可及性评估和实验反馈学习,就可能成为真正面向项目推进的 AI-SBDD 平台,而不只是一个虚拟筛选入口。


小结

CVSP-AIE 的价值不在于宣称 AI docking 已经解决虚拟筛选,而在于它把 AI 对接、AI 打分、分层筛选、网页端操作、本地部署和结果解释放进了同一个可执行协议中。它承认不同模型有不同边界,并用层级策略处理速度、准确性和物理合理性之间的矛盾。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-08,如有侵权请联系 cloudcommunity@tencent.com 删除
目录
  • 文献来源
  • 摘要
  • 为什么这篇论文值得关注?
  • 研究背景
  • 核心思想
  • 4. 方法细节
    • 4.1 输入是什么?
    • 4.2 数据预处理:平台化工作的关键环节
    • 4.3 六个功能模块如何分工?
    • 4.4 三个 AI 模型的技术路线
    • 4.5 推理流程:从 10 万分子到候选清单
  • 5. 实验设计与关键结果:指标好看,但要读出边界
  • 6. 结果输出:不只是分数,还有可解释分析
  • 启发
  • 局限性
  • 对 AI 制药未来发展的意义
  • 小结
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档