核心发现
方法论
论文提出Text-to-Big SQL评测框架，将自然语言到SQL生成与大数据执行统一分析。系统采用ReAct（Reasoning + Acting）智能体，以LLM为控制器，通过list_tables、get_schema、check_query和run_query四个工具访问Spark SQL。除Execution Accuracy外，引入列级精度、端到端延迟和云执行成本，构造VES*、VCES及CVQ。
关键结果
- 在BIRD选取的高准确率查询上，GPT-4o的EX为0.93、平均端到端时间仅6.55秒；Gemini 3 Pro虽EX为1.00，却需54.55秒，GLM-5需79.63秒，说明传统准确率无法反映交互延迟。
- 归一化VES*中GPT-4o为1.00，Gemini 3 Flash为0.81，Opus 4.6为0.51，Gemini 3 Pro为0.23，模型间区分度远高于VES；作者报告VES*的离散范围为809.09%，而VES仅54.93%。
- 在可扩展的大数据场景中，GPT-4o相对后代模型准确率约低7%，却获得最高12.16倍速度优势；GPT-5.2在大输入规模下的成本效率超过Gemini 3 Pro两倍。
研究意义
研究把Text-to-SQL从单纯的翻译正确性推进到真实数据基础设施中的系统级效能评价。它指出错误SQL不仅意味着答案错误，还可能扫描海量数据、延长交互等待并增加账单。对学术界而言，论文连接了自然语言处理、数据库系统和云成本建模；对工业界而言，它提供了选择模型、配置智能体和控制重试开销的依据。
技术贡献
核心技术贡献是将部分正确性与执行代价结合。列级精度P(S,Ŝ)=|S∩Ŝ|/|Ŝ|惩罚多余字段，却保留可人工修正的结果；VES*=平均的结果有效指示量、列精度和Tgold/Te2e乘积；VCES进一步除以Ce2e；CVQ=Ce2e/p估计重试至成功的成本。该框架还分解list、schema、check、run阶段。
新颖性
论文并非提出新的SQL生成模型，而是首次系统性地把生成端和执行端作为同等评测对象。相较EM、EA、VES等近似二元的Text-to-SQL指标，它把智能体工具调用、推理延迟、字段冗余、数据规模和云成本纳入同一评价逻辑，形成面向生产部署的Text-to-Big SQL定义。
局限性
- 实验主要使用Spark SQL、AWS m5.xlarge和零样本ReAct架构，未覆盖Athena、BigQuery等后端，也未系统评估分布式集群、网络波动与缓存。
- 数据集集中于BIRD和可缩放TPC-H；模型、提示词和低延迟推理配置会影响结果，因而结论不能直接代表所有企业模式或工作负载。
- VES*将结果有效性、列精度和时间相乘，权重固定，尚未证明与真实用户满意度或不同业务成本函数完全一致。
未来方向
后续可研究按阶段分配不同模型、独立优化controller与checker，并比较多智能体、缓存和查询计划优化。还应在Athena、BigQuery及真实流式数据上进行多规模、多租户实验，学习面向预算、延迟和风险的动态指标与停止策略。
AI 总览摘要
自然语言查询数据库已经从实验室走向企业分析，但传统Text-to-SQL评测通常只问一个问题：SQL是否得到正确答案。论文指出，在大数据系统中，这远远不够。一次看似轻微的字段冗余或错误连接，可能扫描大量文件、延迟数十秒，并产生真实云账单。因此，作者将这一问题命名为Text-to-Big SQL，强调生成端和执行端都必须被评价。
研究构建了一个零样本ReAct智能体。LLM控制器依次使用list_tables、get_schema、check_query和run_query访问Spark SQL，并记录工具调用、推理、查询执行和成本。新指标VES*在传统有效性基础上加入列级精度和端到端时间，VCES加入总成本，CVQ则估计重复尝试直到成功所需的预期成本。与把答案简单标记为正确或错误的方法相比，这些指标更接近生产系统的实际表现。
BIRD实验显示，GPT-4o平均仅需6.55秒，EX为0.93；Gemini 3 Pro和GLM-5虽达到1.00，却分别需要54.55和79.63秒。归一化VES*中GPT-4o为1.00，而Gemini 3 Pro仅0.23。论文还报告GPT-4o以约7%的准确率差距换取最高12.16倍速度优势，GPT-5.2在大输入规模下比Gemini 3 Pro更具成本效益。结论是：未来的大模型数据库代理不能只追求答对，还必须少调用、快执行、少扫描、可负担。
深度分析
研究背景
Text-to-SQL长期使用EM、Execution Accuracy和VES衡量自然语言到SQL的能力。近年来，GPT系列、Gemini和Claude等生产级LLM结合ReAct智能体，能够检查模式、调用工具并生成跨数据库查询。然而，Amazon Athena、BigQuery和Spark SQL面对的是可扩展数据，延迟、扫描量和费用会随规模放大。传统基准通常忽视这些因素。
核心问题
核心问题是如何评价一个SQL智能体在真实大数据工作流中的综合质量。错误行数或连接条件会使结果失效；缺少字段需重新执行；多余字段虽然可在内存中删除，却已增加扫描和传输成本。同时，LLM推理和check_query可能比本地查询更慢，单一准确率无法区分这些情况。
核心创新
- �� 将生成与执行视为两个同等重要的端点。
- �� 用列级精度保留部分正确结果，并惩罚冗余投影。
- �� 用Te2e覆盖LLM、工具和Spark查询的完整交互路径。
- �� 用VES*、VCES和CVQ分别衡量时间效率、成本效率及重试成本。
- �� 用阶段级日志揭示list、schema、check和run的瓶颈。
方法详解
- �� 输入：BIRD自然语言问题和TPC-H可缩放查询。
- �� 控制器：同一生产级LLM运行ReAct循环，执行Thought、Action、Observation。
- �� 工具：list_tables调用SHOW TABLES；get_schema调用SHOW CREATE TABLE并可采样；check_query进行语法检查；run_query在Spark Session执行。
- �� 终止：首次run_query后停止，避免大数据环境中的无限重试。
- �� 指标：用指示函数判断结果是否包含正确输出，再乘P(S,Ŝ)和Tgold/Te2e；VCES再除以Ce2e，CVQ使用成功率p估计Ce2e/p。
实验设计
实验在AWS us-east-1的m5.xlarge上进行，使用官方API和各模型token价格。数据集为BIRD与TPC-H；模型包括GPT-4o、GPT-5、GPT-5.2、Gemini 2.5 Flash、Gemini 3 Flash、Gemini 3 Pro、Claude Opus 4.5/4.6、Kimi K2.5和GLM-5。BIRD子集选择八个多数模型EX至少0.85的问题，以隔离效率差异。
结果分析
GPT-4o在BIRD子集EX为0.93、Te2e为6.55秒，Gemini 3 Flash为1.00和8.37秒，Opus 4.6为1.00和12.60秒，Gemini 3 Pro为1.00和54.55秒，GLM-5为1.00和79.63秒。check阶段普遍占据主要时间。VES*相较VES更能区分系统，离散范围分别为809.09%和54.93%，说明成本与交互效率是关键变量。
应用场景
该框架适用于企业自然语言分析、湖仓查询、交互式BI和云端无服务器SQL。部署者可依据预算和响应目标选择模型，按阶段使用快模型或强模型，并用CVQ估计失败重试的真实费用。数据平台还可利用阶段日志定位模式读取、校验或执行瓶颈。
局限与展望
研究采用单一Spark后端、单机AWS环境和零样本配置，真实集群、缓存、并发、网络及文件格式差异仍可能改变排名。BIRD规模有限，TPC-H虽可扩展却不等同于企业混合负载。指标的乘法结构和固定权重也未必适合所有业务；未来需要多后端、真实成本函数、动态模型路由和用户研究。
通俗解读 非专业人士也能看懂
把一个数据库智能体想成餐厅的点餐员。客人用日常语言说想吃什么，点餐员先查看菜单，再确认厨房有没有材料，最后把订单交给厨房。传统评价只看端上来的菜对不对；但在大型餐厅里，还要看点餐员花了多久、是否反复询问、厨房用了多少燃气，以及是否端来一堆客人不需要的配菜。
论文的VES*就像综合评分：菜是否包含正确主菜、配菜有多少浪费、从点单到上菜用了多久。VCES还把燃气和服务费用算进去，CVQ则估计如果第一次做错，平均要花多少钱才能重做成功。实验发现，GPT-4o像一个动作很快的熟练店员，答案不一定每次最完美，却通常很快完成；更晚出现的模型有时答得更准，却因为反复确认而慢很多。在大数据中，快、准、少浪费必须一起衡量。
简单解释 像给14岁少年讲一样
想象你让游戏里的机器人帮你从一个超级大的仓库找东西。你说“找出所有蓝眼睛的超级英雄”，机器人不能直接猜；它要先看仓库有哪些箱子，再查看箱子标签，写一张取货单，检查取货单有没有语法错误，最后让机器真的翻箱子。
以前大家只看机器人有没有找到正确答案，就像只看游戏任务是否通关。但如果它为了找一个小物品翻遍整个仓库，等待很久，还花掉很多游戏金币，这种“答对”其实不够好。论文用ReAct让机器人反复进行思考、行动和观察，并记录每一步用了多久、花了多少资源。
结果很有意思：GPT-4o平均6.55秒完成任务，虽然EX是0.93；Gemini 3 Pro的EX达到1.00，却要54.55秒，GLM-5更要79.63秒。也就是说，满分选手不一定是最适合实时游戏的选手！
这篇论文告诉我们，未来的AI不能只追求“答对”，还要像聪明又节省的队友：少走弯路、少翻箱子、快速给答案，并且知道什么时候不要继续尝试。
术语表
Text-to-Big SQL（大数据文本到SQL）
把自然语言转换为可在大规模数据引擎上执行的SQL，并同时考虑正确性、延迟和成本。它扩展了传统Text-to-SQL的评价范围。
论文的核心问题定义。
ReAct（推理与行动）
智能体交替进行Thought、Action和Observation，以决定工具调用并根据反馈修正行为。它连接LLM控制器与数据库工具。
用于构建零样本SQL代理。
VES*
融合结果有效性、列级精度和Tgold/Te2e的效率指标。它允许多余字段造成部分扣分，而不是简单判错。
论文提出的主要Text-to-Big SQL指标。
VCES
在VES*基础上进一步除以端到端成本Ce2e的成本效率指标。它适合云端按量计费环境。
用于比较模型的成本效益。
CVQ
Expected Cost per Valid Query，定义为Ce2e/p，其中p是单次查询有效率。它估计重复尝试直到成功的平均成本。
衡量失败重试的经济影响。
列级精度
P(S,Ŝ)=|S∩Ŝ|/|Ŝ|，表示返回字段中真正相关字段的比例。该值会惩罚多余投影但保留部分正确性。
用于构造VES*。
开放问题 这项研究留下的未解疑问
- 1 如何让指标权重适应不同业务？交互分析重视延迟，批处理可能更重视扫描费用；固定乘法公式尚未证明能普遍代表用户价值。
- 2 在多租户、缓存、网络抖动和分布式集群中，模型排名是否稳定仍未知，需要跨云平台和真实企业负载验证。
应用场景
近期应用
企业自然语言分析
数据团队可用ReAct代理连接Spark SQL，利用VES*记录准确性与响应速度，用VCES和CVQ估计模型账单，从而在GPT-4o等快速模型与高准确率模型之间做有依据的选择。
云端查询网关
平台可在执行前记录check、schema和run阶段，并设置成本阈值；若生成SQL含大量字段或预计扫描过大，则请求模型重写，降低失败查询和无效扫描。
远期愿景
自适应模型路由
未来可为列识别、语法校验和复杂推理分别选择不同模型，根据数据规模、预算与时延目标动态切换，实现比单一LLM更稳定的性能。
原文摘要
Text-to-SQL and Big Data are both extensively benchmarked fields, yet there is limited research that evaluates them jointly. In the real world, Text-to-SQL systems are often embedded with Big Data workflows, such as large-scale data processing or interactive data analytics. We refer to this as ``Text-to-Big SQL''. However, existing text-to-SQL benchmarks remain narrowly scoped and overlook the cost and performance implications that arise at scale. For instance, translation errors that are minor on small datasets lead to substantial cost and latency overheads as data scales, a relevant issue completely ignored by text-to-SQL metrics. In this paper, we overcome this overlooked challenge by introducing novel and representative metrics for evaluating Text-to-Big SQL. Our study focuses on production-level LLM agents, a database-agnostic system adaptable to diverse user needs. Via an extensive evaluation of frontier models, we show that text-to-SQL metrics are insufficient for Big Data. In contrast, our proposed text-to-Big SQL metrics accurately reflect execution efficiency, cost, and the impact of data scale. For example, GPT-4o compensates for roughly 7% lower accuracy than the top-performing later-generation models with up to a 12.16x speedup, while GPT-5.2 is more than twice as cost-effective as Gemini 3 Pro at large input scales.