1. 拆解AI native制药从概念到落地到底在做什么1.1 一个被过度包装但确实在改变行业的概念AI native制药这个词这两年出现的频率越来越高但真正在这个圈子里干活的人都知道大部分挂着这个名头的公司实际上只是把AI当做一个辅助工具在用离native还差得远。所谓AI native核心不在于你用了几块GPU、跑了几个大模型而在于整个公司的项目流程、组织架构、决策链路是不是围绕AI的能力边界和数据流转来设计的。传统制药公司的流程是“靶点发现→化合物筛选→临床前研究→临床申报”AI在这里面通常只是加速某一个环节。而AI native的逻辑是反过来的先想清楚数据能从哪来、模型能学到什么、预测结果如何闭环验证再倒推需要做什么实验、招什么人、建什么管线。我过去两年参与过两个AI native制药项目的从零搭建一个偏向小分子生成一个偏向抗体设计。踩过的坑、交过的学费不少今天就把整个项目流程拆开来讲从立项到交付尽量把每个环节的真实操作和背后的决策逻辑说清楚。不管你是刚入行的算法工程师、药化背景想转AI的产品经理还是投资机构想看明白这类公司到底怎么运转的这篇内容应该都能给你一些参考。1.2 谁适合看这篇流程拆解先明确一下受众。如果你是完全没接触过制药的纯AI背景建议先补一下基础药物发现流程不然很多术语会让你卡住。如果你是有制药背景但对AI一知半解这篇会帮你理解算法团队到底在干什么、为什么他们总是要那么多数据。最合适的读者是已经在AI制药公司工作、或者正在搭建这类团队的人因为我会讲到很多流程设计上的取舍和实际执行中的细节这些在公开资料里基本看不到。整个流程我会拆成五个阶段来讲项目立项与数据基建、模型选型与迭代、干湿实验闭环、计算机化系统验证、以及交付与管线推进。每个阶段都会给出具体的操作步骤、参数选择的依据、以及我们实际踩过的坑。最后会整理一份常见问题速查表方便你在遇到类似情况时快速定位。2. 项目立项与数据基建地基打不好后面全是坑2.1 立项阶段最容易被忽略的三件事大部分AI native制药项目在立项时团队最兴奋的是模型架构和算力配置但真正决定项目生死的是另外三件事。第一是数据可及性评估你得先搞清楚目标靶点相关的公开数据有多少、自有数据有多少、合作方能不能提供数据、数据质量如何。我们做过一个统计在小分子生成项目中真正能用于训练的高质量活性数据往往只占公开数据库的15%到20%剩下的要么是重复的、要么是实验条件不可追溯的、要么是阴性结果没被记录。第二是实验验证能力评估你的模型预测出来的分子有没有能力在合理时间内合成并测试如果外包给CRO周期和成本是多少第三是临床转化路径的初步判断这个靶点有没有已知的临床验证先例适应症市场有多大监管路径是否清晰。这三件事如果立项时没想清楚后面模型做得再漂亮也推不动。我见过一个团队花了八个月训练出一个生成模型结果发现生成的分子大部分超出了合作CRO的合成能力范围最后只能推倒重来。2.2 数据基建的具体操作步骤数据基建不是简单的建个数据库而是要从数据采集、清洗、标注、存储、版本管理全链路设计。我们当时的操作流程是这样的数据源盘点列出所有可能的数据来源包括ChEMBL、PubChem、BindingDB、内部实验记录、合作方数据等。对每个来源标注数据量、字段完整度、更新频率、授权状态。数据清洗流水线搭建用RDKit做分子标准化包括去盐、中和电荷、标准化互变异构体。这一步的代码大概长这样from rdkit import Chem from rdkit.Chem import SaltRemover def standardize_mol(smiles): mol Chem.MolFromSmiles(smiles) if mol is None: return None remover SaltRemover.SaltRemover() mol remover.StripMol(mol) Chem.SanitizeMol(mol) return Chem.MolToSmiles(mol)活性数据统一化不同来源的活性数据单位不同有IC50、Ki、EC50等需要统一转换成pIC50或pKi。转换公式是pIC50 -log10(IC50 in mol/L)。对于有多个活性值的情况取几何平均值。数据版本管理用DVC或类似的工具对数据集做版本控制每次模型训练都要记录用了哪个版本的数据。这个习惯在后期排查模型性能下降时非常关键。注意数据清洗阶段一定要保留原始数据和处理日志不要直接覆盖。我们有一次因为清洗脚本的一个bug导致一批关键数据被错误过滤幸好有原始备份才没造成大问题。2.3 数据标注与质量控制的实操心得数据标注在制药领域是个专业活不是随便找几个实习生就能干的。活性数据的标注需要药化背景的人来判断比如一个化合物在某个实验条件下显示活性但实验条件明显异常比如浓度过高导致假阳性这种数据就要标记为可疑。我们的做法是建立三级审核机制初级标注员做初步筛选中级审核员做交叉验证高级药化专家做最终裁定。每个标注结果都要记录标注人、审核人、标注时间、置信度评分。质量控制方面我们每周会随机抽取5%的标注数据做人工复核如果错误率超过2%就暂停标注工作重新培训。这个流程看起来繁琐但比起用脏数据训练出垃圾模型再返工成本低太多了。3. 模型选型与迭代没有银弹只有取舍3.1 不同任务对应的模型选型逻辑AI native制药涉及的任务类型很多每种任务适合的模型架构完全不同。小分子生成常用的是基于SMILES的序列模型如LSTM、Transformer或基于图的生成模型如GraphVAE、JT-VAE。分子性质预测用图神经网络GNN效果通常比指纹传统机器学习好但数据量少的时候随机森林反而更稳。蛋白质结构预测现在基本被AlphaFold系列统治但如果你做的是抗体设计可能还需要结合Rosetta或FoldX做能量计算。我们当时做小分子生成时对比了三种方案纯Transformer、JT-VAE、以及扩散模型。最后选了JT-VAE作为基线原因是它在保证生成分子有效性的同时计算资源消耗可控而且隐空间插值比较平滑方便做优化。扩散模型生成质量确实好但推理速度太慢一轮生成要等好几个小时不适合需要快速迭代的场景。3.2 模型迭代的完整流程与参数选择模型迭代不是调参那么简单而是一个完整的闭环。我们的流程是基线模型训练用清洗后的数据训练一个基线模型记录所有超参数和评估指标。主动学习循环用基线模型对未标注数据进行预测选出不确定性最高的样本比如预测方差最大的交给实验团队做验证。增量训练把新验证的数据加入训练集重新训练模型。这里要注意灾难性遗忘问题我们通常会用经验回放Experience Replay的方式在增量训练时混入一定比例的旧数据。模型评估除了常规的AUC、RMSE等指标还要看生成分子的多样性、新颖性、合成可及性SA score。SA score的计算可以用RDKit的sascorer模块。from rdkit.Chem import RDConfig import sys sys.path.append(RDConfig.RDContribDir /SA_Score) import sascorer sa_score sascorer.calculateScore(mol)参数选择方面学习率我们通常从1e-4开始用余弦退火调度。Batch size根据GPU显存来定一般尽量大一些梯度累积也可以。Dropout在数据量少的时候调到0.3到0.5数据量大了可以降到0.1。3.3 模型可解释性与药化团队的信任建立这是很多AI团队容易忽略的一点。你模型预测得再准如果药化团队不理解为什么他们就不敢用你的结果。我们当时做了两件事来建立信任一是用注意力机制可视化模型关注分子的哪些子结构二是对每个预测结果给出相似度最高的已知化合物作为参考。药化专家看到模型关注的是合理的药效团而且预测结果和已知类似物的活性趋势一致才会开始认真考虑这些分子。实操心得定期和药化团队开评审会让他们参与模型评估过程。我们每个月会选10个模型生成的分子让药化专家盲评然后对比模型评分和专家评分的一致性。这个做法不仅提升了信任度还帮我们发现了模型的一些系统性偏差。4. 干湿实验闭环AI预测和真实实验怎么对齐4.1 实验设计的基本原则AI native制药和传统制药最大的区别在于实验设计是数据驱动的。传统实验设计可能更依赖专家的经验直觉而AI native模式下实验的目的是最大化信息增益。具体来说每轮实验要优先测试那些模型最不确定的、或者对模型更新最有价值的化合物。我们用的是基于贝叶斯优化的实验设计方法每次选一批化合物通常20到50个保证覆盖不同的化学空间区域。实验类型也要分层设计。第一层是快速筛选用生化实验测活性成本低通量高。第二层是细胞实验验证细胞层面的活性。第三层是动物实验看药代和初步药效。每一层的数据都会反馈到模型里但权重不同。生化数据量大用来训练模型细胞和动物数据量少用来做迁移学习和验证。4.2 湿实验数据回传与模型更新实验数据回传的及时性和标准化程度直接影响迭代速度。我们的做法是实验完成后48小时内数据必须录入系统录入时自动触发数据清洗和标准化流程然后每周做一次模型增量更新。数据回传的格式要统一包括化合物ID、实验类型、实验条件、活性值、单位、操作人、日期等字段。模型更新时要注意新数据可能会引入分布偏移。比如某一批实验用了新的实验条件导致活性值整体偏高或偏低。这时候需要做批次效应校正常用的方法是用对照化合物的活性值做归一化。4.3 闭环迭代的节奏控制与资源分配闭环迭代的节奏很关键。太快了实验数据还没积累够就更新模型容易过拟合噪声太慢了模型更新滞后浪费实验资源。我们摸索下来的节奏是生化实验每两周一批每批50到100个化合物模型每四周做一次大的更新中间做一次小的微调。资源分配上大约60%的实验预算用于验证模型预测的化合物30%用于探索新的化学空间10%用于重复验证关键结果。注意不要把所有实验资源都押在模型预测最好的化合物上。我们曾经犯过这个错误结果发现模型在某个化学空间区域存在系统性偏差导致一批高预测活性的化合物实际活性都很差。后来调整策略每次实验都保留一定比例的随机化合物作为对照。5. 计算机化系统验证AI制药绕不过去的合规门槛5.1 为什么AI系统也需要验证制药行业的计算机化系统验证CSV是个硬性要求不管是传统IT系统还是AI模型只要你的输出会影响药品质量或患者安全就必须做验证。AI native制药公司的模型输出会直接影响化合物选择和实验设计所以必须纳入验证范围。验证的核心目的是证明系统是可靠的、可追溯的、且能持续满足预期用途。验证的级别取决于系统的风险等级。我们当时把系统分成了三类GxP关键系统直接影响临床样品或药品质量、GxP相关系统间接影响、非GxP系统。AI模型通常属于GxP相关系统需要做中等程度的验证。5.2 验证分级的具体操作验证分级不是拍脑袋决定的要有风险评估报告支撑。我们的操作步骤是系统清单梳理列出所有计算机化系统包括模型训练平台、数据管理系统、实验数据采集系统等。风险评估对每个系统评估其对患者安全、产品质量、数据完整性的影响。用FMEA失效模式与影响分析方法给每个系统打分。验证级别确定根据风险评分确定验证级别。高风险系统做完整验证IQ/OQ/PQ中等风险做简化验证低风险只做基本确认。验证文档编写包括验证计划、风险评估报告、测试脚本、测试报告、验证总结报告。AI模型的验证比较特殊因为模型会随着数据更新而变化。我们的做法是把模型训练流程和模型本身分开验证。训练流程验证一次确保流程可控模型每次更新后做性能确认确保满足预设的接受标准。5.3 验证过程中的常见坑最大的坑是把验证当成一次性任务。实际上验证是持续的过程尤其是AI模型每次更新都需要重新评估。另一个坑是验证文档和实际流程脱节写了一套做了一套。我们的做法是让实际操作的工程师参与验证文档的编写确保文档和操作一致。还有一个坑是过度验证。有些团队为了保险把所有系统都按最高级别验证结果耗费了大量资源。合理的做法是根据风险分级把资源集中在关键系统上。实操心得验证工作最好在系统设计阶段就介入而不是等系统建好了再补验证。我们在第二个项目里从需求阶段就开始写验证文档系统上线时验证也基本完成了节省了大量时间。6. 交付与管线推进从项目到产品的最后一公里6.1 交付物的标准化打包AI native制药项目的交付物不只是模型还包括数据集、训练脚本、评估报告、验证文档、以及候选化合物列表。这些交付物需要标准化打包方便后续团队接手。我们的标准交付包包括模型文件含权重和配置文件训练和推理代码含环境依赖文件数据集含数据字典和版本信息模型卡片Model Card记录模型用途、性能、局限性、使用建议验证文档包候选化合物列表含预测活性、合成路线建议、专利检索结果6.2 管线推进的关键决策点从项目交付到管线推进有几个关键决策点。第一个是候选化合物的选择不能只看预测活性还要综合考虑合成难度、专利空间、药代性质预测、毒性预测等。第二个是实验验证策略是先做小规模验证还是直接放大。第三个是资源投入决策决定是继续内部推进还是寻找合作方。我们当时的做法是建立一个打分卡对每个候选化合物从活性、选择性、合成可及性、专利风险、药代预测五个维度打分加权求和后排序。权重根据项目阶段调整早期偏重活性和合成可及性后期偏重药代和安全性。6.3 团队协作与知识管理AI native制药项目涉及算法、药化、生物、临床、注册等多个团队协作效率直接影响项目进度。我们用的工具组合是Notion做项目管理和文档协作GitLab做代码管理DVC做数据版本管理Slack做日常沟通。每周一次全员同步会每个团队用5分钟更新进展和阻塞项。知识管理方面我们要求每个实验、每次模型更新、每个决策都要有记录并且定期整理成内部知识库。这个习惯在人员流动时特别重要新人接手时能快速了解项目历史。7. 常见问题与排查技巧实录7.1 模型相关问题的排查思路问题现象可能原因排查方法解决方案模型预测活性普遍偏高训练数据存在选择偏差检查训练集中高活性化合物比例加入更多低活性数据做数据重采样生成分子多样性差模型模式崩溃计算生成分子的骨架多样性增加温度参数加入多样性正则项增量训练后旧任务性能下降灾难性遗忘对比新旧模型在旧测试集上的表现经验回放弹性权重巩固预测结果与实验差异大分布偏移检查新数据的化学空间分布批次效应校正重新训练7.2 实验相关问题的处理经验实验数据异常是最常见的问题。比如某一批化合物的活性值整体偏高可能是实验条件漂移。我们的排查流程是先检查对照化合物是否正常如果对照也偏高说明是系统性问题需要重新校准实验条件如果对照正常说明是个别化合物的问题检查化合物纯度或溶解性。另一个常见问题是化合物合成失败。AI生成的分子有时候合成难度很高CRO反馈合成失败。这时候需要分析失败原因是路线设计不合理还是反应条件不合适。我们通常会准备备选合成路线如果主路线失败可以快速切换。7.3 合规与验证问题的应对验证文档被审计挑战是常有的事。审计员通常会关注几个点验证范围是否覆盖了所有关键系统、风险评估是否有依据、测试用例是否充分、偏差处理是否规范。我们的应对策略是提前做内部审计模拟审计员的提问把可能的问题准备好答案。偏差处理是另一个容易出问题的地方。任何偏离验证方案的操作都要记录偏差并且做影响评估。我们见过一些团队为了省事偏差不记录或者记录不完整结果在正式审计时被开了观察项。8. 一些个人体会和后续可以扩展的方向这个流程跑下来我最大的体会是AI native制药的核心竞争力不在算法本身而在数据流转效率和实验闭环的速度。算法可以招人来做算力可以花钱买但数据质量和实验反馈速度是花钱买不来的需要长期积累和流程打磨。另外AI native不是把传统流程数字化就完事了而是要从根本上重新思考每个环节的必要性和顺序。比如传统流程里化合物筛选和活性测试是分开的但在AI native模式下这两个环节可以合并成一个主动学习循环实验设计直接由模型的不确定性驱动。后续如果要把这套流程进一步扩展我觉得有几个方向值得尝试一是把临床前数据也纳入模型训练做端到端的活性-药代-毒性联合预测二是引入自动化实验平台实现真正的干湿闭环自动化三是探索联邦学习在多中心数据合作中的应用解决数据孤岛问题。这些方向我们有些已经在做初步尝试有些还在规划阶段等有更多实际数据后再来分享。