ICML 2026 | 会查表却不会预测未来：南大TopBench测出大模型数据盲区

当问题没有明确建模指令时，大模型能否主动完成意图对齐、任务抽象与表格预测？

论文题目：

TopBench: A Benchmark for Implicit Predictive Reasoning in Tabular Question Answering

收录会议：

ICML 2026

论文链接：

https://arxiv.org/abs/2604.28076

代码链接：

https://github.com/LAMDA-Tabular/TopBench

数据集：

https://huggingface.co/datasets/LAMDA-Tabular/TopBench

近年来，大语言模型在表格问答（Table Question Answering，TQA）中表现得越来越像一个“数据助理”：它可以读 CSV、理解列名、写 SQL 或 Python 做筛选聚合，也能把结果组织成自然语言。

对于“查某一行”“统计某个均值”“筛选符合条件的记录”这类问题，模型已经具备相当强的可用性。

但真实的用户请求里，经常有另一类更微妙的问题。

用户并不会说“请以 charges 为目标列训练一个回归模型”，也不会把任务描述成标准机器学习接口，而是会说：“我儿子刚上大学，不抽烟，BMI 是 30.14，我们大概该给他的医保账单准备多少钱？”

这里的关键不是表里有没有一行完全匹配的记录，而是答案本来就不在表里。模型必须先听懂用户真正想问的是一个预测问题，再把自然语言中的人物描述、业务目标、候选集合、约束条件等内容抽象成结构化任务，最后利用历史表格中的统计规律给出未观测结果。

南京大学提出的 TopBench，正是面向这种“隐式预测型表格问答”的系统评测。

它并不只是把“查表”和“预测”切开比较，而是把大模型进入真实数据智能工作流前必须跨过的一道门槛显式化：当预测意图隐藏在自然语言中时，模型能否主动对齐意图，并完成可靠的建模、比较、干预分析或批量筛选。

〓 图1：传统 TQA 与隐式预测型 TQA 的差异。前者答案显式存在于历史表中，后者需要从历史模式中推断未观测结果。

从 TableQA 到隐式预测：问题变难在哪里？

传统 TQA 的默认假设是：答案在表里。模型需要做的是定位、聚合、比较或验证。

例如“37 岁男性吸烟者的费用是多少”是检索；“西南部非吸烟者的平均费用是多少”是聚合。即使需要 SQL 或 Python，这类任务的目标仍然是操作已有事实。

TopBench 研究的是二者之间尚未被充分评测的灰区。用户给出的是一张历史表和一句自然语言问题，但问题并没有把机器学习任务写出来。

模型既要像 TableQA 系统一样理解表格语义，又要像表格预测系统一样从历史数据中建模。更准确地说，它要解决的是 intent-grounded predictive TQA：以自然语言意图为起点的表格预测问答。

这一设定非常贴近真实业务。金融风控里，经理可能问“哪些客户更值得优先审核”；医疗场景里，用户可能问“如果调整某个状态，风险会不会降低”；招聘或保险场景里，数据持有者可能要求“在候选池中筛出最可能产生某类结果的 Top-K”。

这些问题都不是简单查表，也不只是单点预测，而是自然语言、表格结构、统计建模和任务规划的组合。

TopBench 的形式化：先抽象意图，再执行预测推理

因此，TopBench 不是把预测任务硬塞进 TableQA，而是刻意保留真实语言中的不完整性和业务语义，让模型自己完成从“人话”到“建模任务”的转换。

这个转换失败时，后面的代码执行、长链思考或工具调用都可能只是把错误路线走得更远。

〓 图2：TopBench 四类任务。除单点预测外，Decision Making、Treatment Effect Analysis、Ranking and Filtering 都要求将隐式预测与比较、干预或结构化筛选结合起来。

四类任务：TopBench 不止考“预测一个数”

3.1 Single-Point Prediction：最小单元是“未观测画像”的预测

单点预测是 TopBench 的基础任务。用户描述一个历史表中不存在的新 profile，模型需要抽取其中的特征，并给出分类或回归结果。

它看似简单，却能暴露最基本的意图对齐问题：模型到底有没有意识到这个 profile 是一个新样本，而不是历史表中应该被检索到的一行。

3.2 Decision Making：先分别预测，再做决策

