BI 自动化的卡点不在问答，在流程
商业智能（BI）是企业决策的基石，Power BI、Tableau 的庞大用户群就是明证。但传统 BI 流程对普通业务用户并不友好：回答一个业务问题之前，要先识别相关数据表、做数据转换、建立表间 join 关系，最后才是提问本身。这些准备步骤复杂且耗时，也正是大模型最容易被寄予厚望的地方。一篇 9 月下旬挂出的论文（arXiv 2609.20886）决定系统性地测一测：模型能不能把这条链路端到端扛下来。
这篇论文的贡献分两半。评测这半叫 BI-Bench，是定位为端到端 BI 的系统性基准。出题方式很讲究：研究团队从公开渠道收集了大量真实 BI 项目，再从真实用户做好的仪表盘里手工提取「问题-真值答案」对。这比合成题目多了一层保险——真实用户的数据关系、口径与提问习惯，是合成分布很难覆盖的。结论不含糊：即便 frontier 模型，端到端准确率也不足 50%。难处的分布很说明问题：单点问答能力早已不是瓶颈，卡住模型的是四步流程的连续编排——任何一步出错都会向后传导。
BI-Agent：把流程拆开，各步用对工具
解法这半叫 BI-Agent，一个工具增强的智能体，思路是把 BI 工作流在结构化数据上分解成子任务——search 定位相关表、join 建立表间关系、transform 完成清洗转换——并在不同 BI 阶段编排专门的数据管理方法，而不是指望一个通用推理模型临场发挥。效果显著：相对裸模型，工具编排带来最多 40 个百分点的准确率提升。这个数字本身是个诊断：BI 自动化的主要缺口在流程编排层，补上它，模型的原有能力才能真正兑现。
论文还搭了一层后训练框架：从真实 BI 项目合成训练轨迹，让 BI-Agent 经过监督微调（SFT）与强化学习（RL）继续精进，再拿最多 30 个百分点的提升。两组数字叠加起来读才有意思：编排 +40 说明工程手段的天花板还很高，轨迹后训练 +30 说明领域数据仍有可观的空间，两者不互斥，是补同一块短板的两把铲子。
把它与本站此前覆盖的 Text2SQL 工作放在一起看，边界更清楚。Text2SQL 解决的是「把一句自然语言变成一条可执行查询」，属于 BI 四步里的最后一环；BI-Bench 测的是从找表到建联到转换再到回答的完整链条，前置步骤的任何失误都会让后面的查询建立在错误的地基上。这也解释了为什么 frontier 模型在单点能力上已经很强、端到端却过不了半：难点从来不是 SQL 写得好不好，而是知不知道该对哪些表、按什么口径写。对企业数据团队而言，两者不是替代关系而是互补关系——单点能力用 Text2SQL 类工具夯实，流程编排交给智能体调度，架构上分两层建。
给数据团队的三个提示
对正在做数据智能体的团队，这份工作有三个可迁移的判断。其一，评测要从真实工件出发——真实仪表盘、真实问题，合成题再精致也会高估模型；其二，流程分解优先于模型升级——在动辄换模型的迭代之前，先把 search、join、transform 这些子任务的工具链搭扎实，收益立竿见影；其三，轨迹是资产——真实项目里沉淀的执行轨迹值得回流进训练，这条路径在本站此前报道的多个智能体进化工作里反复出现，BI 这里只是又一个验证场景。
辩证地看，局限也摆在明面上：基准取材自公开 BI 项目，私有企业数据上表结构更脏、口径更乱的场景泛化能力有待验证；后训练用的合成轨迹本身来自真实项目，分布外的行业（比如强合规行业）效果未测。BI-Agent 是否开源、基准规模与更多消融数据，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。