Beyond IID：表格基础模型真的有那么通用吗？

  • 关联论文：2606.30410
  • 作者：spark
  • 更新：2026-07-23

一句话结论

本文推出 BeyondArena——第一个面向表格数据（tabular data）的统一整体基准，支持 IID / 时序（temporal）/ 分组（grouped）三类任务，覆盖样本量与特征维度的多个尺度，并包含含文本字段、高基数特征的多样化特征类型；同时开源配套工具 Data Foundry（Python 框架 + 元数据 schema）。在 11 个模型、142 个数据集上的实验给出一个反共识结论：现有 Tabular Foundation Models（TabFMs）只在中小规模 IID 数据上称霸；在非 IID、大规模、高维数据上，传统树模型与深度学习方法仍然更稳。

它到底在解决什么问题

过去两年，表格基础模型（TabPFN、TabICL、Trompt、TabResNet 等）是 AutoML / 表格学习社区最热的叙事之一。它们的卖点一致：用一个跨数据集预训练的大模型，在新数据集上少样本甚至零样本地拿到 SOTA。这套叙事在几个标准 IID 基准上（OpenML-CC18、TABLLM、TabZilla 等）确实亮眼。

但工业落地的人很快就发现：现实里的表格任务，绝大多数根本不是 IID 的。

  • 时序维度：金融风控、零售销量、医疗随访——同一个样本在不同时间点的特征不是独立同分布的，今天的特征会改变明天的目标分布。
  • 分组结构：同一公司不同门店、同一个患者不同就诊记录、同一个用户不同 session——观测之间存在层级聚类，标准 IID 评测会低估组内相关性导致的方差。
  • 高基数与文本字段：SKU、产品描述、用户评论——大量高维 categorical 与 free text，远超标准基准的难度。
  • 规模与维度：几万到几百万样本、几千到几万维——超过大多数 TabFM 训练/推理预算。

这些"难场景"在原 benchmark 体系里被系统性排除。原因不是没人想做，而是评估工具碎片化：每个研究组各自拼一套数据 + 各自一套评估协议，结果不可复现、不可比较。模型研究者因此只能依赖"标准 IID 基准"——而这些恰好是 TabFM 已经擅长的场景，于是领域出现"边际改进 + 自我感觉良好"的循环。

BeyondArena 试图打破这个循环：给整个社区一个统一的、覆盖难场景的、能跑多种 TabFM 与传统方法的评测平台，并配套开源工具降低接入门槛。

核心方法：BeyondArena + Data Foundry 双组件

BeyondArena：统一整体基准

设计上强调四点：

  1. 多任务类型：显式区分 IID、temporal、grouped 三类任务，并在同一协议下评估。三类任务有各自合理的切分方式（IID 用随机切，temporal 按时间切，grouped 按组切），避免"用 IID 切法跑时序数据"这种常见误用。
  2. 多尺度：样本量与特征维度都跨多个量级（从 tiny 到 large），评估模型在不同容量预算下的扩展行为。
  3. 多特征类型：包含含文本字段（with text）、含高基数类别（with high cardinality）的数据集——这正是 TabFM 宣传的优势，也是最容易揭穿宣传的场景。
  4. 跨学科：数据来源不局限于 UCI / OpenML 的"经典 30 个数据集"，而是更广的学科覆盖，让评估结果更接近工业现实。

Data Foundry：配套 Python 框架 + 元数据 schema

仅有一个静态 benchmark 是不够的——未来的新数据集、新任务需要能持续接入。Data Foundry 提供两件东西：

  • Python 框架：把数据集接入评估的流水线标准化（数据加载、切分、特征类型标记、评估指标计算）。
  • 元数据 schema：用结构化方式描述每个数据集的任务类型、特征类型、规模、学科来源——这让"在哪些子集上模型强、在哪些上弱"变得可分析、可复现。

这两件配套工具其实是 benchmark 长期可持续的关键：今天的 OpenML-CC18 之所以被广泛使用，很大程度上是因为 OpenML 平台 + 标准化元数据让接入成本极低。Data Foundry 想在表格预测 ML 领域复制同样的生态。

伪代码层面，Data Foundry 的典型用法大致是：

from foundry import Dataset, EvalProtocol, ModelRegistry

ds = Dataset.load("beyond_arena/finance_default_v3")
protocol = EvalProtocol(task="temporal", split="time", metrics=["auc", "ece"])
models = ModelRegistry.load(["tabpfn", "xgboost", "grboost", "mlp", ...])

results = {}
for m in models:
    preds = m.fit_predict(ds.train, ds.test)
    results[m.name] = protocol.score(preds)

这种"benchmark 即平台"的工程做法，是把一次性论文成果转化为社区基础设施的关键。

关键实验与数据

⚠️ 以下实验数字基于 abstract 与可用元数据的有限信息整理，具体逐模型分数与胜负矩阵建议直接阅读原文。

