Creating An Information Edge With Conversational Access To Data

由柏拉图重新发布

关注： 0

用于数据分析的对话式人工智能

图 1：Text2SQL 流程的表示

随着我们的世界变得更加全球化和动态，企业越来越依赖数据来做出明智、客观和及时的决策。然而，到目前为止，释放组织数据的全部潜力通常是少数数据科学家和分析师的特权。大多数员工不掌握传统的数据科学工具包（SQL、Python、R 等）。为了访问所需的数据，他们需要通过一个附加层，分析师或 BI 团队将业务问题的散文“翻译”为数据语言。此过程中出现摩擦和效率低下的可能性很高——例如，数据的交付可能会延迟，甚至问题已经过时。当需求没有准确地转化为分析查询时，信息可能会丢失。此外，生成高质量的见解需要采用迭代方法，而循环中的每一个额外步骤都不鼓励这种方法。另一方面，这些临时交互对昂贵的数据人才造成了干扰，并分散了他们对更具战略性的数据工作的注意力，正如数据科学家的这些“自白”所述：

当我在 Square 时，团队规模较小，我们有一个可怕的“随叫随到的分析”轮换。它严格每周轮换一次，如果你来的话，你知道那周你几乎不会完成什么“真正”的工作，并且大部分时间都花在回答来自各个产品和运营团队的临时问题上。公司（我们称之为 SQL 猴子）。分析团队中经理职位的竞争非常激烈，我认为这完全是经理被免除轮换的结果——没有任何地位奖励可以与不做随叫随到的工作相比。[1]

事实上，直接与数据对话而不是与数据人员进行多轮交互不是很酷吗？这一愿景得到了对话界面的支持，它允许人类使用语言与数据进行交互，语言是我们最直观和通用的沟通渠道。解析问题后，算法将其编码为所选查询语言（例如 SQL）中的结构化逻辑形式。因此，非技术用户可以与他们的数据进行交流，并快速获取特定、相关和及时的信息，而无需绕道 BI 团队。在本文中，我们将考虑 Text2SQL 的不同实现方面，并重点关注使用大型语言模型 (LLM) 的现代方法，这些方法迄今为止实现了最佳性能（参见 [2]；有关替代方法的调查）除法学硕士外，读者可参考[3]）。本文根据规划和构建人工智能功能时要考虑的主要元素的以下“心智模型”进行结构：

让我们从最终目的开始，回顾一下其价值——为什么要在数据或分析产品中构建 Text2SQL 功能。三个主要好处是：

商业用户 可以直接、及时地访问组织数据。
这缓解了 数据科学家和分析师 减轻业务用户临时请求的负担，使他们能够专注于高级数据挑战。
这允许商业以更加流畅和更具战略性的方式利用数据，最终将其转化为决策的坚实基础。

现在，您可能会考虑 Text2SQL 的产品场景是什么？三个主要设置是：

您提供的是 可扩展的数据/BI产品 并希望让更多用户能够以非技术方式访问他们的数据，从而扩大使用量和用户群。举个例子，ServiceNow 有将数据查询集成到更大的对话产品中及阿特朗最近宣布自然语言数据探索.
您正在寻求在数据/人工智能领域构建一些东西，以使公司中的数据访问民主化，在这种情况下，您可能会考虑 以 Text2SQL 为核心的 MVP。供应商喜欢人工智能2SQL 和 Text2sql.ai 已经进入这个领域。
您正在研究一个 定制BI系统 并希望在各个公司中最大化和民主化其使用。

正如我们将在以下部分中看到的，Text2SQL 需要一个不简单的预先设置。要估计投资回报率，请考虑要支持的决策的性质以及可用数据。在数据快速变化且在投资、营销、制造和能源行业等决策制定中积极且频繁使用的动态环境中，Text2SQL 绝对是赢家。在这些环境中，传统的知识管理工具过于静态，更流畅的数据和信息访问方式可以帮助公司产生竞争优势。就数据而言，Text2SQL 提供的数据库最大价值是：

规模庞大且不断增长，以便随着越来越多的数据被利用，Text2SQL 可以随着时间的推移展现其价值。
高音质，这样 Text2SQL 算法就不必处理数据中过多的噪声（不一致、空值等）。一般来说，应用程序自动生成的数据比人类创建和维护的数据具有更高的质量和一致性。
语义成熟 与原始数据相反，这样人们就可以根据其心智模型中存在的中心概念、关系和指标来查询数据。请注意，语义成熟度可以通过额外的转换步骤来实现，该转换步骤使原始数据符合概念结构（参见“用数据库信息丰富提示”部分）。

