点石成金：当AI开始批量阅读专利，化学反应数据库会变成什么样

先说一件挺离谱的事。

全世界有机化学反应的知识,有相当大一部分并不在教科书或者数据库里,而是散落在专利文档的文字、图片和反应式里。你想查一个反应"以前有没有人做过""用了什么条件""产率多少",大概率得自己去翻专利,一页一页找。专利文档里的信息还特别绕:一个具体实验的描述可能横跨好几个段落,某些化合物或操作只有结合"通用制备方法"和上下文交叉引用才能看懂。这种结构,人工整理起来极其痛苦,机器读起来也容易读错。

这就是DianShi-RxnDB（点石反应数据库）想解决的问题。它是上海人工智能实验室联合复旦大学、上海交通大学等机构做的一个超大规模有机反应数据平台,用全自动化的流水线,从美国专利商标局（USPTO）和欧洲专利局（EPO）的专利里,提取出了将近2400万条反应实例，其中1480万条通过了自动质检。这个数字放在整个行业里是什么概念,后面会讲。但先说一个更直接的感受:这不是又一个"更大的数据库",而是一次关于"怎么把知识从纸堆里榨出来"的系统性尝试。

专利里的化学知识,为什么这么难挖

有机合成是药物、材料、农药这些精细化学品研发的核心。一条有价值的反应记录,不能只写"A加B生成C",还得说清楚谁是反应物、谁是试剂催化剂、用了多少量、温度时间多少、产率多少、具体操作步骤是什么样的。这些信息支撑着反应预测、条件预测、逆合成路线设计这些AI4Chem（人工智能应用于化学领域的研究方向）的下游任务。

但现实是,这些细节往往分散在正文、反应式图片、表格、实验部分、支持信息里,要把它们拼起来才能形成一条完整记录。专利文档尤其麻烦:同一个实验的信息可能跨越多个段落、多个"实施例",有些化合物和操作只有结合通用步骤、上下文和文档内交叉引用才能准确理解。

这就好比你去看一份说明书,但说明书里写着"具体步骤参见第3章第2节",而第3章第2节又写着"参数取值同前述实施例2"。人类读者尚且要来回翻页才能拼凑出完整流程,让机器做到这一点,难度可想而知。如果不做这种细致的边界判断和上下文关联,直接把文本一股脑丢给模型抽取,那结果大概率是残缺的、错位的,甚至张冠李戴。

在DianShi-RxnDB出现之前,行业里已经有几个开放数据集,比如USPTO-Lowe（一个从1976到2016年美国专利中提取的约375万条反应数据集）、CJHIF、USPTO-LLM等。但它们普遍存在规模有限、专利覆盖时间短、缺乏溯源定位、字段信息不够细粒度等问题。商业数据库比如Pistachio、Reaxys、CAS Reactions信息更丰富，规模也更大（CAS Reactions号称有1.5亿条反应），但它们大多需要付费订阅，机器批量访问和系统集成也常常受限。

这就形成了一个尴尬的局面:开放的数据不够精细,精细的数据不开放。

从1580万篇专利到2400万条反应记录

DianShi-RxnDB的数据源来自Sciverse科学数据基础设施聚合的专利文档,最初的候选池有2025万多条专利记录,包含约1238万条USPTO记录和788万条EPO记录。这些记录经过基于国际专利分类号（IPC）的领域过滤、站内去重、跨站去重、全文可用性检查,层层筛选后,最终有158万篇专利文档进入了反应信息抽取流水线,其中约60.8万篇最终链接到了至少一条被保留的反应实例。

这个筛选过程,其实特别像一次大规模的"沙里淘金"。想象你面前堆着两千万份文件,大部分和你要找的东西完全无关(专利里也有大量非有机化学内容),你得先按照学科分类把不相关的筛掉,再把重复上传、重复公开的版本合并,再把美欧两边重叠的记录去重,最后还得确认这份文件到底有没有可读的全文。如果跳过这些步骤直接上手抽取,你会得到大量重复、无效甚至互相矛盾的"反应记录",数据库的可信度会大打折扣。

