企业官网建设流程全解析

1. 表格基础模型选context这件事，到底在纠结什么

表格基础模型（Tabular Foundation Model）这两年在arXiv上的热度肉眼可见地往上走，从早期的TabPFN到后来的TabDPT、Mitra、CARTE，再到各种针对宽表、稀疏表、异构列优化的变体，几乎每隔几周就有新东西冒出来。但真正上手用过的人都知道，模型本身只是半张牌，另外半张牌是context怎么选。这里的context不是指大语言模型里那个"上下文窗口"的概念，而是指喂给表格基础模型的那一批"参考样本"——也就是in-context learning里作为条件输入的那部分训练数据。

为什么这件事值得单独拎出来讲？因为表格基础模型和传统树模型（XGBoost、LightGBM、CatBoost）的工作范式完全不同。树模型是"我先把参数拟合好，你再拿新数据来推理"，而表格基础模型走的是"我不更新参数，你把训练集和测试集一起丢给我，我现场做推理"。这就意味着，你选哪些样本放进context、放多少、怎么排序、怎么处理缺失和类别特征，直接决定了推理结果的质量。选得好，小样本场景下能吊打调参调了半天的GBDT；选得不好，连逻辑回归都不如。

我最近在几个实际项目里反复折腾这件事，从几万行的金融风控表到几百行的医疗小样本，踩了不少坑，也总结出一些相对稳定的做法。这篇文章就把"表格基础模型如何选context"这个问题拆开揉碎讲清楚，包括背后的原理、具体的选样策略、参数计算、实操代码，以及那些文档里不会写的避坑经验。适合已经在用或者准备用TabPFN这类模型的朋友，也适合对in-context learning在表格场景落地感兴趣的人。

2. 先搞清楚表格基础模型的context机制

2.1 context在表格基础模型里扮演什么角色

传统机器学习里，训练集的作用是更新模型参数。你给模型看一万条数据，它通过梯度下降把权重调到一个合适的位置，然后你把训练集扔掉，只留参数做推理。表格基础模型不是这个逻辑。它本质上是一个在大量合成表格任务上预训练过的Transformer，预训练阶段它学会了"给定一批带标签的样本，如何对新样本做预测"这个元能力。推理的时候，它不更新任何参数，而是把你提供的训练集当作attention的key和value，测试样本当作query，通过注意力机制直接算出预测分布。

所以context就是模型做推理时唯一的信息来源。你给它的这批样本，就是它全部的"经验"。这跟人做判断很像：你让一个经验丰富的医生看一个疑难病例，他脑子里调取的是过去见过的类似病例。你给他调取的病例越相关、越典型，他判断越准；你给他一堆不相关的病例，他反而会被带偏。表格基础模型的context选择，本质上就是在做这件事——为当前测试样本挑选最相关的"参考病例"。

2.2 为什么context长度是个硬约束

这里就涉及到热词里反复出现的那个报错："maximum context length is 1048576 tokens"。虽然这个报错本身多半来自大语言模型的API调用，但它反映的问题在表格基础模型里同样存在——context是有长度上限的。TabPFN v2的默认上限大概是10000个样本左右（具体取决于特征维度），超过这个数就得做选择或者分块。原因很直接：Transformer的attention计算复杂度是O(n²)，context越长，显存占用和推理时间涨得越快。你塞进去五万行，可能直接OOM，也可能推理慢到没法用。

这就产生了一个核心矛盾：样本越多，信息越充分，但计算成本越高；样本越少，推理越快，但可能欠拟合。选context的本质，就是在这个矛盾里找平衡点。而且这个平衡点不是固定的，它取决于你的数据特性、任务难度、以及你对推理延迟的容忍度。

2.3 不同模型的context偏好差异

不是所有表格基础模型对context的偏好都一样。我实测下来大致分三档：

