關於資料採礦推薦系統實現

作者：張榮華

先說一說問題，不知道大家有沒有這樣的經驗，反正我是經常碰到。

舉例1，某些網站每隔幾天就發郵件給我，每次發的郵件內容都是一些我根本不感興趣的東西，我不甚其擾，對其深惡痛絕。
舉例2，添加具有某功能的一個msn機器人，每天都有幾次突然蹦出一個視窗，推薦一堆我根本不想知道的內容，煩不煩啊， 我只好將你阻止掉。

每一個觀眾只想看他感興趣的東西，而不是一下與之無關的事物，那麼如何才能知道觀眾的興趣所在呢，還是資料採礦，經過一番思考，終於有點思路，即根據使用者以往的瀏覽曆史來預測使用者將來的行為，也就是基於內容的推薦。
基於內容的推薦（Content-based Recommendation）是資訊過濾技術的延續與發展，它是建立在項目的內容資訊上作出推薦的，而不需要依據使用者對項目的評價意見，更多地需要用機器學習的方法從關於內容的特徵描述的案例中得到使用者的興趣資料。在基於內容的推薦系統中，項目或對象是通過相關的特徵的屬性來定義，系統基於使用者評價對象的特徵，學慣用戶的興趣，考察使用者資料與待預測項目的相匹配程度。使用者的資料模型取決於所用學習方法，常用的有決策樹、神經網路和基於向量的表示方法等。基於內容的使用者資料是需要有使用者的曆史資料，使用者資料模型可能隨著使用者的偏好改變而發生變化。

基於內容推薦方法的優點是：
1）不需要其它使用者的資料，沒有冷開始問題和稀疏問題。
2）能為具有特殊興趣愛好的使用者進行推薦。
3）能推薦新的或不是很流行的項目，沒有新項目問題。
4）通過列出推薦項目的內容特徵，可以解釋為什麼推薦那些項目。
5）已有比較好的技術，如關於分類學習方面的技術已相當成熟。

缺點是要求內容能容易抽取成有意義的特徵，要求特徵內容有良好的結構性，並且使用者的口味必須能夠用內容特徵形式來表達，不能顯式地得到其它使用者的判斷情況。

要實現內容推薦系統總體來說要經過4個大的步驟：
1 搜集資料，即搜集使用者的行為資料，其中也包括很多方法，根據我找到的資料與以往的經驗來看，web日誌可以作為我們的切入點，即我們的資料來源。

2 過濾資料，web日誌中有很多無用的資訊，我們要把這些無用的資訊排除掉，而且要區分出使用者和日誌資料之間的聯絡。

3 分析資料，利用分類聚類技術分析出這些日誌資料之間的關聯性，以及這些日誌資料和使用者之間的關聯性，這也是最重要的一步。

4 輸出結果。

有了這個思路之後，我們可以著手做第一步，即日誌資料的收集
我們知道，大多數的web伺服器都是有自己的日誌記錄的，比如說apache安裝之後有一個logs目錄，其中就有它的記錄檔，一般說來它有自己的一個格式，比如說：
1瀏覽器所在主機的 IP 位址(ip)； 2訪問日期和時間(date-time)；3客戶機與伺服器通訊所用的方法(methed，get or post)； 4客戶機請求訪問頁面的 URL； 5伺服器返回的狀態(status)； 6用戶端瀏覽器的類型；

但是這個記錄檔有一些不能克服的問題，或者我不知道如何克服，那麼我先說說我的疑問，首先，這個記錄檔中記錄的是ip地址，據瞭解，網路中有很多電腦的ip地址是相同的，因為他們在一個統一的路由後面，這個比例可能達到25%。那麼我們就無法根據ip地址來唯一確定一個使用者。其次，一般的web伺服器中都會用多個應用，那麼其他應用的訪問資訊對我們來說有可能是多餘的。再者，web伺服器的日誌形式比較單一，靈活性不大，可定製的餘地很小，在日誌資料中有效資料所佔的比例較小。還有，一些靜態檔案的請求也會被web伺服器記錄下來，比如說js檔案，css檔案，還有圖片檔案，等等這些東西對內容推薦來說都是無用的資源。

基於上面3點原因，我認為可以自訂日誌資料。為瞭解決使用者唯一性，我們讓應用為每一個瀏覽器產生一個clientId儲存在對應的瀏覽器上，這樣該瀏覽器只要訪問網站，我們就可以確定這個瀏覽器的唯一性，當然我們仍然不能確定瀏覽器使用者的唯一性，但是我們可以更進一步，如果瀏覽器的使用者登陸網站的話，我們就可以使用使用者id來確定使用者的唯一性，不過大多數網站使用者可能在使用網站的時候並不會登陸，我也是這樣，沒有關係，即使使用clientId問題也不會太大，隨著社會的發展，電腦的擁有量逐漸增加，一般來說一個人只會使用一台固定的電腦，在公司裡尤其是這樣。所以我認為clientId的方案是可行的，也許有人要問，別人的瀏覽器禁止了cookie怎麼辦，那麼我只能說沒有辦法，不過還好事實是絕大多數人都沒有這樣做。

接下來我們可以定義一下我們所需要的日誌資料的格式，比如這樣，
ip，clientId，userId，url，datetime，get or post等等。
這樣資料有效性會大大提高。

在得到較為有效資料之後，我們還需要對這些資料進行再次過濾：
1 去掉一些非內容的url，這些資料也是無效資料，這些非內容的url需要我們自己手工的統計出來，然後和日誌資料中的資料進行比對，將這些非內容資料從日誌資料中清除出去。
2 同時我們也需要把post請求從日誌資料中清除出去，或者我們在記錄日誌的時候根本不應該把post請求記錄下來。

經過以上步驟之後我們就可以開始第3個階段了，統計每個使用者的訪問的url，對這些url進行訪問，得到對應的html中所包含的資料，這些資料都是文本，將有用的文本提取出來，然後對這些有用的文本進行聚類。這樣就可以得到每個使用者喜歡的幾個類別。

聚類完成之後我們就可以開始分類了，即把最新的文章或者內容和對應的類別進行匹配，匹配成功之後，我們可以認為這個新文章或者內容可以推薦給對應的使用者。

問題：以上的流程只適用於沒有使用緩衝的系統，但是一般大型的網站都會使用varnish，squid等等，使用它們之後我們就無法得到使用者訪問的日誌資料了，所以如果使用了varnish或者squid，我們不得不再次面對web伺服器的日誌資料。

在不考慮varnish或者squid的情況下，使用lucene+jamon+htmlparse基本就可以實現以上推薦系統。