最近我在完成一個旅遊個性化推薦系統的設計，裡面用到的關聯規則和一些協同過濾演算法，目前是用weka在做測試，有沒有對此比較熟悉的朋友？

01-09

旅遊個性化推薦系統主要是模擬實現目前網上音樂、電影、書籍等相關產品推薦，但旅遊屬性多而複雜，普通數據挖掘演算法很難實現，weka有個問題就是與前台沒有對接介面，還有就是vogoo這類推薦引擎用到旅遊推薦方面有沒有作用？

對weka和vogoo都不太懂，嘗試講點小看法。

在考慮引入推薦系統時，演算法往往時最後考慮的，首先需要琢磨的是：

為什麼需要推薦系統，他解決什麼問題？
產品特點、現有數據、用戶習慣，是否適合來做推薦？適合做什麼樣的推薦？

具體到旅遊領域，記得豆瓣的胖子同學在一個slide裡面說過，他們嘗試做旅遊推薦的效果不佳，因為用戶的消費成本非常高影響決策原因很多，後來證明不是太成功——也判斷類似於書籍這樣的推薦在旅遊上面很難做。

在我看來，旅遊相關的決策問題其實很多，除了去哪兒以外，還有吃住行遊方方面面，未必沒有可做的空間；關鍵還是在於產品的定位吧，推薦系統也未必是最好的形式。

1註冊信息（sex，age，career，grade，place，nationhobby三方歷史行為數據）、專家引薦、同品引薦

2提供一些旅遊地點，讓用戶反饋他們對這些物品的興趣，然後根據用戶反饋給個推，如評分

前置條件：熱門、小眾化、多覆蓋

3推新品：猜你喜歡（itemcf）、和你一樣的去過（usercf）、允許用戶打標籤，其中打標籤有步驟

step1標籤種類

表明物品是什麼如是一隻鳥，就會有「鳥」這個詞的標籤
表明物品的種類如表示一個網頁類別的標籤包括 article）、 blog、 book等。
表明物品擁有者如博客的標籤中會包括博客的作者等信息。
表達用戶觀點如用戶認為網頁很有趣，會標funny，認為很無聊，會上boring。
用戶相關的如 my favorite（我最喜歡的）、my comment（我的評論）等。
用戶的任務如 to read（即將閱讀）、job search（找工作）等。
類型主要表示這個電視劇的類別，

時間主要包括電視劇發布的時間，有時也包括電視劇中事件發生的時間
人物主要包括電視劇的導演、演員和劇中重要人物等。
地點劇情發生的地點，或者視頻拍攝的地點等。
語言這部電視劇使用的語言。
獎項這部電視劇獲得的相關獎項。
其他包含不能歸類到上面各類中的其他所有標籤。

step2標籤清理/標籤反饋

去除詞頻很高的停止詞；
去除因詞根不同造成的同義詞，比如 recommender system和recommendation system，
去除因分隔符造成的同義詞，比如 collaborative_filtering和collaborative-filtering）

4利用用戶訪問推薦系統的時間、地點、心情等，如商城衣物季節、lbs、音樂推薦

5推薦系統架構

如果覺得weka性能有問題，可以考慮試試mahout，提供了基於hadoop實現的CF和關聯規則等演算法。

4推薦有很多方法，從簡單到複雜，規則到演算法。不同場景有不同的處理方法，例如列表頁使用用戶profile，詳情頁使用當前景區屬性等。推薦一般都有個baseline，例如熱門，同價位熱門，同地域熱門，加一些規則是baseline。然後你可以上關聯規則，不要拘泥於書本的演算法就照搬，大數據量不一定適合，例如你利用統計可以算出兩個景區的關聯度同樣也能達到關聯規則的效果。協同過濾你可以用weka，演算法簡單，也可以自己實現。一般都是離線計算好結果導入緩存，線上推薦時直接讀取。然後你可以考慮協同過濾計算慢，更新慢的話推薦效果就大打折扣，此時你可以考慮實現一個增量協同過濾，例如實時接入用戶點擊流，實時更新每個用戶的推薦結果列表。然後你可以使用其他很多模型來計算離線推薦結果，不斷做AB測試比較效果。其實這些都只是推薦的一小部分，一般關鍵規則，熱門，協同過濾等模型的結果都只是推薦系統召回層的一部分，一般的做法是利用這些結果召回用戶的候選列表，然後利用模型（例如以用戶下單為目標，構建模型）對候選列表中的item做預估，將排序較高的推薦給用戶。

weka你可以離線跑出每個用戶的推薦結果，導入redis等緩存，開發一個http介面，輸入用戶id返回結果列表，給前端界面。

我也在研究通過用戶行為和相似度對比獲得用戶感興趣的旅行產品並推薦給對應的用戶，通過決策樹分析發現最大的因素莫過於強目的地需求和價格，在怎麼推他也不太會有太好的效果，到是可以研究研究這方面的東西，最近在研究歐吉米德、線性歸一以及概率分布等方面的東西，看看有沒有對於這塊有所幫助

看選擇哪些特徵，以及特徵如何處理吧。特徵之間的業務邏輯和數學邏輯也要考慮清楚，這部分要考業務理解程度。先要問自己一個問題：你或者你的團隊對旅遊的理解程度。理解程度靠積累也是可以的，但這又涉及數據源和處理方法的積累。

至於演算法，其實倒在其次。從數學角度講，只看抽象的數學關係。這樣其實可以用的公式是非常豐富的。

本人做運營商和銀行的精準營銷的設計，歡迎交流。

weka不一定提供了前台介面，但一定可以通過做.bat腳本調用weka的jar包，再調用.bat腳本做動態調用，其實還是很方便的。

以前項目中用過weka的關聯規則，感覺在性能方面還是難以滿足實際需求，關聯規則並不難實現，可以考慮下自己寫一個，不僅效率方面好一些，另外在介面以及後期擴展等方面也更靈活和方便。