CTR预估特征协同网络CAN：原理、结构拆解与落地实操

1. 从"单打独斗"到"协同作战"：CTR预估为什么需要特征协同

点击率预测（CTR）这件事，做过推荐和广告的人都知道，模型效果的天花板往往不在单个特征有多强，而在于特征之间的组合能不能被模型捕捉到。用户ID、商品ID、品类、价格档位、时段这些字段单独看信息量都有限，但一旦交叉起来，比如"年轻女性 × 美妆 × 晚间"，信号强度立刻上一个台阶。这就是特征交互的价值，也是CTR模型演进的一条主线。

早期的做法靠人工做交叉特征，工程师凭经验把几个字段拼在一起喂给模型。这种方式的问题很明显：组合爆炸、维护成本高、覆盖不全。后来FM（因子分解机）用隐向量内积的方式自动建模二阶交互，DeepFM、DCN、xDeepFM这些模型进一步把高阶交互纳入进来。但这里有个被很多人忽略的细节——并不是所有特征交互都值得建模。真实场景里，大量特征对之间是相互独立的，强行让模型去学它们的交互，反而会引入噪声，拖累效果。

CAN（Co-Action Network，特征协同网络）正是冲着这个痛点来的。它的核心思路是：与其让模型被动地接收所有交叉组合，不如让特征之间主动"协同"——用一个特征去调制另一个特征的表示，形成一种条件化的、动态的交互。这个思路和传统"先拼接再送进MLP"的做法有本质区别，前者是静态的、无差别的，后者是动态的、有选择的。

我最初接触CAN是在一个电商CTR项目里，当时模型已经堆到DIN+多层交叉，离线AUC涨得很慢，线上CTR也卡在瓶颈。换成CAN结构之后，同样的特征输入，离线AUC有可见提升，更重要的是线上推理延迟没有明显恶化。这篇文章就把CAN这套东西从原理到落地完整拆一遍，包括它到底解决了什么问题、结构怎么设计、实操中哪些坑必须避开。适合已经做过基础CTR模型、想进一步优化特征交互效果的读者，也适合刚接触推荐系统、想理解"特征协同"这个概念到底怎么回事的同学。

2. CAN的核心机制：用"协同"替代"拼接"

2.1 传统特征交互的三种范式及其局限

要理解CAN，得先看清楚它站在谁的肩膀上。CTR模型里的特征交互大致经历了三个阶段。

第一种是人工交叉。运营和算法工程师根据业务理解手动构造组合特征，比如"城市等级_价格区间"这种。优点是可控、可解释，缺点是人力密集、覆盖有限，而且一旦业务变化，之前构造的交叉可能就失效了。

第二种是隐式高阶交互。DNN本身具备拟合任意阶交互的能力，理论上把原始特征拼接后送进多层全连接，模型能自己学出交互。但实际中DNN对低阶交互的建模效率很低，稀疏特征下更是如此，所以才有了Wide&Deep这种"宽部分记低阶、深部分记高阶"的互补结构。

第三种是显式交互建模。FM用内积显式建模二阶交互，DCN用交叉网络显式建模高阶交互，xDeepFM用CIN做压缩交互。这类方法比纯DNN高效，但它们的交互形式是固定的——FM就是内积，DCN就是逐层交叉，模型没法根据特征本身的内容动态调整交互方式。

这三种范式的共同问题是：交互是"无差别"的。不管两个特征是否真的相关，模型都会尝试去建模它们的交互。在特征维度动辄上万的场景里，这种无差别建模带来的噪声和计算浪费是相当可观的。

2.2 CAN的"协同"到底协同了什么

CAN的出发点是：让一个特征（称为co-action特征）去作用于另一个特征（称为主特征）的embedding，产生一个条件化的表示。用一句话概括就是——主特征的表示不再是固定的，而是被协同特征动态调制过的。

举个具体例子。假设主特征是"商品ID"，协同特征是"用户年龄"。传统做法是把商品embedding和年龄embedding拼接或做内积。CAN的做法是：把年龄作为一个条件，通过一个小型网络生成一组变换参数，用这组参数去变换商品embedding。这样同一个商品，面对不同年龄段的用户，其表示是不同的。这本质上是一种条件计算（conditional computation）的思想。