决策任务把预测推进到比较场景。模型面对多个候选方案，需要分别估计其潜在结果，再根据“更高、更低、更优、更可能”等目标进行选择。

这里的难点不只是给出最终人选，而是要避免“看到某个显著特征就拍脑袋”的启发式判断。候选对往往被构造成相近样本，粗略的语义相似性很容易失效。

3.3 Treatment Effect Analysis：预测状态改变后的方向

3.4 Ranking and Filtering：显式筛选 + 隐式预测排序 + 结构化输出

Ranking and Filtering 更接近工业批处理：模型有时需要先执行显式筛选，例如只保留女性、某类公司或满足特定条件的样本；也有任务并不额外给出显式过滤条件，而是直接要求模型在候选集合中依据隐式预测目标筛出或排出 Top-K。

无论哪种情况，模型都必须把自然语言里的业务目标转成可执行的筛选、批量预测、排序和结构化文件输出。

这类任务尤其重要，因为真实数据工作流往往不是“回答一句话”结束，而是要求模型生成可落地的候选清单。

对大模型来说，这同时考察表格语义理解、代码执行、过滤逻辑、预测建模、排序质量以及文件格式稳定性。

Benchmark 怎么构造？35 张真实表，779 个意图丰富的问题

为了避免把隐式预测做成玩具任务，TopBench 从 Kaggle 等真实来源收集具有真实相关结构的表格，覆盖 Healthcare、Finance 和 Daily Consulting 三个领域。

最终数据集包含 35 张历史表和 779 个高质量查询。每个样本由自然语言查询、原始 CSV 文件和结构化 ground truth JSON 组成。

从任务分布看，TopBench 包含 274 个 Single-Point Prediction、186 个 Decision Making、105 个 Treatment Effect Analysis 和 214 个 Ranking and Filtering 查询。

从目标类型看，384 个为回归目标，395 个为分类目标，基本保持平衡。表格规模也被刻意拉开：既有少于 1000 行的小表，也有超过 600 万行的工业级日志。

更关键的是，TopBench 的问题不是随机从表中抽行再改写成自然语言。

论文采用了逻辑驱动采样：在决策任务中构造结果相近的 hard negative pair，迫使模型依赖精细预测而不是粗略判断；在排序筛选任务中构造高噪声候选池，让少量满足目标的样本混在大量干扰项中。

〓 图3：TopBench 数据分布。数据覆盖三大领域，并包含不同长度的历史表与不同规模的候选列表。

在自然语言生成上，TopBench 还区分了两种视角。

一类是普通用户视角，问题常常以生活化叙述出现，不直接使用列名或任务术语；另一类是数据持有者视角，问题更接近业务需求，例如风险官、招聘经理或 CFO 想从历史记录中筛选候选对象。

这种双视角设计使模型不能只靠模板识别，而必须理解语言背后的任务目的。

〓 图4：数据构造流程。TopBench 从逻辑驱动采样出发，经过双视角问题生成，再由 LLM reward model 与人工专家联合验证。

怎么评估？不能只看最终答案像不像

隐式预测型 TQA 的评估比传统问答更麻烦。模型可能给出一段非常顺滑的解释，但中间没有真正预测；也可能最终决策正确，但理由完全依赖偶然的相似样本检索。

为此，TopBench 将评估拆成两条流：自然语言推理评估和结构化输出评估。

对于 Single-Point、Decision Making 和 Treatment Effect Analysis，模型输出通常是自然语言。

TopBench 使用 LLM-as-a-Judge 提取最终结论和中间预测值，并进一步检查这些值是否真的出现在原始回答中。

为了降低 judge 自己“补全答案”的风险，论文使用字符串匹配、模糊匹配和自然语言推断等层级验证，把抽取结果重新锚定回模型原文。

对于 Ranking and Filtering，模型必须生成结构化 CSV 文件，因此评估转向确定性的文件级指标：筛选任务使用 F1 衡量返回集合是否正确；排序任务同时评估 Set Recall、NDCG 和 batch NMAE，用来分别衡量 Top-K 是否命中、排序质量是否合理以及预测数值是否准确。

对于回归类自然语言输出，TopBench 不是只看点估计误差，而是把点估计、区间覆盖和过宽区间惩罚组合起来。论文主文中的复合得分写作：

