使用項目相似性hadoop工作的基於預計算項目相似性的基於可伸縮實時項目的mahout推薦器？

Question

我具有以下設置：

布爾數據：（用戶ID，項ID）

hadoop的基於象夫itemSimilarityJob與以下arguements： --similarityClassname Similarity_Loglikelihood --maxSimilaritiesPerItem 50 &他人（輸入，輸出.. ）

項目基於布爾推薦： -model MySqlBooleanPrefJDBCDataModel -similarity MySQLJDBCInMemoryItemSimilarity -candidatestrategy AllSimilarItemsCandidateItemsStrat埃及 -mostSimilarItemsCandidateStrategy AllSimilarItemsCandidateItemsStrategy

1. 有沒有使用相似cooccurence在我的設置來獲得最終建議的方法嗎？如果我在作業中插入SIMILARITY_COOCCENCE，則MySqlJDBCInMemorySimilarity前提條件檢查失敗，因爲計數變得大於1.我知道，通過針對預計算相似度運行推薦器作業，我可以得到最終的建議。有沒有辦法使用api實時使用api，如使用MysqlInMemorySimilarity的相似性對數似然性（以及其他相似性度量，其相似度值在-1 & 1之間）？

2. 我們該如何限制最大數量。項目相似性工作中的每件商品的類似商品。我的意思是，所有類似的令人高興的事情都要求所有可能的候選人都有類似的項目（項目）。有沒有一種方法可以說明使用API​​的10/20/50類似項目。我知道我們可以將一個--maxSimilaritiesPerItem傳遞給項目相似度工作，但我不完全確定代表什麼以及它是如何工作的。如果我將此設置爲10/20/50，我是否能夠達到上述要求。也有辦法通過api完成這個嗎？

3. 我正在使用rescorer過濾出並重新編寫最終建議。使用rescorer，與/ similar/itemid？howMany = 10 & rescore {..}的呼叫正在變得更長（300ms-400ms），與（推薦/ userid/how/30-70毫秒）沒有rescorer。我使用redis作爲內存存儲來獲取rescore數據。如上所示，rescorer還會收到一些運行時數據。在rescorer中只會發生一些檢查。問題是，因爲沒有。的特定用戶的項目偏好增加（> 100），否則。的調用isFiltered（）& rescore（）大量增加。這主要是因爲，對於每個用戶首​​選項，對candidateStrategy.getCandidatItems（item）的調用都返回（100+）類似的項目，併爲每個項目調用rescorer。因此需要限制作業中每個項目的最大數量的相似項目。這是正確的還是我錯過了什麼？在這種情況下優化rescorer的最佳方式是什麼？

的MysqlJdbcInMemorySimilarity使用GenericItemSimilarity加載項目的相似性在memeory及其.allsimilaritems（項目）返回從在MySQL預先計算的項相似性的給定項目的所有可能的類似的產品。我是否需要實現自己的物品相似類才能返回前10/20/50類似物品。那麼如果用戶的不是。的偏好繼續增長？

如果有人能告訴我如何實現上述目標，這將是非常好的嗎？感謝堆！

Answer 1

你指的是什麼先決條件檢查？我沒有看到他們;我不確定相似性是否實際上被禁止> 1。但是您似乎在問是否可以創建一個僅返回共現的相似性函數，作爲未與Hadoop一起使用的ItemSimilarity。是的你可以;它在項目中不存在。我不會建議這個; LogLikelihoodSimilarity將會更聰明。

你需要一個不同的CandidateItemStrategy，特別是看看SamplingCandidateItemsStrategy及其javadoc。但這與Hadoop無關，而與運行時元素無關，而且您提到了Hadoop作業的標誌。這不是一回事。

如果rescoring很慢，那就意味着，IDRescorer慢了。它被調用了很多次，所以您肯定需要將所有查找數據緩存在內存中。但是，減少每個上面的候選人數量也會減少這個被調用的次數。

不，不要實現你自己的相似性。您的問題不是相似性度量，而是考慮了多少項作爲候選項。

我是你所談論的很多代碼的作者。我認爲你正在努力解決大多數人在嘗試大規模地進行基於項目的工作時碰到的問題。您可以進行足夠的採樣和調整。

但是，我正在將一項新開發納入一個名爲Myrrix的不同項目和公司，該公司正在開發一種基於相同API的'下一代'推薦器，但應該在沒有這些複雜因素的情況下進行擴展，因爲它基於矩陣因式分解。如果您有時間和興趣，我強烈建議您看看Myrrix。相同的API，實時服務層是自由/開放的，並且基於Hadoop的計算層也可用於測試。