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