这个表是我在几个中等规模数据集上跑出来的经验值，不是论文里的官方数字。你会发现TabPFN v2对context的容纳能力最强，这也符合它"专为小样本表格设计"的定位。Mitra对context规模很敏感，塞太多反而掉点，因为它更依赖特征工程的质量。CARTE因为带了列语义理解，对异构表的容忍度更好。

提示：选模型之前先看你的数据规模。如果训练集只有几百行，TabPFN v2和Mitra都行；如果训练集上万行，优先考虑TabPFN v2或者做context采样。

3. context选择的四套核心策略

3.1 全量喂入：什么时候可以偷懒

最简单粗暴的做法就是把整个训练集全塞进去。什么时候可以这么干？两个条件同时满足：训练集规模在模型上限以内，且推理延迟可接受。比如你有个3000行的训练集，特征20维，用TabPFN v2，直接全量喂进去，推理一批测试样本可能就几秒钟，完全没必要做选择。

全量喂入的好处是信息无损，不用操心采样偏差。坏处是如果数据里有噪声样本或者标注错误的样本，它们会一起进入context，可能干扰预测。我遇到过一种情况：训练集里有一批早期人工标注的数据，标签质量明显比后期差，全量喂进去之后模型在边界样本上的表现反而不如只用后期数据。所以全量喂入之前，先做一轮数据质量筛查，把明显异常的样本剔掉。

3.2 随机采样：快但有风险

当训练集超过模型上限时，随机采样是最省事的方案。从训练集里随机抽N条（N取模型上限的80%左右，留点余量），组成context。这个方案实现简单，一行代码的事：

import numpy as np def random_context_sample(X_train, y_train, n_samples, seed=42): rng = np.random.default_rng(seed) idx = rng.choice(len(X_train), size=n_samples, replace=False) return X_train[idx], y_train[idx]

但随机采样有个致命问题：它不保证类别平衡。如果是个二分类任务，正样本只占5%，随机抽1000条可能只抽到30个正样本，模型对正类的判断会很不稳定。我试过一个欺诈检测的数据集，正样本占比1.2%，随机采样1000条里只有十几个正样本，AUC直接从0.92掉到0.78。所以随机采样必须配合分层采样，按标签比例抽：

from sklearn.model_selection import train_test_split def stratified_context_sample(X_train, y_train, n_samples, seed=42): X_ctx, _, y_ctx, _ = train_test_split( X_train, y_train, train_size=n_samples, stratify=y_train, random_state=seed ) return X_ctx, y_ctx

分层采样能保证context里的类别分布和原始训练集一致，这是最低要求。但即便如此，随机采样仍然可能漏掉一些稀有的特征组合，对于特征空间复杂的数据集，效果不如后面的几种策略。

3.3 相似度检索：给每个测试样本定制context

这是我认为最值得投入精力的策略。核心思想是：对每个测试样本，从训练集里检索出最相似的K个样本作为它的专属context。这样每个测试样本看到的"参考病例"都是最相关的，推理质量自然更高。

具体怎么做？分三步：

第一步，把表格数据编码成向量。类别特征做one-hot或者target encoding，数值特征做标准化，然后拼成一个稠密向量。如果特征维度很高，可以用PCA降到50-100维，减少计算量。

第二步，用余弦相似度或者欧氏距离检索。对每个测试样本，计算它和所有训练样本的距离，取最近的K个。

第三步，把这K个样本作为context喂给模型。

from sklearn.preprocessing import StandardScaler from sklearn.decomposition import PCA from sklearn.metrics.pairwise import cosine_similarity import numpy as np class SimilarityContextSelector: def __init__(self, k=1000, pca_dim=64): self.k = k self.pca_dim = pca_dim self.scaler = StandardScaler() self.pca = PCA(n_components=pca_dim) def fit(self, X_train): X_scaled = self.scaler.fit_transform(X_train) self.X_encoded = self.pca.fit_transform(X_scaled) return self def select(self, x_test, X_train, y_train): x_scaled = self.scaler.transform(x_test.reshape(1, -1)) x_encoded = self.pca.transform(x_scaled) sims = cosine_similarity(x_encoded, self.X_encoded)[0] top_k_idx = np.argsort(sims)[-self.k:] return X_train[top_k_idx], y_train[top_k_idx]

