摘要：为了解决这一问题，我们提出了LinkAlign，这是一种新颖的框架，可以通过系统地解决模式链接问题将现有基线模型有效适应于真实世界环境。我们的框架包括三个关键步骤：针对挑战1的多轮语义增强检索和无关信息隔离，以及针对挑战2的模式提取增强。我们在SPIDER和B

模式链接是实现Text-to-SQL任务中人类水平性能的关键瓶颈，特别是在真实世界的大规模多数据库场景中。解决模式链接面临两个主要挑战：

(1) 数据库检索 : 在多数据库设置中从大量模式池中选择正确的数据库，同时过滤掉无关的数据库。

(2) 模式项定位 : 准确识别大型冗余模式中的相关表和列以生成SQL。

为了解决这一问题，我们提出了LinkAlign，这是一种新颖的框架，可以通过系统地解决模式链接问题将现有基线模型有效适应于真实世界环境。我们的框架包括三个关键步骤：针对挑战1的多轮语义增强检索和无关信息隔离，以及针对挑战2的模式提取增强。我们在SPIDER和BIRD基准上评估了我们的方法在模式链接方面的性能，并在SPIDER 2.0-lite基准上评估了其将现有Text-to-SQL模型适应于真实世界环境的能力。实验结果表明，LinkAlign在多数据库设置中优于现有基线模型，展示了其有效性和鲁棒性。另一方面，我们的方法在不使用长链推理LLM的模型中排名最高。这项工作弥合了当前研究与真实场景之间的差距，提供了一个实用的、稳健且可扩展的模式链接解决方案。代码可在 获取。

图1：Spider 2.0-lite基准测试中各方法对比。我们的方法仅通过将LinkAlign应用于DIN-SQL基础模型，就在不使用长链思维推理大语言模型（LLM）的方法中取得了最高排名。

Text-to-SQL旨在使非专家用户能够通过自动将自然语言问题转换为准确的SQL查询来轻松检索数据。大型语言模型（LLMs）的最新进展显著提升了Text-to-SQL基准的表现 ，展示了它们在理解和生成SQL查询方面日益增长的能力。然而，尽管有这些进展，现有方法往往在真实应用中表现不佳，因为企业数据库通常包含大量的冗余模式和多数据库设置（例如本地SQLite和云BigQuery）。它在将现有的Text-to-SQL模型适应于大规模多数据库场景时遇到重大失败，这主要是由于 模式链接 ，即从大量数据库模式中识别必要的数据库模式（表和列）以响应用户查询 。这些失败的根本原因尚未被深入探讨，留下了一个应对真实世界Text-to-SQL任务的空白。

为了理解这些失败，我们进行了全面的错误分析，并得出结论，模式链接失败主要源于两大挑战。 挑战1 - 数据库检索： 如何在多数据库设置中从大型模式池中选择正确的数据库，同时过滤掉无关的数据库。现有研究通常忽视这个挑战，因为他们总是假设单数据库模式规模较小，可以直接输入模型进行高效处理。 挑战2 - 模式项定位： 如何从大型冗余模式中准确识别相关的表和列以生成SQL。检索后的阶段必须处理复杂的数据库模式，其中大量语义相似的表和列增加了忽略生成准确SQL查询所需的关键模式项的风险。

受这些因素的启发，我们提出了 LinkAlign ，一种针对大规模多数据库场景中的模式链接挑战的新型框架。具体来说，我们的框架包括三个主要步骤。为了解决挑战1，我们的方法首先集中在(1) 通过多轮语义对齐检索潜在数据库模式 。此步骤根据检索结果评估推断出缺失的模式元素，并重写查询以与缺失的数据库模式对齐。然后我们的方法集中在(2) 隔离无关的模式信息 以减少噪声。此步骤从一组候选数据库中筛选出最合适的数据库，最大限度地减少无关模式的干扰，并简化下游处理管道。为了解决挑战2，我们的方法致力于(3) 通过模式解析识别表和列以生成SQL 。此步骤通过引入先进的上下文学习技术和为LLM精心设计的提示，推动大规模数据库中模式链接的边界。为了平衡效率和准确性，我们为框架引入了两种不同的实现策略，即流水线模式和迭代模式。对于流水线模式，每个步骤使用一次LLM调用，特别适合于效率至关重要的场景。相比之下，迭代模式采用多轮多代理协作，优先考虑准确性，擅长处理复杂和模糊的查询，使其成为具有挑战性的Text-to-SQL任务的理想选择。

