BiomedSQL：一个突破性文本转SQL框架，让生物医学研究者更轻松查询知识库

在现代生物医学研究领域，数据已成为驱动科学发现的关键引擎。来自美国国立卫生研究院老年病研究中心(NIA)、DataTecnica公司和约翰霍普金斯大学的研究团队，由Mathew J. Koretsky、Maya Willey、Adi Asija等人共同完成的这项创新研究，于2025年5月23日发表在arXiv预印本平台上（arXiv:2505.20321v1）。这项研究开发了一个名为BiomedSQL的文本转SQL框架，旨在解决生物医学研究者在查询大型结构化数据库时面临的挑战。有兴趣深入了解的读者可以通过论文提供的GitHub链接（https://github.com/NIH-CARD/biomedsql）和HuggingFace数据集链接（https://huggingface.co/datasets/NIH-CARD/BiomedSQL）获取完整资源。

想象一下，你是一位研究阿尔茨海默病的科学家，手头有大量基因组学数据和药物试验记录，但要从这些结构化数据中找到有价值的信息，你必须学会编写复杂的SQL查询语句。这就像你想从一个有成千上万册书的图书馆找到特定信息，但必须先学会图书馆的专门编目系统才能找到正确的书架。这个过程耗时且令人沮丧，特别是对那些专注于生物医学研究而非计算机科学的专家来说。

BiomedSQL正是为解决这一难题而生。它就像一位懂得生物医学专业知识的图书管理员，你可以用自然语言告诉它你想找什么信息，它会自动将你的请求转换为复杂的SQL查询语句，然后返回准确的结果。这样，研究人员就可以专注于科学问题本身，而不是被技术细节所困扰。

这项研究的独特之处在于，BiomedSQL不仅仅是一个简单的语言翻译工具，它还理解生物医学领域的专业知识和隐含规则。例如，当研究者问"哪些SNP与阿尔茨海默病显著相关？"时，系统知道"显著相关"在基因组研究中意味着p值小于5×10^-8这一统计阈值，而不需要研究者显式地指明这一点。

研究团队创建了一个包含68,000个问题-SQL查询-答案三元组的大型数据集，并将其连接到一个整合了基因-疾病关联、组学数据因果推断和药物批准记录的BigQuery知识库。通过这个基准数据集，他们评估了各种大型语言模型(LLM)在生物医学文本转SQL任务上的表现。

一、BiomedSQL的背景与意义

想象一下现代医学研究就像是在探索一片广袤的未知森林。研究人员们不断收集各种植物标本、土壤样本和气候数据，希望发现新的药用植物或了解生态系统的运作机制。这些收集来的数据量非常庞大，存储在各种结构化的数据库中——就像是一个个巨大的仓库，里面整齐地分类存放着成千上万的样本和记录。

这些"数据仓库"包括电子健康记录、高通量实验结果和大规模人群研究数据。研究人员需要从这些结构化数据中提取有用信息来支持他们的科学发现。然而，要从这些数据库中获取信息，传统上需要使用SQL（结构化查询语言）这种专门的计算机语言。这就像是要进入这些数据仓库，你必须先学会使用一套复杂的钥匙和地图系统。

当前的文本转SQL系统虽然能帮助用户将自然语言转换为SQL查询，但它们大多只关注语法层面的翻译，就像是机械地将英语翻译成法语，而不理解其中的文化背景和习惯表达。这些系统将问题结构映射到SQL模板，但不理解更深层次的领域知识。

在生物医学领域，这种抽象方法往往会失效。当专家问"哪些SNP与阿尔茨海默病最显著相关？"或"哪些已批准的药物靶向帕金森病中上调的基因？"这类问题时，他们依赖于隐含的科学约定，如统计显著性阈值、药物批准途径，以及跨多种组学数据的因果推断。这些领域特定的约定，如基因组显著性阈值、临床试验阶段筛选或效应大小解释，仅凭数据库结构是看不出来的。

