最近在推进一个自动驾驶业务的数据仓库升级项目，过程颇为不易。该仓库在初始阶段缺乏系统化设计，不同车型的数据处理链路虽然高度相似，却各自衍生出大量功能重叠、逻辑雷同且命名相近的数据表，仅表名就多达上百个。除了计划构建中间层以提升复用性，我们也在探索能否借助大语言模型实现自然语言转SQL（Text-to-SQL），让数据分析师用日常语言就能查询数据，从而减轻认知负担并提高运营效率。调研过程中，我发现Uber的一篇博客介绍了他们内部使用的QueryGPT，其设计思路与我们高度契合，很有参考意义。今天结合我的阅读体会，来聊聊这个QueryGPT。

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

首先需要明确，这并非实验室中的原型演示，而是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（检索增强生成）系统，并实现了简单的向量相似度搜索。尽管简陋，但这个版本成功验证了方案的可行性。有趣的是，它在小规模场景下表现相当不错。

遇到的挑战

然而，当团队开始规模化推广时，三个典型问题逐渐显现：

1. 相似度搜索不够精准：直接使用自然语言检索SQL样本，匹配度往往不理想。
2. 理解用户意图困难：从自然语言直接映射到数据表结构，难度较大。
3. 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团队在评估方面也做得相当到位。他们采用了两种评估流程：

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而强行使用。Uber选择数据查询这个场景非常明智，因为它有明确的效率提升指标、大量的重复性工作，并且错误成本可控（生成的SQL会经过人工确认）。

2. 循序渐进的开发策略：从一个黑客松的小项目起步，经过20多次迭代才发展到当前版本。这种稳扎稳打、小步快跑的方式值得所有团队借鉴。

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

给开发者的建议

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

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

存在的问题和挑战

当然，这个系统也并非完美无缺：

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

未来发展方向

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

更智能的意图理解：支持多轮对话，理解业务上下文，处理模糊查询。

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

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

写在最后

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

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