这个方案的效果在异构数据上特别明显。我做过一个对比实验，同样的TabPFN v2，随机采样context的AUC是0.85，相似度检索context的AUC是0.89，提升4个点。代价是每个测试样本都要做一次检索，推理时间大概增加2-3倍。如果测试集不大（几千条以内），这个代价完全可以接受。

注意：相似度检索的K值不是越大越好。K太大，检索进来的样本相关性下降，反而引入噪声；K太小，信息不足。我的经验是K取模型上限的30%-50%，比如TabPFN v2上限10000，K取3000-5000比较稳。

3.4 聚类分层：兼顾多样性和相关性

相似度检索的问题是，如果测试样本集中在某个区域，检索出来的context可能高度同质，缺乏多样性。这时候可以用聚类分层的方法：先对训练集做聚类（KMeans或者GMM），然后从每个簇里按比例抽取样本组成context。这样既保证了context覆盖不同的数据分布区域，又不会让某个区域主导。

from sklearn.cluster import KMeans def cluster_based_context(X_train, y_train, n_samples, n_clusters=20, seed=42): kmeans = KMeans(n_clusters=n_clusters, random_state=seed, n_init=10) cluster_labels = kmeans.fit_predict(X_train) samples_per_cluster = n_samples // n_clusters selected_idx = [] for c in range(n_clusters): cluster_idx = np.where(cluster_labels == c)[0] if len(cluster_idx) <= samples_per_cluster: selected_idx.extend(cluster_idx) else: rng = np.random.default_rng(seed + c) chosen = rng.choice(cluster_idx, size=samples_per_cluster, replace=False) selected_idx.extend(chosen) selected_idx = np.array(selected_idx) return X_train[selected_idx], y_train[selected_idx]

这个方案适合数据分布明显多峰的场景。比如用户行为数据，可能有"高频低额""低频高额""中等活跃"几个明显的群体，聚类分层能保证context里每个群体都有代表。缺点是聚类数需要调，聚太少覆盖不够，聚太多每个簇样本太少。

4. 实操全流程：从数据到推理的完整链路

4.1 数据预处理的关键细节

表格基础模型虽然号称"开箱即用"，但预处理做得好不好，对结果影响很大。我总结了几条必须做的：

缺失值处理。TabPFN v2内置了缺失值处理机制，但实测下来，如果缺失率超过30%，最好还是手动填充。数值列用中位数填充，类别列用"缺失"作为一个独立类别。不要用均值填充，均值会扭曲分布，尤其是偏态数据。

类别特征编码。低基数（类别数<10）直接one-hot，高基数用target encoding或者frequency encoding。不要用label encoding，因为表格基础模型会把编码后的整数当成有序数值，引入虚假的序关系。这一点很多人会忽略，我一开始也踩过这个坑，把城市编码成0-300的整数，结果模型学出了一堆莫名其妙的规律。

数值特征标准化。虽然TabPFN v2有内置归一化，但如果你用的是Mitra或者自己做相似度检索，标准化是必须的。用StandardScaler或者RobustScaler，后者对异常值更稳。

异常值处理。表格基础模型对异常值比树模型敏感，因为attention机制会被极端值拉偏。建议对数值列做1%-99%的winsorize，把超出范围的值截断到边界。

4.2 context规模的计算与选择

context规模怎么定？我给一个实操的计算框架：

首先看模型上限。TabPFN v2大概是10000，TabDPT是5000，Mitra是2000。这是硬上限，不能超。

然后看你的显存。假设你用一张24G的卡，context规模N和特征维度D的关系大致是：显存占用 ≈ N × D × 4字节 × 常数因子。常数因子取决于模型层数和attention头数，TabPFN v2大概是几十。实测下来，D=50的时候，N=8000大概占15G显存，N=10000就接近20G了。所以如果你显存紧张，N要往下调。

