企业官网建设流程全解析

本文收录于专栏化学大模型—— 专栏系统覆盖化学大模型的原理、评测与工程落地，点击订阅可跟踪后续更新。

你在用 LLM 搭化学 agent，让模型输出一个分子结构，结果 SMILES 字符串三天两头解析失败、括号不配平、环编号乱飞。这篇解读牛津统计系 Runcie 等人的 arXiv 论文（2605.01822）：78,045 道题、224,055 条模型响应、4 个前沿模型，系统比较 6 种分子表示格式——SELFIES 和 InChI 直接出局，显式列出原子和键的 MolJSON 在翻译（92.3%）、图推理（98.5%）、约束生成（95.3%）三类任务上全面胜出，且模型从未在它上面训练过。文中给出三种格式的选型决策表、pip 包 4 行上手法、8 分子 round-trip 实测、token 成本账单（输入贵 23 倍、推理省 1.8 倍），以及 MiniMax-M3 迷你复现与本地 12–14B 小模型对照实测（全灭——MolJSON 的收益目前只在 API 级模型上兑现）。读完你能直接判断自己的管线该不该换格式、该换输入端还是输出端。

关键字：MolJSON；SMILES；化学大模型；分子表示；结构化输出；IUPAC；RDKit；约束生成

目录：§0. 相关教程与核心文献 ｜ §1. 痛点：LLM 写不对 SMILES ｜ §2. 六格式横评 ｜ §3. MolJSON 的设计 ｜ §4. 三大任务结果 ｜ §5. 本机实测 ｜ §6. 局限与选型 ｜ §7. 结语

§0. 相关教程与核心文献

§1. 痛点：LLM 读得懂分子，写不对字符串

如果你在搭化学相关的 LLM 应用——结构解析助手、逆合成 agent、性质预测管线——大概率踩过这个坑：让模型"输出一个分子"，它给你的 SMILES 字符串里环闭合数字对不上、括号层级错乱，RDKit 一解析就抛异常。

这不是你 prompt 写得不好。牛津团队这篇论文把问题量化了：同样的分子理解能力，换一种输出格式，准确率可以从 64% 跳到 95.3%——差距比换一档模型还大。

分子本质是图（原子=节点、键=边），而 LLM 是序列模型，必须把图"拍扁"成文本。问题就在于：SMILES 靠遍历顺序、IUPAC 靠命名规则，这两套系统都是为人和传统化学软件设计的，不是为 LLM 设计的。给 LLM 一串Cn1c(=O)c2c(ncn2C)n(C)c1=O，它得先在心里把字符串还原成分子图才能开始推理——这个"解码"环节本身就会出错，还白白烧掉大量推理 token。

§2. 六格式横评：SELFIES 和 InChI 直接出局

论文先用 420 个分子做了 6 种格式的双向互译（GPT-5-mini，12,600 条提示），第一轮就把两个"理论派"选手淘汰了：

剩下的 SMILES、IUPAC、MolJSON 进入主赛程：9,201 个分子（PubChem 2025 年 10–12 月新入库的分子，在 GPT-5 发布后上传，降低训练污染风险）的双向翻译，共 55,206 条提示。

§3. MolJSON 的设计：把"解码"这一步省掉

MolJSON 的思路直接到近乎粗暴：分子图就是"原子列表 + 键列表"，那就原样告诉模型，别让人家从字符串里猜。

本机实测（moljson 0.1.0 + RDKit），乙酸的转换输出与论文 Figure 1 完全一致：

fromrdkitimportChemfrommoljsonimportMolToJSON,MolFromJSON,CheckRoundTrip mol=Chem.MolFromSmiles("CC(=O)O")print(MolToJSON(mol))

输出：

{'atoms':[{'id':'C1','element':'C'},{'id':'C2','element':'C'},{'id':'O1','element':'O'},{'id':'O2','element':'O'}],'bonds':[{'source':'C1','target':'C2','order':1.0},{'source':'C2','target':'O1','order':2.0},{'source':'C2','target':'O2','order':1.0}]}

设计上有四个关键点：

