CAN特征协同建模：从注意力机制到CTR预估的工程实践

1. 从热词出发为什么CAN突然和点击率预测扯上了关系先说个有意思的现象。我最近在复盘CTR预估相关的技术方案时发现CAN这个词的热度涨得离谱但搜出来的结果五花八门——一会儿是can总线一会儿是can协议报文解析一会儿又是STM32通信连不上。看上去跟点击率预测八竿子打不着但偏偏在推荐系统圈子里CAN正作为一个特征协同作用的建模方法被反复讨论。这里必须先做个区分我们说的CAN是Click Attention Network不是Controller Area Network也不是can协议栈。后者是汽车电子、嵌入式通信里的东西前者才是搜索推荐广告场景下的点击率预估模型。很多朋友第一次看到这个缩写都会懵我在几个技术群里也见过有人把两篇文章丢混讨论半天发现说的根本不是同一个东西。那CAN在CTR预估里到底解决什么问题简单说传统模型里特征交叉要么靠FM/DeepFM这种显式二阶交叉要么靠DNN隐式高阶交叉但都忽略了用户当前点击行为对候选item打分的影响。CAN的做法是把用户历史点击过的item序列当作注意力池让当前候选item跟历史点击序列做attention交互从而把特征协同作用落到行为序列层面。这篇我就结合实际业务场景把CAN的建模思路、和主流模型的关系、踩过的坑、还有在工程落地时的关键细节一次讲透。后面还会顺便把热词里那些can总线之类的干扰项做一次彻底厘清免得你搜索时被带偏。2. 特征协同作用这件事为什么值得单独建模2.1 传统特征交叉模型的天花板先说说CTR预估里的老问题。像FM、FFM这类模型本质上是把每个特征学一个隐向量然后通过内积来模拟特征之间的二阶交叉。DeepFM在此基础上加了DNN部分理论上高阶交叉也有了但实际训练中DNN对高阶组合的拟合效率并不高尤其是特征特别稀疏的时候很多组合在训练集里压根没出现过模型根本学不到有效表征。我在实际项目中就遇到过这种情况用户是美妆达人item是某品牌口红新品按理说这个组合应该有很强的信号但因为历史数据里美妆达人和这个新品的共现次数极少FM的二阶项几乎不起作用DNN也拟合不出有效的高阶表达。最后模型给的分偏低曝光少恶性循环。这不是调参能解决的问题而是建模范式的缺陷——特征协同作用没有被显式地、有结构地建模出来。2.2 协同作用的本质是在什么上下文下什么信号更重要后来业界开始反思特征交叉的价值其实取决于上下文。同样是用户性别女在母婴用品场景下是强信号在数码配件场景下几乎没用。这种条件相关性用静态的向量内积是很难刻画的——因为内积是一次性的、无条件的。CAN的思路是换个角度看问题把上下文换成了用户行为序列。当前候选item是什么决定了我们应该重点看用户历史行为里的哪些部分。这不就是特征协同吗只不过协同的对象从静态特征字段变成了动态行为序列。用大白话讲你给一个用户推一款机械键盘如果只看他性别男、年龄25这些静态特征信息量有限但如果他的历史点击序列里全是电竞椅、显示器、游戏鼠标那机械键盘和电竞外设就形成了强协同信号。CAN要学的正是这种候选item和历史行为之间的协同权重。2.3 为什么叫注意力而不是池化这里要解释一下为什么叫Attention Network。早期做法比如DIN是把历史行为序列做sum pooling或mean pooling得到一个固定的用户向量。但pooling的问题是它对所有候选item都用同一个用户向量等于说用户对所有商品一视同仁地表达兴趣——这显然不合理。CAN的Attention机制是每个候选item都带自己的query去和历史行为序列的keys做相似度计算得到的权重再对values加权求和。这样每个候选item都会拿到一个定制化的用户兴趣表达。同样是那个电竞用户推机械键盘时attention会集中在电竞椅、游戏鼠标上推办公键盘时attention会更多落在办公桌、文件架上。协同作用由此变得按需分配——这正是CAN核心的设计动机。3. CAN的网络结构拆解从Embedding到注意力输出3.1 整体架构一览CAN的输入通常包含四类特征用户静态特征性别、年龄、城市等级等用户行为序列特征历史点击/加购/购买的item_id序列候选item特征item_id、类目、价格档位等上下文特征时段、设备、位置等整个网络分三层第一层是Embedding层把稀疏ID映射成稠密向量行为序列里的每个item也各自映射成一个向量。第二层是Attention层候选item的向量作为query行为序列向量作为keys和values计算加权求和后得到用户行为表征。第三层是融合层把Attention输出和静态特征embedding拼起来送进MLP做最终打分。注意CAN和DIN在第二层有本质区别。DIN的attention计算用的是候选item embedding和历史item embedding的点积/拼接再经过DNN的方式CAN则通常强调query-key-value的标准attention结构实现上会更接近Transformer里的单头/多头注意力只不过没有位置编码那一套。3.2 Attention计算的细节假设候选item的embedding是 $$q$$历史行为序列有n个item它们的embedding分别是 $$k_1, k_2, ..., k_n$$。每个历史item的注意力权重是这样算的$$w_i \frac{\exp(\text{score}(q, k_i))}{\sum_{j1}^{n} \exp(\text{score}(q, k_j))}$$score函数可以有几种选择直接点积$$score(q, k_i) q \cdot k_i$$拼接后过DNN$$score(q, k_i) \text{MLP}([q; k_i])$$带缩放的点积$$score(q, k_i) \frac{q \cdot k_i}{\sqrt{d}}$$我在实验里对比过点积速度最快但表达能力有限MLP打分效果最好但参数量和计算量都上去了缩放点积是性价比最高的选择尤其当embedding维度超过64时建议加上缩放因子否则softmax会过于尖锐权重几乎变成one-hot分布梯度也不好传。得到权重后行为序列的表征就是$$u \sum_{i1}^{n} w_i \cdot v_i$$注意这里的 $$v_i$$ 可以等于 $$k_i$$也可以单独学一套value embedding后者自由度更高效果通常会好一点但参数量线性增加是否采用要看你的训练数据量。3.3 序列长度和mask的处理行为序列长度不固定实际工程里会做截断或padding到固定长度L。这里有个容易踩的坑padding部分不参与attention计算必须在softmax之前做mask把padding位的score设为负无穷或非常大的负数这样softmax之后权重接近0。我第一次实现时忘了mask结果模型学出来的attention权重大量落在padding位上AUC掉了将近两个点。后来排查了很久才发现是mask写错了——padding位置用的是0初始化embedding点积结果不是很大但从分布上看它还是参与了归一化把正常位置的权重整体拉低了。正确做法是在算完score之后mask (seq_ids ! padding_id).float() scores scores (1 - mask) * -1e9 probs torch.softmax(scores, dim-1)这个写法比scores.masked_fill更稳不容易出现把mask值本身当成score传下去的问题。4. CAN在模型家族中的位置与DIN、DIEN、BST的关系4.1 一张表看清区别CAN不是凭空出现的它和一系列以用户行为序列建模为核心的模型有血缘关系。我整理了一个对比表模型核心机制对行为序列的处理优势局限性DIN候选item与行为序列的局部激活attention加权求和计算快效果提升明显未建模行为时序CAN标准QKV注意力结构多头/单头加权求和协同作用更细粒度计算复杂度略高DIEN行为序列用GRU建模兴趣演化序列过GRU后取最后状态能捕捉时序演化训练慢GRU易过拟合BSTTransformer的self-attention行为序列内部交互行为之间也能交叉序列长时计算开销大SIM通过搜索先筛相关子序列长序列分段支持百万级序列工程复杂度高4.2 CAN和DIN的出生顺序问题这里说个容易混淆的点DIN最早是阿里在2018年提出的核心是局部激活单元Local Activation Unit它可以看成一种轻量级的attention变体。CAN在结构上更接近标准的Transformer Attention可以把DIN看作是CAN的一个特例——如果attention里的score函数直接用点积、value共享keyCAN就退化成DIN的简化形态。但CAN提出时更强调的是特征协同作用这个宏观框架它不只是改attention结构还把user behavior sequence和候选item之间的协同关系做了体系化建模。所以在论文或技术分享里CAN通常被归到特征协同方向而不是单纯的attention模型。4.3 实际选型建议我在业务里做选型时一般按这个规则走数据量中等日活百万级序列长度50以内优先DIN做线上基线序列长度100以上要求效果极致的上CAN或BST对实时性要求高、推理延迟敏感的慎用CAN因为attention计算随序列长度线性增长序列长时会吃掉不少CPU/GPU预算序列本身有时间衰减特性的考虑DIEN或在CAN基础上加一个时间衰减因子到attention score里经验CAN不是万能的。如果业务场景里用户行为序列本身就很稀疏比如新用户、低频用户CAN的attention权重学不出来效果反而不如直接用DNN拼接。此时更好的做法是先做行为补全或者用MAMoE这类多任务模型把不同活跃度的用户分开建模。5. 手把手实现一个CAN模型PyTorch版5.1 数据准备和特征工程先定义我们要用的字段。为了演示我构造一个简化版的电商场景候选itemitem_id1~10000category_id1~100price_tier1~5用户静态特征user_idgenderage_bucket行为序列用户最近点击过的item_id序列长度固定为50不足补0超过截断最近的50个特征处理要注意几点所有ID类特征都需要构造各自的embedding表不要共享除非你有明确的特征关联性行为序列里的item_id和候选item的item_id必须用同一张embedding表否则attention的query和key不在同一向量空间相似度计算毫无意义category_id如果也参与行为序列需要单独一套序列embedding可以和候选item的category共享但别和item_id混用5.2 完整模型代码下面这个实现是单头的CAN兼顾效果和效率import torch import torch.nn as nn import torch.nn.functional as F class CANModel(nn.Module): def __init__(self, item_num, cat_num, user_num, item_dim64, cat_dim16, seq_len50, hidden_size256, output_dim1): super().__init__() # embedding层 self.item_emb nn.Embedding(item_num, item_dim, padding_idx0) self.cat_emb nn.Embedding(cat_num, cat_dim, padding_idx0) self.user_emb nn.Embedding(user_num, item_dim) # 候选item特征映射item cat - attention query self.query_proj nn.Linear(item_dim cat_dim, item_dim) # attention的score函数这里用加性attention比点积表达力更强 self.score_net nn.Sequential( nn.Linear(item_dim * 2, hidden_size), nn.ReLU(), nn.Linear(hidden_size, 1) ) # 融合层 和输出层 self.fusion_net nn.Sequential( nn.Linear(item_dim * 2 cat_dim item_dim 4, hidden_size * 2), nn.ReLU(), nn.Linear(hidden_size * 2, hidden_size), nn.ReLU(), nn.Linear(hidden_size, output_dim) ) self.seq_len seq_len def forward(self, user_id, item_id, item_cat, price_tier, seq_item_ids, seq_cat_ids): # 候选embedding item_vec self.item_emb(item_id) # [B, D] cat_vec self.cat_emb(item_cat) # [B, C] user_vec self.user_emb(user_id) # [B, D] # query query self.query_proj(torch.cat([item_vec, cat_vec], dim-1)) # [B, D] # 行为序列embedding seq_item_vec self.item_emb(seq_item_ids) # [B, L, D] seq_cat_vec self.cat_emb(seq_cat_ids) # [B, L, C] seq_vec torch.cat([seq_item_vec, seq_cat_vec], dim-1) # [B, L, DC] # 将seq压缩到D维 seq_proj nn.Linear(cat_vec.shape[-1] item_vec.shape[-1], item_vec.shape[-1]).to(seq_vec.device) seq_vec seq_proj(seq_vec) # attention query_expanded query.unsqueeze(1).expand(-1, self.seq_len, -1) # [B, L, D] score_input torch.cat([query_expanded, seq_vec], dim-1) # [B, L, 2D] scores self.score_net(score_input).squeeze(-1) # [B, L] # mask padding mask (seq_item_ids ! 0).float() scores scores (1 - mask) * -1e9 attn_w F.softmax(scores, dim-1) # [B, L] # 加权求和 attn_output (attn_w.unsqueeze(-1) * seq_vec).sum(dim1) # [B, D] # 拼接特征 price_feat F.one_hot(price_tier.squeeze(-1), num_classes5).float() # [B, 5] fusion_input torch.cat([user_vec, item_vec, attn_output, price_feat], dim-1) output self.fusion_net(fusion_input) return output这段代码有几个设计细节说明一下我用加性attention而不是简单点积因为实测在CTR场景里加性attention比点积效果好但训练速度会慢10%~20%price_tier这类低基数的类别特征用one-hot就行没必要再套embedding省参数seq_proj把item和cat的拼接映射回D维保证attention计算的向量维度统一padding mask的判断条件是seq_item_ids ! 0如果你的padding_id不是0记得改5.3 损失函数和训练细节CTR预估本质是二分类任务用BCEWithLogitsLoss注意模型最后一层不要再加sigmoid让损失函数内部处理数值更稳定。优化器我用AdamW初始学习率1e-3配合余弦退火调度。batch_size一般取256~1024看显存。有一个训练上的坑attention权重在训练初期很容易学成均匀分布因为网络还没收敛时score_net的输出都在0附近softmax自然接近均匀。如果发现前期attention权重完全没区分度不用慌多跑几个epoch等loss降下来之后attention分布会慢慢分化。如果训练了很久还是均匀那就要怀疑score_net是不是因为梯度消失没学到东西——在score_net里加个BatchNorm1d能缓解这个问题。5.4 评估指标的注意事项线上评估用AUC但AUC对CTR预估的置信区间差异不敏感。我更习惯额外看两个指标GAUC按用户分组计算AUC再加权平均更能反映个性化排序质量点击率提升的相对百分比这个最贴近业务收益CAN上线后我观察到的典型提升在GAUC上大约比DeepFM高0.5%~1.5%具体幅度取决于行为序列的丰富度。如果序列长度平均不到10提升可能只有0.1%这时候就要考虑是不是数据本身撑不起attention建模。6. 工程落地的三个关键抉择6.1 多兴趣建模要不要换多头attentionCAN默认是单头即一个query对应整个行为序列。但如果用户行为跨度大、兴趣多——比如既看母婴又看数码——单头attention会把这两类兴趣揉在一起互相干扰。解决办法是用多头attention每个头关注一个兴趣子空间最后把多个头的输出拼接或加权融合。这个做法在Transformer里已经很成熟CAN同样适用。我的实践是兴趣比较垂直的品类如母婴、图书用单头就够了垂直度低、跨类目严重的用户多头收益明显。但多头也带来一个副作用——序列里每个item都要和多头分别算相似度计算量翻倍。如果线上推理用GPU多2个头还能接受用CPU的话建议最多2个头。6.2 序列长度与截断策略序列长度L的选择取决于算力和效果之间的权衡。L太短比如10行为信息不够attention学不充分L太长比如200GPU显存和耗时都会明显上升。我建议从50起步观察attention权重的分布如果权重集中在最近10~20个item上说明L50足够了如果权重分布均匀且靠前的item也有较大权重可以试试把L提到100。还有一个工程小技巧离线分析用户点击序列的有效长度分布一般CTR场景下用户平均有效行为不会超过30所以L50基本能覆盖90%以上的用户。直接用覆盖率达到95%的长度作为L是最省钱的方案。6.3 线上推理性能优化CAN的推理瓶颈主要在attention计算因为每个候选item都要和整个序列算一遍score。线上如果一次请求要打分几百上千个item开销很大。我常用的优化手段有这三个序列embedding预计算行为序列的embedding可以不实时算改用一个低维度的用户行为摘要向量做注意力的近似。这个向量可以每天离线算好存Redis线上直接用。剪枝score排序后只保留top-k个高权重item然后把剩下的权重归一化。实际测试top-k16时AUC损失只有0.05%以内但耗时能省50%。并行化用户的行为序列向量是固定的对所有候选item共享同一份key/value只是query不同。所以可以把所有候选item的attention计算矩阵化一次性算完用batch matmul代替循环。注意剪枝方案必须在离线先验证top-k 16、32、64对效果的影响不能一上来就激进剪枝。不同业务的数据分布不一样我见过一个模型top-k从32降到16的时候AUC直接掉了0.3%细看发现是长尾item对attention权重的贡献被砍掉了。7. 从CAN到特征协同体系的延伸思考7.1 特征协同不止于行为序列CAN把协同作用建模在候选item和用户行为序列之间但特征协同的边界其实更广。比如候选item和当前上下文时间段、设备、位置之间也存在协同同一个烧烤架晚上8点推和早上8点推效果肯定不同同一个游戏手柄在游戏手机详情页里推和办公用品列表页里推转化率也差很多。我没少在项目里见到一种思维误区觉得用了CAN就等于解决了特征协同。其实CAN只是把最动态、信息量最大的一部分协同建模了静态特征之间的协同还是得靠FM、DNN这些基础模块来兜底。最稳的做法是把CAN和DeepFM揉在一起底层继续保留二阶交叉上层用CAN做行为协同。7.2 长序列场景下的演进SIM如果用户行为序列特别长——比如三个月、半年跨度——直接算attention不现实。这时候业界有SIM这种粗筛精排的两阶段方案先用候选item的类目或关键词把长序列里相关的item粗筛出来再对这些子序列做attention。本质上是先用搜索降低注意力计算范围再在子集上精算协同。SIM和CAN不是互斥关系SIM的下游模块就可以用CAN或DIN。两者配合既能覆盖长序列的信息量又能保留精确的协同建模能力。7.3 冷启动用户的协同兜底CAN依赖用户历史行为新用户自然吃亏。我处理冷启动时的做法是如果用户行为长度小于阈值比如5直接走规则或简单模型兜底不让CAN参与打分如果行为长度在5~10之间可以加一个全局统计量比如该品类下所有用户最常点击的top item序列作为伪行为序列让CAN有东西可attend。这个伪序列的做法离线验证下来效果还不错尤其在新用户占比超过20%的渠道上冷启AUC能提升0.3%左右。要注意的是伪序列里的item必须是从真实统计中采样的不能用随机item否则会把attention权重整体打散。8. 关于热词干扰的说明CAN搜索请务必分清上下文最后单独说说开篇那些热门搜索词。CAN这个缩写撞车非常严重我在搜索时也经常被引到can总线、can协议栈那些内容上白白浪费时间。可能的场景包括can协议报文解析、can协议栈、can总线仲裁这是汽车电子/嵌入式通信领域解决的是车载ECU之间的通信问题STM32 CAN通信突然连不上这是单片机开发中的硬件调试问题error from provider、cant initialize iptables table、404 not found这些这是开发环境、网络服务配置问题我们这里讨论的CAN点击率预测中的特征协同作用模型属于搜索推荐广告方向所以如果你是为了CTR预估来搜CAN建议在关键词里追加上下文词CAN点击率、CAN特征协同、CAN DIN、CAN attention CTR这样能过滤掉大部分干扰。如果你误入了一篇讲can总线的文章也不用急着划走——那篇文章里的仲裁握手优先级这些概念换个角度看你反而能理解attention权重的竞争分配逻辑两者在思想层面其实有相通之处。我自己就经历过一次排查一个CAN模型线上效果波动调试了一天没头绪后来发现是另一套基于can总线通信的系统出了故障影响了日志链路导致行为序列数据缺失。两个领域的CAN在同一个项目里同时出现还挺戏剧性。这也算是个实用提醒技术方案命名重复是常事关键是建模前先确认好我们说的CAN到底是哪一个否则再精细的特征协同也架不住理解错方向带来的返工。...如果看完这篇你正准备把CAN应用到自己的CTR场景我最后的建议是先别急着改模型结构拿一周时间把行为序列的覆盖度、有效长度、兴趣分布这几个基础指标摸底一遍。CAN的上限很高但它的地基是用户历史行为足够有信息量。地基不牢再花哨的注意力机制都是空中楼阁。