【AI落地】Uber QueryGPT如何让AI实现自然语言转SQL

最近在折腾一个自动驾驶业务的数据仓库升级。说起来都是泪，这仓库一开始就没怎么系统设计，不同车型的数据处理链路长得都差不多，但每个车型都有一堆功能重复、逻辑雷同、名字还特别像的数据表，光表名就上百个。我们除了打算做中间层来复用，还想着能不能靠大模型搞个Text-to-SQL，让数据分析师直接说人话就能查数据，省去那些认知负担，提升运营效率。调研的时候，发现Uber的一篇博客介绍了他们内部的QueryGPT，思路跟我们想得很像，很有参考价值。今天就结合自己的阅读心得，聊聊这个QueryGPT。

为什么这个项目值得关注？

首先得说，这可不是什么实验室里的Demo，而是Uber内部已经在用的实战工具。官方数据是，他们每个月要处理120万次数据查询，光是运营团队就占了36%。想想看，一家体量这么大的公司，敢把核心数据查询交给AI来处理，这事儿本身就很有意思。

更关键的是效果。原本写一条SQL查询需要10分钟，现在3分钟就能搞定。做过数据分析的都懂，这效率提升有多夸张。他们内部小范围测试时，每天大概有300个活跃用户，其中78%的用户反馈说这工具确实帮他们省了大把时间。

QueryGPT是怎么工作的？

从技术架构看，QueryGPT的设计很有借鉴意义。它没有简单地把问题甩给大语言模型，而是设计了一套多阶段、智能化的处理流程。

：这个设计很巧妙。他们把不同业务场景的SQL知识分门别类，就像给AI配了不同的“专家组”。比如要查打车数据，就调用出行相关的知识库。这样做大大提高了准确率。

：这是整个流程的核心，每个Agent各司其职，又紧密配合。

• Intent Agent
  ：负责理解用户意图，把自然语言问题映射到特定的业务领域。比如用户问“昨天西雅图有多少订单？”，它就知道这是一个出行业务的查询，涉及时间和地理维度的订单统计。

• Table Agent
  ：根据意图来选择最相关的数据表。不仅要找出主表，还要考虑可能需要关联的维度表，比如用户表、城市表。用户还可以确认或修改Table Agent的选择，这种人机协作的方式平衡了效率和准确性。

• Column Prune Agent
  ：这是一个非常聪明的优化器。它会分析查询需求和表结构，只保留真正需要的字段。想象一下，一张有200多列的表，查询可能只需要5-6个字段，Column Prune Agent就能帮我们精准筛选，既优化了性能，又节省了token。

这种多Agent协作的设计特别有想象力。每个Agent专注自己的任务，又能无缝配合，最终输出高质量的SQL。而且，这种设计大大降低了“幻觉”的风险，因为每个环节都有明确的约束和验证机制。

从MVP到生产：架构演进之路

QueryGPT的架构不是一天建成的，而是经历了20多个版本的迭代才走到今天。这个过程完整展示了企业级AI应用从概念验证到生产系统的完整路径。

最小可行产品（MVP）阶段

最初版本其实出奇地简单：只用了7个核心数据表和20个SQL样本，采用基础的RAG（检索增强生成）系统，做了简单的向量相似度搜索。这个版本虽然简陋，但关键验证了可行性。有趣的是，它在小规模场景下表现还不错。

遇到的挑战

但当他们开始扩大规模时，三个典型问题就冒出来了：

1. 相似度搜索不够精准
   ：直接用自然语言去搜SQL样本，匹配度往往不太理想。

2. 理解用户意图困难
   ：从自然语言直接映射到数据表结构，难度很大。

3. Token限制
   ：一些数据表超过200列，光是描述一张表就能占用大量tokens。

这些问题很有代表性，相信很多做企业AI应用的团队都深有体会。

现有架构的亮点

Uber团队的解决方案很优雅，核心就两点：

：按业务领域（如出行、广告、IT等）划分知识库，每个工作空间包含特定的SQL样本和表结构，支持系统预置和自定义。

：一个清晰的分步处理流程：