这个设计的好处在于：交互不再是预先定义好的固定形式，而是由协同特征的内容动态决定的。模型可以学到"当协同特征取某个值时，主特征应该被怎样变换"，从而实现了更细粒度的交互建模。而且由于变换网络通常很小，计算开销可控。

2.3 为什么这种设计能缓解噪声问题

关键在于CAN的交互是有方向、有条件的。传统交叉是A和B对称地交互，CAN是B对A的调制，这种非对称性让模型可以表达更丰富的语义。更重要的是，当协同特征对主特征没有实际影响时，变换网络可以学出接近恒等的变换，相当于自动"关闭"了这条交互路径。这比强行让模型去拟合一个无意义的交叉要合理得多。

我在实际项目里观察到的一个现象是：CAN对稀疏特征特别友好。像用户ID这种高基数特征，传统embedding在数据稀疏时学得很差，但用行为序列或属性特征去协同调制之后，表示质量明显改善。这背后的逻辑是，协同特征提供了额外的上下文信息，帮助主特征在稀疏条件下也能得到合理的表示。

3. 结构拆解：CAN网络里每一层在干什么

3.1 输入层与embedding的组织方式

CAN的输入和常规CTR模型没有本质区别，都是把离散特征做embedding、连续特征做分桶或直接归一化。但有一个关键设计需要提前想清楚：哪些特征做主特征，哪些做协同特征。

这个划分不是随意的。一般来说，主特征选那些基数高、单独表示能力弱、但业务上重要的字段，比如商品ID、广告ID、内容ID。协同特征选那些能提供上下文、区分度高的字段，比如用户画像、时段、场景、行为统计。一个主特征可以配多个协同特征，也可以多个主特征共享同一组协同特征。

实操中我建议先做一轮特征重要性分析，把高基数稀疏特征挑出来作为主特征候选，然后用业务逻辑判断哪些字段适合做协同。不要一上来就把所有特征两两组合，那样参数量和计算量都会失控。

3.2 协同变换网络的具体构造

协同变换网络是CAN的核心。它的输入是协同特征的embedding，输出是一组用于变换主特征embedding的参数。具体来说，如果主特征embedding维度是d，变换网络输出的是一个d×d的变换矩阵（或者其低秩分解），然后用这个矩阵去乘主特征embedding。

直接输出d×d矩阵参数量是d²，当d=64时就是4096个参数，如果协同特征很多，这个开销不小。所以实践中常用低秩分解：输出两个d×r的矩阵，r远小于d，变换等价于先降维再升维。这样参数量降到2dr，r取8或16时开销很小。

另一个细节是变换网络的结构。通常用一两层全连接加激活函数就够了，不需要太深。激活函数选ReLU或PReLU都行，我实测下来PReLU在稀疏场景下略好一点，因为它保留了负半轴的梯度。

3.3 变换后的表示如何进入后续网络

变换后的主特征表示，会和原始特征、其他协同特征一起拼接，送进后续的DNN或交叉层。这里有个容易踩的坑：变换后的表示是否需要和原始embedding一起保留。

我的经验是保留。因为变换网络学到的是一种调制，但原始embedding本身也携带信息，两者拼接能让模型自己决定用多少调制后的信息、用多少原始信息。如果只保留变换后的，相当于强制模型接受调制结果，灵活性反而下降。

后续网络部分，CAN本身不限制用什么结构，DeepFM、DCN、DIN都可以接。我一般会在变换层之后接一个DCN交叉层再加DNN，这样低阶和高阶交互都能覆盖。

3.4 一个可参考的结构参数配置

下面这张表是我在一个中等规模电商CTR任务里用过的配置，可以作为起点参考，具体数值需要根据你的数据规模调整。

这套配置在百万级样本、特征维度十万级的场景下，单卡训练可以跑得动，推理延迟相比基线模型增加在可接受范围内。

4. 落地实操：从数据准备到线上部署的完整链路

4.1 特征工程阶段要做的取舍

CAN对特征工程的要求和常规CTR模型类似，但有几个点需要特别注意。

第一，主特征的基数控制。如果某个ID类特征基数达到千万级，embedding表会非常大，训练和推理都吃不消。这时候要么做hash分桶，要么用频次过滤把长尾ID去掉。我一般会把出现次数低于阈值的ID统一映射到一个"其他"桶，阈值根据数据量定，百万级样本下取10左右比较合适。

