Agentar-Scale-SQL: 蚂蚁集团多智能体协同 Text2SQL 系统

图1: Agentar-Scale-SQL 整体架构图

图1说明: 系统采用"编排式测试时扩展"(Orchestrated Test-Time Scaling)策略, 通过协同多个专用模块处理 Text2SQL 任务, 在 BIRD 基准测试集上以 81.67% 的执行准确率登顶全球第一。

---

背景故事: 为什么 Text2SQL 仍然很难?

在企业数据分析场景中, 让非技术人员用自然语言查询数据库, 是一个延续了数十年的梦想。从最早的 SQL 生成规则, 到后来的 Seq2Seq 模型, 再到 GPT 时代的大语言模型, Text2SQL 技术经历了多次范式跃迁, 但至今仍是 AI 落地最难啃的硬骨头之一。

问题出在哪里? BIRD 基准测试揭示了真相: 真实业务数据库往往规模庞大(上百张表、数千个字段), 而用户的自然语言问题又高度口语化、含糊不清。顶尖商业模型 GPT-4o 在 BIRD 上的执行准确率仅约 76%, 与人类专家 85% 以上的水平仍有显著差距。

蚂蚁集团(Ant Group)旗下的数据智能团队直面这一挑战, 在 2025 年 9 月发布了 Agentar-Scale-SQL 框架, 将 BIRD 榜单准确率从 76% 提升至 81.67%, 超越 GPT-4o 成为全球第一。项目同时开源了 32B 参数的专用 Text2SQL 生成模型和完整推理框架。

---

核心技术: 测试时扩展的三层编排

Agentar-Scale-SQL 的核心创新是"编排式测试时扩展"(Orchestrated Test-Time Scaling)。与传统的单次生成不同, 该框架将 Text2SQL 任务分解为三个视角的协同处理:

第一层: 任务理解(Task Understanding)

系统首先调用 keyword_extraction 模块, 通过 Gemini Flash 模型以 0.2 的低温度参数提取用户问题中的关键数据库字面量(literal), 即问题中出现的具体值(如"2023年"、"日本"等用于 WHERE 筛选的数据)。同时, 系统会从向量数据库中检索与问题骨架(skeleton)相似的历史查询案例作为参考。

第二层: SQL 候选生成(SQL Candidate Generation)

这是框架的计算密集型核心。系统并行调用多个 LLM 推理器(如 Gemini、GPT-5), 每个推理器在不同的 temperature 参数下(0.5、1.0、1.8)生成多组 SQL 候选, 并利用 128 步的 thinking budget 进行链式推理(Chain-of-Thought)。多个推理器的输出形成候选池, 为后续选择提供丰富的选择空间。

第三层: SQL 选择与修正(SQL Selection & Fix)

候选池中的 SQL 语句通过两轮筛选: 首先通过 schema_retrieve 模块从向量数据库中检索相关表结构; 然后通过 sql_fix 模块由 Gemini 模型以 0.2 低温度参数对语法和逻辑错误进行修正; 最后由 sql_revision 模块进行最终的质量评估和排序。

---

四大核心模块深度解析

Light Schema Engine(轻量 Schema 引擎)

传统 Text2SQL 系统面临的核心挑战之一是: 真实数据库包含数百张表和数千个字段, 直接将完整 Schema 塞入 LLM prompt 会超出模型的上下文窗口限制。Agentar-Scale-SQL 提出了 Light Schema 机制——通过抽样数据库行数据(每列取 3 条代表性值), 让 LLM 在有限 token 内快速理解每个字段的业务语义, 而非机械地列字段名。

这一设计在 BIRD 的 dev 和 test 集上均带来了显著提升。执行准确率从 CHASE-SQL+Gemini 的 76.02% 跃升至 81.67%, 相对提升超过 5 个百分点。

Chroma 向量检索系统

