1. 表格基础模型的上下文选择为什么值得单独聊

表格基础模型（Tabular Foundation Model，下称TFM）这两年在arXiv上的热度一直没降过。从早期的TabPFN，到后来的TabPFN v2、CARTE、以及各类基于Transformer的表格预训练方案，核心思路都是把结构化表格当成一种“语言”来建模，用大规模合成或真实表格数据预训练，再通过上下文学习（In-Context Learning）直接完成小样本分类与回归。这里的关键词是context——不是我们平时说的“上下文语境”那么虚，而是实打实地决定了模型一次能“看”多少行、多少列、多少特征交互。

我最初接触这类模型的时候，踩过一个很典型的坑：把一张几万行的宽表直接塞进去，结果要么显存爆掉，要么推理时间从秒级变成分钟级，要么精度不升反降。后来才慢慢意识到，TFM的context不是“越大越好”，它和传统深度学习里调batch size、调序列长度是两套逻辑。表格数据有它自己的特性：列与列之间存在强语义关联，行与行之间可能是独立同分布，也可能存在时间或分组结构。context怎么选，直接决定了模型是在“认真读题”还是在“被噪声淹没”。

这篇文章我想把这件事讲透。适合谁看？如果你正在用TabPFN这类模型做小样本表格任务，或者你在自己微调/部署表格基础模型，又或者你只是好奇“为什么我喂进去的数据越多效果反而越差”，那这篇应该能帮你省下不少试错时间。我会从设计思路、核心参数、实操流程、常见报错排查几个角度展开，尽量把每个选择背后的“为什么”说清楚，而不是只丢一个结论。

2. 表格基础模型里context到底指什么

2.1 从NLP的context length说起

在NLP里，context length通常指模型一次能处理的最大token数。比如你调用某个大模型API，报错信息里会写“maximum context length is 1048576 tokens”，意思是输入加输出不能超过这个上限。表格基础模型借用了这个概念，但含义有微妙差别。对TFM来说，context一般指参与一次前向推理的训练样本集合，也就是模型在预测目标行时，能同时“看到”的那些带标签的行。

举个具体例子。假设你有一张1000行的表格，想预测其中100行的标签。在传统监督学习里，你会用900行训练、100行测试。但在TFM的上下文学习范式里，你是把900行带标签的数据和100行待预测数据一起喂给模型，模型通过注意力机制在900行里找规律，然后对100行输出预测。这900行就是context，100行是query。context的大小、构成、排列顺序，都会影响最终结果。

2.2 表格context和文本context的本质差异

文本context是线性的、顺序敏感的，位置编码决定了词与词的距离。表格context是二维的，既有行方向也有列方向。一个单元格的值，既受同一行其他列影响，也受同一列其他行影响。这就导致TFM在处理context时，注意力模式比纯文本复杂得多。

我在实际测试中发现，当context行数超过某个阈值后，模型对“列语义”的捕捉会明显变弱。原因不难理解：行数一多，注意力权重被摊薄，模型很难再聚焦到某几个关键列上。这和文本模型里“长文本中间信息丢失”是类似的现象，但表格里更严重，因为表格没有天然的顺序结构来帮助模型定位。

2.3 为什么context选择是个独立问题

很多人会把context选择等同于“调参”，我觉得这个理解偏了。调参是在固定架构下找最优超参，而context选择涉及的是信息筛选：哪些行应该进context，哪些列应该保留，行和列的排列顺序要不要打乱，需不需要做特征工程后再喂进去。这些问题在传统机器学习里对应的是特征选择和采样策略，但在TFM里它们被统一到了context这个入口上。

换句话说，context选择做得好，模型能发挥出预训练阶段学到的先验；做得不好，再强的底座也白搭。这也是为什么arXiv上专门有论文讨论TFM的context构造策略，而不是只关注模型结构本身。

3. 影响context选择的核心因素拆解

3.1 数据规模与任务类型

