RDKit中MolToInchiKey函数版本间差异问题分析

问题背景

在化学信息学领域，RDKit是一个广泛使用的开源工具包，用于处理分子结构和化学反应。其中，MolToInchiKey函数用于将分子结构转换为InChIKey（国际化学标识符哈希键），这是化学结构中非常重要的唯一标识符。

近期有用户发现，在RDKit不同版本间，对于某些特殊分子结构，MolToInchiKey函数生成的InChIKey存在不一致的情况。这种差异主要出现在2024.03.2到2024.03.3版本升级过程中。

问题重现

以简单分子"C=[At]"（含有一个碳原子和一个砹原子的双键结构）为例：

from rdkit import Chem
print(Chem.MolToInchiKey(Chem.MolFromSmiles("C=[At]", sanitize=False)))

在RDKit 2023.09.1版本中输出为：

FPQJPOVNMNOCOT-UHFFFAOYSA-N

而在RDKit 2024.03.5版本中输出为：

AZYOCFZZNKPCCR-UHFFFAOYSA-N

原因分析

经过深入调查，发现这种差异源于RDKit内部对InChI生成逻辑的一个bug修复。在2024.03.3版本中，修复了关于InChI代码调用方式的问题。

关键点在于，早期版本在处理某些特殊价态原子时，会错误地计算分子式。以前述"C=[At]"分子为例：

• 修复前版本生成的InChI为：InChI=1S/CH3At/c1-2/h2H,1H2

  • 分子式错误地计算为CH3At（多了一个氢原子）

• 修复后版本生成的InChI为：InChI=1S/CH2At/c1-2/h1H2

  • 正确反映了分子式CH2At
  • 同时给出了价态警告："Accepted unusual valence(s): At(2)"

技术影响

1. 化学准确性：修复后的版本能更准确地反映分子的实际组成和结构，特别是对于含有不常见价态元素的分子。

2. 向后兼容性：这种修复虽然提高了准确性，但确实导致了不同版本间InChIKey的不一致。对于依赖InChIKey作为持久标识符的应用，需要考虑版本差异带来的影响。

3. 价态处理：RDKit现在能更好地处理非常规价态，如示例中砹原子的二价状态，并会给出明确的警告信息。

建议与解决方案

对于需要保持InChIKey一致性的应用场景，开发者可以考虑以下方案：

1. 版本锁定：在关键应用中锁定RDKit版本，确保所有环境使用相同的算法版本。

2. 数据迁移：如果必须升级版本，可以考虑对历史数据进行批量重新计算和迁移。

3. 自定义处理：对于特定分子类型，可以开发预处理逻辑来确保一致的输出。

总结

RDKit作为活跃开发的开源项目，会不断改进算法和修复问题。这次InChIKey生成的变更反映了项目对化学准确性的追求。开发者在使用这类工具时，应当关注版本更新日志，特别是涉及核心功能如分子标识符生成的变更，以便及时调整应用逻辑。

对于化学信息学应用来说，分子标识符的一致性至关重要。这次事件也提醒我们，在开发涉及化学结构处理的系统时，需要考虑算法版本可能带来的影响，并建立相应的版本管理和数据迁移策略。