开源工具：用Riot API自动采集80万高分段LoL对局数据

从游戏爱好到数据科学项目

对于同时热爱《英雄联盟》(LoL)和数据科学的开发者来说，一个自然而然的想法是：能否用机器学习模型（比如XGBoost）纯粹基于队伍阵容和英雄组合来预测比赛结果？

XGBoost（eXtreme Gradient Boosting）是一种基于梯度提升决策树的集成学习算法，由陈天奇于2014年提出。它通过串行地构建多个决策树，每棵树都试图纠正前面树的预测误差，最终将所有树的预测结果加权组合。XGBoost在Kaggle等数据竞赛中表现突出，特别擅长处理表格数据和特征工程后的结构化数据。相比传统梯度提升算法，XGBoost引入了L1和L2正则化项防止过拟合，支持并行计算提升训练速度，并内置了缺失值处理机制。在同类算法中，XGBoost与微软推出的LightGBM和Yandex的CatBoost并称为"GBDT三巨头"——LightGBM在大规模数据上训练更快，CatBoost在处理类别特征时更方便，而XGBoost在社区生态和稳定性方面积累最深。与随机森林（Random Forest）相比，XGBoost的树是顺序构建而非并行构建，因此能更有效地修正系统性偏差。在游戏胜负预测这类二分类任务中，XGBoost能够自动捕捉英雄组合之间的非线性交互关系——例如"当队伍同时拥有强开团英雄和AOE法师时，胜率显著提升"这类复杂模式，无需手动设计复杂的特征工程。历史上，多个Kaggle游戏预测竞赛（包括Dota 2胜负预测）的获奖方案均以XGBoost为核心模型。

这正是开源项目 lol-dataset-generator 诞生的初衷。据Reddit上的一位开发者分享，他在构建预测模型时遇到了核心痛点——缺乏一个针对当前赛季的、干净且大规模的公开数据集。市面上现有的LoL数据要么过时，要么格式混乱，难以直接用于机器学习训练。

为了解决这个问题，他基于Python和官方Riot API，从零打造了一个完整的数据集生成器并完全开源。

Riot Games为开发者提供了一套完整的RESTful API体系，允许第三方应用访问《英雄联盟》的游戏数据。API分为多个端点（endpoints），包括召唤师信息（Summoner API）、对局历史（Match API）、排行榜（League API）、英雄精通度（Champion Mastery API）等。开发者需要在Riot Developer Portal注册并申请API密钥，免费的开发者密钥有严格的速率限制（通常为每秒20请求，每2分钟100请求），而经过审核的生产级密钥可获得更高配额。API返回JSON格式数据，包含详细的对局时间线、击杀事件、经济数据等。一个关键概念是PUUID（Player Universally Unique Identifier）——这是Riot在2021年引入的全球唯一玩家标识符，取代了旧的地区性Summoner ID，使得跨服数据关联成为可能。Riot API采用分区（region）架构，不同服务器（如NA、EUW、KR）需要使用对应的区域端点，而对局数据则通过大区端点（americas、europe、asia）访问。此外，Riot还维护着Data Dragon——一个静态资源库，提供英雄数据、技能描述、图片等不频繁变动的信息，无需消耗API配额即可访问。社区也围绕官方API构建了丰富的生态，例如Python封装库Riot-Watcher和Cassiopeia，它们提供了更友好的接口和自动速率限制管理。值得注意的是，API实施了数据保留策略，通常只能获取近期几个月的对局数据，这也是为什么需要持续采集并本地化存储的原因之一。

项目在Reddit上的分享

该项目托管在GitHub上，任何人只需申请一个免费的Riot开发者API密钥即可运行使用。

工具核心功能：自动化高分段数据采集

聚焦高质量对局样本

该工具的核心能力在于自动化地聚焦高质量对局。它会自动抓取所有服务器（regions）中的王者(Challenger)、宗师(Grandmaster)和大师(Master)段位玩家。这种设计思路很有讲究——高分段玩家的对局往往更能反映版本英雄强度和真实的战术博弈，噪声更少，对训练预测模型而言数据质量更高。

