mahout in Action2.2-給用戶推薦圖書（3）-評價推薦系統
推薦系統引擎是一個工具，一種回答問題的手段，“對用戶來講什么是最好的推薦？”，在研究回答的前先研究一下這個問題。一個好的推薦的準確含義是什么？如何知道推薦系統是如何生成推薦的？下面的章節將探索推薦系統的評價，在尋找特定推薦系統時，這將是一個有用的工具。
最好的推薦系統是心理學的范疇，有人在你做事情之前知道確切的知道你還沒有看過的、或者沒有任何現象說明你喜歡的一些item，以及你對這些item的喜歡程度。
大部分的推薦引擎通過給item評價打分來實現。所以，評價推薦引擎的一種方式是評價它的評估偏好值的質量 —評價評估偏好和實際偏好的匹配度。
2.3.1 訓練集和打分
“真實偏好”并不充分，沒有人會知道你將來是否會喜歡一些新的item。推薦引擎可以通過設置一部分真實數據作為測試數據。這些測試數據偏好在訓練集中并不展示偏好值 —要求推薦系統對這些缺少偏好值的數據作出評估，并比較和實際值的差距。
對于推薦系統產生一系列打分是很簡單的。例如，計算評估值和實際值之間的平均距離，在這種方法下，分值越低越好。0.0表示非常好的評估 — 評估值和實際值根本沒有差距。
均方根（root-mean-square）也是一種方法，也是分值越低越好。
上面的表中展示了實際偏好度和評估偏好度集合的不同值，以及如何將它們轉化為打分。均方根能比較重的處罰距離遠的，例如item2，這是基于某種考慮在內的。因為平均距離容易理解，接下來的示例將使用它作為評估方法。
2.3.1 運行RecommenderEvaluator
下面是代碼示例：
大部分的操作發生在evaluate()這個方法中。內部，RecommenderEvaluator將數據劃分為訓練集和測試集，創建一個新的訓練DataModel和推薦引擎測試，比價評估結果和實際結果。
注意，沒有將Recommender傳給方法，這是因為在其內部，將基于創建的訓練集的DataModel創建一個Recommender。所以調用者必須提供一個RecommenderBuilder對象用于從DataModel創建Recommender。
2.3.3 評估結果
程序打印出了評估結果：一個表明推薦系統表現如何的打分。在這種情況下你能看到很簡單的1.0。盡管評價器內部有很多隨機方法去選擇測試數據， 結果可能是一致的因為RandomUtils.useTestSeed()的使用，每次選取的隨機數都一樣。這只用于示例、單元測試來保證重復的結果。不 要在真是數據上用它。
AverageAbsoluteDifferenceRecommenderEvaluator
基于AverageAbsoluteDifferenceRecommenderEvaluator實現，得到的這個值是什么含義？1.0意味著，平均意義上，推薦系統評估偏好和實際偏好的的距離是1.0.
1.0早1-5規模上并不大，但是我們的數據太少。如果數據集被隨機劃分結果可能不一樣，因此訓練、測試數據集可能每次跑都不一樣。
這種技術可以應用于任何Recommender和DataModel。使用均方根打分的實現類RMSRecommenderEvaluator
替代AverageAbsoluteDifferenceRecommenderEvaluator。
evaluate()的null參數是DataModelBuilder的實例，用于控制訓練DataModel是如何從訓練數據上建立的。正 常情況下默認就好，如果需要，可以使用特別實現的DataModel。DataModelBuilder用于將DataModel注入評價過程中。
參數1.0表示使用整個數據集的比例。這樣用于產生一個很快的、可能精度低一些的評價方式。例如，0.1可能意味著用數據集的10%，忽略其他90%。這對于快速檢測到Recommender的細微變化是非常有用的。
2.4 評估準確率和召回率
借用更普遍的看法，我們接收經典的信息檢索矩陣去評價推薦系統：準確率和召回率。這些是用于搜索引擎的術語，通過query從眾多可能結果中返回最好結果集。
一個搜索引擎不應該在靠前的結果中返回不相關的搜索結果，即使他致力于得到盡可能多的相關結果。”準確率”是指在靠前的結果中相關結果所占的比 例，當然這種相關是某種程度上我們定義的相關。”precision at 10″應該是從前10個結果中判斷得到的準確率。“召回率”靠前的結果中相關結果占的比例。看圖2.3可以有一些直觀的概念。
這些術語也可以應用到推薦系統中：準確率是靠前的推薦中好的推薦所占的比例，召回率是指出現在靠前推薦中好的推薦占整個好的推薦的比例。
2.4.1 運行RecommenderIRStatsEvaluator
Mahout提供了非常簡單的方式為推薦系統計算結果。
2.5 評價GroupLen數據集
有了這些工具在手，我們不僅可以考慮速度，還要考慮推薦系統的效率。盡管大量數據集的例子還在幾章以后，小數據集上評價性能已成為可能。
2.5.1 抽取推薦系統輸入
GroupLens (http://grouplens.org/)是一個研究型的項目。提供了很多不同大小的數據集。每個都是用戶對電影打分的真實數據。這是幾個大的真實可用數據集之一，更多的將會在本書后續探尋。從GroupLens網站上下載“100K data set”,http://www.grouplens.org/node/73.解壓下載文件，在解壓后后，有一個叫ua.base的文件。該件tab分割user IDs, item IDs, ratings（偏好值）和其他信息。
這個文件能使用嗎？Tabs, 不是逗號，分隔字段，在每行結尾還有一個額外的字段。答案是肯定的。該文件可以類似FileDataModel的讀取。回到前面列表2.3，試著用 ua.base的路徑代替小文件路徑。重新跑一遍數據。這時，評估可能需要幾分鐘，因為數據量是100k。
最后，你應該得到一個大約0.9的值。這不算壞，盡管值幾乎分布在1-5區間內，聽起來還不錯。可能特殊的推薦系統對這種類型的數據來講是不完全的？
2.5.2 其他推薦系統實驗
在這個數據集上測試“slope-one” ，一個簡單的算法，在后面的章節中會講到。很容易替換RecommenderBuilder，使用 org.apache.mahout.cf.taste.impl.recommender.slopeone.SlopeOneRecommeder, 像這樣：
運行評價方法。你應該發現它很快，得到一個大約是0.748的值。正朝好的方向發展。
這并不能說明slope-one算法總是很快、很好。在給定數據集上，每一個算法都有自己的特性和屬性，這些屬性很難去檢測出來。例 如，slope-one算法運行時能夠很快的計算推薦過程，但是它需要在計算前需要花費很大一部分時間構建內部數據結構。基于用戶的推薦引擎，能夠在其他 數據集上擁有很快的計算速度和更高的準確度，我們將在第四章探索各種算法的優點。
2.6 總結
在這一章我們介紹了推薦引擎的思想。我們創建了一些簡單的Mahout Recommender的輸入，運行一個簡單計算，然后輸出結果。
然后，我們花時間介紹了推薦引擎系統的數據結果的質量評價，因為接下來的章節會頻繁用到。這一章包含了評價推薦引擎的準確性，像傳統的準確性和召回率。最后，我們嘗試去評價GroupLens的真實數據集，觀察如何將評價結果用于推薦引擎的性能提升上。
在我們繼續詳細學推薦引擎之前，需要花一些時間去了解另一個Mahout中推薦系統的基本概念：數據表示。接下來一章會著重講這一點。