用户自然语言问题  
→ Intent Agent（理解查询意图并确定业务领域）
→ Table Agent（选择和确认相关数据表）  
→ Column Prune Agent（优化表结构和字段选择）
→ SQL Generation（生成最终查询）

这种流水线设计的优势很明显：每个Agent职责单一，便于优化和维护；Agent之间相互配合，形成了强大的错误校正机制；用户也能在关键节点介入和调整。

下图是Table Agent和用户的互动：

：Column Prune Agent的设计尤其值得琢磨。它不是简单地删字段，而是会分析查询语义，理解所需的维度和指标，保留必要的关联字段，确保统计汇总字段的完整性，同时维持表间关系的正确性。

如何评估AI系统的效果？

Uber团队在评估上做得也很到位。他们采用两种评估流程：

1. 原生流程
   ：完全自动化的端到端测试。

2. 解耦流程
   ：允许人工干预的组件级测试。

评估指标包括：

• 意图识别准确率
• 表格选择准确率（用重叠度衡量）
• SQL执行成功率
• 查询结果有效率
• 与标准SQL的相似度

特别值得一提的是，他们使用了基于LLM的相似度评分，来比较生成的SQL与标准SQL的差异，这确实是个很有创意的做法。

评估中的发现

评估过程中也有一些有趣的发现：

1. 非确定性问题
   ：同样的问题，可能得到略有不同的SQL。

2. 覆盖率挑战
   ：不可能测试所有可能的业务场景。

3. 多样性答案
   ：同一个问题可能有多种正确的SQL写法。

技术选型的考虑

从技术栈来看，Uber选的是：OpenAI的GPT-4 Turbo（128K上下文窗口）、向量数据库存储SQL样本、多个专门的AI Agent协作。

这些选择背后的考虑很值得分析：

• GPT-4的高准确率很重要，毕竟SQL写错了成本很高。
• 大上下文窗口对处理复杂表结构很关键。
• 多Agent架构提供了更好的可控性和可扩展性。

给企业的启示

这个项目给我们几个重要启示：

：别为了用AI而用AI。Uber选数据查询这个场景很聪明，因为它有明确的效率提升指标，有大量重复性工作，而且错误成本可控（生成的SQL会经过人工确认）。

：从黑客松的一个小项目起步，经过20多次迭代才到现在的版本。这种稳扎稳打、小步快跑的方式值得所有团队学习。

：系统不是完全自动化的，在关键环节保留了人工确认。比如SQL生成后，用户可以检查和修改。这种设计既保证了效率，又控制了风险。

给开发者的建议

如果想开发类似系统，有几点建议值得参考：

1. 从小场景开始
   ：先圈定一个业务领域，用少量表和SQL样本验证想法，然后快速迭代改进。

2. 重视数据质量
   ：精心挑选SQL样本，确保表结构文档准确，建立完善的评估数据集。

3. 设计合理的评估体系
   ：建立量化指标，支持组件级测试，同时收集用户反馈。

4. 注意性能和成本
   ：优化token使用，减少不必要的API调用，合理使用缓存。

存在的问题和挑战

当然，这个系统也不是完美的：

1. AI的“幻觉”问题仍然存在，有时会生成包含不存在表格或字段的SQL。
2. 用户提问不够精准时，系统需要额外处理才能理解意图。
3. 对AI模型的token限制仍然是个挑战，特别是处理大型数据表时。

未来发展方向

展望一下，QueryGPT这类系统未来可能会朝着几个方向演进：

：支持多轮对话，理解业务上下文，处理模糊查询。

：减少“幻觉”问题，提供查询建议，自动优化性能。

：解释查询逻辑，可视化数据流，提供优化建议。

写在最后

QueryGPT是企业级AI应用的一个优秀范本。它告诉我们如何把AI技术落地到具体业务场景，如何平衡效率和可靠性，以及如何循序渐进地推进AI项目。对于正在考虑AI转型的团队来说，这个项目提供了大量可借鉴的实战经验。

如果对某个技术细节感兴趣，欢迎留言交流。