小样本分类和回归对context的敏感度完全不同。分类任务里，如果类别不平衡，context里少数类样本太少，模型会直接偏向多数类。我试过一个二分类任务，正负比1:9，context里只放50行时，少数类召回率不到0.3；把context扩到200行并做分层采样后，召回率提到0.7以上。回归任务则更关注context的数值分布覆盖，如果context里的目标值都集中在某个区间，模型对区间外的预测会非常保守。

任务类型还影响context的“有效容量”。分类任务通常需要每个类别至少若干样本才能形成稳定决策边界，回归任务则需要context在特征空间里足够分散。这两者的context构造逻辑不能混用。

3.2 特征维度与列语义复杂度

宽表是TFM的噩梦。我做过一个实验，同样500行context，列数从10增加到100时，推理时间翻了近8倍，精度先升后降，拐点大概在30到40列之间。原因在于注意力计算量随列数增长，而且很多列其实是冗余或噪声。

列语义复杂度也很关键。如果列之间高度相关，比如“年龄”和“出生年份”，同时放进context会让模型重复计算。如果列是类别型且基数很高，比如用户ID，直接放进去几乎等于给模型加噪声。这时候要么做目标编码，要么直接剔除。我的经验是，context里的列数控制在20以内，且每列都有明确语义，效果最稳。

3.3 计算资源与延迟约束

context越大，显存占用和推理延迟越高。以TabPFN v2为例，在单张24G显存的卡上，context行数超过2000后基本就跑不动了。即使能跑，单次推理超过10秒在生产环境里也很难接受。所以context选择必须考虑实际部署条件，不能只看离线精度。

这里有个折中思路：如果任务允许，可以把context分成多个子集分别推理，再对结果做集成。这样单次context不用太大，又能利用更多数据。我试过把5000行拆成10个500行的context，集成后的精度比单次2000行context还高一点，延迟也可控。

3.4 预训练分布与迁移距离

TFM在预训练时见过的表格分布，和你的目标任务分布差距越大，context需要越“干净”。如果目标数据有很多缺失值、异常值、或者列类型和预训练数据差异大，context里混入这些噪声会放大分布偏移。这时候宁可少放一些行，也要保证context的质量。

我一般会先做一次分布诊断：看目标数据的列类型、缺失率、数值范围，和模型文档里描述的预训练数据做对比。差距大的话，context行数先砍一半，再逐步加，观察精度变化曲线。

4. context构造的实操策略与参数选择

4.1 行采样：分层、聚类还是随机

行采样是context构造的第一步。随机采样最简单，但在类别不平衡或存在分组结构时会出问题。分层采样按目标变量分布抽，适合分类任务。聚类采样先对特征做聚类再按簇抽，适合回归和分布复杂的场景。

我通常的做法是：先看目标变量分布，如果偏斜明显就用分层；如果特征空间有明显簇结构就用聚类；如果数据量本身不大且分布均匀，随机就够。采样比例上，context行数建议是query行数的5到20倍。太少模型学不到规律，太多边际收益递减。

4.2 列筛选：相关性、重要性和语义三重过滤

列筛选我一般走三步。第一步算列与目标的相关性，剔除几乎无关的列。第二步用轻量模型（比如逻辑回归或浅层树）算特征重要性，去掉重要性接近零的列。第三步人工过一遍列名，把语义重复或明显是ID类的列拿掉。

这三步下来，列数通常能压到原来的三分之一到一半。别心疼删掉的列，TFM的注意力机制对噪声列很敏感，少而精比多而杂强。

4.3 排列顺序：行序和列序要不要打乱

行序方面，如果数据本身有时间或分组结构，保持原序可能让模型学到顺序信息，但也可能过拟合。我一般会做一次随机打乱，再做一次保持原序，对比验证集精度。多数情况下打乱后更稳，因为TFM预训练时见到的表格大多是无序的。

列序方面，把语义相近的列放在一起，有时能帮助注意力聚焦。但这个效果不稳定，我通常不刻意调整列序，除非有明确的领域知识支持某种排列。

4.4 数值处理：归一化、分箱与缺失值

TFM对数值尺度比较敏感。我试过同一份数据，不做归一化和做归一化，精度差了近10个百分点。归一化用RobustScaler比StandardScaler更稳，因为表格数据常有离群值。类别型列做目标编码或频率编码，比one-hot更适合高基数场景。

