最近在折腾一个自动驾驶业务的数据仓库升级。

这个仓库一开始就没怎么系统设计。不同车型的数据处理链路长得都差不多，但每个车型都有一堆功能重复、逻辑雷同、名字还特别像的数据表，光表名就上百个。

我们除了打算做中间层来复用，还在想能不能靠大模型搞个Text-to-SQL。这样数据分析师直接说人话就能查数据，省去认知负担，提升运营效率。

调研时，我看到Uber一篇介绍内部QueryGPT的博客。它的思路跟我们想得很像，很有参考价值。今天就结合自己的阅读心得，聊聊这个QueryGPT。

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

这不是实验室里的Demo，而是Uber内部已经在用的实战工具。

官方数据是，他们每个月要处理120万次数据查询，光是运营团队就占了36%。 一家体量这么大的公司，敢把核心数据查询交给AI来处理，这件事本身就很有意思。

更关键的是效果。 原本写一条SQL查询需要10分钟，现在3分钟就能搞定。

做过数据分析的都懂，这种效率提升很夸张。内部小范围测试时，每天大概有300个活跃用户，其中78%的用户反馈，这个工具确实帮他们省了很多时间。

QueryGPT是怎么工作的？

从技术架构看，QueryGPT的设计很有借鉴意义。

它没有简单地把问题直接甩给大语言模型，而是设计了一套多阶段、智能化的处理流程。

工作空间系统

这个设计很巧妙。

他们把不同业务场景的SQL知识分门别类，相当于给AI配了不同的“专家组”。比如要查打车数据，就调用出行相关的知识库。这样做能明显提高准确率。

多Agent协作系统

这是整个流程的核心。每个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（检索增强生成）系统，做了简单的向量相似度搜索。

这个版本虽然简陋，但关键在于验证了可行性。有趣的是，它在小规模场景下表现还不错。

遇到的挑战

但当他们开始扩大规模时，三个典型问题很快出现了：

• 相似度搜索不够精准：直接用自然语言去搜SQL样本，匹配度往往不太理想。
• 理解用户意图困难：从自然语言直接映射到数据表结构，难度很大。
• Token限制：一些数据表超过200列，光描述一张表就会占用大量tokens。

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

现有架构的亮点

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

1. 工作空间机制

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

2. Agent流水线模式

它形成了一个清晰的分步处理流程：

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

这种流水线设计的优势很明显：

• 每个Agent职责单一，便于优化和维护。
• Agent之间相互配合，形成了较强的错误校正机制。
• 用户也能在关键节点介入和调整。

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

3. 智能化的表结构处理

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架构提供了更好的可控性和可扩展性。

给企业的启示

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

1. AI落地要解决实际问题

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

2. 循序渐进的开发策略

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

3. 合理的人机协作

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

给开发者的建议

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

• 从小场景开始：先圈定一个业务领域，用少量表和SQL样本验证想法，然后快速迭代改进。
• 重视数据质量：精心挑选SQL样本，确保表结构文档准确，建立完善的评估数据集。
• 设计合理的评估体系：建立量化指标，支持组件级测试，同时收集用户反馈。
• 注意性能和成本：优化token使用，减少不必要的API调用，合理使用缓存。

存在的问题和挑战

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

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

未来发展方向

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

更智能的意图理解

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

更强的可靠性

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

更好的可解释性

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

写在最后

QueryGPT是企业级AI应用的一个优秀范本。

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

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