虽然像SPIDER和BIRD这样的通用文本转SQL基准测试推动了该领域的发展，但它们并不评估复杂领域中所需的科学推理。同样，以电子健康记录为中心的基准测试强调时序逻辑或患者检索，但不专门测试科学推理能力。

BiomedSQL正是为填补这一空白而设计的。它是第一个专门评估生物医学领域SQL生成中科学推理能力的基准测试。这就像是设计了一个特殊的测试，不仅检验翻译员能否正确翻译单词和语法，还检验他们是否理解医学术语背后的专业知识和文化背景。

二、BiomedSQL的构建方法

构建BiomedSQL就像是打造一座连接两个世界的桥梁：一边是生物医学研究者使用的自然语言世界，另一边是计算机数据库理解的SQL语言世界。这座桥梁不仅要确保结构坚固（功能正确），还要对使用者友好（理解领域知识）。研究团队分三个阶段完成了这一宏伟工程。

首先，研究团队构建了一个多源关系数据库，就像是为这座桥梁打造坚实的地基。他们从可信的生物医学资源中抽取了十个核心表格，确保数据库覆盖面足够广，能够回答68,000个问题。所有数据经过预处理以保证一致性，并部署到BigQuery以便高效查询和公开复现。

主要数据来源包括OpenTargets平台，这是一个汇总基因-疾病-药物关联的平台，以及ChEMBL，一个手动维护的生物活性分子和药理学数据库。通过FTP获取OpenTargets数据并手动清理，而ChEMBL数据则通过Google BigQuery访问并通过扁平化嵌套字段进行标准化。这些数据源共同提供了基因-疾病链接、药物-靶点对、临床试验状态和药效动力学的统一模式。

为支持涉及统计遗传学的问题，他们包括了来自GWAS目录的阿尔茨海默病和帕金森病大规模GWAS研究的汇总统计数据。他们保留了SNP级别数据，包括p值、rsID、等位基因频率和最近基因映射。

团队还整合了来自omicSynth的因果推断数据，该数据应用基于汇总数据的孟德尔随机化(SMR)来识别与神经退行性疾病有潜在因果联系的多组学生物标志物。这些数据集使研究者能够推理那些没有直接陈述但通过统计推断的关联。

所有表格都被标准化并以Parquet格式上传到Google Cloud BigQuery。完整的模式和列表在论文附录A.1中提供。为支持未来扩展，他们还策划了额外的表格，扩展了BiomedSQL的覆盖范围到更广泛的组学和临床试验数据。

在第二阶段，就像是设计桥梁的蓝图，领域专家手动编写了黄金标准SQL查询。一位领域专家(MW)为从CARDBiomedBench抽取的40个种子问题手动编写了黄金标准SQL查询。每个查询都经过精心设计，检索回答问题所需的最小必要证据，避免使用SELECT *模式并将结果限制在100行以内。两名额外的分析师(MK, OB)审查了所有查询的语法正确性和语义保真度。

最后，在第三阶段，团队通过编程方式进行扩展，就像是用工业化方法大规模生产桥梁组件。他们将40个查询模板化，并使用实体替换自动扩展。他们将这些模板与CARDBiomedBench中完整的68,000个问答对对齐，通过编程方式将疾病、基因、SNP和化合物提及插入到查询模板中。所有生成的SQL查询都在BigQuery数据库上执行，以获取执行结果，作为评估LLM生成的SQL和自然语言答案的真实依据。

这个流程产生了一个基准测试，其中每个问答对都链接到一个可执行的SQL查询及其结果，使我们能够精确评估模型将科学问题转换为领域基础、语义有效且可执行的SQL逻辑的能力。

三、BiomedSQL数据集的特点与分析

BiomedSQL数据集就像是一个精心设计的健身房，专门用来锻炼和测试大型语言模型在生物医学领域的"SQL肌肉"。这个数据集不仅数量庞大，还涵盖了多种SQL操作类型和生物医学推理类别，让我们能全面评估模型的能力。

