下厨房1. MTGR混合范式建模概述
在推荐系统领域，我们经常面临一个经典难题：如何平衡特征工程与模型表达能力。传统推荐系统严重依赖人工设计的交叉特征（如"用户年龄+商品类别"的组合特征），这些特征往往对模型效果至关重要。但美团技术团队在实践中发现，当去除这些精心设计的交叉特征后，即使增加模型规模也无法弥补性能下降。这个发现引发了对新范式的思考——能否将用户粒度建模与传统特征工程的优势结合起来？
MTGR（Meituan Generative Recommendation）正是对这一问题的创新解答。它巧妙地将生成式模型架构（Transformer+用户序列）与判别式建模目标相结合，既保留了交叉特征的价值，又发挥了序列建模的优势。这种混合范式在美团多个业务场景中验证有效，相比纯特征工程方法点击率提升3-8%。
关键洞察：MTGR的核心突破在于重新思考了"手段"与"目的"的关系——生成式架构是强大的表征学习手段，但不必局限于生成式目标；用户序列是高效的计算组织方式，也不必然要求严格的因果建模。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MTGR的数据组织与token设计
2.1 数据格式解析
MTGR的数据组织方式独具匠心，采用分层token结构：
python复制[User, Seq, RealTime, [Cross_1,Item_1], [Cross_2,Item_2], ...]
这种结构明确划分了四种语义单元：
- User tokens：静态用户画像（年龄、性别、城市等）
- Sequence tokens：长期行为序列（过去30天的点击/购买记录）
- RealTime tokens：短期实时行为（最近1小时的交互）
- Candidate tokens：每个候选物品及其交叉特征（用户-物品交叉统计）
2.2 设计哲学剖析
这种设计体现了三个关键思想：
-
时空分离原则
将用户行为按时间尺度分层：长期稳定偏好（Seq）、短期实时兴趣（RealTime）与即时决策环境（Candidate）。例如在外卖推荐中，用户的常住地属于User tokens，每周五的奶茶订单属于Seq tokens，今天午餐前的咖啡浏览属于RealTime tokens。 -
特征解耦策略
交叉特征不再作为独立输入，而是作为候选物品的增强表示。例如"用户对该商家的历史点击率"不再是一个单独特征，而是融入候选商家的表示向量中。 -
并行推理优化
由于候选之间相互独立，系统可以并行处理多个候选，显著提升线上推理效率。实测显示，相比传统序列模型，MTGR的推理延迟降低40%。
3. 架构创新与技术实现
3.1 Group Layer Normalization
传统LayerNorm对所有token采用相同的归一化参数，这在MTGR的异构token场景下会导致语义混淆。GLN的创新在于：
python复制# 传统LayerNorm
output = (input - mean)/std * gamma + beta
# GLN实现
group_output = []
for group in [user, seq, realtime, candidate]:
group_mean = mean(group_hidden_states)
group_std = std(group_hidden_states)
output = (group_hidden_states - group_mean)/group_std * group_gamma + group_beta
group_output.append(output)
return concat(group_output)
这种分组处理带来两大优势：
- 分布对齐：同组token（如所有User特征）具有相似统计分布，独立归一化更稳定
- 语义保留：不同组别可以在相同维度编码不同语义（如维度1在User组表示年龄，在Seq组表示品类偏好）
3.2 Dynamic Masking机制
MTGR的注意力掩码设计超越了传统Transformer的causal mask，采用三重规则：
| 规则类型 | 适用场景 | 可见性逻辑 | 示例 |
|---|---|---|---|
| 静态可见 | User→All, Seq→All | 全连接 | 用户年龄对所有候选可见 |
| 因果可见 | RealTime→RealTime | 时间先后 | 早餐浏览影响午餐推荐 |
| 候选隔离 | Candidate→Candidate | 仅自连接 | 两个外卖商家互不影响 |
这种设计在保持因果约束的同时，实现了：
- 训练时防止信息泄露（确保真实的因果关系学习）
- 推理时支持并行计算（候选间无依赖关系）
4. 实战经验与调优技巧
4.1 特征工程转型建议
从传统模型迁移到MTGR时，特征处理需要转变思路：
-
交叉特征改造
将user_id x item_category等传统交叉特征，转化为用户对该类目的历史CTR等可量化的统计特征，作为候选物品的附加属性。 -
时序特征编码
对RealTime tokens采用相对时间编码（如"2小时前"），而非绝对时间戳，增强模型对时间模式的捕捉能力。 -
冷启动处理
对新用户/物品，用聚类中心或默认值填充缺失的交叉特征。例如新商家可用同类商家的平均表现作为初始值。
4.2 模型训练技巧
-
渐进式训练策略
先固定User/Seq参数，只训练RealTime和Candidate部分；待loss稳定后再解冻全部参数。这种方法在美团实践中使收敛速度提升2倍。 -
多任务学习设计
在主推荐任务外，增加辅助任务如：- 候选曝光预测（判断物品是否会被展示）
- 用户行为预测（点击/购买/跳过）
这种设计在A/B测试中带来5%的CTR提升。
-
负采样优化
对Candidate tokens采用batch内负采样时，需确保同一batch中的负样本来自相似场景（如同为午餐时段的外卖商家），避免过于简单的负样本。
5. 典型问题排查指南
5.1 效果下降问题
现象：上线后CTR不升反降
排查步骤：
- 检查RealTime tokens的时间戳是否准确（常见错误：客户端时间与服务端时间未对齐）
- 验证交叉特征的计算逻辑（如历史CTR是否使用正确的时间窗口）
- 分析候选物品的特征覆盖率（特别是新物品的默认值设置）
案例：某次上线后发现夜宵时段推荐异常，最终定位是RealTime tokens使用了UTC时间而非本地时区。
5.2 性能瓶颈问题
现象：推理延迟突增
优化方案：
- 对User/Seq tokens进行缓存（变化频率低）
- 对Candidate tokens进行分桶处理（相似候选共享部分计算）
- 使用TensorRT优化GLN计算图
数据：经过上述优化后，美团外卖推荐服务的P99延迟从120ms降至65ms。
6. 扩展思考与应用前景
MTGR的思想可以延伸到更多场景：
- 广告系统：将广告创意作为特殊Candidate，考虑用户对广告主的历史行为
- 搜索排序：将查询词作为额外的User token，动态融合搜索意图
- 社交推荐：把好友关系作为新的Sequence维度
在实际部署中发现，这种架构对数据分布变化展现出色鲁棒性。例如在疫情期间，用户行为模式剧烈变化时，MTGR相比传统模型能更快适应新趋势，部分场景下AUC跌幅减少60%。