第二，协同特征的质量。协同特征是要去调制主特征的，如果它本身噪声大，调制出来的结果也好不了。所以协同特征尽量选那些统计稳定、区分度高的字段，比如用户的历史点击率分档、活跃度分档，而不是原始的行为序列。

第三，连续特征的处理。连续特征直接送进变换网络效果通常不好，建议先做分桶离散化再embedding，或者做归一化后和embedding拼接。分桶的边界可以用等频分桶，保证每桶样本量均衡。

4.2 训练过程中的几个关键细节

训练CAN的时候，有几个地方和常规模型不太一样。

学习率设置。变换网络的参数和主embedding的学习率可以分开设。我通常给变换网络稍大的学习率，因为它参数量小、需要更快适应，而主embedding用较小的学习率避免震荡。具体可以用分组学习率，变换网络用1e-3，embedding用5e-4。

正则化。变换网络容易过拟合，尤其是协同特征维度较高时。除了Dropout，还可以对变换矩阵加L2正则。我实测L2系数取1e-5到1e-4之间比较合适，太大反而欠拟合。

batch size。CAN对batch size比常规模型敏感一些，因为变换是条件化的，batch太小会导致每个条件见到的样本太少。建议batch size不低于1024，有条件的话用2048或4096。

负采样。如果是广告场景，负样本比例要控制好。CAN本身不改变负采样策略，但要注意负采样后的分布偏移对变换网络的影响，必要时做校准。

4.3 离线评估与线上AB的衔接

离线评估不能只看AUC。CAN这种结构，AUC提升可能不明显，但GAUC（分组AUC）和LogLoss往往有改善，因为它在细粒度交互上更强。我一般会同时看这几个指标，再结合校准曲线判断。

线上AB的时候，除了CTR，还要盯住推理延迟和内存占用。CAN的变换网络虽然小，但如果主特征和协同特征组合很多，累加起来开销不小。我建议先在小流量上验证延迟，确认可接受再放量。

还有一个容易被忽略的点：模型热更新。CAN的embedding表通常很大，热更新时要注意变换网络参数和embedding的同步，避免出现新旧参数混用导致的表示不一致。

4.4 一个简化的PyTorch实现骨架

下面这段代码展示了CAN核心变换层的实现思路，省略了数据加载和训练循环部分，重点看变换逻辑。

import torch import torch.nn as nn class CoActionLayer(nn.Module): def __init__(self, main_dim, co_dim, rank=16, hidden=(64, 64)): super().__init__() layers = [] in_dim = co_dim for h in hidden: layers.append(nn.Linear(in_dim, h)) layers.append(nn.PReLU()) in_dim = h # 输出两个低秩矩阵的参数 layers.append(nn.Linear(in_dim, 2 * main_dim * rank)) self.mlp = nn.Sequential(*layers) self.main_dim = main_dim self.rank = rank def forward(self, main_emb, co_emb): # main_emb: [B, main_dim], co_emb: [B, co_dim] params = self.mlp(co_emb) B = params.size(0) u, v = params[:, :self.main_dim * self.rank], params[:, self.main_dim * self.rank:] u = u.view(B, self.main_dim, self.rank) v = v.view(B, self.rank, self.main_dim) # 低秩变换: main_emb -> u @ (v @ main_emb) transformed = torch.bmm(u, torch.bmm(v, main_emb.unsqueeze(-1))).squeeze(-1) return transformed

这段代码里，变换网络输出两个矩阵u和v，通过低秩分解实现变换。实际使用时，变换后的表示会和原始embedding拼接，再送进后续网络。注意PReLU的参数量也要纳入正则化考虑。

5. 踩坑记录：那些文档里不会写的教训

5.1 变换网络输出初始化不当导致训练不收敛

我第一次跑CAN的时候，变换网络输出层用了默认初始化，结果训练前几个epoch loss几乎不降。排查后发现是变换矩阵初始值太大，导致变换后的embedding数值范围失控，后续网络梯度爆炸。

