这是一篇发表在Uber2024年官方博客上的文章，介绍了Uber是如何使用LLM技术落地了一个满足实际生产需求的Text2SQL应用的。本文对于想要在企业实际场景中落地AI应用的人非常具有参考价值，我对其中的精华内容进行了总结和翻译。

• QueryGPT 诞生： 为解决此痛点，优步开发了 QueryGPT，利用大型语言模型（LLM）和检索增强生成（RAG）技术，将自然语言提问直接转换成 SQL。

• 迭代之路： 该项目始于 2023 年 5 月的 Uber Generative AI Hackdays 上的一个概念验证，最初依赖简单的 RAG 和 Few-Shot Prompting。但在扩展数据范围后遭遇准确性瓶颈，随后经历了超过 20 次迭代，才发展为如今的生产级服务。

• 架构优化： 面对大型数据表（有的超 200 列，消耗 40-60K Token）带来的挑战和早期版本的局限，团队引入了多项关键改进（如下文的关键经验所述），形成了包含多智能体（Agent）的先进架构。

• 显著效果： 目前 QueryGPT 将平均查询时间从 10 分钟缩短至约 3 分钟。在部分团队有限发布后，已拥有约 300 名日活跃用户，其中 78% 的用户反馈该工具节省了他们的时间。

1. 起点 (Hackdayz 版本 - V1):
• 技术: 简单的 RAG（检索增强生成） + Few-Shot Prompting。
• 流程: 将用户自然语言提示向量化，在少量（7个表，20个SQL查询）样本和模式上进行 k-NN 相似性搜索，找出3个相关表和7个相关SQL样本。
• 输入给LLM: 系统提示 + 找到的表模式 + SQL样本 + 用户提示 + Uber业务指令（如日期处理）。
• 输出: SQL 查询 + 解释。
• 遇到的问题:
• 准确性下降: 当引入更多表和SQL样本时，简单的相似性搜索效果变差，准确率降低。
• 意图理解困难: 难以直接从自然语言准确映射到所需的表模式。
• Token 限制: 大型表模式（超200列，可能占用40-60K Token）轻易超出当时LLM（如32K模型）的上下文窗口限制。

2. 中间迭代 (超过 20 次):
• 文章未详述每次迭代，但明确指出是为了解决 V1 版本遇到的准确性、意图理解和 Token 限制等问题而进行的持续改进。这些改进最终形成了当前的架构。

1. 引入 Workspaces (工作区):
• 是什么: 按业务领域（如出行、广告、核心服务等）组织的、包含精选的 SQL 样本和表模式的集合。有系统预设的，也允许用户自定义。
• 目的: 大幅缩小 RAG 的搜索范围，提高上下文的相关性和准确性。

2. 增加 Intent Agent (意图识别 Agent):
• 技术: 使用 LLM 进行分类。
• 流程: 接收用户自然语言提示，首先判断用户的查询意图，并将其映射到一个或多个相关的 Workspace。
• 目的: 解决 V1 中难以准确理解用户意图并找到正确数据源的问题，为后续 RAG 提供更精确的起点。

3. 增加 Table Agent (表推荐 Agent):
• 技术: 使用 LLM 进行推荐，并加入人机交互。
• 流程: 基于 Intent Agent 识别的意图和 Workspace，推荐一组可能相关的表。用户可以确认（"Looks Good"）或编辑这个列表。
• 目的: 提高最终用于生成查询的表的准确性，解决 LLM 可能选错表的问题，引入用户反馈环节。

4. 增加 Column Prune Agent (列裁剪 Agent):
• 技术: 使用 LLM 进行模式裁剪。
• 流程: 在确定了要使用的表之后，该 Agent 会分析用户问题和表模式，移除与查询不相关的列，生成一个“瘦身版”的模式。
• 目的: 解决大型表模式导致的 Token 超限问题，同时降低 LLM 调用的成本和延迟，并可能提高生成查询的准确性（减少干扰信息）。

5. 改进的 RAG 流程:
• 在选定的 Workspace 内，利用 Intent Agent 和 Table Agent 确定的更精确的上下文（意图、表），进行更有效的 RAG，检索最相关的 SQL 样本和（经过裁剪的）表模式。

6. 核心 LLM 调用:
• 输入: 系统提示 + 经过裁剪的相关表模式 + RAG 检索到的相关 SQL 样本 + 用户原始提示（可能经过内部增强）+ Uber 业务指令。
• 模型: 使用了如 OpenAI GPT-4 Turbo (128K Token 限制) 的模型。
• 输出: SQL 查询 + 解释 (与 V1 类似)。

• Uber 数据平台每月处理约 120 万次交互式查询，运营部门贡献约 36%。

• 手动编写查询平均耗时约 10 分钟，QueryGPT 可将此时间缩短至约 3 分钟。

• QueryGPT 项目始于 2023 年 5 月的 Uber Generative AI Hackdays。

• 某些大型数据表模式可包含超过 200 列，消耗 40-60K Token。

• 目前约有 300 名日活跃用户，78% 的用户认为 QueryGPT 节省了他们的时间。

• 迭代优化是成功的唯一途径： 没有完美的 V1。从最小可行产品（MVP）开始，快速验证，收集真实反馈，并投入资源进行持续迭代（优步 >20 次），是通往成功的必经之路。

• 精巧设计 > 蛮力堆砌 (上下文 > 纯模型)： 与其寄望于一个无所不能的超大模型，不如通过巧妙的系统设计（如多 Agent 架构）为 LLM 提供精准的上下文，引导其在特定任务上发挥优势。优步证明，LLM 在特定、小范围的分类或转换任务（如意图识别）上表现极佳。

• 正视并管理企业AI应用的“最后一公里”挑战：
• “幻觉”是常态： LLM 生成不存在的表、列或错误逻辑是普遍现象。必须建立验证机制和评估体系来发现和修正错误。
• 用户输入多样： 用户提问的质量参差不齐，需要**“提示工程”或增强机制**来优化输入。
• 高预期管理： 用户往往期望 AI“开箱即用”且绝对准确。因此，明确应用边界、管理用户预期、设计人机协同环节（如 Table Agent 的确认） 至关重要。这些都是企业 AI 应用落地的典型“最后一公里”难题。

• 产品思维引领技术落地： 将 AI 工具视为产品来打磨，深入理解用户场景和痛点，设计友好的交互体验，并选择合适的目标用户群体进行早期测试和推广，是技术能否产生实际业务价值的关键。

• 将 LLM 作为核心部件

• 深度的业务理解

• 创新的系统架构

• 持续的迭代评估

• 产品化思维