主结论（基于 abstract 能确认的事实）：

  • TabFM 在 tiny 到 medium 的 IID 数据上占优——这与过去两年的叙事一致。
  • 在非 IID、大规模、高维数据上，传统树模型（XGBoost、LightGBM 等）与深度学习模型仍占主导——这是对当前"TabFM 万能"叙事的最直接反驳。
  • 特征类型多样化的场景下，TabFM 的相对优势收窄甚至反转——含文本、高基数类别这类它们宣传擅长的场景，反而是它们最容易翻车的场景。

这一结论的隐含含义非常工程化：选模型时，场景决定模型，而不是"FM 一招鲜"。预算紧、IID、中小数据，TabFM 值得试；时序/分组/大规模/高维，树模型与深度学习方法仍是稳妥选择。

⚠️ 具体的逐模型分数、每个数据集上的胜负矩阵、参数规模分布等细节，原文 abstract 与可用元数据未明确给出，建议阅读原文 §4§5 核实。

亮点与局限

亮点

  • 第一个真正"统一整体"的表格基准：过去类似工作多是某一类任务（仅有 IID、仅有时序、仅有分组），BeyondArena 是首个把三类任务类型 + 多尺度 + 多特征类型 + 跨学科组合在一起的整体基准。
  • 反共识结论清晰：把"FM 在非 IID 上不行"这件事用 11×142 的规模量化出来，给整个社区一个非常明确的矫正信号。
  • 配套工具可持续：Data Foundry 把"一次性 benchmark"升级为"持续平台"，降低新数据集接入成本。这是学术 benchmark 工业化的典范路径。
  • 跨学科覆盖：让评估结果对医学、金融、零售、工程等多个领域的实际从业者都有参考价值。

局限

  • 仍未触及全部"难场景"：时序/分组/高基数/大规模是论文强调的，但还有更难的场景——分布漂移（distribution shift over time）、对抗特征、缺失率极高、极度类别不平衡等，abstract 没明确是否覆盖。
  • 11 个模型代表性有限：选哪些模型进入 ModelRegistry 直接影响结论。11 个里可能没包含某些最新 TabFM 版本，或某些专用时序模型（如时序树、NeuralProphet 等），具体名单原文未明确。
  • 142 个数据集的分布偏置：跨学科是好事，但每个学科的数据集数量是否平衡、难度梯度是否合理，会影响"哪个学科最弱"这种子结论的可信度，原文未明确。
  • 缺少"训练效率 / 推理时延"维度：工业选模型时，TabFM 的推理成本远高于树模型是公认事实，但 abstract 没明确 BeyondArena 是否在评测中纳入 cost-aware 维度。

对工程落地的启发

  1. 不要迷信"基础模型一招鲜"。在表格预测场景里，第一步应当看任务类型——IID 小数据试 TabFM，非 IID / 大数据 / 高维优先考虑树模型与深度学习方法。
  2. 基准的可信度取决于覆盖。任何模型/算法选型工作都应该自问"我的评估覆盖了我业务里所有难场景吗"——BeyondArena 给出的多维度切分（任务类型 × 规模 × 特征类型 × 学科）就是这种自检的范本。
  3. 平台化优于一次性 benchmark。团队内部搭模型评估体系时，不要只做一次性评测表，而应该像 Data Foundry 一样提供：标准化数据接入 + 元数据 schema + 评估协议 + 模型注册表。这能让评估能力持续滚动积累。
  4. TabFM 与树模型不是替代而是互补。工程上一个常见做法是"TabFM 做 cold-start + 树模型做 production"，BeyondArena 的结论支持这种 hybrid 策略：让 TabFM 在它擅长的小数据场景提供初始预测，用树模型在数据积累到一定规模后接管。
  5. 关注非 IID 切分。评估时序/分组数据时，不要用随机切分——这会泄漏未来信息或破坏组内相关性。BeyondArena 的"按时间切 / 按组切"是正确示范。

与同方向工作的关系

  • vs. OpenML-CC18 / TabZilla / TABLLM-bench：这些是 IID 主导的标准基准，BeyondArena 把任务类型从 IID 扩展到 temporal 与 grouped。
  • vs. PMLB（Penn Machine Learning Benchmarks）：PMLB 是数据集合，但评估协议偏 IID；BeyondArena 在协议层做了多任务类型适配。
  • vs. TabPFN / TabICL / Trompt 等 TabFM 论文：这些是被评测对象。BeyondArena 给它们提供了一个更严格、更难、更工业化的试金石。
  • vs. 时序表格专用基准（如 Columbia 商业基准、医疗 EHR 基准）：这些是某一类的深度基准，BeyondArena 想做的是"整体"——同时支持三类而非只支持一类。

适合谁读

  • AutoML / 表格学习研究者：任何在写 TabFM 或"基础模型 for tabular"论文的人，都应该先在 BeyondArena 上跑一遍 baseline，避免在 IID 上自嗨。
  • 数据科学家 / ML 工程师：在做表格预测选型时，这篇给出的"IID 中小 → TabFM，非 IID / 大 / 高维 → 树模型与深度学习"结论是直接可用的决策树。
  • 金融风控 / 医疗 / 零售领域 ML 团队：这些领域的表格任务几乎都是时序或分组的，BeyondArena 的"非 IID 才见真章"结论特别值得借鉴。
  • Benchmark 设计者：这篇是"如何做一个能持续服务社区的 benchmark"的范例——不仅给数据，还给框架 + 元数据 schema + 评估协议。