为了更好地评估模型的模式链接能力，我们构建了AmbiDB，这是Spider (俞等, 2018) 基准的一个变体，旨在模拟真实环境中文本到SQL的模糊性和复杂性。我们在SPIDER、BIRD (李等, 2024) 基准和我们提出的AmbiDB数据集上评估了我们方法的模式链接能力，并将其与现有的基线方法进行比较。实验结果表明，我们的方法在多数据库设置下所有指标上都达到了最先进的性能。此外，我们将LinkAlign应用于经典的DIN-SQL方法，并在SPIDER 2.0 (雷等, 2024) 基准上进行实验，以验证其在将现有基线模型适应于大规模多数据库场景中的有效性。图 的结果显示，LinkAlign在排除使用长链推理LLM的情况下排名最高。

为了更好地理解现有研究与真实环境之间的差距，我们从Spider数据集中随机抽取了500个样本，并分析了现有基线方法在Text-to-SQL任务中的常见错误类型。特别是，模型需要处理来自所有数据库的模式，而不是来自单个数据库的小规模模式，这更符合真实场景。结果显示，模式链接错误是Text-to-SQL失败的主要原因，错误率超过60%。为了更好地理解这些失败，我们手动检查了错误样本，并将四种常见的错误类型归因于引言中提出的两大挑战。附录 提供了更多结果细节。

错误1: 未检索到目标数据库（数据库检索）。 此错误表明检索结果不包括完整的实际数据库模式，占总失败的23.6%。例如，用户打算查询“硕士和学士都注册的学期”，但检索结果排除了目标数据库中的 degree_program 表，这需要基于查询语义和常识知识进行推断。然而，一般的向量化检索方法仅根据嵌入距离返回语义相似的结果，这与用户复杂查询常与实际模式不符的事实相冲突。

错误2: 引用了无关数据库（数据库检索）。 不同于专注于缺失目标数据库的错误1，错误2侧重于多数据库设置下不精确检索引入的无关数据库噪声。此错误表明模型在生成SQL时引用了来自无关数据库的错误模式，占总失败的13.3%。例如，用户希望查询“拥有猫和狗的学生的名字”。然而，生成的SQL错误地从无关数据库中推断出 People.first_name ，而忽略了实际的 Student.f_name ，尽管两者都被成功检索并输入到模型中。如果不隔离无关的数据库信息，模型倾向于错误地选择看似更合适的来自无关数据库的模式，从而导致SQL执行失败。

总之，错误1和错误2突显了现有方法与真实大规模多数据库场景之间的差距。即使避免了这些错误，SQL执行仍可能因其他模式链接错误而失败。

错误3: 链接到错误的表（模式项定位）。 此错误表明生成的SQL遗漏或误用了表，占总失败的19.8%。例如， student 和 people 表都有 name 字段，但模型错误地选择了后者。在真实场景中，模型经常忽略关键表，这直接影响生成SQL的执行准确性 (Maamari 等 2024) 。

错误4: 链接到错误的列（模式项定位）。 此错误表明生成的SQL尽管正确引用了实际表，但仍遗漏或误用了字段，占总失败的11.6%。例如，模型可能在正确的SQL语句中遗漏了连接列 pets.pet_id 和 has_pet.pet_id 。遗漏此类关键列直接导致SQL执行失败。

图2：LinkAlign框架概览，包含三大核心组件

本节介绍了用于模式链接的LinkAlign框架及其实施策略。我们的框架包括三个主要步骤，旨在应对大规模多数据库场景中的挑战。实施策略提供了两种互补的方法来执行这些步骤，平衡效率和准确性。

LinkAlign框架通过系统地解决模式链接挑战，可以有效适应现有模型到真实世界环境。该框架包括三个主要步骤，有助于缩小数据库模式并增强模式链接能力。

第一步：检索潜在数据库模式。为缓解错误1，我们提出了一种多轮语义增强检索方法。在此步骤中，使用LLM评估检索结果并根据推断出的缺失数据库模式重写输入查询。动态调整检索策略以与缺失的数据库模式语义对齐，能够在较少迭代次数内实现高检索性能。这种方法在检索批次有限和规模受限的场景中尤为有效。

重写的查询嵌入到向量中，然后用于检索相关的数据库模式。检索结果根据重写次数和相似度得分排序和汇总。通过重写查询并增强其语义表示，这种方法改进了用户查询与数据库模式之间的对齐，确保更准确的检索结果。

第二步：隔离无关的模式信息。为缓解错误2，我们尝试从检索到的多数据库结果中过滤掉无关的模式。一旦检索结果Z 包含来自无关数据库的模式，下一步就是精确定位目标数据库D_t ，同时过滤掉无关的模式。此组件旨在最小化外来模式的干扰，这些模式可能会模糊准确SQL查询的生成。通过专注于最合适的数据库，此步骤隔离了无关的模式信息，避免其被包含在后续操作中。这种过滤至关重要，因为无关的模式会不必要地扩展输入上下文，增加计算成本并降低SQL生成性能。通过仅选择目标数据库，框架确保模式链接专注于相关信息，从而提高准确性和效率。此外，我们的方法在单数据库设置中仍然有效，通过调整目标以过滤掉无关的数据库模式而非来自无关数据库的模式。