• 原子 ID 唯一即可，顺序无关——分子身份由原子和键的集合决定，规避了 SMILES 对遍历顺序的依赖
• 隐式氢——绝大多数氢按标准化合价规则推断，只有芳香氮上的氢需要用aromatic_n_h字段显式记录（本机实测吡咯c1c[nH]cc1正确触发{'atom_id': 'N1', 'hcount': 1}）
• 稀疏电荷表——charges字段只记录非零形式电荷（本机实测带电荷的吡唑鎓分子正确生成formal_charge: 1）
• 天然适配结构化输出——MolJSON 本身就是一个 JSON Schema，可以直接塞进 OpenAI/Anthropic API 的结构化输出模式，让模型只能输出合法结构，语法层面就锁死了

最后一点其实是隐藏大杀器。本机复现时我故意不开 schema 约束、让 MiniMax-M3 自由生成，它把原子 ID 写成了裸整数{"id": 1}而不是字符串，官方解析器MolFromJSON直接拒收——没有 schema 强制，连"id 必须是字符串"这种细节都会翻车；开了结构化输出，这类错误从机制上就不存在。

§4. 三大任务：MolJSON 赢在哪，赢多少

论文用三类任务把"输入能力"和"输出能力"拆开测，全部模型开结构化输出、低推理努力档。

任务一：双向翻译（输入+输出联合）。GPT-5 的核心数字：SMILES→MolJSON92.3%，而 SMILES→IUPAC 只有 43.5%；IUPAC→MolJSON71.0%，而 IUPAC→SMILES 只有 43.7%。规律清晰得刺眼：决定准确率的是输出格式——模型从 SMILES/IUPAC 里"读出"分子的能力其实不差，瓶颈在"写出来"。翻译到 MolJSON 的准确率约为翻译到 SMILES/IUPAC 的 1.6–2.1 倍。

任务二：最短路径推理（输入格式单独测，2,919 个含两个卤素的分子）。MolJSON 是全部模型的最佳输入格式，还更省推理 token：

（数据为论文附录 Table 4，±95% CI 略。）MolJSON 是"预解码"的，模型可以直接在图上做搜索，推理 token 约为 SMILES 的 1/1.8。

任务三：约束生成（输出格式单独测，494 组"含 F/Cl/Br 各一个、路径长度、环数环拓扑"约束）。GPT-5：SMILES 64.0%、IUPAC 76.3%、MolJSON95.3%。

按环拓扑分层后差异更夸张（论文 Table 6）：

双环稠环体系上，GPT-5 用 SMILES 生成只有 41.5%，IUPAC 56.4%，MolJSON 91.5%——复杂拓扑上优势翻倍。GPT-5-nano 这种小模型更惨：双环任务用 SMILES/IUPAC 输出时准确率不足 1.4%，换 MolJSON 能到 13.8–19%。

稠环同时是 IUPAC 的死穴：最短路径任务中，GPT-5 读 IUPAC 在无稠环分子上 96.9%，遇到稠环崩到 66.2%；而 MolJSON 两种情况下都是 98.5%，纹丝不动。

还有一个耐人寻味的发现：模型写 MolJSON 时可以自选原子 ID。输入是 SMILES 时，GPT-5 生成的 ID 基本是a1, a2, a3式的朴素编号；输入是 IUPAC 名称时，22.1% 的 ID 变成了C_acyl、O_carb这种带化学语义的官能团标签。作者推测这些"富 ID"实际上是模型思维链里的"图 token"——它在边推理边给原子贴标签。这提示了一个方向：如果训练 LLM 用显式图表示来"思考"，提升的可能不只是翻译准确率。

§5. 本机实测：pip 四行上手，round-trip 全过，但 token 贵 23 倍

官方 PyPI 包一行装好（依赖只有 RDKit）：

pipinstallmoljson# 0.1.0, BSD-3-Clause, Python >=3.10

本机实测（Linux，RDKit 2024.3.5）：乙酸、苯甲酸、萘、咖啡因、螺环、布洛芬、阿司匹林、二甲双胍、金刚烷等 8 个分子CheckRoundTrip（SMILES→MolJSON→SMILES）8/8 全部通过。

但 MolJSON 有一个论文里没强调的代价——输入侧体积膨胀。本机用 tiktoken（o200k_base）实测：

8 个分子合计，MolJSON 输入是 SMILES 的22.9 倍 token（字符数 35.9–53.3 倍）。账单要两头算：输入 token 贵 23 倍，推理 token 省 1.8 倍——对"重推理"任务（路径搜索、约束生成）可能净赚，对"轻任务大批量"（如大规模库过滤）输入成本会实打实上升。

