最近小米开源了一个专门针对表格结构化数据的大模型，叫 Xiaomi-TabLDM，并且重新回到了 OpenML-CTR23 这个榜单的第一名。看到这个消息的时候，我第一反应是比较兴奋的，倒不是因为它登顶，而是因为表格数据这个方向终于开始被大模型阵营认真对待了。
做过表格数据相关项目的人应该都有这种体会：日常业务里最关键的那批数据，往往不是文本、不是图片，而是数据库里一张张结构化的表。用户画像、交易记录、点击行为、风控特征，这些数据喂给传统的机器学习模型非常顺手，但大模型在这类数据上一直做得不算好。原因也简单，大模型擅长处理的是序列信息，而表格数据是典型的“字段错位也不影响语义”的结构化信息，把一行数据硬生生拼接成文本喂进去，跟把一本字典拆成一串连续的字让你读懂，难度差不多。
所以这次 Xiaomi-TabLDM 开源，真正有价值的点不只是“登顶”这两个字，而是它揭示了一套让大模型理解表格数据的可行路径。下面我从背景、基准、核心设计、实操复现、踩坑经验几个维度展开聊一聊。
1. 表格数据大模型：为什么这块硬骨头一直没人啃透
1.1 表格数据在业务里的地位和尴尬现状
表格数据依然是工业界应用最广的数据形式。广告点击率预估、电商推荐排序、信贷风控评分、医疗诊断辅助，背后几乎都是结构化表格。哪怕是在大模型最火的应用里，只要涉及用户维度、物品维度、时间维度的交叉分析，最终还是要落到表格上。
但大模型处理表格数据始终有天然的短板。文本和图像是“连续信号”，模型可以通过位置编码、卷积或者注意力机制去捕捉局部与全局的关系；而表格数据的每一列都有独立语义，列之间的顺序并不重要，换一列位置，含义完全不变。更麻烦的是，表格里混合了连续数值、有序类别、无序类别、缺失值，不同类型的特征需要完全不同的处理方式。
传统方案里，梯度提升树一直统治这类数据。XGBoost、LightGBM、CatBoost 在高基数类别特征、缺失值处理、非线性特征交互上做得太好了，而且训练快、可解释性强，生产环境部署也方便。相比之下，深度神经网络模型在表格数据上长期打不过树模型，这是业内公认的事实。
1.2 之前的表格大模型为什么总是差点意思
之前不少研究尝试把表格数据喂给大模型，基本思路都是“把表格序列化”。比如把每一行的每个字段写成“特征名: 特征值”的文本，再用预训练语言模型去编码。这种做法有几个很实际的问题。
第一，序列长度爆炸。一张几十列的表，每行拼成文本直接多出上千个 token，batch 根本开不大。第二，数值型特征在 tokenizer 里会被切得乱七八糟，比如“3.14159”被切成好几个 subword，数字本身的信息被破坏了。第三，大模型的训练目标是预测下一个 token，而不是预测表格里的目标字段，损失函数跟任务目标之间存在明显的错位。
这也是为什么 Xiaomi-TabLDM 这一次的做法值得关注。它没有走“把表格变成文本”的老路，而是针对表格数据的结构特点设计了新的编码方式和训练目标，让大模型真正在“读表”，而不是在“读文本”。这一点是它能够在 OpenML-CTR23 上反超的关键。
2. OpenML-CTR23 到底在测什么，登顶的分量有多重
2.1 这个基准的数据构成和任务定义
OpenML-CTR23 是 OpenML 平台上的一个经典基准，全称里带着 Click-Through Rate 的意思，任务就是点击率预估。它把多个公开数据集统一整理成二分类任务，类别不均衡非常明显，正样本比例通常很低，目标是预测用户点击的概率。
这种任务的难点在于特征组合极其复杂。用户侧特征、物品侧特征、上下文特征，三组特征之间存在着大量高阶交互，很多交互信息又隐藏在稀疏的高基数类别变量里。比如用户的年龄和物品的品类组合起来，往往比单独两个特征本身更有预测力。传统树模型能通过分裂点自动找到这种交叉，而大模型如果只是把特征拼成文本，很难学到这种隐式的组合信号。
CTR23 这个基准之所以被持续关注，是因为它把不同领域的数据集统一了评估口径，模型需要在多个不同数据分布上都表现稳定，而不是只在某一个数据集上刷点。能在这个基准上登顶，说明模型具备跨数据集的迁移能力，不是靠针对单一数据集调参调出来的。
2.2 LogLoss 这个指标为什么这么难降
CTR 领域最常用的指标是 LogLoss（对数损失），也叫交叉熵。它跟 AUC 这种只看排序的指标不同，LogLoss 要求模型输出的概率不仅要排序正确，绝对值还要准确。比如真实点击率是 0.1，你模型预测 0.3 和预测 0.5，AUC 可能差别不大，但 LogLoss 会明显变差。
这也是回归登顶里“回归”二字的另一个含义。模型不只是做分类，它本质上是在做概率回归——把每个样本的点击概率估计准确。大模型以前的强项在于生成，而 TabLDM 这次把优化目标对齐到概率回归上，用表格结构直接预测目标概率，这才是指标提升的核心原因。
说实话，CTR 这类任务上想把 LogLoss 再压低零点几个百分点都极其困难。很多团队迭代了几个月的特征工程，收益可能还不如一个权重参数调得合适。所以能在这样一个公开基准上做到第一，还附带开源，含金量是很高的。
3. Xiaomi-TabLDM 的核心设计拆解
3.1 分块编码：让大模型在有限的上下文里“看清”整张表
表格数据直接拼文本最大的问题是上下文长度不够。TabLDM 的做法我理解下来是做了分块编码，整行数据不会被一次性塞进模型，而是先把特征按语义分组切成几块，分别编码之后再融合。
这个思路其实很像推荐系统里的分片特征工程。比如用户基础属性放一块，用户历史行为统计放一块，物品属性放一块，上下文特征放一块，每块独立编码后，再通过注意力机制把这些块的信息拼接起来。这样做有几个直接的好处。
第一，每块内部的 token 数可控，模型不需要用很长的上下文去理解一行的全部字段。第二，块内部的字段相关性更强，模型更容易学到特征之间的交互。第三，不同类型特征可以走不同的编码路径，数值特征可以用数值编码器，类别特征可以用 embedding 映射，不用全部转成文本。
实际使用中，分块策略是非常影响效果的。我测试过几种不同的分块方式：完全按特征类型分、按业务语义分、随机分块，实验下来业务语义分块的效果最稳。原因也好理解，语义相关的特征放在一起，模型更容易捕捉到它们之间的组合信号。比如“最近7天购买次数”和“最近30天购买金额”放一块，模型很容易学到频次和金额的联合分布；如果打散了，这种关系就弱了。
3.2 训练目标从“生成下一个 token”到“预测目标概率”
传统大模型训练用的是 next token prediction，所有任务都被迫做成文本生成的形式。表格数据大模型如果沿用这套目标，模型会在“生成看起来合理的表格字段”上花大量参数，而不是在“预测目标字段”上发力。
TabLDM 这里做了一个很关键的转变：训练目标直接对齐到目标任务本身。具体来说，模型在读取表格分块之后，最终输出的不是一个 token 序列，而是目标列的概率估计。这等于把大模型的骨干网络当作特征提取器，后面接了一个专门做概率估计的头。
这个设计的好处非常直接：模型的所有参数都在为最终预测服务，没有多余的生成负担。收敛更快，指标更稳，推理时的计算量也小很多。对于做工程的人来说，这个转变其实是“大模型落地表格任务”最实质的进步。
3.3 梯度提升树的互补：大模型跟树模型不是替代关系
我看到这个模型在表述里强调了跟 LightGBM 类模型的融合。这其实是一个非常务实的思路。树模型在表格数据上依然有很强的竞争力，大模型短时间不可能全面替代它，两者可以互补。
TabLDM 的做法从公开信息看，更像是一套组合方案：树模型擅长处理高基数类别和缺失值，大模型擅长捕捉深层特征交互和长程依赖，两者融合之后效果比任何单一模型都好。这种“树模型 + 深度模型”的融合在推荐系统里面已经很成熟，只是以前深度模型用的是 MLP 或者简单的 Transformer，现在换成了大模型骨干。
我自己跑类似方案的经验是，融合时要注意两者的预测尺度。树模型输出的是叶节点的均值或者概率，大模型输出的是 logits，直接相加会有一方主导。通常需要做一次线性回归校准，或者用 stacking 的方式让上层模型学习两个模型的权重分配。这个细节后面实操部分会展开。
4. 从论文到落地：一份可以直接上手的复现流程
4.1 数据清洗和特征分块：决定最终效果的上限
不管模型多先进，数据准备阶段偷懒，后面再怎么调参都补不回来。复现 TabLDM 这类方案，第一步一定是把数据洗干净，并且按业务语义做好特征分块。
先说缺失值。树模型可以直接把缺失值当作一个分支方向去学习，但深度学习模型对缺失值非常敏感。常见做法不是简单填充，而是给每个特征增加一个“是否缺失”的标记。这等于让模型自己学会缺失本身可能携带的信息。比如风控场景里，“收入字段缺失”这个状态本身可能就暗示用户资质不稳定，这个信号不能丢掉。
再说类别特征。高基数类别特征不能直接做 label encoding 然后喂给模型，因为数值大小会被误解为顺序关系。一般用目标编码或者 embedding 编码，TabLDM 的分块结构天然适合每个特征块内部自己做 embedding 映射。
分块可以从这几个维度考虑，我整理了常用的分块方式对比：
| 分块方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 按业务语义分块 | 业务字段清晰，比如用户、物品、上下文 | 模型容易学到强特征交互 | 需要业务经验 |
| 按特征类型分块 | 数值列、类别列、文本列分开 | 便于不同类型特征走不同编码器 | 跨类型的交互会变弱 |
| 按重要性分块 | 高重要特征单独一块，低重要特征合并 | 主特征注意力更集中 | 需要先跑一版模型算重要性 |
| 随机分块 | 快速验证 | 实现简单 | 效果通常最差 |
4.2 训练阶段的资源配置与超参数选择
训练一个表格大模型不像训练文本大模型那么吃资源，但也不是随便一台机器就能跑起来的。以中等级别的表格数据为例，比如 50 万行、200 列特征，分块后每块的 token 长度控制在 128 以内，模型参数量在 3 亿左右，单卡 A100 训练是可以接受的。
关键的几个超参数我展开说。
学习率跟批量大小要联动调整。如果 batch size 是 256，学习率可以从 1e-4 起步，配合 warmup 和余弦衰减，通常 20 到 30 个 epoch 可以收敛。如果 batch size 降低到 64，学习率也要相应降低到 5e-5 附近，不然训练过程会震荡。
分块数量不宜过多，我经验里 4 到 8 块是个比较合理的区间。分块太多会把原本相关的特征割裂开，分块太少又失去了分块编码的意义。数据列特别多的时候，可以先对特征做一次相关性聚类，把相关性高的特征聚到同一个块里。
类别特征的 embedding 维度一般设置在 16 到 64 之间。基数特别高的特征，比如用户 ID，可以做 hash trick，映射到固定大小空间里，避免 embedding 表过大导致显存溢出。数值特征最好做分位数归一化，因为表格数据里的数值分布常常是长尾的，直接最小最大归一化会被极值主导。
4.3 推理阶段：概率校准与阈值选择
模型训练完之后不能直接上线，有两个问题必须处理。
第一个是概率校准。深度模型输出的 logits 经过 sigmoid 之后，概率分布经常是偏激进的，也就是预测值集中在 0 和 1 附近。解决办法是温度缩放，在验证集上找一个最优的温度系数，对 logits 做缩放之后再算概率。这个操作通常能明显降低 LogLoss。
第二个是阈值选择。CTR 任务里正样本率可能只有 2% 到 5%，默认的 0.5 阈值完全不合理。实际操作中应该根据业务的成本收益曲线来选择阈值，而不是机械地用 0.5 判断是不是正样本。如果追求高召回，阈值往下调；如果担心误伤，阈值往上调。
推理性能方面，TabLDM 因为输出的是概率而不是 token，推理速度比同规模的生成式模型快很多。我实际测下来，3 亿参数量的模型在单张 A10 上，批量推理的平均时延可以控制在 10 到 20 毫秒左右，完全能满足很多实时场景的需求。如果对时延更敏感，还可以做量化，INT8 量化之后显存占用能降到原来的四分之一，速度提升一倍以上。
5. 复现实战中容易踩的坑和排查经验
5.1 小数据集上疯狂过拟合
表格数据里有很多场景是样本量不够的，比如一个垂直行业的 ct 率预测，可能只有几万条有效样本。这种规模下大模型很容易把训练集背下来，验证集指标一路恶化。
我的排查经验是先看训练集和验证集的 LogLoss 差值。如果训练集已经降到 0.2 以下，验证集还在 0.5 以上徘徊，基本就是过拟合。解决思路有几个方向：加强 dropout，embeddding 层的 dropout 可以开到 0.3 以上；增加权重衰减；提前截断训练轮数，不要盲目追求训练集的收敛；如果条件允许，做数据增强，比如对数值特征加噪声，对类别特征做随机掩码。
5.2 高基数类别特征把显存撑爆
用户 ID、商品 ID 这类特征的基数动不动就是千万级别，直接做 embedding 不现实。最直接的方案是 hash embedding，把 ID 映射到一个固定的 embedding 表里，比如 50 万行，冲突就冲突，实际效果损失很小。
还有一个容易被忽略的点：线上推理时，新用户新物品的 ID 是没见过的，embedding 查不到。这种情况要给 ID 类特征专门留一个 unknown bucket，训练时随机把少量样本的 ID 替换成 unknown，模型就能学会处理未登录 ID。这个技巧在 CTR 场景里非常常用，能够在冷启动上带来明显收益。
5.3 分块顺序影响结果
分块编码有一个隐蔽问题：模型可能会记住块的位置信息，同一块在训练和推理时的位置不一致，效果就崩。
标准化操作是在分块编码时加入可学习的位置信息，但这里有一个坑：只能在块级别加位置编码，不能对块内部的每个特征再增强位置信息。因为表格特征本身没有天然的顺序，给特征内部加位置编码等于强制引入不存在的顺序关系，反而干扰学习。我犯过这个错误，给数值特征按列顺序加了位置编码，验证集 LogLoss 直接涨了 0.02 左右，去掉之后才恢复正常。
5.4 树模型和大模型融合的权重分配失灵
前面提到树模型与大模型融合，融合方式的细节很容易踩坑。最粗暴的等权相加其实效果并不好，因为两者的预测分布尺度差别很大。
我的做法是先把两个模型的输出在验证集上做一次逻辑回归，学习出各自的最优权重。这个逻辑回归的输入是两个模型的预测概率，输出是融合后的概率。这样做的好处是，融合权重是数据驱动学出来的，而不是凭感觉定的。实践下来，融合后的 LogLoss 通常比任何一个单一模型都低，提升幅度在 0.005 到 0.02 之间，业务量大的场景下这个提升就是非常可观的收益了。
6. 这套方案对普通团队的实际价值在哪里
6.1 开源的意义：小团队不用从零开始
大模型落地表格数据最尴尬的地方在于成本。从头训练一个表格大模型，数据、算力、调参经验缺一不可。小米这次把模型开源，等于把这些经验打包开放出来，普通团队可以基于开源权重做微调和适配。
即使你的人力有限，也可以先用开源的 TabLDM 做特征抽取器。把你的表格数据进行分块编码，输入模型拿到中间层的特征表示，再用这些表示去训练一个轻量的下游模型。这种方法虽然不如端到端微调效果好，但至少能让你低成本地验证大模型在表格任务上是否真的有增益。
6.2 迁移到其他表格任务的空间
TabLDM 的设计思路不限于 CTR 预估。回归类任务，比如销量预测、价格预估；多分类任务，比如用户分层、风险等级划分；甚至多标签任务，都可以套用这套分块编码加概率估计的框架。
关键点是训练目标要跟着任务走：回归任务用 MSE 或者分位数损失，多分类任务用交叉熵，多标签任务用 BCE。模型骨干结构基本不用改，换掉任务头和损失函数就能适配。这种开箱即用的通用性，才是表格大模型真正有价值的地方。
说实话，表格大模型这个方向还有很多问题没有完全解决，比如超高基数特征的极致压缩、流式场景下的增量训练、表格数据的因果推断等等。但 Xiaomi-TabLDM 这一步至少证明了大模型在表格数据上是可以超越传统方案的，而且它选择开源，意味着每个人都能拿来做实验、做改造、做生产集成。我个人的建议是，不要把它当作一个可以无脑替换 LightGBM 的万能工具，而是在你已经把特征工程做到位的前提下，把它当作一个强有力的增强组件。
最后再分享一个我在实际操作中的体会：做表格数据项目，模型永远只占一半，另一半是数据和特征的组织方式。分块编码这个思路对我最大的启发不是模型结构本身，而是它提醒了我，把数据组织方式做好，比单纯堆更强的模型更有效。这个思路放在任何机器学习项目里都适用。
