实测 NVIDIA 表格基础模型库：免训练预测可用，但三个默认设置会静默出错

Sana Hassan 在 MarkTechPost 发表了一篇实测教程，系统测试了 NVIDIA 新发布的结构化数据模型库（Structured Data Models）。这个库把多个预训练表格基础模型封装在同一个 PyTorch 接口后面，使用者只需提供标注好的上下文行和待预测的查询行，模型在一次前向传播中返回概率或完整预测分布，不需要训练步骤，也不需要调超参数。在乳腺癌数据集上，用 300 行标注数据作为上下文，TabICLv2 和 KumoTabular 两个模型在完全没有训练的情况下均达到了 0.970 的准确率，AUC 分别为 0.996 和 0.995，与在同一批数据上训练的逻辑回归和梯度提升基线基本持平。在糖尿病回归任务上，模型中位数预测的 RMSE 为 53.6，略优于 RidgeCV 的 54.3，明显优于梯度提升的 64.7，而且一次前向传播同时返回 999 个分位数构成的预测分布，其 80% 和 90% 区间对留出样本的实际覆盖率分别接近 81% 和 91.5%，校准表现良好。这些结果足以解释为什么从业者会想直接用这个库。

但 Hassan 真正想传达的信息不在模型本身，而在默认设置。他发现三个地方会静默地做错事，而且不会报错。第一个是预处理配方：TabICLv2 的默认配方按语义类型分派，只处理类别列和数值列，时间戳和文本列根本不会变成特征。在一个客服工单升级预测任务中——升级信号来自工单打开的时间和工单内容里的关键词——默认配方的 AUC 只有 0.525，接近随机猜测。库确实会发出一条 RuntimeWarning 指出被忽略的列类型，但这是一次性警告：同一个进程里后续所有模型调用都静默丢弃这些列。加上 AddCalendarFields 把时间戳转为周期编码的小时和星期特征后，AUC 升到 0.634；再加上 TFIDF 提取工单文本后，升到 0.789。

第二个陷阱在解释器里。GradientExplainer 对每个估计器调用一次输出函数，每次调用覆盖上一次的结果，所以 num_estimators=4 时你拿到的解释只是最后一个估计器的，不是平均。更隐蔽的是，默认配方对每个估计器打乱类别标签顺序，如果按列位置而不是列名选取目标概率，在顺序被反转的种子下所有特征符号都会翻转。Hassan 在六颗种子上验证：按位置选取在两颗种子上翻转了全部符号，按名称选取在六颗种子上都给出正确方向。

第三个也是最严重的一个，涉及关系模型。Hassan 构造了一个包含 800 个客户、60 种产品和一年订单的小型商店数据库，任务是预测每个客户在截止日后 30 天内是否会再次下单。KumoRelational 在声明了时间列的情况下，从原始三张表中读取订单行，通过外键遍历邻居，达到 AUC 0.823——与手工构建六个历史特征（近 30 天和 90 天订单数、消费额、距上次下单天数、累计订单数）的 TabICLv2 管线（0.828）几乎相同。但当他不声明时间列时，AUC 跳到 0.940。原因很简单：没有时间列，采样器可以自由返回截止日期之后的订单，而这些订单恰好定义了标签。模型不再是在预测，而是在读答案。没有任何错误被抛出，数字看起来像是突破。

Hassan 的结论是：默认设置比模型本身更值得审查。免训练表格预测确实可用，但每个有默认行为的组件都可能在静默中把关键信息挡在模型外面，或者把不该看到的信息递进去。他的建议是三句话：主动声明语义类型而不是依赖推断，在解释器里按名称而不是位置选取类别，以及每一张有时间列的表都必须放进 time_columns 参数。核心原则是：在信任模型输出之前，先检查什么进入了模型。

需要指出的是，以上所有数字来自 Hassan 在 CPU 上的单次运行，使用合成或小型基准数据集，作者身份是 MarkTechPost 的咨询实习生和印度理工学院马德拉斯分校的双学位学生。这些结果不构成独立复现，也不代表该库在大规模生产数据上的表现。