在机器学习中，样本质量往往比数量更重要。《英雄联盟》的段位系统呈金字塔分布，王者、宗师、大师段位仅占玩家总数的约0.1%，但这些高分段对局具有独特价值。首先，决策质量高：高段位玩家对英雄理解深刻，BP选择更接近理论最优解，减少了低段位常见的"乱选"噪声。其次，元游戏代表性强：职业赛场和高分段的英雄选择趋势高度相关，这些数据更能反映版本真实强度。第三，技术执行稳定：高段位玩家能充分发挥英雄潜力，对局结果更多取决于阵容和战术而非操作失误。从统计学角度，这相当于对样本空间进行了"质量筛选"，牺牲了样本的随机性但提升了信噪比（SNR）。

这里存在一个值得注意的统计陷阱——辛普森悖论（Simpson's Paradox）：如果将高段位和低段位数据混合分析，某些英雄的整体胜率可能呈现出与分段位分析完全相反的趋势。例如，一个操作门槛极高的英雄可能在低段位胜率仅45%而在高段位达到55%，混合后的50%胜率完全掩盖了真实情况。因此，按段位分层采样不仅是"质量筛选"，更是避免统计谬误的必要手段。不过这也带来局限性——模型可能在低段位预测效果不佳，因为低段位存在完全不同的游戏模式和英雄生态，某些在高分段被视为弱势的英雄反而在低段位表现强势。

采集流程分为三步：

获取各大区高分段玩家名单
收集这些玩家的排位单双(Ranked Solo/Duo)对局ID
提取对局详情并将其"扁平化"(flatten)成干净的、可直接用于机器学习的CSV文件

结构化的特征字段

生成的数据集包含了对建模有价值的关键特征：

版本号(Patch version)：LoL每两周更新一次平衡性调整，同一英雄在不同版本的强度可能天差地别，这个字段对模型泛化至关重要

《英雄联盟》采用快速迭代的平衡性调整机制，大约每两周发布一个新补丁（Patch），每年累计约24个版本。每个版本可能调整英雄的技能伤害、冷却时间、基础属性，或改变装备、符文系统，甚至重做整个英雄机制。这导致同一英雄在不同版本的强度可能发生巨大变化——某个版本的T0级英雄在下个版本可能被削弱到冷门。在机器学习理论中，这种现象被称为概念漂移（concept drift）——数据的底层分布随时间发生变化，导致历史训练的模型性能下降。概念漂移分为突变型（如大版本英雄重做，某英雄技能机制彻底改变）和渐变型（如连续多个版本的小幅数值调整），LoL的版本更新通常兼具两种特征。应对概念漂移的常见策略包括：（1）时间衰减加权：赋予近期对局更高的训练权重，使模型更关注当前版本的数据分布；（2）滑动窗口训练：仅使用最近N个版本的数据，丢弃过时样本；（3）版本特征编码：将版本号作为模型输入特征，让模型自主学习版本间差异；（4）在线学习：每个新版本到来时用增量数据更新模型参数。职业电竞分析中，通常只参考最近2-3个版本的数据来制定BP策略，因为更早的数据参考价值已大幅降低。这也是为什么该项目强调"针对当前赛季"的数据集尤为重要。

游戏时长(Game Duration)
双方队伍的英雄分路：包括上单(Top)、打野(Jgl)、中单(Mid)、下路(Bot)、辅助(Sup)
队伍平均段位(Average Team Tier)
比赛结果(Win/Loss)

这些字段的组合恰好覆盖了"英雄选择阶段结束后即可获得的信息"，为构建"选人即预测胜负"的模型提供了完整输入。

"ML-ready"（机器学习就绪）的数据集指的是经过清洗、转换和格式化，可以直接导入机器学习框架进行训练的数据。CSV（逗号分隔值）格式是最通用的表格数据交换格式，可被pandas、scikit-learn、XGBoost等主流工具直接读取。相比API返回的嵌套JSON结构（可能包含数组、字典等复杂层级），CSV将数据"扁平化"为二维表格，每行代表一场对局，每列是一个特征。

