科研人不担心有机物命名不规范了Transformer开源工具自动起名

　　「有机化合物怎么命名啊？」、「有机化合物命名规则是什么？」、「这个药物的有效成分叫什么？」、「有没有查找有机化合物命名的软件或程序？」、「某某命名软件还花钱。」、「某软件命名不准确。」......
　　注：部分来自知乎问题。
　　总之，有机化合物命名太难、规则太繁琐、还没有开源软件......
　　AI 发展「风生水起」，能否解决以上问题？
　　现在，来自莫斯科罗蒙诺索夫国立大学和 Syntelly 初创公司的研究人员开发了 一种基于 Transformer 的人工神经方法，可根据 IUPAC 命名系统生成有机化合物的名称。
　　而且还开源，可在线使用。
　　我已迫不及待，进行了在线体验，在本文的「使用小攻略」部分。
　　项目地址：https://app.syntelly.com/smiles2iupac
　　IUPAC命名法是系统命名有机化合物的方法，在有机化学中发挥着重要作用。化学家通常手动创建 IUPAC 名称，但这个过程容易出错，需要对命名规则有深入的了解。计算机可缓解该问题。化学家可使用软件工具来生成名称。
　　然而， 目前还没有用于有机结构到名称翻译的开源工具。 与现有解决方案（如 ChemDraw JS 和 LexiChem TK）的许可协议需要特殊权限才能嵌入其他平台。
　　近日，来自莫斯科罗蒙诺索夫国立大学和 Syntelly 初创公司的研究人员开发了一种基于 Transformer 的人工神经方法，根据 IUPAC 命名系统生成有机化合物的名称。新的解决方案已经在Syntelly 平台上实现，并可在线使用。
　　该研究以《基于 Transformer 的人工神经网络，用于化学符号之间的转换》（  Transformer‑based artifcial neural networks for the conversion between chemical notations  ）为题，于 7 月 20 日 发表在《  Scientific Reports  》杂志上。
　　「最初，我们想为我们的 AI 化学平台 Syntelly 创建一个 IUPAC 名称生成器。很快我们意识到通过数字化 IUPAC 规则来创建算法需要一年多的时间，因此，我们决定利用我们在神经网络解决方案方面的经验，」该研究的主要作者， Syntelly 初创公司的联合创始人 Sergey Sosnin 说。
　　循环神经网络（RNN）和 Transformer 已成功用于自然语言翻译。研究人员 构建了一个基于 Transformer 的神经网络，可以将分子从 SMILES（简化分子线性输入规范） 表示转换为 IUPAC 名称，反之亦然。 描述了他们的解决方案，讨论了其方法的优缺点，并表明 Transformer 可以提供类似于人类化学直觉的东西。
　　研究结果表明： 将 SMILES 字符串转换为 IUPAC 名称的 Struct2IUPAC 模型在 PubChem 的测试集上达到了98.9% 的准确率。反向模型（IUPAC2Struct）达到了 99.1% 的准确率 ，与开源 OPSIN 软件（名称到结构转换的开源工具）相当。 方法
　　数据库： 深度学习技术需要大量数据。新网络使用 世界上最大的开放化学数据库 PubChem  进行训练和测试，包含 94,726,085个结构。把数据库分成两部分，一半用于训练，另一半用于测试。
　　IUPAC 和 SMILES 标记器： 标记化是将序列划分为块并划分这些块（标记）的过程。它是语言模型的常见预处理阶段。 使用基于字符的 SMILES 标记并实现了基于规则的 IUPAC 标记器。 该研究的 IUPAC 标记器是手动设计和管理的。标记器能够正确处理来自 PubChem 的 99% 以上的分子。
　　图示：SMILES 标记化（顶部）和 IUPAC 名称标记化（底部）的演示。（来源：论文）
　　Transformer 模型： 使用由 Google 团队设计的现代 神经架构 Transformer  ，这是谷歌最初设计的最强大的机器翻译神经网络之一，作为研究的基础，并训练它将分子的结构表示转换为 IUPAC 名称，反之亦然。
　　训练了两个模型： 将 SMILES 字符串转换为 IUPAC 名称的 Struct2IUPAC 和执行反向转换的IUPAC2Srtuct。基本上，不需要 IUPAC2Srtuct 模型，因为可以成功地使用开源 OPSIN。
　　图示：Struct2IUPAC Transformer模型。（来源：论文）
　　验证步骤： 使用 OPSIN，可以验证生成的化学名称，以确保这些名称对应于正确的结构。可以检测到生成器的故障并且不会显示错误的名称。
　　图示：验证步骤。（来源：论文）  模型的优缺点
　　优点1：Struct2IUPAC 模型准确率达 98.9%
　　为了验证模型的质量，研究人员从测试集中随机抽取了 100,000 个分子。SMILES 到 IUPAC 名称转换器以验证步骤运行， 在测试集中的 100,000 个随机分子的子集上实现了 98.9% 的准确度。
　　「我们已经证明，Transformer 可以精确解决算法问题，为软件开发提出了一个新范式。推翻了以前普遍认为不应该将它们用于此类问题的观念。在机器翻译中，用同义词替换一个单词是很有可能的，而在我们的任务中，一个错误的符号会导致一个错误的分子。然而，Transformer 成功地完成了这一任务。」Sosnin 补充道。
　　优点2：IUPAC2Struct 模型准确率达 99.1%
　　研究人员在测试集上将 IUPAC 与 SMILES Transformer 模型 (IUPAC2Struct) 与基于规则的工具 OPSIN 进行了比较（表 1）。 IUPAC2Struct 转换器实现了 99.1% 的准确率 ，OPSIN 执行了 99.4%。
　　表1：具有不同光束大小的 100, 000 分子测试集上模型的准确度 (%)。
　　缺点：
　　具有大量标记（寡聚体、肽等）的分子在我们的数据集中代表性不足， 这可能是此类 大分子性能下降 的一个原因。
　　尽管模型的准确度在非常大的分子上不超过 50%，但发现了一些有趣的复杂分子示例，这些示例正确生成了 IUPAC 名称。
　　图示：Transformer 生成正确名称的两个挑战分子示例。（来源：论文）
　　此外， 非常小分子的性能明显下降。 例如：甲烷，可能是 Transformer 使用了一种自注意力机制来分析输入序列中标记之间的相关性。对于超短序列，很难掌握 token 之间的关系。 在线可用
　　新的解决方案已经在 Syntelly 平台上实现，并可在线使用。研究人员希望他们的方法可以用于化学符号之间的转换，以及其他与技术符号相关的任务，例如数学公式的生成或软件程序的翻译。
　　研究人员表示：「 令人惊讶的是，我们基于神经的解决方案性能，可与基于规则的软件相媲美。 」 使用小攻略
　　在介绍之前，小声明一下：仅代表个人试用的感受，更专业的同学，应该会有更多的收获~
　　期刊论文提到「目前还没有用于结构到名称翻译的开源工具。」
　　首先， 打开在线开源网址：  https://app.syntelly.com/molecules/1  ，左侧菜单栏有很多功能选项，在这里选择「Inpidual」选项，点击搜索框，进入画板。输入需要命名的有机化合物结构，以甲苯（C7H8）为例。
　　点击「calculate」 ，即可得到甲苯的 SMILES：Cc1ccccc1，以及 IUPAC 名称：methylbenzene。
　　期刊论文里提到：「可以将分子从 SMILES 表示转换为 IUPAC 名称，反之亦然。」
　　在这里输入 SMILES/IUPAC，同样点击「calculate」，即可得到甲苯结构及其对应的 SMILES/IUPAC。
　　除此以外，该工具还自带超大数据集库。
　　还有收录的已发表的期刊论文中有机化学结构命名。当然还可以自行上传新论文 PDF。
　　还可预测化学反应：
　　更多功能解锁，小伙伴们自己 Get 吧~  有机化合物命名的历史
　　在有机化学的初级阶段，化合物的命名并没有共同的规则。 1919年国际纯粹与应用化学联合会（IUPAC）成立，IUPAC 出版有机化学命名法，俗称「蓝皮书」。 提供了有关化合物明确名称的指南。
　　现在有机结构有几种替代表示形式。 例如，简化分子线性输入规范（SMILES，Simplified molecular-input line-entry system）旨在为基于人类和基于计算机的化学信息处理提供便利。
　　过去，化学家手动创建 IUPAC 名称。 这个过程容易出错，因为它需要对命名法有深入的了解，且涉及复杂的算法。此外，化学家偏向于琐碎的名称，这对不同符号之间的正确转换构成了额外的挑战。计算机缓解了这个问题。现在化学家广泛使用软件工具来生成名称。
　　名称生成器的历史始于 Garfeld 的开创性工作。 然而，第一个面向化学家的日常软件是在 20 世纪末才创建和发布的。
　　现在，有几个用于生成 IUPAC 名称的商业程序： ACD/Labs、ChemDraw、Marvin、IMnova IUPAC Name 等。此外，还有一个框架 LexiChem TK 为某些编程语言提供应用程序编程接口 (API)。
　　然而， 没有用于有机结构到名称翻译的开源工具。 与现有解决方案（如 ChemDraw JS 和 LexiChem TK）的许可协议需要特殊权限才能嵌入其他平台。
　　研究人员表示：「我们相信，我们的方法适用于解决其他技术符号（或其他算法挑战）之间的转换问题，并希望我们的发现能在开发基于规则的解决方案成本高昂或耗时时突出解决问题的新方法。」