别再为特征工程烧钱了：XGBoost不是问题，喂它的方式才是

作者：老余捞鱼

原创不易，转载请标明出处及原作者。

写在前面的话：作为量化团队负责人，我亲眼见过团队为特征工程烧掉300万预算。传统方法让70%成本花在数据准备上，而非模型本身。关系型基础模型直接读取数据库结构，让数据工程师转型为模式设计师，成本降低三分之二，效率提升五倍。这是AI的真正变革。

本文约 2700 字 | 阅读预计需8分钟，建议先收藏

第一部分：我们曾经崇拜的”神”

○ 竞赛冠军不等于生产能手

2017年，我带队参加一个金融风控竞赛。我们用XGBoost拿了第二，奖金50万。那时候觉得，这就是未来。我开始帮朋友公司用同样的方法做实际业务。

现实打脸：竞赛数据是别人喂到嘴边的精致料理。干净整洁的CSV文件，每个特征都精心设计过。而企业的数据呢？是散落在十几个数据库里的生猛海鲜，你得自己捕捞、清洗、烹饪。

在朋友的电商公司，有用户表、订单表、商品表、行为日志表、客服工单表……这些表通过外键关联，形成一个复杂的网络。但XGBoost只能吃二维表格，于是我们开始了漫长的”数据扁平化”工程。

左图：整洁的关系型数据库结构 | 右图：混乱的SQL连接和Airflow DAG管道

数据扁平化流程是这样的：

• 第一步：确定要预测什么。比如用户会不会流失。
• 第二步：找数据。用户画像、历史订单、浏览记录、客服记录……分布在8个不同的数据库里。
• 第三步：写SQL。大量的SQL。把8个表连起来，计算各种统计量：平均购买金额、最大间隔天数、事件总数……
• 第四步：建管道。用Airflow调度，每晚跑一次，把结果存到Redis特征存储。
• 第五步：维护。上游数据库改个字段，我们的管道就崩了。业务要加个新特征，数据工程师忙两周。

数据不说谎：我们做过统计，团队70%的时间花在数据工程上，只有30%在真正的模型优化。每100万AI预算，70万给了数据工程师，30万给了算法工程师。这合理吗？

○ 平台期来得比想象中快

2022年，我发现了问题：做个团队从5人扩到12人，基础设施越来越复杂，但模型效果提升微乎其微。

CTO问我：”为什么我们要花300万养一个团队，就为了维护一个别人周末就能写出来的模型？”

我答不上来。因为问题不在模型，而在喂模型的方式。我们在强迫关系型数据变成二维表格，这个过程本身就在破坏信息。

第二部分：信息去哪了？

○ 那个被平均值”杀掉”的用户

让我讲个真实案例。用户A和用户B，他们的月平均购买金额都是2000元。

看到问题了吗？在平均值这个特征里，用户A和用户B看起来一模一样。但他们的行为模式天差地别。一个会持续贡献价值，一个可能已经流失。

左：丰富的序列信号 | 中：均值聚合 | 右：方差为零的扁平特征向量

当我们用AVG()、MAX()、COUNT()这些聚合函数时，这不是在总结数据，而在破坏数据。时间序列信息、购买爆发模式、用户行为节奏……全都没了。

○ 更深的损失：关系看不见了

还有更糟的。用户C和用户D都有10个客服工单。

— 传统方法只能看到这些 用户C：客服工单数 = 10 用户D：客服工单数 = 10 — 但看不到这些 用户C：10个工单都关于同一个商品（质量问题） 用户D：10个工单分散在10个不同商品（使用困惑）

在数据库里，客服工单表通过外键同时关联用户表和商品表。这个”三角关系”包含重要信息：用户C可能遇到了有质量问题的商品，用户D可能只是不太会用我们的产品。

但XGBoost看不到这个三角关系。它只能看到”客服工单数=10″这个孤立的数字。

第三部分：换个思路，海阔天空

○ 不扁平化，直接理解

2024年，我们开始尝试关系型基础模型。核心思想很简单：不把数据压扁，让模型直接理解数据的原始结构。