为了描述BiomedSQL的科学和计算复杂性，研究团队对所有68,000个问题-查询对进行了SQL操作类型和生物医学推理类别的注释。表1定义了SQL操作类别，图2a显示了它们的经验分布。较简单的操作（如Select、Order-By和Calculate）需要相对浅层的语法解析，LLM通常表现良好。相比之下，Multi-Filter、Threshold、Join和Similarity Search等操作难度更大，因为它们需要多步逻辑组合、隐式模式链接或基于模式的检索。

在SQL类别中，Select操作（检索特定列）占18.6%，Order-By（结果排序）占19.1%，而Multi-Filter（应用复合过滤逻辑）占12%。这些操作像是健身房中的不同器械，有些相对简单，有些则需要更高的技巧和协调能力。

为了探索科学推理能力，研究团队将BiomedSQL查询分为三类，反映了生物医学专家典型的认知过程：

第一类是操作隐含的科学约定。查询通常涉及领域特定的概念（如"显著相关的SNP"），这些概念暗示非显而易见的统计阈值，如GWAS命中的p < 5 × 10^-8或基于beta系数的方向性。这些约定在模式中很少明确，必须由模型推断。这就像是一位厨师知道"少许盐"大约是多少，而无需精确的测量工具。

第二类是整合缺失的上下文知识。专家经常整合辅助数据（如药物批准状态或临床试验阶段），即使问题中没有直接提及。例如，确定一种药物是否"获批"用于某种疾病需要消除特定适应症的临床试验阶段信息的歧义，而不仅仅依靠任何二元"获批"标志。这就像是一名医生在看到症状时会考虑患者的完整病史，而不仅仅是当前的抱怨。

第三类是执行复杂的多跳推理工作流。BiomedSQL中的许多问题需要在多个表格间链接关系操作。例如，"与帕金森病相关的基因在哪些组织中最显著表达？"需要在基因-疾病、基因-表达、组织注释和统计排名上进行四步推理。LLM往往难以将这种多跳逻辑转换为有效的、可执行的SQL。这就像是要求某人通过一系列复杂的公共交通换乘到达目的地，而不是简单的点对点旅行。

论文附录A.2（表6，图4）提供了额外的生物学推理类别和它们分布的可视化。这些包括批准状态（检索药物或适应症的FDA批准状态）、临床试验阶段、GWAS显著性、SMR显著性等多种类别，形成了一个全面的测试场景。

与其他近期的文本转SQL基准相比，BiomedSQL在四个方面独特：(1)它包含最大数量的问题-SQL-答案三元组，(2)它拥有一些最长的平均SQL查询（仅次于EHRSQL），(3)它明确针对科学推理而非模式翻译，以及(4)它同时评估生成的SQL和模型的自然语言响应。此外，BiomedSQL是唯一使用BigQuery（一种云原生SQL方言）的基准，进一步模拟了部署相关的环境。

这种设计让BiomedSQL成为一个全面的测试场，不仅考验模型的SQL生成能力，还考验它们对生物医学领域特定知识的理解和应用能力。就像是一场综合性的考试，不仅测试基础知识，还要求应用这些知识解决实际问题。

四、模型评估方法与实验设置

研究团队设计了一系列严格的实验，就像是为不同的运动员设计全面的体能测试，以评估大型语言模型（LLM）在将BiomedSQL中的生物医学自然语言问题转换为准确且可执行的BigQuery SQL查询方面的能力。这些实验不仅评估了SQL执行准确性，还评估了生成的自然语言答案的质量。

在评估的模型方面，研究团队选择了一系列最先进的开源和专有LLM。开源模型包括LLaMA-3.1（70B和405B参数版本）和Qwen-2.5-Coder（14B和32B参数版本）。专有模型包括GPT系列（GPT-4o、GPT-4o-mini、GPT-o3-mini）、Claude-3.7-sonnet和Gemini-2.0-flash系列（flash和flash-lite）。这种选择涵盖了多种参数规模、计算成本配置和架构设计理念，就像是测试不同类型和体格的运动员。