下面我们将深入探讨Text2SQL特性的数据、算法、用户体验以及相关的非功能需求。本文是为产品经理、UX 设计师以及刚刚开始 Text2SQL 之旅的数据科学家和工程师编写的。对于这些人来说，它不仅提供了入门指南，而且还提供了围绕产品、技术和业务之间的接口（包括相关权衡）进行讨论的共同知识基础。如果您在实施方面已经比较先进，那么最后的参考资料将提供一系列可供深入探索的内容。

如果这些深入的教育内容对您有用，则可以订阅我们的AI研究邮件列表当我们发布新材料时被提醒。

1。数据

任何机器学习工作都是从数据开始的，因此我们将首先阐明训练和预测期间使用的输入和目标数据的结构。在整篇文章中，我们将使用图 2 中的 Text1SQL 流作为我们的运行表示，并以黄色突出显示当前考虑的组件和关系。

1.1 数据的格式和结构

通常，原始 Text2SQL 输入输出对由自然语言问题和相应的 SQL 查询组成，例如：

问题“列出每个用户的姓名和关注者数量。”

SQL查询:

从用户个人资料中选择姓名、关注者

在训练数据空间中，问题和 SQL 查询之间的映射是多对多的：

一个 SQL 查询可以映射为许多不同的自然语言问题；例如，上述查询语义可以表示为：“显示每个用户的姓名和关注者数量“”每个用户有多少关注者？“等
SQL 语法非常通用，几乎每个问题都可以用 SQL 多种方式表示。最简单的示例是 WHERE 子句的不同顺序。从更高级的角度来看，每个做过 SQL 查询优化的人都会知道，许多道路都通向相同的结果，而语义上等效的查询可能具有完全不同的语法。

手动收集 Text2SQL 的训练数据尤其繁琐。它不仅需要注释者掌握 SQL，而且每个示例比情感分析和文本分类等更一般的语言任务需要更多的时间。为了确保足够数量的训练示例，可以使用数据增强——例如，LLM 可用于为同一问题生成释义。 [3] 提供了对 Text2SQL 数据增强技术的更完整的调查。

1.2 用数据库信息丰富提示

Text2SQL 是一种连接非结构化数据和结构化数据的算法。为了获得最佳性能，在训练和预测期间需要同时存在两种类型的数据。具体来说，该算法必须了解所查询的数据库，并能够以可以针对数据库执行的方式制定查询。这些知识可以包括：

数据库的列和表
表之间的关系（外键）
数据库内容

合并数据库知识有两种选择：一方面，训练数据可以仅限于为特定数据库编写的示例，在这种情况下，直接从 SQL 查询及其到问题的映射中学习模式。这种单一数据库设置允许优化单个数据库和/或公司的算法。然而，它消除了任何可扩展性的野心，因为模型需要针对每个客户或数据库进行微调。或者，在多数据库设置中，可以将数据库模式作为输入的一部分提供，从而允许算法“泛化”到新的、未见过的数据库模式。如果您想在许多不同的数据库上使用 Text2SQL，您绝对需要采用这种方法，但请记住，它需要大量的即时工程工作。对于任何合理的业务数据库，在提示中包含完整信息将是极其低效的，并且由于提示长度限制很可能是不可能的。因此，负责提示制定的功能应该足够聪明，能够选择对给定问题最“有用”的数据库信息子集，并对可能不可见的数据库执行此操作。

最后，数据库结构起着至关重要的作用。在您对数据库有足够控制权的情况下，您可以通过让模型从直观的结构中学习来使模型的工作更轻松。根据经验，您的数据库越能反映业务用户如何谈论业务，您的模型就能从中更好更快地学习。因此，考虑对数据应用额外的转换，例如将规范化或以其他方式分散的数据组装到宽表或数据仓库中，以明确且明确的方式命名表和列等。您可以预先编码的所有业务知识都会减少减轻模型的概率学习负担并帮助您取得更好的结果。

2。算法

Text2SQL 是一种 语义解析 ——文本到逻辑表示的映射。因此，算法不仅要“学习”自然语言，还要“学习”目标表示——在我们的例子中是 SQL。具体来说，它必须获取以下知识：

SQL 语法和语义
数据库结构
自然语言理解（NLU）
自然语言和 SQL 查询之间的映射（句法、词汇和语义）

2.1 解决输入中的语言变异性