这个抽取流水线本身也值得说道。

流水线*：指从原始文档到结构化数据的一整套自动化处理流程,通常包含解析、识别、抽取、归一化等多个步骤。

它能解析专利的文本、图片和反应式,不需要人工逐条整理,自动识别出与有机合成实验相关的内容,把参与者、实验条件、产率、实验步骤、来源位置组织成结构化的反应实例。在具体技术选型上,团队用DeepSeek-V3-0324这个大语言模型处理专利实验文本,用MinerU.Chem解析图片和反应式中的化学信息,并且这套系统部署在华为昇腾910C AI处理器上,配合DeepLink做软硬件适配。

生成的每一条反应实例,还要经过一道"质检关"。

自动质检*：指用算法自动判断一条反应记录是否合格的过程。这里具体做法是用RXNMapper工具给反应生成原子映射,检查是否通过原子守恒等规则,通过的记录叫"合格实例"。

最终,2400万条反应实例里,1480万条(占比61.7%)通过了这道质检。没通过的那部分并没有被丢弃,依然保留着提取出的信息和溯源链接,只是没有拿到"合格"标签。这种设计其实挺聪明:与其把可能有问题的数据一刀切掉,不如标注清楚状态,让用户自己判断要不要用。

这套流水线跑出来的数据到底准不准,团队没有自说自话,而是找了一批有机化学专业背景的评审员,从140万合格实例里随机抽了1300条,对产率、反应物、试剂、催化剂、溶剂这五个字段逐条人工核对。结果是微平均字段准确率92.95%。细看各字段,催化剂字段准确率最高,达到97.31%,试剂字段最低,只有84.62%。为什么试剂容易出错?论文里给出的解释是,试剂和其他参与者角色的边界很依赖具体反应上下文,机器容易在"这个东西到底是反应物还是试剂"这类判断上犯迷糊。

这让我想起一个生活化的类比。判断一个原料在反应里究竟是"反应物"还是"试剂",有点像判断一个人在聚会上是"主角"还是"配角"。有些人身份很明确,一眼就能看出;但有些人,比如那个既帮忙布置场地又顺手参与了游戏的朋友,你很难简单归类。机器在处理这类模糊角色时,出错率自然更高。如果不做角色细分,把所有参与物质都堆在一起当"反应物质列表",看似省事,但会丢失大量关于反应机制的关键信息,比如哪个是真正驱动反应发生的核心物质,哪个只是辅助溶解或调节环境的配角。

除了试剂角色混淆,评审还发现了另外三类常见错误:后处理和纯化信息(比如干燥、淬灭、洗涤用的材料)有时被误记为试剂或溶剂;同一材料被重复提及时可能产生重复记录或角色分配错误;括号内或浓度表达式里的溶剂信息容易被遗漏,后面段落报告的产率也可能被漏抓;还有跨段落、跨实施例引用的内容解析不完整,多个反应步骤被误合并成一条记录。这些问题,团队明确列出来作为后续改进方向,而不是藏着掖着,这种坦诚本身也值得一提。

反应实例、反应组、反应模板:一套三层结构怎么支撑起溯源和比较

DianShi-RxnDB的核心组织单位叫"反应实例"（Reaction Instance）。

反应实例*：指从专利文档中提取出的一条具体、单步的反应记录,包含反应物产物结构、参与者角色、用量、温度时间、产率、实验步骤,并链接到来源专利和具体位置。

单看反应实例还不够,因为同一个反应(比如水杨酸加乙酸酐生成阿司匹林)可能在不同专利、不同实验条件下被反复报告过。为了让这些"同款反应,不同做法"的记录方便比较,数据库设计了"反应组"（Reaction Group）这个概念,按照归一化后的反应物-产物组合把多条反应实例聚在一起,但注意,它不会把这些记录合并成一条"平均记录",每条实例的试剂、催化剂、溶剂、条件、产率、来源信息都各自独立保留。