在实验设置方面，研究团队首先评估了模型在单轮文本转SQL设置中的表现。每个模型收到一个基线提示，包含： - 基准问题：一个生物医学自然语言查询 - 数据库架构：表格、列和关系的描述 - 指令：关于如何构建SQL查询并与数据库架构保持一致的简单指南

为了研究提示敏感性，研究团队在几个方面变化提示结构： - 添加示例表行（3行、5行） - 添加少样本示例（1样本、3样本、5样本） - 添加显式领域特定指令（如通过stat-instruct提供统计阈值） - 组合变体，包括3行、3样本和stat-instruct（combo）

除了单轮提示外，研究团队还研究了允许迭代推理和查询优化的多轮交互范式。这些系统可以请求架构细节、提出中间查询，并在呈现最终SQL查询前更新它们的方法。研究团队实验了三种架构变体：

第一种是ReAct，一种提示编排方法，其中架构验证、语法检查和其他外部工具在多轮SQL生成步骤中被调用。这就像是一位有经验的教练实时给运动员提供反馈，让他们能够在过程中调整技术。

第二种是架构索引，使用LlamaIndex动态检索架构描述，以支持上下文基础和表格选择。这就像是给运动员提供一本可以随时查阅的参考手册，帮助他们了解不同器械的使用方法。

第三种是多轮查询优化，研究团队实现了一个迭代文本转SQL架构，称为BMSQL，其中初始查询通过基于中间结果或执行错误的反馈循环进行优化，模拟专家级的优化过程。这就像是运动员根据每次尝试的结果不断调整他们的技术，直到达到最佳表现。

每种范式都使用GPT和Gemini模型进行评估，以测量它们在不同架构中的有效性。

在评估指标方面，研究团队报告了三个SQL性能指标：执行准确率（EX）、Jaccard指数（JAC）和语法错误率（SER）。

执行准确率是一个广泛使用的文本转SQL指标，表示评估集中问题的比例，对于这些问题，LLM生成的查询和地面真实查询返回相同的结果。研究团队调整了EX以测量行级集合相等性，比较返回的UUID集合（对于SELECT *查询）或返回的数值集合（对于COUNT和其他计算查询）。

Jaccard指数，或交集与并集的比值，是一个用于衡量两个集合相似度的指标。它告诉我们LLM生成的SQL查询结果与地面真实结果有多接近。与EX不同，JAC会对返回略多或略少行的查询仍给予部分分数，使其成为一个更宽容的指标。

语法错误率简单地表示评估集中问题的比例，对于这些问题，LLM生成的SQL查询在数据库上不可执行。

为了评估自然语言响应，研究团队采用了BioScore，一个使用GPT-4o作为评判的LLM-as-a-judge指标。BioScore包括： - 响应质量率（RQR）：事实正确答案的比例，测量模型提供正确答案的频率 - 安全率（SR）：在所有不正确或放弃的答案中放弃的比例，评估模型在不确定时放弃回答的能力

所有指标定义和提示都在附录A.6中提供。SQL和BioScore指标之间的相关性分析在附录A.7中。

作为基线，两位专家生物医学分析师（CA和NK）回答了一个代表性问题样本测验。对于每个问题，他们生成SQL查询、执行结果和自然语言答案。研究团队报告了平均EX、JAC和RQR。由于专家不能放弃回答且在所有情况下都产生了有效的SQL，所以SR和SER对这种格式不可用。

五、实验结果与分析

实验结果揭示了一个明显的现象：即使是最先进的大语言模型在处理生物医学文本转SQL任务时，也存在显著的科学推理挑战。这就像是即使训练有素的翻译员在处理高度专业化的医学文献时也会遇到困难，因为这需要领域知识而非仅仅语言技能。