顺手用 MiniMax-M3 做了迷你复现（3 个双卤素分子 × 2 格式 + 3 个翻译题，非推理模式，样本小仅作演示）：最短路径题两种格式打平（各 2/3，小样本噪声水平）；翻译题完美复刻论文方向——SMILES→MolJSON 两题全对（萘、含芳香 NH 的吡咯，连aromatic_n_h字段都正确触发），反向 MolJSON→SMILES 的咖啡因却写错。"MolJSON 好写、SMILES 难产"这个结论，在一个从未为 MolJSON 训练过的国产模型上也成立。

本地小模型是另一个故事（消费级 GPU 上 Ollama 实测）。用本机 deepseek-r1:14b（64k 版）和 gemma3:12b 跑同一套题：gemma3 最短路径 0/6，r1 路径 0/4、翻译 0/4——全灭。错误模式和论文里 SMILES 的失败方式如出一辙：r1 把萘写成C1C2C3C4C5C6C7C8C9C10C1C4C9这种荒谬长链，把吡咯（c1c[nH]cc1）写成吡啶（c1ccncc1，NH 直接丢了）；gemma3 则每个题只生成 7–12 个 token 纯粹瞎猜数字。速度也不实用：r1 单题思维链 500–1500 token（约 6 token/s），一道题 1.5–7 分钟，萘的路径题想了 600 秒没想完超时。对照论文里 GPT-5-nano（最小的 API 模型）在双环拓扑上 SMILES 输出也只有 <1.4% 准确率，本地 12–14B 级模型能力还在其之下——MolJSON 的收益目前只在 API 级前沿模型上兑现，本地小模型做分子结构任务，换什么格式都救不了。

§6. 局限与选型：什么场景该换，什么场景别动

论文自己坦承的边界：只测了翻译/路径/约束生成三类基础任务，没有上反应预测、性质预测等真实下游；MolJSON 当前版本不含立体化学、原子坐标、多组分体系；schema 本身也只是起点（键用 source/target 还是二元素列表、氢是否全部显式列出，都有讨论空间）。另外注意一点：实验由 OpenAI 提供 API 额度，评测以 GPT-5 系列为主，Claude Haiku 4.5 只跑了 420 分子的小集（趋势一致）。

我的选型建议：

§7. 结语

这篇论文的价值不在于又发明了一个格式，而在于用 78,045 道题系统回答了一个早就该问的问题：我们一直默认 SMILES 是"自然选择"，但它是为计算效率设计的，不是为 LLM 设计的。当你的 agent 下一次因为 SMILES 括号错乱而解析失败时，值得想起这组数字：换个格式，比换个更大的模型，便宜得多也有效得多。

MolJSON 本身未必是终局——作者自己也说 schema 还有一堆可改的地方。但它证明了一件事：让 LLM"直接看到"分子图，而不是从字符串里"恢复"分子图，这种输入表示与内部推理的对齐，是化学大模型一个被低估的杠杆。

参考来源

1. Runcie N T, Imrie F, Deane C M.Molecular Representations for Large Language Models. arXiv:2605.01822 (2026). https://arxiv.org/abs/2605.01822
2. MolJSON schema 与脚本：https://github.com/oxpig/MolJSON；评测数据：https://github.com/oxpig/MolJSON-data；PyPI：https://pypi.org/project/moljson/
3. Runcie N T, Deane C M, Imrie F.Assessing the Chemical Intelligence of Large Language Models. J. Chem. Inf. Model. 66(1):216–227 (2026). 10.1021/acs.jcim.5c02145
4. Weininger D.SMILES, a chemical language and information system. J. Chem. Inf. Comput. Sci. 28(1):31–36 (1988). 10.1021/ci00057a005
5. Krenn M 等.SELFIES: A 100% robust molecular string representation. Mach. Learn.: Sci. Technol. 1(4):045024 (2020). 10.1088/2632-2153/aba947

本机实测环境：Linux，Python 3.11（conda），RDKit 2024.3.5，moljson 0.1.0，tiktoken o200k_base；LLM 复现用 MiniMax-M3 直连 API（非推理模式），全部脚本与输出为真实运行记录。

系列导航：专栏全集化学大模型

我的专栏