许多 AI 问数演示，都有一个漂亮的开场。
会议室的大屏上，业务同事问一句：“上个月华东区退款率为什么升了？”几秒钟后，系统给出一段解释、一张趋势图，还顺手列了三条建议。字很顺，图也漂亮。要是这时有人问：“它到底读了哪几张表？退款口径用的是申请时间还是到账时间？那份 PDF 里的活动规则算进去了吗？”屋里往往会安静一点。
这不是哪一家公司的事故复盘，而是 AI 问数进入真实工作后很常见的尴尬：我们越来越容易得到一个答案，却还没有同样容易地证明它是对的。
8 月 4 日提交到 arXiv 的 DataSpace 论文，给这件事泼了一杯不算冷、但足够醒脑的水。在它设计的 410 个跨语言任务里，表现最好的组合，准确率是 66.34%。
换句话说，在这套特定基准上，最好的系统也还有大约三分之一的任务没能完整答对。
这次考的，不只是会不会写 SQL
过去很多 Text-to-SQL 测试，像一场条件很好的笔试：给你数据库结构和一个问题，看能不能写出正确 SQL。它当然有价值，但和公司的真实桌面还隔着几层文件夹。
现实里的问题通常长这样：一部分数据在 SQLite 里，一部分在 CSV 和 JSON 里；业务规则写在几十页 PDF 中；最新口径藏在 Markdown 文档里；某个关键条件甚至只在培训视频里讲过。分析师不是只要“查出一张表”，还要先找到证据、判断哪些文件相关、对齐不同来源的实体，再做计算。
DataSpace 把这些麻烦都放了回来。它包含 410 个任务、7,439 份文件制品，总量约 15.01 GB，覆盖 CSV、JSON、SQLite、Markdown、PDF 和视频。每个 Agent 只拿到一个问题和一个工作区，最后必须交出完整的表格结果。
这点很重要。真实工作里，答对一段解释还不够。少一行客户、错一个日期、把金额单位弄反，都可能让一张看似合理的表失去用途。论文里的评估器因此会对齐不同名称或位置的列，按数据类型和数值精度做归一，并依据任务要求处理行顺序，而不只是让另一个模型评判“这段话看起来像不像对的”。
我是这么想的：AI 问数真正的门槛，不是把自然语言变成 SQL，而是把散落的证据变成可复核的结果。 SQL 只是其中一把扳手，桌上还有 PDF、视频、口径文档和一堆名字相似的文件。
66.34%，不能被读成一句耸动的结论
先把边界说清楚。66.34% 来自一篇预印本 v1 的特定实验：六个多模态模型、五种 Agent 运行框架，在 DataSpace 这套任务上的最好成绩。它不能证明“所有数据 Agent 都只有六成准确”，也不能直接拿来评价某个公司的内部系统。
但它至少提醒了我们三件事。
第一，异构证据会显著增加失败机会。数据库里的字段可以直接查询，PDF 里的表格可能要先解析，视频里的规则要先定位，几个来源之间还可能没有现成主键。每多跨一种介质，系统就多一次读错、漏读或对齐失败的可能。
第二，连接依然是硬骨头。论文发现，多模态证据整合和跨来源连接，会持续拉低不同模型的准确率。这一点做过数据项目的人并不陌生。两张表各自都对，不等于连起来就对；手机号会复用，商品名会改，日期时区会错半天。Agent 会写代码，并不会让这些旧问题自动消失。
第三，回答完整性比语言流畅更难。业务要的往往不是“给我一个趋势判断”，而是“把所有符合条件的门店列出来，带上原因和金额”。少返回三行，文字照样可以很漂亮，经营动作却可能恰好漏掉那三家门店。
所以，66.34% 最值得看的不是“AI 不行”，而是它把失败从一句笼统的抱怨，拆成了可以检查的工程问题。
同一个模型，换套运行框架能差 15.36 个百分点
论文里还有一个容易被忽略的数字：在底层模型不变时，换不同的 Agent harness——也就是负责规划步骤、调用工具、管理上下文和收集结果的运行框架——成绩最多能相差 15.36 个百分点。
这说明企业做 AI 问数时，只盯着模型排行榜，会漏掉相当大的一块。
一个系统可能因为没有先列文件清单，漏掉关键 PDF；也可能因为一次把太多内容塞进上下文，后面的数字被前面的噪声盖住；还可能在生成中间表后没有做行数和唯一键检查，带着错误继续算到底。模型像一个很聪明的新同事，harness 更像它所在的工作流程。你只给他换一台更好的电脑，却不告诉他资料在哪、做完怎么复核，事情还是会乱。
这也是为什么“再改一版 prompt”常常救不了生产问题。提示词可以改善表达和局部行为，但无法替代文件权限、工具边界、中间结果校验、失败重试和审计记录。
数据团队现在可以先补三道门禁
如果你的公司正在做 AI 问数，没必要等到 Agent 百分之百可靠才开始。那一天大概和“所有指标口径终于统一”一样，听着吉利，日历上找不到。
更实用的办法，是先给它三道门禁。
第一道：答案必须能被机器核对
不要只让 Agent 输出一段自然语言。对需要落到经营动作的问题，优先要求它交付结构化结果，并提前写清：
- 必须有哪些列；
- 金额和比例保留几位；
- 是否允许缺失值；
- 一行代表顾客、订单还是门店；
- 排序和去重规则是什么。
这些要求看起来不聪明，却很有用。因为“语气像专家”很难测试，“结果必须包含 32 家门店且门店 ID 唯一”却可以直接断言。
第二道：每个关键数字都要留证据路径
Agent 不只要给答案，还要告诉你它用过哪些文件、执行过哪些查询、采用了哪个口径版本。关键中间表最好保留行数、唯一键和时间范围检查。
这不是为了把过程写成一份冗长的思想汇报，而是为了出错时能回答三个朴素问题：它看了什么、漏了什么、在哪一步开始偏了。
第三道：按业务风险决定谁来签字
低风险任务可以让 Agent 直接做，比如资料检索、字段说明和分析草稿。涉及财务确认、库存调拨、客户触达或绩效判断时，结果应该经过规则校验和人工复核；证据不足时，系统还要允许明确说“不知道”。
一个会拒答的 Agent，偶尔让人扫兴。一个每次都很自信、偶尔把退款当收入的 Agent，才真正让人睡不好。
上线前，做一张最小验收单
三道门禁落到项目里，最好不要只写成原则。先从准备上线的真实任务中留一组固定验收题，覆盖团队最常遇到的表连接、口径文档、时间边界和空结果。题目不必多，但参考结果必须由业务和数据共同确认，并且保留生成它的查询或明细。以后换模型、换 harness、改工具权限，都重跑同一组题，才知道变化来自哪里。
验收不要只记一个平均正确率。至少分开记录四类结果：表结构是否符合约定，行是否完整，关键数值是否准确，证据路径能否重放。DataSpace 的整题准确率要求完整表格匹配，少行、多行、少列或多列都可能使整题失败；公司内部也可以采用更细的分项检查，但不能用几处单元格正确掩盖漏掉整批客户。
再按风险设置放行条件。资料检索可以允许 Agent 给出带来源的候选答案；经营报表要通过确定性规则；付款、库存、触达名单等动作还要有人签字。若输入文件缺失、口径版本冲突或结果无法重放，系统应停止在“待确认”，而不是为了完成率拼一个答案。
这里还有一道容易混淆的边界：66.34% 是这套基准、这组模型与 harness 的实验结果，不是任何企业系统现成的上线门槛。内部验收要由任务分布、错误代价和人工兜底能力决定。引用论文数字可以帮助团队保持清醒，却不能替团队签字。
别急着问它能不能替代分析师
DataSpace 的意义，不是替我们宣布数据 Agent 成功或失败。它做了一件更有用的事：把测试场景从“会不会写一条 SQL”，推近到“能不能在真实文件堆里交出一张完整、可验证的结果表”。
对做数据工作的同学来说，这反而是个清楚的职业信号。以后更值钱的能力，不只是亲手把每一条 SQL 写出来，而是能定义正确结果、组织证据、设计检查点，并知道什么情况下不能放行。
明天再参加一场 AI 问数演示，你可以少问一句“它用了什么模型”，多问三句：
- 这个答案的完整性怎么验证？
- 我能不能看到它的证据路径？
- 哪些结果必须由人签字？
屏幕上的字还是会很快出现。只是从这三句开始，演示才有机会变成系统。
我叫石头，在数据行业里摸爬滚打了十几年，这一轮 AI，我也是边看边想。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：DataSpace: Benchmarking Data Agents for Verifiable Analytics over Heterogeneous Workspaces · KDD Cup 2026 Data Agents 官方页面 · 官方 Starter Kit
