簡介面向Python課程設(shè)計與機器學習實踐場景這份資源以美職籃NBA比賽數(shù)據(jù)為切入點實現(xiàn)了從爬蟲采集、數(shù)據(jù)清洗到智能預測的比賽結(jié)果分析流程。項目取材真實賽季數(shù)據(jù)涵蓋球隊場均統(tǒng)計、對手數(shù)據(jù)、賽程安排與歷史交鋒結(jié)果等多維信息適合高校學生用于學期答辯、大作業(yè)或課程設(shè)計展示也適合希望快速上手數(shù)據(jù)采集與建模的初學者參考。壓縮包共有十一個文件以六個數(shù)據(jù)文件、四個腳本文件和一個說明文檔為主整體大小約三百一十一KB。其中數(shù)據(jù)文件分別存放球隊常規(guī)賽統(tǒng)計、對手常規(guī)賽統(tǒng)計、歷史賽程與比賽結(jié)果腳本文件覆蓋爬蟲抓取與機器學習模型訓練及預測說明文檔則整理了項目背景、設(shè)計思路、模塊劃分和運行步驟。該方案曾獲學期優(yōu)秀項目評選代碼結(jié)構(gòu)清晰、數(shù)據(jù)資料齊備可直接運行復現(xiàn)預測結(jié)果也便于后續(xù)擴展算法或更換數(shù)據(jù)源。目前已有一千四百六十二人學習是完成課程設(shè)計或入門賽事數(shù)據(jù)分析的實用資源。1. 把NBA比賽結(jié)果預測當課程設(shè)計為什么說這是新手最友好的機器學習項目NBA比賽結(jié)果預測是Python課程設(shè)計里少有的數(shù)據(jù)、算法、業(yè)務三頭都占的實戰(zhàn)選題。它不需要深度學習傳統(tǒng)機器學習模型就能把準確率做到60%以上但數(shù)據(jù)獲取、特征構(gòu)造、評估方式到處是坑足夠你學到東西。在機器學習實戰(zhàn)項目案例里這個題目的好處是入門順滑、天花板也夠高。很多同學做完后發(fā)現(xiàn)真正決定成績的不是模型多高級而是數(shù)據(jù)預處理和特征工程做沒做干凈。這個題目恰好能把Python爬蟲、pandas數(shù)據(jù)處理、scikit-learn建模和可視化完整串一遍非常適合剛?cè)腴T機器學習、想補機器學習基礎(chǔ)、又想做真實項目的初學者。NBA比賽數(shù)據(jù)完全公開免費接口無需注冊比申請權(quán)限的數(shù)據(jù)集友好得多。下文方案基于nba_api加pandas加scikit-learn的經(jīng)典組合全程本地跑通不需要GPU每段代碼都附參數(shù)說明和踩坑記錄。2. 獲取NBA比賽數(shù)據(jù)nba_api 拉取與本地落地的完整方案2.1 選型理由為什么第一選擇是 nba_api 而不是現(xiàn)成CSV先說結(jié)論課程設(shè)計階段直接用 nba_api 這個第三方庫拉數(shù)據(jù)比去 Kaggle 下載現(xiàn)成 CSV 更值得做。原因有三個。第一現(xiàn)成 CSV 的截止日期是固定的你拿到手的可能是上個賽季的數(shù)據(jù)沒法覆蓋最新比賽。課程設(shè)計答辯時老師大概率會問你這套流程能不能預測明天的比賽如果你用的是一份去年的靜態(tài)數(shù)據(jù)這個問題會非常尷尬。用接口拉數(shù)據(jù)代碼一跑就是最新賽程。第二拉數(shù)據(jù)的過程本身就是評分點。Python課程設(shè)計的評分標準里通常有工作量這一項能展示一個從網(wǎng)絡獲取數(shù)據(jù)的完整環(huán)節(jié)比單純讀CSV文件的工作量要扎實得多。你可以順帶在文檔里寫清楚請求流程、解析邏輯和異常處理體現(xiàn)的是從爬取到存儲的完整閉環(huán)。第三nba_api 封裝的是 NBA 官網(wǎng) stats.nba.com 的公開接口免費、無需注冊、無需API key對校園網(wǎng)絡環(huán)境也比較友好。相比去爬第三方統(tǒng)計網(wǎng)站官方接口的可靠性要高不少也不會遇到網(wǎng)站改版導致解析規(guī)則失效的問題。當然nba_api 有個前提你得先把Python環(huán)境裝好。給新手的建議是直接用 Anaconda 裝 Python 3.x然后把 conda 和 pip 的默認源都切成國內(nèi)鏡像裝包速度會快很多。裝完在終端里跑 python --version 確認版本再 pip install nba_api pandas scikit-learn xgboost matplotlib機器學習常用包就這么齊了。如果你用 vscode 寫代碼記得在右下角把解釋器切成 conda 環(huán)境不然容易遇到終端里能 import、vscode 里 import 報錯的經(jīng)典問題。2.2 最小可用代碼拉取近五個賽季的常規(guī)賽日程與比分nba_api 的核心用法是先構(gòu)造一個端點對象再調(diào)它的 get_data_frames() 方法拿回 DataFrame。最常見的入口是 leaguegamefinder它返回每一支球隊在指定范圍內(nèi)的所有歷史比賽記錄每條記錄是一行包含球隊、對手、比分、主客場、賽季、比賽日期等幾十個字段。下面這段代碼拉取近五個賽季所有常規(guī)賽的比賽日程和最終比分import pandas as pd from nba_api.stats.endpoints import leaguegamefinder def fetch_games(season_start2020, season_end2024): frames [] for season in range(season_start, season_end 1): # 每個賽季單獨拉取避免單次請求數(shù)據(jù)量過大被接口限流 season_str f{season}-{str(season 1)[-2:]} finder leaguegamefinder.LeagueGameFinder( season_nullableseason_str, season_type_nullableRegular Season ) df finder.get_data_frames()[0] frames.append(df) print(f賽季 {season_str} 拉取完成{df.shape[0]} 行) result pd.concat(frames, ignore_indexTrue) return result games fetch_games() games.to_csv(nba_games_raw.csv, indexFalse) print(games.shape)這段代碼的邏輯很直接循環(huán)遍歷每一個賽季構(gòu)造 LeagueGameFinder 請求對象用 get_data_frames() 把響應解析成 DataFrame最后合并保存為CSV。幾個參數(shù)要說明參數(shù)取值示例含義season_nullable2020-21賽季字符串格式必須是帶橫杠的2020-21season_type_nullableRegular Season賽事類型常規(guī)賽季后賽填 Playoffsleague_id_nullable00默認就是NBA一般不用動timeout30單個請求的最大等待秒數(shù)防卡死注意一個重要細節(jié)leaguegamefinder 返回的是球隊視角的數(shù)據(jù)也就是說一場比賽會出現(xiàn)兩行——主隊一行、客隊一行。字段里 matchup 列能看出是 ATL vs BOS 還是 BOS ATL 表示客場。做特征工程之前必須先按 GAME_ID 去重或配對這個后面特征章節(jié)會細說。接口返回的字段里GAME_ID 是比賽唯一標識GAME_DATE 是比賽日期字符串TEAM_ID 是球隊IDPTS 是這支球隊本場得分PLUS_MINUS 是凈勝分FG_PCT 是投籃命中率REB、AST、TOV 分別是籃板、助攻、失誤。一次拉五個賽季的數(shù)據(jù)量在一萬行上下完整跑完大約一到兩分鐘速度完全可以接受。2.3 數(shù)據(jù)落地CSV 與 SQLite 怎么選數(shù)據(jù)落地方式我一般分兩種情況。如果只是課程設(shè)計數(shù)據(jù)量在幾萬行以內(nèi)直接存CSV就夠了老師拷貝你的代碼和CSV文件就能復現(xiàn)。如果你打算長期維護、每周更新數(shù)據(jù)或者想在文檔里體現(xiàn)一點數(shù)據(jù)庫能力用 SQLite 更合適零配置、單文件、Python 內(nèi)置 sqlite3 即可讀寫不用額外裝 MySQL。存CSV時有一個坑nba_api 返回的某些列含有特殊字符直接用默認 to_csv 沒問題但用 Excel 打開中文列名可能出現(xiàn)亂碼。保存時我習慣把編碼指定為 utf-8-sig這樣 Excel 雙擊打開也不會亂碼讀取時如果遇到解析錯誤大概率是某行數(shù)據(jù)里有多余的逗號或引號用 on_bad_linesskip 就能兜底。如果你選 SQLite建表時不要照搬所有列挑實際會用到的字段建表就行。下面這段代碼把數(shù)據(jù)寫入 SQLite并給 game_id 和 team_id 建了聯(lián)合唯一索引import sqlite3 conn sqlite3.connect(nba_games.db) cur conn.cursor() # 建表只保留特征工程會用到的核心字段 cur.execute( CREATE TABLE IF NOT EXISTS games ( game_id TEXT, team_id INTEGER, team_abbreviation TEXT, matchup TEXT, game_date TEXT, pts INTEGER, plus_minus INTEGER, home_away TEXT, season TEXT, PRIMARY KEY (game_id, team_id) ) ) # 寫入前先重命名列為干凈的小寫格式 columns [GAME_ID, TEAM_ID, TEAM_ABBREVIATION, MATCHUP, GAME_DATE, PTS, PLUS_MINUS, HOME_AWAY, SEASON] games[columns].to_sql( games, conn, if_existsreplace, indexFalse) conn.commit() conn.close() print(SQLite 寫入完成)這里用 PRIMARY KEY (game_id, team_id) 做聯(lián)合主鍵能防止重復拉取時插入重復數(shù)據(jù)。后續(xù)做增量更新時可以先查詢當前庫里最大的 game_date只拉那之后的比賽再把新數(shù)據(jù)以 if_existsappend 追加進去不用每次全量重跑。to_sql 是 pandas 自帶的數(shù)據(jù)庫寫入方法很適合新手需要注意 DataFrame 列名如果有空格或特殊符號建表時會很麻煩所以寫入前先重命名成干凈的小寫列名最省事。2.4 請求頻率與異常處理限速、超時和重試nba_api 雖然封裝得不錯但底層還是去請求 stats.nba.com 的 HTTP 接口。如果把它當成隨便調(diào)的接口連續(xù)快速請求幾十次就會收到 429 狀態(tài)碼也就是請求過于頻繁被限流。這不是封IP但會讓循環(huán)中斷。我的經(jīng)驗是兩個約束同時加一是每次請求之間 sleep 至少 0.5 到 1 秒二是設(shè)置超時和重試機制遇到 429 或 5xx 錯誤就等幾秒再重試。下面是一段加了重試邏輯的拉取函數(shù)import time import requests from nba_api.stats.endpoints import leaguegamefinder def fetch_with_retry(season_str, max_retries4): for attempt in range(max_retries): try: finder leaguegamefinder.LeagueGameFinder( season_nullableseason_str, season_type_nullableRegular Season, timeout30 ) return finder.get_data_frames()[0] except requests.exceptions.HTTPError as e: # 429是限流5xx是接口臨時出錯都值得重試 wait 2 ** attempt 1 print(f請求失敗({e}){wait}秒后重試) time.sleep(wait) raise RuntimeError(f賽季 {season_str} 拉取失敗) for season in range(2020, 2025): season_str f{season}-{str(season 1)[-2:]} df fetch_with_retry(season_str) time.sleep(1.0)幾個細節(jié)說明。timeout30 表示單個請求最多等30秒防止網(wǎng)絡卡死導致程序掛在那里。重試的等待時間用 2^n 1 這種指數(shù)退避第一次失敗等3秒第二次等5秒第三次等9秒給服務端留出恢復的時間。還有一個容易被忽略的問題有的校園網(wǎng)出口會攔截帶特定 UAUser-Agent的請求。如果發(fā)現(xiàn) nba_api 一直在報連接錯誤或 SSL 錯誤先別急著懷疑代碼檢查一下系統(tǒng)網(wǎng)絡設(shè)置或者換個網(wǎng)絡環(huán)境再試一次。遇到存疑的報錯把完整異常棧貼到搜索引擎里按報錯關(guān)鍵詞搜通常比盲改代碼高效得多——這是這個項目里最典型的不確定是代碼問題還是網(wǎng)絡問題的場景。3. 特征工程決定準確率的不是模型而是這四步數(shù)據(jù)加工3.1 先定預測目標預測勝負還是預測分差動手寫模型之前第一件事是把預測目標定死。NBA比賽結(jié)果預測一般有兩種定義方式一是二分類預測主隊贏還是客隊贏二是回歸預測分差。課程設(shè)計我建議選二分類理由很實際二分類的評估指標準確率、AUC對新手來說好解釋答辯時一句模型對未知比賽預測準確率達到62%就夠直觀回歸任務要考慮分差預測誤差解釋起來繞而且分差分布離散模型很難學出有效規(guī)律。如果你非要做回歸也可以把回歸預測的分差轉(zhuǎn)成勝負標簽比如預測分差大于0就判主隊勝。這樣做的好處是多一個中間量壞處是誤差會疊加。建議主線做二分類把回歸當作補充實驗寫進文檔對比兩種建模方式的結(jié)果這反而是加分項。目標變量生成時有一個新手常犯的錯誤直接把原始數(shù)據(jù)里的 WL勝負字段當標簽。還記得前面說過 leaguegamefinder 返回的是球隊視角的數(shù)據(jù)嗎同一場比賽有兩行客隊那行的 WL 是客隊的勝負。如果不做配對直接喂給模型模型就學到看自己球隊的勝負去預測自己球隊的勝負這種作弊邏輯。正確的做法是按 GAME_ID 把一場比賽的兩行合并成一行主隊一列、客隊一列標簽是主隊是否獲勝。3.2 滾動均值特征近五場和近十場統(tǒng)計怎么算才不算錯特征工程里最有價值的特征組是兩支球隊各自最近N場比賽的表現(xiàn)統(tǒng)計業(yè)界叫滾動均值rolling average。它背后的假設(shè)很樸素一支球隊近期的進攻效率和防守效率最能反映它下一場可能的發(fā)揮。計算滾動均值最核心的一點只能用比賽日之前的數(shù)據(jù)絕不能用之后的數(shù)據(jù)。舉個例子預測1月15日的比賽只能用截至1月14日的比賽統(tǒng)計如果1月15日當天或之后的比賽混進滾動窗口就造成數(shù)據(jù)泄漏訓練準確率虛高好幾個點實戰(zhàn)預測卻崩盤。實現(xiàn)時先按 TEAM_ID 和 GAME_DATE 排序再對每支球隊單獨算最近5場和最近10場的滾動均值。下面這段代碼是完整實現(xiàn)# 先按球隊和日期排序保證滾動窗口的順序正確 games pd.read_csv(nba_games_raw.csv) games[GAME_DATE] pd.to_datetime(games[GAME_DATE]) games games.sort_values([TEAM_ID, GAME_DATE]).reset_index(dropTrue) # 要計算滾動均值的統(tǒng)計列 stat_cols [PTS, PLUS_MINUS, FG_PCT, REB, AST, TOV] for col in stat_cols: for window in [5, 10]: # 先按球隊分組計算滾動均值 roll ( games.groupby(TEAM_ID)[col] .rolling(window, min_periods1) .mean() .reset_index(level0, dropTrue) ) # shift(1) 把均值整體下移一行 # 讓第k行不再包含第k場自己的數(shù)據(jù)這是防泄漏的關(guān)鍵 games[f{col}_roll{window}] roll.groupby(games[TEAM_ID]).shift(1) print(games[[TEAM_ID, GAME_DATE, PTS, PTS_roll5, PTS_roll10]].head(20))注意沒有 shift(1) 的滾動均值等于把本場比賽的數(shù)據(jù)喂給了本場比賽這是整個項目最隱蔽的數(shù)據(jù)泄漏點務必檢查。這段代碼有兩個關(guān)鍵點。第一groupby(TEAM_ID).rolling(window).mean() 在分組內(nèi)部計算滾動均值窗口是5場或10場互不干擾。第二shift(1) 是防止數(shù)據(jù)泄漏的心臟它把計算結(jié)果整體下移一行這樣第k行存的是第k-1場及之前窗口內(nèi)的均值當前場比賽本身不參與自己的特征計算。為什么 min_periods1 而不是默認的 window因為賽季初的前幾場比賽不夠湊滿窗口。設(shè)成 window 的話賽季前4場的特征全是空值要么刪樣本要么手工填充設(shè)成1表示至少有一場比賽就開始算均值缺點是賽季初期特征偏小、波動大但至少模型有特征可用。認真一點的做法是用上一賽季的均值回填賽季前幾場課程設(shè)計階段不必做這么細。3.3 賽程特征休息天數(shù)、背靠背和主場優(yōu)勢怎么編碼滾動均值之外還有三類特征在NBA預測里被反復驗證有效休息天數(shù)、背靠背標記、主場優(yōu)勢。休息天數(shù)指距離上一場比賽隔了多少天。NBA常規(guī)賽幾乎每天都有比賽強隊一個賽季要打多次背靠背連續(xù)兩天比賽球員體能差異會直接影響比賽結(jié)果。計算方式是把同一支球隊的比賽按日期排序然后算相鄰兩場比賽的日期差。背靠背是個0/1標記表示該隊這場比賽的前一天是否也有比賽。注意背靠背還要區(qū)分主客場如果是客場打完再趕去下一個客場影響更大如果是連續(xù)兩個主場影響相對小。課程設(shè)計階段做一版簡化的0/1標記就夠了想認真雕琢可以拆成背靠背且客場和背靠背且主場兩個特征。主場優(yōu)勢是從 matchup 字段里解析出來的包含 表示客場否則是主場。這個特征在模型里通常系數(shù)顯著為正說明主場優(yōu)勢對NBA比賽結(jié)果有真實影響。下面這段代碼把這三類賽程特征一次性生成# 從 matchup 解析主客場包含 表示客場 games[is_home] games[MATCHUP].apply(lambda x: not in x) # 每支球隊的上一場比賽日期用于推算休息天數(shù)和背靠背 games games.sort_values([TEAM_ID, GAME_DATE]) games[prev_game_date] games.groupby(TEAM_ID)[GAME_DATE].shift(1) games[rest_days] (games[GAME_DATE] - games[prev_game_date]).dt.days # 背靠背距離上一場正好1天 games[back_to_back] (games[rest_days] 1).astype(int) # 主隊表和客隊表按 GAME_ID 合并回到比賽視角 home games[games[is_home]].copy() away games[~games[is_home]].copy() merged home.merge( away, onGAME_ID, suffixes(_home, _away) ) print(merged.shape) merged.to_csv(nba_games_features.csv, indexFalse)整體思路是把球隊視角數(shù)據(jù)拆成主隊表和客隊表再按 GAME_ID 合回比賽視角。合并之后每一行就是一場比賽左邊是主隊近期統(tǒng)計右邊是客隊近期統(tǒng)計中間夾著賽程特征。至此特征工程的骨架就搭完了。合并后行數(shù)會變成原來的一半因為每場比賽從兩行合為一行這是正常的。合并完記得檢查有沒有 GAME_ID 重復——如果接口在某個賽季返回了全明星賽或其他非正式比賽可能出現(xiàn)一對多的匹配需要提前按賽事類型過濾只保留常規(guī)賽記錄。3.4 時間切分為什么隨機打亂訓練集相當于讓模型作弊這個問題幾乎每個做時序預測的人都會踩一次用 train_test_split 默認隨機切分訓練集里混著后面的比賽測試集里混著前面的比賽。對NBA這種強時序依賴的數(shù)據(jù)隨機切分意味著模型的訓練數(shù)據(jù)里包含了未來特征和標簽產(chǎn)生隱性的時間交叉準確率虛高。正確的做法是按時序切分比如用2020到2023賽季的數(shù)據(jù)訓練用2024賽季的數(shù)據(jù)測試。train_test_split 不支持直接按時間切但把 shuffleFalse 配合已排序的數(shù)據(jù)即可實現(xiàn)或者干脆手動切片games pd.read_csv(nba_games_features.csv, parse_dates[GAME_DATE_home]) games games.sort_values(GAME_DATE_home).reset_index(dropTrue) split_date 2023-10-24 # 以2023-24賽季揭幕戰(zhàn)為界 train games[games[GAME_DATE_home] split_date] test games[games[GAME_DATE_home] split_date] print(f訓練集 {train.shape[0]} 場 f{train[GAME_DATE_home].min().date()} ~ {train[GAME_DATE_home].max().date()}) print(f測試集 {test.shape[0]} 場 f{test[GAME_DATE_home].min().date()} ~ {test[GAME_DATE_home].max().date()})這么切完會發(fā)現(xiàn)測試集在時間上完全晚于訓練集模型在測試集上的準確率通常比隨機切分低2到4個百分點這才是真實水平。答辯時主動提一句我沒有用隨機切分而是用了時間切分以避免數(shù)據(jù)泄漏這一句話就能讓評委知道你理解機器學習應用流程里最關(guān)鍵的細節(jié)。4. 機器學習模型選型與調(diào)參從邏輯回歸到XGBoost的三個階梯4.1 基線模型先跑邏輯回歸立住能跑通的版本模型部分我強烈建議先跑邏輯回歸當基線不要一上來就上XGBoost。原因有兩個一是邏輯回歸訓練快幾秒出結(jié)果適合用來驗證特征管道有沒有問題二是邏輯回歸的系數(shù)可以解釋你能看到哪些特征對預測結(jié)果影響最大這對寫課程設(shè)計文檔非常有幫助。特征列的準備和標簽列的定義是這一步的關(guān)鍵。以 nba_games_features.csv 為例特征列包括主隊和客隊的滾動均值、休息天數(shù)、背靠背標記。標簽列定義為 home_win表示主隊是否獲勝。import pandas as pd from sklearn.linear_model import LogisticRegression from sklearn.preprocessing import StandardScaler from sklearn.metrics import accuracy_score, log_loss games pd.read_csv(nba_games_features.csv, parse_dates[GAME_DATE_home]) games games.sort_values(GAME_DATE_home).reset_index(dropTrue) # 標簽主隊得分大于客隊得分則主勝 games[home_win] (games[PTS_home] games[PTS_away]).astype(int) # 特征列滾動均值 賽程特征 feature_cols [ PTS_roll5_home, PLUS_MINUS_roll5_home, FG_PCT_roll5_home, PTS_roll5_away, PLUS_MINUS_roll5_away, FG_PCT_roll5_away, rest_days_home, rest_days_away, back_to_back_home, back_to_back_away, ] X games[feature_cols] y games[home_win] # 邏輯回歸對特征尺度敏感先標準化 scaler StandardScaler() X_scaled scaler.fit_transform(X) # 時間切分2023-24賽季之前訓練之后測試 split_date pd.Timestamp(2023-10-24) train_idx games[GAME_DATE_home] split_date test_idx games[GAME_DATE_home] split_date model LogisticRegression(max_iter1000) model.fit(X_scaled[train_idx], y[train_idx]) y_prob model.predict_proba(X_scaled[test_idx])[:, 1] y_pred (y_prob 0.5).astype(int) print(f邏輯回歸準確率{accuracy_score(y[test_idx], y_pred):.4f}) print(f對數(shù)損失{log_loss(y[test_idx], y_prob):.4f}) # 打印系數(shù)看特征影響方向 coef_df pd.DataFrame({feature: feature_cols, coef: model.coef_[0]}) print(coef_df.sort_values(coef, ascendingFalse))這段代碼里max_iter1000 是因為標準化之后特征數(shù)量不算少默認100次迭代偶爾不收斂調(diào)大一點更穩(wěn)妥。predict_proba 返回二維數(shù)組取第二列就是主勝概率。log_loss 是概率預測的對數(shù)損失越小說明概率校準越好后面比較模型時比準確率更細膩。跑完你會看到PLUS_MINUS_roll5_home 這類凈勝分滾動均值的系數(shù)通常顯著高于其他特征說明近期凈勝分是預測比賽結(jié)果最強的單一信號。把基于系數(shù)分析特征重要性寫進課程設(shè)計報告就是一塊拿得出手的內(nèi)容。4.2 樹模型上場隨機森林和XGBoost的參數(shù)怎么設(shè)基線跑通之后下一步換更強的模型。比賽預測場景里隨機森林和XGBoost是主流選擇。兩者都是樹模型能自動處理特征之間的非線性關(guān)系不需要像邏輯回歸那樣做標準化。代價是模型本身像個黑匣子你很難直接說出每個特征的作用方向。隨機森林的優(yōu)勢是參數(shù)少、不容易過擬合、訓練速度快適合作為第一個升級版模型。XGBoost 的準確率通常比隨機森林高零點幾到一兩個百分點但參數(shù)非常多調(diào)起來耗時對新手不友好。建議課程設(shè)計用隨機森林做主線XGBoost 作為進階對比實驗時間緊的話只做隨機森林也完全夠。下面這段代碼同時跑隨機森林和 XGBoostfrom sklearn.ensemble import RandomForestClassifier from xgboost import XGBClassifier # 樹模型不需要標準化直接用原始特征 X_train, X_test X.iloc[train_idx], X.iloc[test_idx] y_train, y_test y[train_idx], y[test_idx] rf RandomForestClassifier( n_estimators300, max_depth6, min_samples_leaf5, random_state42, n_jobs-1 ) rf.fit(X_train, y_train) rf_prob rf.predict_proba(X_test)[:, 1] print(f隨機森林準確率{accuracy_score(y_test, (rf_prob 0.5).astype(int)):.4f}) xgb XGBClassifier( n_estimators300, max_depth4, learning_rate0.05, subsample0.8, colsample_bytree0.8, random_state42, eval_metriclogloss ) xgb.fit(X_train, y_train) xgb_prob xgb.predict_proba(X_test)[:, 1] print(fXGBoost準確率{accuracy_score(y_test, (xgb_prob 0.5).astype(int)):.4f})關(guān)鍵參數(shù)說明如下表模型參數(shù)作用課程設(shè)計推薦值隨機森林n_estimators樹的數(shù)量200~500隨機森林max_depth樹的最大深度防過擬合6~8隨機森林min_samples_leaf葉子節(jié)點最少樣本數(shù)5~10XGBoostlearning_rate學習率越小步長越細0.03~0.1XGBoostn_estimators迭代輪數(shù)與學習率配合200~500XGBoostsubsample每輪抽樣比例0.7~0.9XGBoostcolsample_bytree每棵樹使用特征比例0.7~0.9隨機森林的 max_depth6 和 min_samples_leaf5 是防過擬合的核心參數(shù)如果訓練集只有幾千場樹的深度超過8就很容易把訓練集背下來。XGBoost 的 learning_rate0.05 配合 n_estimators300表示以較小步長迭代300輪subsample0.8 每輪抽80%樣本colsample_bytree0.8 每棵樹抽80%特征這兩個參數(shù)能明顯提升泛化能力。另外樹模型的超參數(shù)設(shè)置在一定程度上有玄學成分不用追求全局最優(yōu)關(guān)鍵是先設(shè)一組合理的默認值跑通再圍繞防過擬合調(diào)深度和樣本量。eval_metriclogloss 是告訴 XGBoost 用對數(shù)損失作為內(nèi)部評估標準。如果你裝的是很老的 XGBoost 版本可能遇到 deprecation 警告不影響運行新版直接不用管。4.3 評估指標怎么選準確率、對數(shù)損失與AUC的分工課程設(shè)計報告里只寫一個準確率數(shù)字很單薄。建議至少同時報告三個指標準確率、對數(shù)損失和AUC它們各自回答不同的問題。準確率最直觀預測錯誤的場次占比多少但缺點是無法反映概率的可信度。比如模型對某場比賽給出51%的勝率贏了算對、輸了算錯但51%和95%的置信度顯然不一樣。對數(shù)損失就能懲罰這種低置信度錯誤模型在錯誤方向上給出的概率越高懲罰越重。AUC 則是排序能力的度量回答模型給出的概率排序是否合理和具體閾值無關(guān)對樣本不平衡也不太敏感。三者的組合能幫你判斷改進方向。如果準確率還行但 log loss 偏高說明模型對某些比賽過度自信可以降低樹模型深度如果 AUC 明顯高于0.5說明特征和標簽的關(guān)聯(lián)真實存在問題出在閾值設(shè)置可以微調(diào)判定閾值。from sklearn.metrics import roc_auc_score, brier_score_loss for name, prob in [(邏輯回歸, y_prob), (隨機森林, rf_prob), (XGBoost, xgb_prob)]: auc roc_auc_score(y_test, prob) brier brier_score_loss(y_test, prob) acc accuracy_score(y_test, (prob 0.5).astype(int)) print(f{name}: 準確率{acc:.4f}, AUC{auc:.4f}, Brier{brier:.4f})Brier 分數(shù)是概率預測和真實結(jié)果之間的均方誤差越小越好。答辯時一張表格列出三個模型的準確率、AUC、log loss、Brier就構(gòu)成了一個完整的評估體系。如果想把 Python數(shù)據(jù)分析與可視化 也加進去用 matplotlib 畫一條 ROC 曲線放到報告里能直觀展示三個模型在不同閾值下的表現(xiàn)差異。4.4 分組交叉驗證防止同賽季的比賽同時出現(xiàn)在訓練集和驗證集講完評估指標必須講交叉驗證的正確姿勢。很多同學用 GridSearchCV 調(diào)參時發(fā)現(xiàn)驗證集表現(xiàn)很好一到時間切分的測試集就掉點。原因在于默認的 KFold 是隨機切分的前面也說過隨機切分在時序數(shù)據(jù)上等于讓模型瞥見了未來。正確的做法是 TimeSeriesSplit 或 GroupKFold 按賽季分組。TimeSeriesSplit 每次都拿時間靠前的數(shù)據(jù)做訓練、時間靠后的做驗證模擬真實預測場景。GroupKFold 則保證整個賽季的數(shù)據(jù)在同一折里面避免同賽季比賽被切到訓練和驗證兩側(cè)。from sklearn.model_selection import TimeSeriesSplit, cross_val_score from sklearn.ensemble import RandomForestClassifier # 數(shù)據(jù)必須先按時間升序排序TimeSeriesSplit 才有效 games_sorted games.sort_values(GAME_DATE_home).reset_index(dropTrue) X_sorted games_sorted[feature_cols] y_sorted games_sorted[home_win] tscv TimeSeriesSplit(n_splits5) rf RandomForestClassifier(n_estimators200, max_depth6, random_state42, n_jobs-1) scores cross_val_score(rf, X_sorted, y_sorted, cvtscv, scoringaccuracy) print(fTimeSeriesSplit 交叉驗證準確率{scores.mean():.4f} ± {scores.std():.4f})關(guān)鍵點cross_val_score 用 TimeSeriesSplit 時不會自動打亂數(shù)據(jù)你必須確保傳入的 X_sorted 本身按時間升序排好否則切分失去意義。scoringaccuracy 可以換成 scoringroc_auc 評估排序能力。如果想用默認切分快速看一眼指標可以先用 KFold 跑一遍但報告里一定要寫明隨機切分在時序數(shù)據(jù)上的局限。把隨機切分和時間切分的對比寫進課程設(shè)計文檔本身就是很漂亮的實驗設(shè)計。5. 避坑指南NBA預測項目里最常翻車的五個地方這幾個坑是我自己反復踩、也幫同學改這個題目時見得最多的按出現(xiàn)頻率排序照著排查基本能解決大部分問題。5.1 現(xiàn)象拉取數(shù)據(jù)時頻繁報429或連接超時現(xiàn)象循環(huán)拉五個賽季的數(shù)據(jù)拉到第二個賽季就拋 requests.exceptions.HTTPError: 429 Too Many Requests或者程序直接卡住不動。原因nba_api 底層請求的是 NBA 官網(wǎng)接口官網(wǎng)對單IP的請求頻率有限制。課程設(shè)計階段大家常在機房或宿舍網(wǎng)絡下跑一個出口IP可能有多臺設(shè)備同時請求更容易觸發(fā)限流。另一個隱藏原因是某些版本的 nba_api 默認沒有設(shè)置 User-Agent被官網(wǎng)的防火墻識別成爬蟲直接拒絕。解決一是在每次請求之間加 time.sleep(1)把請求間隔控制在一秒以上二是給請求設(shè)置瀏覽器 UA 和完整的請求頭三是給單次請求設(shè)置 timeout 參數(shù)避免卡死。前面2.4節(jié)的重試代碼可以直接復用。如果學校網(wǎng)絡反復出問題換手機熱點試一次很多時候是網(wǎng)絡鏈路的問題而不是代碼的問題。5.2 現(xiàn)象訓練準確率高達80%以上一上真實預測就崩現(xiàn)象訓練集準確率能到85%時間切分的測試集也能到65%左右但拿模型去預測下一周的真實比賽準確率只有50%上下跟猜差不多。原因根子上幾乎全是數(shù)據(jù)泄漏。常見泄漏點有三個滾動均值沒有 shift(1)當天的比賽數(shù)據(jù)參與了當天特征計算切分沒有按時間隨機切分讓模型在訓練時看到了未來第三個最隱蔽——標簽構(gòu)造錯誤或者把比賽結(jié)束后的全場累計統(tǒng)計比如球隊單場籃板、助攻總數(shù)當成了特征數(shù)據(jù)和標簽同時來自同一個結(jié)果準確率自然虛高。解決逐一排查。滾動均值必須 shift(1)切分必須用時間切分標簽必須按 GAME_ID 配對后生成主隊勝負特征列里不能出現(xiàn)和比賽同一天生成的統(tǒng)計。排查方法很樸素隨機挑一場已知結(jié)果的比賽手工算它的滾動均值特征和代碼計算值對比看是否嚴格排除了當天比賽。在報告里寫一句已人工校驗特征無泄漏很顯專業(yè)。5.3 現(xiàn)象做滾動均值或合并時報索引不對齊現(xiàn)象跑特征工程時報 ValueError: cannot reindex on an axis with duplicate labels或者合并出來的結(jié)果是全 NaN。原因通常是因為 GAME_ID 有重復或者 rolling 之后 reset_index 的方式不對。一個 GAME_ID 在主客兩行里如果格式不一致一個純數(shù)字一個字符串merge 時會變成笛卡爾積。另外groupby().rolling() 返回的是分組級索引沒有正確 reset 的話會把原始 DataFrame 索引打亂后續(xù)一切按索引對齊的操作都會錯位。解決拿到原始數(shù)據(jù)后先做三件事GAME_ID 統(tǒng)一轉(zhuǎn)成 str檢查并去除重復行確保 GAME_DATE 已轉(zhuǎn)成 datetime。rolling 計算完統(tǒng)一 reset_index(dropTrue)再做 merge。標準的預處理開頭長這樣games[GAME_ID] games[GAME_ID].astype(str) games games.drop_duplicates(subset[GAME_ID, TEAM_ID]) games games.sort_values([TEAM_ID, GAME_DATE]).reset_index(dropTrue) assert games.duplicated(subset[GAME_ID, TEAM_ID]).sum() 0 print(數(shù)據(jù)檢查通過無重復記錄索引已重置)5.4 現(xiàn)象同樣的代碼換臺電腦跑結(jié)果完全不一樣現(xiàn)象自己電腦上準確率62%換到舍友電腦或者答辯電腦上跑變成58%甚至更低或者直接報錯。原因最常見的原因是庫版本不一致。pandas 不同版本的 rolling 行為、sklearn 不同版本的隨機數(shù)、nba_api 不同版本的字段名都會導致差異。特別是 nba_api 更新頻繁字段名或構(gòu)造函數(shù)參數(shù)名可能變化老代碼在新版本下可能直接報錯。另一個原因是數(shù)據(jù)不同——兩次拉取時間不同數(shù)據(jù)里包含的場次數(shù)不一樣特征統(tǒng)計自然有差異。解決寫一個 requirements.txt 把核心依賴版本鎖死文檔里寫明測試環(huán)境。答辯前提前去答辯電腦上把環(huán)境和依賴裝好不要臨場拉數(shù)據(jù)。數(shù)據(jù)方面固定下載日期把原始CSV隨代碼一起提交任何環(huán)境跑的都是同一份數(shù)據(jù)。如果 nba_api 版本過新導致參數(shù)報錯快速定位的方式是打印 dir(leaguegamefinder) 看當前支持的參數(shù)名別拿老教程硬套。5.5 現(xiàn)象預測概率總往0.5收縮看不出觀點現(xiàn)象模型輸出的概率絕大多數(shù)落在0.4到0.6之間很少出現(xiàn)70%以上的判斷看著不夠有觀點。原因這在NBA預測里是正?，F(xiàn)象不是bug?；@球比賽本身隨機性很強主場優(yōu)勢、近期狀態(tài)這些信號只能解釋比賽結(jié)果的一部分方差模型天然學不到特別強的區(qū)分度。NBA單場兩隊合計得分動輒230分以上一個球員手感爆發(fā)就能改變走勢概率往0.5收縮是信息量的真實反映不是模型壞了。解決不要為了模型有觀點去強行調(diào)閾值或改損失函數(shù)。正確做法是接受這個現(xiàn)實從特征側(cè)找增量——加入球員輪休、傷病名單、球隊連勝連敗狀態(tài)都能小幅拉開概率。還可以建模分差而不是勝負因為連續(xù)量比分立標簽包含更多信息。說到底60%到63%的準確率對這個任務已經(jīng)是很不錯的水平對比隨機猜測的50%基準這個結(jié)論本身就立得住。6. 進階驗證用滾動回測與概率校準檢驗模型真實水平模型訓練完還差最后一環(huán)用一套能反復執(zhí)行的驗證流程證明模型不是碰運氣。課程設(shè)計里最常說的一句話是模型準確率62%但這個數(shù)字怎么來的、在不同時間段是否穩(wěn)定很多人說不清楚。這一章講兩個進階動作滾動回測和概率校準。滾動回測的思路是模擬真實的預測節(jié)奏。假設(shè)現(xiàn)在是某個比賽日你有截至前一天的所有數(shù)據(jù)要預測今天所有比賽的勝負等比賽結(jié)束把預測和結(jié)果對比記錄命中。把時間軸往前推每周做一次這樣的預測累積一整個賽季就得到一條真實的準確率曲線。實現(xiàn)上不需要復雜框架一個 for 循環(huán)就能完成。# 把測試期按周切塊逐周回測 test_games games[games[GAME_DATE_home] split_date].copy() test_games[week] test_games[GAME_DATE_home].dt.isocalendar().week results [] for week, group in test_games.groupby(week): # 截止到本周之前的全部數(shù)據(jù)作為訓練集 train_data games[games[GAME_DATE_home] group[GAME_DATE_home].min()] if len(train_data) 200: continue X_tr train_data[feature_cols] y_tr train_data[home_win] # 每周重新訓練一次模擬真實部署節(jié)奏 rf RandomForestClassifier(n_estimators200, max_depth6, random_state42) rf.fit(X_tr, y_tr) prob rf.predict_proba(group[feature_cols])[:, 1] acc ((prob 0.5).astype(int) group[home_win].values).mean() results.append({week: week, games: len(group), accuracy: acc}) result_df pd.DataFrame(results) print(result_df) print(f整體回測準確率{result_df[accuracy].mean():.4f})這段代碼的核心是每周重訓一次而不是訓一次模型測一整年。因為NBA賽季中有交易、傷病、陣容變化固定模型會隨時間推移慢慢失效。回測結(jié)果里命中率的波動范圍值得關(guān)注——如果某幾周準確率突然跌到40%以下去查那幾周發(fā)生了什么往往能對應上全明星周末、交易截止日這類特殊賽程事件。概率校準是第二個值得做的動作。模型輸出0.55的概率到底接近真實命中率還是虛標需要用校準曲線驗證。sklearn 的 calibration_curve 可以直接畫from sklearn.calibration import calibration_curve import matplotlib.pyplot as plt # 把測試集概率分桶對比每個桶內(nèi)的實際命中率 prob_true, prob_pred calibration_curve(y_test, xgb_prob, n_bins10) plt.figure(figsize(6, 6)) plt.plot(prob_pred, prob_true, markero, labelXGBoost) plt.plot([0, 1], [0, 1], linestyle--, label理想校準) plt.xlabel(預測概率) plt.ylabel(實際命中率) plt.legend() plt.savefig(calibration_curve.png, dpi150)如果校準曲線明顯偏離對角線說明概率系統(tǒng)性偏高或偏低這時可以用 CalibratedClassifierCV 做一次事后校準。對課程設(shè)計來說畫一張校準曲線并解釋它的含義比多調(diào)幾個百分點的準確率更能體現(xiàn)你對機器學習模型的理解深度。我自己做這個項目時養(yǎng)成的習慣是每個比賽日結(jié)束后把前一天的真實結(jié)果回填到數(shù)據(jù)表重算滾動均值重新訓練模型再把當日比賽的預測輸出到一個CSV。堅持一個月累積下來就能畫出一條真實的準確率曲線。看到曲線連續(xù)下滑就知道該更新特征或者查查是不是有核心球員傷停了——這種從數(shù)據(jù)里發(fā)現(xiàn)問題的感覺比調(diào)參更有成就感。這個項目做完你帶走的不只是代碼而是一套從需求到可驗證結(jié)果的完整套路先跑通最小流程再逐層加特征、換模型、補評估每一步都有可驗證的輸出。以后做別的數(shù)據(jù)類項目這條骨架都能直接復用。希望幫到你。本文還有配套的精品資源點擊獲取