微软说：NL2SQL是一个远未解决的问题！

快乐的打字员

已于 2024-04-08 23:10:47 修改

阅读量970

点赞数

分类专栏：分享文章标签： NL2SQL NLP

于 2024-04-07 17:00:22 首次发布

原文链接：https://www.cidrdb.org/cidr2024/papers/p74-floratou.pdf

版权

分享专栏收录该内容

19 篇文章

订阅专栏

NL2SQL是一个已解决的问题？不！

摘要

大型语言模型（LLM）的兴起极大地影响了数据库自然语言（NL）接口的发展，它提供了一种将 NL 查询自动转换为结构化 SQL 查询的简单方法。虽然 LLM 带来了有价值的技术进步，但本文强调，实现企业级 NL2SQL 还远未得到解决，需要在各个领域进行广泛的新颖研究。我们介绍了两个竞争团队的见解，该团队致力于提供可靠的企业级NL2SQL技术，阐明了实际应用中面临的挑战，包括处理复杂模式，处理自然语言语句中的歧义，并将其纳入我们的基准测试方法和负责任的AI考虑因素。虽然本文提出的问题可能比回答的要多，但其目的是成为对该主题进行富有成效的讨论的催化剂。此外，它还为社区开发企业级 NL2SQL 解决方案提供了实用的途径。

1 介绍

大型语言模型（LLM）的出现深刻地改变了自然语言处理（NLP）领域。对数据库社区的影响最大的任务莫过于NL2SQL的进步，即将自然语言（NL）自动转换为以流行的声明式语言SQL表示的数据库查询。这有可能通过向 10× 到 100 ×更多用户普及直接数据库查询，从而在系统可访问性方面带来重大转变。因此，NL2SQL多年来一直是研究的主题[16,24,26]，但迄今为止还没有一种方法达到足以获得广泛商业成功的准确性。

LLM革命有望改变这一切，而有效的NL2SQL技术有可能改变我们的行业：如何做到这一点是CIDR等数据库场所最热门的争论领域之一。无数的博客文章和教程会让我们相信 NL2SQL 现在是一个已解决的问题，而普通的 ChatGPT 可以解决我们所有的 SQL 生成需求。虽然我们同意 LLM 正在改变游戏规则，但在本文中，我们表明实现企业级 NL2SQL 绝非易事，甚至对此类系统进行基准测试也需要新颖的研究。

这篇论文很不寻常，因为它从隐形创业公司和Microsoft中捕获了两个竞争团队在NL2SQL上的共同观点。每个团队都在狂热地工作，以提供可靠的NL2SQL技术，该技术能够处理广泛的实际用例（即企业级）。在这个过程中，每个团队都发现了一系列丰富的挑战，许多客户互动为我们提供了一个独特的优势，了解用户对此类技术的实际期望。在这篇文章中，我们聚集在一起，为企业级NL2SQL提供更完整的问题陈述。我们认为这篇文章是及时的，也是必要的公共服务公告，因为我们在公共论坛和社区内的私人对话中观察到许多对这个问题的过度简化。本文的主要贡献之一是为该研究领域提供真实世界支持的问题陈述——我们讨论的一些被忽视的问题包括复杂的数据库模式、NL 查询中的歧义、理解数据库何时无法回答查询、基准测试限制、控制模型偏差（例如，性别/种族刻板印象）以及处理有害内容。