将英雄阵容数据转化为模型可接受的数值输入是这类项目的核心技术挑战。最直接的方法是One-Hot编码——为每个英雄创建一个二进制列，如果该英雄出现在蓝色方上单位置则标记为1，否则为0。考虑到LoL目前有超过160个英雄、10个位置槽位（双方各5个），One-Hot编码会产生1600+维的稀疏矩阵。虽然XGBoost等树模型能有效处理稀疏特征，但这种表示丢失了英雄之间的语义关系。更高级的方法包括：（1）实体嵌入（Entity Embedding）：借鉴NLP中词嵌入的思想，将每个英雄映射到低维稠密向量空间，语义相近的英雄（如都是坦克）在向量空间中距离更近；（2）英雄属性特征：用英雄的攻击力、防御力、控制能力等数值属性替代英雄ID，降低维度的同时保留功能信息；（3）图神经网络（GNN）：将阵容建模为图结构，英雄为节点，协同/克制关系为边，通过消息传递捕捉复杂的队伍交互。近年来的前沿研究表明，结合嵌入表示和注意力机制的深度学习模型在阵容胜率预测上已超越传统XGBoost方案，但后者在可解释性和训练效率上仍有优势。对于该项目生成的CSV数据，用户可以根据自己的建模需求灵活选择编码方案。

值得关注的工程设计细节

基于SQLite的断点续传机制

这个项目最能体现工程意识的地方，是它内置了一个 SQLite数据库来追踪采集进度。这意味着你可以随时中断采集任务，之后再从断点处恢复，既不会丢失已有数据，也不会浪费宝贵的Riot API请求配额。

SQLite是一个轻量级的嵌入式关系数据库，无需独立的服务器进程，数据存储在单个文件中，整个引擎以C语言库的形式链接到应用程序。在数据采集场景中，SQLite充当"状态管理器"的角色：记录已采集的对局ID、玩家PUUID、采集时间戳等元数据。这种设计实现了幂等性（idempotency）——即使程序异常终止，重启后可以查询数据库跳过已采集的数据，避免重复请求。相比简单的文本日志或checkpoint文件，SQLite提供了SQL查询能力，可以快速检索"哪些玩家的对局还未采集"、"某个版本已有多少样本"等复杂条件信息。

SQLite的WAL（Write-Ahead Logging）模式特别适合这类"频繁写入、偶尔查询"的场景——它将变更先写入预写日志再同步到主数据库文件，不仅提升了并发写入性能，还增强了崩溃恢复能力，即使在写入过程中断电也不会损坏数据库。此外，SQLite的ACID事务特性保证了数据一致性——要么一场对局的所有相关数据都写入成功，要么全部回滚。与其他状态管理方案相比：Redis虽然读写更快但需要额外部署服务且数据持久化配置复杂；MySQL/PostgreSQL功能强大但部署和配置门槛高；纯文件存储则缺乏查询能力和事务保障。对于需要长时间运行（可能数天甚至数周）的爬虫程序，SQLite这种"零配置、单文件、事务安全"的轻量级持久化方案是最佳平衡点。

对于熟悉API开发的人来说，这个设计非常关键。Riot API有严格的速率限制(rate limit)，采集80万场对局意味着数以百万计的API调用，可能需要连续运行数天。如果没有断点续传机制，任何一次网络中断或程序崩溃都可能让之前的努力付诸东流。这个细节把一个"能跑通的脚本"提升到了"可用于生产的数据采集工具"层面。

80万场对局的数据规模

开发者的目标是采集约 80万场对局。这个量级对于机器学习任务相当可观——足以训练出泛化能力较强的模型，同时也能支撑对不同版本、不同英雄组合的细粒度分析。

要理解80万这个数字的意义，可以从几个维度思考。从特征空间覆盖度来看，LoL有160+英雄，10个位置槽位，理论上的英雄组合数量是天文数字（仅单方5个英雄的组合就超过10亿种）。80万场对局显然无法穷举所有组合，但可以覆盖高频出现的主流阵容组合，为这些组合提供统计显著性。从学习曲线（Learning Curve）角度，机器学习中通过绘制样本量与验证集性能的关系曲线，可以判断模型是否仍能从更多数据中获益——经验表明，XGBoost等树模型在表格数据上通常在几十万到百万样本时达到性能平台期。从历史先例来看，OpenAI Five训练Dota 2 AI时使用了数十亿帧游戏数据，但那是强化学习场景；而在监督学习的胜率预测中，学术论文常用的数据集规模为10万-100万场，例如Kaggle上经典的Dota 2胜率预测竞赛使用了约5万场对局，该项目80万的规模约为其16倍。从细粒度分析的需求看，如果要分析特定英雄对位（如某英雄对某英雄的上单对线胜率），需要足够多的该特定组合出现次数。80万场对局使得即使是中等热门的英雄组合也能积累数百次样本，为置信区间较窄的统计推断提供基础。