关键突破：在关系型数据库中，表是节点，外键是边。整个数据库就是一个图。为什么不让AI直接读这个图呢？

具体做法：

• 不写SQL：直接把数据库连接给模型。
• 不建特征：告诉模型”用户表、订单表、行为表是相关的”。
• 不搞管道：模型实时读取最新数据。
• 不存中间结果：每次预测都基于原始数据重新计算。

○ 外键变成”注意力”

技术实现上，这用了图神经网络加Transformer的混合架构。

简单说：当模型要理解一个用户时，它不会看所有用户。它会通过外键关系，找到这个用户的所有订单，再看每个订单的所有行为记录。就像一个人理解朋友时，会想到他做过的事、说过的话、买过的东西。

外键关系决定哪些实体可以相互”关注”，保留完整的结构信息

○ 时间序列不爆炸

一个用户可能有上万条行为记录，用传统Transformer处理会计算量爆炸。关系型基础模型用状态空间模型（比如Mamba）来解决。

原理：不是记住每一笔交易，而是维持一个”状态”，随着新交易更新这个状态。就像你不是记住朋友说过的每一句话，而是对他有个整体印象，这个印象随着新互动而更新。

第四部分：实战效果

○ 我们的5000亿行数据实验

我们在真实的金融交易数据上做了对比测试，涉及5000亿行记录。

成本对比：惊掉下巴

图4：XGBoost特征工程栈 vs 关系型基础模型管道的真实成本对比

XGBoost模型推理便宜，但周边基础设施（特征存储、数据管道、重训练、ML工程师薪资）使总成本高出3倍。

财务总监笑了：很多人以为神经网络推理贵，但算总账时，关系型方案反而便宜三分之二。因为省掉了整个特征工程流水线。

○ 效果对比：意外之喜

我们最担心的效果下降并没有发生：

• 零样本性能：新模型不用特征工程，直接达到老模型85%的效果。
• 微调后：简单调整后，效果反超老模型15%。
• 实时性：新数据秒级生效，不用等夜间跑批。
• 稳定性：上游数据库改字段，模型自适应，管道不崩了。

○ 团队转型：从苦力到设计师

最大的变化是团队角色：

数据工程师小李：“以前我70%时间在写SQL修bug，现在我在设计数据模式。怎么设计表结构能让AI理解得更好？怎么建立外键关系能传递更多信息？这工作有意思多了。”

算法工程师小王：“以前我纠结特征怎么设计，现在我在想怎么让模型更好地理解业务关系。从特征工程师变成了模式设计师。”

第五部分：实话实说

○ XGBoost还能用吗？

当然能用。在三种情况下，XGBoost还是首选：

• 数据本来就很平：如果就是一个CSV文件，没多少关系结构。
• 数据量很小：就几万行，没必要上大模型。
• 解释性要求高：要给老板看”为什么这么预测”，XGBoost的特征重要性更直观。

○ 转变已经发生

这不是未来时，是进行时。RelationalAI等公司已经在提供商业服务，RelBench等开源框架让实验成本大大降低。

老余的建议：如果你团队有3个以上数据工程师，每年AI预算超过200万，还在为特征工程头疼，现在就该开始了解关系型基础模型了。不用马上全换，可以先在一个项目上试点。

观点总结

我们花了十年时间，假装企业数据是二维表格。为此建了庞大的基础设施，养了庞大的团队，花了庞大的预算。

关系型基础模型让我们停止这个假装。数据本来就是关系网络，那就让它保持关系网络。让AI直接理解这个网络，而不是通过我们笨拙的翻译。

这不是技术的微调，是思维的重置。从"怎么把数据喂给模型"到"怎么让模型理解数据"，这是企业AI从青春期到成年的标志。

关键词： #企业AI实战 #关系型基础模型 #XGBoost对比 #机器学习成本 #数据工程优化 #量化投资 #AI降本增效 #团队转型 #技术变革 #业务价值 #智能决策 #数字化转型

本文基于真实项目经验，数据已做脱敏处理。技术细节有简化，但核心结论经得起验证。

关注”老余捞鱼”，看AI如何真实创造业务价值