本文虽然全面概述了众多挑战，但它也深入研究了特定领域，进行了初步调查，揭示了潜在的问题，并勾勒出未来研究的轨迹。我们的主要贡献之一是专注于理解用户意图何时不明确，并提出我们应该将模糊性引入的不确定性纳入 NL2SQL 基准测试的案例。特别是，我们表明，即使是这个领域的基本基准测试也未得到解决（并且可能需要超出本文范围的深入研究）。关键问题是如何在存在歧义的情况下进行基准测试。我们提出了一个初步的启发式方法来解决这个问题。举个简单的例子，考虑一个 NL 请求“销售细节”：该语句本质上是模棱两可的，用户可能同样对 [item_id，date，price] 和 [item_name，price 的答案感到满意，这使得传统的字符串匹配或执行匹配指标无效。忽略模棱两可的查询是不切实际的，因为我们讨论的大多数客户都打算使用契约和非常非正式的语言来与我们的系统进行交互——事实上，正确支持模棱两可的查询（例如，使用上下文或历史来消除歧义）将使NL2SQL技术最有用。我们提出了一种务实的方法来解决这个问题，利用执行匹配的放松（我们通过与潜在客户交谈来验证这一点），但也讨论了如何需要更深入的研究工作才能进行更合理和完整的评估。

这篇论文提出的问题多于它所提出的问题，但也指出了一条务实的前进道路，旨在引发一些（希望是激烈的）讨论，即我们必须对未来的NL2SQL技术提出什么要求，以及如果我们没有选择正确的衡量标准会带来什么影响。本文的其余部分围绕四个核心挑战进行组织：模式复杂性（§2）、歧义和语义不匹配（§3.1）、基准测试（§4）和负责任的 AI （§5

2 模式复杂性

现实世界的数据库通常具有复杂的模式，其特点是各个维度的复杂性，例如大量的表和列以及特定于领域的术语。例如，Microsoft 的一个内部财务数据仓库由包含超过 4000 列的 632 个表和 200 个包含超过 7400 列的视图组成。同样，另一个跟踪产品使用情况的商业数据集包括 2281 个表，总共包含 65000 个列和 1600 个视图，其中包含近 50000 列。两个架构都包含具有缩写名称和自定义术语的列，只有领域专家才能理解。这些模式比标准NL2SQL基准（如Spider [27]、KaggleDBQA [15]和BIRD [17]）中的模式要复杂得多。

NL2SQL解决方案在这样的环境中面临挑战，尤其是在依赖LLM时。这些解决方案通常会创建一个提示，其中包括自然语言查询、架构信息和其他详细信息，例如每个表的示例行数或少量示例。此提示用于调用 LLM 并生成与 NL 问题相对应的 SQL 查询。但是，随着数据库架构的扩展，此类方法会遇到某些限制。首先，LLM 的上下文窗口是有限的，因此很难在提示符中容纳整个数据库模式。其次，最近的研究[18]表明，增加提示大小以包含更多信息并不一定能提高性能;事实上，随着输入上下文变长，它会导致准确性显着降低。第三，有趣的是，在我们的实验中，我们观察到，即使模式可以适应提示，也可以通过仅选择与NL查询相关的相关表和列来获得更好的准确性。

图 1 显示了我们在 KaggleDBQA 基准测试中的结果，该基准测试由 17 个表和 246 列组成。这个模式足够小，可以适应像 GPT-3.5 这样的 LLM 的提示。为了突出 schema 上下文的效果，我们使用了一个简单的提示策略，包括 NL 查询和 schema，并使用 GPT-3.5 生成对应的 SQL。经过分析，我们观察到，当在提示中加入完整的架构时，执行匹配准确率达到 22.7%。但是，通过根据基准测试中的真实查询，仅手动选择与每个查询相关的表和列，并且仅包含提示中的表和列，准确率提高了 7%。另一方面，对相关表和所有相关列进行排序可使精度提高（2%）。这些结果表明，即使架构可以完全适应提示，仅选择相关的表和列也可以显著提高性能。因此，设计技术来选择模式的相关部分对于小型和大型模式都是有利的。

图 1：使用各种模式选择技术的 KaggleDBQAdataset 的执行匹配精度。

图 1 说明了我们评估的两种简单模式选择技术的结果：RAG 和基于 LLM 的模式选择技术。前者涉及为表名和列名创建嵌入（使用 text-similarity-davinci-001model），并使用余弦相似度的 nearest-neighborsearch 作为距离函数来识别与 NL 查询最相似的词。随后，我们只包括提示中的那些。后一种方法首先利用 LLM 来标识与 NL 查询相关的表和列，并仅包含通过对 LLM 的第二次调用发送的提示中的表和列。虽然这些技术显示出有希望的结果，但准确性仍然低于完整的模式基线，并且明显低于最佳精度。

未来的研究方向。为了实现能够处理大量架构的企业级 NL2-SQL 解决方案，同时保持高精度，开发能够识别给定 NL 查询架构相关部分的技术至关重要。我们的初步研究表明，这些技术也有可能提高小型模式的性能。然而，基于 RAG 和 LLM 的简单模式选择解决方案即使在更简单的开源基准测试中也无法达到最佳性能，

但正如我们用专家方法所演示的那样，这样做可能会显着影响生成的 SQL 的质量。因此，进一步的研究和创新是完全有理由改进这些技术并充分发挥其潜力的。

3 歧义和语义不匹配

在本节中，我们将深入探讨 NL2SQL 系统上下文中有关用户意图理解及其与底层数据库的一致性的两个问题。第一个问题涉及自然语言中固有的歧义，以及它如何给这些系统带来挑战。第二个问题涉及语义不匹配，即所提供的数据库无法有效地满足用户的意图。

3.1 歧义

自然语言本质上是模棱两可的，使其容易受到多种解释的影响。解决这种歧义是自然语言处理中的一项关键任务，以确保人与机器之间的准确通信。在数据库查询的上下文中，数据库相关上下文（包括数据库架构、值和批注）的存在引入了额外的复杂性层。遗憾的是，NL2SQL上下文中的模糊性尚未引起数据管理社区的足够关注。然而，随着NL2SQL技术的日益普及，迫切需要深入研究歧义的各种形式和表现形式，并开发适合其检测和解决的技术，以满足各种应用的特定要求。我们提出了在NL2SQL上下文中建立歧义定义的初步努力。我们假设 NL2SQL 解决方案将识别数据库何时无法应答给定的 NL 查询，并返回适当的消息（如下所示）1。在建立了基本定义之后，我们展示了在调查过程中遇到的几个歧义实例，并提供了关于自动检测歧义的初步结果。

定义 1.考虑非等效 2 SQL 查询 Q={q1， ...，qN} 的范围，它可以在给定的数据库 D 上表述。让我们φ指出 D 无法回答 NL 查询的情况。给定一个 NL 查询和一个确定性 3 NL2SQL 映射 f：s→ P（Q）Ðφ，其中 P（Q）是幂集，如果 f（s）的基数至少为 2，我们说 s 是模棱两可的。

换言之，上面的定义抓住了一种直觉，即如果两个不等效且可接受的 SQL 查询可以回答 NL 查询，那么就是模棱两可的。

作为我们探索的一部分，我们彻底检查了 KaggleDBQA [15] 数据集中的 272 个问题，并征求了两个用户的意见，以根据定义 1 识别模棱两可的问题。有趣的是，我们发现基准确实包含 112 个模棱两可的问题，对应于数据集中 41.1% 的问题4。然后，我们对数据集中遇到的主要歧义类型进行了分析，如下所示：

•与数据库架构（DB schema）的映射不明确。NL 查询是精确的，但可能有多种方法可以将其映射到 DB schema。例如，让我们以查询“最危险的区域在哪里？该表包含两列包含地理信息，Location和LSOA（下层超级输出区域），并且不清楚应该使用两者中的哪一列.36.6%的歧义查询属于这一类。

•与数据库值的映射不明确。在本例中，NL 查询是精确的，但不清楚如何在生成的 SQL 查询中表述 WHERE 语句。例如，考虑查询“有多少核电站准备在日本使用？可以期望此查询在表单状态的状态列上使用筛选器，例如“%preparation%”。但是，“Under Construction”值也是有效的，并且实际上是在地面实况查询的相应过滤器中使用的值。19.6%的模棱两可的查询属于这一类。

•NL 查询中的语言不明确。在这些情况下，没有足够的上下文来确定用户的意图。例如，考虑查询“哪种农药最容易测试？在这种情况下，可能有多种方法可以确定测试农药的难易程度，例如，根据其浓度、执行测试所需的样品数量等.34.8%的模棱两可的查询属于这一类。

下一步，我们进行了初步调查，以探索 LLM 识别歧义的能力以及他们的评估与人类注释者的一致性程度。在这项研究中，我们同时使用了 GPT-3.5 和 GPT-4。我们设计了一个提示，根据前面提到的定义 1，询问给定的 NL 查询在特定数据库的上下文中是否不明确。我们的实验结果如图2所示。为了衡量一致性，我们计算了人类注释者之间以及人类和LLM之间的一致性。X 和 Y 两方之间的一致性计算为 X 和 Y 在标签上达成一致的 NL 查询的百分比除以查询总数。

值得注意的是，即使是人类注释者也无法始终如一地同意一个问题是否相对于给定的数据库是模棱两可的，他们之间的一致率约为62%。与人类注释者相比，GPT-3.5 的同意率较低，仅为 44%。另一方面，GPT-4 表现出与人类的一致率显着更高（65%）。这些结果表明，高级 LLM，如 GPT-4，有可能在人类可以识别的范围内识别歧义。

虽然获得的结果显示出希望，但人类注释者之间的低一致性表明，在确定数据库顶部的 NL 查询是否模棱两可时，歧义的概念缺乏普遍明确的定义。这种固有的挑战来自用户如何用自然语言表达他们的意图，它强调了对歧义进行更精细定义的必要性，即考虑对NL语句的各种解释的可能性。由于人类注释者之间关于这种歧义定义的显着差异，因此在此阶段计算此特定任务的 LLM 的精确度和召回率没有意义。在评估LLM在处理此类场景方面的表现之前，有必要进一步工作以建立对歧义的更精确和一致的理解。

未来的研究方向。我们的调查得出了以下几个发现：1）现有的NL2SQL基准测试确实包含歧义查询，但每个NL问题都包含一个基本事实SQL查询，这使得使用它们准确评估NL2SQL解决方案具有挑战性。我们将在下一节中对基准测试进行扩展。2）人类注释者对NL查询是否模棱两可的看法不同，这可能表明我们需要一个更好的歧义定义，可能接受其概率性质，并纳入给定查询的各种解释的可能性（这将需要大规模和劳动密集型的调查）。3）像 GPT-4 这样的高级 LLM 表现出与人类注释者相似的一致率，这对于他们在 NL2SQL 上下文中识别歧义的能力来说是有希望的（尽管非常初始）的结果。

这些发现为该领域的研究提供了新的途径。首先，很明显，企业级NL2SQL系统必须解决歧义的挑战。因此，当务之急是制定适当的基准和基准测试方法，包括标签，并尽可能尽可能地衡量模糊查询的整体性能。其次，重新定义歧义的概率性质在我们的NL2SQL解决方案中是必不可少的。为了实现这一点，我们应该将模糊性的概念完全整合到我们的工作流程中。这需要开发技术来识别给定 NL 查询中的歧义，衡量不同解释的可能性，并实施机制以寻求进一步的清晰度。一种有效的方法是通过有针对性的问题来吸引用户，这有助于获得额外的信息并减少不确定性。最后，探索LLMs检测歧义和提供多种解释的潜力是未来研究的一条引人入胜的途径。

3.2 语义不匹配

NL2SQL解决方案的设计主要基于这样的假设，即输入问题确实可以由底层数据库回答。然而，在实践中，情况可能并非总是如此。最终用户可能不知道（全部或部分）列或表的语义。因此，它们可能表达基础数据库无法回答的意图。数据库可能完全或部分不匹配此类意图。作为前者的一个例子，业务用户可能会在不相关的 HR 表上提出财务问题。作为后者的一个例子，考虑一个表 singers（name，cause_of_death， . . . . ， year）。语义year是歌手发行第一张专辑的那一年。对于“2021 年有多少歌手死于新冠病毒”的问题，LLM 可能会生成查询SELECT * FROM singers WHERE cause_of_death LIKE’%covid%’ and year=2021.。虽然 cause_of_death 上的谓词是正确的，但 year 上的谓词错过了年份列的语义，从而导致错误的响应。

正如上面歧义的定义中所讨论的，理想情况下，NL2SQL解决方案应该能够在数据库无法回答用户的问题时通知用户（即returnφ）。我们进行了初步调查，以探索 LLM 是否可以检测到给定数据库无法回答 NL 查询的情况。对于我们的实验，我们同时使用了 KaggleDBQA 和 Spider 基准测试。特别是，我们尝试在 KaggleDBQA 基准的犯罪数据库之上运行来自 Spider 基准的 NL 查询。我们要求 LLM 为给定的 NL 问题生成适当的 SQL 查询，或者如果数据库无法回答该问题，则返回 φ。我们还在提示中加入了两个示例，以教导模型何时返回 φ 值：1）在返回 φvalue 的 KaggleDBQA 数据库上提出的 Spider 问题，以及 2）在相应的 KaggleDBQA 数据库上返回正确的 SQL 查询的 KaggleDBQA 问题。我们尝试了两种模型（GPT-3.5 和 GPT-4）。

在我们的设置中，理想的结果是收到 Spider 基准测试中所有 NL 查询的φ响应。GPT-3.5 模型正确地识别出只有 60% 的问题无法被数据库回答的问题。对于剩下的 40% 的问题，GPT-3.5 生成了一个 SQL 查询，该查询通常包括 KaggleDBQA 模式的一部分，但也包括根本不出现在模式中的幻觉表和列名称。另一方面，GPT-4 正确检测到数据库无法回答任何 Spider 问题。这些结果表明，高级LLMs能够很好地识别语义不匹配。（gpt4真强）

未来的研究方向：在部署NL2SQL解决方案时，检测语义不匹配非常重要。我们对 GPT-4 的实验非常有希望。然而，值得注意的是，GPT-4 是一个非常大的模型，其成本远高于 GPT-3.5 等模型（在撰写本文时，GPT-4 比 GPT-3.5 每个 1K token贵约 30 倍 [1]），并且延迟明显更高，这使得在生产环境中部署更具挑战性。设计技术来识别与更小、更便宜的模型的语义不匹配是未来工作的重要方向。

4 基准测试

随着对自然语言和数据库之间无缝交互的需求不断增长，基准测试对于评估 NL2SQL 系统的性能和功能变得至关重要。已经提出了多个基准来评估NL2SQL方法，例如Spider [27]，KaggleDBQA [15]和BIRD [17]。这些基准在推动该领域的界限方面发挥了重要作用。但是，实际工作负载的某些方面并未体现在这些基准和相关的评估方法中。例如，正如我们在 §3.1 中所展示的，KaggleDBQA 基准测试中 41% 的查询被人类注释者描述为模棱两可。然而，该基准测试仅提供与每个 NL 查询相关的单个真实值查询，忽略了多种解释的可能性。此外，评估标准通常过于保守，即使生成的 SQL 查询正确地对应于另一种可能的解释，也认为是失败的。在本节中，我们强调需要更全面的基准和评估指标，以更好地适应实际 NL2SQL 场景中存在的固有复杂性和不确定性。

就我们的目的而言，NL2SQL 基准测试由一组 NL 查询及其在数据库之上的关联真实 SQL 查询组成。数据库架构和数据可用。该基准测试是通过基准测试框架执行的，该框架通过遍历 NL 查询、生成相应的 SQL 查询，然后将其与真实查询进行比较来评估给定的 NL2SQL 方法。基准测试运行的结果是一个准确性分数，该分数量化了与真实查询匹配的生成查询数。基准测试的目的是建立一个易于测试的环境，忠实地模拟真实世界的用户体验，将更高的分数与更好的用户体验联系起来。评估两个查询是否匹配的常见指标是完全字符串匹配和执行匹配[17]指标。前者只是比较两个查询是否具有相同的字符串表示形式。后者需要对输入数据集执行查询，并确认其结果相同。这两种类型的指标都存在问题：完全匹配通常过于保守，因为它没有考虑语义上等效但语法不同的查询。执行匹配也有局限性，因为它没有考虑多个 an-swers/解释可能正确的情况。例如，考虑查询“查找硕士生和本科生都入学的学期。来自 Spider 基准测试。相应的地面实况查询返回semester_ID列。现在，假设一个 NL2SQL 解决方案同时返回 semester_name 列和 semester_ID 列。用户可能会对这个答案感到满意，但现有的评估指标（通过精确和执行匹配）会将这种情况标记为失败。

上述基准测试方法的问题在于，它只关注正确性，而不是生成的 SQL 查询的有用性概念。只有当基准测试正确地模拟了现实情况时才有价值，在这种情况下，即用户利用 NL2SQL 技术的可能满意度。因此，我们建议转向基于意图的基准测试框架，并认为这是必要的。基于意图的基准测试的特点是评估围绕确定生成的SQL查询是否有效地满足原始用户的意图。通过关注与用户意图的一致性，这样的框架将对NL2SQL系统进行更全面、更有意义的评估，确保生成的查询不仅具有正确的性，而且满足用户自然语言查询的根本目的。

虽然原则上是可取的，但由于§3.1中讨论的自然语言固有的歧义以及对用户领域的可见性有限，掌握用户的意图是一个挑战。尽管如此，通过做出一些合理的假设，我们可以为开发基于意图的基准测试方法奠定基础。作为第一步，我们提出了一个新的指标，用于评估生成的 SQL 查询是否“匹配”我们称之为基于意图的执行匹配的基准中的基础真实查询。该指标同时考虑数据库模式以及生成的查询（q）和地面真值查询（ˆq）的查询执行结果，以确定是否存在匹配。新指标背后的想法很简单：我们比较两个查询的执行结果，并应用一组基于架构结构的规则来确定是否应该允许某些偏差。松弛规则的设计使得响应虽然偏离了原始的基本事实，但仍然满足理性用户的可能意图。这些规则被设计为务实的权宜之计，并基于我们（正如您在介绍中回忆的那样）竞争团队的广泛讨论，并在几次客户对话中得到验证。因此，它们代表了建立基于意图的基准机制的有效和务实的尝试。该领域的更正式的工作正在进行中，可能需要我们社区的投入。一般而言，任何生成的查询q在语义上等同于基准测试中提供的基本真值查询ˆq必须被认为是正确的.5我们现在建议对生成的查询q和基本真值查询之间的语义等价标准进行以下放宽：

(1)我们允许在 q 和 ˆq 的结果中使用不同的行顺序，除非用户特别要求特定的排序。

(2)我们允许 q，c（q）中的（无序）列集成为 ˆq，c（ˆq）中的列集的超集。例如，如果 c（q）包含 employee_name 和 employee_salary 列，而 c（ˆq）仅包含 employee_name 列，则这仍被视为匹配项。

(3)此外，在 NL 查询中没有显式提及列的情况下，我们还考虑 c（q）中的候选键以匹配 c（ˆq）中的其他候选键。例如，让我们再看一下我们上面讨论的查询“查找硕士生和本科生入学的学期”。尽管 NL 查询是精确的，但可能有多个映射到 DB 模式（参见 §3.1 中的歧义类别）。使用这种基于候选键的放宽，任何导致 SQL 查询返回学期 ID、学期名称或两者的解释都将被标记为正确，因为这两列都是学期表中的候选键。

4.1 Archerfish 基准测试框架

作为应对上述挑战的第一步，我们推出了一个名为Archerfish[3]的新型开源NL2SQL基准测试框架。该框架的主要目标是能够跨大量数据集评估各种 NL2SQL 系统和方法，通过一系列评估指标促进它们的比较。我们的愿望是让更广泛的数据库社区积极参与到进一步开发这个框架的工作中，将其转变为一个强大的NL2SQL基准测试和评估工具。Archerfish 基准测试由数据库上的一组（NL 问题和 SQL 结果）对组成。该框架由以下关键组件组成：

•驱动程序：与底层 NL2SQL 系统接口，并编排整个执行过程。

•分析器：实现各种评估指标，包括精确匹配、执行匹配和本文介绍的基于意图的执行匹配。分析器使用用户定义的指标评估生成的查询是否与真实查询匹配。

•数据库、题库和地面实况规范：描述给定基准的规范文件

•生成器：一个可选工具，便于直接从给定数据库生成基准测试。

•结果视图：可视化基准测试运行结果的 HTML 页面。

为了证明 Archerfish 的实用性，我们运行了 Spider 基准测试并收集了各种指标：原始的 exactand 执行匹配和更轻松的基于意图的执行匹配。图 3 报告了三个 Spider 数据库的结果。该测试是通过一个简单的提示进行的，其中包括数据库模式和 NL 问题，针对 GPT-4 [8]。正如预期的那样，基于意图的指标不如精确匹配和执行指标严格，从而可以考虑歧义的正确性。举例来说，考虑以下问题：“哪家航空公司的航班数量最多？真值查询生成的结果只有一列，即航空公司名称。另一方面，LLM 生成的查询不仅返回航空公司名称，还包括该航空公司的航班总数。根据原始执行匹配指标，这将被视为失败，因为它引入了一个附加列。但是，从用户的角度来看，生成的查询和表仍然正确地回答了问题，同时提供了额外的（可能有价值的）信息。在这种情况下，基于意图的指标将此示例归类为成功。

我们的框架可以在多个维度上扩展。首先，它允许用户合并新的基准测试和测试用例。这样可以轻松创建自定义工作负载来测试特定域。还可以包括专有数据集，以将测试扩展到涉及隐私的领域。该框架还可以与其他工作（如QATCH[22]）结合使用，以从现有数据库自动生成基准。其次，Archerfish 允许将额外的数据库管理系统和 SQL 方言合并为 PostgreSQL 作为默认值。第三，该框架允许添加新的评估指标，以衡量各个维度（例如，准确性或响应时间）的确定性能。最后，用户还可以提供可以在提示中利用的其他上下文（例如，业务术语或数据目录）。

未来的研究方向。基于意图的NL2SQL基准测试为未来的研究提供了一条有前途的途径。我们提出的新颖度量试图放宽之前度量学对成功 NL2SQL 映射的构成的假设。但是，即使此指标也无法从用户的角度捕获可接受查询的全部范围。因此，关于如何调整我们的基准方法以有效地涵盖这一频谱，仍然存在一个悬而未决的问题。

此外，对基准测试中的模糊性进行建模至关重要，不仅要对 NL 查询的模糊性提供注释，还要通过基准测试方法本身。基准测试框架应包含评估 NL 查询是否模棱两可的组件，可能会生成多个交互及其关联的 SQL 查询，以便与基本事实进行比较。引入多种解释需要开发新的指标来评估系统根据代表用户意图的可能性对这些解释进行排名的程度。在信息检索和网络搜索的背景下也讨论了类似的想法[20]，我们相信该领域的先前工作也可以适应我们的背景。

5 负责任的人工智能

自然语言固有的模糊性、LLM 的概率性以及个人的潜在恶意导致了越来越多的与 NL2SQL 解决方案的负责任 AI 相关的担忧。在本节中，我们阐明了我们遇到的问题，并概述了相应的研究方向。有害内容：存在恶意用户引入有害内容是一个令人担忧的问题，已知LLM会生成包含此类内容的补全[13,21,30]。检测和阻止此类有害内容在像Microsoft Copilot[5]这样的LLM经验中至关重要，这同样适用于NL2SQL系统。但是，在 NL2SQL 的上下文中，数据库本身可能包含敏感或有害的内容。考虑一个维护罪犯数据库的警察部门，警官需要搜索具有特定模式的犯罪。在这种情况下，输入问题和补全内容自然可能包含有害内容。然而，这样的内容应该是允许的，由于数据库的性质，查询也应该被允许。

为了应对这一挑战，我们认为，使NL2SQL解决方案能够决定是否阻止或允许数据库语义上的有害内容是一个有趣的研究方向。找到区分真正符合数据库目的的有害内容和恶意引入的有害内容的方法对于负责任和有效的 NL2SQL 解决方案至关重要。

语言支持。NL2SQL 解决方案将某些语言的问题作为输入，并以目标 SQL 方言输出 SQL 查询。然而，众所周知，LLM在英语以外的语言中资源不足，无法完成一些任务[10,12,14,28]。我们在NL2SQL任务上的发现是相似的。我们使用 Azure AI Translator [4] 将 KaggleDBQA 基准测试中的 NL 问题翻译成中文、印地语、德语、法语和希腊语。我们观察到，NL2SQL 性能（即 top-1 执行匹配）在翻译问题上下降了 3.5%-15%，具体取决于语言。

此外，我们的实验表明，LLM可能会以目标方言（例如T-SQL）以外的SQL方言（例如，SQLite兼容）生成查询。当目标是 T-SQL 时，不兼容的示例包括设置 LIMIT 子句而不是 TOP 子句或双引号中的文本，这些子句在 SQLite 中被解释为字符串文字，但在 T-SQL 中被解释为列名（默认情况下）。特别是，在 KaggleDBQAbenchmark 上运行我们的内部 NL2SQL 解决方案时，我们观察到 ~6% 的完成在将基准转换为特定于 T-SQL 后存在这种不兼容性。从这个意义上说，我们认为不断尝试从LLM中支持语言，检测并可能阻止低资源语言，提高LLM完成率（通过训练，微调或更好的提示），以及修复LLM完成以改善语言支持是有趣的研究方向。

意想不到的效果。让 NL2SQL 在用户输入的请求下生成和执行查询可以导致数据库状态修改（例如，通过生成 CRUD 语句）。根据客户反馈，这在多种情况下都可能令人担忧，尤其是在考虑用户意图的模糊性时（例如，询问“过去一小时的清除操作”会导致删除最后一小时的记录 inoperationstable，而不是返回 recordsfromoperationswithoperations.action = 'purge'in the lasthour）。因此，NL2SQL 解决方案可能需要限制其输出语句类型（例如，仅允许 SELECT 查询而不会对数据库产生副作用）或可以执行的内容（例如，通过具有 READ-onlyprivileges 的角色执行查询）。但是，按类型或通过基于角色的数据库访问来阻止查询可能会受到很大限制。例如，数据科学家可能希望使用 LLM 的生成能力来生成示例并将其插入到新表中（以开始原型设计）。因此，使NL2SQL解决方案能够避免意外的副作用，同时又不限制体验是一个有趣的研究方向。在这个方向上，我们认为现有的数据库研究和实践可能至关重要。例如，可以允许 NL2SQL 执行任何语句类型，但在既不提交的事务中执行（阻止事务语句类型，如 ROLLBACK，并禁用隔离级别，如 READ UNCOMMITTED 以避免相反的影响），要么使用时间旅行或分支（如果底层数据库系统支持）

在上面关于RAI的讨论的基础上，NL2SQLsolutions必须与治理平台无缝集成（例如，Microsoft Purview [7]或Microsoft Fabric Governance [6]）。这些平台的用户，如审计员或数据库管理员，应该能够理解NL2SQL解决方案的输入和输出，以及他们采取的相应行动。他们还应该能够识别可能涉及整个数据资产中 NL2SQL 操作的根本原因（例如，报告工具无法更新，因为 NL2SQL 执行了修改报告访问的数据库架构的 ALTER 语句），确定 NL2SQL 操作对企业数据生态系统中各种元素（例如，数据集、流程、数据库或服务）的影响），保留反向操作的灵活性，并生成来自他们利用 NL2SQL 解决方案的有见地的报告。同时，NL2SQL 解决方案必须遵守在治理平台内建立的策略，或利用这些平台中可用的上下文信息（例如，元数据、出处或业务术语表）来提高 NL2SQL 交互的质量。