戈登贝尔奖获得者张林峰：「AI + Science」的路径思考，突破科学边界、解决困难问题，做一个牧羊少年
作者简介 01   02 路径：如何让愿景成真？
【谁是主角】 这个阶段的算法和软件开发只需要几个人的投入。 但值得注意的是，作为用户的各领域专家也是我们协同开发的主体。用户-深度用户-开发者的体系也在这个过程中潜移默化地形成了。 阶段二：自动化产生模型与数据 【干了什么】 在模型和代码被逐渐验证的过程中，新的命题出现了：如何有效产生数据？ 引用DP回顾性文章中的段落： 「 」 【效果是什么】 去中心化的交叉验证是一个积累信心的过程。 作为结果，大家考虑的点逐渐由“搞波数据、训个模型、做个应用、发个paper”，变成了“怎样能一劳永逸地用DP模型替代已有模型做我关心的体系”、“我关心的哪些领域难题可能可以被DP有效解决”等。 更重要的是，这么一个看似简单的流程将不同尺度上做不同模拟、用不同软件的人都聚在了一起。例如，在第一性原理计算这个环节有十多个电子结构软件，核心开发者显然不会熟悉所有软件。于是，社区中熟悉不同软件且有用DP-GEN需求的人很自然地就成为了相应功能的开发者和维护者。 【难点在哪里】 做DP-GEN的过程第一次让一帮算法开发者和做各方向应用的科学家们感受到了工程化的困难。 DP-GEN的算法想法很简单，甚至学界呆惯了的人很容易不把它当回事。但它却有极为丰富的适配领域的变种，且作为一个循环迭代式的工作流，它在不同环节对算力规模、弹性的需求还不一样。 这对我们抽象问题、定义接口的能力、弹性调度的能力、过程管理的能力都提出了挑战，这事实上也让学界的用户很难驾驭。这是不同领域人员协同的放大版。我们至今尚未能有信心地发布v1.0版本。 【谁是主角】 在这个过程中，领域专家变得越来越重要，他们是定义问题的人，也是验证模型、做深入应用的人。 同时，更多工程化的主角呼之欲出。我也认清了核心开发者的一个新角色：做不同群体之间的桥梁。 做不同群体之间的桥梁，图源：网络 阶段三：工程化——规模工程、数据工程、性能工程 这个阶段要做的事情已经逐渐明晰，但工程难度可谓越来越高。很多是我们在进行中、且迫切需要有工程经验的小伙伴支持的。我相信，对DP来说，这是眼下最具有挑战性、也最激动人心的事情。 我把工程化需求简要总结为三类：规模工程、数据工程、性能工程。这个分类未必是最好的，这里只是为了方便抛出问题。 【规模工程】 这部分写给做云基础设施、AI后台支持的朋友们！DP-GEN这样的科学计算工作流有怎样的特点？它与CV/NLP等场景的active learning有点像，但最大的不同是，它实现了数据标注和模型训练的计算闭环，这里没有数据标注工！ 这是一个循环式的工作流，在资源无限、理想调度能力下的典型模式是需要几块GPU花几个小时训练，接着需要更多GPU做各种条件下的模拟演绎，然后需要近万核CPU机器做电子结构计算。 但是，在有限、类型单一的资源，特别是科学计算一般依托的超算集群上，这个过程很难高效。以下我回答两个问题。 问题一，以前为什么这样的需求不够典型？DP-GEN对应的是云上面向计算的弹性调度需求。科学计算本身是很大的需求，但是传统的需求类型主要还是大规模高并行的高性能集群。近年来高通量计算也很火，但计算类型偏简单、也不是持续性大规模的需求。AI+Science看起来是把高并行的高性能计算特点和高并发的云计算特点所代表的两个极端的中间地带填满了，而且填的很均匀。未来类似逻辑的工作流将越来越多。 问题二，用云不挺好吗？是的，我们发现了！从20年初开始，学界常用的高性能集群已经满足不了我们对DP Library（见下面“模型数据工程”部分）发展的诉求了。我们走上了上云之路。这个过程中，我们很感谢阿里云的支持。但与此同时，我们也意识到，当时的我们所代表的科学计算群体跟云计算基础设施还是不太匹配的。事实表明，这里面的gap还是得靠我们自己来填补。这么摸爬滚打的半年后，我们发现自己节省了巨大的成本，开心的不得了。再往后，“云原生”突然也成为了我们身边非常热的话题。 有了这样的经历，我们逐渐认识到面向计算密集流程的云基础设施是科学计算群体的公共需求。像DP-GEN这样的模型生产、数据采样的工作流将填满从微观到宏观的各个尺度，而有了模型和计算引擎后，更多性质计算和与实验交互的工作流才开始对这个基础设施真正提出挑战：从几千台机器的并发算力到逐渐几万、几十万的需求；从规范的建立到为开发者提供框架、组件、SDK。对于日志、容灾等一系列在业界有过很多实践的话题，我们也有很多新的特点和需求。 这是“AI+Science”从创新到落地所不得不做的事情，我们需要对这件事感到激动的高手们的帮助！篇幅所限，我也挖个坑，把更多内容留给未来的一篇文章，总结与小伙伴们的探索和实践。 最后，更多性质计算和与实验交互的工作流设计是一个眼下的困难。前阵子我们想借用一些已有框架来做好基础设施，然后向社区呼吁这件事。但是，我们发现自己低估了这件事的难度。没有更多实践，我们也很难抽象。因此，我们目前不得不再提前向社区呼吁这件事情的重要性，同时积累经验。在最近举办的首届DeepModeling Hackathon里面，我们惊喜地发现，有几个相关项目还是做的挺不错的。 【数据工程】 这部分写给做AI算法工程、模型工程的朋友们！先说这个事是什么，再说这个事难在哪，再说为什么现在是好时候。 这个事情很直观。设想五年后，对于每一个科学问题的研究、每一个材料/药物设计的需求，人们还会从用DP-GEN产生模型、数据开始吗？AI在很多领域的发展告诉我们，大数据和基于大数据产生的大模型，和小数据、小模型的玩法不一样。
图源：网络 基于海量数据发展的预训练模型，将为下一步迁移、压缩、反向设计等工作提供新的基础。我们会搜数据库，看有没有直接满足需求的数据集；即便没有，我们也可以从已有数据和预训练模型出发，做进一步的优化。预训练的特征还可以帮助我们迁移到新的任务中，或者结合实验进一步改进模型。 为了这件事情，我们一直在努力建设DP Library，将DP训练数据和模型收集在一起。 这个事情难在哪？难在领域跨度。 上述第二阶段的领域专家和这里的模型工程所需要的专长非常不同。我们既要吸收GNN、attention这些新的招式，又要快速地在各个场景中通过一个个测试应用验证这些新的想法是否好使。 这里面的“各个”所代表的生物、化学、材料等方向的场景需求方也往往是语言不通的。这也造成DP Library里面很多关于数据、模型质量的metric都很难确定。如果再加上其他各个尺度的需求，肉眼可见这会是未来发展的瓶颈。 为什么现在是好时候？两点原因。 首先，做AI算法工程的朋友们渐渐开始关注科学计算领域了。DeepMind的alphafold2是个极端情况，但不得不说，像数据、模型和领域发展契合度那么好的话题真的不多（第一阶段的DP也算一个）。我看到很多做AI算法工程的朋友将自己在CV/NLP等领域积累的聪明才智应用于小分子homo-lumo gap、催化剂设计等打榜比赛的问题上，既兴奋又郁闷。兴奋于大家渐渐开始关注、了解、学习这方面的问题，郁闷于我觉得搞定那些比赛——特别是为小数点后几位的事情排个一二三名——的意义有限。因为这样产生的模型跟领域专家的应用需求间有差距。我们需要一个模型工程师和行业专家的无缝交互接口。 所以，我这里的第二点原因是，我们想清楚并即将准备好这个接口了：一个大数据集和一套测试接口。数据上，DP Library即将初具规模，数据丰富度即将有一个质变。测试上，自动测试还是不够的，但社区里的行业专家们积累了非常多的测试基准，我们也形成了很好的连接桥梁。自动化的模型工程和测试流程只是一个时间问题，有经验的AI算法工程师将大大加速这个时间阶段。这是一个行业萌芽的起点！ 【性能工程】 这部分写给做高性能计算、软硬件协同设计的朋友们！ 对DP稍微了解的同学可能知道去年的一个大新闻，深度势能团队喜获戈登贝尔奖。这个奖是高性能计算领域的最高奖。那篇新闻稿是我提前一个月写好的。 其实在奖项还没有公布的时候，我们准备了DP进入奖项final list的新闻稿。但我们犹豫了很久，还是没发这个稿。当时我们认定，不管有没有拿奖，都在奖项公布的第一时刻把我们最想说的话说出来： 「 」 现在，我们更加地坚定了这一点。
《深度势能团队喜获戈登贝尔奖》这篇稿件最想说的是： 又经过快一年的时间，我们也有了更多的思考。 即便对于DeePMD-kit这样走在最前面的“AI+Science”项目，我们也还有很长的路要走。 已经有很多直接的工作发生在戈登贝尔奖之后了：
此外，社区中一系列新玩法也呼吁着一些新方案，例如DP和经典力场结合的分区域描述方法可能需要较好的动态负载均衡。 未来有两件事将相伴相生，但也挑战重重： 首先，算法端，既然模型工程是一路向前的，那么性能工程也得是紧密跟随的。分布式训练、更丰富的模型压缩蒸馏技术可能会成为下一步高性能优化的重点。 其次，硬件端，正如AI的发展最终走向AI芯片一样，随着算法的固化和应用场景的丰富化，软硬件协同设计可能是不得不做的事情。这件事可能不属于当下，因为我们对算法、对已有硬件平台、对最合适的中间框架的探索都还没收敛。但是这件事很可能在不远的将来。 想想Anton吧，那是21世纪初上一代分子动力学技术在生物体系上逐渐收敛后的最终产物。从08年，到14年，再到今年，Anton分子动力学专用机即将有3代。但是，随着算法端和应用端的剧烈变化，未来的Anton会不会适配、怎样适配新的需求？按照Anton release的速度，这些事情可能在五六年后就要见分晓了。这真是激动人心的事情。 最后，说起性能工程，总有人问我对量子计算怎么看。我推荐下我写的这篇文章吧。一句话总结，我无比地拥抱量子计算的可能性，只不过我拥抱的方式是在当下压榨经典方案的极限，为未来做好准备。 阶段四：面向产业场景的迭代演绎 这个阶段与第二、三个阶段会有overlap。从产业场景需求出发，有很多事情需要提前做好准备。 随着第二、三阶段的推进，越来越多的可能性正在被我们打开。例如，药物对靶点的亲和力会不会因此算的更准？对电池正负极界面的动力学模拟会不会因此成为可能？我们期待的答案是“是的”，但我们需要做的远不止实现这几个功能。 这依旧是个接口设计和方案迭代的漫长过程。 我们的原则是，尽可能地实现最快、最大范围的迭代。对于药物设计行业，计算机辅助药物设计已经有了上一代成熟的解决方案和较为广泛的行业认知，所以我们做了SaaS（Software as a Service）化的药物设计平台Hermite，从而实现与从业人员的交互迭代；对于材料设计行业，新能源材料设计刚刚涌现出旺盛的需求，但没有像药物那样相对成熟的计算-实验交互实践，因此我们与需求最大的厂商做最直接的合作。 面向产业场景需求对算法和软件工程人员来说是一件有一点点痛苦的事情，因为这里面的话语体系不一样。但是，这条路只要趟通，就会变得十分有趣。对技术人员来说，这归根结底会是一系列与模型优化、性质计算、数据处理、实验相关的工作流设计问题。在开源社区积累的算法软件和算力基础设施上的实践经验具有可复用性。 面向产业场景需求，最令我激动的莫过于实践过程中一个个真实的问题将倒逼我们一路回归到理论算法和算力的底层基础，激发新一轮的创新。这个在药物自由能计算、材料缺陷性质计算等场景已经是在发生的事情了。 03 对AI+Science发展路径的思考 用较长的篇幅回顾和展望DP项目的发展后，我们也试着总结和展望下整个AI+Science事业的发展之路。DP项目的发展是点动成线的过程。其他各个尺度的工具也会经历这个过程。我有几个思考：
发展路径，图源：网络 1. 早期发展阶段。从真实需求出发往往是十分必要的：无论是算法发展驱动的需求、算力适配驱动的需求、还是场景落地驱动的需求。每个科学计算软件的开发都是不小的工程，每个开发者和用户真正想做的事不见得一致。但是，当他们想做的事都指向同样的一个眼下必须解决的问题时，这个问题就会成为真痛点问题。 大家往往在解决真痛点问题时才会同时迸发出战斗力和创造力。这需要每个项目有鲜明的目标定位和拥有强大自驱力的核心开发者。如果目标定位不够鲜明，就很难吸引“志同道合”的用户和社区开发者；如果自驱力不够强大，那么很多看似完不成但伟大的事情就没有完成的可能了。这里我还是想大声呼吁：这个痛点需求不是发文章、不是KPI！ 2. 去中心的规模化验证。如果开发者定义的痛点照顾到了很大一部分群体的需求，使得这部分群体人员能够克服使用新工具的迁移成本尝试起来，那么相应的工具就走上了发展的快车道。这个时候最需要建立的，是开发者与各方向领域专家之间的桥梁。
3. 工程化。在这里，规模工程、数据工程、性能工程依旧缺一不可。回想DP相应的挑战是上一步“规模化验证”和这一步的工程化的专家背景往往相去甚远。但是，我们再回想下像有限元这样的例子，一系列底层方法的工程化，不都是杰出的工程师们在巨大的需求下做到的事情吗？随着场景需求的指数级增加，AI+Science这波热潮在迎来工程化的同时，也会对相应知识体系产生大的冲击。 尤记得一位业界大佬说：“无论哪件事，只要程序员群体扑上去，它的门槛一定会降下来。”因为我相信AI+Science必将影响到人们的科研范式和工业体系，所以我相信，各个尺度的工具都将经历这个工程化的过程。 在各个尺度工具都有长足发展的同时，它们的组合也将更为有力地影响到它们的上下游。归根结底我们走在一条打造新一代基础设施的路上。 我们要做的要么是用数据改进模型，要么是基于模型的进一步控制或设计。AI给了我们模型函数和策略函数的表示及优化能力。云将使得算力像电力一样，让做计算的人聚焦到计算的结果上；一系列不同尺度上的自动微分编程框架、高性能适配框架等的需求会革新现有的一切科学计算软件；基于新引擎、实现不同目的的工作流将串联起所有新的可能性。 到那一天，新一代工业设计系统与数字孪生，还只是可能吗？ AI+Science意味着新的数学工具串联起更多物理模型的有效求解，这意味着工具层的颠覆！朋友们，还有比现在更好的机会吗？ 04 不对称性与不确定性 最后我们谈谈协同问题。 在AI+Science这项事业中，不光是物理问题面临着“维度灾难”，软、硬件工程与在此基础之上的商业模型也面临“维度灾难”。 或许更本质的是，在这个鼓励个体差异化、信息快速传递、关系错综复杂的世界里，面向某个愿景的有效协同模式都面临着巨大的“维度灾难”。所谓的组织架构和协同模式的设计对应到微观个体，也就像设计原子间相互作用的模型。不过这个模型的优化不能放在监督学习的框架内。它更像是在定义好组织愿景、洞察好个人激励后的强化学习问题。
信息不对称，图源：网络 这里面的不对称性和不确定性意味着什么？在很长时间里我一直觉得信息不对称是一个组织最需要解决的问题。想想这蛮有道理，信息差太多、信息流不通往往是组织走向无效的起点。 然而，信息对称就解决问题了吗？把所有信息广播给所有人是不是有效的？比信息不对称更难的问题是认知不对称。信息像是数据，而认知像是处理器。信息的产生、传播、接收、解读是需要时间和能量的。 有相同知识背景的人可以通过很不花时间且很低能量的方式进行协同，但当大家认知不对称时，“信息对称”也就变成了“你以为的信息对称”。 举个例子，在很长一段时间里，我知道我们需要最优秀的工程师、需要最优秀的药物、材料设计的从业人员，但我需要懂他们的语言才能有效传递我想向他们传递的信息，才能让他们产生兴趣。其实我们基本不可能对所有事情都实现“认知对称”（那会是拥有脑机接口后的人类的未来吗？），但我觉得只要对“认知对称”这个概念有足够深刻的认知对称，一个组织中每个个体就能真正有效地处理信息，知道在不同情况下如何处理信息，是自己私下处理，还是发起局域讨论，还是拉响全局警报。也只有这样，一个组织的个体之间才能相互欣赏各自的闪光点、和而不同、产生有效碰撞。 AI+Science是我看到的涉及学科最多的一项事业。理论基础需要数理化，工程沉淀需要计算机，与各个应用领域走向数字孪生的未来需要各行各业深刻的实践。这里面需要有经济学的头脑、政治学的智慧，需要有对商业本质和长期价值的思考。 我不由得感慨，那个更广义的AI是不是能把这些事情处理的更漂亮。我不知道这个问题的答案，但我很清楚的是，这是一个打破认知不对称的过程，这是一个突破个体认知边界、解放个体生产力的过程，这是一个重构知识体系、重构协同方式、磨合每个个体间交互接口的过程。 这个过程也是一个充满不确定性的过程。一个伟大的愿景往往具有两个特点，一个是伟大，另一个是实现难度极高。 这里有一个算法的不确定性、工程化的不确定性、商业化的不确定性，这里有一切外部因素带来的不确定性。 对此，似乎最应景的是我在深势科技半年会上分享的标题：“如果你的反应不是退缩，而是激动”，哈哈哈。 在此处不如推荐一本名为《正见》的书，并摘录其中的一段话： 「 ......恐惧和焦虑是人类心智中主要的心理状态。恐惧的背后是对确定性不断的渴求。我们对未知感到恐惧。人心对肯定的渴望，是根植于我们对无常的恐惧。 当你能够觉察不确定性，当你确信这些相关联的成分不可能保持恒常与不变时，就能生起无畏之心。 你会发现，自己真正能准备好面对最坏的状况，同时又能容许最好的发生。你会变得高贵而庄严。这种特质能增强你的能力，不论是在工作、作战、谈和、组织家庭，或是在享受爱和情感关系。 知道下个转弯处就有某件事等着你，接受从此刻起有无限的可能存在，你将学会运用遍在的觉性和预见的能力，如同英明的将军一般，胸有成竹，毫不惊慌。 」 05 总 结 在今年5月6号我们发表的《DeepModeling社区宣言》中，首段写道： 「 机器学习与物理建模的结合正在改变着科学研究的范式。那些希望通过计算建模突破科学边界、解决困难问题的人们正在以前所未有的新方式集结起来。他们需要新的基础设施——新的协作平台，新的代码框架，新的数据处理手段，新的算力使用方式；他们需要新的文化——追求通力协作、惠及大众；追求知识与工具的自由交流与分享；追求尊重并欣赏相互的成就、和而不同。DeepModeling社区是这样的一群人的社区。 」 对过去几年实践的思考让我对“基础设施”的构想变得更为具象。而对不对称性和不确定性的思考，则让我更深刻地认识到我们需要怎样的文化。
拥抱开放，拥抱当下，拥抱不确定性。从颠覆工具层、到惠及全人类，如果你的反应不是退缩，而是激动，那么AI+Science的事业很可能适合你、我们很可能适合一起做一个牧羊少年。 |
