最近在着力升级一个自动驾驶业务分析的数据仓库。由于历史原因，该数据仓库一开始没有经过系统设计，不同车型的数据处理链路高度相似，但每个车型都有一套功能类似、逻辑重复、名称相近的数据表，光表名就有上百个。除了构建中间层做复用外，还打算借助大模型通过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的架构设计很有借鉴意义。它不是简单地把问题丢给大语言模型，而是采用了一个多阶段的智能处理流程：
工作空间系统：这个设计很巧妙。他们把不同业务场景的SQL知识分门别类，就像给AI配了不同的"专家组"。比如要查询打车数据，就调用出行相关的知识库。这样大大提高了准确率。
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）阶段
最初版本其实出奇简单：
这个版本虽然简单，但验证了可行性。有趣的是，它在小规模场景下表现还不错。
遇到的挑战
但是，当他们开始扩大规模时，遇到了三个典型问题：
- 相似度搜索不够精准：用自然语言直接搜SQL样本，匹配度往往不理想
- 理解用户意图困难：直接从自然语言映射到数据表结构有很大难度
- token限制：一些数据表超过200列，单表描述就能占用大量tokens
这些问题其实很有代表性，相信很多做企业AI应用的团队都会遇到。
现有架构的亮点
Uber团队的解决方案很优雅，主要包括：
用户自然语言问题
→ Intent Agent（理解查询意图并确定业务领域）
→ Table Agent（选择和确认相关数据表）
→ Column Prune Agent（优化表结构和字段选择）
→ SQL Generation（生成最终查询）
这种流水线设计的优势在于：
下图是Table Agent和用户的互动：
TableAgent- 智能化的表结构处理 Column Prune Agent的设计特别值得关注。它不是简单地删除字段，而是会：
如何评估AI系统的效果？
Uber团队在评估方面的做法很值得借鉴。他们采用了两种评估流程：
评估指标包括：
特别值得一提的是，他们使用了基于LLM的相似度评分，来比较生成的SQL与标准SQL的差异。这是个很创新的做法。
评估中的发现
一些有意思的发现：
- 非确定性问题：同样的问题，可能得到略有不同的SQL
技术选型的考虑
从技术栈来看，Uber选择了：
- OpenAI的GPT-4 Turbo（128K上下文窗口）
这些选择背后的考虑因素值得分析：
- GPT-4的高准确率很重要，因为SQL错误的成本较高
给企业的启示
这个项目给我们几个重要启示：
- AI落地要解决实际问题 不要为了用AI而用AI。Uber选择数据查询这个场景很合适，因为：
循序渐进的开发策略 他们从黑客松的小项目开始，经过20多次迭代才到现在的版本。这种稳扎稳打的方式值得学习。
合理的人机协作 系统不是完全自动的，在关键环节保留了人工确认环节。比如SQL生成后，用户可以检查和修改。这种设计既保证了效率，又控制了风险。
给开发者的建议
如果想开发类似系统，建议：
存在的问题和挑战
当然，这个系统也不是完美的：
- AI的"幻觉"问题仍然存在，有时会生成包含不存在表格或字段的SQL。
- 用户提问不够精准时，系统需要额外处理才能理解意图。
- 对AI模型的token限制仍然是个挑战，特别是处理大型数据表时。
未来发展方向
我认为QueryGPT这类系统未来可能的发展方向包括：
写在最后
QueryGPT是企业级AI应用的一个优秀案例。它展示了如何把AI技术落地到具体业务场景，如何平衡效率和可靠性，以及如何循序渐进地推进AI项目。对于正在考虑AI转型的企业来说，这个项目提供了很多可借鉴的经验。
如果你对某个技术细节特别感兴趣，欢迎留言讨论。如果觉得这篇文章有帮助，别忘了点赞关注，我会持续分享更多AI领域的深度解读！
粤ICP备14082021号
免费POC，
零成本试错