这个设计思路,类似于图书馆给同一本书的不同版本(精装版、平装版、不同出版社版本)建一个"作品条目",但每个版本各自的出版信息、页数、装帧细节都完整保留,不会因为归到同一个条目下就被抹平成一个"平均版本"。如果反应组直接把多条记录合并压缩成一条"综合数据",研究者就没法比较不同专利里报告的具体条件差异了,这恰恰是做反应对比研究时最需要的信息。

数据库还有一层更抽象的组织,叫"反应模板"（Reaction Template）。

反应模板*：用SMARTS(一种描述化学结构模式的语言)表示的局部结构转化规律,比具体的反应物产物组合更抽象。比如"酚羟基乙酰化"这种转化模式,可以对应许多具体的、反应物不同的实际反应。

数据库用LocalRetro和RDChiral两种方法分别生成了独立的模板集合,规模分别约119万和186万个。

再往下一层,是把"物质"和"来源专利"也纳入结构关系里。每个化学物质被组织成"物质记录"（Substance）,记录名称、分子式、分子量、SMILES等信息;每个来源专利被组织成"参考文献"（Reference）,记录专利标题、编号等元数据。物质和反应实例之间通过"反应参与者关系"连接,记录这个物质在这条反应里到底扮演反应物、产物、试剂、溶剂还是催化剂的角色。

这套物质、反应实例、反应组、反应模板、参考文献的五层结构,加起来才构成了数据库真正的骨架。截至目前的数据快照,数据库里有约626万个物质记录、约2400万条反应实例、约658万个反应组、约60.8万篇来源专利。这些数字对应的是不同层级的对象,不能简单相加成一个"总反应数"。

跟Pistachio硬碰硬:三个维度的外部对比

光自说自话不够,团队还专门找了商业数据库Pistachio做了一次外部对比,涉及三个维度:去重后的记录规模、信息组织粒度、字段级精确匹配率。

先看规模。Pistachio官方宣称约2100万条反应记录,DianShi-RxnDB约2400万条,单看这两个数字,DianShi-RxnDB似乎领先,但团队很诚实地指出,这两个总量数字口径不完全一致,不能直接拿来比。

于是他们做了一次更细致的实验:从两个数据库都有抽取结果的美国专利里随机选了100篇,统计所有相关反应记录,再用统一的反应物-产物匹配规则去重。这里有个值得展开的细节:Pistachio的数据分文本和图片两个通道提取,同一个专利里的同一个反应,可能在文本通道和图片通道里各生成一条记录,如果不去重直接相加,会造成"一个反应被算成两条"的虚高统计。团队专门举了个例子(专利US07795244),文本通道和图片通道提取出的反应物产物完全一致,只是中间的"试剂"部分表述不同,文本通道还带着完整段落原文,图片通道则把关键的碘化钠和丙酮都笼统归为"Agent"（宽泛试剂类别）。

这个去重逻辑,让我想到统计一个班级人数时,如果班主任花名册和体育老师花名册各自统计一遍再直接相加,肯定会把请假重复登记的学生算成两个人。必须先核对两份名单里是不是同一个人,才能得到真实人数。Pistachio的文本图片双通道如果不做这层去重,统计出的"反应总数"会明显虚高。

去重之后,DianShi-RxnDB从4222条降到4093条,Pistachio从3630条降到2992条,DianShi-RxnDB去重后的记录数是Pistachio的1.368倍。这个比例是这个抽样里的结果,团队也明确说了不能外推到全部数据。

第二个维度是信息组织粒度。团队挑了一个两边都记录了的共享反应案例(专利US10975080里的"中间体4"),逐字段对比两边暴露出来的信息颗粒度。结果显示,DianShi-RxnDB明确区分了试剂和催化剂角色,而Pistachio把两者笼统归入"Agent";DianShi-RxnDB有独立的反应阶段对象、专门的后处理字段、显式的验证诊断信息(比如SMILES置信度、原子缺失检查),这些在检视的Pistachio记录里都没有对应的独立字段。