缺失值处理上，如果缺失率低于5%，直接填中位数或众数就行。缺失率高的话，建议加一个缺失指示列，让模型知道这个值原本是缺失的，而不是真实值。

4.5 context大小的经验区间

综合我自己的测试和arXiv上几篇论文的结论，context行数的经验区间大致如下：

这个表不是硬性规定，但可以作为起点。实际调的时候，我会从区间下限开始，每次增加50%行数，观察验证集精度，直到精度不再提升或延迟超限。

5. 完整实操流程：从原始表格到可用的context

5.1 数据诊断与预处理

拿到一份表格，我第一步不是急着喂模型，而是先做诊断。看行数、列数、每列类型、缺失率、目标变量分布。这一步用pandas几行代码就能完成。诊断的目的是判断这份数据适不适合直接用TFM，以及context大概要控制在什么规模。

import pandas as pd df = pd.read_csv("data.csv") print(df.shape) print(df.dtypes) print(df.isnull().mean().sort_values(ascending=False).head(20)) print(df["target"].value_counts(normalize=True))

如果缺失率超过30%的列很多，或者目标变量极度偏斜，我会先考虑做数据清洗或重采样，而不是硬调context。

5.2 列筛选与编码

列筛选按前面说的三步走。编码方面，数值列用RobustScaler，类别列用目标编码。目标编码要注意做平滑，避免过拟合。我一般用category_encoders库里的TargetEncoder，平滑参数设10到20。

from sklearn.preprocessing import RobustScaler from category_encoders import TargetEncoder num_cols = df.select_dtypes(include=["number"]).columns.tolist() cat_cols = df.select_dtypes(include=["object", "category"]).columns.tolist() scaler = RobustScaler() df[num_cols] = scaler.fit_transform(df[num_cols]) encoder = TargetEncoder(smoothing=10) df[cat_cols] = encoder.fit_transform(df[cat_cols], df["target"])

编码完记得检查一下有没有产生新的缺失值或无穷值，有的话要处理掉。

5.3 行采样与context组装

行采样根据任务类型选策略。分类用分层，回归用聚类或随机。采样完把context行和query行分开，context带标签，query不带标签。组装时把context放在前面，query放在后面，这是TFM的标准输入格式。

from sklearn.model_selection import train_test_split context_df, query_df = train_test_split( df, test_size=0.2, stratify=df["target"], random_state=42 ) context_X = context_df.drop(columns=["target"]) context_y = context_df["target"] query_X = query_df.drop(columns=["target"])

如果context行数还是太多，可以再做一次降采样，直到落在经验区间内。

5.4 推理与结果评估

推理阶段把context和query一起喂给模型。以TabPFN为例，fit的时候传context，predict的时候传query。评估指标分类用AUC、F1，回归用RMSE、MAE。我一般会跑多次不同随机种子的采样，看指标的均值和方差，方差大的话说明context选择不稳定，需要调整采样策略。

from tabpfn import TabPFNClassifier clf = TabPFNClassifier(device="cuda") clf.fit(context_X.values, context_y.values) preds = clf.predict(query_X.values) proba = clf.predict_proba(query_X.values)

跑完记得记录context行数、列数、采样策略、精度和延迟，方便后续对比。

5.5 迭代优化：从基线到稳定

第一轮跑完通常不是最优。我会做几轮迭代：固定其他条件，只调context行数；然后固定行数，只调列集合；再调采样策略。每轮记录结果，画一条精度随context变化的曲线。拐点通常就是比较合适的context大小。

迭代过程中要注意，验证集不能和context重叠，否则精度会虚高。我一般会留一个独立的验证集，只用来评估，不参与context构造。

6. 常见报错与排查技巧实录

6.1 context超限类报错

最常见的报错就是“maximum context length exceeded”。这类报错在TFM里通常表现为显存不足或推理中断。排查思路：先看context行数和列数乘积，估算token量；再看模型文档里的上限；如果超了，优先减行数，因为减列数对精度影响更大。