在基线实验中，表现最好的模型GPT-o3-mini的执行准确率（EX）为53.5%，Jaccard指数（JAC）为60.4%，响应质量率（RQR）为73.3%，但这与领域专家的表现（90-95%）相比仍有很大差距。GPT-4o的表现略低，EX为46.9%，JAC为54.7%，RQR为71.2%。在开源模型中，尽管参数量较小，Qwen-2.5-Coder-32B达到了有竞争力的EX（40.8%），而Qwen-14B达到了较强的RQR（62.1%），表现优于参数量远大于它们的Llama模型。Claude-3.7-sonnet展示了最佳的SR（43.0%），表明它具有更好的放弃行为，即在不确定时选择不回答。

提示变化实验显示，组合提示（combo）为GPT-o3-mini提供了最佳改进（EX增加5.5%，JAC增加5.7%，RQR增加4.5%）。然而，这些收益以近3倍的token使用为代价，表明成本效益有限。仅传递原始表行显示效益可忽略，强调模式级理解比内容记忆更重要。

在交互范式实验中，架构索引在EX和RQR方面表现不佳，可能是因为它使用简单的表描述和轻量级基础。然而，它展示了最佳的SR（例如，Index-GPT-4o为66.9%），表明它在不确定时有效地放弃。ReAct略微改善了GPT变体的EX，但并非在所有模型中都一致。这表明ReAct风格的提示可能需要针对不同模型的性能进行调整。此外，它的高token使用使其在部署中不太实用。

研究团队的定制系统BMSQL是整体表现最佳的。GPT-o3-mini与BMSQL的组合达到了62.6%的EX和69.2%的JAC，均为同类最佳。与Gemini配对时，BMSQL达到了84.6%的RQR，甚至在答案质量上接近领域专家。然而，执行准确率仍然显著低于专家基准。这些结果强调了领域特定多步代理在结构化生物医学任务中的价值。

为了更好地理解模型行为，研究团队分析了不同SQL任务类型的性能，并评估了增加推理时间计算的效果。图3展示了雷达图，显示了SQL类别的执行准确率（EX）和响应质量率（RQR）分布。研究团队评估了GPT-o3-mini在四种设置下的表现：基线提示、组合提示、ReAct提示和BMSQL。

对于EX，不同提示策略之间的SQL类别性能保持相对稳定。正如预期的那样，模型在Join、Similarity Search和Multi-Filter查询上最为困难，这些需要多表推理、隐式过滤或模糊匹配，都是当前LLM的挑战。令人惊讶的是，Select查询也显示中等水平的性能；然而，这个类别包括BiomedSQL中的大部分问题，所以均值水平的性能是预期的。

对于RQR，BMSQL在各类别中展示了最平衡的性能，可能是因为它能够：(i)应用领域特定指令（如p值阈值、试验状态），(ii)比较有阈值和无阈值的结果，(iii)通过执行反馈优化查询。这强化了多步管道在生物医学推理中的好处。

研究团队还评估了模型性能如何随着推理时间计算的增加而变化。具体来说，他们允许BMSQL-GPT-o3-mini检查其初始SQL查询、执行结果和答案，然后选择执行最多两个额外的传递，如果输出看起来不充分。

表5的结果显示，增加推理步骤只产生轻微收益。从1次传递到3次传递，EX保持相对稳定（62.6%→61.7%），而RQR略有增加（83.1%→85.5%）。SR的改善和语法错误的消除（SER=0.0%）表明大多数校正涉及修复语法或在适当时放弃，而不是显著重新制定查询逻辑。值得注意的是，BMSQL很少选择调用第三次传递，这反映在2次传递和3次传递设置之间的小幅token增加中。

这些结果表明，虽然定制的多步骤代理如BMSQL能够显著提高性能，但当前的LLM在科学推理任务上仍然面临挑战，即使给予额外的推理时间也只能获得有限的改进。这突显了未来研究的机会，特别是在增强模型对领域特定知识和推理能力方面。

六、讨论与局限性

