2.2 創建一個推薦器
推薦引擎室一個工具，一種回答問題的方法，“對一個用戶而言，什麼是最好的推薦呢？”在研究答案以前，最好是要先調查下問題。究竟什麼纔是真正的一個好的推薦引擎？當一個推薦引擎產出時我們怎麼才能知道？本章之後的內容主要挖掘怎樣構建一個推薦器，因爲這在研究特定的推薦系統時會相當有用。
可能的最好的推薦器會是一種通靈物，他可以奇蹟般清楚地知道對於每一個可能的物品你喜歡到什麼程度，在你還沒看到它們或者是還沒表露出對它們的任何偏好。可以準確地預測你所有的偏好的一個推薦器會展示出所有的商品，它們將按你將來的或者已經存在的偏好來排序。以上所說的就是可能的最好的推薦器了。
事實上，大多數的推薦引擎運行起來只是嘗試做這些事情，它們通過估計一些或者所有其他的商品評分等級。因此，一種計算出推薦器的推薦的方法是計算它所估計的產品偏好的質量——即通過算出估計偏好與實際偏好的匹配情況。
2.3.1 訓練數據和評分
但是，那些實際偏好並不存在。沒有人確定知道在將來你會不會喜歡某個新的產品（包括你自己）。在推薦引擎的上下文中，這可以採用分離真實數據集中的一部分並作爲測試數據集來模擬實現。計算時這部分測試用的偏好數據並不作爲訓練數據給到推薦器。相反，訓練出來的推薦器要被用來評估對缺失的測試數據集的偏好，且評估結果要與真實值進行比較。
以上的做法就可以很容易地生成對一個特定推薦器的分數。例如，可以計算推薦器的評估值和真實偏好之間的差平均。利用類似這類的分數，越低越好，因爲這就意味着評估結果與真實偏好越接近。一個0.0的分數就意味着完美的估計——評估值與真實值相同。
有時會採用差值的均方根（root-mean-square）來衡量真實值和估計值之間的差距。均方根的公式都知道了，不貼了。
2.3.2 運行RecommenderEvaluator
代碼下利用RecommenderEvaluator計算推薦分數，貼代碼：
沒有Recommender對象傳入evaluate方法，因爲在evaluate方法中會用新創建的訓練數據模型對象DataModel，調用者需要提供一個可以構建Recommender對象的Object——一個RecommenderEvaluator對象。
2.3.3 結果評估
程序輸入推薦系統的最終分數。結果肯定是1.0，因爲RandomUtils.useTestSeed()會強制使用相同的隨機取值。AverageAbsoluteDifferenceRecommenderEvaluator類決定了最後的分數的意義，在這裏它表示推薦器的推薦結果偏離真實偏好的平均值是1.0。若要使用均方根，使用RMSRecommenderEvaluator .
null參數表示的是一個DataModelBuilder實例，它控制着怎樣由訓練數據集轉化爲訓練的DataModel對象。一般默認的就ok。如果要在你的程序中定製DataModel的實現，那麼可能需要使用它。
1.0參數表示的是使用100%的輸入數據進行計算，如果是在一個可能巨大數據集的情況下，可以在要更快地得到推薦結果（不是那麼準確）時調整數數值（例如，0.1）。
2.4 計算precision和recall
我們也可以從更寬泛的角度看待推薦問題：爲了要生成推薦結果，並不嚴格要求估計偏好值。在許多案例中，從好到差展示出一個推薦列表已經足夠了，而並不需要包含估計的偏好值。而在其他的一些例子中，精確順序的結果列表並不怎麼要緊——得到一個好的推薦結果集就是好的。
這種更一般的視角，我們也可以採用經典信息獲取度量來計算推薦：precision以及recall。這兩個準則也被應用在例如搜索引擎（從很多可能的結果中返回與一個查詢匹配的最好結果集）等度量中。
Precision表示top結果中與查詢相關的比例，在給定相關的定義下。
Recall表示top結果中的與查詢相關的結果在所有相關結果中的佔比。
把查詢換成推薦就應用到了推薦系統中了。
2.4.1 運行RecommenderIRStatsEvaluator
threshold = μ + s 作爲默認的衡量推薦好壞標準
以105爲例，講解整個推薦過程，以及StatsEvaluator如何選擇自認爲是good的推薦的。
2.4.2 precision和recall存在的問題
precision和recall在推薦系統的使用是否有效依賴於對好的推薦的定義。
例子1： 從用戶已經做過偏好的項目中選擇進行推薦
例子2： 當偏好值是布爾類型時更復雜，推薦器只能隨機地從喜歡的項目中選幾個作爲推薦了
需要知道測試的侷限性
2.5 實例講解：計算GroupLens數據集