最近在着力升级一个自动驾驶业务分析的数据仓库。由于历史原因，该数据仓库一开始没有经过系统设计，不同车型的数据处理链路高度相似，但每个车型都有一套功能类似、逻辑重复、名称相近的数据表，光表名就有上百个。除了构建中间层做复用外，还打算借助大模型通过Text-to-SQL来实现通过自然语言查询数据，从而减少数据分析师的认识负担，提升业务运营效率。在调研过程中，发现Uber在博客中介绍了QueryGPT，实现了类似功能，具有相当的借鉴性。于是结合自己的阅读心得，介绍一下QueryGPT。其原文链接?如下：

https://www.uber.com/en-HK/blog/query-gpt/?uclick_id=0ac2178a-ff45-42ee-bd2d-43ba9c3f95e9

Uber最近公开了他们内部的一个AI工具QueryGPT，这个工具可以让完全不懂SQL的人也能轻松查询数据。作为关心AI在数据领域实践的一线研发，我第一时间研究了这个项目，今天就来给大家详细解读一下。

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

首先，这不是一个实验性项目，而是已经在Uber内部实际使用的工具。据官方透露，他们每月要处理120万次数据查询，其中运营团队就占了36%。想想看，一个这么大体量的公司，居然敢用AI来处理核心数据查询需求，这本身就很有意思。

更让我惊讶的是其实际效果：原本需要10分钟才能写出来的SQL查询，现在3分钟就能搞定。如果你做过数据分析，就知道这个效率提升有多大。在他们的小范围测试中，每天有约300个活跃用户，78%的用户表示这个工具确实帮他们节省了大量时间。

QueryGPT是怎么工作的？

从技术角度来看，QueryGPT的架构设计很有借鉴意义。它不是简单地把问题丢给大语言模型，而是采用了一个多阶段的智能处理流程：

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

2. 多Agent协作系统：

• Intent Agent：负责理解用户的查询意图，将自然语言问题映射到特定的业务域。例如，当用户问"昨天西雅图有多少订单？"，Intent Agent会识别这是一个出行业务的查询请求，涉及时间和地理维度的订单统计。

• Table Agent：基于Intent 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团队的解决方案很优雅，主要包括：

1. 工作空间机制

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

2. Agent流水线模式

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

这种流水线设计的优势在于：

• 每个Agent职责单一，便于优化和维护
• Agents之间的配合形成了强大的错误校正机制
• 用户可以在关键节点进行干预和调整

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

3. 智能化的表结构处理 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架构提供了更好的可控性和可扩展性

给企业的启示

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

1. AI落地要解决实际问题 不要为了用AI而用AI。Uber选择数据查询这个场景很合适，因为：

• 有明确的效率提升指标
• 有大量重复性工作
• 错误成本可控（生成的SQL会经过人工确认）

2. 循序渐进的开发策略 他们从黑客松的小项目开始，经过20多次迭代才到现在的版本。这种稳扎稳打的方式值得学习。

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

给开发者的建议

如果想开发类似系统，建议：

1. 从小场景开始

• 先选择一个业务领域
• 用少量表和SQL样本验证想法
• 快速迭代改进

2. 重视数据质量

• 精心挑选SQL样本
• 确保表结构文档准确
• 建立完善的评估数据集

3. 设计合理的评估体系

• 建立量化指标
• 支持组件级测试
• 收集用户反馈

4. 注意性能和成本

• 优化token使用
• 减少不必要的API调用
• 合理使用缓存

存在的问题和挑战

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

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

未来发展方向

我认为QueryGPT这类系统未来可能的发展方向包括：

1. 更智能的意图理解

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

2. 更强的可靠性

• 减少"幻觉"问题
• 提供查询建议
• 自动优化性能

3. 更好的可解释性

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

写在最后

QueryGPT是企业级AI应用的一个优秀案例。它展示了如何把AI技术落地到具体业务场景，如何平衡效率和可靠性，以及如何循序渐进地推进AI项目。对于正在考虑AI转型的企业来说，这个项目提供了很多可借鉴的经验。

如果你对某个技术细节特别感兴趣，欢迎留言讨论。如果觉得这篇文章有帮助，别忘了点赞关注，我会持续分享更多AI领域的深度解读！