在任何研究中，了解其局限性和讨论潜在的问题都是科学诚实的重要部分。研究团队在论文中讨论了几个值得注意的点，这些点有助于我们更全面地理解BiomedSQL的价值和限制。

首先，研究团队承认SQL查询可以有多种有效解决方案。虽然BiomedSQL中的黄金SQL查询是由领域专家撰写并由分析师独立验证的，但它们并不代表检索相关数据的唯一正确方式。生物医学问题通常允许多种语义有效的表述，例如，使用替代连接、过滤器或聚合。为了解决这一点，研究团队使用了多种指标的组合，包括基于执行的（EX、JAC）和LLM判断的响应质量（RQR），以更稳健地反映现实世界的答案效用。

其次，研究团队没有评估通用领域文本转SQL系统的性能，如DIN-SQL、DAIL-SQL或CHESS。这些系统与BIRD和SPIDER等特定基准紧密耦合，并且依赖于特定于数据集的语法约束、数据库格式或解析假设，这些与BiomedSQL的模式和BigQuery SQL方言不兼容。未来的工作可以调整这些架构以适应BiomedSQL，特别是在将基准与其特定于云的执行环境解耦后。

第三，虽然依赖云特定方言如BigQuery SQL可能限制与先前工作的直接可比性，但研究团队认为这是一个重要的设计决策。云原生SQL方言在生产系统中越来越普遍，特别是在生物医学信息学管道中。在这种环境中评估LLM引入了新的挑战，包括供应商特定功能、语法和查询规划，这些在研究社区中目前未被充分探索。为支持更广泛的可再现性，研究团队也计划发布BiomedSQL的SQLite兼容版本。

最后，研究团队不预见任何负面社会风险。BiomedSQL由公共、非可识别数据构建，旨在提高LLM支持生物医学发现的能力，特别是为非技术研究人员查询结构化数据。

这些讨论点增强了我们对BiomedSQL的贡献和限制的理解，强调了它作为评估生物医学领域文本转SQL系统科学推理能力的有价值工具的潜力。

七、结论与未来展望

BiomedSQL代表了生物医学文本转SQL研究领域的一个重要里程碑。就像是为医学研究建立了一座新的桥梁，让研究人员能够更轻松地从复杂的数据库中获取有价值的见解，而不必掌握SQL编程的技术细节。

研究团队展示了即使是最先进的大型语言模型在处理需要专业领域知识的文本转SQL任务时仍面临显著挑战。最佳模型GPT-o3-mini与BMSQL架构的组合达到了62.6%的执行准确率，但这与领域专家90%的表现相比仍有很大差距。这个差距突显了目前AI系统在处理高度专业化、需要深厚背景知识的任务时的局限性。

BiomedSQL的关键贡献在于提供了第一个专门设计用于评估生物医学领域SQL生成过程中科学推理能力的大规模基准测试。通过聚焦隐含的领域约定、多步推理和结构化生物医学数据，这个基准测试突显了当前系统的关键限制，并为未来研究提供了严格的测试平台。

研究团队认为，这个基准测试是朝着构建更具能力、更值得信任的文本转SQL系统迈出的关键一步，这些系统可以扩大生物医学知识的获取范围，并为各学科的研究人员加速发现。未来的研究方向可能包括：

1. 开发专门针对生物医学领域知识的预训练或微调策略，帮助模型更好地理解领域特定的术语和概念。 2. 探索更高效的多步推理框架，能够处理复杂的生物医学查询，而不显著增加计算成本。 3. 整合更多的结构化知识库和本体论，帮助模型理解生物医学概念之间的关系。 4. 开发更好的评估方法，能够捕捉到模型理解和应用科学概念的细微差别。

总的来说，BiomedSQL不仅是一个评估工具，也是促进生物医学自然语言处理和数据库查询之间更紧密集成的催化剂。随着这一领域的发展，我们可以期待看到更智能、更具领域意识的系统出现，这些系统将大大简化生物医学研究人员从大型数据集中提取有价值见解的过程，最终加速科学发现和医疗进步。