Uber 最近分享了他们的内部文本到 SQL 平台 QueryGPT，通过让员工简单地用自然语言提问并接收 SQL 查询作为回报，将查询编写时间缩短了 70%。考虑到他们每月运行约 120 万个查询，这意味着每月可节省惊人的 140,000 小时。

这篇文章，我们尝试拆解一下QueryGPT中，提升NL-to-SQL效果的技术设计，可以为智能数据分析产品设计做参考。

传统的数据分析方式往往需要专业的技术知识，如编写 SQL 查询语句，这对于非技术人员来说是一个巨大的门槛。自然语言转 SQL（NL-to-SQL）技术的出现，旨在打破这一壁垒，让任何人都能用通俗易懂的语言与数据进行交互，获取有价值的信息。但要实现这一目标，面临着诸多挑战，如何提升 NL-to-SQL 的表现成为了亟待解决的问题。

自然语言与数据库模式的鸿沟

NL-to-SQL 系统需要在人类自由格式的自然语言和复杂的数据库模式之间建立联系。自然语言灵活多变，充满了模糊性和歧义性，而数据库模式由严格的表、列、连接和转换构成，两者之间存在着巨大的差异。

例如，用户可能会问 “我们上季度在华东区的总销售额是多少？”，但系统很难直接理解 “上季度”“华东区”“总销售额” 这些自然语言表述在数据库中对应的具体内容。

虽然 LLM 非常擅长理解语言模式，但它们并不知道哪个表包含“销售”数据，或者“华东区”对应于地理维度表中的某些值。如果没有明确的定义，系统很容易出错或者幻觉。

QueryGPT 的技术架构

具体怎么实现呢，核心由四个主要的组件组成：工作区、意图Agent、表Agent、列修剪Agent。一起构成一个精简、高效的文本到 SQL 生成过程。

通过将解决方案细分为特定领域的工作区、通过意图Agent过滤查询、通过表Agent验证表选择以及在生成最终查询之前修剪不必要的列，QueryGPT 确保了高准确性、成本节约和快速周转。

工作区：聚焦业务领域的关键设计

工作区是 QueryGPT 中的一个重要概念，它是与特定业务领域（如行程、广告、核心服务等）紧密相关的 SQL 示例和表架构的精选集合。每个工作区都针对特定的业务需求进行了优化，包含了一组在该领域内常用的表和与之对应的 SQL 查询模板。

当用户与 QueryGPT 进行交互时，系统首先会对用户的查询进行分析，确定其所属的业务领域。例如，如果用户的问题涉及行程数据、驾驶员详细信息或车辆属性，系统会将其路由到移动工作区。在行程工作区内，QueryGPT 只会参考与出行和司机相关的表和 SQL 模式，而无需扫描整个庞大的数据库生态系统。

工作区的优势体现

• 提高查询准确性：通过将搜索空间限制在特定领域的参考范围内，QueryGPT 能够更精准地选择与用户问题相关的表和列，从而生成更准确的 SQL 查询。例如，在处理行程领域的查询时，系统只会关注与行程、司机或文件相关的表格，避免了在无关数据中搜索，减少了错误的可能性。
  

• 降低数据探索复杂性：对于用户来说，只需要面对与当前业务领域相关的表格，大大简化了数据探索的过程。他们无需在海量的数据库表中迷失方向，能够更快速地找到所需的数据，提高了工作效率。

• 支持用户定制化：除了 Uber 预先定义的系统工作区外，用户还可以根据自己的特定需求创建自定义工作区。这对于一些小众用例或新项目非常有用，用户可以根据自己的业务逻辑和数据需求，灵活地组织和管理相关的表和查询模板，实现个性化的数据访问和分析。

意图Agent：精准解读用户意图的导航仪

意图Agent在 QueryGPT 中起着至关重要的作用，它利用大型语言模型来对用户输入的自然语言问题进行深度分析。通过识别问题中的关键字、上下文信息以及语义特征，意图Agent试图将用户的查询准确映射到一个或多个业务领域工作区。

在实际应用中，许多查询可能涉及多个业务领域。例如，一个关于分析行程数据与广告效果之间关系的问题，就需要同时涉及行程工作区和广告工作区的数据。意图Agent能够智能地识别这种跨域需求，并将问题正确地映射到多个相关的工作区，确保查询能够获取到全面准确的数据。

由于意图Agent能够快速准确地确定相关工作区，QueryGPT 在后续的查询生成过程中只需在这些有限的范围内进行搜索和处理，大大减少了搜索不相关模式所带来的计算开销。这不仅提高了查询生成的准确性，还显著缩短了整体的查询响应时间，提升了系统的性能和用户体验。