第三步：提取用于SQL生成的模式。为缓解错误3和4，我们需要识别用于SQL生成的正确表和列。此步骤模仿数据库模式提取的手动过程，但可以通过链式思维等推理技术自动化。与传统的Text-to-SQL方法不同，这些方法通常依赖静态映射，LinkAlign框架结合动态推理来处理复杂的模式链接场景。

本节重点介绍 多代理协作 策略，该策略优先考虑准确性，为解决现实世界环境中的复杂查询任务提供了充分的能力。

通过查询重写对齐语义。 受 Shinn 等 (2024) 讨论的LLM反射能力的启发，我们设计了一种由两步组成的语义增强检索方法：推断缺失模式和查询重写。具体来说，Schema Auditor首先评估检索结果，推断出生成准确SQL所需的缺失模式（例如SELECT/JOIN/WHERE字段），并以审计报告形式总结。接下来，Query Rewriter通过添加额外的语义信息丰富问题，以便更好地与推断出的缺失数据库模式对齐，最终提高检索准确性。

通过响应过滤减少噪音。 当多个候选数据库显示出细微差异时，通过多代理辩论达成共识显著减少了错误风险 (Chan 等 2023) 。受此启发，我们开发了一种由Data Analyst和Database Expert组成的多代理辩论模型。具体来说，Data Analyst从多个候选数据库中推断出最合适的数据库，Database Expert评估选择是否合理并决定是否保留。辩论遵循一对一策略，即从数据分析师开始，之后两位角色依次陈述观点。辩论在达到预定轮数后结束，然后由终结者输出共识数据库作为最终结果。

通过模式解析识别表和列。 为增强模式链接能力，我们基于Simultaneous-Talk-with-Summarizer策略开发了一种多代理辩论模型，即多个同行参与者同时参与辩论，最终结果由总结者评估。辩论涉及两个角色：Schema Parser和Data Scientist。在每一轮中，每个Schema Parser提取特定子句的数据库模式（例如JOIN/WHERE...字段），然后Data Scientist验证所有Schema Parser的结果，识别任何遗漏或错误。多角色参与增强了SQL生成所需的表和列的召回率，多样化的答案相互补充，减少了单提示输出的随机性。

多数据库上的结果. 如表 所示，我们的方法在SPIDER、BIRD和AmbiDB数据集上实现了最先进的定位精度(LA)，得分分别为86.4%、83.4%和69.4%，证明了框架在将数据需求映射到目标数据库方面的有效性。与基线方法不同，我们的框架引入了“通过响应过滤减少噪音”的步骤，过滤掉无关的数据库模式，减少了错误2并保持了高LA精度。此步骤还通过消除对相似候选模式的选择需求，使模型能够更准确地识别所需的表和列。实验结果证实了这一点：我们的框架在所有三个数据集上均实现了最先进的精确匹配（EM）性能，分别超过基线模型23.6%、1.8%和37.3%。在多数据库环境中存在错误1和2，使得模型难以避免混合无关模式，从而在准确召回相关表和列方面面临挑战。特别是随着数据库规模的增加，我们在AmbiDB数据集上观察到所有方法的召回率显著下降，进一步证明了我们提出的数据集加剧了这一挑战。

表1: 多数据库场景下不同方法在LA、EM和Recall指标上的对比

表2: 单数据库场景下不同方法在精确率（Precision）、召回率（Recall）和EM指标上的对比

单数据库上的结果. 我们进一步比较和评估了不同方法在大规模数据库中识别正确表和列的能力。如表 2所示，我们的Agent方法在所有数据集的EM评估指标上均实现了最先进的性能。在消除来自无关数据库模式的干扰后，所有方法的召回率相比表 1中的结果显著提高。与基线模型相比，Agent方法在Spider-dev和Bird-dev数据集上实现了最高的召回率。这表明当大规模模型的推理能力受到限制时，我们的方法表现出优越的性能和鲁棒性。尽管在AmbiDB数据集上，我们的方法召回率落后于MCS-SQL (88.5%) 和RSL-SQL (88.3%)，但在精确度上分别超出这些模型21.3%和7.4%。这表明我们的方法在保持高召回率的同时最大限度地减少了无关噪音。总体而言，考虑所有指标，我们的方法展示了卓越的性能和稳健的模式链接能力。

来源：鼠meme