ctr預估演算法或者推薦系統中的排序演算法，目前的主流做法是embedding＋MLP，對於序列特徵，比如瀏覽或者點擊過的物品序列，除了採用pooling，比如求和，平均或者DIN的加權求和，可否對物品序列按照時間順序對embedding向量做拼接，作為MLP的輸入？

與pooling相比，優劣在哪？

說一個曾經看到的paper，原諒我忘了名字，之後記起來補上

具體做法是，把embedding向量拼接成矩陣，然後用TextCNN類似的方式做一維卷積，應該類似於題主說的拼接。

其實所謂的拼接，就是想辦法不用序列建模而直接採用橫向或者縱向的拼接。題主想要用MLP(橫向拼接)，其實看看NLP裡面對於序列的處理，通常不會這麼做，一個是隱藏層參數太多，另一個位置信息不明顯(沒有序列性)，因為MLP既然全連接，那相鄰就沒有體現出來。

採用TextCNN的做法，既有一定的序列性，模型也比較輕，思路供參考。

直接拼接不如pooling簡單易控。序列的好文章：

Personalized Top-N Sequential Recommendation via Convolutional Sequence Embedding wsdm2018

A Simple Convolutional Generative Network for Next Item Recommendation wsdm2019

Modeling the Past and Future Contexts for Session-based Recommendation

跑個題，為啥直接送MLP。一般MLP效果都不好啊，沒有考慮直接特徵交叉行為。也有一些文章指出來這個問題。FFM、XdeepFM 更好用吧。

Latent Cross: Making Use of Context in Recurrent Recommender Systems

按時間順序拼接送入mlp，不是不可以。和pool相比，優點是可以更好的考慮時間順序，缺點是序列比較長的話，mlp的參數會比較多，對數據量的要求比較高，否則很容易過擬合，而pool就好很多。

提供個思路。

我們之前在做用戶安裝和點擊app信息時候做過序列embedding，思路就是把用戶最近一段時間的app embedding喂進lstm，最後拿lstm 最後timestep下的hidden state做序列embedding

問題快涼了，提供一個角度。

行為序列做拼接，相比做pooling，DNN的輸入向量維度會增大多倍，DNN的參數數量也會增加若干倍，計算複雜度也會增加。

我的看法是，這種做法基本不可能比pooling更好。

1,長度問題。要做拼接然後進mlp那肯定要保證長度一致，無非是截長補短的做法，截長會丟信息，補短會導致被補的部分可能學不充分。比如說一個用戶行為序列，可能平均長度是20，中位數是15，如果長度固定為20，那超過20的很多有效信息會被丟掉，而15到20之間因為大量的都是默認值，也無法學好；

2,位置問題。這個問題更加致命，因為直接拼接相當於是加了一個正無窮強的位置信息，例如一個用戶的行為序列是a,b,c，另一個序列是c,b,a。這倆是非常相似的，但是因為embedding輸入mlp的位置是固定的，那對模型來說這倆就是完全不一樣的了。

本質原因在於每個用戶的歷史序列長度是不同的，如果拼接的話只能首先固定歷史序列長度，對於歷史序列較短的樣本添0補全，效果不會好

做拼接首先就是序列長度需要找個方式控制，其實就是mlp的輸入會太大。還有一個問題就是mlp無法是無法控制序列順序變化帶來的影響。

推薦閱讀：
相關文章