数据集的实际应用场景

有了这样一个大规模高分段数据集，可以开展多种有价值的分析和建模工作：

分析Ban/Pick阶段的胜率：量化不同阵容搭配的胜负倾向
研究英雄协同效应(champion synergies)：发现哪些英雄组合具有隐藏的强力配合

协同效应（synergy）是指两个或多个英雄同时出现在一支队伍时，其组合胜率显著高于根据各英雄单独胜率预期的水平。量化协同效应的基础方法是计算条件胜率差：假设英雄A单独出场胜率52%、英雄B单独出场胜率50%，如果两者同队时胜率达到58%，则6%的超额胜率即为协同增益。更严谨的做法是使用贝叶斯估计来处理小样本组合——当某对英雄组合仅出现少量对局时，直接计算的胜率置信度很低，需要引入先验分布（通常以该英雄的整体胜率为先验）进行平滑。进阶方法包括：（1）协同矩阵分解：构建英雄×英雄的协同/克制矩阵，使用SVD（奇异值分解）或NMF（非负矩阵分解）发现潜在的英雄群组关系；（2）关联规则挖掘：借鉴推荐系统中的Apriori或FP-Growth算法，发现频繁共同出场且高胜率的英雄组合；（3）SHAP值交互分析：利用XGBoost模型的SHAP（SHapley Additive exPlanations）交互值，量化任意两个英雄特征对预测结果的联合贡献，从而识别模型隐式学到的协同关系。同理，克制关系（counter）的分析可以通过计算对阵条件胜率来实现——当英雄A出现在己方而英雄B出现在对方时的胜率偏差。

构建选人阶段的胜负预测模型：在英雄选择结束、比赛正式开始之前，预测哪支队伍更可能获胜
电竞BP策略研究：为职业战队的阵容决策提供数据支撑

这类研究不仅对普通玩家的上分策略有参考价值，对电竞BP分析和游戏平衡性研究也有实际意义。值得一提的是，Riot Games自身也在内部使用类似的数据分析方法来指导平衡性调整——他们的设计团队会监控各段位、各地区的英雄胜率和出场率，当某个英雄显著偏离目标值时就会纳入下个版本的调整计划。

对开发者的启示

这个项目虽然聚焦于游戏领域，但它展示了一个优秀数据工程项目的通用范式：明确的数据源（Riot官方API）、聚焦高质量样本（高分段对局）、健壮的采集机制（断点续传）、以及面向下游任务的数据格式（ML-ready CSV）。

这套范式在其他领域同样适用：金融领域的交易数据采集、医疗领域的病历数据集构建、社交媒体的舆情监控，都需要解决相似的工程问题——API速率限制的应对、长期采集的可靠性保障、原始数据到分析就绪格式的转换。该项目可以作为一个轻量级但完整的参考架构，展示如何以最小的技术栈（Python + SQLite + CSV）实现一个生产级的数据采集管线（data pipeline）。

对于想入门数据科学的开发者，这也是一个很好的实践案例——从一个真实的兴趣痛点出发，用工程手段解决"没有现成数据集"的难题，最终产出一个既服务自己、也惠及社区的开源工具。在数据科学领域，有一句广为流传的经验之谈："数据科学家80%的时间花在数据获取和清洗上"——这个项目正是将这80%的工作自动化，让研究者能将精力集中在真正的建模和分析环节。

开发者也在Reddit上主动征求反馈，询问未来还应该在CSV中加入哪些统计字段。感兴趣的读者可以访问其GitHub仓库 mehdbenguiza/lol-dataset-generator 自行体验和贡献代码。