表Agent：确保数据准确性的把关者

在确定了相关的业务领域后，表Agent会根据用户的意图和所选工作区的内容，从众多可能的表中筛选出构建 SQL 查询所需的最相关候选表。它会综合考虑多个因素，如示例查询中涉及的表、表之间的关系以及特定领域的知识，来判断哪些表最有可能包含用户所需的数据。

表Agent会将所选表格的摘要展示给用户，并要求用户进行确认。这一用户验证机制是确保生成 SQL 质量的关键环节。用户作为领域专家，能够凭借自己的实际经验判断系统选择的表格是否正确。如果系统选择了过时的表格或遗漏了新的重要表格，用户可以在继续查询之前进行编辑和调整，从而保证了数据的准确性和可靠性。

这种人机协作的方式有效地弥补了自动查询生成与用户领域专业知识之间的差距。数据分析师等熟悉特定业务模式的用户可以通过参与表选择过程，确保 QueryGPT 引用的数据源准确无误，提高了系统生成的 SQL 查询的实用性和有效性，同时也增强了用户对系统的信任和依赖。

列修剪Agent：优化查询性能的利器

在企业级的数据环境中，大型数据模式往往非常复杂，每个表可能包含数百列甚至更多。当将这些数据输入到语言模型中时，过多的列信息可能会导致令牌限制问题，尤其是在使用具有较高令牌容量的模型（如 GPT - 4 Turbo）时也可能会超出其处理能力。这不仅会影响查询生成的效率，还可能导致模型无法正常工作。

通过使用 LLM 调用来智能地过滤掉那些不太可能与用户问题相关的列。它会根据用户的查询意图、已选择的表以及表之间的关系等信息，对列进行筛选，只保留对回答问题最关键的列信息。这样做大大减少了传递到后续查询生成步骤的信息量，降低了数据处理的复杂度。

• 降低成本与提高速度：由于涉及的令牌数量减少，QueryGPT 在每次 LLM 调用时所需的计算资源和成本也相应降低。同时，查询处理速度得到显著加快，系统能够更快速地响应用户的查询请求，提高了整体的性能和效率。

• 减少错误与提高准确性：处理更精简、更有针对性的列信息可以减少模型在选择字段时出错的机会。模型能够更专注于与问题相关的关键数据，从而生成更清晰、准确的 SQL 输出，提高了查询结果的质量和可靠性。

评估和优化

为了跟踪 QueryGPT 性能的逐步改进，需要一个标准化的评估程序。能够区分服务的重复缺陷和异常缺陷，并确保算法变化在总体上逐步提高性能。 

程序构建完并不是AI应用软件开发的终点，收集反馈、创建数据、优化效果是一个持续的过程。未来这种模式会成为软件的主流模式，有人称之为软件2.0。

评估集

团队从 QueryGPT 的日志中精心挑选出一系列真实的问题，这些问题涵盖了各种类型和业务场景，能够反映用户在实际使用过程中的需求。并手动验证正确的意图、回答问题所需的架构和黄金 SQL。构建评估集需要大量的人工投入。

评估程序

对于评估中的每个问题，评估一下项目：

• 意图：分配给问题的意图是否准确？ 

• 表重叠：通过搜索 + 表代理识别的表是否正确？这表示为 0 到 1 之间的分数。例如，如果查询需要回答“上周洛杉矶有多少行程被司机取消？”的问题，需要使用 [ fact_trip_state，dim_city ]，而 QueryGPT 识别出 [ dim_city，fact_eats_trip ]，则此输出的搜索重叠分数将为 0.5，因为选择了回答该问题所需的两个表之一。 

• 运行成功：生成的查询是否运行成功？ 

• 运行有输出：查询执行是否返回 > 0 条记录。（有时，QueryGPT 会产生像 WHERE status = “Finished” 这样的过滤器，而过滤器应该是 WHERE status = “Completed”，导致运行成功而没有输出）。 

• 定性查询相似度：生成的查询与黄金 SQL 有多相似？我们使用 LLM 分配 0 到 1 之间的相似度分数。这使我们能够快速查看由于语法原因而失败的生成查询在所使用的列、连接、应用的函数等方面是否正确。 

对一段时间内的进展进行可视化，以识别回归和模式，揭示需要改进的领域。汇总每次评估运行的准确性和延迟指标，以跟踪一段时间内的性能。 

局限性

LLM 的不确定性使相同评估可能产生不同结果；Uber 数据集众多且文档程度不一，评估集难以覆盖所有业务问题；同一问题可能有多种正确答案。因此，主要关注长期误差模式，根据产品变化更新评估集，并通过 LLM 评估生成查询与标准 SQL 的意图相似性。