最后看任务难度。简单任务（线性可分）N可以小，1000就够；复杂任务（高度非线性）N要大，尽量往上限靠。怎么判断任务难度？先跑一个小N（比如500）看看效果，如果和全量训练的GBDT差距很大，说明任务复杂，需要加大N。

我一般会做一个context规模扫描：取N=500, 1000, 2000, 5000, 10000，分别跑一遍验证集，画一条N-AUC曲线，找拐点。拐点之后的收益递减，就取拐点附近的N。

4.3 推理阶段的批处理技巧

表格基础模型的推理是逐样本或者逐批做的。如果你有大量测试样本，直接循环调用会很慢。两个优化技巧：

批量推理。把测试样本分成batch，每个batch共享同一个context（如果用的是全局context），一次性算完。TabPFN v2支持batch推理，batch size取64或者128比较合适，太大显存扛不住。

context缓存。如果context是固定的（不随测试样本变化），把context的attention key/value缓存下来，每个batch复用，能省不少计算。这个需要改模型代码，但收益明显，推理速度能提升30%-50%。

# 批量推理示例 def batch_predict(model, X_test, X_ctx, y_ctx, batch_size=64): predictions = [] for i in range(0, len(X_test), batch_size): batch = X_test[i:i+batch_size] pred = model.predict(batch, X_ctx, y_ctx) predictions.append(pred) return np.concatenate(predictions)

4.4 一个完整的端到端示例

把上面的东西串起来，一个完整的流程大概长这样：

import numpy as np from sklearn.preprocessing import StandardScaler from sklearn.model_selection import train_test_split # 1. 数据准备 X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, stratify=y, random_state=42 ) # 2. 预处理 scaler = StandardScaler() X_train_scaled = scaler.fit_transform(X_train) X_test_scaled = scaler.transform(X_test) # 3. context选择（这里用分层采样） from sklearn.model_selection import train_test_split as tts X_ctx, _, y_ctx, _ = tts( X_train_scaled, y_train, train_size=min(5000, len(X_train_scaled)), stratify=y_train, random_state=42 ) # 4. 模型推理 from tabpfn import TabPFNClassifier model = TabPFNClassifier(device='cuda', N_ensemble_configurations=8) model.fit(X_ctx, y_ctx) preds = model.predict_proba(X_test_scaled)[:, 1] # 5. 评估 from sklearn.metrics import roc_auc_score print(f"AUC: {roc_auc_score(y_test, preds):.4f}")

这个流程我跑过十几个数据集，稳定性不错。关键点是第3步的context选择，以及第4步的N_ensemble_configurations参数——这个参数控制模型做多少次集成，值越大越稳但越慢，8是个比较平衡的值。

5. 踩坑记录与常见问题排查

5.1 context里类别极度不平衡怎么办

这是最常见的问题。如果正样本只有几十个，分层采样也救不了，因为context里正样本太少，模型学不到正类的模式。我的做法是过采样正类，但不要用SMOTE那种合成方法（表格基础模型对合成样本不友好），而是直接复制正样本，让正负比例达到1:5左右。复制的时候加一点高斯噪声，避免完全重复。

def oversample_minority(X, y, target_ratio=0.2, noise_std=0.01): minority_idx = np.where(y == 1)[0] majority_idx = np.where(y == 0)[0] n_target = int(len(majority_idx) * target_ratio / (1 - target_ratio)) n_repeat = n_target // len(minority_idx) X_minority = X[minority_idx] y_minority = y[minority_idx] X_oversampled = np.repeat(X_minority, n_repeat, axis=0) y_oversampled = np.repeat(y_minority, n_repeat) noise = np.random.normal(0, noise_std, X_oversampled.shape) X_oversampled = X_oversampled + noise X_combined = np.vstack([X[majority_idx], X_oversampled]) y_combined = np.concatenate([y[majority_idx], y_oversampled]) return X_combined, y_combined

