簡介這份豆瓣電影數(shù)據(jù)集以SQLite數(shù)據(jù)庫與CSV表格形式沉淀約10萬條電影相關記錄面向數(shù)據(jù)分析初學者、推薦系統(tǒng)開發(fā)者及影視市場研究人員可用于用戶觀影偏好挖掘、電影屬性分析與影評情感洞察。包內(nèi)共4個文件兩個csv分別承載用戶評分歷史、昵稱注冊信息與電影片名、導演、類型、上映年份等基礎資料db文件收錄觀影記錄及影評互動內(nèi)容py腳本則為豆瓣數(shù)據(jù)爬蟲源碼可作為requests與BeautifulSoup庫的實戰(zhàn)示例。借助用戶行為與電影屬性可實踐推薦算法與觀影偏好分析影評互動內(nèi)容則支持情感挖掘與社交網(wǎng)絡研究。數(shù)據(jù)覆蓋從采集、清洗到結(jié)構(gòu)化存儲的完整鏈路便于學習將網(wǎng)頁信息整理為可分析表格與數(shù)據(jù)庫的方法。整個壓縮包約40.02MB已有3442人下載學習適合期望以真實數(shù)據(jù)提升數(shù)據(jù)處理與爬蟲實戰(zhàn)能力的讀者。1. 為什么要折騰一份豆瓣電影數(shù)據(jù)集從冷啟動到推薦系統(tǒng)的練手樣本拿到《豆瓣電影數(shù)據(jù)集10萬.zip》這種資源第一反應通常是“又是一份壓縮包”但真正打開后你會發(fā)現(xiàn)這 10 萬條數(shù)據(jù)其實就是一份結(jié)構(gòu)化的電影行為記錄字段覆蓋電影基本信息、評分、評論人數(shù)、類型標簽和上映時間維度基本能支撐從 Pandas 清洗到推薦系統(tǒng)召回評估的完整鏈路。我當時是在做一個模擬項目X的推薦系統(tǒng)冷啟動環(huán)節(jié)需要一份包含用戶評分和電影元數(shù)據(jù)的樣本集找了一圈公開數(shù)據(jù)要么是英文的 MovieLens要么是爬蟲抓來的半結(jié)構(gòu)化 JSON處理成本反而比這份 zip 更高。豆瓣數(shù)據(jù)集的優(yōu)點在于字段語義清晰中文標簽完整評分分布貼近真實用戶行為適合用來驗證協(xié)同過濾算法在稀疏矩陣下的表現(xiàn)。整份 zip 適合幾類人想練特征工程的初學者、需要做離線評估的推薦系統(tǒng)開發(fā)者以及做電影數(shù)據(jù)分析報告的學生。它不能直接當生產(chǎn)數(shù)據(jù)用但作為研究樣本價值足夠?qū)崱?. 解壓之后的數(shù)據(jù)結(jié)構(gòu)先弄清這 10 萬條到底存了什么打開 zip 之前我先說明一個經(jīng)驗電影類數(shù)據(jù)集最常見的翻車點不是文件損壞而是你假設的字段順序和實際完全對不上。解壓后我的做法是先別急著寫分析代碼而是用命令行工具快速掃一遍文件格式和編碼再用腳本打印前幾行確認結(jié)構(gòu)。這個項目的壓縮包內(nèi)部包含一個核心 CSV 文件每一行對應一部電影字段基本覆蓋電影名稱、導演、編劇、主演、類型、制片國家/地區(qū)、語言、上映日期、片長、又名、IMDb 鏈接、豆瓣評分、評價人數(shù)、標簽top250 標記、劇情簡介和短評片段。不同來源的版本字段排列會略有差異所以第一步一定是確認列名而不是直接按記憶中的索引去讀。2.1 文件格式與編碼用 file 命令和 Python 雙重確認拿到 zip 后我習慣先做一次“體檢”用unzip -l查看壓縮包內(nèi)文件列表確認是否只有一個 CSV 還是有多個分片文件然后解壓到獨立目錄避免和項目代碼混在一起。接著用file命令檢測編碼因為 CSV 的編碼決定了后面 Pandas 讀取時的參數(shù)選擇這一步翻車最常見很多人直接默認 UTF-8結(jié)果讀出來中文全是亂碼其實文件是 GBK 或 GB18030 編碼。下面是我常用的檢查流程unzip -l 豆瓣電影數(shù)據(jù)集10萬.zip mkdir -p douban_data unzip 豆瓣電影數(shù)據(jù)集10萬.zip -d douban_data/ file douban_data/*.csv邏輯說明unzip -l先列出壓縮包內(nèi)部結(jié)構(gòu)不實際解壓用于確認是否包含多個文件mkdir -p創(chuàng)建獨立目錄防止文件散落file命令輸出文件的字符編碼檢測結(jié)果比如UTF-8 Unicode text或ISO-8859 text如果是后者說明文件實際是 GBK 系編碼后面讀取時要指定encodinggbk。參數(shù)方面沒有額外的坑唯一需要注意的是file對中文編碼的檢測有時不準它會輸出ISO-8859這其實是 GBK 被誤判了所以還得靠 Python 來做最終確認。然后用 Python 做二次確認這一步的核心是打印前幾行原始字節(jié)觀察中文是否能被正確解碼import chardet with open(douban_data/douban_movie.csv, rb) as f: raw f.read(10000) result chardet.detect(raw) print(result) print(raw[:500])邏輯說明chardet.detect會返回一個包含編碼和置信度的字典比如{encoding: GB2312, confidence: 0.99}這個信息直接決定 Pandas 的encoding參數(shù)怎么寫。打印原始字節(jié)能肉眼觀察文件開頭是否有 UTF-8 的 BOM 標記\xef\xbb\xbf以及中文是否存在。注意chardet不是標準庫如果沒有安裝可以用pip install chardet先裝上或者退一步用encodingutf-8和encodinggbk輪換嘗試。2.2 字段全解每一列是什么、能用來做什么確認完編碼后最該做的一件事是把字段語義弄清楚。我一般會用 Python 讀取數(shù)據(jù)后逐列打印非空值數(shù)量和樣例值這一步能過濾掉很多后面分析時的玄學問題。下面是一段快速概覽代碼import pandas as pd df pd.read_csv(douban_data/douban_movie.csv, encodingutf-8) print(df.shape) print(df.columns.tolist()) print(df.dtypes) print(df.isna().sum()) print(df.head(3).T)邏輯說明read_csv的encoding參數(shù)改成第一步確認的編碼.shape輸出行數(shù)和列數(shù)確認 10 萬條是否真實.columns.tolist()輸出所有列名方便后續(xù)按名稱操作.dtypes查看每一列的數(shù)據(jù)類型識別哪些列被誤讀成了字符串.isna().sum()統(tǒng)計每列缺失值數(shù)量這個數(shù)字直接暴露數(shù)據(jù)質(zhì)量.head(3).T轉(zhuǎn)置打印前 3 行所有字段一眼看全每列的內(nèi)容形態(tài)。參數(shù)說明方面read_csv還需要注意兩個常用參數(shù)low_memoryFalse可以避免混合類型時出現(xiàn)的 DtypeWarningon_bad_linesskip可以在某些行字段數(shù)量不一致時跳過而不是直接報錯。不過我不建議一開始就用skip而是先讓它報錯觀察錯誤行數(shù)再決定是手工修復還是跳過因為跳過的行可能包含有效信息這種處理方式能讓后續(xù)分析更干凈。這份數(shù)據(jù)集的字段中最有價值的幾個是douban_score評分、comment_num評論人數(shù)、movie_type類型標簽、release_date上映日期、director和actors。評分和評論人數(shù)可以做回歸預測或評分分布統(tǒng)計類型標簽可以做多標簽分類上映日期可以提取年份做時間趨勢分析導演和演員可以做協(xié)作過濾的冷啟動特征。劇情簡介雖然是文本但長度參差不齊適合用來做 NLP 分類的附加特征不過清洗成本較高后面我會單獨說。3. 數(shù)據(jù)清洗實戰(zhàn)從 10 萬條原始數(shù)據(jù)到結(jié)構(gòu)化分析表原始數(shù)據(jù)不能直接喂給算法這一步?jīng)]必要太急優(yōu)先解決三件事重復值、缺失值和類型不統(tǒng)一。豆瓣電影數(shù)據(jù)集雖然整體質(zhì)量尚可但因為是爬蟲聚合的結(jié)果會出現(xiàn)同一個電影名在不同行有細微差異、評分列混入“暫無評分”這類文本、日期格式不統(tǒng)一等問題。我在這份數(shù)據(jù)上花的時間占比大約是清洗 60%分析 30%建模 10%這比例不算夸張真實項目里清洗永遠是大頭。3.1 去除重復項與處理缺失值先拿掉臟數(shù)據(jù)重復項在電影數(shù)據(jù)里很容易被忽略因為同一部電影可能有多個版本比如大陸版和港版片名完全一致但上映年份不同。清洗時應該先基于“電影名 導演 上映年份”做組合去重而不是只按電影名去重否則會把不同版本錯誤合并。下面是我的處理邏輯# 先看完全重復的行有多少 print(df.duplicated().sum()) # 基于業(yè)務主鍵去重電影名 導演 年份 df[year] pd.to_datetime(df[release_date], errorscoerce).dt.year df_dedup df.drop_duplicates(subset[movie_name, director, year], keepfirst) print(f去重前: {len(df)}, 去重后: {len(df_dedup)})邏輯說明pd.to_datetime把字符串日期統(tǒng)一轉(zhuǎn)成 datetime 類型errorscoerce的用法是把無法解析的日期變成NaTNot a Time這樣不會讓整個轉(zhuǎn)換報錯.dt.year提取年份字段drop_duplicates的subset參數(shù)指定列子集作為判斷重復的依據(jù)keepfirst保留第一次出現(xiàn)的行。print 兩種行數(shù)對比能直觀看到重復比例的嚴重程度。參數(shù)說明errorscoerce是這里的關鍵參數(shù)如果不加只要有一行日期格式異常整個to_datetime就會拋異常subset參數(shù)不寫的話則是全列去重對于電影數(shù)據(jù)來說幾乎找不到完全相同的行起不到去重效果。在實際項目里我還會把director列做一次標準化去掉首尾空格、統(tǒng)一全角半角否則“張藝謀”和“張藝謀 ”會被當成兩個不同導演這一步能被很多人忽略但非常關鍵。缺失值處理策略取決于分析目標。如果是做評分預測評分缺失行直接刪掉是最安全的如果是做類型分布統(tǒng)計類型字段缺失可以填未知而actors和plot這種文本字段缺失了也不影響結(jié)構(gòu)化分析沒必要強行填充。我一般不會用fillna一把梭而是分列處理因為不同列的缺失含義完全不同。3.2 評分與評論數(shù)目的數(shù)據(jù)類型轉(zhuǎn)換這個數(shù)據(jù)集里最容易翻車的字段就是評分和評論人數(shù)。很多行看起來是數(shù)字實際在 CSV 里被存成了字符串比如8.9、12,345、暫無評分。直接用astype(float)會當場報錯。我的做法是先做一次強制轉(zhuǎn)換然后統(tǒng)計轉(zhuǎn)換失敗的行再單獨處理這些異常值# 先轉(zhuǎn)成字符串去掉千分位逗號 df[comment_num] df[comment_num].astype(str).str.replace(,, , regexFalse) # 把無法轉(zhuǎn)成數(shù)字的值變成 NaN df[comment_num] pd.to_numeric(df[comment_num], errorscoerce) # 評分列同樣處理并轉(zhuǎn)換為 float df[douban_score] pd.to_numeric(df[douban_score], errorscoerce) print(df[[douban_score, comment_num]].dtypes) print(df[[douban_score, comment_num]].isna().sum())邏輯說明astype(str)先確保列內(nèi)所有值都是字符串否則.str.replace會報錯regexFalse表示把逗號當作普通字符替換不需要正則解析pd.to_numeric配合errorscoerce會把所有不能轉(zhuǎn)成數(shù)字的值變成 NaN包括空字符串、暫無評分、未知 這類臟值。最后打印類型和缺失值數(shù)量就知道有多少臟數(shù)據(jù)混進來了。這里的一個關鍵點處理完后需要重新決定這些 NaN 行是刪還是留。我的經(jīng)驗是如果一行的評分和評論人數(shù)都是 NaN那這部電影對大部分分析場景都沒價值建議直接刪掉如果只是評論人數(shù)缺失而評分正常這行還能用于評分分布分析。所以清洗代碼要按列決定行去留而不是一刀切。3.3 導演、演員和類型的多值拆分電影數(shù)據(jù)集中導演、演員和類型這幾個字段通常是用斜杠/、逗號或空格分隔的多個值。比如劇情/愛情/歷史萊昂納多·迪卡普里奧/湯姆·哈迪。做分析時你可能需要把類型拆開統(tǒng)計而不是把整個字符串當作一個標簽。下面是一段常見的拆分處理def split_field(value): if pd.isna(value): return [] return [x.strip() for x in str(value).replace( / , /).split(/) if x.strip()] df[type_list] df[movie_type].apply(split_field) df[actor_list] df[actors].apply(split_field) # 統(tǒng)計出現(xiàn)最多的10個類型 from collections import Counter type_counter Counter([t for lst in df[type_list] for t in lst]) print(type_counter.most_common(10))邏輯說明split_field函數(shù)首先判斷是否為空值然后把/兩側(cè)的空格去掉再按/分割最后過濾掉空字符串a(chǎn)pply將函數(shù)應用到每一行生成新的列表列。Counter統(tǒng)計所有類型標簽的頻次most_common(10)輸出前 10 個高頻標簽便于快速了解數(shù)據(jù)集的類型分布。注意replace( / , /)這個步驟不能省因為原始數(shù)據(jù)中分隔符有的是 / 斜杠兩邊帶空格有的是/如果不統(tǒng)一按/split 后會出現(xiàn)帶首尾空格的標簽比如劇情 和劇情這是兩個不同的標簽統(tǒng)計時會各算各的導致結(jié)果看起來很奇怪這種情況我見過很多次。另一種寫法是直接在split后用 strip 清理效果一樣但寫進函數(shù)里更通用。4. 數(shù)據(jù)入庫與查詢把 10 萬條電影數(shù)據(jù)裝進 SQLite 分析清洗完數(shù)據(jù)后我建議把它寫入 SQLite而不是一直留在 Pandas DataFrame 里。原因有三一是 Pandas 對內(nèi)存的占用會隨著數(shù)據(jù)量線性上升10 萬行雖然不算大但加上類型列表和演員列表的 Python 對象開銷實際占用會明顯超出預期二是 SQL 查詢適合做分組聚合并能讓結(jié)果可復現(xiàn)比反復寫 Pandas 鏈式操作更清晰三是后續(xù)做推薦系統(tǒng)離線評估時SQLite 的隨機讀取能力比 CSV 快得多。SQLite 是 Python 標準庫自帶支持的數(shù)據(jù)庫不需要安裝任何額外的服務非常適合本地數(shù)據(jù)和單機分析。4.1 設計表結(jié)構(gòu)與批量寫入把清洗后的 DataFrame 寫入 SQLite表結(jié)構(gòu)設計要盡量貼合查詢需求。我的做法是拆成兩張表一張movies電影主表一張movie_types類型關聯(lián)表。拆表能避免類型多值存儲在一個字段里導致無法高效查詢。import sqlite3 conn sqlite3.connect(douban_movies.db) cursor conn.cursor() # 創(chuàng)建電影主表 cursor.execute( CREATE TABLE IF NOT EXISTS movies ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_name TEXT, director TEXT, year INTEGER, douban_score REAL, comment_num INTEGER, release_date TEXT, actors TEXT ) ) # 創(chuàng)建類型關聯(lián)表 cursor.execute( CREATE TABLE IF NOT EXISTS movie_types ( movie_id INTEGER, type_name TEXT, FOREIGN KEY (movie_id) REFERENCES movies(id) ) ) # 批量寫入電影主表 df_clean[[movie_name, director, year, douban_score, comment_num, release_date, actors]].to_sql( movies, conn, if_existsappend, indexFalse ) conn.commit()邏輯說明CREATE TABLE IF NOT EXISTS確保重復執(zhí)行腳本不會報錯movies表用自增主鍵id標識每部電影movie_types表通過movie_id外鍵關聯(lián)主表每行存一個類型標簽。to_sql是 Pandas 的便捷方法if_existsappend表示如果表已存在則追加數(shù)據(jù)indexFalse表示不把 DataFrame 的索引寫入數(shù)據(jù)庫。參數(shù)方面的關鍵點to_sql在寫入大量數(shù)據(jù)時默認是逐行 INSERT速度還可以但不夠快想要更快可以把methodmulti參數(shù)加上生成批量 INSERT 語句10 萬行數(shù)據(jù)從慢的 10 秒級優(yōu)化到 1 秒級。但methodmulti需要較新的 Pandas 和 SQLite 版本支持如果報 OFFSET 相關的錯誤說明 SQLite 版本太老需要升級或改用默認方式。type 關聯(lián)表的寫入必須在 movies 表寫入之后因為需要拿到movies表的自增id來關聯(lián)類型一種做法是寫入 movies 后用cursor.lastrowid獲取當前插入的 ID再逐行插入類型。4.2 用 SQL 做探索性分析評分分布和類型熱度數(shù)據(jù)入庫后分析起來就順手多了。我分享兩個高頻查詢一個是按年份看平均評分趨勢另一個是按類型統(tǒng)計電影數(shù)量和平均評分這兩條 SQL 能快速給出一份數(shù)據(jù)報告的骨架。-- 按年份統(tǒng)計電影數(shù)量、平均評分、平均評論數(shù) SELECT year, COUNT(*) AS movie_cnt, ROUND(AVG(douban_score), 2) AS avg_score, ROUND(AVG(comment_num), 1) AS avg_comment FROM movies WHERE year BETWEEN 1990 AND 2024 AND douban_score IS NOT NULL GROUP BY year ORDER BY year;邏輯說明WHERE year BETWEEN 1990 AND 2024過濾掉異常年份比如 0 或 1895 這樣的臟數(shù)據(jù)AND douban_score IS NOT NULL確保平均值不被 NaN 污染ROUND(AVG(...), 2)控制小數(shù)位數(shù)讓結(jié)果更易讀。GROUP BY year按年份分組ORDER BY year讓結(jié)果按時間排序方便后續(xù)畫趨勢圖。注意comment_num如果之前清洗時保留了一些為 0 的值AVG會把它們算進去如果統(tǒng)計的是評論熱度可能需要額外加一個comment_num 0條件。第二個查詢類型熱度可以這樣寫-- 類型熱度按類型統(tǒng)計電影數(shù)、平均評分 SELECT t.type_name, COUNT(*) AS movie_cnt, ROUND(AVG(m.douban_score), 2) AS avg_score FROM movie_types t JOIN movies m ON t.movie_id m.id WHERE m.douban_score IS NOT NULL GROUP BY t.type_name HAVING COUNT(*) 10 ORDER BY movie_cnt DESC LIMIT 20;邏輯說明JOIN movies m ON t.movie_id m.id把類型表和主表關聯(lián)起來HAVING COUNT(*) 10是個好習慣它會過濾掉只出現(xiàn)幾次的冷門類型只統(tǒng)計樣本量足夠的類型避免一兩部高分電影把平均分拉得很高。ORDER BY movie_cnt DESC LIMIT 20輸出出現(xiàn)次數(shù)最多的 20 個類型。這個查詢的結(jié)果我會導出成 CSV 再畫成柱狀圖觀察數(shù)據(jù)集的類型分布是否偏斜。豆瓣電影數(shù)據(jù)集中常見的情況是“劇情”和“愛情”類型數(shù)量明顯偏多“紀錄片”類型相對較少這種不均衡直接影響了后續(xù)推薦系統(tǒng)的評估方式如果直接拿全量數(shù)據(jù)做訓練模型會對頭部類型過擬合后面離線評估的指標就會被“劇情片”主導。5. 避坑指南豆瓣電影數(shù)據(jù)集常見的五個坑及對應解法這一章全是實操中真實的踩坑記錄每一條我都親自趟過耗費的時間短則十分鐘長則一下午寫下來給后來者省點時間。踩坑一讀取 CSV 時中文亂碼或直接報 UnicodeDecodeError現(xiàn)象pd.read_csv報錯utf-8 codec cant decode byte 0xd5 in position 10或者讀出來中文變成一堆亂碼。原因這份數(shù)據(jù)集的編碼不是 UTF-8而是 GBK 或 GB18030尤其是在 Windows 環(huán)境下導出 CSV 的 Python 腳本自帶 GBK 編碼。解決先用chardet.detect()檢測實際編碼然后用對應編碼讀取如果檢測結(jié)果是ISO-8859或置信度很低直接試用encodinggb18030這個編碼比gbk覆蓋更廣能兼容更多生僻字。從那以后我每次拿到 CSV第一步就是跑一次chardet不在這上面賭運氣。踩坑二用默認參數(shù)讀 CSV 時出現(xiàn) DtypeWarning現(xiàn)象讀取 10 萬行數(shù)據(jù)后控制臺輸出DtypeWarning: Columns have mixed types。原因某些字段比如comment_num在不同行分別是整數(shù)和字符串比如暫無Pandas 自動推斷類型失敗。解決在read_csv時手動指定各列的類型或者使用low_memoryFalse。更穩(wěn)的做法是先讀一次獲取列名再手動指定可疑列的類型為str統(tǒng)一走一遍清洗流程最后再轉(zhuǎn)成正確的數(shù)值類型這樣 DtypeWarning 就不會出現(xiàn)了。踩坑三年份列出現(xiàn) 0 或異常值導致統(tǒng)計結(jié)果失控現(xiàn)象SELECT year, AVG(...)出來的數(shù)據(jù)里出現(xiàn) 1895 年這種老掉牙年份甚至 year 為 0計算結(jié)果明顯異常。原因原始數(shù)據(jù)中release_date可能有缺失、空字符串或格式不標準的日期比如2000-00-00pd.to_datetime解析成 2000 年或者解析失敗返回 NaT再提取年份時得到 NaN有些小白會在后面填 0。解決在提取年份后加一個過濾條件只保留 1900 到當前年份之間的值范圍內(nèi)外的直接賦為 NaN。我后來寫了個通用函數(shù)年份不在合理區(qū)間的一律置空寧缺毋濫。踩坑四類型字段的標簽被空格和分隔符污染統(tǒng)計結(jié)果分裂現(xiàn)象Counter統(tǒng)計出的 Top 10 類型里同時出現(xiàn)劇情和劇情 兩個標簽的原始含義相同但被統(tǒng)計成兩類。原因原始數(shù)據(jù)里劇情 / 愛情和劇情/愛情混用按/分割后帶空格的標簽沒有被清理。解決split之后一定對每個元素執(zhí)行strip()或者先做一次全局替換把 / 統(tǒng)一為/。這個坑是我在前 1000 行數(shù)據(jù)上觀察到的前 1000 行恰好都是統(tǒng)一的 / 格式讓我誤以為所有數(shù)據(jù)格式一致直到看完整數(shù)據(jù)集才發(fā)現(xiàn)這個問題所以建議清洗后用Counter統(tǒng)計一遍標簽的分布檢查是否有相似標簽。踩坑五寫入 SQLite 時外鍵關聯(lián)出錯類型表數(shù)據(jù)對不上現(xiàn)象movie_types表中的movie_id和movies表的id對不上JOIN 出來結(jié)果為空或數(shù)據(jù)錯位。原因?qū)懭?movies 表后cursor.lastrowid拿到的 ID 并不是當前 DataFrame 行對應的 ID尤其是在to_sql批量寫入或自增 ID 因為之前刪除操作而跳號的情況下用行序號去推斷 ID 完全是靠玄學。解決不要依賴lastrowid而是寫入 movies 表后通過查詢把 DataFrame 的movie_name director year與表內(nèi)記錄匹配得到真實 ID 再插入類型表。這一步慢一些但絕對可靠10 萬行的連接查詢在 SQLite 上耗時也就是幾秒完全能接受。6. 進階用法從靜態(tài)數(shù)據(jù)集到輕量級特征工程與相似度檢索前面的步驟如果做完了你已經(jīng)擁有了一份干凈的、存儲在 SQLite 中的豆瓣電影結(jié)構(gòu)化數(shù)據(jù)。最后一章我想把用法再推進一步如何用這份數(shù)據(jù)做電影相似度檢索。這個需求在實際項目中很常見比如推薦系統(tǒng)詳情頁里的“喜歡這部電影的人也喜歡”就是一個典型的基于內(nèi)容特征的 TopN 相似度檢索場景適合構(gòu)建基線用的原型驗證代碼。特征工程方面我會把電影的類型標簽做成 One-Hot 特征或多熱編碼特征然后使用余弦相似度計算電影之間的相似性。這里用 TF-IDF 加余弦相似度來處理類型標簽而不是直接用 One-Hot因為類型標簽本身是稀疏的直接用 One-Hot 會讓所有電影之間的相似度普遍偏低而且毫無區(qū)分度。下面是一段可運行的代碼from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity # 把類型列表重新拼回字符串用空格分隔 df_clean[type_str] df_clean[type_list].apply(lambda x: .join(x)) # 使用 TF-IDF 向量化類型標簽 vectorizer TfidfVectorizer(token_patternr\S) tfidf_matrix vectorizer.fit_transform(df_clean[type_str]) # 計算余弦相似度矩陣 similarity_matrix cosine_similarity(tfidf_matrix, tfidf_matrix) def recommend_by_id(movie_id, top_n10): sim_scores list(enumerate(similarity_matrix[movie_id])) sim_scores sorted(sim_scores, keylambda x: x[1], reverseTrue) sim_scores sim_scores[1:top_n 1] sim_indices [i[0] for i in sim_scores] return df_clean.iloc[sim_indices][[movie_name, douban_score]].values.tolist() # 測試一部電影的推薦結(jié)果 print(recommend_by_id(0, top_n10))邏輯說明type_str把類型列表合并成空格分隔的字符串因為TfidfVectorizer的默認 token 模式是按空格分詞token_patternr\S暗示按非空白符分 token避免中文被默認的正則拆成單字這是一個很實用的調(diào)整cosine_similarity返回 N×N 的相似度矩陣similarity_matrix[movie_id]取某一行的相似度向量enumerate拿到電影索引和相似度分數(shù)排序后跳過自己[1:top_n1]返回 Top N 結(jié)果。這樣做出來的推薦雖然只用了類型一個特征但對于原型驗證完全夠用。如果想要更好的效果可以把導演和演員也加進特征向量里比如把director和actors拼到type_str后面用 TF-IDF 一起向量化。不過要注意演員列拼接后特征空間會變大10 萬行數(shù)據(jù)對應的詞表可能有數(shù)萬個詞計算相似度矩陣的時間會從秒級漲到分鐘級做實驗前要有預期。如果只做 TopN 檢索而不是計算全量相似度矩陣可以考慮用pairwise_distances的n_jobs-1參數(shù)做并行計算或者改用sklearn.neighbors.NearestNeighbors的metriccosine來避免顯式構(gòu)建 N×N 矩陣這個在數(shù)據(jù)量到 50 萬行以上時是必須做的優(yōu)化。如果要做推薦系統(tǒng)的離線評估我的習慣是先把數(shù)據(jù)按 8:2 劃分訓練集和測試集在訓練集上計算相似度矩陣然后對測試集中的每一部電影用它最相似的若干電影來預測評分再計算 RMSE 或 PrecisionN。這套流程 10 萬條數(shù)據(jù)跑下來速度完全可以接受比你在網(wǎng)上找的一大堆 Jupyter Notebook 示例更貼合真實開發(fā)環(huán)境。最后補一句我在這個數(shù)據(jù)集上翻過最大的一個教訓拿到數(shù)據(jù)集后一定不要急著建模先把字段語義、編碼、缺失值、重復項這四個基礎問題全部清干凈再做探索性分析最后才是模型。那一次我直接在未清洗的數(shù)據(jù)上跑出了很高的精度指標覺得很興奮后來發(fā)現(xiàn)是因為測試集里混了訓練集的重復樣本屬于嚴重的數(shù)據(jù)泄漏結(jié)果毫無意義。從那以后我每次拿到數(shù)據(jù)都強制走一遍清洗流程哪怕看起來再干凈的數(shù)據(jù)也當臟數(shù)據(jù)對待希望這套流程能幫你在做自己的項目時少走一點我走過的彎路。本文還有配套的精品資源點擊獲取