有个细节容易被忽略：有些TFM会把列名也编码进context，列名很长的话也会占token。我遇到过列名是长句子的表格，光列名就占了近10%的context预算。这种情况要么缩短列名，要么在预处理阶段把列名去掉。

6.2 精度异常下降的排查

精度突然下降，先查三件事：context里有没有混入query的标签，归一化是不是在采样后做的导致分布偏移，类别编码有没有产生数据泄漏。这三类问题我几乎每次调新数据都会遇到至少一个。

排查方法：把context和query的分布画出来对比，看有没有明显偏移；检查编码器的fit范围是不是只用了context数据；确认标签列没有意外进入特征。

6.3 推理速度慢的优化

推理慢通常是context太大或列太多。优化顺序：先减行数，再减列数，最后考虑换更小的模型或做量化。如果任务允许，可以把context缓存起来，query分批推理，避免每次重新编码context。

我试过把context的编码结果缓存成numpy数组，query推理时直接复用，延迟从8秒降到2秒左右。这个技巧在需要频繁推理的场景下很实用。

6.4 常见问题速查表

6.5 几个容易踩的坑

第一个坑是归一化顺序。一定要先划分context和query，再分别做归一化，或者用context的统计量去归一化query。如果先归一化再划分，query的统计信息会泄漏到context里。

第二个坑是目标编码的平滑参数。平滑太小会过拟合，太大等于没编码。我一般从10开始试，根据验证集调整。

第三个坑是context行序。有些TFM对行序敏感，打乱后精度波动大。如果遇到这种情况，可以多试几种行序，选验证集最稳的那种。

第四个坑是列类型判断。pandas有时候会把数值列读成object，导致编码错误。读数据时显式指定dtype，或者读完后强制转换，能避免很多莫名其妙的问题。

7. 不同场景下的context选择实例

7.1 小样本二分类：信用卡欺诈检测

这类任务正负比极端，context构造的核心是保证少数类有足够样本。我的做法是：先对多数类降采样，让正负比接近1:5，再分层抽context。context行数控制在200左右，其中少数类至少30行。列方面只保留交易金额、时间、商户类别等有明确语义的列，去掉ID类列。实测AUC能从0.82提到0.91。

7.2 中等规模回归：房价预测

房价数据通常有几十列，包含数值和类别。context构造时，数值列做RobustScaler，类别列做目标编码，列筛选后保留15到20列。行采样用聚类，保证不同价位区间的房子都有代表。context行数设800左右，RMSE比随机采样低约12%。

7.3 宽表场景：用户行为预测

宽表列数可能上百，直接喂TFM基本跑不动。我的策略是先做列聚类，把相关性高的列合并或剔除，压到20列以内。行采样用分层，按目标变量分箱后抽。context行数控制在500以内，配合缓存编码结果，延迟能压到可接受范围。

7.4 时间序列表格：销量预测

时间序列表格有天然的行序，context构造时要保留时间顺序，不能打乱。行采样用滑动窗口，取最近N个时间点作为context。列方面加入滞后特征和滚动统计量。context行数根据季节周期定，比如周周期就取最近4到8周的数据。

8. 我个人的几条经验总结

调TFM的context这件事，说到底是在信息量和噪声之间找平衡。我自己的几条经验：context行数不是越多越好，拐点通常出现在验证集精度不再提升的时候；列筛选比行采样更重要，噪声列对注意力的干扰远大于噪声行；归一化和编码一定要在划分之后做，否则精度虚高；缓存context编码结果能大幅降低延迟，适合生产环境。

还有一点，不同TFM对context的敏感度不一样。TabPFN v2对行数比较敏感，CARTE对列语义更敏感。换模型的时候，context策略要重新调，不能直接套用。我一般会先用小规模数据快速扫一遍参数空间，找到大致区间后再精细调。

最后分享一个小技巧：如果任务允许，可以把context分成多个子集分别推理再集成。这样既能利用更多数据，又能控制单次context规模，精度和延迟都比较可控。我在几个项目里用这个思路，效果比单次大context稳定不少。