其中，为了避免模型用过宽置信区间“兜底”，论文进一步定义了宽度惩罚项：

而在排序任务的数值误差中，论文采用归一化绝对误差，使不同量纲的数据集可以放在同一标尺上比较：

这个评估设计体现了 TopBench 的核心立场：一个真正可靠的数据智能模型，不应该只会讲一段“像是分析”的话，而应在意图、数值、逻辑和结构化产物上都经得起检查。

〓 图5：自然语言评估中的抽取与幻觉验证流程。评估器不只抽取结论，还会验证证据是否来自模型原始回答。

实验结果：模型不是不会用表，而是常常没进入正确任务模式

TopBench 评测了通用大模型、推理增强模型和表格专用模型，并分别考察纯文本推理与可执行代码的 agentic workflow。

总体结果显示，当前模型在隐式预测型表格问答中仍然不稳定，大多数分数低于 0.60。即便是表现最好的模型，在基础单点预测上的准确率也只有约 0.65 左右。

这与模型在显式事实检索或简单聚合上的表现形成鲜明对比。差距并不说明模型完全不会处理表格，而是说明它们常常没有把问题识别为需要建模的预测任务：一旦模型默认进入“查找历史记录”的模式，它后续生成的长推理、代码或解释都可能围绕错误目标展开。

〓 表1：TopBench 主实验结果。结果覆盖单点预测、决策、处理效应以及 Ranking and Filtering 的结构化输出指标。

代码执行并不是万能钥匙。GPT-5.2 在 Treatment Effect Analysis 中借助代码执行将 Trend Score 从 0.51 提升到 0.65，说明外部工具有助于复杂计算。

但 Qwen3-Instruct 在 agentic 设置下的单点预测从 0.57 降到 0.43，原因在于它用代码去做 pandas 式过滤或相似行查找，而不是训练预测模型。工具越强，前提越重要：模型必须先知道自己为什么要用工具。

推理增强模型也没有稳定占优。论文观察到，Qwen3-Thinking 在超过一半的文本设置样本中会陷入重复循环：它不断检查历史表中是否存在完全匹配的新 profile，直到上下文耗尽。

这种失败非常典型——模型并非“不努力”，而是把一个未来状态的预测问题误解成了历史记录检索问题。

表格专用模型的表现也不理想。它们在传统 TableQA 或表格代码生成任务上接受过专门训练，但这些训练目标多集中在显式检索、格式转换或简单计算，并不足以支撑“从隐式用户意图恢复预测任务”这一更上游的能力。

进一步分析：TopBench 拆出了两个瓶颈

7.1 瓶颈一：意图对齐是进入预测模式的前提

论文的语义信息消融实验直接验证了这一点。当提示中额外提供目标列、任务类型和特征描述时，部分模型性能显著提升。

例如在 agentic 设置下，Qwen3-Instruct 的 Single-Point Prediction 从 0.43 提升到 0.56；DeepSeek-V3.2 的 Treatment Effect Analysis 从 0.57 提升到 0.68；GPT-5.2 的单点预测也从 0.60 提升到 0.64。

这说明很多失败并不是“不会写代码”或“算力不够”，而是模型没有正确识别任务框架。一旦把隐式意图显式化，模型更容易切换到预测模式，减少把问题误当作查表、筛选或聚合的情况。

〓 表2：语义信息消融。补充目标列、任务类型等信息后，部分模型明显改善，说明意图消歧是关键瓶颈之一。

7.2 瓶颈二：知道要预测之后，还需要真正的表格建模能力

不过，意图对齐并不能解决全部问题。论文进一步设置了 predict-only baseline：直接给模型金标准结构化目标和 profile，再由一个更强的表格 ensemble 完成预测。

这个设置不再考察从自然语言中恢复任务，而是诊断“预测模块”的上限。

结果显示，predict-only ensemble 相比最强的 Gemini agentic E2E 设置仍有明显提升：Single-Point 从 0.66 到 0.76，Decision Making 从 0.65 到 0.72，Treatment Effect 从 0.65 到 0.69。

这说明即使模型已经知道要预测，准确建模仍然困难。特征选择、类别编码、缺失值处理、模型家族选择、候选比较和自我校验，都会影响最终数值或排序。

