簡介互聯(lián)網(wǎng)時(shí)代的信息過載讓推薦系統(tǒng)成為電商、外賣、內(nèi)容平臺(tái)的關(guān)鍵技術(shù)而協(xié)同過濾則是其中應(yīng)用最廣、最容易落地的經(jīng)典算法。它不需要昂貴的GPU和海量數(shù)據(jù)集僅依靠用戶行為數(shù)據(jù)通過余弦相似度、皮爾遜相關(guān)系數(shù)等方法計(jì)算用戶或物品之間的相似關(guān)系就能生成個(gè)性化的Top-N推薦列表。這一技術(shù)價(jià)值在于兼顧效果與可解釋性尤其適合美食、電影、圖書等興趣相對(duì)穩(wěn)定的垂直場(chǎng)景。以美食推薦系統(tǒng)畢業(yè)設(shè)計(jì)為例可將協(xié)同過濾算法與Python、Flask、MySQL結(jié)合完成從評(píng)分?jǐn)?shù)據(jù)清洗、相似度矩陣構(gòu)建、UserCF/ItemCF算法實(shí)現(xiàn)到推薦接口開發(fā)的全流程并針對(duì)冷啟動(dòng)和數(shù)據(jù)稀疏問題給出工程化解決方案。這套設(shè)計(jì)思路同樣可遷移到其他物品推薦項(xiàng)目是理解推薦系統(tǒng)原理與工程實(shí)踐的理想切入點(diǎn)。1. 項(xiàng)目整體設(shè)計(jì)與核心思路1.1 為什么選“美食推薦系統(tǒng)”作為課題如果你是計(jì)算機(jī)、軟件工程或者大數(shù)據(jù)相關(guān)專業(yè)的學(xué)生應(yīng)該能感覺到畢業(yè)設(shè)計(jì)選題這件事有多關(guān)鍵。題目太簡單答辯的時(shí)候?qū)煄讉€(gè)問題就把你問住了題目太難開發(fā)周期拖到天荒地老論文還憋不出字。美食推薦系統(tǒng)這個(gè)題我覺得是性價(jià)比非常高的一類選擇。先說行業(yè)背景。推薦系統(tǒng)在電商、短視頻、外賣平臺(tái)里已經(jīng)是標(biāo)配技術(shù)了比如你打開外賣軟件會(huì)看到“猜你喜歡”打開菜譜App會(huì)看到“今日推薦”這些都是推薦算法在背后工作。把協(xié)同過濾算法落到美食場(chǎng)景既有真實(shí)的應(yīng)用價(jià)值又有清晰可拆解的技術(shù)點(diǎn)用來做畢業(yè)設(shè)計(jì)或課程項(xiàng)目素材非常充足。再說技術(shù)層面。協(xié)同過濾Collaborative Filtering是推薦系統(tǒng)里最經(jīng)典的算法家族它不像深度學(xué)習(xí)方法那樣需要昂貴的GPU和超大數(shù)據(jù)集只要有一臺(tái)普通筆記本、一份像樣的用戶評(píng)分?jǐn)?shù)據(jù)就能跑出效果明顯的推薦結(jié)果。這對(duì)本科生或剛?cè)腴T的研究生來說非常友好。1.2 一個(gè)系統(tǒng)拆開看推薦引擎只是核心不是全部我見過很多同學(xué)做這類系統(tǒng)上來就悶頭寫算法結(jié)果算法寫完發(fā)現(xiàn)系統(tǒng)交互、數(shù)據(jù)庫、可視化、論文圖表全都沒有著落。真正完整的“美食推薦系統(tǒng)”應(yīng)該包含三層。第一層是數(shù)據(jù)層。用戶信息、菜品信息、用戶對(duì)菜品的評(píng)分行為這些數(shù)據(jù)要能存下來、查得快、方便做分析。第二層是算法層也就是協(xié)同過濾推薦引擎接收用戶的評(píng)分歷史輸出Top-N推薦列表。第三層是應(yīng)用層用戶通過網(wǎng)頁或桌面端的界面注冊(cè)登錄、瀏覽菜品、給菜品打分然后看到一個(gè)“為你推薦”的列表。三層都打通這個(gè)系統(tǒng)的完整度才算合格。而且這三層恰好對(duì)應(yīng)畢業(yè)論文里的幾個(gè)核心章節(jié)需求分析、系統(tǒng)設(shè)計(jì)、核心算法實(shí)現(xiàn)、系統(tǒng)測(cè)試。也就是說你每做完一層論文就多出一章素材不會(huì)出現(xiàn)“算法做得挺好但論文湊不夠字?jǐn)?shù)”的尷尬。還有一點(diǎn)值得注意這套系統(tǒng)的設(shè)計(jì)思路可以通用。今天做美食明天把數(shù)據(jù)換成電影、圖書、音樂算法邏輯不需要大改。這也是我在答辯時(shí)比較喜歡強(qiáng)調(diào)的點(diǎn)——項(xiàng)目的擴(kuò)展性和方法論價(jià)值這比單純說“我實(shí)現(xiàn)了一個(gè)算法”要有說服力得多。1.3 技術(shù)棧選型別為了炫技選不熟悉的東西我整理過一份做這類系統(tǒng)的主流技術(shù)方案你可以根據(jù)自己的熟悉程度來選。層次推薦方案A主流推薦方案B輕量說明語言Python 3.8Python 3.8算法生態(tài)最成熟pandas/numpy/scikit-learn齊全Web框架FlaskDjangoFlask輕量好上手適合單體小系統(tǒng)Django自帶Admin后臺(tái)管理方便數(shù)據(jù)庫MySQLSQLite開發(fā)調(diào)試用SQLite省事寫論文建議用MySQL體現(xiàn)“企業(yè)級(jí)”前端Bootstrap jQuery原生HTML CSS不追求復(fù)雜交互的話Bootstrap最快出效果算法實(shí)現(xiàn)手動(dòng)實(shí)現(xiàn) scikit-learn驗(yàn)證僅手動(dòng)實(shí)現(xiàn)手動(dòng)實(shí)現(xiàn)能寫在論文里sklearn用于交叉驗(yàn)證結(jié)果個(gè)人建議如果時(shí)間緊Flask SQLite Bootstrap 手寫協(xié)同過濾這個(gè)組合最穩(wěn)。Python的安裝和環(huán)境配置是個(gè)老話題常見坑包括環(huán)境變量沒配好、pip下載慢、numpy版本沖突等直接用Anaconda或者Python官方安裝包裝好再用pip install -i https://pypi.tuna.tsinghua.edu.cn/simple flask pandas numpy這類國內(nèi)鏡像源裝依賴能把時(shí)間省下一大截。提示盡量別選你不熟悉的框架。畢業(yè)設(shè)計(jì)的核心是把推薦原理講清楚、系統(tǒng)能跑起來不是展示你會(huì)多少冷門技術(shù)。2. 協(xié)同過濾算法核心原理解析2.1 兩種路線UserCF與ItemCF協(xié)同過濾的核心思想一句話就能說透跟你相似的人喜歡吃的東西你大概率也喜歡你以前喜歡的東西的相似品你大概率也會(huì)喜歡。前一句話對(duì)應(yīng)基于用戶的協(xié)同過濾UserCF后一句話對(duì)應(yīng)基于物品的協(xié)同過濾ItemCF。UserCF的步驟是第一步計(jì)算用戶之間的相似度找到當(dāng)前用戶的“鄰居”第二步把鄰居們?cè)u(píng)分高但當(dāng)前用戶沒吃過的菜品聚合起來按預(yù)測(cè)評(píng)分排序輸出推薦列表。ItemCF的步驟是第一步計(jì)算菜品之間的相似度注意這個(gè)相似度是基于用戶行為算的不是基于菜品的原料、口味等屬性第二步根據(jù)用戶歷史評(píng)分過的菜品找出相似的菜品按預(yù)測(cè)評(píng)分排序輸出推薦。兩個(gè)路線各有適合的場(chǎng)景。UserCF更偏“社交化”適合新聞、社區(qū)這類用戶興趣變化快的場(chǎng)景ItemCF更偏“個(gè)性化”適合圖書、電影、美食這類興趣相對(duì)穩(wěn)定的場(chǎng)景。做美食推薦系統(tǒng)我在實(shí)際開發(fā)中其實(shí)更推薦ItemCF作為主力算法原因后面細(xì)說。2.2 相似度計(jì)算的三種常用方法無論UserCF還是ItemCF都繞不開“相似度計(jì)算”這個(gè)核心步驟。常用的有三種方法。余弦相似度是最容易理解的把用戶A的評(píng)分向量和用戶B的評(píng)分向量看作高維空間里的兩個(gè)向量計(jì)算它們夾角的余弦值。夾角越小余弦值越接近1說明兩個(gè)人越相似。計(jì)算公式是cos(θ) (A·B) / (|A| × |B|)在Python里用numpy實(shí)現(xiàn)只需要幾行代碼import numpy as np def cosine_similarity(vec_a, vec_b): # 兩個(gè)向量必須長度一致對(duì)應(yīng)位置是同一個(gè)菜品 dot np.dot(vec_a, vec_b) norm_a np.linalg.norm(vec_a) norm_b np.linalg.norm(vec_b) if norm_a 0 or norm_b 0: return 0 return dot / (norm_a * norm_b)皮爾遜相關(guān)系數(shù)是余弦相似度的升級(jí)版它對(duì)評(píng)分做了“中心化”處理也就是減去每個(gè)用戶的平均打分。這樣做的好處是如果一個(gè)用戶普遍打分偏高給什么都給4分另一個(gè)用戶打分偏低喜歡才給3分直接用余弦相似度會(huì)誤判他們口味不同而皮爾遜相關(guān)系數(shù)能消除這種評(píng)分尺度差異。公式是r Σ(A_i - avgA)(B_i - avgB) / sqrt(Σ(A_i - avgA)^2 × Σ(B_i - avgB)^2)修正余弦相似度是ItemCF里常用的變體用來消除不同用戶打分習(xí)慣對(duì)物品相似度的影響。它的做法是計(jì)算物品相似度時(shí)先把每個(gè)用戶的評(píng)分減去該用戶的平均分再套用余弦相似度公式。這三種方法的選擇邏輯我建議這么定數(shù)據(jù)稀疏、評(píng)分尺度差異大優(yōu)先皮爾遜評(píng)分?jǐn)?shù)據(jù)相對(duì)稠密、想快速看到效果用余弦ItemCF場(chǎng)景直接上修正余弦。2.3 評(píng)分預(yù)測(cè)最常用的加權(quán)求和公式算完相似度之后下一步是預(yù)測(cè)用戶對(duì)未吃過菜品的評(píng)分。這里最常用的方法是“加權(quán)求和”公式長這樣pred(u, i) Σ(sim(u, v) × r(v, i)) / Σ(sim(u, v))意思是用戶u對(duì)菜品i的預(yù)測(cè)評(píng)分等于“與u最相似的K個(gè)用戶v對(duì)菜品i的評(píng)分”的加權(quán)平均權(quán)重就是u和v的相似度。分母做歸一化防止不同K取值導(dǎo)致分?jǐn)?shù)范圍不穩(wěn)定。ItemCF的預(yù)測(cè)公式稍微有點(diǎn)不同它的加權(quán)對(duì)象是“用戶u評(píng)過分的物品與目標(biāo)物品i的相似度”pred(u, i) Σ(sim(i, j) × r(u, j)) / Σ(sim(i, j))在實(shí)際寫代碼的時(shí)候這個(gè)公式更適合用一個(gè)預(yù)計(jì)算好的“物品相似度矩陣”來查表而不是每次請(qǐng)求都現(xiàn)場(chǎng)算一遍。把相似度矩陣提前算好存下來推薦接口的響應(yīng)速度能從秒級(jí)降到毫秒級(jí)這個(gè)優(yōu)化在論文的“系統(tǒng)性能優(yōu)化”章節(jié)里是很好的加分項(xiàng)。3. 數(shù)據(jù)方案與預(yù)處理實(shí)戰(zhàn)3.1 評(píng)分?jǐn)?shù)據(jù)從哪來別在爬蟲上栽跟頭開發(fā)推薦系統(tǒng)最理想的數(shù)據(jù)集是像MovieLens那樣公開的評(píng)分?jǐn)?shù)據(jù)但美食領(lǐng)域公開數(shù)據(jù)集相對(duì)少。常見的解決方案有兩條路。第一條路是自己造數(shù)據(jù)。讓宿舍同學(xué)、網(wǎng)友幫忙填一批評(píng)分比如20個(gè)用戶對(duì)50道菜品的打分評(píng)分范圍1到5。數(shù)據(jù)量雖小但能跑通全鏈路而且你可以清楚知道每一行數(shù)據(jù)的來龍去脈。對(duì)畢業(yè)設(shè)計(jì)來說數(shù)據(jù)量不是問題算法的完整性和推理過程才是重點(diǎn)。第二條路是用爬蟲抓公開數(shù)據(jù)。這個(gè)方向要特別謹(jǐn)慎抓取網(wǎng)站數(shù)據(jù)要遵守目標(biāo)網(wǎng)站的robots協(xié)議和用戶條款只抓合法允許的公開信息做個(gè)人學(xué)習(xí)研究不得用于任何商業(yè)用途。我個(gè)人的建議是優(yōu)先找公開的菜譜數(shù)據(jù)集比如一些開源社區(qū)整理的帶評(píng)分字段的菜品數(shù)據(jù)或者自己構(gòu)造別把精力耗在爬蟲和反爬對(duì)抗上那對(duì)本課題的核心目標(biāo)幫助不大。注意論文里寫數(shù)據(jù)處理流程時(shí)一定要說明數(shù)據(jù)來源和預(yù)處理規(guī)則。答辯老師很可能會(huì)問“你的數(shù)據(jù)量這么小推薦結(jié)果有說服力嗎”這時(shí)候你要回答的是算法流程的合理性和評(píng)估指標(biāo)的設(shè)計(jì)而不是夸大數(shù)據(jù)的規(guī)模。3.2 核心數(shù)據(jù)表設(shè)計(jì)用戶、菜品、評(píng)分設(shè)計(jì)數(shù)據(jù)庫表的時(shí)候我習(xí)慣遵循“常規(guī)字段 推薦專用字段”的思維。用戶表user的常規(guī)字段包括user_id、username、password、register_time。如果想給系統(tǒng)加一點(diǎn)個(gè)性化可以加food_preference字段存用戶偏好的口味比如“辣、清淡、甜”之類的標(biāo)簽。但要注意協(xié)同過濾本身不需要這些屬性字段加上它只是為了在冷啟動(dòng)場(chǎng)景用戶還沒有評(píng)分歷史時(shí)有東西可用。菜品表dish的常規(guī)字段包括dish_id、dish_name、category分類如川菜、粵菜、甜品、price、description、image_url。你可以額外加一個(gè)avg_rating字段用來存菜品平均分。這個(gè)字段有兩個(gè)用處一是新用戶冷啟動(dòng)時(shí)可以按平均分推薦二是做排行榜功能時(shí)直接用SQL排序不用現(xiàn)場(chǎng)算。評(píng)分表rating是最核心的一張表字段包括rating_id、user_id、dish_id、score、rating_time。這張表一定要給(user_id, dish_id)建聯(lián)合唯一索引防止同一個(gè)用戶對(duì)同一道菜重復(fù)評(píng)分。每次寫入評(píng)分時(shí)順便同步更新dish表的avg_rating字段這樣排行榜和推薦候選池的數(shù)據(jù)始終是最新的。3.3 數(shù)據(jù)清洗稀疏矩陣的坑與應(yīng)對(duì)協(xié)同過濾的數(shù)據(jù)清洗和普通Web項(xiàng)目不太一樣關(guān)鍵在“評(píng)分矩陣”的構(gòu)建。假設(shè)有20個(gè)用戶、50道菜全量評(píng)分是20×501000個(gè)評(píng)分。但現(xiàn)實(shí)里每個(gè)用戶可能只評(píng)了10道菜那矩陣?yán)锞陀?00個(gè)空位稀疏度達(dá)到了80%。直接用這個(gè)矩陣算相似度結(jié)果會(huì)非常不穩(wěn)定。我的處理順序是第一步過濾掉評(píng)分?jǐn)?shù)量少于5條的用戶這些人提供的信息太少算出的相似度沒有統(tǒng)計(jì)意義第二步過濾掉被評(píng)分次數(shù)少于3次的菜品這些菜屬于長尾中的長尾推薦出來用戶也沒聽說過第三步補(bǔ)全空缺值常用兩種策略填0適合余弦相似度或填用戶平均分適合皮爾遜系數(shù)。在Python里構(gòu)建評(píng)分矩陣用pandas的pivot_table可以一行搞定import pandas as pd # 假設(shè)rating_df是原始評(píng)分表字段為user_id, dish_id, score rating_matrix rating_df.pivot_table( indexuser_id, columnsdish_id, valuesscore ).fillna(0) # 打印矩陣形狀確認(rèn)行列對(duì)不對(duì) print(rating_matrix.shape)這個(gè)矩陣的行是用戶列是菜品值就是評(píng)分。后面計(jì)算相似度的時(shí)候每次取一行就是一個(gè)用戶的評(píng)分向量非常方便。我在實(shí)際項(xiàng)目里習(xí)慣把這步處理封裝成build_rating_matrix(user_rating_df)這樣的函數(shù)輸入原始評(píng)分表輸出可直接用于相似度計(jì)算的矩陣保持代碼結(jié)構(gòu)清晰。4. 推薦引擎完整實(shí)現(xiàn)從算法到接口4.1 工具函數(shù)先算好相似度矩陣在寫推薦函數(shù)之前先把相似度矩陣準(zhǔn)備好。我習(xí)慣用一個(gè)單獨(dú)的函數(shù)來算UserCF的用戶相似度矩陣再用另一個(gè)函數(shù)算ItemCF的物品相似度矩陣。用戶相似度矩陣的實(shí)現(xiàn)思路對(duì)每一個(gè)用戶i遍歷所有用戶j計(jì)算i和j的皮爾遜相關(guān)系數(shù)。數(shù)據(jù)規(guī)模不大時(shí)雙重循環(huán)是沒問題的。20個(gè)用戶算下來最多400次相似度計(jì)算毫秒級(jí)完成。import pandas as pd import numpy as np def calculate_user_similarity(rating_matrix): 計(jì)算用戶之間的皮爾遜相似度矩陣 rating_matrix: DataFrame行是用戶列是菜品 返回: 相似度DataFrame行和列都是用戶id users rating_matrix.index.tolist() sim_matrix pd.DataFrame(0, indexusers, columnsusers) for u in users: for v in users: if u v: sim_matrix.loc[u, v] 1.0 continue # 找出兩個(gè)用戶都評(píng)過分的菜品 u_ratings rating_matrix.loc[u] v_ratings rating_matrix.loc[v] # 只取雙方評(píng)分都 0 的項(xiàng) common_mask (u_ratings 0) (v_ratings 0) common_items u_ratings[common_mask] if len(common_items) 2: sim_matrix.loc[u, v] 0 continue # 皮爾遜相關(guān)系數(shù) corr np.corrcoef( u_ratings[common_mask].values, v_ratings[common_mask].values )[0, 1] if np.isnan(corr): corr 0 sim_matrix.loc[u, v] round(corr, 4) return sim_matrix這段代碼里有兩個(gè)細(xì)節(jié)值得注意一是common_items 2時(shí)直接置0這是為了避免“兩個(gè)用戶只共同評(píng)過一道菜系數(shù)恰好算出來是1”這種偶然情況二是np.corrcoef可能返回NaN原因是共同評(píng)分項(xiàng)的方差為0比如兩個(gè)用戶共同評(píng)分都是5分要把它處理成0否則會(huì)影響后續(xù)計(jì)算。4.2 基于用戶的協(xié)同過濾推薦有了相似度矩陣UserCF的推薦函數(shù)就順理成章了。核心邏輯是找到和目標(biāo)用戶最相似的K個(gè)用戶K通常取5到10把這K個(gè)用戶評(píng)分高且目標(biāo)用戶沒吃過的菜品找出來按相似度加權(quán)算預(yù)測(cè)分返回Top-N。def recommend_by_user_cf(user_id, rating_matrix, sim_matrix, top_n10, k5): 基于用戶的協(xié)同過濾推薦 user_id: 目標(biāo)用戶 rating_matrix: 用戶-菜品評(píng)分矩陣 sim_matrix: 用戶相似度矩陣 top_n: 返回推薦菜品數(shù)量 k: 鄰居數(shù)量 if user_id not in rating_matrix.index: return [] # 目標(biāo)用戶已評(píng)分的菜品 rated set(rating_matrix.loc[user_id][rating_matrix.loc[user_id] 0].index) # 獲取相似用戶列表排除自己 sim_scores sim_matrix.loc[user_id].sort_values(ascendingFalse) # 只看相似度大于0的鄰居 neighbors [(uid, score) for uid, score in sim_scores.items() if uid ! user_id and score 0] neighbors neighbors[:k] if not neighbors: return [] # 候選菜品集合 candidate_scores {} candidate_weight {} for neighbor_id, sim_score in neighbors: neighbor_ratings rating_matrix.loc[neighbor_id] # 鄰居評(píng)分過的菜品 neighbor_rated_items neighbor_ratings[neighbor_ratings 0] for dish_id, score in neighbor_rated_items.items(): if dish_id in rated: continue # 用戶已經(jīng)吃過了不推薦 candidate_scores[dish_id] candidate_scores.get(dish_id, 0) sim_score * score candidate_weight[dish_id] candidate_weight.get(dish_id, 0) sim_score # 歸一化計(jì)算最終預(yù)測(cè)分 predictions {} for dish_id, total_score in candidate_scores.items(): if candidate_weight[dish_id] 0: predictions[dish_id] total_score / candidate_weight[dish_id] # 按預(yù)測(cè)分從高到低排序 sorted_predictions sorted(predictions.items(), keylambda x: x[1], reverseTrue) return sorted_predictions[:top_n]這里的加權(quán)公式用了“歸一化”核心原因是避免相似度值大的鄰居帶偏結(jié)果。你設(shè)想一下如果用戶A只和一個(gè)人特別像這個(gè)人給某道菜打了5分A對(duì)這道菜的預(yù)測(cè)分就是5分但如果有三個(gè)不那么像的人也打了4分平均下來才是更穩(wěn)的結(jié)果。歸一化恰好能平衡這個(gè)偏差。4.3 基于物品的協(xié)同過濾推薦ItemCF的推薦邏輯有點(diǎn)不同。它的核心不是“看鄰居吃了什么”而是“看你吃過的菜與什么菜相似”。def calculate_item_similarity(rating_matrix): 計(jì)算物品之間的修正余弦相似度矩陣 items rating_matrix.columns.tolist() sim_matrix pd.DataFrame(0, indexitems, columnsitems) # 物品的評(píng)分向量 item_vectors {} # 對(duì)每個(gè)菜品計(jì)算被用戶評(píng)分的平均分修正 for item in items: item_rating rating_matrix[item] # 對(duì)每個(gè)用戶做中心化處理 centered [] user_ids [] for uid in rating_matrix.index: score item_rating[uid] if score 0: # 該用戶所有評(píng)分的平均值 user_avg rating_matrix.loc[uid][rating_matrix.loc[uid] 0].mean() if user_avg user_avg: # 檢查非NaN centered.append(score - user_avg) user_ids.append(uid) item_vectors[item] (np.array(centered), user_ids) for i, item_i in enumerate(items): for j, item_j in enumerate(items): if i j: sim_matrix.loc[item_i, item_j] 1.0 continue # 找出同時(shí)評(píng)分過物品i和物品j的用戶 vec_i, users_i item_vectors[item_i] # 構(gòu)建用戶到評(píng)分的映射 map_i dict(zip(users_i, vec_i)) common [map_i[u] for u in users_i if u in dict(zip(*item_vectors[item_j][::-1]))] # 實(shí)際項(xiàng)目中更簡潔的寫法 set_i set(users_i) set_j set(item_vectors[item_j][1]) common_users set_i set_j common_i [] common_j [] for uid in common_users: common_i.append(map_i[uid]) common_j.append(item_vectors[item_j][0][item_vectors[item_j][1].index(uid)]) if len(common_users) 2: sim_matrix.loc[item_i, item_j] 0 continue common_i np.array(common_i) common_j np.array(common_j) # 修正余弦相似度 denom np.sqrt(np.sum(common_i**2)) * np.sqrt(np.sum(common_j**2)) if denom 0: sim_matrix.loc[item_i, item_j] 0 continue sim np.sum(common_i * common_j) / denom sim_matrix.loc[item_i, item_j] round(sim, 4) return sim_matrix這段代碼在實(shí)現(xiàn)時(shí)比較考驗(yàn)對(duì)“修正余弦”的理解。修正的核心在于先對(duì)每個(gè)用戶評(píng)分做中心化減去該用戶平均分再計(jì)算余弦。不這么做的話一個(gè)總是打5分的用戶和一個(gè)總是打3分的用戶即使口味高度一致算出來的相似度也會(huì)失真。實(shí)際開發(fā)里我通常把ItemCF的物品相似度矩陣存成Spark DataFrame或直接在MySQL里建一張表item_id_a, item_id_b, similarity因?yàn)橛?jì)算一次之后就不需要頻繁重算。只有新菜品加入或者用戶評(píng)分發(fā)生明顯變化時(shí)才做增量更新。4.4 雙算法融合與冷啟動(dòng)策略單獨(dú)用UserCF或ItemCF都可能遇到效果不穩(wěn)定的情況。我最后實(shí)現(xiàn)的是混合推薦策略當(dāng)用戶的評(píng)分?jǐn)?shù)量少于一定閾值時(shí)走冷啟動(dòng)邏輯評(píng)分?jǐn)?shù)量足夠時(shí)用UserCF和ItemCF各出一份推薦列表加權(quán)融合后再輸出。冷啟動(dòng)邏輯又分三種場(chǎng)景。第一種是系統(tǒng)里完全沒有評(píng)分這時(shí)候只能按菜品平均分推薦做得更好一點(diǎn)是按照分類做多樣性推薦。第二種是用戶沒有任何評(píng)分但注冊(cè)時(shí)填了口味偏好可以按偏好分類推薦。第三種是用戶只有1到3條評(píng)分這時(shí)我傾向于直接用內(nèi)容匹配比如用戶評(píng)分過的菜品的同分類菜品來補(bǔ)充算法推薦放到評(píng)分?jǐn)?shù)據(jù)積累到5條以上再介入。加權(quán)融合的公式也不復(fù)雜final_score(d) α × score_userCF(d) (1 - α) × score_itemCF(d)α的取值可以在實(shí)驗(yàn)里調(diào)。我在自己的數(shù)據(jù)集上測(cè)下來α取0.4左右效果最好也就是稍微偏向ItemCF。原因也簡單美食推薦場(chǎng)景里“你以前喜歡的菜的相似菜”比“和你相似的人喜歡的菜”更穩(wěn)妥因?yàn)榍罢叩耐扑]理由用戶更容易接受。5. 系統(tǒng)功能設(shè)計(jì)與論文PPT素材搭建5.1 功能模塊拆解照著做不會(huì)漏功能一個(gè)完整的Web版美食推薦系統(tǒng)功能模塊可以這樣拆。用戶模塊負(fù)責(zé)注冊(cè)、登錄、個(gè)人信息管理注冊(cè)時(shí)盡可能讓用戶選擇口味偏好這是冷啟動(dòng)的重要數(shù)據(jù)。菜品模塊負(fù)責(zé)菜品信息展示、分類瀏覽、關(guān)鍵詞搜索。評(píng)分模塊是核心交互用戶給吃過的菜打分這個(gè)動(dòng)作決定了推薦質(zhì)量。推薦模塊負(fù)責(zé)生成“為你推薦”列表要同時(shí)給“推薦理由”。榜單模塊負(fù)責(zé)展示熱門菜品、高分菜品本質(zhì)上是推薦系統(tǒng)的兜底。這套功能拆解對(duì)應(yīng)到代碼結(jié)構(gòu)上用Flask藍(lán)圖來組織非常合適比如一個(gè)auth_bp負(fù)責(zé)登錄注冊(cè)一個(gè)dish_bp負(fù)責(zé)菜品瀏覽一個(gè)recommend_bp負(fù)責(zé)推薦接口。每個(gè)藍(lán)圖獨(dú)立成文件代碼不會(huì)亂。5.2 Flask后端接口設(shè)計(jì)我整理了一份最小的接口清單照著寫就能支撐整個(gè)系統(tǒng)前后端聯(lián)動(dòng)。接口路徑方法功能關(guān)鍵參數(shù)/api/registerPOST用戶注冊(cè)u(píng)sername, password, taste/api/loginPOST用戶登錄username, password/api/dishesGET菜品列表分頁page, category/api/dishes/idGET菜品詳情無/api/ratePOST提交評(píng)分user_id, dish_id, score/api/recommend/user_idGET獲取推薦列表top_n/api/hotGET熱門榜單limit在實(shí)現(xiàn)時(shí)/api/rate這個(gè)接口稍微特殊一點(diǎn)它不只是往數(shù)據(jù)庫里插入一條評(píng)分記錄還應(yīng)該同步更新菜品表的avg_rating。這個(gè)操作可以用數(shù)據(jù)庫事務(wù)來保證一致性防止評(píng)分插入成功但平均分更新失敗的情況。5.3 畢業(yè)論文章節(jié)怎么搭、PPT怎么提煉論文這塊我建議章節(jié)結(jié)構(gòu)直接按系統(tǒng)構(gòu)建的自然順序來寫。第一章緒論寫研究背景、意義、國內(nèi)外研究現(xiàn)狀、論文結(jié)構(gòu)。第二章相關(guān)技術(shù)介紹寫Python、Flask、協(xié)同過濾算法概述、MySQL。第三章需求分析與概要設(shè)計(jì)寫功能性需求、非功能性需求、系統(tǒng)架構(gòu)圖、功能模塊圖。第四章詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)這部分是重點(diǎn)寫數(shù)據(jù)庫設(shè)計(jì)、每個(gè)功能模塊的時(shí)序圖、推薦算法的實(shí)現(xiàn)細(xì)節(jié)、核心代碼分析。第五章系統(tǒng)測(cè)試寫測(cè)試環(huán)境、功能測(cè)試用例表、推薦效果評(píng)估準(zhǔn)確率、召回率、Top-N命中率、測(cè)試結(jié)果分析。第六章總結(jié)與展望。PPT的提煉邏輯和論文不同核心是“講故事”。我的經(jīng)驗(yàn)是首頁用系統(tǒng)截圖吸引眼球然后一頁講痛點(diǎn)信息過載、選擇困難一頁講解決方案的宏觀流程圖再花三四頁講算法原理與效果對(duì)比最后用一張架構(gòu)圖收尾。PPT上盡量少放代碼多放流程圖和效果對(duì)比圖那才是答辯老師會(huì)關(guān)注的。這里有個(gè)很實(shí)用的技巧答辯PPT里的算法講解頁別只放公式放一張“用戶A和用戶B的評(píng)分矩陣以及相似度計(jì)算過程”的手工演算小表直觀到答辯老師一眼就懂。表里兩行用戶數(shù)據(jù)、簡單的加減乘除、最終相似度0.87這段講解會(huì)讓你在答辯時(shí)的表達(dá)順暢很多。6. 推薦效果評(píng)估與常見問題排查6.1 離線評(píng)估指標(biāo)別只盯著準(zhǔn)確率很多同學(xué)做推薦系統(tǒng)評(píng)估就是“看起來推薦得還挺準(zhǔn)”這在論文里是不太夠的。我建議至少做三個(gè)維度。準(zhǔn)確率Precision的含義是推薦列表里用戶實(shí)際喜歡評(píng)分≥4的比例。比如推薦了10道菜用戶點(diǎn)了其中4道準(zhǔn)確率就是40%。計(jì)算方法是在測(cè)試集里把用戶評(píng)分行為隨機(jī)劃分成80%訓(xùn)練集和20%測(cè)試集用訓(xùn)練集學(xué)到的模型預(yù)測(cè)測(cè)試集里的評(píng)分行為。召回率Recall的含義是用戶喜歡的菜有多少被推薦出來了。如果用戶一共喜歡10道菜推薦列表覆蓋了其中4道召回率就是40%。覆蓋率Coverage的含義是推薦系統(tǒng)能推薦出的菜品占全部菜品的比例。覆蓋率太低說明系統(tǒng)總在推薦熱門菜長尾菜品永遠(yuǎn)沒曝光機(jī)會(huì)這在真實(shí)場(chǎng)景里是個(gè)問題。覆蓋率計(jì)算公式是推薦出去的不同菜品數(shù) / 菜品總數(shù)。三個(gè)指標(biāo)不能只看單一值。我在實(shí)驗(yàn)中發(fā)現(xiàn)UserCF在小數(shù)據(jù)集上準(zhǔn)確率往往比ItemCF高一點(diǎn)點(diǎn)但覆蓋率明顯偏低因?yàn)樗偘延脩粢颉按蠹叶紣鄢缘臒衢T菜”。ItemCF在覆蓋率上表現(xiàn)好得多這也是我最終系統(tǒng)把ItemCF作為主力、UserCF做補(bǔ)充的另一個(gè)原因。6.2 冷啟動(dòng)與稀疏性處理方案冷啟動(dòng)是推薦系統(tǒng)里繞不開的經(jīng)典問題也是答辯老師最喜歡追問的點(diǎn)。我的系統(tǒng)里用了一套分場(chǎng)景策略。新用戶冷啟動(dòng)分三步走注冊(cè)時(shí)收集口味偏好標(biāo)簽沒有評(píng)分時(shí)按口味標(biāo)簽推薦對(duì)應(yīng)分類的熱門菜品有少量評(píng)分后進(jìn)入混合推薦模式。新菜品冷啟動(dòng)的處理方式不同菜品剛上線沒有評(píng)分無法參與協(xié)同過濾計(jì)算所以需要在展示上給個(gè)“新品嘗鮮”入口讓新菜先獲得曝光和被評(píng)分的機(jī)會(huì)等積累到一定評(píng)分量再進(jìn)入推薦候選池。用戶冷啟動(dòng)的側(cè)重點(diǎn)不同如果只有個(gè)別用戶評(píng)分稀疏用“全局熱門榜”兜底推薦如果整體數(shù)據(jù)稀疏就增加評(píng)分引導(dǎo)交互比如推薦列表下方提示“點(diǎn)個(gè)評(píng)分推薦更懂你”。這些策略在實(shí)現(xiàn)上并不復(fù)雜但寫進(jìn)論文里很有價(jià)值體現(xiàn)的是你對(duì)推薦系統(tǒng)工程問題的理解深度而不僅僅是“我調(diào)了一個(gè)庫”。6.3 常見錯(cuò)誤和坑花式Debug實(shí)錄這個(gè)部分我整理了幾條我實(shí)際踩過的坑每一個(gè)都能節(jié)省你半天以上的調(diào)試時(shí)間。第一個(gè)坑是np.corrcoef返回全NaN。引起這個(gè)問題的原因是共同評(píng)分項(xiàng)方差為0比如兩個(gè)用戶對(duì)同一批菜全部打了5分。解決辦法是在用之前做NaN檢查或者手動(dòng)實(shí)現(xiàn)皮爾遜公式推薦后者自己寫公式還能加深理解。第二個(gè)坑是pandas的pivot_table用了fillna(0)之后評(píng)分矩陣變得極度稀疏。0在數(shù)學(xué)上等于“沒有評(píng)分”但在余弦相似度的計(jì)算里0直接參與運(yùn)算兩個(gè)“沒評(píng)過分”的菜品可能因此被判定為“不相似”。這個(gè)問題沒那么容易察覺因?yàn)槌绦虿粓?bào)錯(cuò)只是結(jié)果詭異。解決辦法是計(jì)算相似度的時(shí)候只取共同評(píng)分的維度也就是我前面代碼里common_mask的處理方式。第三個(gè)坑是評(píng)分表沒有唯一索引導(dǎo)致同一個(gè)用戶對(duì)同一道菜重復(fù)評(píng)分。從用戶體驗(yàn)上看用戶可能不小心點(diǎn)了兩次提交系統(tǒng)就記錄了兩次評(píng)分推薦結(jié)果會(huì)出現(xiàn)一種不合理波動(dòng)。解決辦法是建表時(shí)給(user_id, dish_id)加聯(lián)合唯一索引再用INSERT ... ON DUPLICATE KEY UPDATE做覆蓋式更新。第四個(gè)坑是推薦接口返回太慢。如果你每次請(qǐng)求都現(xiàn)場(chǎng)算相似度矩陣20個(gè)用戶、50道菜的數(shù)據(jù)規(guī)?？赡芨杏X不出來但數(shù)據(jù)量上千后就會(huì)明顯卡頓。我建議把相似度矩陣的構(gòu)建放在一個(gè)獨(dú)立模塊里程序啟動(dòng)時(shí)預(yù)計(jì)算并緩存到內(nèi)存或數(shù)據(jù)庫推薦接口只做查表和Top-N排序?qū)崪y(cè)響應(yīng)時(shí)間能從1秒多降到50毫秒以內(nèi)。6.4 實(shí)操總結(jié)一步一步跑通全項(xiàng)目的順序我最后整理一個(gè)實(shí)操順序清單適合完全沒思路的同學(xué)按步驟執(zhí)行。第一步安裝Python環(huán)境并配置好pycharm或vscode裝好pandas、numpy、flask、pymysql等庫。第二步準(zhǔn)備數(shù)據(jù)優(yōu)先用公開數(shù)據(jù)集或自定義數(shù)據(jù)構(gòu)建rating.csv、dish.csv、user.csv三個(gè)文件。第三步單獨(dú)寫一個(gè)算法測(cè)試腳本用pandas讀數(shù)據(jù)、構(gòu)建評(píng)分矩陣、實(shí)現(xiàn)UserCF和ItemCF、輸出推薦結(jié)果并打印評(píng)估指標(biāo)這一步的重點(diǎn)是確認(rèn)算法邏輯正確。第四步搭建Flask項(xiàng)目結(jié)構(gòu)創(chuàng)建藍(lán)圖、模板目錄、靜態(tài)資源目錄。第五步設(shè)計(jì)數(shù)據(jù)庫表結(jié)構(gòu)并建表寫數(shù)據(jù)庫連接模塊。第六步實(shí)現(xiàn)注冊(cè)登錄、菜品瀏覽、評(píng)分提交等基礎(chǔ)功能。第七步把推薦引擎嵌入到推薦接口中做冷啟動(dòng)和混合推薦邏輯。第八步寫測(cè)試用例準(zhǔn)備論文里的截圖和測(cè)試數(shù)據(jù)。第九步按照論文章節(jié)結(jié)構(gòu)填充內(nèi)容PPT提煉核心邏輯。在做完這九步之后你會(huì)發(fā)現(xiàn)自己對(duì)推薦系統(tǒng)的理解已經(jīng)不是停留在“調(diào)了一個(gè)庫”的水平而是真正能講清楚“推薦結(jié)果為什么是這樣”的人。這種從原理到實(shí)現(xiàn)的閉環(huán)才是這門課真正帶給你的東西。最后分享一個(gè)我在實(shí)際測(cè)試中發(fā)現(xiàn)的規(guī)律協(xié)同過濾最怕的不是數(shù)據(jù)量少而是行為數(shù)據(jù)不真實(shí)。如果造數(shù)據(jù)時(shí)所有人都只打高分、不打低分推薦結(jié)果幾乎沒有區(qū)分度。所以不管是自己造數(shù)據(jù)還是找公開數(shù)據(jù)一定確保評(píng)分有高有低、用戶口味有差異這樣算法效果才能真實(shí)反映出來。數(shù)據(jù)質(zhì)量決定了推薦質(zhì)量這個(gè)道理在真實(shí)業(yè)務(wù)里一樣成立。本文還有配套的精品資源點(diǎn)擊獲取