1樓：慕雲
回答一下召回存在的必要性吧。
如你所想，如果排序演算法足夠強大，我認為不要召回也沒關係。
但是現階段每乙個公司都必須要有召回這個階段，首先是排序演算法還沒能做到那麼強大，需要召回做乙個初篩的作用。另一方面是效能問題，對於較大資料量，直接排序效能問題無法攻克。再然後是召回不單單是常規的協同，矩陣分解等，還要包括冷啟動等等很多很多問題這都是排序模型很難解決的。
2樓：熊貓
關於本質區別，很多人已經回答了，我就不贅述了。
只回答下面一點。
「如果系統有能力對所有商品打分，是不是就不需要召回了？」
對於推薦系統來說，召回的特點是效率高，排序的特點是精準所以這裡需要加乙個時間限制，業內的推薦系統通常在600ms內返回給使用者推薦列表，也就是最長1s內實現打分所有商品，截斷返回，如果能做到，相當於排序具備了召回的高效率，我覺得可以不需要召回。
如果召回能做到非常精準，同樣不需要排序。
工業場景下，商品數量應該是千萬級
同樣，搜尋場景也有一樣的情況
3樓：phase
使用者滿意視角：怎麼建模使用者體驗進而影響留存？這是乙個session至少是pagewise的目標，由此引發出的多樣性、驚喜性（興趣探索流轉機制）等問題就遠不是乙個ctr預估能搞定的問題，當然業內也有很多就是通過ctr+打散來搞的
平台滿意視角：通常電商場景更看重轉化效率（點多少買多少）使用者意圖也更明確，所以可能更接近ctr（cvr）的任務，但是內容推薦的場景通常沒那麼看重ctr而是看重留存和時長，所以平台的視角更接近讓使用者滿意的視角，問題就更複雜了
4樓：sanoka
推薦系統的一般包括召回->排序->重排幾個階段，CTR預估就是排序階段的主要任務，而一般常說的推薦演算法如協同過濾、矩陣分解等都是對應到召回階段的策略。
之所以有召回階段主要是由於算力的限制，以及線上對響應延遲的要求，一般可推薦Item集合可能是百萬、千萬甚至是上億級的，對所有Item進行CTR預估不現實。召回階段即是從所有Item庫中先篩選出千級或萬級別的Item候選，然後送去排序模型進行打分，如果排序模型過於複雜或召回Item量過大，往往還會再分為粗排和精排兩個階段，粗排一般是比較簡單的線性模型（如LR），精排為較複雜的深度模型，通過粗排進一步縮小候選集到精排模型進行打分。
5樓：
ctr預估只是推薦系統中的一環。
一般推薦系統包括召回，精排（ctr預估），rerank（機制策略）。召回和精排的打分集合是不一樣的。召回針對的是全部item，而精排針對的是召回輸出的item。
因此召回一般是在全部item集合上構建訓練樣本，而精排一般是基於展現樣本來構建訓練樣本，而這部分樣本本身是有偏的。即使精排有能力對全體item進行打分，由於只基於展現樣本訓練，對於沒有展現過的item，預估會有偏差，可能會有問題。因此現階段需要依賴召回通過各種召回方式來對item進行過濾篩選。
但是後面算力足夠了，這個問題是不是就不能解了呢？我覺得未必不能解。只不過在算力還沒達到的時候，大家的精力暫時不在這個地方。
另外推薦系統的排序目標一般是多種多樣的，以阿里電商推薦為例，乙個主要排序目標是gmv（ctr×cvr×price），同時要兼顧使用者體驗，考慮多樣性等指標，這些僅僅靠乙個ctr預估模型是無法做到的。
大林演算法與PID演算法有什麼本質區別
李崇 應某總的要求 施法前搖 試著回答一下此問題。先說結論，兩者最初的思路完全不同，我不知道為啥會有人會問這個問題，有相似之處嗎？大林法是針對純滯後系統的乙個控制演算法，思路上比較接近使用參考模型 我後面會具體解釋的。pid我相信大家都很了解了，只說一句，pid的兩個零點也會對系統的純延遲起到很好的...
麵包和餅有什麼本質區別麼？
夏靈素 麵包有很多種，餅有更多種。所以為了簡單起見，就只比較用來做漢堡的白麵包和用來做肉夾饃的白吉饃吧。最直白的區別就是，麵包是烤箱拷出來的，而白吉饃是炕出來的。不知道大家有沒有看過那種肉夾饃小攤子，肉夾饃是放在下面那個很大的爐灶裡面炕出來的。其實家裡做的話，用平底鍋就行了。至於製作材料的話 麵包的...
投資和投機有哪些本質區別？
先說結論，沒有區別。不管是投資也好，投機也好，這個行為叫什麼不重要，但是做出這個行動的目的，肯定是有預期回報的。既然有預期回報希望通過這乙個行為來獲利，那麼這個行為叫什麼不重要。結果才重要。不要回報的叫做慈善。 9D投機 投資就是投機的馬甲或牌坊，屌絲瞬間高大上的套詞。些微的區別就是投資一般具有長期...