在输入方面，Text2SQL的主要挑战在于语言的灵活性：正如数据的格式和结构一节中所述，同一个问题可以用多种不同的方式解释。此外，在现实生活中的对话环境中，我们必须处理许多问题，例如拼写和语法错误、不完整和模糊的输入、多语言输入等。

GPT 模型、T5 和 CodeX 等法学硕士越来越接近解决这一挑战。他们从大量不同的文本中学习，学会处理大量的语言模式和不规则之处。最终，他们能够概括出尽管表面形式不同但语义相似的问题。法学硕士可以开箱即用（零样本）或经过微调后应用。前者虽然方便，但精度较低。后者需要更多的技能和工作，但可以显着提高准确性。

在准确性方面，正如预期的那样，性能最好的模型是 GPT 系列的最新模型，包括 CodeX 模型。 2023 年 4 月，GPT-5 的准确率比之前最先进的技术显着提高了 85.3% 以上，达到 4% 的准确率（以“值执行”为衡量标准）。 [2] 在开源阵营中，解决 Text5SQL 难题的最初尝试集中在自动编码模型上，例如 BERT，它擅长 NLU 任务。[6] 然而，在围绕生成式 AI 的炒作中，最近的方法侧重于在自回归模型（例如 T7 模型）上。 T5 使用多任务学习进行了预训练，因此可以轻松适应新的语言任务，包括。语义分析的不同变体。然而，在语义解析任务方面，自回归模型有一个内在的缺陷：它们有不受约束的输出空间，并且没有限制其输出的语义护栏，这意味着它们可以在行为中获得惊人的创造力。虽然这对于生成自由格式的内容来说是令人惊奇的东西，但对于像 Text5SQL 这样我们期望得到受约束的、结构良好的目标输出的任务来说却很麻烦。

2.2 查询验证和改进

为了限制 LLM 输出，我们可以引入额外的机制来验证和改进查询。正如 PICARD 系统中所提议的，这可以作为额外的验证步骤来实现。[8] PICARD 使用 SQL 解析器，可以验证部分 SQL 查询在完成后是否可以生成有效的 SQL 查询。在 LLM 的每个生成步骤中，会使查询无效的令牌将被拒绝，并保留最高概率的有效令牌。由于具有确定性，只要解析器遵守正确的 SQL 规则，这种方法就能确保 100% SQL 有效性。它还将查询验证与生成分离，从而允许彼此独立地维护两个组件以及升级和修改 LLM。

另一种方法是将结构和 SQL 知识直接纳入法学硕士。例如，Graphix [9] 使用图形感知层将结构化 SQL 知识注入到 T5 模型中。由于这种方法的概率性质，它使系统偏向于正确的查询，但不能保证成功。

最后，LLM 可以用作多步骤代理，可以自主检查和改进查询。 [10] 通过使用思维链提示中的多个步骤，代理可以负责反思其自身查询的正确性并改进任何缺陷。如果经过验证的查询仍然无法执行，则可以将 SQL 异常回溯传递给代理作为改进的附加反馈。

除了这些发生在后端的自动化方法之外，还可以让用户参与查询检查过程。我们将在用户体验部分对此进行更详细的描述。

2.3评估

为了评估我们的 Text2SQL 算法，我们需要生成一个测试（验证）数据集，在其上运行我们的算法并对结果应用相关的评估指标。分割为训练、开发和验证数据的原始数据集将基于问题-查询对，并导致次优结果。验证查询可能会在训练期间向模型透露，并导致对其泛化能力过于乐观。 A 基于查询的分割，其中数据集的分割方式使得在训练和验证期间都不会出现查询，从而提供更真实的结果。

就评估指标而言，我们在 Text2SQL 中关心的并不是生成与黄金标准完全相同的查询。这 “精确的字符串匹配” 方法过于严格，会产生许多漏报，因为不同的 SQL 查询可能会导致返回相同的数据集。相反，我们想要实现高 语义准确性 并评估预测查询和“黄金标准”查询是否始终返回相同的数据集。有三个评估指标可以接近这个目标：

精确设置的匹配精度：生成的 SQL 查询和目标 SQL 查询被分为其组成部分，并对结果集进行身份比较。[11] 这里的缺点是它只考虑了 SQL 查询中的顺序变化，而没有考虑语义等效查询之间更明显的语法差异。
执行精度：比较生成的 SQL 查询和目标 SQL 查询生成的数据集的同一性。运气好的话，具有不同语义的查询仍然可以在特定数据库实例上通过此测试。例如，假设数据库中所有用户的年龄都超过 30 岁，以下两个查询将返回相同的结果，尽管语义不同：
从用户中选择 *
从年龄 > 30 岁的用户中选择 *
测试套件的准确性：测试套件准确性是执行准确性的更高级且不太宽松的版本。对于每个查询，都会生成一组数据库（“测试套件”），这些数据库在查询中的变量、条件和值方面具有高度差异性。然后，在每个数据库上测试执行准确性。虽然需要额外的努力来设计测试套件的生成，但该指标还显着降低了评估中误报的风险.[12]