5.2 推理结果不稳定，每次跑都不一样

表格基础模型如果开了ensemble，每次结果会有微小差异，这是正常的。但如果差异很大（AUC波动超过2个点），说明context选择有问题。排查顺序：先固定随机种子，看是否还波动；如果还波动，检查context里是否有重复样本或者高度相似的样本，这些会让attention权重集中，导致不稳定；最后检查特征尺度，如果某些特征量纲差异巨大，attention会被大数值特征主导。

5.3 context太长导致OOM

这个前面提过，解决方案就是采样。但采样的时候要注意，不要简单截断。有些人图省事，直接取前N条，这是大忌，因为数据可能按时间排序，前N条只覆盖了早期分布。一定要随机采样或者分层采样。

5.4 常见问题速查表

5.5 几个容易被忽略的细节

特征顺序。表格基础模型对特征顺序不敏感（因为attention是置换不变的），但如果你做了特征选择，每次跑的特征子集不一样，结果会有差异。建议固定特征顺序。

context和测试集的分布一致性。如果测试集来自不同的时间段或者不同的数据源，分布可能和训练集有偏移。这时候相似度检索策略会比随机采样好很多，因为它能针对测试样本的分布去检索相关的训练样本。

模型版本。TabPFN v1和v2的context机制差别很大，v2支持更大的context和更好的缺失值处理。如果你还在用v1，建议升级。

6. 不同场景下的context选择建议

6.1 小样本场景（训练集<1000）

这种场景下不用纠结，全量喂进去就行。重点是数据质量，把标注错误的、异常的样本清理干净。小样本下每个样本的权重都很高，一个坏样本可能带偏整个预测。我一般会做一轮交叉验证，把那些在CV中预测 consistently 错误的样本挑出来人工检查。

6.2 中等规模场景（1000-10000）

这是最需要策略的场景。我的建议是：如果推理延迟不敏感，用相似度检索；如果延迟敏感，用分层采样+聚类分层的组合。context规模取5000左右，既能覆盖主要分布，又不会太慢。

6.3 大规模场景（>10000）

必须做采样。这时候相似度检索的计算成本会很高（每个测试样本都要和上万训练样本算距离），可以用近似最近邻（ANN）来加速，比如Faiss或者HNSW。或者退而求其次，用聚类分层，先把训练集聚成100个簇，每个簇抽50条，组成5000的context。

6.4 在线推理场景

在线场景对延迟要求高，context必须固定，不能每个请求都重新检索。做法是离线把context选好、缓存好，线上直接复用。如果数据分布会漂移，定期（比如每天）重新选一次context。

7. 我个人的几条实操心得

第一，不要迷信全量。我早期总觉得数据越多越好，后来发现对于表格基础模型，精选的5000条往往比随机的10000条效果好。信息密度比信息总量重要。

第二，相似度检索的编码方式很关键。我试过用原始特征做检索、用PCA降维后做检索、用自编码器编码后做检索，效果最好的是PCA降维到64维，简单且稳定。自编码器虽然理论上更强，但训练不稳定，容易过拟合。

第三，context规模扫描是必须的。不要拍脑袋定N，花半个小时跑个扫描，找到你数据上的最优N，这个投入产出比极高。

第四，保留一个baseline。不管你怎么选context，都要和XGBoost对比。如果表格基础模型没有明显优势，说明你的数据可能不适合这类模型，或者context选择还有优化空间。

第五，注意版本兼容性。TabPFN的API在不同版本间有变化，我遇到过升级后predict_proba的参数名变了导致代码报错的情况。锁定版本，或者写好兼容层。

这套东西我在实际项目里跑了小半年，从最开始的一头雾水到现在基本能稳定复现论文里的效果，中间踩的坑基本都写在这了。context选择没有银弹，核心还是理解你的数据，然后针对性地设计采样策略。