共计 1085 个字符，预计需要花费 3 分钟才能阅读完成。
在看一个大佬向量的解释时候提到召回中的向量的解耦，看完之后有所感触，回想 DSSM 中的实现，跟这描述似乎完全契合。
召回模型的特点：解耦
u2i召回，与排序，虽然都是建模user与item的匹配（match）关系，但是在样本、特征、模型上都有显著不同。在之前的文章中，我详细论述了二者在样本选择上的区别，这一节将论述二者在特征、模型上的区别。简言之，就是：排序鼓励交叉，召回要求解耦。
排序鼓励交叉
特征上，排序除了利用user feature(包括context)、item feature，最重要还使用了大量的交叉统计特征，比如“user tag与item tag的重合度”。这类交叉统计特征是衡量“user与item匹配性”的最强信号，但是也将user feature与item feature紧密耦合在一起。
模型上，排序一般将user feature、item feature、交叉统计特征拼接成一个大向量，喂入DNN，让三类特征通过多层全连接层（Fully Connection, FC）进行充分交叉。从第一层FC之后，你就已经无法分辨，FC的输出中哪些属于user信息？哪些属于item信息？
召回要求解耦
排序之所以允许、鼓励交叉，还是因为它的候选集比较小，最多不过几千个。换成召回那样，要面对百万、千万级别的海量候选item，如果让每个user与每个候选item都计算交叉统计特征，都过一遍DNN那样的复杂操作，是无论如何也无法满足线上的实时性要求的。所以，召回要求解耦、隔离user与item特征。
特征上，尽管信号强，但是召回不允许使用“交叉统计特征”。（放弃这么强的信号，的确可惜。如何在不使用交叉统计特征的情况下，仍然达到使用了它们的效果？有一种方法是使用蒸馏，详情见《Privileged Features Distillation at Taobao Recommendations》）
模型上，禁止user feature与item feature出现DNN那样的多层交叉，二者必须独立发展，i.e., user子模型，利用user特征，生成user embedding；item子模型，利用item特征，生成item embedding。唯一一次user与item的交叉，只允许出现在最后拿user embedding与item embedding做点积计算匹配得分的时候。
只有这样，才能允许我们
离线时，在user未知的情况下，独立生成item embedding灌入faiss；
在线时，能独立生成user embedding，避免与每个候选item进行“计算交叉特征”和“通过DNN”这样复杂耗时的操作