第三个维度最关键,是字段级精确匹配率。团队从100篇专利里找出了660对"来源段落完全一致"的反应记录对(来自58篇专利),用GPT-5.6-sol做语义仲裁,建立了不依赖任何一方数据库、只依据原始专利文本的"源文本参照标准",然后分别检查Pistachio和DianShi-RxnDB与这个参照标准的精确匹配程度。

这套评估逻辑挺值得琢磨。它没有拿Pistachio当"标准答案"去检验DianShi-RxnDB对不对,而是两边都回到最原始的专利文本上,各自和这个"裁判"比对。这就好比两个学生都做同一道题,老师不拿其中一个学生的答案去判另一个学生的对错,而是拿标准答案分别判两份卷子。

结果是,DianShi-RxnDB在全部六个评估字段上都比Pistachio的匹配率高。差距最小的是产物字段,只高出0.75个百分点;差距最大的是产率字段,高出18.33个百分点(DianShi-RxnDB达到99.39%,Pistachio只有81.06%)。这个巨大差距的原因,论文里解释得很清楚:DianShi-RxnDB倾向于只记录源文本里明确写出的百分比数字,而Pistachio在文本没有明确给出百分比时,可能会用产物质量和化学计量比反推出一个产率值。在这次评估用的"源文本精确一致"标准下,这种反推出来的值不算作"明确百分比",于是被判定为不匹配。

两条给研究者和AI的路:网页工作台和MCP服务

数据打好了地基,接下来是怎么用起来。DianShi-RxnDB提供了两套互补的接口。

给研究者用的是"网页研究工作台"（Web research workbench）。它提供三个搜索入口:物质搜索支持按名称或分子结构查询,可以直接画结构式;反应搜索支持用反应SMILES或反应SMARTS查询,结果按反应实例和反应组两个粒度组织;文献搜索支持按专利号或标题摘要关键词查询。更重要的是,每条反应实例都能一键跳转回它在源专利里的具体段落或区域,研究者可以在同一个界面里左边看专利原文、右边看结构化数据,逐字核对。

给AI智能体用的是"MCP服务"。

MCP*：全称Model Context Protocol(模型上下文协议),是一种让AI智能体以标准化方式调用外部工具和数据的协议规范。

DianShi-RxnDB的MCP服务把物质检索、反应组检索、反应实例获取、来源文献查询这四类能力封装成可组合的结构化工具,支持AI智能体做多步查询。比如一次典型的"查找某个反应先例"任务,可以是这样的链路:先按目标产物检索候选反应组,从中定位到具体的反应物-产物组合,拿到对应的反应实例和实验信息,再查询来源文献,最后把结果整理成带出处的答案。

论文里用阿司匹林的经典合成反应(水杨酸+乙酸酐→阿司匹林)做了一个完整的案例演示。通过网页工作台搜索,能找到84条以阿司匹林为产物的反应实例,进一步定位到目标反应组,里面包含53条来自10篇专利的具体实例。团队挑了三条做对比:一条用硫酸作催化剂,50℃反应20分钟,产率70%;一条用SOMS(可膨胀有机改性硅胶)作试剂,二氯甲烷做溶剂,40℃,产率97%;还有一条用硫酸锆作催化剂,120℃反应30分钟,产率92-95%。团队还专门打开了第一条记录对应的源专利,核实里面确实写着"加入催化量的浓硫酸(5滴),50℃反应20分钟",和结构化记录完全吻合。

用MCP走同样的流程,AI智能体接到自然语言指令后,自动完成了"检索11个候选反应组→锁定1个目标反应组→确认组内53条实例→本次调用返回20条→查询对应来源文献"的完整链路,并且严格标注了哪些字段是数据库里没有返回的,不会用化学常识去"脑补"缺失信息。这种"缺失就是缺失,不装懂"的克制态度,在AI应用里其实并不常见,很多工具遇到信息缺口会倾向于生成一个看似合理但没有依据的答案,而这里选择了老老实实标记"未返回"。

这种设计选择背后,其实是对"可信"这件事的一种坚持。如果AI智能体在缺失字段时随意用化学直觉去填补,表面上答案更"完整"了,但一旦这个填补的数字被当成真实实验数据引用,后果可能是严重的。这就像医生开处方时,如果某项检查数据缺失,靠谱的做法是标注"待补充检查",而不是凭经验估一个数字写上去,哪怕经验通常是对的。