〓 表3：Predict-only baseline。给定金标准结构化目标后，更强的表格预测流水线仍能提升性能，说明预测建模本身也是瓶颈。

这正好把 TopBench 的理论价值讲清楚：它不是单点考一个能力，而是把成功路径拆成连续成立的两个环节。只有当模型既能读懂隐式意图，又能完成稳健建模时，才可能在真实表格问答中可靠工作。

为什么“调用模型”也不等于“会建模”？

在 agentic workflow 中，论文进一步分析模型生成的代码。DeepSeek 更常主动导入 scikit-learn 等库训练预测器，而 Qwen3 更容易依赖 pandas 过滤、近邻检索或启发式计算。

常见被调用的模型包括 Random Forest、Logistic Regression 和 Linear Regression。

这带来一个很现实的问题：大模型会写一段看起来像机器学习的代码，并不意味着它建立了合适的预测流程。

表格数据对预处理极其敏感，类别变量如何编码、缺失值如何填补、目标是分类还是回归、数据规模是否适合某个模型、是否需要交叉验证或集成，这些都会改变结果。

零样本代码生成中，模型常常默认选择简单算法，例如未调参的线性回归，而真实数据可能存在强非线性、高噪声和长尾分布。

〓 图6：不同模型在 agentic 设置中的工具与模型使用偏好。能否从 pandas 式过滤转向真正预测建模，是行为差异的关键。

图中的 “With Modeling vs. Without Modeling” 进一步说明，显式建模通常能带来平均性能提升。但这种提升不是自动发生的，它依赖于模型是否识别了预测意图，以及是否生成了足够完整的数据处理与建模流水线。

〓 图7：使用预测模型与不使用预测模型的性能差异。建模通常有效，但仍受任务理解和预测流水线质量限制。

一个典型失败：把未来预测当成历史检索

论文将一种失败模式称为 Exhaustive Retrieval Loop。模型面对一个历史表中不存在的新 profile，却假设答案必然隐藏在某一行，于是开始逐行检查、不断排除不匹配项，直到上下文窗口耗尽。

这个现象非常能说明隐式预测的特殊性。传统 TQA 训练让模型形成了“答案在表内”的强先验，而隐式预测要求模型承认“答案不在表内”，并从历史表中学习规律。

前者是查询过去，后者是建模未来。TopBench 要评测的，正是模型能不能在没有明确任务标签时完成这种模式切换。

〓 图8：Qwen3-Thinking 的检索循环失败案例。模型将新样本预测误解为历史表精确匹配，最终陷入逐行查找。

总结：TopBench 指向的是“自主数据智能”的入口能力

TopBench 的意义不在于再次证明某个模型比另一个模型高几分，而在于它重新定义了表格问答中一个过去被忽略的中间环节。

现有 TableQA benchmark 多强调显式事实检索、聚合或文本到 SQL；表格预测 benchmark 则通常默认任务已经被结构化。

TopBench 把问题放在更真实的位置：任务尚未被写成机器学习格式，而是隐藏在人的自然语言需求中。

因此，TopBench 评测的是一个完整能力链：理解用户意图，识别隐式预测目标，抽取结构化 profile 或候选集合，执行适当的数据处理和建模，再把预测结果转化为自然语言决策或结构化文件。

Ranking and Filtering 进一步提醒我们，真实数据助手往往不仅要回答一句话，还要生成可以进入业务流程的候选表。

从实验看，当前大模型已经具备一定的表格理解、代码生成和解释能力，但在“隐式预测意图对齐”和“稳健预测建模”这两个环节上仍存在明显短板。

更长的思考、更强的工具或更大的模型，都不能自动解决任务框架错误的问题；而即使框架正确，预测精度仍依赖于更成熟的表格建模流程。

未来的表格智能系统需要的不只是会读表、会写 SQL、会跑 Python，而是能在用户没有明说的情况下判断：这到底是查历史、做统计，还是在要求基于历史数据预测一个尚未发生的结果。TopBench 给出的正是这条道路上的一块试金石。

#投 稿 通 道#

 让你的文字被更多人看到 

如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。

总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。 

PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。

📝 稿件基本要求：

• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注 

• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题

• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算

📬 投稿通道：

• 投稿邮箱：hr@paperweekly.site 

• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者

• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿

△长按添加PaperWeekly小编

🔍

现在，在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