簡介基于協(xié)同過濾算法的Java電影推薦系統(tǒng)源碼面向Java開發(fā)者、電影類流媒體平臺及相關(guān)專業(yè)學(xué)習(xí)者。系統(tǒng)通過分析用戶歷史行為數(shù)據(jù)提取偏好特征并智能推薦符合口味的電影適合課程設(shè)計、畢業(yè)設(shè)計參考或二次開發(fā)起點。壓縮包共76個文件包括38個Java源文件、15個JSP頁面、10個XML配置、2個SQL腳本及JS、CSS等業(yè)務(wù)邏輯、頁面展示與數(shù)據(jù)庫腳本分層存放整體結(jié)構(gòu)清晰壓縮包大小僅1.1MB下載部署輕量。目前已有823人學(xué)習(xí)/下載受到開發(fā)者關(guān)注。源碼可直接導(dǎo)入常見IDE運(yùn)行配合SQL腳本快速初始化數(shù)據(jù)庫幫助理解協(xié)同過濾算法從評分矩陣構(gòu)建、相似度計算到TopN推薦的完整落地過程同時可借鑒JSPServlet風(fēng)格的Web分層設(shè)計、數(shù)據(jù)訪問與接口組織方式是JavaWeb與推薦系統(tǒng)入門及項目實戰(zhàn)的高性價比參考。1. 基于協(xié)同過濾算法的Java電影推薦系統(tǒng)源碼它解決什么問題值不值得照著做你手頭有一個電影站的后臺每天進(jìn)來幾千用戶留下幾萬條點擊和打分但首頁只能按時間或熱度排運(yùn)營問你“能不能給每個人推不一樣的電影”。這個標(biāo)題給的就是一條能直接落地的路線基于協(xié)同過濾算法的Java電影推薦系統(tǒng)源碼從數(shù)據(jù)表設(shè)計、相似度計算到Top-N推薦接口全部用Java技術(shù)棧實現(xiàn)不依賴Python服務(wù)、不引入Spark一臺普通服務(wù)器加MySQL就能跑起來。它適合三類人做Java課程設(shè)計和畢業(yè)設(shè)計的學(xué)生接私活需要快速交付推薦模塊的工程師以及正在刷java基礎(chǔ)面經(jīng)、隨時可能被問到“協(xié)同過濾怎么算、缺點是什么”的求職者。后面我會拆成算法選型、數(shù)據(jù)建模、核心代碼、工程接口和踩坑記錄五塊每一步都能照著抄也能照著排錯。2. 協(xié)同過濾算法選型UserCF與ItemCF的取舍以及Java實現(xiàn)前的數(shù)據(jù)準(zhǔn)備協(xié)同過濾不是一種算法而是一族算法落地前如果選錯方向后面寫多少代碼都救不回來。這一章先解決兩個問題你的場景到底選UserCF還是ItemCF以及算法跑起來之前評分?jǐn)?shù)據(jù)應(yīng)該以什么形態(tài)裝進(jìn)Java內(nèi)存。2.1 UserCF還是ItemCF先看你的用戶量和電影量協(xié)同過濾分兩派基于用戶的UserCF和基于物品的ItemCF。UserCF先找出和你口味最接近的一批用戶再把這批用戶看過而你沒看過的電影推薦給你ItemCF反過來先算出電影和電影的相似度然后從你自己打過高分的電影出發(fā)找沒看過的相似片單。兩者數(shù)學(xué)上都在算相似度矩陣但適用場景差的非常多。我的經(jīng)驗是用戶量遠(yuǎn)大于物品量的場景UserCF會先崩。比如一個電影站有50萬注冊用戶、1萬部電影UserCF要算50萬乘以50萬的用戶相似度矩陣那就不叫推薦系統(tǒng)叫內(nèi)存殺手。反過來物品量遠(yuǎn)大于用戶量的場景ItemCF的物品相似度表同樣會爆炸。電影推薦的典型特征是物品穩(wěn)定、用戶量大業(yè)內(nèi)普遍首選ItemCF做主力UserCF用來做“和你口味相似的人也在看”這種社交化榜單兩個一起上也沒問題。在這套源碼里我會把兩個都實現(xiàn)通過配置文件切換默認(rèn)走ItemCF。這樣既方便交作業(yè)時講清選型理由也方便你拿同一份數(shù)據(jù)做對比實驗。還有兩個必調(diào)的參數(shù)相似度閾值和鄰居數(shù)K。我一般把“相似度低于0.1的鄰居直接扔掉”做成常量配置而不是散落在代碼里后面調(diào)參時只需要改配置文件不用重編譯。2.2 MovieLens數(shù)據(jù)集與Java實體建模從CSV到User-Rating矩陣推薦系統(tǒng)沒有數(shù)據(jù)就是空中樓閣最常見的做法是拿MovieLens開源數(shù)據(jù)集里面包含users、movies、ratings三個文件。ratings文件每行是“userId::movieId::rating::timestamp”評分是1到5的整數(shù)這個字段格式直接決定了Java代碼里怎么切分字符串。把這份數(shù)據(jù)映射成Java對象最少只需要兩個東西一個Rating實體類和一個能裝載整個評分矩陣的DataLoader。下面這段代碼先定義了Rating實體再用一個方法把CSV解析成嵌套Map。為什么用Map而不是二維數(shù)組假設(shè)1萬個用戶、1萬部電影稠密二維數(shù)組要開1億個格子double[][]占用約800MB內(nèi)存而真實評分記錄可能只有10萬條。稀疏Map只存放有的位置內(nèi)存占用能降一個數(shù)量級。public class Rating { private int userId; private int movieId; private double score; private long timestamp; public Rating(int userId, int movieId, double score, long timestamp) { this.userId userId; this.movieId movieId; this.score score; this.timestamp timestamp; } public int getUserId() { return userId; } public int getMovieId() { return movieId; } public double getScore() { return score; } public long getTimestamp() { return timestamp; } }public class DataLoader { public static MapInteger, MapInteger, Double loadRatings(String path) throws IOException { MapInteger, MapInteger, Double userItemMap new HashMap(); try (BufferedReader br new BufferedReader(new FileReader(path))) { String line; while ((line br.readLine()) ! null) { String[] fields; if (line.contains(::)) { fields line.split(::); } else { fields line.split(,); } if (fields.length 3) { continue; } try { int userId Integer.parseInt(fields[0]); int movieId Integer.parseInt(fields[1]); double score Double.parseDouble(fields[2]); userItemMap.computeIfAbsent(userId, k - new HashMap()).put(movieId, score); } catch (NumberFormatException e) { // 臟數(shù)據(jù)直接跳過真實環(huán)境不能因為一行壞數(shù)據(jù)掛掉整個加載過程 } } } return userItemMap; } }邏輯說明userItemMap的結(jié)構(gòu)是“用戶ID - (電影ID - 評分)”這是UserCF的輸入形態(tài)。關(guān)鍵方法是computeIfAbsent它是java基礎(chǔ)里很常用的Map操作等價于“key不存在就new一個HashMap放進(jìn)去存在就直接用”比先判斷再put的三行樣板代碼干凈得多。注意我在解析里同時兼容了雙冒號和逗號兩種分隔符因為MovieLens舊版用“::”新版改成了逗號寫死任何一種都會在換數(shù)據(jù)集時翻車。NumberFormatException的catch也是必須的爬蟲拉來的數(shù)據(jù)永遠(yuǎn)比你想象的臟。2.3 評分矩陣的存儲與加載為什么要轉(zhuǎn)置成ItemCF能用的結(jié)構(gòu)實際寫ItemCF時光有userItemMap還不夠因為它要回答“某部電影被哪些人評過分”這是userItemMap的反向關(guān)系。常見做法是啟動時做一次轉(zhuǎn)置生成itemUserMap結(jié)構(gòu)是“電影ID - (用戶ID - 評分)”內(nèi)存開銷比再讀一遍文件要小。public class DataLoader { public static MapInteger, MapInteger, Double transpose( MapInteger, MapInteger, Double userItemMap) { MapInteger, MapInteger, Double itemUserMap new HashMap(); for (Map.EntryInteger, MapInteger, Double userEntry : userItemMap.entrySet()) { int userId userEntry.getKey(); MapInteger, Double items userEntry.getValue(); for (Map.EntryInteger, Double itemEntry : items.entrySet()) { int movieId itemEntry.getKey(); double score itemEntry.getValue(); itemUserMap.computeIfAbsent(movieId, k - new HashMap()).put(userId, score); } } return itemUserMap; } }參數(shù)說明這段是純循環(huán)遍歷不依賴任何框架用Java 8的forEach也能寫但傳統(tǒng)的for在這種雙重遍歷下可讀性更好。轉(zhuǎn)置完以后ItemCF的相似度計算只需要把itemUserMap里的兩個value取出來求余弦連Map結(jié)構(gòu)都幾乎不用改。還有一個值得做的預(yù)處理過濾掉評分記錄少于5條的用戶這些人對相似度矩陣貢獻(xiàn)的是噪聲刪掉以后推薦質(zhì)量會明顯提升——這個閾值在真實項目里要按數(shù)據(jù)量調(diào)數(shù)據(jù)稀疏就降到2到3數(shù)據(jù)稠密就提到10。3. 用Java實現(xiàn)協(xié)同過濾核心相似度計算、UserCF與ItemCF的完整代碼這一章是全篇的重頭戲。我按“相似度函數(shù) - UserCF流程 - ItemCF流程 - TopN排序”的順序給代碼每個函數(shù)都能直接復(fù)制進(jìn)你的工程跑起來。拿到源碼后先改數(shù)據(jù)路徑再調(diào)閾值最后看推薦列表比對著概念空想快得多。3.1 余弦相似度與皮爾遜相關(guān)系數(shù)兩段可直接抄的Java方法相似度是協(xié)同過濾的心臟。最常用的是余弦相似度和皮爾遜相關(guān)系數(shù)。余弦相似度把每個用戶的評分看成一個向量計算兩個向量夾角的余弦值完全同向為1垂直為0反向為-1。皮爾遜相關(guān)系數(shù)相當(dāng)于對兩個用戶各自的評分做中心化也就是減掉各自均值之后再算余弦它能抵消“有人手松全打5分、有人手緊平均給3分”這種偏差。public class SimilarityUtil { public static double cosine(MapInteger, Double a, MapInteger, Double b) { SetInteger common new HashSet(a.keySet()); common.retainAll(b.keySet()); if (common.isEmpty()) { return 0.0; } double dot 0.0; for (int id : common) { dot a.get(id) * b.get(id); } double normA 0.0; for (double v : a.values()) { normA v * v; } double normB 0.0; for (double v : b.values()) { normB v * v; } if (normA 0.0 || normB 0.0) { return 0.0; } return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } public static double pearson(MapInteger, Double a, MapInteger, Double b) { SetInteger common new HashSet(a.keySet()); common.retainAll(b.keySet()); if (common.size() 2) { return 0.0; } double sumA 0.0; double sumB 0.0; for (int id : common) { sumA a.get(id); sumB b.get(id); } double meanA sumA / common.size(); double meanB sumB / common.size(); double numerator 0.0; double denomA 0.0; double denomB 0.0; for (int id : common) { double va a.get(id) - meanA; double vb b.get(id) - meanB; numerator va * vb; denomA va * va; denomB vb * vb; } if (denomA 0.0 || denomB 0.0) { return 0.0; } return numerator / (Math.sqrt(denomA) * Math.sqrt(denomB)); } }參數(shù)說明皮爾遜至少要求2個共同評分否則分子分母恒為0算出來是NaN在推薦鏈路里NaN會一路傳染到排序結(jié)果。還要注意一個細(xì)節(jié)余弦相似度的normA、normB是對用戶全部評分計算的而不是只對共同評分的電影計算。如果你只算共同交集里的模長結(jié)果會把“看過很多電影的用戶”和“只看過幾部電影的用戶”拉到同一水平線上這是我踩過的坑忘一次錯一次。3.2 用Java實現(xiàn)UserCF找TopK相似用戶加權(quán)匯總候選電影UserCF的流程拆成四步取出目標(biāo)用戶的評分遍歷全部用戶算相似度按相似度排序取前K個鄰居最后把鄰居們評過分而目標(biāo)用戶沒看過的電影按相似度加權(quán)匯總。預(yù)測分?jǐn)?shù)用“加權(quán)平均”而不是簡單求和這是為了避免鄰居多的用戶天然占優(yōu)。public class UserCF { private final MapInteger, MapInteger, Double userItemMap; private final int topK; private final int topN; private final double minSimilarity; public UserCF(MapInteger, MapInteger, Double userItemMap, int topK, int topN, double minSimilarity) { this.userItemMap userItemMap; this.topK topK; this.topN topN; this.minSimilarity minSimilarity; } public ListMap.EntryInteger, Double recommend(int targetUserId) { MapInteger, Double targetRatings userItemMap.get(targetUserId); if (targetRatings null || targetRatings.isEmpty()) { return Collections.emptyList(); } MapInteger, Double simMap new HashMap(); for (Map.EntryInteger, MapInteger, Double entry : userItemMap.entrySet()) { int otherUserId entry.getKey(); if (otherUserId targetUserId) { continue; } double sim SimilarityUtil.pearson(targetRatings, entry.getValue()); if (sim minSimilarity) { simMap.put(otherUserId, sim); } } ListMap.EntryInteger, Double neighbors topN(simMap, topK); MapInteger, Double scoreMap new HashMap(); MapInteger, Double weightMap new HashMap(); for (Map.EntryInteger, Double neighbor : neighbors) { int neighborId neighbor.getKey(); double sim neighbor.getValue(); for (Map.EntryInteger, Double rating : userItemMap.get(neighborId).entrySet()) { int movieId rating.getKey(); if (targetRatings.containsKey(movieId)) { continue; } scoreMap.merge(movieId, sim * rating.getValue(), Double::sum); weightMap.merge(movieId, sim, Double::sum); } } MapInteger, Double predictMap new HashMap(); for (Integer movieId : scoreMap.keySet()) { predictMap.put(movieId, scoreMap.get(movieId) / weightMap.get(movieId)); } return topN(predictMap, topN); } private ListMap.EntryInteger, Double topN(MapInteger, Double map, int n) { return map.entrySet().stream() .sorted(Map.Entry.Integer, DoublecomparingByValue().reversed()) .limit(n) .collect(Collectors.toList()); } }邏輯說明minSimilarity默認(rèn)給0.1低于這條線的用戶不做鄰居topK默認(rèn)給20。在稀疏的數(shù)據(jù)集上把minSimilarity降到0.05能多召回不少候選但同時引入噪聲。scoreMap里累加的是“相似度乘以鄰居評分”weightMap里累加的是相似度本身兩者相除得到加權(quán)平均分天然落在1到5區(qū)間不用再歸一化。過濾“已看過的電影”必須做否則推薦列表里出現(xiàn)用戶看過的片子產(chǎn)品驗收這關(guān)就過不了。3.3 用Java實現(xiàn)ItemCF先離線建電影相似度表再在線召回ItemCF和UserCF最大的差別是把“用戶與用戶相似”換成“電影與電影相似”而電影相似度可以預(yù)先離線算好。第一步把userItemMap轉(zhuǎn)置成itemUserMap第二步對兩兩電影算余弦相似度寫入movieSimMap第三步在線推薦時從用戶評分過的電影出發(fā)去相似表里撈候選。下面這段先給出建表和召回兩個方法。public class ItemCF { private final MapInteger, MapInteger, Double itemUserMap; private final MapInteger, MapInteger, Double movieSimMap new HashMap(); private final int numSimilar; private final int topN; private final double minSimilarity; public ItemCF(MapInteger, MapInteger, Double userItemMap, int numSimilar, int topN, double minSimilarity) { this.itemUserMap DataLoader.transpose(userItemMap); this.numSimilar numSimilar; this.topN topN; this.minSimilarity minSimilarity; buildSimilarityTable(); } private void buildSimilarityTable() { ListInteger movieIds new ArrayList(itemUserMap.keySet()); for (int i 0; i movieIds.size(); i) { int movieA movieIds.get(i); MapInteger, Double usersOfA itemUserMap.get(movieA); for (int j i 1; j movieIds.size(); j) { int movieB movieIds.get(j); MapInteger, Double usersOfB itemUserMap.get(movieB); double sim SimilarityUtil.cosine(usersOfA, usersOfB); if (sim minSimilarity) { movieSimMap.computeIfAbsent(movieA, k - new HashMap()).put(movieB, sim); movieSimMap.computeIfAbsent(movieB, k - new HashMap()).put(movieA, sim); } } } } public ListMap.EntryInteger, Double recommend(MapInteger, Double userRatings) { MapInteger, Double scoreMap new HashMap(); MapInteger, Double weightMap new HashMap(); for (Map.EntryInteger, Double entry : userRatings.entrySet()) { int ratedMovie entry.getKey(); double rating entry.getValue(); MapInteger, Double simMovies movieSimMap.get(ratedMovie); if (simMovies null) { continue; } ListMap.EntryInteger, Double similarList topN(simMovies, numSimilar); for (Map.EntryInteger, Double similar : similarList) { int candMovie similar.getKey(); double sim similar.getValue(); if (userRatings.containsKey(candMovie)) { continue; } scoreMap.merge(candMovie, sim * rating, Double::sum); weightMap.merge(candMovie, sim, Double::sum); } } MapInteger, Double predictMap new HashMap(); for (Integer movieId : scoreMap.keySet()) { predictMap.put(movieId, scoreMap.get(movieId) / weightMap.get(movieId)); } return topN(predictMap, topN); } }邏輯說明buildSimilarityTable是雙重循環(huán)只算上三角j從i1開始并在兩邊同時寫入能把計算量減半。movieSimMap的規(guī)模是“存量電影數(shù)乘以平均鄰居數(shù)”1萬部電影最終可能存幾十萬個相似對完全在內(nèi)存可接受的范圍內(nèi)。recommend方法里的numSimilar我通常取10意思是一部電影最多找10個相似電影參與累加避免相似度表過大時每個候選都要遍歷全表。這段代碼的潛在翻車點如果你在recommend里傳入了空的userRatingsscoreMap和weightMap為空最后返回空列表——調(diào)用方要提前做冷啟動判斷不能救到這一步。3.4 TopN排序與推薦列表去重用一個工具方法收尾無論是UserCF還是ItemCF最后都要把候選按得分降序截斷成指定長度。Java里最省事的寫法是stream加sorted加limit但要注意一個細(xì)節(jié)當(dāng)分?jǐn)?shù)相同且條目數(shù)超過limit時stream limit的結(jié)果順序不穩(wěn)定。工程上更穩(wěn)妥的做法是先按“分?jǐn)?shù)降序、電影ID升序”做二次排序保證結(jié)果是確定性的。排序這塊我不建議自己手寫冒泡排序java教科書代碼數(shù)據(jù)量上去之后性能不夠看。用JDK自帶的排序就行private ListMap.EntryInteger, Double topN(MapInteger, Double map, int n) { return map.entrySet().stream() .sorted(Map.Entry.Integer, DoublecomparingByValue().reversed() .thenComparing(Map.Entry.comparingByKey())) .limit(n) .collect(Collectors.toList()); }參數(shù)說明thenComparing(Map.Entry.comparingByKey())是加分項它解決了同分時排序結(jié)果不穩(wěn)定導(dǎo)致的前端展示跳變問題。如果你還在JDK 8以下把stream換成Collections.sort然后手動截斷效果一樣。去重邏輯在核心流程里已經(jīng)做了兩次一是在累加候選時跳過用戶已評分的電影二是在最終推薦表里不重復(fù)插入同一部電影復(fù)合主鍵(user_id, movie_id)兜底防止并發(fā)寫重復(fù)。4. 把算法源碼變成可交付的工程Spring Boot MyBatis的分層與接口算法能跑通只是第一步推薦系統(tǒng)源碼真正值錢的部分在工程化目錄分層是否清晰、數(shù)據(jù)從哪兒來、接口怎么暴露。這一章我按一個常見做法來拆Maven工程打底Spring Boot接HTTPMyBatis管SQL算法層保持純凈。4.1 推薦系統(tǒng)源碼的目錄結(jié)構(gòu)算法包和業(yè)務(wù)包為什么必須分開我見過很多推薦系統(tǒng)源碼最頭疼的是把協(xié)同過濾算法寫在Controller里一個類幾百行既沒法單測也沒法復(fù)用。正確的做法是把算法層和Spring框架徹底隔離目錄結(jié)構(gòu)大致是這樣movie-recommend/ ├── pom.xml └── src/main/java/com/example/recommend/ ├── algorithm/ │ ├── SimilarityUtil.java │ ├── UserCF.java │ ├── ItemCF.java │ └── DataLoader.java ├── entity/ │ ├── Movie.java │ └── UserRating.java ├── mapper/ │ ├── MovieMapper.java │ └── UserRatingMapper.java ├── service/ │ └── RecommendService.java ├── controller/ │ └── RecommendController.java └── RecommendApplication.javaalgorithm包里的類不依賴Spring的Component、Autowired這些注解放到任何Java 8環(huán)境都能直接運(yùn)行。這樣做的直接收益是你可以寫一個main方法單獨(dú)加載MovieLens數(shù)據(jù)調(diào)UserCF不用啟動一個Web容器就能驗證算法效果debug一個推薦邏輯從改代碼到看到結(jié)果不超過10秒。這也是面向?qū)ο缶幊蘪ava里“職責(zé)單一”思想落地算法只負(fù)責(zé)算Service只負(fù)責(zé)編排Controller只負(fù)責(zé)傳輸。pom.xml里需要引入的東西很簡單Spring Boot Web、MyBatis Starter和MySQL驅(qū)動。版本以你自己本地的Spring Boot為準(zhǔn)我習(xí)慣用2.7.x搭配MyBatis 2.x如果是新學(xué)的同學(xué)直接用3.x也一樣接口上沒有大差別。4.2 MySQL表設(shè)計評分表、電影表與推薦結(jié)果表字段和索引這樣定推薦系統(tǒng)要落庫至少要有三張表電影表存元數(shù)據(jù)評分表存用戶行為推薦結(jié)果表存離線算好的TopN。表結(jié)構(gòu)可以直接照抄下面這個字段名我壓到了最少CREATE TABLE movie ( id int NOT NULL, title varchar(255) NOT NULL, genres varchar(255) DEFAULT NULL, PRIMARY KEY (id) ); CREATE TABLE user_rating ( id bigint NOT NULL AUTO_INCREMENT, user_id int NOT NULL, movie_id int NOT NULL, score double NOT NULL, create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_movie_id (movie_id) ); CREATE TABLE recommend_result ( user_id int NOT NULL, movie_id int NOT NULL, score double NOT NULL, rank int NOT NULL, update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (user_id, rank) );參數(shù)說明user_rating表的核心是user_id和movie_id兩個索引user_id索引服務(wù)于“給某用戶取全部評分”movie_id索引服務(wù)于“給某電影取全部評分用戶”第二個用途是ItemCF離線計算時的SQL支撐。recommend_result表用(user_id, rank)做復(fù)合主鍵rank直接存1到N意味著同一個用戶新一輪結(jié)果只要按rank覆蓋插入不用先刪后插省一次事務(wù)。score字段存的是協(xié)同過濾算出來的預(yù)測分前端排序直接按它排就行。4.3 Spring Boot接口層Controller保持輕薄Service兜底冷啟動接口層最常見的錯誤是把算法塞進(jìn)Controller再包一層循環(huán)。下面這個例子是標(biāo)準(zhǔn)的三層寫法先看ControllerRestController RequestMapping(/api/recommend) public class RecommendController { private final RecommendService recommendService; public RecommendController(RecommendService recommendService) { this.recommendService recommendService; } GetMapping(/{userId}) public ListMovieVO recommend(PathVariable int userId) { return recommendService.recommendForUser(userId); } }邏輯說明Controller只干一件事把userId參數(shù)取出來交給Service再把Service返回的結(jié)果以JSON形式吐給前端。構(gòu)造函數(shù)注入比字段上加Autowired更利于測試這也是很多公司代碼規(guī)范里的要求。MovieVO是一個輕量DTO只有movieId、title、score、rank四個字段不要直接把MyBatis的實體類返回給前端否則表結(jié)構(gòu)一改接口字段就跟著變坑所有調(diào)用方。緊接著是Service層Service public class RecommendService { private final UserRatingMapper userRatingMapper; private final RecommendResultMapper recommendResultMapper; private final MovieMapper movieMapper; public RecommendService(UserRatingMapper userRatingMapper, RecommendResultMapper recommendResultMapper, MovieMapper movieMapper) { this.userRatingMapper userRatingMapper; this.recommendResultMapper recommendResultMapper; this.movieMapper movieMapper; } public ListMovieVO recommendForUser(int userId) { ListRecommendResult results recommendResultMapper.selectByUserId(userId); if (results null || results.isEmpty()) { ListMovie hotMovies movieMapper.selectHotMovies(20); return MovieVO.fromMovies(hotMovies); } return MovieVO.fromResults(results); } }參數(shù)說明Service層做了冷啟動兜底——如果recommend_result表里查不到這個用戶直接查movie表里的熱門電影榜返回前端的推薦位永遠(yuǎn)不會空。這比在算法層強(qiáng)行判斷更干凈因為接口的語義變成“永遠(yuǎn)有推薦結(jié)果”。selectHotMovies的SQL用“評分人數(shù)和平均分”組合排序ORDER BY score_count DESC, avg_score DESC LIMIT 20不需要join性能就夠。如果要把在線實時推薦也接進(jìn)來做法是在Service里注入ItemCF的Bean把mapper查到的評分記錄轉(zhuǎn)成Map結(jié)構(gòu)喂給算法但這要求評分?jǐn)?shù)據(jù)量小到能在幾十毫秒內(nèi)完成遍歷。數(shù)據(jù)量超過10萬條以后我更建議離線計算落庫再加每日定時任務(wù)別讓算法接口扛實時壓力這就是“離線為主、實時兜底”的常見架構(gòu)。5. 協(xié)同過濾必踩的五個坑冷啟動、稀疏矩陣、評分偏差與性能翻車排查筆記這一章的每條記錄都是真實調(diào)參時會撞見的現(xiàn)象我按“現(xiàn)象、原因、解決”三段寫你照著日志對比就知道問題在哪一環(huán)。5.1 冷啟動新用戶沒有評分推薦結(jié)果永遠(yuǎn)是空的現(xiàn)象剛注冊的用戶調(diào)用推薦接口返回空列表前端頁面在“猜你喜歡”區(qū)域一片空白轉(zhuǎn)化率直接歸零。原因UserCF和ItemCF都依賴歷史評分。用戶沒有任何行為時相似度計算的分母是0任何公式都產(chǎn)出0算法層面無能為力。解決冷啟動階段不做協(xié)同過濾用熱門榜兜底。我前面Service里的實現(xiàn)就是把selectHotMovies結(jié)果返回出去。熱門榜不能簡單用評分人數(shù)排序我一般用“評分人數(shù)×平均分”再乘時間衰減權(quán)重避免老片霸榜。等用戶產(chǎn)生了五六條評分記錄之后再切換回協(xié)同過濾邏輯這是最簡單的漸進(jìn)式冷啟動。5.2 稀疏矩陣兩個用戶只共同看過一部電影相似度卻高達(dá)0.9現(xiàn)象調(diào)日志時發(fā)現(xiàn)一對用戶相似度0.87但他們共同評分只有1部電影。相似表里大量這樣虛高的相似對推薦結(jié)果跑偏。原因余弦相似度在交集樣本極少時統(tǒng)計上不顯著一個共同評分就能把夾角帶得極小相似度虛高。電影站動輒上萬部電影用戶平均評分又少交集為0是常態(tài)交集為1根本不稀奇。解決加置信度門檻當(dāng)共同評分?jǐn)?shù)小于閾值時直接返回0。我在SimilarityUtil.pearson里已經(jīng)寫了common.size() 2就返回0.0實際項目里建議把閾值提到5。同時優(yōu)先使用皮爾遜相關(guān)系數(shù)替代原始余弦因為皮爾遜先做了均值中心化對“共同評分樣本少但絕對分?jǐn)?shù)高”的抗性更好。這條在數(shù)據(jù)稀疏的新站上尤其重要。5.3 評分偏差有人手松全打5分有人手緊只打3分余弦相似度直接失真現(xiàn)象用戶A給所有電影打5分用戶B同樣幾部電影打4分余弦相似度依然算得很高可兩人的真實口味可能完全相反。原因余弦相似度把絕對分?jǐn)?shù)當(dāng)成向量方向來算沒有減去每個用戶的平均分。手松和手緊在絕對分?jǐn)?shù)上差了整整一個常數(shù)偏移這個偏移在余弦公式里沒有被消除。解決改用皮爾遜相關(guān)系數(shù)等價于把每個用戶的評分先中心化原分?jǐn)?shù)減均值再算余弦。我的SimilarityUtil里兩個方法都寫了工程里默認(rèn)走pearson就對了。如果你堅持用余弦那就先做歸一化我可以把“score - userAvgScore”存入Map后再交給余弦方法。5.4 熱門電影屠榜推薦結(jié)果全是全局爆款多樣性和個性化同時歸零現(xiàn)象離線計算結(jié)果里Top10推薦總是那幾部評分人數(shù)最多的電影每個用戶的列表大同小異運(yùn)營抱怨“推薦沒有差異性”。原因熱門電影被大量用戶評分它們和所有電影都容易產(chǎn)生相似關(guān)系用戶在評分過的電影里去撈相似候選熱門電影出現(xiàn)的頻率極高累加積分碾壓小眾片。解決累加權(quán)重時加入熱門懲罰。常見做法是對候選電影的相似度乘上一個衰減系數(shù)sim / Math.pow(1 Math.log(1 itemUserMap.get(movieId).size()), 2)這個系數(shù)隨評分人數(shù)上升而下降。還可以在后處理里做類型約束按genres分組每組最多選3部保證TopN里有喜劇也有懸疑而不是清一色的動作大片。這一步是推薦結(jié)果從“能用”到“像樣”的分水嶺。5.5 性能翻車循環(huán)里查庫導(dǎo)致N1查詢一次推薦接口把數(shù)據(jù)庫打掛現(xiàn)象一次推薦請求發(fā)出后數(shù)據(jù)庫慢查詢?nèi)罩纠锍霈F(xiàn)兩三百條SQL接口耗時8秒QPS一高M(jìn)ySQL連接直接打滿。原因典型的N1問題。常見寫法是在算法里遍歷用戶列表每次循環(huán)調(diào)一次mapper查詢評分比如for (userId : allUsers) { userItemMap userMapper.selectRatingsByUserId(userId); }。用戶量一上來這個循環(huán)就是災(zāi)難。解決把行為數(shù)據(jù)一次性加載進(jìn)內(nèi)存。在Spring Boot啟動時用PostConstruct或ApplicationRunner執(zhí)行一次全量load把評分記錄組裝成userItemMap和itemUserMap保存在單例Bean里接口只從內(nèi)存取數(shù)。數(shù)據(jù)量超過百萬條時改為離線Spark或定時任務(wù)預(yù)計算后再落recommend_result表在線接口絕不碰評分明細(xì)表只查推薦結(jié)果表。這條不只是性能問題還是一個架構(gòu)取舍推薦結(jié)果表里只有每個用戶前20條結(jié)果查詢走主鍵P95響應(yīng)時間能壓到10毫秒以內(nèi)。6. 驗證推薦結(jié)果是否靠譜離線切分、覆蓋率與K值調(diào)參的進(jìn)階收尾推薦系統(tǒng)源碼寫完最容易被忽略的一步是驗證。沒有驗證手段你就分不清“參數(shù)調(diào)好了”和“參數(shù)調(diào)順手了”。我最后分享一個每次都會做的離線驗證流程和兩個指標(biāo)。先把評分?jǐn)?shù)據(jù)按時間切分按timestamp排序前80%作為訓(xùn)練集后20%作為測試集。協(xié)同過濾只用訓(xùn)練集計算相似度和推薦然后用測試集里用戶真實看過的電影和推薦結(jié)果做比對。如果推薦結(jié)果里出現(xiàn)了用戶真實看過的測試集電影說明這次推薦是命中的。命中數(shù)除以測試集電影數(shù)就是召回率再算一下推薦結(jié)果覆蓋了電影全量的多少比例得到覆蓋率。這兩個數(shù)字一個衡量準(zhǔn)確度一個衡量多樣性。K值和相似度閾值的調(diào)參法固定minSimilarity為0.1把K從5、10、15、20依次跑一遍記錄每組的召回率和覆蓋率。你會發(fā)現(xiàn)K小的時候精度高但覆蓋面窄K大了以后結(jié)果趨于熱門化。我在做電影推薦這類的經(jīng)驗值是K20到30minSimilarity0.1到0.2如果你的數(shù)據(jù)更稀疏K往下調(diào)、minSimilarity往下調(diào)數(shù)據(jù)更稠密就反過來。調(diào)參順序是先調(diào)K再調(diào)minSimilarity最后才調(diào)熱門懲罰系數(shù)因為K對結(jié)果的影響最直接。最后一個進(jìn)階技巧是存一份movieSimMap的序列化緩存。ItemCF建電影相似度表在幾千部電影時需要幾十秒可能每次重啟都要等。常見做法是用Java自帶的ObjectOutputStream把movieSimMap寫到本地臨時文件啟動時先檢查文件存在就反序列化加載不存在才重建。我會在代碼里注明緩存的失效條件只要評分?jǐn)?shù)據(jù)更新了就要刪掉緩存文件重新生成否則推薦永遠(yuǎn)不會反映新行為。這套源碼我自己交過課設(shè)也改過生產(chǎn)環(huán)境的需求最大的教訓(xùn)是協(xié)同過濾不是裝上去就完事的黑匣子它需要你把每一個閾值當(dāng)成可配置的參數(shù)再把驗證指標(biāo)當(dāng)成調(diào)參的準(zhǔn)繩。推薦結(jié)果能打60分還是90分差別往往不在算法本身而在于你有沒有把冷啟動兜底和熱門懲罰做到位。希望幫到你。本文還有配套的精品資源點擊獲取