企业里的流失预测、购买意向判断和欺诈评分，过去通常意味着一套完整的机器学习工程：特征工程、模型训练、超参数调优、部署，以及随着数据变化不断重新训练。XGBoost、随机森林和深度神经网络都能解决问题，但这条链路对时间、基础设施和专业人员的要求并不低。
BigQuery 现已推出由 Google Research 开发的 TabFM。它是面向表格数据回归与分类任务的预训练基础模型，利用上下文学习（In-Context Learning，ICL）读取历史标注数据，并直接为新数据生成预测结果。开发者不再需要单独创建、部署和管理模型，可以通过内置 SQL 函数完成预测与评估。目前，TabFM on BigQuery 处于预览阶段。
一条 SQL 完成零样本预测
传统模型需要先拟合训练参数，TabFM 则把历史数据作为上下文示例传给模型。对于分类任务，目标列可以是布尔值或类别；对于回归任务，目标列通常是数值。BigQuery 会根据目标标签的数据类型推断任务类型，并自动处理缺失值、类别编码等特征化工作。
下面的示例将交易标记为欺诈或非欺诈。运行前，将项目、数据集和表名替换成自己的 BigQuery 资源，并确认历史表和预测表的字段结构兼容。
-- 使用历史交易作为上下文示例，预测新交易是否欺诈
SELECT *
FROM AI.PREDICT(
TABLE `my_project.my_dataset.historical_transactions`,
TABLE `my_project.my_dataset.new_transactions`,
label_col => 'is_fraud'
);
结果会保留预测表中的原始列，并增加预测标签和概率等字段，例如 predicted_is_fraud。这意味着下游分析、告警或业务规则可以直接消费查询结果，不需要等待模型导出和部署。
可以这样实践：先把最近一段时间的已标注数据放入历史表，再把待预测数据写入独立表。两张表的特征列应保持一致，预测表不需要包含目标列。
用 AI.EVALUATE 快速检查效果
免训练并不等于免评估。上线到营销、风控或客户运营流程前，仍然需要留出测试数据，确认模型是否满足业务要求。BigQuery 提供 AI.EVALUATE，可以直接在测试表上生成标准指标。
-- 评估客户生命周期价值预测效果
SELECT *
FROM AI.EVALUATE(
TABLE `my_project.my_dataset.historical_customer_ltv`,
TABLE `my_project.my_dataset.test_customer_ltv`,
label_col => 'ltv'
);
回归任务可以获得 r2_score、mean_absolute_error 等指标；分类任务则可以查看 precision、recall 和 f1 等指标。建议将这类评估查询纳入数据质量或发布流程，并按照时间切分测试集，避免把未来信息泄露到历史上下文中。
TabFM 的工作方式与规模边界
TabFM 的核心不是传统意义上的“训练一个新模型”。它使用上下文学习：模型读取历史表中的带标签样本，在一次前向推理中为目标表生成预测。BigQuery 会通过分布式、并行化推理处理计算和内存压力，并结合训练数据采样与分布式执行，让规模达到数百万行的推理表也能在较短时间内完成处理。
这种方式特别适合以下场景：
- 希望快速获得预测结果，但团队不想维护完整的机器学习训练流程。
- 历史数据规模处于小到中等范围。
- 业务数据变化频繁，需要经常更新预测依据。
- 需要在对话式应用或智能代理中按需执行预测。
- 预测任务已经位于 BigQuery 中，希望减少数据搬运和运行时基础设施。
TabFM 也不是所有场景的默认选择。历史数据非常庞大、特征数量超过当前限制、需要精细控制超参数，或者必须解释“每个特征对结果贡献了多少”时，XGBoost 等传统模型仍然更合适。TabFM 的摘要描述强调了准确率和易用性，但生产系统仍应通过自己的时间窗口、类别分布和业务成本函数进行验证。
接入智能代理的一个实践路径
如果业务代理已经通过 BigQuery MCP server 访问数据，可以把 TabFM 作为预测工具暴露给代理。一个典型流程是：代理识别用户意图，生成受控的预测查询，调用 AI.PREDICT，再根据预测概率触发人工审核、优惠推荐或风险提示。
可以先用参数化查询验证这个流程：
-- 预测待处理订单的风险，并限制返回字段
SELECT
order_id,
predicted_is_fraud,
predicted_is_fraud_probs
FROM AI.PREDICT(
TABLE `my_project.risk.historical_orders`,
TABLE `my_project.risk.pending_orders`,
label_col => 'is_fraud'
);
生产环境中应限制代理可访问的表和列，避免让自然语言请求直接生成任意 SQL；同时记录输入数据版本、预测时间、模型返回结果和人工处置结果。这样才能在预览能力变化或数据分布改变时定位问题。
落地前检查清单
TabFM 把表格预测的入口压缩成了 SQL，但数据治理和效果验证仍然不可省略。采用前可以检查：
- 历史标签是否可靠，且与预测时点保持一致。
- 训练上下文与预测表是否存在字段类型、缺失值和类别分布差异。
- 是否准备了独立测试集，以及适合业务的 precision、recall、MAE 等指标。
- 预测延迟和查询成本是否满足批处理或在线业务要求。
- 是否真的需要特征重要性、定制调参或超大规模历史数据。
- 预览阶段的接口、配额和能力是否已纳入上线风险评估。
TabFM 的价值在于降低了从数据到预测的工程门槛：当预测任务规模适中、数据变化快、结果需要被分析师或智能代理即时调用时，AI.PREDICT 和 AI.EVALUATE 可以成为很短的验证路径。对于需要长期稳定运行、深度调优和强解释性的核心模型，则应继续保留传统机器学习方案，并让两者按场景协作。