BI-Agent and BI-Bench: Towards Automating End-to-End Business Intelligence
Chuxuan Hu, Yeye He, Penny Zhou, Wee Hyong Tok, Daniel Kang, Surajit Chaudhuri
cs.LG, cs.AI, cs.CL, cs.DB
2026-09-17
UIUC与微软从真实Power BI项目抽出100道端到端商务问答。不用工具时o4-mini的SQL正确率只有48.2%;接上搜表、join和reshape工具后,GPT-OSS-120B从5.3%跳到45.3%。
Power BI、Tableau 这类工具的真实工作流不是「对着一张干净表写 SQL」。用户要先在一堆原始表里找出相关的,做 unpivot、transpose 这类整形,再手工点 join,最后才拖出一张图。NL2SQL 评测(BIRD、Spider)跳过了前三步:表已经洗好、schema 已经对齐。企业里最耗人的恰好是那三步。
UIUC 和微软研究院从公开网页爬了 3000 多个真实 .pbix 项目,人工从仪表盘可视化里抽出 100 对(商务问题,导出的结果表),做成 BI-Bench。平均每个项目 10.6 张表(最多 52)、约 8 万行(最多超 700 万)、12.75 条 join(最多 94)。他们问的是:给 LLM 一堆生表加一句自然语言问题,它能不能自己走完搜表、整形、join、分析,吐出对的结果表。
BI-Agent 把数据库社区里现成的算法接到 agent 工具循环里,不让模型凭抽样行去猜。
后训练走合成轨迹。从与测试集隔离的真实 BI 项目里抽连通子图,物化成一张宽表,让 LLM 在宽表上合成问题和代码,得到可验证的结果表 R;再把相关表和无关表混在一起,随机做逆 reshape,逼模型练习搜表和整形。筛掉与测试 query 过近的样本(embedding 近邻重叠只有 0.28%)。SFT 用 GPT-4o 当老师,只留执行结果精确等于 R 的轨迹;RL 用 GRPO,奖励是对了 +1、交了错表 -0.5、没交出表 -1,语法错误每次再扣 0.1。梯度只打在 tool-call 块上。Qwen3-8B 在 2×H100 上 SFT 约 9 小时、RL 约 22 小时,训练成本不到 200 美元。
评测看结果表的形状(聚合粒度)和逐格数值,允许行列置换,数值容差 rtol=1e-2、atol=0.5。每条 query 跑 10 次取平均,100 道题做配对 t 检验。
24 个模型和系统,SQL 与 Python 两套环境。
| 模型 | SQL 无工具 | SQL 接工具 |
| o4-mini | 48.2% | 61.9% (+13.7) |
| GPT-5.5 | 46.7% | 60.2% (+13.5) |
| GPT-OSS-120B | 5.3% | 45.3% (+40.0) |
| Qwen3-8B | 5.2% | 19.8% (+14.6) |
| Qwen3-8B-RL-Tool | 5.2% 基座 | 35.0%(相对基座 +29.8) |
工具平均给 SQL +14 个点、Python +11 个点,20 组里 19 组显著。GPT-OSS-120B 无工具时中位只调 3 次模型就收工,几乎不看数据;有工具后中位 9 次,每次换成对数据的观察。
后训练的 8B:SQL 无工具 SFT 到 22.6%、RL 到 23.5%;接工具后 SFT 27.2%、RL 35.0%。BIRD 榜前四的开源 NL2SQL 模型在 BI-Bench 上 SQL 只有 6.0%–17.3%;Spider 2.0-lite 上最好的两个开源 agent(ktx 配 GPT-5.5、Databao 配 GPT-5.2)也只有 26.3% 和 23.8%。
迁到未见过的 Spider 2.0-lite(122 条本地 query):Qwen3-8B 的 SQL 从 0.8% 到 RL 加工具 16.4%,大约 20.5 倍。错误分析里,工具把 transform 错误砍掉 54.2%、选表错误砍掉 40.9%。缺信息(漏列、漏行、漏字段)仍然是第一大错。
成本:Qwen3-8B-RL 跑完整份 BI-Bench 约 0.19 美元,o4-mini 和 GPT-4o 超过 10 美元,大约 54 倍差。工具还把平均交互轮次从 7.2 降到 6.3。
给企业数据团队的信号很具体。现成的 NL2SQL 智能体在「表已经进数仓」的设定里能打 70 分,换到真实 .pbix 的生表上会掉到 20 分出头。卡点不在写 SELECT,在 unpivot 一张从 Excel 来的交叉表、在 30 多张表里找对的雪花 join。把数据库社区已经做过的 join 和 reshape 预测接到工具循环里,比把模型再加大一档更值钱。8B 加上工具和后训练,SQL 正确率 35%,还没追上 o4-mini 加工具的 61.9%,但推理成本差一个数量级,适合先做长尾、一次性、没有现成语义层的分析,不适合替换已经建好的企业 BI。
BI-Bench 只有 100 道题,来自 82 个项目,人工标注超过 400 人时。题目是从可视化标题改写的,带上了作者补进去的隐式过滤,跟业务人员随口问的句子仍有距离。评测只对结果表,不对仪表盘怎么画。作者自己把问题定义成「生表上的一次性问答」,明确说不是要替换成熟数仓上的企业 BI。
工具集也不完备:缺信息是第一大错,说明 search 和 join 之后模型仍会漏度量、漏过滤。RL 奖励一拆,Python 加工具设置里准确率会从 SFT 的 22.6% 掉到 19%–21%,奖励设计绑得很死。合成训练 query 跟真实仪表盘问题的分布仍可能有缝,Spider 2.0 上 16.4% 也谈不上能用。公开 .pbix 还偏向教程和作品集,不一定代表银行或供应链里那些更脏的内部模型。