简介：在机器学习与数据挖掘领域，回归预测任务常常面临数据分布长尾、特征维度复杂、时序依赖明显等挑战。面对这类工程问题，构建稳定的Baseline和大规模的用户特征体系，往往比单纯堆叠模型更为高效。以新浪微博互动预测为例，其核心是对转发、评论、点赞这类互动指标进行回归建模，而效果的关键则在于对用户历史行为、发布时段和内容属性的深度挖掘。通过特征工程中的用户分位数统计、时序安全处理，以及LightGBM与XGBoost的加权融合策略，可在MAE指标上获得稳定提升。该方案的实践路径，也为参与天池等大数据竞赛的选手提供了一条可复现的通用技术路线，帮助理解从数据处理到模型优化的工程闭环。 做了多年的数据挖掘，天池竞赛也跟过几场。这次要聊的是“新浪微博互动预测大赛”第一赛季的参赛源码。这套代码是我完整跑通过、能直接复现到本地的一份参赛方案，不是那种只有骨架的空仓库。我会把赛题拆解、特征工程、模型选型、调参思路、融合方式和代码目录结构全部串起来讲清楚。适合两类人看：一类是想入门天池这类大数据竞赛、想找一个完整baseline起步的选手；另一类是已经在做比赛但卡在特征工程或提分阶段，想看看别人怎么设计用户历史特征和时序窗口的。
先交代一下赛题背景。新浪微博互动预测，预测的是某条微博在发布后一段时间内获得的转发量、评论量和点赞量。数据来自新浪微博真实业务，训练集给的是历史微博的发布信息和对应的互动结果，测试集给的是新一批微博的发布信息，要预测它们的互动量。本质是一个典型的表格型回归问题，特征设计空间很大，模型层面主流就是GBDT系。第一赛季的排名竞争主要集中在特征工程、时序处理和模型融合这三个环节。
1. 赛题定义与数据结构的还原
很多人拿到一个比赛，第一反应是赶紧跑一个demo看分数。这个习惯不差，但我建议先花半天把赛题定义、数据字段和评估指标吃透。方向不对，后面跑得再快也是白费。
1.1 这场比赛到底在预测什么
赛题名称里写的是“互动预测”，具体预测对象是三件事：转发数、评论数、点赞数。从建模角度，这就是一个多目标回归任务，三个目标之间相关性很高，但分布差异也比较明显。点赞数通常远高于转发和评论，转发和评论在内容属性上更接近。
一个容易忽略的点是目标的数值分布。微博互动数据是典型的长尾分布：绝大多数微博互动量很低，可能只有个位数或者两位数，少数头部微博能达到成千上万。如果直接用原始数值做回归，模型会被少数大值样本牵着走。我的做法是对目标做对数变换，即预测log(互动量 + 1)，提交前再指数还原。加 1 是为了处理互动量为 0 的样本。
更细一点的做法是把问题拆成两阶段。第一阶段的模型判断“这条微博会不会有互动”（二分类，阈值可以根据训练集分布调），第二阶段只对互动量大于 0 的样本做回归。这样能捕捉到“从 0 到 1”和“从 1 到 1000”两类完全不同的信息模式。很多公开方案都走了这个路子，实测能拿到稳定的提升。
1.2 赛题数据长什么样
根据天池公开的数据说明和参赛过程中整理的字段信息，训练数据大概包含以下字段。
| 字段 | 含义 | 类型 |
|---|---|---|
| id | 微博唯一标识 | 字符串 |
| uid | 发布者用户ID | 字符串 |
| post_time | 发布时间 | 时间戳 |
| content | 微博正文 | 文本 |
| url_num | 正文中包含的URL链接数 | 整数 |
| pic_num | 正文中包含的图片数 | 整数 |
| video | 是否包含视频 | 0/1 |
| is_original | 是否原创 | 0/1 |
| retweet_num | 转发数 | 整数（训练集） |
| comment_num | 评论数 | 整数（训练集） |
| like_num | 点赞数 | 整数（训练集） |
特别要注意的是时间维度。训练集和测试集不是同时间段的随机抽样，而是按时间顺序切分的。也就是说，测试集里的微博发布时间普遍晚于训练集。这个特性决定了我们不能简单地把训练集整体作为统计背景来做特征，而要做时序安全的特征工程。
第一赛季数据量大概在几十万条量级，不算大。单机内存就能轻松跑起来，处理成特征表之后用 LightGBM 训练一轮也就几分钟的事。这种体量下，特征工程的上限远高于模型复杂度，深度学习方法在这里并没有明显优势，反而容易过拟合。
1.3 评估指标决定了你的策略
这场比赛第一赛季的评估指标以平均绝对误差（MAE）为核心的回归指标，三个目标分别计算后再进行加权汇总。具体权重在不同赛季可能微调，但整体逻辑一致：预测值与真实值的绝对差距越小越好。
这个指标有个容易被忽略的后果。MAE 对中位数附近的误差不敏感，但对少量高互动微博的预测偏差却会放大绝对值。因为高互动微博的真实值可能是几百上千，一旦预测偏差巨大，MAE 会被拉得很惨。所以策略上不能只追求“大多数预测准”，还要尽量稳住头部样本。
这就引出两个操作：第一，高互动样本在特征工程阶段要给予足够关注，比如用户历史最高互动量的信息不能丢；第二，融合阶段对高互动区间可以做一些修正，比如对数空间下的误差权重调整。总之，指标决定了特征设计和后处理的方向，先看懂评估方式永远比盲目调参重要。
2. 特征工程：从原始字段到信息密度最高的特征集
特征工程是这场比赛的核心，也是“下载即用”源码里最值得看的部分。下面的内容按特征分组展开，每一类特征背后都有我对业务的理解和实测验证。
2.1 时间特征：互动量随发布时段呈现的强规律
微博互动和用户的活跃时段强相关。晚上 8 点到 10 点是用户刷微博的高峰期，这个时段发布的微博天然有更高的曝光和互动概率。凌晨发布的微博互动量通常偏低，但也有例外，比如凌晨发布的深度内容可能在次日早晨迎来阅读高峰。
我构造的时间特征包括：
- 发布小时（0-23）
- 发布星期几（0-6）
- 是否周末
- 是否工作日早晚高峰（早 7-9 点、晚 18-21 点）
- 发布时间到当天 0 点的分钟数
- 该用户历史上习惯发布的时段（例如用户历史平均发布小时）
这些特征里，最有效的是发布小时和是否周末。用户历史平均发布小时能反映作者的内容类型，比如一个长期深夜发博的用户，其粉丝活跃时段也可能偏晚，模型可以从中学到这种个性化规律。
时间特征属于强业务先验类特征，几乎不需要额外成本，但能带来稳定的上分效果。在交叉验证里我会单独观察加了时间特征后的 MAE 变化，这部分大约能带来 1%-2% 的提升。
2.2 用户历史特征：发布者影响力是最直接的信号
互动预测任务里，用户是比单条内容更强的信号源。一个千万粉丝的大V发布一条无内容图片，互动量也可能轻松破千；一个素人用户发布一条精心撰写的长文，互动量也很可能只有两位数。所以用户历史表现是最重要的特征组。
我在源码里构造的用户历史特征分三层：
第一层是基础统计。以每条微博的发布者为单位，统计该用户在训练集中所有历史微博的平均转发数、平均评论数、平均点赞数、互动总数、发布微博数量、活跃天数等。
第二层是分位数和极值统计。只看均值会丢失分布信息，比如某用户大部分微博低互动，但偶尔有几条爆款，这种情况下均值偏低但极值很高。因此我加了用户历史转发数的 25%、50%、75% 分位数、最大值、标准差等特征。
第三层是时间衰减统计。距离当前微博越近的历史行为参考价值越大，所以我对用户历史特征做时间衰减加权，权重随历史时间跨度指数衰减。这是一个比较细节的处理，但对模型的效果改善是肉眼可见的。
需要注意的是，用户历史特征不能直接使用全部训练集的统计值。比如要预测测试集的某条微博，只能使用该用户在该微博发布时间之前的历史数据。这个点做到位之后，模型分数会有一次比较明显的跳变。
提示：用户历史特征是整个特征工程里信息密度最高的一层。如果只能保留一组特征，我会优先保留这一组。它的作用不是锦上添花，而是直接决定模型的下限。
2.3 文本与内容特征：从正文里抠信息
微博正文是官方提供的最丰富的原始信息源。互动量差异很多时候来自内容本身，所以文本特征不能忽略。但考虑到参赛代码的可复现性和第一赛季的体量，我没有上特别重的深度模型，而是用了一套性价比很高的文本特征组合。
第一是文本物理特征。正文长度、包含的汉字数、@用户数量、#话题#数量、URL链接数、图片数、是否包含视频、是否原创。这些特征直接计算即可，反映的是内容的丰富程度和形式。
第二是关键词特征。统计训练集中高频出现的话题词和热词，构造是否包含特定关键词的识别结果。比如“抽奖”、“福利”、“转发抽奖”这类词对转发量的拉动作用非常明显，出现这些词时互动量通常会显著提升。
第三是情感和主题层面的轻度特征。用情感词典对正文做情感得分计算，结合文本长度生成“情感强度”等衍生特征。更复杂的LDA主题模型、Word2Vec向量、BERT向量在这个赛题里也可以用，但它们在百万级以下表格数据上的边际收益不如传统特征，且上线成本高，所以我的源码里只保留了基础文本特征和TF-IDF降维后的少量成分。
2.4 交叉特征与二次提炼：把单维特征组合出增量
单维度特征构造完以后，很多信息仍然藏在特征与特征的交互里。我常用的交叉方式有三类：
- 用户历史平均互动量 与 发布小时 的交叉：不同量级用户在不同时段的互动模式不一样，大V在深夜发广告可能依然高互动，素人深夜发内容可能无人问津。
- 用户历史发布频率 与 文本长度 的交叉：高频段子手发短文本是常态场景，低频用户发长文往往是深度内容，两类内容的互动规律差异很大。
- 图片数 与 文本是否含话题分享 的交叉：图文搭配的内容往往比纯图片或纯文本更容易引发讨论。
这些交叉特征的实现很简单，本质就是两个或三个字段的笛卡尔组合，但在模型里的作用却很大。GBDT 类模型虽然自带一定程度的分裂学习能力，但对高阶交叉信息的学习不如显式构造来得充分，尤其是在数据量有限的情况下。
需要提醒的是，特征不是越多越好。我在第一赛季时曾经把特征堆到 150 多列，结果线上分数比 90 列时还差了一点，原因是个别噪音特征带来了负迁移。更合理的做法是先加一批特征，跑一个 baseline，观察模型特征重要性和验证集指标，再决定是否保留。
3. 模型选型、调参与融合的最优组合
特征工程的产出是一张规范的特征表。接下来就是在模型层面把它榨干。第一赛季的主流方案基本是 GBDT 系模型，原因很简单：表格型数据、中等数据规模、存在大量类别和数值混合特征，GBDT 的适应能力和调参成本都最友好。
3.1 为什么主模型选 LightGBM
XGBoost、LightGBM、CatBoost 三个模型我都做过横向对比。XGBoost 稳定但训练速度慢；CatBoost 对类别特征处理效果好但内存占用大；LightGBM 在训练速度和内存占用上有明显优势，且直方图算法对这类中等数据规模的任务非常高效。
第一赛季的数据规模下，我的体验是 LightGBM 的默认参数已经能跑出不错的分数，XGBoost 需要更细致的参数调整，CatBoost 在这个场景下没有体现出对类别特征的额外优势，而时间戳、用户ID这类高基数类别特征本身也不是 CatBoost 的强项。
| 模型 | 优点 | 缺点 | 第一赛季实测效果 |
|---|---|---|---|
| LightGBM | 训练快、内存小、参数少 | 对过拟合更敏感 | 主模型，效果最佳 |
| XGBoost | 稳定、可控性强 | 训练较慢、调参成本高 | 辅助模型，用于融合 |
| CatBoost | 类别特征天然支持 | 内存占用大、训练慢 | 效果相近，耗时高 |
3.2 参数配置里直接影响得分的几个旋钮
模型参数很多，但真正影响第一赛季分数的就那几个。我在源码里给出的 LightGBM 参数配置大致如下。
import lightgbm as lgb params = { "objective": "regression", "metric": "mae", "learning_rate": 0.02, "num_leaves": 96, "max_depth": 8, "min_data_in_leaf": 40, "feature_fraction": 0.8, "bagging_fraction": 0.8, "bagging_freq": 1, "lambda_l1": 0.5, "lambda_l2": 1.0, "verbose": -1, "seed": 42, } d_train = lgb.Dataset(X_train, y_train) d_valid = lgb.Dataset(X_valid, y_valid) model = lgb.train( params, d_train, num_boost_round=5000, valid_sets=d_valid, callbacks=[lgb.early_stopping(100), lgb.log_evaluation(200)], )几个关键参数的意图说明一下。
learning_rate设为 0.02 是为了配合早停获得更多迭代次数，这个组合在多数表格竞赛里都稳。num_leaves控制模型复杂度，从默认的 31 调到 96 后，模型对特征交互的学习能力更强，但要注意配合min_data_in_leaf避免过拟合。feature_fraction和bagging_fraction是两种正则化手段，一个控制特征采样，一个控制样本采样，分别都设为 0.8 能有效降低方差。lambda_l1和lambda_l2是防止过拟合的补充手段。
三个目标（转发、评论、点赞）虽然相关，但分布和波动性不同。我在源码里确实是为每个目标单独训练了一个模型，没有共享参数。实际效果比一个模型同时预测三个目标要好。原因在于三个目标的分布形态存在差异，比如点赞数的量级普遍大于评论数，合训会强制模型在同一个结构上平衡两者，导致精度下降。
3.3 模型融合：单模上分难，融合是直接手段
单模到了后期提分空间很小，融合几乎是必然选择。我在源码里采用了“多折交叉验证 + 多模型加权平均”的方案，步骤如下：
- 对训练集做 5 折切分，每折独立训练 LightGBM 模型，得到验证集上的 5 份预测。
- 同样的数据，训练 XGBoost 模型，得到另一组验证集预测。
- 针对三个目标分别求验证集上的最优线性权重，可以通过简单的网格搜索或 scipy 的优化函数实现。
- 用找到的最优权重对测试集预测做加权平均。
关于 Stacking，我的态度比较谨慎。Stacking 在数据量很大的情况下效果不错，但在几十万条数据的场景里，第二层模型很容易在验证集上过拟合，尤其是当第一层模型之间的相关性较高时。第一赛季我更推荐简单加权平均，它更稳定，也更容易解释。
# 加权融合示意 # valid_pred_lgb 和 valid_pred_xgb 是验证集上的预测结果 best_w = 0.6 blend_pred = best_w * valid_pred_lgb + (1 - best_w) * valid_pred_xgb线上实测最优权重在 0.6 到 0.7 之间，说明 LightGBM 在这个任务上确实比 XGBoost 强一些。融合带来的提升不会特别夸张，但在冲排名阶段，0.5% 的提升可能就决定了能否进入下一轮。
4. 源码目录逐层拆解与本地复现指南
标题里说“下载即用”，那我得把这套源码的可执行性说清楚。先讲目录结构，再讲运行流程，最后讲环境和常见报错。
4.1 仓库结构总览
weibo-interaction-prediction/ ├── data/ │ ├── raw/ # 官方提供的原始数据 │ ├── processed/ # 清洗和特征工程后的中间数据 │ └── submit/ # 最终提交文件输出目录 ├── features/ │ ├── build_time_feat.py # 时间特征 │ ├── build_user_feat.py # 用户历史特征 │ ├── build_content_feat.py # 文本与内容特征 │ └── build_cross_feat.py # 交叉特征 ├── models/ │ ├── train_lgb.py # LightGBM 训练 │ ├── train_xgb.py # XGBoost 训练 │ └── infer.py # 预测与输出 ├── ensemble/ │ └── blend.py # 加权融合 ├── utils/ │ ├── config.py # 路径与参数配置 │ └── logger.py # 日志模块 ├── run_all.sh # 一键跑完全流程 └── README.md这个结构是典型的竞赛项目布局。features目录下每个脚本对应一类特征，模块化程度高，后添加特征时不会影响已有逻辑。models目录下的训练脚本和推理脚本分离，训练完成后会保存模型文件供推理阶段调用。
4.2 从原始数据到提交结果：五步流水线
整体执行顺序和产物如下。
| 步骤 | 对应脚本 | 输入 | 输出 | 预计耗时 |
|---|---|---|---|---|
| 1. 特征工程 | build_time_feat.py / build_user_feat.py / build_content_feat.py / build_cross_feat.py | 原始 CSV | processed/train_feat.csv / test_feat.csv | 20-40 分钟 |
| 2. 单目标训练 | train_lgb.py | 训练特征表 | models/lgb_model.sav | 10 分钟 |
| 3. 辅助模型训练 | train_xgb.py | 训练特征表 | models/xgb_model.sav | 20 分钟 |
| 4. 单模推理 | infer.py | 测试特征表 + 模型文件 | submit/lgb_submit.csv / xgb_submit.csv | 5 分钟 |
| 5. 融合输出 | blend.py | 两份提交文件 | submit/final_submit.csv | 1 分钟 |
运行run_all.sh会按顺序执行上述所有脚本。需要注意的一点是，特征工程生成的中间文件会占用一定磁盘空间，几十万条数据大概会产生几百兆的中间结果，部署到云服务器或本地时提前预留空间。
4.3 环境配置与常见报错
源码基于 Python 3.7-3.9 开发，核心依赖如下：
- pandas >= 1.2
- numpy >= 1.20
- lightgbm >= 3.3
- xgboost >= 1.5
- scikit-learn >= 1.0
- scipy >= 1.6
直接通过requirements.txt安装即可。环境上遇到的常见问题有两个。
第一个是FileNotFoundError。很多第一次跑的人把数据文件放在了错误的路径下，或者改了目录结构。这个问题的根源是utils/config.py中的路径配置使用了相对路径，而执行脚本时的当前工作目录与脚本所在目录不一致。解决方法是统一在项目根目录下执行bash run_all.sh，或者把config.py里的相对路径改成绝对路径。
第二个是内存溢出。几十万数据 + 几百列特征在特征工程阶段会生成较大的中间 DataFrame，如果机器内存小于 8GB，部分步骤可能报错。建议在特征工程阶段及时释放中间变量，或者在pandas读取时指定dtype减少内存占用。我在源码里已经对这些做了处理，但如果自己加了特征，还是要注意内存控制。
第三类问题是版本兼容。lightgbm在 4.0 之后对部分回调函数接口做了调整，如果使用最新版本跑旧代码，可能报lgb.early_stopping相关错误。我的建议是直接安装 3.3.x 版本，最稳妥。
5. 第一赛季参赛复盘：踩过的坑和提分最快的操作
代码逻辑讲完之后，聊点只有参赛过程里才会知道的事情。第一赛季给我最大的体会是：想拿高分，技术的“硬实力”只占一半，另一半是时间管理、代码管理和试错效率。
5.1 复盘：提分最快的三次操作
我把自己第一赛季的提分路径整理成了一张表格，每项操作的具体提升幅度只是参考值，不同赛季可能不同，但它能反映特征工程的重心分布。
| 操作 | 验证集 MAE 变化 | 说明 |
|---|---|---|
| 添加用户历史基础统计特征 | 降低约 3%-5% | 从零到一，效果最猛 |
| 修正时间窗口避免数据泄漏 | 降低约 2% | 数据泄漏会让模型虚高，修正后实际的泛化效果提升 |
| 对数变换 + 多目标分模型 | 降低约 1%-2% | 解决长尾分布和不同目标分布差异问题 |
如果是第一次参赛，我建议先快速拿一个基础逻辑的 baseline，然后立刻把主力精力放在用户历史特征和数据清洗上，这部分提分速度最快。模型调参和融合应该放到后面，不要一开始就陷入调参的泥潭。
5.2 数据泄漏的典型场景：很多人都栽在这里
数据泄漏是时间序列类比赛中容错率极低的问题。我在第一赛季就踩过一次。
当时的做法是计算全量训练集中每个用户的历史平均互动量作为特征，训练集内部表现非常好，验证集也不错，但提交到线上就发现分数不对。原因是在计算某条微博的特征时，用到了该微博发布时间之后才产生的数据，相当于模型“偷看”了未来。
正确做法是：对每一条要预测的微博，统计其特征时，只使用该用户在该微博发布时间之前的样本。实现上要按时间顺序构造特征，不能简单地按用户分组聚合。我在算用户历史特征时严格按post_time排序，用前 N 条微博的数据做统计，这样才保证时序安全。
另一个隐蔽泄漏是文本层面的。假设某条爆款微博的内容本身带有“年终总结”关键词，如果把这个关键词纳入全局统计，因为测试集和训练集是时间切分的，关键词整体频率分布会有差异。处理方式是从特征统计角度避免使用全量数据的全局统计值，尽量使用滑动窗口内的统计值。
5.3 提交节奏与代码管理的建议
天池的赛制通常允许每天多次提交，但线上评测次数有限制。最忌讳的是做一次试一个提交，不带方向地乱试。我一般会固定一个每天节奏：上午做特征或模型的假设并实现，下午跑交叉验证，晚上选一次最有信心的提交上线上评测。每隔两三天做一次完整 batch 提交对比，摸清各特征版本之间的相对优劣。
代码管理方面，我建议从第一天就养成版本管理的习惯。每做一次有效变更，就把代码和结果记录下来，特征文件命名里带上版本号或日期。否则到赛季末，模型文件几十个，特征文件几十份，根本分不清哪份对应哪份。这个习惯不只在比赛里有用，在真实业务里也一样重要。
5.4 这套源码在比赛结束之后的延伸价值
第一赛季结束后，这套源码的价值并没有归零。我后来用它的特征工程思路复盘过其他比赛，也帮朋友跑过天池的新赛季报名，结论是一致的：特征工程的通用思路是共通的，用户历史统计、时间窗口切分、目标分布处理这三板斧，几乎可以迁移到任何用户行为预测类任务。
另外，这份参赛代码也是一块很好的“面试素材”。面试最后问项目经历时，你可以把从零搭建特征管线、规避数据泄漏、调整模型融合权重的完整过程讲清楚，这比简单背几个算法概念要扎实得多。我见过不少候选人在算法原理上层层过关，但一问到数据泄漏和特征构造，就露馅了。真正跑过一场完整比赛的人，对这些问题的回答是完全不同的。
比赛本身的胜负只是很短一段时间的事情。我更看重的是把一套代码拆开、跑通、理解每个模块存在的意义。希望这份“下载即用”的参赛源码，能成为你理解大数据竞赛的一个起点，而不是一个终点。
本文还有配套的精品资源，点击获取