框架依赖 ChromaDB(版本 1.0.15)构建了两级向量检索体系: 训练集骨架库(bird_train_skeleton)和数据库内容库(bird_test)。前者用于基于问题结构的语义检索, 后者用于基于数据库具体值的内容检索。检索阈值分别设置为 1.5 和 0.8, k 参数分别为 15 和 5, 确保召回率和精度的平衡。

vLLM 推理加速

官方推荐的推理后端是 vLLM 0.8.5(CUDA 12.1 专用构建), 支持 PagedAttention 和连续批处理, 显著提升 32B 模型的推理吞吐量。相比原生 HuggingFace Transformers, vLLM 可实现 3-5 倍的推理加速, 对于需要生成大量候选 SQL 的场景尤为重要。

LangChain 生态集成

框架的 metadata_generation 模块使用 LangChain(0.3.27)构建了结构化输出流水线: ChatPromptTemplate → LLM → JsonOutputParser → OutputFixingParser。Pydantic(2.11.7)定义了 TableMetadata 等数据模型, 确保 LLM 输出与数据库 Schema 的类型对齐。

---

部署体验: 企业级应用的高门槛

从部署角度看, Agentar-Scale-SQL 是一个不折不扣的高门槛项目。它没有 Docker 化, 部署涉及 5 个预处理流水线步骤: Light Schema 生成、训练集向量化、数据库内容向量化、BM25 索引构建、DDL Schema 生成(依赖 Java 环境)。

更关键的是, 该项目本质上是离线推理工具, 不是开箱即用的在线服务。开发者需要准备好 BIRD 数据集、配置 column_meaning.json(需从 TA-SQL 项目获取), 以及 HuggingFace/ModelScope 账号用于下载 32B 模型。硬件方面, 官方推荐 24GB+ VRAM 的 GPU(CUDA 12.1), 整体部署时间预计在 2 小时以上。

不过, 蚂蚁集团同步上线了 Data Agent 产品(https://antdigital.com/products/DataAgent), 以 SaaS 形式提供 Text2SQL 能力, 用户可以直接在网页端用自然语言查询数据, 无需自行部署框架。

---

架构亮点与技术债务

值得称赞的工程设计:

分层模块化做得相当扎实。workflows、modules、llms、retrievers、prompts 五个子包职责清晰, 通过 pipeline_config.yaml 集中配置 LLM 参数, 新模型接入成本低。Pydantic 数据验证、LangChain 统一接口、YAML 驱动的 Prompt 工程, 这些都符合现代 LLM 应用的最佳实践。

客观存在的局限:

目前只支持 SQLite 数据库方言(pipeline_config.yaml 中 dialect: sqlite), 生产环境常见的 MySQL、PostgreSQL、ClickHouse 暂不支持。SQL Selection 模块代码尚未开源, 只能通过 API 调用闭源的 32B 选择模型。此外, 系统严重依赖外部 LLM API(Gemini/GPT-5), 离线部署需要自行替换为开源模型(如 Qwen2.5、DeepSeek)。

---

行业意义: 从科研到落地的桥梁

Agentar-Scale-SQL 的发布标志着 Text2SQL 领域进入了"工程化深水区"。此前的 SOTA 方法(如 CHASE-SQL、XiYan-SQL)主要通过改进 Prompt 策略或模型微调来提升准确率, 而 Agentar-Scale-SQL 首次将"测试时扩展"(Test-Time Scaling)——这一 LLM 推理领域的核心理念——系统性地引入 Text2SQL 任务。

其意义体现在三个层面: 技术上证明了多 LLM 协同推理对复杂结构化任务的必要性; 工程上开源了完整的预处理流水线, 为社区提供了可复现的基准; 商业上通过 Data Agent 产品验证了从开源研究到企业级产品的转化路径。

从 GitHub 趋势看, Agentar-Scale-SQL 的 Star 增长曲线与其在 BIRD 榜单登顶的时间节点高度吻合(2025年9月), 反映出 AI 开发者对"效果导向"的工业级项目有强烈的跟进意愿。

---

分析基于 GitHub 公开仓库数据及 arXiv 论文(arXiv:2509.24403)。数据截止至 2026 年 6 月。