3.用户体验

当前最先进的 Text2SQL 不允许完全无缝集成到生产系统中 - 相反，有必要积极管理用户的期望和行为，用户应该始终意识到她正在与一个人工智能系统。

3.1 故障管理

Text2SQL 可能会以两种模式失败，需要以不同的方式捕获：

SQL 错误：生成的查询无效 - SQL 无效，或者由于词法或语义缺陷而无法针对特定数据库执行。在这种情况下，无法将结果返回给用户。
语义错误：生成的查询是有效的，但它没有反映问题的语义，从而导致返回错误的数据集。

第二种模式特别棘手，因为“无声故障”（用户未检测到的错误）的风险很高。典型用户既没有时间也没有技术技能来验证查询和/或结果数据的正确性。当数据用于现实世界中的决策时，这种失败可能会产生毁灭性的后果。为了避免这种情况，教育用户并建立 业务层面的护栏 限制潜在影响，例如对具有更高影响力的决策进行额外的数据检查。另一方面，我们还可以使用用户界面来管理人机交互，帮助用户检测和改进有问题的请求。

3.2 人机交互

用户可以不同程度地参与你的人工智能系统。每个请求更多的交互可以带来更好的结果，但它也会降低用户体验的流畅性。除了错误查询和结果的潜在负面影响之外，还要考虑用户提供来回反馈的积极性，以获得更准确的结果，并有助于长期改进产品。

最简单且最不吸引人的方法是使用置信度分数。虽然将置信度简单地计算为生成标记的概率的平均值过于简单，但可以使用更高级的方法，例如口头反馈。 [13] 置信度可以显示在界面中，并通过明确的警报突出显示，以防置信度过低。这样，在“现实世界”中适当跟进的责任——无论是拒绝、接受还是对数据进行额外检查——就落在了用户的肩上。虽然这对供应商来说是一个安全的选择，但将这项工作转移给用户也会降低产品的价值。

第二种可能性是在出现低置信度、模糊或其他可疑查询的情况下让用户进行澄清对话。例如，您的系统可能会建议对输入进行拼写或语法更正，并要求消除特定单词或语法结构的歧义。它还可能允许用户主动请求更正查询：[14]

用户： 显示 John 在本次冲刺中的任务。

助理： 您想查看约翰创建的任务或他正在处理的任务吗？

用户： 约翰创建的任务

助理： 好的，这是任务 ID：

用户： 谢谢，我还想查看有关任务的更多信息。还请按紧急程度排序。

助理： 当然，这里有任务以及简短的描述、受让人和截止日期，按截止日期排序。

最后，为了方便用户对查询的理解，您的系统还可以提供查询的明确文本重新表述，并要求用户确认或更正它。 [15]

4、非功能性需求

在本节中，我们讨论 Text2SQL 的特定非功能性需求以及它们之间的权衡。我们将重点关注对于该任务来说最重要的六个要求：准确性、可扩展性、速度、可解释性、隐私性和随着时间的推移的适应性。

4.1精度

对于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 查询之间的映射是多对多的。
作为提示的一部分提供有关数据库的信息非常重要。此外，还可以优化数据库结构，使算法更容易学习和理解。
在输入方面，主要挑战是自然语言问题的语言变异性，可以使用在各种不同文本样式上进行预训练的法学硕士来解决这个问题
Text2SQL 的输出应该是有效的 SQL 查询。这个约束可以通过将 SQL 知识“注入”到算法中来纳入；或者，使用迭代方法，可以通过多个步骤检查和改进查询。
由于返回错误数据以供决策的“无声故障”的潜在影响很大，因此故障管理是用户界面中的主要关注点。
以“增强”的方式，用户可以积极参与 SQL 查询的迭代验证和改进。虽然这降低了应用程序的流畅性，但也降低了故障率，允许用户以更灵活的方式探索数据，并为进一步学习创建有价值的信号。
需要考虑的主要非功能性需求是准确性、可扩展性、速度、可解释性、隐私性和随着时间的推移的适应性。主要的权衡一方面是准确性，另一方面是可扩展性、速度和隐私。