简介：一套基于Python的英雄联盟（LoL）胜率预测系统源码，面向电子竞技数据分析师、机器学习初学者及战术研究爱好者，解决从海量历史比赛数据中预测对局胜率的核心问题，可应用于战队BP策略分析、赛事复盘、选手训练与教学演示。整包共24个文件，压缩后仅31KB，以22个Python脚本为主体，按数据生成、特征构建、分类器训练、状态测试等功能模块划分，并附带.gitignore与数据结构说明txt，目录精简、逻辑清晰。已有235人学习下载。资源覆盖完整机器学习流程：利用Pandas清洗原始比赛记录，通过特征工程提炼战队历史战绩、选手KDA、团队经济等关键指标，借助Scikit-learn训练逻辑回归、随机森林等分类模型，并用交叉验证与网格搜索调优；配套的多个测试脚本与配置文件，便于快速运行、逐行调试和二次开发。无论是想掌握ML落地电竞场景的完整思路，还是需要一份可直接扩展预测模型的项目模板，这套源码都能提供扎实的参考。
1. LeaguePredictor：不是玄学，是把每局对局矢量化成胜率
开黑前对着双方阵容互道“这局稳了/没了”，是每个英雄联盟玩家都做过的事。但凭感觉判断阵容胜负，经常被翻盘打脸。某数据分析师朋友把这个直觉用Python落成了一个小项目LeaguePredictor：拉取对局数据，把击杀、补刀、视野、经济差、英雄组合等字段清洗成特征，训练分类模型，最终输出胜率。它的核心不是让你上分，而是给你一套可复现的「阵容评分」能力——自己在游戏开始前算一算哪边赢面大，顺便把数据分析、特征工程、机器学习调参完整跑一遍。适合想入门机器学习但不想跑鸢尾花手写数字的人，也适合游戏数据爱好者拿真实数据练手。
2. 技术栈与工程结构：为什么选Python，数据从哪里来
2.1 技术选型：pandas接数据，XGBoost做主力模型
这个项目在选型上没有搞花活，整体沿着「数据清洗、特征工程、模型训练、结果预测」四步走。数据清洗和特征拼接用pandas，因为对局数据本质上是结构松散的JSON，用pandas的DataFrame做行列变换比手写循环快得多。模型部分主力用XGBoost，偶尔拿逻辑回归或随机森林做对比基线，理由是这类表格型数据场景下，梯度提升树对特征量纲、缺失值、异常值的容忍度都比较好，不需要做过度的归一化就能出不错的效果。
我一般会把scikit-learn和XGBoost同时装好，训练脚本里留一个模型参数开关，方便在逻辑回归和XGBoost之间切换对比。关于版本，Python建议3.9及以上，pandas和XGBoost用当前稳定版本即可，项目本身不依赖某个特定小版本。整个项目不涉及GPU推理，单机上用CPU跑万级样本量完全够用，这也是选XGBoost而不是深度学习框架的原因——没必要为一个表格分类问题引入过重依赖。
2.2 目录结构：把数据、特征、模型、预测拆成四层
这个项目在工程组织上最大的优点是「四层分离」，拿到源码后第一件事是看它的目录结构，而不是急着装依赖。常见的组织方式是这样：
LeaguePredictor/ ├── data/ │ ├── raw/ # 原始对局JSON或CSV │ ├── processed/ # 清洗后的结构化数据 │ └── sample/ # 小样本测试集 ├── features/ │ ├── build_features.py # 特征构建 │ └── feature_config.py # 特征字段配置 ├── models/ │ ├── train.py # 训练与交叉验证 │ └── predictor.py # 加载模型并输出胜率 ├── scripts/ │ ├── fetch_data.py # 数据获取脚本 │ └── run_pipeline.py # 一键执行完整流程 └── config.yaml # 全局配置每一层只做一件事：scripts层负责拉数据，features层把数据变成特征，models层负责训练和推理，data目录只存放数据产物。这样的设计对单人项目来说可能显得重，但如果你后续要加特征、加模型、加服务化接口，会发现每一层都有清晰的落点，不需要重构。
config.yaml是全局配置的集中地，API相关的开关、样本时间范围、特征开关、模型参数都写在这里。run_pipeline.py会依次调用数据获取、特征构建、模型训练三个步骤，并把中间产物自动写入对应目录，这个脚本很适合作为执行入口，跑一次就能看到从数据到模型的完整链路。
2.3 数据获取：离线清洗与接口拉取的取舍
英雄联盟对局数据有两个常见来源。一个是开源的对局数据集，通常以CSV或JSON格式打包好，已经包含玩家段位、英雄ID、击杀死亡助攻、补刀、经济、视野得分等字段，适合快速上手；另一个是官方开发者平台的对局接口，需要注册获取API密钥，按时间范围拉取指定对局的详细信息。这个项目里两者都做了适配，config.yaml中的data_source字段用来切换来源。
如果是自己拉数据，直接按比赛时间、游戏模式（排位/匹配）、玩家段位三个维度过滤即可。段位字段建议只取铂金及以上段位的对局，这部分数据质量更稳定，玩家水平波动小，特征与胜率的相关性也更容易被模型学到。拉下来后的原始数据通常存在data/raw下，文件名带时间戳防止重复拉取。需要注意接口拉取有频率限制，常见做法是在fetch_data.py里做请求限流，每次请求之间sleep 1秒到2秒，避免触发封禁。
3. 核心模块拆解：一个对局样本从进入到预测的完整链路
3.1 原始对局长什么样：从JSON到结构化字段
拿到了原始数据，第一件事是看清字段结构。对局数据的原始JSON里包含participants（参战者）、teams（两支队伍）、timeline（时间线）三大部分。参战者里每个玩家有击杀、死亡、助攻、造成伤害、经济、等级；团队信息里有队伍总经济、总补刀、防御塔数量、大小龙数量。时间线则记录了每隔一段时间的经济差和塔数差。
在动手建模前，我习惯先写一个小脚本把某一条原始记录的关键字段打出来，确认数据类型和缺失情况。这个步骤看起来基础，实际上能省掉很多后面定位问题的麻烦：
import json with open("data/raw/match_20250211.json", "r", encoding="utf-8") as f: match = json.load(f) print("元数据字段:", list(match.keys())) print("队伍数量:", len(match["teams"])) team0 = match["teams"][0] print("队伍0关键字段:", { "win": team0.get("win"), "firstBlood": team0.get("firstBlood"), "towerKills": team0.get("towerKills"), "totalGold": team0.get("totalGold") }) player = match["participants"][0] print("参战者关键字段:", { "championId": player.get("championId"), "kills": player.get("kills", 0), "deaths": player.get("deaths", 0), "assists": player.get("assists", 0), "totalMinionsKilled": player.get("totalMinionsKilled", 0), "visionScore": player.get("visionScore", 0) })这段代码的作用是快速对数据集建立结构认知。每个字段都带get默认值，是因为不同来源的JSON字段命名可能有细微差异，有的叫wardScore，有的叫visionScore，加上默认值避免字段缺失时直接抛KeyError。确认字段名之后，再写struct_clean.py把统一字段名固化下来，避免每次拉数据都重新对一遍。
3.2 特征工程：阵营、位置、时间窗口怎么塞进一行
特征工程是胜率预测的核心，也是翻车最多的地方。原始JSON里每个对局有10个参战者，但模型输入需要的是「一行代表一个对局」或「一行代表一个分阶段对局」。常见做法是先把双方阵营分别聚合成队伍级特征，再做差值。
我一般会把特征分成三类：队伍静态特征、队伍动态特征、差值特征。静态特征比如阵容硬度、控制数量、英雄组合强度；动态特征来自时间线，比如10分钟时的经济差、20分钟时的塔差，这类特征能反映当前节奏；差值特征把双方同维度字段相减，模型更容易理解“领先多少”而不是“蓝方多少红方多少”。
下面这段代码是从特征构建脚本里抽取的核心逻辑，输入是清洗后的DataFrame，输出是模型可用的特征矩阵：
import pandas as pd import numpy as np def build_match_features(df): # df包含一局对局中双方阵营的聚合数据 blue = df[df["side"] == "blue"] red = df[df["side"] == "red"] features = {} # 静态差值特征：KDA、补刀、经济 for col in ["kills", "assists", "totalMinionsKilled", "totalGold"]: features[f"diff_{col}"] = blue[col].sum() - red[col].sum() # 动态时间线特征：15分钟经济差、15分钟经验差 features["gold_diff_at_15"] = blue["goldAt15"].mean() - red["goldAt15"].mean() features["xp_diff_at_15"] = blue["xpAt15"].mean() - red["xpAt15"].mean() # 击杀死亡比，死亡数加1避免除零 features["blue_kda_ratio"] = ( blue["kills"].sum() + blue["assists"].sum() ) / (blue["deaths"].sum() + 1) features["red_kda_ratio"] = ( red["kills"].sum() + red["assists"].sum() ) / (red["deaths"].sum() + 1) features["kda_ratio_diff"] = ( features["blue_kda_ratio"] - features["red_kda_ratio"] ) return pd.DataFrame([features])这段代码的构造逻辑并不复杂，核心思路是把「10个玩家的细节」压缩成「两支队伍的数值差」。kills、totalMinionsKilled这类字段在队伍之间求差值，模型面对的是“蓝队比红队多推了多少兵线、多拿了多少经济”，比同时输入两边绝对值更容易学到方向性规律。KDA比率单独做了除零保护，死亡数为0的时候加1平滑，这是表格型数据里最基础的防御性处理。
在真实数据上，建议保留5分钟、15分钟、25分钟等多个时间节点的经济差特征，因为游戏节奏会随版本变化，不同时间节点的经济差对胜率的影响权重差异很大。我在调试feature_config.py时会用开关逐个打开时间节点，观察哪些节点对AUC贡献最高，而不是一股脑全部灌进去。
3.3 训练主流程：样本切分、交叉验证与模型选择
特征构建完后进入训练环节。训练脚本里有一个容易被新手忽略的点：样本切分方式。比赛数据天然带时间属性，如果直接把所有样本随机打乱再切训练集和测试集，高版本对局的特征分布可能泄露到低版本样本里，造成评估结果虚高。这个项目里我采用的是按时间排序后分段切分，前80%的时间作为训练集，后20%作为测试集。
训练脚本的核心部分用XGBoost的交叉验证方式来选择迭代轮数，再用early_stopping防止过拟合：
import xgboost as xgb from sklearn.model_selection import StratifiedKFold from sklearn.metrics import roc_auc_score X = train_features y = train_labels params = { "max_depth": 4, "eta": 0.03, "objective": "binary:logistic", "eval_metric": "auc", "subsample": 0.8, "colsample_bytree": 0.8, "seed": 42 } dmatrix = xgb.DMatrix(X, label=y) cv_result = xgb.cv( params, dmatrix, num_boost_round=2000, nfold=5, early_stopping_rounds=50, stratified=True, as_pandas=True ) best_rounds = cv_result["test-auc-mean"].idxmax() + 1 print(f"最佳迭代轮数: {best_rounds}") final_model = xgb.train( params, dmatrix, num_boost_round=best_rounds )参数里max_depth取4，比默认的6要小，原因是当前特征数量有限，深度过大容易在交叉验证中表现不稳定。eta取0.03，配合较大的迭代轮数，目的是让每一棵树的影响更小，整体更平滑。subsample和colsample_bytree都取0.8，相当于让每棵树在80%的样本和80%的特征上训练，起到类似随机森林的效果，减小方差。early_stopping_rounds设50，当连续50轮的测试AUC都没有提升时停止训练，防止在无效迭代上浪费时间。
完成训练后，把模型保存为models/xgb_model.json，方便predictor.py后续加载。同时保存一份特征列名清单，这样预测时如果输入数据缺少某个特征列，可以立刻发现维度不匹配，而不是等模型报错才排查。
4. 评估调参与常见问题排查：从AUC到翻车现场
4.1 为什么不用准确率：AUC才是胜率预测的标尺
胜率预测是多分类还是二分类并不绝对，但实际上每个对局的结果只有输赢两种，所以模型天然是二分类问题。二分类模型最常见的评估指标是准确率，但在比赛数据上准确率有很强的迷惑性——如果数据里70%的对局是红方获胜，模型全预测红方也能拿到70%的准确率，而这种预测毫无意义。
这个项目里以AUC（ROC曲线下面积）作为主要评估指标，AUC衡量的是模型把正样本排在负样本前面的概率，不受类别分布影响。在输出结果里，常见做法是打印训练集AUC、测试集AUC，以及5折交叉验证的AUC均值和标准差。标准差很关键，如果5折AUC方差超过0.02，基本可以认为特征或样本切分有问题，模型在不同数据切片上的表现很不稳定。
测试集AUC落在0.65到0.75之间是这个场景的正常水平。英雄联盟对局的影响因子除了可量化的数据外，还有选手状态、英雄熟练度等大量外部变量，模型能解释一部分方差就已经有价值了。如果目标是把AUC推到0.85以上，不要试图堆模型复杂度，而是考虑引入更多特征，比如选手历史胜率、英雄组合协同度，这才是合理的下一步。
4.2 调参顺序：先修数据泄漏，再动模型参数
调参最容易犯的错误是一上来就动XGBoost的learning_rate或者max_depth，这样调半天往往发现提升微小。我的习惯是严格按照「数据 → 特征 → 模型」的顺序排查：先确认样本切分是否按时间排序，再看特征是否存在未来函数，最后才调模型参数。
所谓未来函数，在游戏对局场景里很容易踩中：用「下一分钟的经济差」预测这一分钟之后的胜负，模型学到的其实是作弊信息，测试集里如果混入了这类特征，评估结果会虚高到离谱。排查方法是把特征按产出时间归类，只用「对局开始前或当前时间点已知」的字段。列好特征清单后逐项问自己：这个信息在我预测的那一刻拿得到吗？拿不到就直接删除。
排查完泄漏问题后，调参顺序是：先调subsample和colsample_bytree这类随机性参数，再调max_depth这类复杂度参数，最后调eta和num_boost_round。调参过程中每次只改一个参数，同时记录交叉验证的AUC均值和方差，方便对比哪次改动真正有效。这个习惯能省下大量重复劳动。
4.3 五个常见踩坑点
现象：训练时提示除零警告，损失函数出现NaN。原因：KDA计算时死亡数为0，直接做除法得到无穷大，后续特征缩放时把无穷大带入了树模型。解决：所有除法运算的分母统一加平滑项，比如在deaths上+1，或改用np.where判断后再计算。这是赔率预测类项目最容易出现的问题，死亡数为0的高光对局并不少见。
现象：英雄ID做独热编码后特征数量爆炸，训练集AUC接近1，测试集AUC只有0.58。原因：英雄池有一百多个，独热编码后特征维度从几十涨到几百，样本量不够时模型把英雄ID本身当成了主要信号，过拟合严重。解决：改用目标编码，把每个英雄的历史胜率作为数值特征，或者对英雄ID先做聚类压缩成少量类别。目标编码需要小心做交叉验证内的平滑处理，防止把当前对局的结果泄露进编码值。
现象：随机切分训练集测试集时AUC是0.73，改成按时间切分后掉到0.66。原因：随机切分让版本更新前后的对局混在一起，模型记住了版本特征，一旦遇到新版本数据就失效。这不算模型变差，是评估方式泄露了未来信息。解决：严格按比赛时间戳排序，时间靠前的样本进训练集，靠后的进测试集。每次更新数据后，滚动更新训练集窗口，保持训练数据始终与预测时段的版本接近。
现象：预测所有对局的胜率都在0.45到0.55之间，模型几乎不输出极端值。原因：输入特征里缺少「阵容优劣」这类强信号，树模型只能学到微弱相关性。解决：在特征工程里加入英雄组合协同度，比如常见搭配的双人路组合、开团型辅助与进场型打野的组合评分，这类先验特征能显著拉开输出分布的方差。另外检查是不是因为训练数据里胜负分布太均衡，可以尝试在样本里加权重。
现象：用接口拉取的数据和本地数据集拼接训练后，测试集AUC反而下降。原因：两边数据的字段口径不一致，比如一边是totalDamageDealtToChampions，另一边是damageDealtToChampions，字段合并后新数据大量缺失或全为0。解决：写一个字段映射函数，把不同来源的字段名统一成标准命名，再检查缺失率超过30%的列直接丢弃。数据源切换后，重新跑一遍探索性数据分析，不要默认字段名一致。
5. 二次开发：把离线预测变成赛前阵容评分助手
有了训练好的XGBoost模型，离线的「输出胜率」已经能跑通，但它的价值还有很大提升空间。我建议你从三个方向做二次开发：第一是把模型改造成按游戏时间阶段分段预测的「阶段胜率模型」，分别预测开局、15分钟、25分钟三个节点的胜率，这样看比赛时能直观看到翻盘曲线；第二是增加阵容组合评分功能，输入两只队伍的五个英雄ID，自动输出阵容的进攻性、防守性、后期强度等维度的评估，让预测结果更可解释；第三是做成一个简单的Web接口，让朋友也能在网页上输入阵容并看到胜率预测。
如果做Web接口，最省力的方案是用FastAPI包一层预测服务，模型加载到内存后通过POST接口接收阵容特征，返回胜率和概率分布：
from fastapi import FastAPI from pydantic import BaseModel import pandas as pd app = FastAPI() model = load_model("models/xgb_model.json") class MatchInput(BaseModel): blue_kills: float red_kills: float blue_totalGold: float red_totalGold: float # 实际使用时把特征字段完整列出 @app.post("/predict") def predict_win_rate(input_data: MatchInput): feature_dict = input_data.dict() df = pd.DataFrame([feature_dict]) win_prob = model.predict_proba(df)[0][1] return {"blue_win_rate": round(float(win_prob) * 100, 2)}代码里注意先启动服务再加载模型，避免每个请求都重复加载模型文件，带来不必要的延迟。多数情况下一次对局特征只有二三十个字段，吞吐量根本不是瓶颈，所以不需要上消息队列，直接同步请求响应即可。预测服务跑起来后，可以用curl或Postman构造一条训练集里已有的样本验证预测结果与训练脚本输出是否一致，这个验证步骤能确认特征列顺序是否对应得上。
验证阶段建议用滚动回测而不是一次性切分：每次新增一批对局数据，就把新数据追加到训练集末尾，重新训练并测试最近时间段的效果。滚动回测能持续暴露模型随版本更新的衰减速度，如果连续几个时间窗的AUC都在下降，说明原有特征已经跟不上版本变动，需要补充新特征了。这个习惯让模型具备「自检」能力，而不是训练一次就固化了。
这几条改造做下来，LeaguePredictor就不再只是一个跑完就丢的训练脚本，而是一个能持续使用的赛前分析工具。每次拿到新数据，我都会强制自己先重跑一遍滚动回测，确认AUC没有明显掉点再更新部署。踩过的坑多了之后，我渐渐明白胜率预测的核心从来不是模型本身，而是特征理解和对数据来源的把控，这比调出一个漂亮AUC更有价值。希望这个项目能帮你在数据分析和游戏数据结合的路上少走一段弯路。
本文还有配套的精品资源，点击获取
