通过对数据进行对话式访问，创造信息优势
实现Text2SQL以推动数据驱动的组织的指南
随着我们的世界变得越来越全球化和动态化，企业越来越依赖数据来做出明智、客观和及时的决策。然而，到目前为止，发挥组织数据的全部潜力通常是少数数据科学家和分析师的特权。大多数员工并不精通传统的数据科学工具包（SQL、Python、R等）。为了访问所需数据，他们通过附加层，由分析师或BI团队将商业问题的散文“翻译”成数据语言。在这个过程中摩擦和低效的潜力很高——例如，数据可能会有延迟，甚至在问题已经过时时才得到提供。当要求没有准确地转化为分析查询时，信息可能会在途中丢失。此外，生成高质量的见解需要迭代方法，在循环中每增加一步都会受到阻碍。另一方面，这些临时的交互会给昂贵的数据人才带来干扰，并使他们分心于更战略性的数据工作，正如这位数据科学家的“自白”所描述的那样：
当我在Square工作时，团队规模较小，我们有一个可怕的“分析值班”轮换。它是严格按周轮换的，如果轮到你了，你知道那个星期你会很少做“真正”的工作，大部分时间都要处理公司各个产品和运营团队的临时问题（我们称之为SQL猴子）。在分析团队的经理角色上有激烈的竞争，我认为这完全是经理被免除这个轮换的结果——没有任何身份奖励可以与不值班工作的胡萝卜相提并论[1]。
的确，直接与数据交流而不必经过与数据人员的多轮交互，这不是很酷吗？这种愿景被对话界面所采纳，它允许人们使用语言与数据进行交互，这是我们最直观和最普遍的沟通方式。在解析问题后，算法将其编码为所选查询语言（如SQL）的结构化逻辑形式。因此，非技术用户可以与他们的数据聊天，并快速获取特定、相关和及时的信息，而不需要经过BI团队的绕路。在本文中，我们将考虑Text2SQL的不同实现方面，并关注使用大型语言模型（LLMs）的现代方法，这些方法目前实现的最佳性能（参见[2]；对于超出LLMs的替代方法的调查，读者可以参考[3]）。本文根据计划和构建AI功能时需要考虑的主要要素的以下“精神模型”组织结构：
让我们从最终目标开始，回顾一下价值——为什么要将Text2SQL功能构建到您的数据或分析产品中。三个主要的好处是：
- 商业用户可以直接和及时地访问组织数据。
- 这减轻了数据科学家和分析师从商业用户那里获取临时请求的负担，并允许他们专注于高级数据挑战。
- 这使企业能够以更流动和战略性的方式利用其数据，最终将其转化为决策的坚实基础。
现在，您可能考虑Text2SQL的产品场景是什么？三个主要设置是：
- 您正在提供一个可扩展的数据/BI产品，希望以非技术方式使更多用户访问其数据，从而增加使用率和用户基础。例如，ServiceNow已将数据查询集成到更大的对话性产品中，Atlan最近宣布了自然语言数据探索。
- 您正在寻求在公司内民主化数据访问的数据/人工智能领域构建一些东西，这种情况下您可能潜在地考虑具有Text2SQL核心的MVP。像AI2SQL和Text2sql.ai这样的供应商已经进入了这个领域。
- 您正在开发一个自定义的BI系统，并希望最大化和民主化其在个别公司中的使用。
正如我们将在接下来的章节中看到的那样，Text2SQL 需要一个非常复杂的前期设置。为了估算 ROI，需要考虑所支持的决策性质以及可用的数据。在动态环境中，比如投资、市场营销、制造业和能源行业等，Text2SQL 可以绝对胜出，因为在这些环境中，传统的知识管理工具过于静态，而更流畅的访问数据和信息的方式可以帮助公司获得竞争优势。就数据而言，Text2SQL 在以下数据库中提供最大的价值：
- 大量增长，因此 Text2SQL 可以随着时间的推移展现其价值，因为越来越多的数据被利用。
- 高质量，以便 Text2SQL 算法不必处理数据中的过多噪声（不一致性、空值等）。一般来说，由应用程序自动生成的数据比由人类创建和维护的数据具有更高的质量和一致性。
- 语义成熟，而不是原始的，以便人类可以基于中心概念、关系和度量来查询数据。请注意，语义成熟可以通过附加的转换步骤来实现，将原始数据转换为概念结构（参见“使用数据库信息丰富提示”一节）。
接下来，我们将深入研究数据、算法、用户体验以及 Text2SQL 功能的相关非功能要求。本文面向产品经理、UX 设计师以及那些刚开始进行 Text2SQL 之旅的数据科学家和工程师。对于这些人士，它不仅提供了入门指南，还提供了一个共同的知识基础，用于讨论产品、技术和业务之间的接口，包括相关的权衡。如果您在实现方面已经更加先进，末尾的参考资料提供了一系列可深入探索的内容。
1. 数据
任何机器学习项目都始于数据，因此我们将从澄清训练和预测期间使用的输入和目标数据的结构开始。在本文中，我们将使用图 1 中的 Text2SQL 流程作为我们运行的表示，并在黄色突出显示当前考虑的组件和关系。
1.1 数据的格式和结构
通常情况下，一个原始的 Text2SQL 输入输出对由一个自然语言问题和相应的 SQL 查询组成，例如：
问题：“列出每个用户的名称和关注者数量。”
SQL 查询：
select name, followers from user_profiles在训练数据空间中，问题和 SQL 查询之间的映射是多对多的：
- 一个 SQL 查询可以映射到自然语言中的许多不同问题；例如，上面的查询语义可以用“显示每个用户的名称和关注者数量”、“每个用户有多少关注者？”等方式表示。
- SQL 语法非常灵活，几乎每个问题都可以用多种方式表示为 SQL。最简单的例子是 WHERE 子句的不同顺序。在更高级的情况下，每个人都会使用 SQL 查询优化，许多方法都可以得出相同的结果，语义等效的查询可能具有完全不同的语法。
手动收集 Text2SQL 的训练数据特别繁琐。这不仅需要注释者具备 SQL 掌握能力，而且每个示例需要比情感分析和文本分类等更一般的语言任务更多的时间。为确保有足够数量的训练示例，可以使用数据增强技术，例如，LLMs 可以用于为同一问题生成重新表述。[3] 提供了 Text2SQL 数据增强技术的更完整调查。
1.2 使用数据库信息丰富提示
Text2SQL 是处于非结构化数据和结构化数据之间的算法。为了实现最佳性能，训练和预测期间需要同时存在两种类型的数据。具体而言，算法必须了解所查询的数据库，并能以这样一种方式构造查询，以便可以针对数据库执行查询。这个知识可以包括：
- 数据库的列和表
- 表之间的关系（外键）
- 数据库内容
在整合数据库知识方面，有两种选项：一方面，训练数据可以限定为为特定数据库编写的示例，这种情况下模式可以直接从SQL查询及其与问题的映射中学习。这种单数据库设置允许为个人数据库和/或公司优化算法。但是，它会限制可扩展性，因为模型需要为每个客户或数据库进行微调。另一方面，在多数据库设置中，数据库模式可以作为输入的一部分提供，从而使算法可以“概括”到新的、未见过的数据库模式。虽然如果想在许多不同的数据库上使用Text2SQL，你必须选择这种方法，但请记住，它需要考虑大量的快速工程努力。对于任何合理的商业数据库，包括提示中的全部信息将极其低效，而且由于提示长度限制，这很可能是不可能的。因此，负责提示制定的函数应该足够智能，能够选择对于给定问题最“有用”的数据库信息子集，并且对于可能未见过的数据库也能做到这一点。
最后，数据库结构扮演了至关重要的角色。在那些你对数据库有足够控制的情况下，你可以通过让它从一个直观的结构中学习来使你的模型更容易。一般而言，你的数据库反映商业用户如何谈论业务的程度越高，你的模型学习得越好、越快。因此，考虑对数据进行额外的转换，例如将规范化或分散的数据组装成宽表或数据仓库，明确且不含糊地命名表和列等。你可以事先编码所有商业知识，这将减轻你的模型的概率学习负担，并帮助你实现更好的结果。
2. 算法
Text2SQL是一种语义解析的类型——将文本映射到逻辑表示。因此，算法不仅要“学习”自然语言，还要学习目标表示——在我们的情况下是SQL。具体来说，它必须获得以下知识：
- SQL语法和语义
- 数据库结构
- 自然语言理解（NLU）
- 自然语言和SQL查询之间的映射（句法、词汇和语义）
2.1 解决输入中的语言变异性
在输入方面，Text2SQL的主要挑战在于语言的灵活性：如在数据的格式和结构部分所述，同一个问题可以用许多不同的方式改写。此外，在实际的对话环境中，我们还必须处理一些问题，例如拼写和语法错误、不完整和模糊的输入、多语言输入等等。
像GPT模型、T5和CodeX这样的LLMs越来越接近解决这个挑战。通过学习大量不同的文本，它们学会处理大量的语言模式和不规则性。最终，它们能够在表面形式不同但语义上相似的问题上进行概括。LLMs可以直接应用（零样本）或经过微调后应用。前者虽然方便，但精度较低。后者需要更多的技能和工作，但可以显著提高准确性。
在准确性方面，如预期的一样，表现最好的模型是GPT家族的最新模型，包括CodeX模型。2023年4月，GPT-4在“执行与值”指标上的精度比先前的最新技术提高了超过5%，达到了85.3%的精度。[4]在开源社区中，解决Text2SQL难题的最初尝试集中在自动编码模型（如BERT）上，这些模型在NLU任务中表现出色。[5,6,7]然而，在围绕生成式AI的热潮中，最近的方法专注于自回归模型，如T5模型。T5是使用多任务学习预训练的，因此容易适应新的语言任务，包括语义解析的不同变体。然而，自回归模型在语义解析任务中存在固有缺陷：它们具有无约束的输出空间和没有约束它们输出的语义保护栏，这意味着它们在行为上可以变得惊人地创造性。虽然这对于生成自由形式的内容来说是惊人的，但对于Text2SQL之类的任务来说则是一种麻烦，因为我们期望得到一个有限制的、结构良好的目标输出。
2.2 查询验证和改进
为了限制LLM的输出，我们可以引入额外的机制来验证和改进查询。这可以作为PICARD系统[8]中提出的额外验证步骤来实现。PICARD使用一个SQL解析器，可以验证部分SQL查询是否可以在完成后导致有效的SQL查询。在LLM的每个生成步骤中，会拒绝会使查询无效的标记，并保留最高概率的有效标记。由于是确定性的，这种方法只要解析器遵守正确的SQL规则，就可以确保100%的SQL有效性。它还将查询验证与生成解耦，从而允许将两个组件彼此独立地维护，并升级和修改LLM。
另一种方法是直接将结构和SQL知识纳入LLM中。例如，Graphix[9]使用图形感知层将结构化的SQL知识注入T5模型中。由于这种方法的概率性质，它会偏向于正确的查询，但并不能保证成功。
最后，LLM可以用作一个多步骤代理，可以自主检查和改进查询[10]。使用一系列思考提示中的多个步骤，代理可以被赋予反思其自己查询的正确性并改进任何缺陷的任务。如果经过验证的查询仍无法执行，则可以将SQL异常回溯作为额外的反馈传递给代理以进行改进。
除了这些在后端发生的自动化方法外，在查询检查过程中还可以涉及用户。我们将在用户体验部分中详细描述这一点。
2.3 评估
为了评估我们的Text2SQL算法，我们需要生成一个测试（验证）数据集，对其运行我们的算法，并对结果应用相关的评估指标。一个朴素的数据集分为训练、开发和验证数据，是基于问题-查询对的，并导致次优的结果。验证查询可能在训练期间向模型揭示，并导致对其泛化能力过于乐观的看法。一个基于查询的分割，其中数据集被分为这样的方式，即在训练和验证期间没有查询出现，提供更真实的结果。
在评估指标方面，Text2SQL中我们关心的不是生成与金标准完全相同的查询。这个“精确字符串匹配”方法太严格了，会产生许多假阴性，因为不同的SQL查询可以导致相同的返回数据集。相反，我们想要实现高语义准确性，并评估预测的“金标准”查询是否总是返回相同的数据集。有三个评估指标可以近似实现这个目标：
- 精确集匹配准确度：生成的和目标SQL查询被分割为它们的组成部分，并比较它们的身份[11]。这里的缺点是它只考虑SQL查询中的顺序变化，而不考虑语义上等价的查询之间更显着的语法差异。
- 执行准确度：从生成的和目标SQL查询所得到的数据集进行比较以确定它们是否相等。幸运的是，具有不同语义的查询仍然可以在特定的数据库实例上通过此测试。例如，假设一个数据库中所有用户的年龄都超过30岁，那么以下两个查询将返回相同的结果，尽管它们具有不同的语义：<select * from user select * from user where age > 30
- 测试套件准确度：测试套件准确度是执行准确度的更高级别和更不宽容的版本。对于每个查询，生成一组（“测试套件”）高度不同的数据库，这些数据库与查询中的变量、条件和值有关。然后，在每个数据库上测试执行准确度。虽然需要额外的工作来设计测试套件生成，但这个指标也显著降低了评估中假阳性的风险[12]。
3. 用户体验
目前Text2SQL的最新技术还不能完全无缝地集成到生产系统中–相反，有必要积极管理用户的期望和行为，用户应该始终意识到她正在与一个AI系统交互。
3.1 失败管理
Text2SQL 可以以两种模式失败，需要以不同的方式进行捕获：
- SQL 错误：生成的查询无效 —— 无论是 SQL 无效还是由于词法或语义缺陷而无法针对特定数据库执行，都不能向用户返回结果。
- 语义错误：生成的查询是有效的，但它不反映问题的语义，从而导致返回错误的数据集。
第二种模式特别棘手，因为“静默故障”的风险（用户未检测到的错误）很高。原型用户既没有时间也没有技术技能来验证查询和/或生成的数据的正确性。当数据用于现实世界的决策时，这种类型的故障可能会产生灾难性的后果。为了避免这种情况，至关重要的是教育用户并在业务层面上建立限制潜在影响的“防护栏”，例如对于具有更高影响的决策进行额外的数据检查。另一方面，我们还可以使用用户界面来管理人机交互，帮助用户检测和改进有问题的请求。
3.2 人机交互
用户可以以不同的强度参与您的 AI 系统。每个请求的更多交互可以带来更好的结果，但它也会减慢用户体验的流畅性。除了错误查询和结果的潜在负面影响外，还要考虑您的用户提供来回反馈的动机，以便获得更准确的结果，并在长期内帮助改进产品。
最简单且最不引人注目的方法是使用置信度分数。虽然置信度的天真计算作为生成的令牌概率的平均值过于简单，但可以使用更先进的方法，例如口头反馈。[13] 可以在界面中显示置信度，并在危险地低时用明确的警报突出显示。这样，在“现实世界”中适当的跟进工作——无论是拒绝、接受还是对数据进行额外检查——就落在您的用户肩上。虽然这对于您作为供应商来说是个安全的选择，但将这项工作转移给用户也可能降低您的产品价值。
第二种可能性是在置信度低、模糊或其他可疑查询的情况下引导用户进行澄清对话。例如，您的系统可能会建议输入的拼写或语法纠正，并要求澄清特定单词或语法结构。它还可以允许用户主动请求查询的更正：[14]
用户：展示 John 在这个迭代中的任务。
助手：您想看 John 创建的任务还是他正在处理的任务？
用户：看 John 创建的任务。
助手：好的，这是任务 ID：
用户：谢谢，我还想查看更多关于任务的信息。请按紧急程度排序。
助手：好的，这是任务以及简短描述、受托人和截止日期，按截止日期排序。
最后，为了让用户更容易理解查询，您的系统还可以提供查询的明确文本重述，并要求用户确认或更正它。[15]
4. 非功能性需求
在本节中，我们将讨论 Text2SQL 的具体非功能性需求以及它们之间的权衡。我们将重点关注似乎对任务最重要的六个要求：准确性、可扩展性、速度、可解释性、隐私和适应性。
4.1 准确性
对于 Text2SQL，准确性的要求很高。首先，Text2SQL 通常应用于一对一的对话设置中，因此，“大数定律”通常帮助平衡批处理预测中的误差，但这对 Text2SQL 没有帮助。其次，句法和词汇的有效性是一个“硬”条件：模型必须生成一个形式良好的 SQL 查询，可能具有复杂的语法和语义，否则请求无法针对数据库执行。如果这一点做得好，查询仍然可能包含语义错误，并导致错误的返回数据集（参见第 3.1 节“失败管理”）。
4.2 可扩展性
主要的可扩展性考虑是您是否想在一个或多个数据库上应用Text2SQL，以及在后一种情况下，数据库集是否已知和封闭。如果是，您将更容易，因为您可以在培训期间包括这些数据库的信息。然而，在可扩展产品的情况下，无论是独立的Text2SQL应用程序还是现有数据产品的集成，您的算法都必须应对任何新的数据库架构。这种情况也不给您机会转换数据库结构，使其更易于学习（链接！）。所有这些都会导致准确性的重大权衡，这也可能解释为什么目前提供新数据库的即席查询的Text2SQL提供程序尚未实现显着的市场渗透。
4.3 速度
由于Text2SQL请求通常会在对话中在线处理，因此速度方面对于用户满意度很重要。从积极的一面来看，用户通常知道数据请求可能需要一定的时间，并表现出所需的耐心。然而，这种好意可能会被聊天设置所破坏，其中用户下意识地期望像人类对话速度一样。像缩小模型大小这样的蛮力优化方法可能对准确性产生不可接受的影响，因此请考虑推理优化以满足这种期望。
4.4 可解释性和透明度
在理想情况下，用户可以跟踪如何从文本生成查询，查看问题中特定单词或表达式与SQL查询之间的映射等。这允许验证查询并在与系统交互时进行任何调整。此外，系统还可以明确地重新制定查询并要求用户确认或更正。
4.5 隐私
Text2SQL函数可以与查询执行隔离，因此返回的数据库信息可以保持不可见。但是，关键问题是提示中包含多少关于数据库的信息。三个选项（按隐私级别降低）是：
- 没有信息
- 数据库架构
- 数据库内容
隐私与准确性相互权衡——您在提示中包含有用信息的限制越少，结果就越好。
4.6 随时间的适应性
要以持久的方式使用Text2SQL，您需要适应数据漂移，即模型应用的数据分布的变化。例如，假设用于初始微调的数据反映了用户在开始使用BI系统时的简单查询行为。随着时间的推移，用户的信息需求变得更加复杂，并需要更复杂的查询，这会使您的天真模型不堪重负。此外，公司的目标或战略可能会发生变化并漂移，并将信息需求引导到数据库的其他领域。最后，Text2SQL特定的挑战是数据库漂移。随着公司数据库的扩展，新的、未见过的列和表进入提示。虽然为多数据库应用程序设计的Text2SQL算法可以很好地处理此问题，但它可能会显着影响单数据库模型的准确性。所有这些问题最好通过反映用户当前的真实行为的微调数据集来解决。因此，记录用户问题和结果以及可以从使用中收集的任何相关反馈是至关重要的。此外，可以应用语义聚类算法，例如使用嵌入或主题建模，以检测用户行为中潜在的长期变化，并将其作为完善微调数据集的另一个信息来源
结论
让我们总结一下本文的要点：
- Text2SQL允许在业务中实现直观和民主的数据访问，从而最大化可用数据的价值。
- Text2SQL数据包括输入的问题和输出的SQL查询。问题和SQL查询之间的映射是多对多的。
- 提供数据库的信息作为提示的一部分非常重要。此外，可以优化数据库结构，使算法更容易学习和理解。
- 在输入上，主要的挑战是自然语言问题的语言变异性，可以使用在多种不同文本样式上进行预训练的LLM来解决
- Text2SQL的输出应该是一个有效的SQL查询。这个约束可以通过“注入”SQL知识到算法中来实现；或者，使用迭代方法，可以在多个步骤中检查和改进查询。
- 由于“无声失败”的潜在影响可能会为决策制定返回错误的数据，因此故障管理是用户界面中的主要关注点。
- 以“增强”的方式，用户可以积极参与SQL查询的迭代验证和改进。虽然这使应用程序不太流畅，但也减少了失败率，使用户可以以更灵活的方式探索数据，并为进一步的学习创建有价值的信号。
- 需要考虑的主要非功能性需求包括准确性、可扩展性、速度、可解释性、隐私和随时间的适应性。主要的权衡在于一方面是准确性，另一方面是可扩展性、速度和隐私。
参考文献
[1] Ken Van Haren. 2023. 用26个递归GPT提示替换SQL分析员
[2] Nitarshan Rajkumar等。2022。评估大型语言模型的文本到SQL能力
[3] Naihao Deng等。2023。文本到SQL的最新进展：我们拥有什么和我们期望什么的调查
[4] Mohammadreza Pourreza等。2023。DIN-SQL：具有自我校正的文本到SQL的分解上下文学习
[5] Victor Zhong等。2021。零-shot可执行语义解析的基于接地的适应
[6] Xi Victoria Lin等。2020。跨域文本到SQL语义解析的文本和表格数据桥接
[7] Tong Guo等。2019。内容增强的基于BERT的文本到SQL生成
[8] Torsten Scholak等。2021。PICARD：从语言模型逐步解析约束自回归解码
[9] Jinyang Li等。2023。Graphix-T5：将预训练的变压器与图形感知层混合用于文本到SQL解析
[10] LangChain。2023。LLMs和SQL
[11] Tao Yu等。2018。蜘蛛：用于复杂和跨域语义解析和文本到SQL任务的大规模人类标记数据集
[12] Ruiqi Zhong等。2020。带蒸馏测试套件的文本到SQL的语义评估
[13] Katherine Tian等。2023。只需询问校准：从人类反馈微调的语言模型获取校准置信度分数的策略
[14] Braden Hancock等。2019。部署后从对话中学习：喂养自己，聊天机器人！
[15] Ahmed Elgohary等。2020。与自然语言反馈进行交互式文本到SQL
所有图片均由作者提供。