不确定 / 待核实

  • 11 个被评测模型的完整名单（含具体 TabFM 版本、树模型、深度学习模型）原文未明确。
  • 142 个数据集的具体学科分布、任务类型分布、规模分布，原文未明确。
  • 评估协议是否纳入训练时间、推理时延、显存占用等 cost-aware 指标，原文未明确。
  • BeyondArena 的"中位 / 平均 / 子集切片"具体数字，原文未明确。

工程落地与核查（Jay）

真实系统怎么用

模型选型决策树（可直接贴在团队 Wiki）

输入任务特征 → 判断路径：
1. 样本量 < 10,000 且为随机切分？ → TabFM（TabPFN / TabICL）优先
2. 样本量 10,000–100,000，随机切分？ → TabFM + XGBoost/LightGBM 对比选优
3. 样本量 > 100,000？ → 直接树模型或深度学习方法，TabFM 通常不划算
4. 时序/分组任务（任意规模）？ → 严格用时间切/组切，树模型或深度学习方法，TabFM 不适用
5. 含高基数 categorical（如 SKU、ID）或 free text？ → 树模型或深度学习方法优先

Data Foundry 风格的内部评估框架骨架

如果团队内部有多个表格预测任务要做，用 Data Foundry 的思路搭一个简化版注册体系：

# 模型注册表
MODEL_REGISTRY = {
    "tabpfn": TabPFNClassifier(),
    "xgboost": XGBClassifier(),
    "lightgbm": LGBMClassifier(),
    "mlp": MLPClassifier(),
    "catboost": CatBoostClassifier(),
}

# 评估协议（参考 Data Foundry schema）
EVAL_PROTOCOLS = {
    "iid":      {"split": "random",      "metrics": ["auc", "accuracy"]},
    "temporal": {"split": "time",         "metrics": ["auc", "ece"]},
    "grouped":  {"split": "group",        "metrics": ["auc", "f1"]},
}

def run_benchmark(ds_name, task_type, model_names):
    ds = Dataset.load(ds_name)
    protocol = EvalProtocol(**EVAL_PROTOCOLS[task_type])
    results = {}
    for m in model_names:
        model = MODEL_REGISTRY[m]
        preds = model.fit_predict(ds.train, ds.test)
        results[m] = protocol.score(preds)
    return results

这样每次新增数据集只需 Dataset.load + 声明 task_type，不需要重新写 pipeline。

常见坑与避让

坑 1：用随机切分跑时序数据

这是表格建模里最常见的评估错误。随机切分会让模型"看到未来"，导致 AUC/准确率高估 10–30%。BeyondArena 的 temporal 分组用时间切是正确示范，工程上如果数据有时间戳，必须用 sklearn.model_selection.TimeSeriesSplit 或按时间点切。

坑 2：把 TabFM 的 IID 优势外推到非 IID 场景

TabPFN 等在 OpenML-CC18 上很强，是因为这些数据集本身偏 IID。到了真实业务（金融风控、医疗随访），表头可能随时间漂移，同一用户在不同时间的样本有相关性——TabFM 的优势就消失了，甚至反转为劣势。选型时一定要用业务真实切分方式评估，而不是直接相信 IID 基准数字。

坑 3：忽视 cost-aware 维度

TabFM 的推理延迟通常是 XGBoost 的 10–100 倍（取决于模型大小），且需要 GPU 推理。在延迟敏感场景（实时风控、在线推荐），仅靠 accuracy/AUC 选型会选到错误的模型。建议在评估协议里加入 p99 延迟和单样本推理时间。

坑 4：混合策略没有正确冷启动设计

"TabFM 做 cold-start + 树模型接管"听起来简单，但很多人没有把「数据量何时触发切换」量化清楚。建议设一个明确的 data volume threshold（如 10K / 50K / 100K），在阈值到达时自动切换模型，而不是靠感觉。

核查清单（落地前必查）

  • [ ] 确认当前任务类型（IID / temporal / grouped），并用对应切分方式做评估，随机切分跑 temporal/grouped 任务需立即修正
  • [ ] 在真实业务切分下（不是 OpenML 标准切分）跑 TabFM vs. XGBoost/LightGBM 对比
  • [ ] 评估协议里加入推理延迟（p50 / p99）和显存占用，TabFM 在 GPU 不可用时的推理成本需单独评估
  • [ ] 如果含高基数 categorical（如商品 SKU > 10,000 个），确认 TabFM 版本是否支持此类特征，或改用 LightGBM/CatBoost
  • [ ] ⚠️ 142 数据集具体分布与 11 个模型名单未经原文核验，引用具体数字前建议阅读原文 §4–§5 核实