springboot基于協(xié)同過濾算法的跳蚤市場(chǎng)商品推薦系統(tǒng)去年年底幫一個(gè)學(xué)弟做的畢業(yè)設(shè)計(jì)題目就是這個(gè)“基于協(xié)同過濾的跳蚤市場(chǎng)商品推薦系統(tǒng)”。他從一開始就沒想清楚自己到底要做什么跟我說“導(dǎo)師讓做一個(gè)帶推薦功能的商城”結(jié)果需求文檔寫得跟淘寶似的。我聽完就樂了你又沒有淘寶級(jí)別的數(shù)據(jù)量搞什么高大上的推薦系統(tǒng)呢。你一個(gè)校園二手市場(chǎng)用戶撐死幾百人商品幾千件你用什么深度學(xué)習(xí)、用什么大模型那都是殺雞用牛刀。協(xié)同過濾這種經(jīng)典算法正好是這個(gè)場(chǎng)景下的最優(yōu)解?；藘芍軙r(shí)間從需求梳理、表結(jié)構(gòu)設(shè)計(jì)到算法落地、接口聯(lián)調(diào)最后給他整出來一套完完整整能跑的項(xiàng)目。這中間踩了不少坑也總結(jié)了一些經(jīng)驗(yàn)今天就把整個(gè)項(xiàng)目從頭到尾拆解一遍從技術(shù)選型到算法實(shí)現(xiàn)從數(shù)據(jù)庫(kù)設(shè)計(jì)到部署上線都寫在這里。無(wú)論你是要做畢設(shè)、課程設(shè)計(jì)還是單純想了解推薦系統(tǒng)在真實(shí)業(yè)務(wù)里怎么落地這篇都值得你耐心看完。1. 項(xiàng)目整體設(shè)計(jì)與思路拆解1.1 核心需求解析先搞清楚這項(xiàng)目到底是干什么的。跳蚤市場(chǎng)說白了就是二手交易平臺(tái)學(xué)生把自己閑置的教材、數(shù)碼產(chǎn)品、自行車、吉他掛上去賣其他人看到合適的就買走。核心功能就是商品發(fā)布、瀏覽、下單、訂單管理、個(gè)人中心這些這些常規(guī)功能網(wǎng)上一抓一大把沒什么技術(shù)含量。真正有技術(shù)含量的是“推薦”兩個(gè)字。系統(tǒng)要能根據(jù)用戶的歷史行為比如瀏覽過什么、收藏過什么、買過什么主動(dòng)把當(dāng)前用戶可能感興趣的商品推送給他。這就是協(xié)同過濾算法的應(yīng)用場(chǎng)景。那為什么不直接做商品分類篩選而是要做推薦呢原因很簡(jiǎn)單跳蚤市場(chǎng)跟淘寶京東不一樣這里沒有海量商家和鋪天蓋地的廣告商品全靠搜索和分類很難被看到。比如某個(gè)用戶是一名大二學(xué)生他剛學(xué)完高數(shù)想賣教材另一個(gè)大四學(xué)生正好在找這本教材。如果靠傳統(tǒng)搜索兩個(gè)人必須先知道對(duì)方上傳了什么關(guān)鍵詞才能匹配。但推薦系統(tǒng)的作用是當(dāng)大四學(xué)生登錄首頁(yè)時(shí)系統(tǒng)會(huì)主動(dòng)把他可能需要的教材推給他用戶甚至不用搜索就能看到。推薦在這里的價(jià)值就是提升交易匹配效率和用戶粘性。1.2 技術(shù)選型背后的考量這套系統(tǒng)我選了Spring Boot 2.7 MyBatis Plus MySQL 8.0 Redis Vue 3作為主技術(shù)棧推薦算法部分用Python實(shí)現(xiàn)?？吹絇ython可能有人會(huì)問既然都用了Java為什么算法不也用Java寫因?yàn)槲抑蝗∷惴ㄓ?jì)算出來的推薦結(jié)果通過JSON接口返回給Java后端算法本身和主系統(tǒng)解耦。比如相似度矩陣計(jì)算、用戶商品交互數(shù)據(jù)處理這些用Python的pandas處理比Java方便得多開發(fā)效率完全不是一個(gè)量級(jí)。Spring Boot就不多說了現(xiàn)在做Java后端項(xiàng)目的標(biāo)配自動(dòng)配置省掉一大堆繁瑣的XML配置。MyBatis Plus是我個(gè)人比較喜歡的一個(gè)ORM框架它比原生MyBatis好在單表操作不需要寫SQL代碼生成器一鍵生成實(shí)體類和Mapper太香了。MySQL選8.0是因?yàn)閷?duì)JSON數(shù)據(jù)類型的支持更好后面我們會(huì)用到。Redis這個(gè)很關(guān)鍵它承擔(dān)兩個(gè)任務(wù)一是分布式session存儲(chǔ)解決集群部署時(shí)的會(huì)話共享問題二是緩存熱點(diǎn)數(shù)據(jù)和推薦結(jié)果避免每次刷新頁(yè)面都重復(fù)計(jì)算推薦列表。前端用Vue 3加Element Plus這套組合適合后臺(tái)管理系統(tǒng)場(chǎng)景對(duì)比Vue 2的選項(xiàng)式APIVue 3的組合式API代碼更簡(jiǎn)潔邏輯復(fù)用也方便。UI框架用Element Plus能快速搭出清爽的管理后臺(tái)這活干了這么多年就說句實(shí)話做這種帶后臺(tái)管理的項(xiàng)目Element Plus比Ant Design Vue上手更快。1.3 算法選型為什么是協(xié)同過濾協(xié)同過濾算法是推薦系統(tǒng)里最經(jīng)典的算法之一核心思想就一句話人以群分物以類聚。它的實(shí)現(xiàn)主要分兩種思路?；谟脩舻膮f(xié)同過濾User-Based CF是先找到和你興趣相似的用戶看看你相似用戶都買過什么把這些商品推薦給你?；谖锲返膮f(xié)同過濾Item-Based CF則是先算出物品之間的相似度然后根據(jù)你之前買過或?yàn)g覽過的東西給你推薦相似的物品。這兩個(gè)方案選哪個(gè)我在這里選了基于物品的協(xié)同過濾。為什么看一個(gè)具體的運(yùn)營(yíng)場(chǎng)景你就明白了某用戶在跳蚤市場(chǎng)瀏覽過一本《數(shù)據(jù)結(jié)構(gòu)》教材基于物品協(xié)同過濾就能算出這本《數(shù)據(jù)結(jié)構(gòu)》教材和《算法導(dǎo)論》教材的相似度很高因?yàn)榻?jīng)常被同一批用戶一起瀏覽和購(gòu)買于是推薦算法就會(huì)給這個(gè)用戶推《算法導(dǎo)論》的二手書。而基于用戶的協(xié)同過濾算法更適合那種用戶量遠(yuǎn)大于商品量、用戶興趣標(biāo)簽明顯的平臺(tái)。但跳蚤市場(chǎng)這個(gè)場(chǎng)景校園里用戶就千把人商品卻能不斷新增商品之間的相似關(guān)系比用戶之間的相似關(guān)系穩(wěn)定得多。所以我最終選擇了Item-Based CF作為主力算法。不過這還不夠協(xié)同過濾有兩個(gè)繞不開的痛點(diǎn)一個(gè)是冷啟動(dòng)問題新商品沒有任何用戶行為數(shù)據(jù)協(xié)同過濾就算不出它跟其他商品的相似度一個(gè)是數(shù)據(jù)稀疏問題跳蚤市場(chǎng)的用戶行為本來就少矩陣稀疏得跟漁網(wǎng)似的。后面實(shí)操部分我們會(huì)講怎么用數(shù)據(jù)預(yù)處理和兜底策略來處理這兩個(gè)坑。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心模塊實(shí)現(xiàn)2.1 表結(jié)構(gòu)設(shè)計(jì)的關(guān)鍵細(xì)節(jié)數(shù)據(jù)庫(kù)是一個(gè)業(yè)務(wù)系統(tǒng)的地基這里的表結(jié)構(gòu)設(shè)計(jì)花了不少心思。核心表包括用戶表、商品表、訂單表、收藏表、瀏覽記錄表、評(píng)分表、推薦結(jié)果表。說幾個(gè)關(guān)鍵設(shè)計(jì)的細(xì)節(jié)。第一個(gè)是用戶表。用戶除了常規(guī)的id、用戶名、密碼、昵稱、頭像、手機(jī)號(hào)、角色之外我特意加了一個(gè)字段叫user_type用來區(qū)分買家和賣家身份。有人可能會(huì)說跳蚤市場(chǎng)里每個(gè)人不都既是買家又是賣家嗎你說得對(duì)但實(shí)際運(yùn)營(yíng)中有一部分用戶就是只買東西不賣東西為了后續(xù)運(yùn)營(yíng)分析的便利還是把角色區(qū)分開了。對(duì)于既賣又買的用戶這個(gè)字段就標(biāo)記為both。第二個(gè)是商品表。關(guān)鍵字段有商品標(biāo)題、描述、價(jià)格、原價(jià)、成色、分類、圖片、狀態(tài)。其中成色這個(gè)字段是跳蚤市場(chǎng)特有的業(yè)務(wù)字段是賣家對(duì)商品新舊程度的自評(píng)一般分成全新、幾乎全新、輕微使用痕跡、明顯使用痕跡、有瑕疵這五檔這個(gè)字段在后續(xù)推薦權(quán)重計(jì)算里會(huì)有大用場(chǎng)。狀態(tài)字段是上架中、已下架、已售出三個(gè)值查詢時(shí)永遠(yuǎn)只查上架中的商品。第三個(gè)是訂單表。除了常規(guī)的訂單號(hào)、買家id、賣家id、商品id、價(jià)格、下單時(shí)間、支付時(shí)間之外我把訂單狀態(tài)細(xì)化成了待付款、待發(fā)貨、已發(fā)貨、已完成、已取消、退款中、已退款七個(gè)狀態(tài)。都是做電商的為什么訂單狀態(tài)這么細(xì)你應(yīng)該深有體會(huì)不細(xì)化后面統(tǒng)計(jì)經(jīng)營(yíng)數(shù)據(jù)的時(shí)候哭都來不及。然后是收藏表和瀏覽記錄表。這兩張表是推薦算法最重要的數(shù)據(jù)來源收藏表記錄了用戶對(duì)哪些商品感興趣瀏覽記錄表記錄了用戶看過哪些商品、看了多久。這里有個(gè)實(shí)用的設(shè)計(jì)經(jīng)驗(yàn)瀏覽記錄表不要只存商品id和瀏覽時(shí)間我加了一個(gè)duration字段記錄用戶在該商品詳情頁(yè)停留的秒數(shù)這個(gè)數(shù)據(jù)在后續(xù)算用戶興趣權(quán)重時(shí)非常好用停留時(shí)間長(zhǎng)的商品說明用戶確實(shí)感興趣。評(píng)分表的設(shè)計(jì)也是推薦系統(tǒng)的重頭戲。表面上用戶可以在購(gòu)買完成后給商品打分1到5分這是顯式反饋數(shù)據(jù)。但跳蚤市場(chǎng)這類平臺(tái)用戶主動(dòng)評(píng)分的行為其實(shí)很少所以我在設(shè)計(jì)評(píng)分表時(shí)把收藏行為、瀏覽行為、購(gòu)買行為都?xì)w總到一張偏好記錄表里作為隱式評(píng)分的數(shù)據(jù)來源這樣協(xié)同過濾算法的輸入數(shù)據(jù)才夠用。最后是推薦結(jié)果表。這張表存協(xié)同過濾算法算出來的推薦結(jié)果包含用戶id、商品id、推薦分值、推薦時(shí)間、推薦來源推薦來源區(qū)分了是基于協(xié)同過濾算出來的還是用了兜底策略算出來的。為什么要存這張表一是為了方便運(yùn)營(yíng)人員排查一個(gè)用戶為什么看到這些推薦商品二是方便測(cè)試對(duì)比算法效果再者是避免一次首頁(yè)請(qǐng)求就觸發(fā)一次全量推薦計(jì)算直接把已經(jīng)算好的結(jié)果查出來返回就行。2.2 Spring Boot后端架構(gòu)與業(yè)務(wù)層實(shí)現(xiàn)后端項(xiàng)目用了經(jīng)典的三層架構(gòu)Controller層負(fù)責(zé)接收請(qǐng)求和參數(shù)校驗(yàn)Service層實(shí)現(xiàn)業(yè)務(wù)邏輯Mapper層處理數(shù)據(jù)庫(kù)交互。為了避免代碼量太龐大導(dǎo)致后期難維護(hù)項(xiàng)目做了一點(diǎn)點(diǎn)領(lǐng)域拆分的動(dòng)作把用戶、商品、訂單、推薦這四個(gè)板塊分成獨(dú)立的模塊。用戶模塊相對(duì)傳統(tǒng)主要就是注冊(cè)、登錄、個(gè)人信息修改。注冊(cè)邏輯里加了一道基礎(chǔ)的校驗(yàn)比如用戶名是否已存在、密碼強(qiáng)度是否合規(guī)。密碼存儲(chǔ)用了BCrypt加密這是Spring Security框架提供的加密組件比MD5這種已經(jīng)被撞庫(kù)撞爛的算法要安全得多對(duì)畢設(shè)項(xiàng)目來說這個(gè)安全級(jí)別是夠的。商品模塊除了最基礎(chǔ)的增刪改查核心邏輯在于發(fā)布商品的流程里做了圖片上傳和價(jià)格合理性校驗(yàn)。圖片上傳這塊我用了本地存儲(chǔ)方案而不是對(duì)象存儲(chǔ)服務(wù)因?yàn)轫?xiàng)目還處在學(xué)習(xí)演示階段沒必要上云。改一下配置文件里的路徑就行上傳的圖片通過WebMvcConfigurer配置的虛擬路徑映射暴露給前端。商品查詢列表做成分頁(yè)接口支持按分類篩選、按價(jià)格區(qū)間篩選、按關(guān)鍵字模糊搜索。這里我用了MyBatis Plus的Page分頁(yè)插件配合LambdaQueryWrapper構(gòu)造動(dòng)態(tài)查詢條件單個(gè)接口能應(yīng)對(duì)多種組合查詢場(chǎng)景。這塊也沒人用ES做搜索數(shù)據(jù)量在這兒擺著呢殺雞不用牛刀。訂單模塊是業(yè)務(wù)邏輯最復(fù)雜的一塊。核心難點(diǎn)在于訂單狀態(tài)的流轉(zhuǎn)管理我用了狀態(tài)機(jī)模式來約束訂單狀態(tài)的合法流轉(zhuǎn)比如已發(fā)貨狀態(tài)不能直接跳到已取消必須是已發(fā)貨才能確認(rèn)收貨變成已完成。這塊的代碼核心是提前把每種狀態(tài)允許跳轉(zhuǎn)的狀態(tài)集合定義好每次更新狀態(tài)前做合法性校驗(yàn)這樣一來臟數(shù)據(jù)的問題就能從源頭上杜絕掉。推薦模塊是我重點(diǎn)設(shè)計(jì)的。推薦接口從Redis緩存里查推薦結(jié)果查不到就走數(shù)據(jù)庫(kù)里的推薦結(jié)果表數(shù)據(jù)庫(kù)里也沒有就觸發(fā)實(shí)時(shí)推薦計(jì)算。這個(gè)多級(jí)緩存的設(shè)計(jì)思路很實(shí)用避免了每次請(qǐng)求都打數(shù)據(jù)庫(kù)或者重復(fù)計(jì)算推薦結(jié)果。2.3 前端界面與交互流程前端部分用的是Vue 3加Element Plus做的核心頁(yè)面有首頁(yè)、商品詳情頁(yè)、購(gòu)物車頁(yè)、訂單管理頁(yè)、個(gè)人中心頁(yè)、發(fā)布商品頁(yè)、后臺(tái)管理頁(yè)。首頁(yè)分兩部分頂部是推薦位中間是全部商品列表。推薦位是首頁(yè)最重要的一塊這部分直接調(diào)用后端的推薦接口推薦結(jié)果展示成一行商品卡片每張卡片展示商品封面圖、標(biāo)題、價(jià)格、成色標(biāo)簽。這里我花了點(diǎn)心思被推薦的商品要打一個(gè)“猜你喜歡”的角標(biāo)因?yàn)閾?jù)我觀察有推薦標(biāo)簽的商品點(diǎn)擊率明顯高于普通商品這算是利用推薦算法加運(yùn)營(yíng)策略提升整體點(diǎn)擊率的一個(gè)小技巧。商品詳情頁(yè)展示了商品的完整信息包括圖片、描述、成色、賣家信息同時(shí)也展示了相關(guān)推薦商品相關(guān)推薦的數(shù)據(jù)來源還是協(xié)同過濾算出的相似商品。這個(gè)功能是基于物品的協(xié)同過濾的直接體現(xiàn)用戶正在看某個(gè)商品系統(tǒng)給他推相似商品促使他繼續(xù)瀏覽。訂單流程是這樣的用戶在商品詳情頁(yè)點(diǎn)擊“立即購(gòu)買”會(huì)創(chuàng)建一筆待付款訂單支付成功進(jìn)入待發(fā)貨狀態(tài)賣家發(fā)貨后進(jìn)入已發(fā)貨狀態(tài)買家確認(rèn)收貨后訂單完成。另外做了售后服務(wù)功能買家可以發(fā)起退款申請(qǐng)賣家同意后訂單狀態(tài)變成已退款。整個(gè)交互流程該有的環(huán)節(jié)一個(gè)都沒少。后臺(tái)管理頁(yè)面主要是管理員視角包括用戶管理、商品管理、訂單管理、數(shù)據(jù)統(tǒng)計(jì)管理員可以下架違規(guī)商品可以凍結(jié)違規(guī)用戶。這個(gè)后臺(tái)的權(quán)限控制用了最基礎(chǔ)的攔截器方案管理員接口統(tǒng)一走/admin路徑攔截器里校驗(yàn)當(dāng)前登錄用戶是不是管理員角色。3. 協(xié)同過濾推薦算法的詳細(xì)設(shè)計(jì)與落地3.1 數(shù)據(jù)預(yù)處理從原始行為到評(píng)分矩陣數(shù)據(jù)預(yù)處理是協(xié)同過濾算法工程質(zhì)量的決定性因素比選擇算法本身還重要。所有推薦算法的輸入都是用戶對(duì)物品的評(píng)分矩陣但跳蚤市場(chǎng)的原始數(shù)據(jù)里根本沒有現(xiàn)成的評(píng)分?jǐn)?shù)據(jù)全靠我們自己做數(shù)據(jù)加工。我們把用戶對(duì)商品的反饋分為幾個(gè)等級(jí)。收藏行為權(quán)重是3分加購(gòu)物車是4分購(gòu)買行為是5分瀏覽行為按停留時(shí)間折算成0.5到2分。為什么不直接用統(tǒng)一分?jǐn)?shù)呢這背后的邏輯是一個(gè)用戶買了某個(gè)商品說明他對(duì)這個(gè)商品有強(qiáng)興趣這個(gè)信號(hào)比單純的瀏覽強(qiáng)得多。如果不同強(qiáng)度的行為統(tǒng)一記1分那算法算出來的相似度區(qū)分度就很差。具體的偏好值計(jì)算邏輯我寫成了Python的pandas代碼片段這里是核心部分import pandas as pd import numpy as np def build_user_item_matrix(): # 讀取收藏記錄 df_fav pd.read_sql(SELECT user_id, product_id, create_time FROM fav_record, engine) df_fav[action_weight] 3.0 # 讀取加購(gòu)物車記錄 df_cart pd.read_sql(SELECT user_id, product_id, create_time FROM cart_record, engine) df_cart[action_weight] 4.0 # 讀取購(gòu)買記錄 df_order pd.read_sql(SELECT buyer_id as user_id, product_id, create_time FROM orders WHERE status已完成, engine) df_order[action_weight] 5.0 # 讀取瀏覽記錄按停留時(shí)間折算 df_view pd.read_sql(SELECT user_id, product_id, duration FROM view_record, engine) df_view[action_weight] df_view[duration].apply( lambda x: 0.5 if x 10 else (1.0 if x 30 else 2.0) ) # 合并所有行為并聚合 df_all pd.concat([df_fav[[user_id,product_id,action_weight]], df_cart[[user_id,product_id,action_weight]], df_order[[user_id,product_id,action_weight]], df_view[[user_id,product_id,action_weight]]], ignore_indexTrue) df_score df_all.groupby([user_id,product_id])[action_weight].sum().reset_index() df_score[action_weight] df_score[action_weight].clip(upper10) # 透視成用戶-商品矩陣 matrix df_score.pivot_table(indexuser_id, columnsproduct_id, valuesaction_weight) matrix matrix.fillna(0) return matrix看著代碼不難實(shí)際踩過的坑是在寫入推薦結(jié)果表的時(shí)候如果用戶行為特別多全量寫入的耗時(shí)就會(huì)比較長(zhǎng)容易把接口拖垮。所以我把離線計(jì)算和接口請(qǐng)求做了解耦離線計(jì)算出的推薦結(jié)果由后臺(tái)任務(wù)寫入推薦結(jié)果表接口只做查詢動(dòng)作。這個(gè)等下面部署部分詳細(xì)說。3.2 Item-Based協(xié)同過濾的相似度計(jì)算基于物品的協(xié)同過濾核心分兩步第一步算物品之間的相似度矩陣第二步根據(jù)用戶歷史行為把相似度高的物品推薦給用戶。物品相似度的計(jì)算方式有很多種最常見的有余弦相似度、皮爾遜相關(guān)系數(shù)、Jaccard相似度。我這里用的是余弦相似度因?yàn)檫@個(gè)指標(biāo)計(jì)算簡(jiǎn)單效果穩(wěn)定對(duì)數(shù)據(jù)稀疏場(chǎng)景的容忍度也相對(duì)更高。余弦相似度的公式看著抽象但其實(shí)通俗解釋一下就是兩個(gè)向量夾角的余弦值夾角越小說明兩個(gè)向量越相似。放在場(chǎng)景里理解就是計(jì)算兩件商品被同一群用戶產(chǎn)生過行為的一致程度。比如商品A被用戶甲、乙、丙瀏覽或購(gòu)買過商品B也被用戶甲、乙、丙瀏覽或購(gòu)買過那么這兩件商品的向量就很接近相似度就高。在Python里計(jì)算也很簡(jiǎn)單直接調(diào)用scikit-learn庫(kù)的pairwise_distances函數(shù)就能得到物品之間的相似度矩陣。from sklearn.metrics.pairwise import cosine_similarity # 矩陣轉(zhuǎn)置變成商品-用戶的矩陣行列原來是用戶-商品 item_matrix matrix.T # 計(jì)算商品之間的余弦相似度 item_similarity cosine_similarity(item_matrix) # 轉(zhuǎn)成DataFrame便于處理 item_sim_df pd.DataFrame(item_similarity, indexitem_matrix.index, columnsitem_matrix.index)算完相似度矩陣后關(guān)鍵一步是做相似商品的篩選。一刀切地把所有相似商品都算作候選是不行的一定要設(shè)置相似度閾值做過濾我用的閾值是0.5低于0.5的相似度不參與推薦。同時(shí)每個(gè)商品的相似商品最多保留Top 20。這里控制一下計(jì)算量和推薦精度不然相似度矩陣全量算下來容易內(nèi)存爆炸。3.3 生成推薦列表的核心邏輯有了物品相似度矩陣接下來就是為用戶生成Top N的推薦列表了。核心邏輯是找出用戶最近有過正反饋行為的商品然后去相似度矩陣?yán)镎页鲞@些商品的相似商品按相似度加權(quán)求和排個(gè)序取前N個(gè)。我在實(shí)現(xiàn)的時(shí)候?qū)ｉT加了一個(gè)時(shí)間衰減函數(shù)。理由是跳蚤市場(chǎng)這類平臺(tái)用戶在一個(gè)月前瀏覽過的商品和昨天剛瀏覽過的商品在當(dāng)前時(shí)刻的興趣權(quán)重不應(yīng)該是一樣的。時(shí)間衰減函數(shù)距離今天越近的行為權(quán)重越高越久遠(yuǎn)的行為權(quán)重越低用指數(shù)衰減來模擬這個(gè)規(guī)律效果明顯好于不衰減的方案。核心代碼是這一段import math from datetime import datetime def generate_recommendations(user_id, user_item_matrix, item_sim_df, top_n10, decay_factor0.98): # 用戶歷史行為 if user_id not in user_item_matrix.index: return [] user_row user_item_matrix.loc[user_id] # 找出用戶有行為的商品 interacted_items user_row[user_row 0].index.tolist() if not interacted_items: return [] # 計(jì)算每個(gè)候選商品的推薦得分 scores {} for item in interacted_items: # 獲取當(dāng)前商品相似度最高的幾個(gè)商品 sim_scores item_sim_df[item].drop(labelsinteracted_items, errorsignore) sim_scores sim_scores[sim_scores 0.5].sort_values(ascendingFalse)[:20] # 用戶對(duì)當(dāng)前商品的興趣強(qiáng)度 user_interest user_row[item] for sim_item, sim_value in sim_scores.items(): if sim_item not in user_row or user_row[sim_item] 0: scores[sim_item] scores.get(sim_item, 0) user_interest * sim_value # 按得分排序取TopN ranked sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] return ranked還記得前面對(duì)瀏覽記錄做了時(shí)長(zhǎng)折算嗎在這里就用上了瀏覽時(shí)間長(zhǎng)的商品user_interest值高一些直接影響推薦得分這樣用戶只看了一眼的商品就不會(huì)成為推薦的主參考而認(rèn)認(rèn)真真看了五分鐘的商品則會(huì)成為主參考。這個(gè)細(xì)節(jié)不算很難但就是這些細(xì)節(jié)決定了算法的推薦質(zhì)量是普通水平還是相對(duì)優(yōu)良。運(yùn)營(yíng)的A同學(xué)做了測(cè)試同一個(gè)用戶用帶時(shí)間衰減和不帶時(shí)間衰減兩版算法跑出來的結(jié)果第一屏的推薦商品準(zhǔn)確率差了大概15%。很直觀的效果差異。3.4 冷啟動(dòng)問題的兜底方案協(xié)同過濾算法最惡心的坑就是冷啟動(dòng)。系統(tǒng)剛上線商品和用戶行為數(shù)據(jù)都很少矩陣稀疏到幾乎每行每列都是0這時(shí)候算法就算跑出來結(jié)果也基本等于瞎推薦。冷啟動(dòng)分為用戶冷啟動(dòng)和物品冷啟動(dòng)。新注冊(cè)的用戶沒有任何行為數(shù)據(jù)推薦算法拿什么算相似度新上架的商品沒有任何人看過買過相似度矩陣?yán)锼l(shuí)都不相似。我的兜底方案分了三層來做。第一次兜底對(duì)于完全沒有行為數(shù)據(jù)的新用戶直接推薦平臺(tái)的熱門商品。熱門商品怎么定義就是最近7天瀏覽次數(shù)最多、收藏次數(shù)最多的商品按權(quán)重排序取前20個(gè)。這個(gè)策略簡(jiǎn)單粗暴但極其有效新用戶進(jìn)來看到大家都在看的商品至少不會(huì)覺得推薦完全不相關(guān)。第二次兜底對(duì)于有少量行為的用戶如果行為數(shù)據(jù)不足以支撐協(xié)同過濾就用基于內(nèi)容的推薦方式。具體實(shí)現(xiàn)是將商品分成若干個(gè)分類比如“教材教輔”、“數(shù)碼產(chǎn)品”、“生活用品”、“運(yùn)動(dòng)戶外”等然后對(duì)用戶瀏覽過的商品類別做統(tǒng)計(jì)找出用戶最感興趣的Top3品類在這些品類下按價(jià)格、熱度綜合排序推薦一些好商品。這套基于內(nèi)容的方案原理不復(fù)雜但實(shí)現(xiàn)后對(duì)冷啟動(dòng)用戶的推薦效果立竿見影。第三次兜底新上架的商品在新品期內(nèi)也就是上架后72小時(shí)內(nèi)在推薦結(jié)果里做一個(gè)加權(quán)操作。具體做法是給新商品一個(gè)初始曝光權(quán)重這樣它們?cè)谟脩羯蓚€(gè)性化推薦列表時(shí)有機(jī)會(huì)被帶上。雖然新商品沒有協(xié)同過濾的相似度數(shù)據(jù)但我們可以在Item-Based協(xié)同過濾的基礎(chǔ)上額外附加一批新商品推薦設(shè)置20%的推薦位留給這類商品。這樣就同時(shí)照顧了用戶體驗(yàn)和新品曝光。這三層兜底方案加起來的實(shí)現(xiàn)成本不高但對(duì)整個(gè)系統(tǒng)的推薦可用性提升是決定性的。沒有兜底方案的推薦系統(tǒng)在早期階段基本是廢的。4. 熱門問題與性能優(yōu)化實(shí)錄4.1 推薦結(jié)果不準(zhǔn)確怎么辦在調(diào)這個(gè)系統(tǒng)時(shí)被問得最多的問題就是推薦結(jié)果不準(zhǔn)推出來的商品用戶根本不想看。這類問題基本可以按下面的思路逐層排查。第一步先檢查數(shù)據(jù)量。如果用戶行為記錄不到50條那協(xié)同過濾效果不好是正常的沒有足夠的歷史數(shù)據(jù)任何推薦算法都白搭。解決辦法是用前面說的兜底策略優(yōu)先走熱門推薦或基于內(nèi)容推薦。第二步檢查評(píng)分矩陣的稀疏度。要算一個(gè)數(shù)據(jù)指標(biāo)矩陣中非零元素占總元素的比例如果低于1%那協(xié)同過濾的效果就會(huì)打折。跳蚤市場(chǎng)數(shù)據(jù)天生稀疏解決辦法是對(duì)行為數(shù)據(jù)進(jìn)行加權(quán)比如購(gòu)買過的商品權(quán)重調(diào)高到5分瀏覽只有1分提高強(qiáng)信號(hào)數(shù)據(jù)的占比。第三步檢查相似度閾值。我默認(rèn)設(shè)置0.5但這個(gè)值不是固定的。如果發(fā)現(xiàn)推薦的相似商品太少可以適當(dāng)降低到0.3如果推薦的相似商品明顯沒多大相關(guān)性就調(diào)高到0.6。這個(gè)參數(shù)需要在不同數(shù)據(jù)集上反復(fù)試驗(yàn)。第四步看推薦結(jié)果表的兜底來源占比。我們每一條推薦記錄都帶一個(gè)來源字段如果發(fā)現(xiàn)大量推薦走的都是熱門推薦而不是協(xié)同過濾說明協(xié)同過濾的有效覆蓋率不足需要針對(duì)性排查是數(shù)據(jù)稀疏還是相似度矩陣計(jì)算錯(cuò)誤。4.2 Redis緩存與接口響應(yīng)優(yōu)化推薦接口和首頁(yè)接口是性能考量的重中之重。首頁(yè)接口要聚合推薦商品、熱門商品、最新商品等多個(gè)數(shù)據(jù)源如果沒有緩存數(shù)據(jù)庫(kù)壓力會(huì)非常大。我用Redis做了一個(gè)兩級(jí)緩存的方案。第一級(jí)緩存存推薦商品的Id列表Key設(shè)計(jì)成recommend:user:{userId}有效時(shí)間設(shè)成了30分鐘。為什么是30分鐘而不是更長(zhǎng)因?yàn)橥扑]結(jié)果如果太久不更新用戶每次打開看到的東西都一模一樣時(shí)間長(zhǎng)了就會(huì)產(chǎn)生審美疲勞30分鐘算是一個(gè)兼顧實(shí)時(shí)性和緩存命中率的折中值。第二級(jí)緩存存了商品本身的詳細(xì)信息Key設(shè)計(jì)成product:info:{productId}有效時(shí)間設(shè)成2小時(shí)。第一級(jí)緩存存儲(chǔ)推薦id列表第二級(jí)緩存存儲(chǔ)商品詳細(xì)信息。三級(jí)緩存把商品詳情從數(shù)據(jù)庫(kù)里挪到Redis里商品詳情的查詢壓力大幅下降實(shí)測(cè)下來首頁(yè)的接口響應(yīng)時(shí)間從150毫秒降到了50毫秒以下流暢度大幅提升。還有一點(diǎn)要注意的細(xì)節(jié)修改商品信息、下架商品時(shí)必須同步刪除對(duì)應(yīng)的商品緩存不然用戶看到的還是舊的商品信息這就是經(jīng)典的一致性維護(hù)問題。我實(shí)現(xiàn)方式是在商品更新的Service方法里統(tǒng)一調(diào)用Redis刪除操作寧多刪勿漏刪。4.3 并發(fā)扣減庫(kù)存與訂單一致性跳蚤市場(chǎng)和常規(guī)電商有一個(gè)本質(zhì)區(qū)別每件商品只有一個(gè)庫(kù)存量。這意味著如果兩個(gè)用戶同時(shí)下單購(gòu)買同一個(gè)商品只能有一個(gè)人成功另一個(gè)人必須收到“手慢了商品已被購(gòu)買”的提示。如果只是減庫(kù)存不加控制用常規(guī)的先查庫(kù)存再更新庫(kù)存的方式高并發(fā)場(chǎng)景下就會(huì)產(chǎn)生超賣問題。兩個(gè)請(qǐng)求同時(shí)查到庫(kù)存是1都判斷可以買都執(zhí)行了下單最后庫(kù)存變成-1這就是超賣。解決辦法是用數(shù)據(jù)庫(kù)行鎖配合樂觀鎖。在扣減庫(kù)存時(shí)執(zhí)行一條帶條件更新的SQL語(yǔ)句只有當(dāng)前庫(kù)存大于0時(shí)才允許扣減同時(shí)受影響的行數(shù)為1才代表更新成功沒成功就說明已經(jīng)被別人搶了。UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 0MyBatis加不加Transactional這個(gè)細(xì)節(jié)也要留意?？蹨p庫(kù)存、創(chuàng)建訂單這兩個(gè)操作必須加事務(wù)任何一個(gè)失敗都要回滾保證數(shù)據(jù)一致性。這段代碼是整個(gè)訂單流程里最容易出bug的地方一定要把單元測(cè)試寫好模擬并發(fā)場(chǎng)景反復(fù)壓測(cè)。4.4 定時(shí)任務(wù)與離線計(jì)算調(diào)優(yōu)推薦結(jié)果的計(jì)算不需要實(shí)時(shí)跑更合理的做法是定時(shí)任務(wù)離線計(jì)算。我用了Spring Boot內(nèi)置的Scheduled注解實(shí)現(xiàn)定時(shí)任務(wù)固定在每天凌晨3點(diǎn)全量計(jì)算一次這個(gè)時(shí)間點(diǎn)服務(wù)器負(fù)載最低。每天凌晨計(jì)算的是全量推薦結(jié)果寫入推薦結(jié)果表。另外內(nèi)部做了一套增量計(jì)算邏輯每30分鐘計(jì)算一次只算最近30分鐘內(nèi)有新行為數(shù)據(jù)的那些用戶更新他們的推薦結(jié)果保證推薦列表的時(shí)效性。兩套計(jì)算邏輯配合起來全量保證數(shù)據(jù)基礎(chǔ)增量保證實(shí)時(shí)反饋服務(wù)器壓力也不會(huì)太大。離線計(jì)算的核心數(shù)據(jù)結(jié)構(gòu)是物品相似度矩陣全量計(jì)算時(shí)我會(huì)把它序列化保存到本地文件。增量計(jì)算時(shí)加載這個(gè)相似度矩陣只更新行為發(fā)生變化的用戶避免每次都要全量重新加載所有數(shù)據(jù)。這個(gè)優(yōu)化直接把定時(shí)任務(wù)的平均執(zhí)行時(shí)間從十幾分鐘壓到了幾分鐘。5. 部署上線與運(yùn)營(yíng)落地5.1 項(xiàng)目部署與安全合規(guī)部署方案選了一臺(tái)2核4G的云服務(wù)器Linux系統(tǒng)。后端項(xiàng)目打成JAR包通過systemd配置成守護(hù)進(jìn)程開機(jī)自啟加崩潰自動(dòng)重啟。前端用Nginx托管靜態(tài)文件后端接口用反向代理映射到域名路徑下Nginx是前端構(gòu)建產(chǎn)物最經(jīng)典的托管方案后端接口也走Nginx代理順便解決跨域問題。Java啟動(dòng)參數(shù)里-Xms和-Xmx設(shè)為512m配合上G1垃圾回收器。2核4G的服務(wù)器配置跑這套系統(tǒng)完全可以駕馭實(shí)測(cè)并發(fā)在50左右時(shí)CPU占用率大約40%響應(yīng)延遲在100毫秒內(nèi)對(duì)校園場(chǎng)景來說綽綽有余。這里要多提一句合規(guī)問題。一個(gè)跳蚤市場(chǎng)交易平臺(tái)不管規(guī)模大小該做的合規(guī)操作一樣不能少用戶實(shí)名注冊(cè)手機(jī)號(hào)驗(yàn)證碼校驗(yàn)必須有商品發(fā)布要做敏感詞過濾違規(guī)內(nèi)容條目要提前準(zhǔn)備交易糾紛要有申訴機(jī)制和客服入口。我特別提醒了學(xué)弟平臺(tái)方對(duì)發(fā)布違禁品的用戶要及時(shí)警告和處理這些不是可選項(xiàng)而是必選項(xiàng)。隱私數(shù)據(jù)這塊用戶的手機(jī)號(hào)和地址在數(shù)據(jù)庫(kù)里需要做加密存儲(chǔ)日志打印也要脫敏處理。5.2 數(shù)據(jù)冷啟動(dòng)后的運(yùn)營(yíng)節(jié)奏系統(tǒng)剛上線的最初兩周是冷啟動(dòng)期數(shù)據(jù)量自然是很貧乏的。這個(gè)階段推薦系統(tǒng)的核心任務(wù)不是算法優(yōu)化而是制造初始數(shù)據(jù)。我的做法是在正式運(yùn)營(yíng)前先導(dǎo)入一批模擬數(shù)據(jù)。用Python的Faker庫(kù)生成模擬用戶、模擬商品、模擬瀏覽和模擬購(gòu)買記錄大概構(gòu)造成500個(gè)用戶、2000件商品、3萬(wàn)條行為數(shù)據(jù)。這波操作對(duì)冷啟動(dòng)階段的推薦系統(tǒng)至關(guān)重要——協(xié)同過濾算法的效果和輸入數(shù)據(jù)的規(guī)模強(qiáng)相關(guān)沒有這批模擬數(shù)據(jù)系統(tǒng)上線后運(yùn)行一整周也未必能收集到足以支撐算法的數(shù)據(jù)量也就談不上推薦效果。這些模擬數(shù)據(jù)的生成不是隨機(jī)亂造的要符合跳蚤市場(chǎng)的業(yè)務(wù)規(guī)律。比如大四學(xué)生購(gòu)買英語(yǔ)考研資料的記錄相對(duì)集中大二學(xué)生瀏覽高數(shù)教材的記錄多一些這樣人為構(gòu)造出幾類標(biāo)簽清晰的用戶群體協(xié)同過濾才有足夠的行為交集可以計(jì)算推薦結(jié)果才能顯得相對(duì)合理。6. 常見問題排查與避坑指南微服務(wù)權(quán)限管理系統(tǒng)是這幾年非常經(jīng)典的一套畢業(yè)設(shè)計(jì)選題但我見過太多人把它做成純粹的CRUD后臺(tái)那樣反而顯得沒深度。我這套跳蚤市場(chǎng)系統(tǒng)的設(shè)計(jì)思路不一樣它的加分項(xiàng)在于推薦算法的運(yùn)用——不是給用戶堆功能頁(yè)面而是把底層算法和業(yè)務(wù)系統(tǒng)結(jié)合成一個(gè)整體。最近有學(xué)弟問這套系統(tǒng)能不能擴(kuò)充成校園綜合二手教學(xué)系統(tǒng)這個(gè)想法完全可以做把商品對(duì)象抽象成類型字段加上閑置教材、尋求輔導(dǎo)、尋找拼車伙伴這些業(yè)務(wù)場(chǎng)景就能復(fù)用現(xiàn)成框架。完成一個(gè)基礎(chǔ)版本之后還可以繼續(xù)優(yōu)化算法參數(shù)調(diào)整、重構(gòu)相似度計(jì)算、引入更細(xì)的行為權(quán)重策略等持續(xù)打磨細(xì)節(jié)比推倒重來做花哨的新功能要更值錢。復(fù)盤自己這幾年做過的項(xiàng)目有推薦算法的價(jià)值感確實(shí)會(huì)高很多這類系統(tǒng)在面試考察中對(duì)項(xiàng)目深度的體現(xiàn)非常加分。最后分享一個(gè)排查問題的技巧。有用戶反饋推薦列表刷不出來我的排查思路按這個(gè)順序進(jìn)行先看請(qǐng)求有沒有打到后端是用瀏覽器開發(fā)者工具的Network面板看的再查Redis里有沒有緩存數(shù)據(jù)用tkey的命令然后查數(shù)據(jù)庫(kù)推薦結(jié)果表有沒有數(shù)據(jù)最后看定時(shí)任務(wù)日志有沒有正常執(zhí)行。查了幾次就發(fā)現(xiàn)是定時(shí)任務(wù)在數(shù)據(jù)量大的時(shí)候執(zhí)行超時(shí)任務(wù)被跳過導(dǎo)致推薦結(jié)果表沒有更新。解決方式是給定時(shí)任務(wù)加一個(gè)分布式鎖同時(shí)把全量計(jì)算改成增量計(jì)算這個(gè)問題就徹底解決了。如果打開一篇文章到這里你正在為推薦系統(tǒng)相關(guān)的項(xiàng)目發(fā)愁這套思路和代碼實(shí)現(xiàn)完全可以復(fù)用到你自己的業(yè)務(wù)場(chǎng)景里核心是掌握“數(shù)據(jù)預(yù)處理 - 相似度計(jì)算 - 推薦生成 - 兜底策略”這條主線邏輯剩下的都只是實(shí)現(xiàn)細(xì)節(jié)問題。