简介：一份学术论文资源，聚焦机器学习增强的电子商务平台用户行为预测，发表于2019年，刊于《科技与创新》期刊。该文面向电商数据分析、推荐系统及人工智能方向的研究者，可作为技术调研与论文写作的参考文献。内容围绕用户购买行为预测，系统阐述了数据挖掘、深度学习、统计学的融合应用；针对传统Logistic回归、Bagging和随机森林等方法在非线性特征处理上的局限，提出基于深度学习的消费者行为分析方案，采用卷积神经网络（CNN）与循环神经网络（RNN）相结合的基本框架，并详细介绍了数据清洗、特征构建、模型训练、超参数调整与验证等流程，有助于读者理解从海量用户行为数据到实时预测的技术链路。压缩包内为1个PDF文件，大小约1.35MB，论文结构完整。该资源已有一百二十人学习下载，适合希望快速掌握机器学习增强电商行为预测技术思路的专业人群。
1. 机器学习增强的电子商务平台用户行为预测：先把“预测什么”定义清楚，再谈模型
很多团队拿到电商行为数据，第一反应是“上个深度学习模型”，结果在第一个月就被三个问题同时卡住：标签口径错了一个月、训练集和线上数据时间分布对不上、模型输出的分数没人敢接。机器学习增强的电子商务平台用户行为预测，核心不是把算法换得多高级，而是把浏览、加购、收藏这些行为日志翻译成能学习的样本，再用一个可解释的模型输出用户购买概率，接进优惠券、推荐、流失召回这些场景。我按实际项目的完整链路拆成六段，覆盖数据准备、特征工程、模型选型、评估采样和上线避坑，适合电商数据产品、增长算法，以及想找一条完整落地路径的机器学习入门者。
2. 从埋点到训练集：先把“用户行为”翻译成机器学习能吃的样本
电商数据团队最容易翻车的地方不在模型，而在样本构造。原始埋点日志长什么样，决定了你能做什么样的预测。一份典型的电商行为事件表，字段大致如下：
| 字段 | 示例 | 说明 |
|---|---|---|
| user_id / cookie_id | U12345 / C8888 | 登录用户ID或匿名设备ID |
| item_id | SKU100233 | 被浏览/加购的商品 |
| behavior | view / cart / purchase / favorite / search | 行为类型 |
| event_ts | 2024-12-01 20:13:45 | 事件发生时间，精确到秒 |
| session_id | S778812 | 一次会话的ID |
| scene | home / search / detail / cart | 行为发生的页面场景 |
| channel | app / mini_program / h5 | 流量渠道 |
拿到这张表，你要做的第一件事不是写模型，而是回答三个问题：样本的“用户”是谁？样本的“标签”是什么？样本的时间窗口怎么切。这三个问题没定清楚，后面所有特征和AUC都是空中楼阁。
2.1 行为事件与session边界：先确认你手里的日志里“用户”是谁
埋点日志里的“用户”不是人，而是user_id与cookie_id的混合体。同一个真人，在未登录状态下浏览商品是一个cookie，登录后下单是另一个cookie；同一台设备被家人共用时，一个cookie下又会混着多个真人的行为。做行为预测前，我一般会先做一次身份归一：以登录user_id为主体键，匿名cookie行为能关联就关联、不能关联就单独作为一条匿名样本。
session边界同样容易被忽略。常见做法是以“30分钟无新行为”作为session结束点，把连续点击切成一串有序行为。session的价值在于保留行为顺序：同样是加购，A用户加购后立刻去结算，B用户加购后反复浏览竞品页，这两个人下一个session的行为差异很大。如果你只用汇总计数特征，这种差异会被抹掉。所以我在特征清单里一定会保留“该session内从加购到下单的间隔”“有没有跨session回访”这种顺序类特征。
还有一类脏数据要先清掉：内部测试账号、爬虫、刷单脚本。一般维护一张test_accounts黑名单，在样本构造时直接排除，否则你会在“高活跃用户”里混进大量非真人流量，模型学出来的规则会偏到“经常凌晨批量访问某个SKU的用户是高意向用户”，这在电商场景里大概率是机器行为。
2.2 三个候选预测目标：点击、加购、购买，样本结构完全不同
“用户行为预测”听起来是一个任务，实际落到指标上要明确到“预测什么行为、在什么时间窗口内发生”。我通常会在三个目标里选一个：
| 预测目标 | 常见正样本率 | 标签窗口 | 业务用途 |
|---|---|---|---|
| 次日是否购买 | 约1%~3% | 24小时 | 优惠券发放、Push召回、客服触达 |
| 7日内是否加购 | 约5%~15% | 7天 | 推荐粗排、购物车提醒 |
| 是否流失 | 因定义而异 | 14~30天 | 会员运营、短信召回 |
上面的比例是我在不同电商项目里的经验值，不是标准答案，你的DAU和品类结构不同，正样本率会明显变化。选择哪个目标，取决于业务动作：发优惠券这种低成本动作可以选次日购买；推荐排序这种要覆盖大多数流量的场景，选点击或加购更合适；做会员召回才需要考虑流失定义。
标签窗口的选择也要谨慎。很多团队一上来就预测“未来7天是否购买”，看起来样本量更大，但标签窗口拉长之后，“今天买还是六天后买”搅在一起，模型对近期意图的敏感度会下降。做日常运营干预，我优先用24小时标签；做复购周期长的品类，才放到7天甚至30天。
2.3 构造训练集：特征窗口在前，标签窗口在后，中间必须断开
样本构造的核心原则只有一句话：特征只用过去的信息，标签只用未来的信息。具体到SQL，特征取自[特征日-7天, 特征日)这个半开区间，标签取自[特征日, 特征日+1天)这个半开区间，两个窗口背靠背但不交叉。下面是我常用的Hive风格SQL骨架：
WITH user_day AS ( -- 每个用户每个有行为的日期，都生成一个训练样本 SELECT user_id, TO_DATE(event_ts) AS feature_day FROM user_behavior_events GROUP BY user_id, TO_DATE(event_ts) ), behavior_features AS ( SELECT u.user_id, u.feature_day, COUNT(DISTINCT e.item_id) AS distinct_item_7d, -- 7天内看过几个不同商品 SUM(CASE WHEN e.behavior = 'view' THEN 1 ELSE 0 END) AS view_cnt_7d, SUM(CASE WHEN e.behavior = 'cart' THEN 1 ELSE 0 END) AS cart_cnt_7d, SUM(CASE WHEN e.behavior = 'favorite' THEN 1 ELSE 0 END) AS fav_cnt_7d, COUNT(DISTINCT e.session_id) AS session_cnt_7d FROM user_day u LEFT JOIN user_behavior_events e ON e.user_id = u.user_id AND e.event_ts >= TIMESTAMP(DATE_ADD(u.feature_day, -7)) AND e.event_ts < TIMESTAMP(u.feature_day) -- 特征窗口不含当天 GROUP BY u.user_id, u.feature_day ) SELECT b.user_id, b.feature_day, b.distinct_item_7d, b.view_cnt_7d, b.cart_cnt_7d, b.fav_cnt_7d, b.session_cnt_7d, CASE WHEN EXISTS ( SELECT 1 FROM user_behavior_events p WHERE p.user_id = b.user_id AND p.behavior = 'purchase' AND p.event_ts >= TIMESTAMP(b.feature_day) AND p.event_ts < TIMESTAMP(DATE_ADD(b.feature_day, 1)) ) THEN 1 ELSE 0 END AS label_next_day_purchase FROM behavior_features b LEFT JOIN test_accounts ta ON b.user_id = ta.user_id WHERE ta.user_id IS NULL;重点看两个时间条件。特征窗口的右边界是< TIMESTAMP(u.feature_day)，标签窗口的左边界是>= TIMESTAMP(b.feature_day)，也就是特征日当天零点是硬分界。为什么不用event_date直接切？因为如果日志只到日期粒度，当天23:59的购买行为会被同时算进“当天特征”和“当天标签”，这就是典型的数据泄漏。生产环境我要求事件表必须保留event_ts且切到小时级，代码里严格用半开区间[begin, end)。
这里有两个参数要解释。特征窗口取7天，不是越长越好：30天窗口能捕获“长期活跃度”，但会带来大量稀疏特征，还会让训练集膨胀到跑不动；7天能覆盖一个完整的浏览-加购-决策周期，对“近期意图”更敏感。标签窗口取24小时，是因为运营动作的干预周期就是按天做的，你预测“明天买不买”，今天就能决定发不发券。如果要预测大促前一周的蓄水行为，再把标签窗口拉长到7天，但训练数据要重新按时间轴检查。
提示：上面SQL把“每个用户每天”都生成一个样本，在千万级DAU上会产出上亿条训练数据。常见做法是先按用户采样，比如只保留最近28天活跃用户，或每用户每周只取一个特征日，把训练集控制在百万级。日志量特别大时，先把事件表按天做聚合，再参与JOIN，避免对原始事件表反复扫描。
这段SQL跑完之后，你会得到一张train_set.parquet，每一行是“某个用户在某个特征日的7天行为汇总 + 次日是否购买”。这张表就是后面所有模型的输入。
3. 特征工程与基线模型：先拿逻辑回归跑通，再谈“机器学习增强”
样本表出来后，接下来是特征工程。很多机器学习入门资料喜欢从线性回归、逻辑回归的数学原理讲起，但工程上真正难的不是假设函数怎么写，而是假设哪些特征对“用户明天买不买”这个信号有用。我习惯把行为特征分成三组，分别对应三种不同的用户信号。
3.1 用户行为特征的三组划分：频次、金额、时序
频次类特征是最直观的：近7天浏览数、加购数、收藏数、搜索次数、活跃天数。这些特征反映“这个用户今天到底有多活跃”。金额类特征反映消费力：近30天实付金额、订单均件单价、最近一笔订单金额、是否买过高价商品。时序类特征经常被新手忽略，但它们往往比频次更有效：最近一次浏览距今天数、最近一次加购距今天数、活跃时段分布（白天为主还是深夜为主）、两次购买的平均间隔天数。
| 特征分组 | 例子 | 表达了什么 |
|---|---|---|
| 频次 | view_cnt_7d, cart_cnt_7d, session_cnt_7d | 近期活跃强度 |
| 金额 | order_amt_30d, order_mean_price, max_price | 消费能力与客单区间 |
| 时序 | recency_days, buy_interval_mean, active_hour_entropy | 购买节奏与习惯 |
| 类别 | device, channel, scene, category | 访问渠道与偏好 |
类别特征要单独说。电商场景里的category、channel、device这类高基数类别列，直接做one-hot编码会让特征维度爆炸，逻辑回归迭代慢还容易过拟合。我的处理顺序是：先用逻辑回归做基线时，高基数类别只保留频次编码（比如这个channel近7天出现次数）；等切到GBDT时再接target encoding或直接让树模型切分。
特征工程做完之后，不要急着堆特征。先对每个特征做一次单变量分析：正样本和负样本在这个特征上的分布差异大不大。如果某个特征的均值在正负样本上几乎一样，它大概率没有信息量。这个检查能帮你砍掉一半垃圾特征，也能避免把“用户ID”这种唯一值特征直接丢进模型——逻辑回归会把每个用户学成一个单独系数，线上看到新用户直接傻眼。
3.2 用逻辑回归建第一个基线：标准化、class_weight与AUC
第一个模型我坚持用逻辑回归。它不是一个最终模型，而是一个校验工具：跑完之后你能检查每个特征的系数方向是否符合业务直觉，比如“历史购买金额越高，预测购买概率越高”应该是正系数。如果方向反了，大概率是特征或标签出错，这时候先别急着调模型。
逻辑回归代码很简单，但有几个参数必须解释清楚：
import pandas as pd from sklearn.linear_model import LogisticRegression from sklearn.preprocessing import StandardScaler from sklearn.metrics import roc_auc_score # 读取2.3节生成的训练样本 df = pd.read_parquet('train_set.parquet') feature_cols = [ 'distinct_item_7d', 'view_cnt_7d', 'cart_cnt_7d', 'fav_cnt_7d', 'session_cnt_7d', 'order_amt_30d', 'recency_days', 'active_hour_entropy' ] # 剔除标签或特征全为空的异常行 df = df.dropna(subset=feature_cols + ['label_next_day_purchase']) X = df[feature_cols] y = df['label_next_day_purchase'].astype(int) # 逻辑回归对特征尺度敏感，先做标准化 scaler = StandardScaler() X_scaled = scaler.fit_transform(X) # class_weight='balanced' 让少数类在损失函数里获得更高权重 model = LogisticRegression(C=1.0, class_weight='balanced', max_iter=500) model.fit(X_scaled, y) print('AUC:', roc_auc_score(y, model.predict_proba(X_scaled)[:, 1]))两个参数值得单独拎出来。第一，class_weight='balanced'并不是让模型“更准”，而是为了防止模型把所有样本都预测成负类。购买行为只有1%~3%，不做任何处理的话，逻辑回归学出来的最优解就是“所有人都不买”，AUC看似还能到0.5，实际上一个高意向用户都挑不出来。第二，C=1.0是正则化强度的倒数，C越小正则越强。逻辑回归在高维稀疏特征下非常容易过拟合，我一般把C放在0.1到1.0之间搜，而不是直接用默认值。
跑完这个基线的目的有三个：确认数据管道没跑偏、确认特征方向合理、拿到一个后续能对比的AUC下界。我在实际项目里，这一步的AUC通常在0.62到0.72之间。如果连这个区间都到不了，先别急着换模型，回头检查标签定义和特征窗口。
3.3 什么时候从逻辑回归切到GBDT：非线性、缺失值与高基数类别
逻辑回归是线性模型，它对“深夜加购且浏览过竞品且7天内有3次搜索”这种特征组合束手无策，因为这类交叉效应没法用线性加权表达。当你发现逻辑回归的AUC卡在0.7上不去，而且错误用户集中在“行为复杂但总量不大”的群体里，就该换GBDT了。
我在生产环境的主力是LightGBM，它训练快、能直接吃类别特征、对缺失值有原生处理。一个可以抄的起始参数如下：
import lightgbm as lgb train_data = lgb.Dataset(X_train, label=y_train) valid_data = lgb.Dataset(X_valid, label=y_valid, reference=train_data) params = { 'objective': 'binary', 'metric': 'auc', 'learning_rate': 0.05, 'num_leaves': 31, 'max_depth': 6, 'min_data_in_leaf': 100, 'feature_fraction': 0.8, 'bagging_fraction': 0.8, 'bagging_freq': 1, 'is_unbalance': False, 'verbose': -1 } model = lgb.train( params, train_data, num_boost_round=500, valid_sets=[valid_data], callbacks=[lgb.early_stopping(50)] )参数里最重要的是min_data_in_leaf和num_leaves。叶子节点数据量太小会学到噪声，树越深越容易过拟合。is_unbalance这里我设为False，是因为在GBDT中我更喜欢手动控制负采样比例，而不是让模型自动调权重，这样后期做概率校准更可控。如果你在2.3节做了负采样，训练集正负比已经变成1:10或1:20，这里不需要再开is_unbalance。
从逻辑回归切到LightGBM后，我一般能提升3~8个AUC点。但这段时间也更长：特征重要性分析、缺失值策略、每棵树的叶子数量都要重新调整。记住一个原则：先跑通逻辑回归，再用GBDT提分。逻辑回归的线性系数是你的“常识校验器”，跳过它直接上GBDT，特征和标签的错位会被树模型完整学进去，最后成了一个谁也不敢动的高分黑匣子。
4. 样本不均衡与时间验证：别让AUC骗了你
模型训练到这一步，很多初学者会直接拿sklearn的train_test_split随机切一份数据，跑个AUC就宣布模型完成。在用户行为预测这个任务上，这样做的结果一定是“线下AUC好看，线上效果全无”。这一章讲两个绕不开的问题：样本不均衡和验证集的时间顺序。
4.1 电商行为预测的不均衡程度：买了的人永远是少数
次日购买这个标签，正样本率通常在1%~3%。这意味着如果用全量数据直接训练，负样本数量是正样本的30到100倍。模型为了最小化损失函数，会趋向于把所有样本都预测成“不买”，因为它只需要把准确率做到97%就赢了。这时AUC看起来可能在0.6以上，但如果去看模型给高分的用户，你会发现跟随机抽人没太大差别。
一个判断标准是：模型输出的平均预测概率，应大致等于验证集的正样本率。如果你的模型预测均值是0.01而验证集正样本率是0.02，说明模型预测整体偏低，分数不可直接当概率用。另一个标准是看PR曲线，而不是只看ROC。ROC的横轴是假正率，负样本基数太大，曲线会被“容易区分的负样本”拉得很乐观；PR曲线的横轴是召回率，竖轴是精确率，更贴近“从100个预测为高意向的用户里，真正有几个买了”这个业务问题。
4.2 采样与类别权重的取舍：负采样比例不是玄学，但也不能硬套
处理不均衡的常见方案有四类，我按实际效果排序：
| 方案 | 做法 | 优点 | 风险 |
|---|---|---|---|
| 负采样 | 随机抽取部分负样本，使正负比达到1:10~1:20 | 训练数据量可控，模型有足够正样本可学 | 采样比例不对，概率失真 |
| class_weight | 在损失函数里给少数类加权 | 不改数据分布，线上无偏差 | 对树模型容易过拟合正样本 |
| 随机欠采样 | 把负样本砍到和正样本一样多 | 训练最快 | 丢失大量负样本信息 |
| SMOTE | 插值生成人工正样本 | 适合连续数值特征 | 电商count特征多为离散整数，插值会生成“看0.5次商品”这种无意义样本 |
我最常用的组合是“负采样 + 不调整class_weight”。负采样比例先试1:10，然后看验证集上的PR曲线。如果正样本召回率上不去，把比例调到1:20；如果精确率掉得厉害，回调到1:5。这个比例没必要过度调参，因为在最后概率校准那一步，你还要把采样带来的偏差修正回来。
提示：采样只能在训练集上做，验证集必须保持原始分布。如果你在验证集上也采样了，算出来的AUC和PR都无法反映线上真实表现。这是最常见的翻车点。
4.3 时间验证：随机K折在行为预测里是错的
用户行为预测的本质是“用过去预测未来”。随机K折会把12月的数据混进训练集、把11月的数据混进验证集，模型学到的“大促前用户行为规律”就会被高估。正确的做法是滚动窗口验证，保证验证集所有样本的时间都晚于训练集。
def rolling_window_split(df, day_col, train_days=60, valid_days=14, gap_days=7, step=7): days = sorted(df[day_col].unique()) total_days = len(days) # 保证最后一个窗口也能取到有效的验证集 for start in range(0, total_days - train_days - gap_days - valid_days + 1, step): train_set = days[start:start + train_days] valid_set = days[start + train_days + gap_days:start + train_days + gap_days + valid_days] train_df = df[df[day_col].isin(train_set)] valid_df = df[df[day_col].isin(valid_set)] yield train_df, valid_df # 用法：每次迭代拿一组训练/验证数据 for train_part, valid_part in rolling_window_split(df, 'feature_day'): print('train days:', train_part['feature_day'].min(), '->', train_part['feature_day'].max()) print('valid days:', valid_part['feature_day'].min(), '->', valid_part['feature_day'].max())这里gap_days=7是为了把训练集标签窗口所在的未来一天和验证集特征窗口的首日隔开。如果训练集最后一个样本的feature_day是12月7日，它的标签会用到12月8日，验证集第一个样本如果直接从12月8日开始，两边窗口贴得太近，样本会有重叠，AUC会被虚高。中间空7天，让模型面对一个真实的时间断档。
验证指标我固定看三样：AUC、PR-AUC、以及TopK命中率。TopK命中率的意思是：按模型分数从高到低取前10%的用户，这10%里有多少人真的在次日产生了购买。这个指标直接对应业务动作，比如你只打算给10%的用户发优惠券，那你要看的就是这个数。AUC负责排序质量，TopK负责业务收益，两者配合才完整。
5. 模型上线的避坑指南：5个血泪经验
模型训练完、AUC也达标了，不等于能上线。以下五个坑是我在电商行为预测项目里真实踩过的，每条按“现象 → 原因 → 解决”记录，给准备上线的你当参考。
5.1 线下AUC高，线上活动效果为零：特征里混进了未来信息
现象：模型离线验证AUC达到0.82，上线做优惠券发放实验，发出去的券核销率跟随机组没有显著差异。
原因：特征工程里有一列叫“当日是否访问过购物车”，它取的是特征日当天的事件。但我们的标签是“特征日次日是否购买”，访问购物车这个行为跟次日购买高度相关，模型学到的其实是“今天加了购的人明天大概率买”，这个规律在线上并不稳定，因为用户在看到券之前可能根本没进过购物车。
解决：把样本构造改成严格的时间断点，特征窗口右边界只到事件发生的上一秒，标签窗口从下一秒开始；上线前写一个自动校验任务，抽一批样本检查特征表最后更新时间是否永远早于标签表最早时间。这条防止数据泄漏的检查，值得写进发布流程。
5.2 模型里的“用户”和业务里的“用户”对不上
现象：模型预测的高意向用户名单，推给业务方后，对方反馈“这里面好多用户是半个月前注册的小号，我们不想触达”。
原因：训练样本里用了user_id做主键，但有很多user_id对应用户未登录状态下的多个cookie，模型把这些cookie算成不同用户的行为，导致部分真实用户的历史行为被拆散，而另一些用户被错误汇总。
解决：在样本构造前做身份图合并，至少要把“同一手机号/同一设备ID下多个user_id”识别出来；对无法合并的匿名cookie单独打标记。上线名单生成时，额外加一道“黑名单/小号过滤”规则，模型只负责输出概率，是否触达由业务规则决定。
5.3 模型上线三个月后，AUC掉了5个点
现象：上线初期AUC在0.75附近，三个月后掉到0.70，运营反馈推送转化率明显下降。
原因：电商行为随促销节奏、季节、竞品活动持续漂移。双十一前后的用户行为模式完全不是同一个分布，模型学到的“大促前高活跃度用户”的规律，在平销期完全失效。
解决：对线上模型的分数分布做逐日监控，计算PSI（Population Stability Index），PSI超过0.25就要告警。同时建立周度重训任务：每周用过去90天数据重新训练一次，并保留最近一个月的验证集做对比。不要把“训练一次管半年”当默认方案，用户行为预测模型没有一劳永逸。
5.4 缺失值处理不当：电商日志里的“缺”不是随机缺
现象：价格特征缺失的用户，模型预测概率普遍偏高，仔细查发现这些用户的商品类目集中在“下架清仓”和“内部福利单”。
原因：缺失不是随机产生的。下架商品没有及时回填价格字段，内部商品本身就不走正常价格逻辑，这些有缺失的商品天然集中在特定人群里。用均值填充后，模型把“价格缺失”学成了“高意向”的信号。
解决：缺失值单独编码，加一列price_is_missing，让模型自己去学缺失的含义。同时排查缺失发生的日志节点：是埋点丢失、数据延迟，还是业务字段本身不存在。如果缺失集中在特定来源渠道，还要考虑这个渠道是否要纳入建模。
5.5 活动期评估失真：优惠券实验只测一周，结果骗了所有人
现象：优惠券召回实验跑了一周，实验组购买率提升20%，业务方准备全量放开时，复购率数据显示实验组的购买行为大多是本来就要买的用户，只是把购买时间提前了。
原因：评估窗口太短。一周时间只能看到“谁领了券”，看不到“这个用户本来会不会买”。高意向用户在活动刺激下提前下单，会制造出虚假的增量。
解决：评估期至少覆盖一个完整的复购周期。客单价高的品类，复购周期可能是30到60天，低于这个周期的实验结论只能叫“转化前置”，不能叫“增量”。在看实验指标时，把“新客首购”和“老客复购”分开统计，能有效避免被整体数据带偏。
6. 从预测到决策：把分数接进推荐、优惠券与客服
6.1 分数分桶与AB实验：模型输出只是中间结果
模型输出的概率分数本身不产生价值，把它接进业务动作才产生价值。我的常见做法是把分数分成三桶：0~0.3为低意向，0.3~0.6为中意向，0.6以上为高意向。低意向用户不打扰，中意向用户发一张小额满减券，高意向用户直接推专属客服或大额券。分桶阈值不是拍脑袋定的，用验证集TopK命中率来找：先看前5%用户的分数底线是多少，再看前20%的底线是多少，这两个分数就是高意向和中意向的边界。
接业务前一定要做AB实验。实验分组按user_id哈希，保证实验组和对照组在历史购买率上基本一致。指标不要只看“领券率”和“核销率”，要看“增量购买率”——实验组购买率减去对照组购买率。这个增量才是模型带来的真实收益，核销率很高但全是原有购买行为前置，说明模型选的人不够准。
6.2 再进一步：用行为序列与向量化提分
如果你已经把上面的链路跑通，想继续提分，下一步不是换更大的模型，而是把行为顺序消掉的信息补回来。具体做法是取用户最近20个行为事件，把item_id映射成embedding向量，用GRU或浅层Transformer编码成用户向量，再把这个向量作为特征拼进LightGBM。相比纯手工特征，这种方式能自动学习“浏览A后加购B”的序列模式。但它的成本也不低：需要准备行为序列表、训练embedding、维护向量推理服务。我一般建议线性模型和GBDT都做扎实之后，再考虑这一步。
我被时间泄漏坑过一次之后，现在每个行为预测项目里都强制加两道工序：样本表必须带feature_day和label_day两个字段，上线前必须跑一遍“特征时间晚于标签时间”的自检脚本。这套流程并不复杂，但能拦住大多数模型翻车。希望帮到你。
本文还有配套的精品资源，点击获取