解决办法是把变换网络输出层初始化为接近零的值，让初始变换接近恒等映射。这样训练初期模型行为接近基线，再逐步学出有意义的变换。具体做法是把输出层权重初始化为很小的值（比如1e-3量级），偏置初始化为零。这个技巧在条件计算类模型里很常见，但很多教程不会提。

5.2 协同特征选错导致效果不升反降

有一次我把用户实时行为序列作为协同特征，想着信息量大应该有用。结果离线AUC反而掉了。分析后发现，实时行为序列噪声大、分布不稳定，用它去调制主特征，等于给主特征引入了大量随机扰动。

后来换成用户历史统计特征（比如7天点击率分档、活跃天数分档），效果就正常了。这个教训是：协同特征要稳定、要有明确的语义，不能只看信息量。实时特征不是不能用，但要做平滑和降噪，或者只在特定场景下用。

5.3 主特征和协同特征维度不匹配的处理

CAN要求主特征和协同特征的embedding能配合变换。如果主特征维度是64，协同特征维度是32，变换网络输出的是64×64的变换（低秩分解后是64×r和r×64），协同特征维度只影响变换网络的输入层。这个没问题。

但如果主特征有多个，每个维度不同，就需要分别处理。我遇到过主特征维度从16到128不等的情况，统一到64最省事，但会损失一些信息。后来我的做法是保持各自维度，变换网络按主特征分别构造，虽然代码复杂一点，但效果更好。

5.4 线上推理时的批处理优化

CAN的变换是逐样本条件化的，这意味着不能像普通embedding查表那样简单批处理。线上推理时如果每个请求单独算变换，延迟会很高。

我的优化方案是把同一批请求里的协同特征做分组，相同协同特征取值的请求合并计算变换矩阵，然后再分发。这样能把变换计算从O(N)降到O(不同协同特征取值数)。在协同特征基数不高的情况下，这个优化效果很明显。如果协同特征是连续值，可以先做分桶再分组。

5.5 与现有模型的兼容问题

CAN不是要完全替换现有模型，而是可以作为一层插入。但如果现有模型已经用了DCN或FM做交叉，再叠加CAN要注意交互重复的问题。我建议要么用CAN替代原有的交叉层，要么让CAN只处理那些原有交叉层覆盖不到的特征对，避免同一对特征被建模两次。

6. 效果验证与调优方向

6.1 怎么判断CAN是否真的起了作用

不能只看最终AUC。我一般会做几组对照实验：基线模型、基线+CAN、基线+CAN但协同特征随机打乱。如果第三组效果明显差于第二组，说明CAN确实在利用协同特征的信息，而不是单纯增加了参数量带来的收益。这个对照实验很关键，能排除"参数多了效果自然好"的干扰。

另外可以做消融，把变换网络换成恒等映射，看效果下降多少。下降越明显，说明协同机制贡献越大。

6.2 参数量与效果的平衡

CAN的参数量主要来自变换网络和embedding表。变换网络参数量可以通过降低秩r来控制，embedding表通过控制基数来控制。我的经验是，在效果不明显下降的前提下，r可以压到8甚至4，尤其是协同特征维度不高的时候。

如果发现模型过拟合，优先降r和加Dropout，而不是砍特征。因为CAN的价值就在于特征协同，砍特征等于放弃了它的核心优势。

6.3 后续可以尝试的扩展

一个方向是多协同特征。目前多数实现是一个主特征配一个协同特征，但实际上可以让多个协同特征共同作用，比如用注意力机制加权多个协同特征的调制结果。这样表达力更强，但计算量也更大。

另一个方向是协同特征的自动选择。现在主特征和协同特征的配对靠人工，未来可以用门控机制让模型自己决定哪些协同特征对哪些主特征重要。这本质上和CAN的思路一脉相承，都是让交互更智能、更有选择性。

我在实际项目里还试过把CAN和序列模型结合，用用户行为序列的attention输出作为协同特征去调制商品embedding，效果比单独用DIN要好一些。这个方向值得继续挖，尤其是序列特征丰富的场景。

最后分享一个实操小技巧：CAN的调试建议从单主特征单协同特征开始，跑通之后再逐步加特征。一上来就搞复杂结构，出问题很难定位是哪个环节的锅。先把最小可用版本跑出正向收益，再谈优化，这个节奏在CTR模型迭代里屡试不爽。