1樓：
僅針對原題回答：為什麼大多都用各種加權的pooling，而不做concat操作？
主要就是因為快。
舉個例子：特徵的embeddingSize是32，現在所有Field的個數是35，其中5個Field是序列形式的特徵（對於序列長度的上限取30）。此時你有兩種處理方式：
a.用mean/sum pooling，那麼embedding層的參數量是32 * 35 = 1120
b.用concat，那麼embedding層的參數量是32*(35-5) + 30*5 = 2460
embedding層的參數量直接漲了120%左右，實際ctr/cvr的模型，參數量最大的很有可能是embedding -> MLP的這一層，所以concat一下會直接拖慢線上inference的速度。
2樓：
按時間順序拼接送入mlp，不是不可以。和pool相比，優點是可以更好的考慮時間順序，缺點是序列比較長的話，mlp的引數會比較多，對資料量的要求比較高，否則很容易過擬合，而pool就好很多。
3樓：徐森海
做拼接首先就是序列長度需要找個方式控制，其實就是mlp的輸入會太大。還有乙個問題就是mlp無法是無法控制序列順序變化帶來的影響。
4樓：
問題快涼了，提供乙個角度。
行為序列做拼接，相比做pooling，DNN的輸入向量維度會增大多倍，DNN的引數數量也會增加若干倍，計算複雜度也會增加。
5樓：爽如此
我的看法是，這種做法基本不可能比pooling更好。
1,長度問題。要做拼接然後進mlp那肯定要保證長度一致，無非是截長補短的做法，截長會丟資訊，補短會導致被補的部分可能學不充分。比如說乙個使用者行為序列，可能平均長度是20，中位數是15，如果長度固定為20，那超過20的很多有效資訊會被丟掉，而15到20之間因為大量的都是預設值，也無法學好；
2,位置問題。這個問題更加致命，因為直接拼接相當於是加了乙個正無窮強的位置資訊，例如乙個使用者的行為序列是a,b,c，另乙個序列是c,b,a。這倆是非常相似的，但是因為embedding輸入mlp的位置是固定的，那對模型來說這倆就是完全不一樣的了。
6樓：王海岩
本質原因在於每個使用者的歷史序列長度是不同的，如果拼接的話只能首先固定歷史序列長度，對於歷史序列較短的樣本添0補全，效果不會好
CTR預估模型有怎樣的發展規律？
天雨粟 從上往下，代表了整個CTR預估的發展趨勢 LR的主要限制在於需要大量手動特徵工程來間接提高模型表達，此時出現了兩個發展方向 以FM為代表的端到端的隱向量學習方式，通過embedding來學習二階交叉特徵 以GBDT LR為代表的兩階段模型，第一階段利用樹模型優勢自動化提取高階特徵交叉，第二階...
推薦系統或者ctr預估中，如何區分或者如何定義高頻低頻特徵 有通用的閾值區分嗎？
失落的薩特 問題中的頻率的定義是什麼。比如在樣本中出現的次數？特徵非空非零值的覆蓋度？還是對於正負樣本的區分度？比如實際情況會考慮的，乙個是特徵的覆蓋度，即非空非零的樣本比例，如果覆蓋度太低那麼這個特徵對於大部分樣本的學習沒有任何幫助 乙個是這個特徵的區分度，即這個特徵能不能把待排序的樣本區分開來。...
CTR和推薦演算法有什麼本質區別？
慕雲 回答一下召回存在的必要性吧。如你所想，如果排序演算法足夠強大，我認為不要召回也沒關係。但是現階段每乙個公司都必須要有召回這個階段，首先是排序演算法還沒能做到那麼強大，需要召回做乙個初篩的作用。另一方面是效能問題，對於較大資料量，直接排序效能問題無法攻克。再然後是召回不單單是常規的協同，矩陣分解...