作者：張榮華
先說一說問題，不知道大家有沒有這樣的經驗，反正我是經常碰到。
舉例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基本就可以實現以上推薦系統。