这些边界和局限,团队没有藏着

值得一提的是,论文用了整整一个章节讨论"数据和使用边界"。首先,数据覆盖范围是1976到2025年的USPTO和EPO专利,期刊文献和未发表的实验室知识不在范围内。其次,人工质量评估结果只适用于通过自动质检的合格实例群体,不能推广到未通过质检的实例,也不代表数据库的整体召回率。团队特别提醒,自动抽取仍可能出现字段遗漏、重复记录、角色错误、步骤边界错误,建议用户对关键记录自行核对源专利。

对于AI智能体的使用,团队也明确提示:结构化记录以及智能体对检索结果的组织和解读,都可能包含遗漏或错误,溯源链接提供了核查路径,但不能替代专业人士基于完整上下文的判断。涉及实验安全、临床或监管事项、专利评估、生产条件选择的场景,相关信息应由具备相应专业知识的人员进一步审核。

这种主动划定边界的做法,反而让人更信任这份工作。一个愿意告诉你"我们哪里可能出错"的工具,往往比一个只吹嘘"准确率多高"的工具更靠谱。

写在后面

读完这篇论文,最触动我的其实不是那个2400万的数字,而是团队处理"不完美数据"的方式。很多数据构建项目会本能地想把所有不合格的东西藏起来,只展示光鲜的部分。但这里的设计是,不合格的实例照样保留在数据库里,附带完整的提取信息和溯源链接,只是打上"未通过质检"的标签。这种选择背后其实是一种更成熟的数据观:与其追求虚假的100%完美,不如诚实地标注置信度,把判断权交还给使用者。

还有一个细节值得单独说一说。团队在做外部对比时,没有把Pistachio当成"标准答案"去检验自己,而是专门构建了一套完全独立于两个数据库、只基于原始专利文本的参照标准,让双方都去对照这套标准。这种"不预设自己更对"的评估设计,在很多同类研究里其实是缺失的,大部分对比研究默认某个既有权威数据库就是真理,自己的方法能接近它就算达标。这里反过来了,两边都被同等审视。

产率字段那18个百分点的差距也让我多想了一层。表面上看是"谁的抽取更准",但深挖下去,其实是两种不同的数据哲学:一种选择只记录文本里明确写出的数字,保守但可信;另一种在信息缺失时用化学计量反推补全,看起来更完整但掺入了推断成分。哪种更好,取决于你要拿这些数据做什么。如果是训练模型预测产率,你大概想要干净的、来源明确的真实数字,而不是被算法悄悄"美化"过的估计值。这或许是这篇论文留给我最值得反复咂摸的一个点:数据的"完整"和数据的"真实",有时候是两件需要权衡取舍的事,而不是理所当然可以兼得的东西。

Q&A

Q1：DianShi-RxnDB是什么？

A：DianShi-RxnDB(点石反应数据库)是上海人工智能实验室等机构联合开发的大规模有机反应数据平台,通过全自动化流水线从USPTO和EPO专利中提取了约2400万条反应实例,其中1480万条通过了自动质检,同时提供网页工作台和MCP服务两种接口供研究者和AI智能体使用。

Q2：DianShi-RxnDB和Pistachio相比有什么优势？

A：在外部对比测试中,DianShi-RxnDB在去重后记录规模上是Pistachio的1.368倍,信息组织粒度更细(比如明确区分试剂和催化剂角色),在反应物、试剂、催化剂、溶剂、产物、产率六个字段上与源文本参照标准的匹配率都更高,尤其产率字段高出18.33个百分点。

Q3：DianShi-RxnDB的数据准确率有多高？

A：团队从140万条合格反应实例中随机抽取1300条做人工核查,涵盖产率、反应物、试剂、催化剂、溶剂五个字段,微平均字段准确率为92.95%,其中催化剂字段准确率最高达97.31%,试剂字段最低为84.62%。