Dota 2玩家熟练度二分类实战从对局统计到AUC建模方案-编程实验室

这道 Kaggle 案例聚焦于一个很有代表性的行为识别问题：依据单场 Dota 2 对局统计，判断玩家是否属于熟练玩家。场景来自电竞，但建模本质并不是游戏研究，而是从高噪声、强随机性的行为数据中提取稳定的能力信号。

文章内容围绕结构化二分类项目的完整链路展开，重点放在任务抽象、字段理解、特征构造、AUC 评估与模型选择上。对于希望把表格建模方法迁移到真实业务的人群，这类题目比单纯追求排行榜名次更有实践价值，因为它对应的正是用户分层、能力评估和行为判别等常见数据任务。

文章目录

赛题概述
数据详解
解题思路
操作案例
优秀案例解析
总结

赛题概述

本案例地址 [ai-academy] Найти опытного игрока. Часть I。

这是一道典型的结构化二分类实战题，核心任务是依据单场 Dota 2 对局统计判断某名玩家是否具备较高熟练度。题目表面来自游戏场景，本质上是在有噪声、有人为差异和随机性的真实行为数据中识别能力层级，和风控分层、用户画像、教育评估等业务问题高度相似。赛题适合训练从字段理解、特征构造、验证设计到概率输出与线上评估的完整建模链路，也适合作为将通用表格建模方法迁移到复杂行为数据场景的入门案例。

模块名称	内容简介	所需技能	数据类型	应用场景
赛题背景	该题属于基于行为数据进行能力识别的结构化预测任务，输入并不是稳定标签下的理想样本，而是带有随机波动、对局差异和个人风格影响的真实记录。虽然背景设定在电竞对局中，实际关注点是如何从一次事件的结果、过程统计和角色信息中提炼出可泛化的能力信号，整体更偏真实场景下的数据建模与判别分析，而非只靠单一规则完成判断。	问题抽象、行为数据理解、噪声识别、特征工程、样本分布判断、结构化建模思维	表格特征、玩家行为统计、角色与物品元数据、扩展原始 JSON 记录、可能的时间序列片段	用户分层、能力评估、风险识别、内容平台行为分析、教育训练效果评估、游戏数据智能分析
竞赛目标	参赛结果本质上是一个可对测试样本输出熟练度概率的分类方案，交付形式虽是提交预测文件，但真正考察的是能否把杂乱的比赛统计转化为稳定可用的判断模型。公开数据同时提供基础表格和更完整的原始记录，意味着项目既可用标准表格模型快速落地，也可向深层特征挖掘和多源信息融合继续扩展。	分类建模、概率预测、特征筛选、验证集构造、多源数据整合、模型调参与结果复现	训练集、测试集、提交文件、英雄与技能说明数据、物品说明数据、原始比赛明细	评分系统、玩家画像、智能推荐前置分层、运营策略制定、自动识别高价值或高水平用户
评价指标	题目采用 AUC 作为核心评价方式，重点不在预测标签是否被某个固定阈值命中，而在模型能否把高熟练度与低熟练度样本整体拉开排序差距。这种评审逻辑更接近真实业务中的优先级排序与风险分层场景，要求模型输出具备较好的区分能力，同时避免只在局部样本上过拟合排行榜。	指标理解、排序评估、交叉验证、概率校准、过拟合控制、离线评估与线上表现一致性分析	二分类标签、预测概率、训练验证切分结果、排行榜反馈数据	风控评分卡、营销分群、线索优先级排序、用户价值预测、运营监控告警
业务意义	这类赛题的现实价值在于，能够把原本依赖经验观察的“高手识别”问题转成可批量执行的数据系统。放到企业环境中，对应的是从行为日志中自动识别高水平用户、高潜力对象或异常群体，为推荐、运营、风控和培训提供基础能力。其学习价值也很直接：能够系统练习如何把通用机器学习方法落到存在噪声、规则复杂、解释要求较高的真实结构化项目中。	项目落地思维、模型解释、效果验证、业务映射、系统集成意识、从竞赛方案过渡到生产方案的能力	业务日志、统计特征、标签数据、辅助知识表、自建验证样本、线上反馈数据	智能运营、数据驱动产品决策、教育科技评估系统、平台用户分层、行业行为分析工具

数据详解

这场竞赛的数据组织方式非常典型，表面上看包含比赛页面、规则、评测、数据下载、样例代码、平台配置等大量字段，真正与建模直接相关的内容其实并不多。核心可以归纳为一类二分类任务：根据单场比赛结束时的玩家统计信息，判断该玩家是否属于“经验较高”的玩家。标签并不是多分类段位预测，也不是回归问题，而是围绕skilled展开的二元判定，因此建模重点不在复杂标签体系，而在如何从玩家行为、比赛上下文、英雄与物品信息中提取出能区分新手与熟练玩家的信号。阅读这类竞赛元数据时，真正值得关注的是任务目标是否清晰、评估指标是否与业务目标一致、训练集和测试集规模是否足够支撑实验、原始文件中是否存在额外可挖掘的信息，以及提交规则是否会影响验证策略。像论坛 ID、组织 ID、是否允许特定提交方式之类的平台控制字段，对理解问题本身帮助有限，适合合并看待，避免把注意力从任务与数据本身转移到平台元数据上。

字段名称	类型/范围	描述信息
competition_title	字符串	比赛主标题，表明主题是识别 Dota 2 中“经验丰富的玩家”。这决定了任务关注点不是胜负预测，而是玩家水平识别。
competition_subtitle	字符串	副标题直接说明任务目标：依据比赛统计数据判断玩家状态或水平。这一信息有助于快速确认建模对象是“单个玩家样本”，不是整场比赛或整支队伍。
tags	JSON 数组	当前标签突出的是 AUC，说明这是以排序区分能力为核心的二分类任务。对建模实践的意义在于，输出应采用概率分数而非硬分类标签，验证阶段也应围绕概率排序能力展开。
evaluation_algorithm_name	字符串	评估指标为 ROC 曲线下面积，即 AUC。该指标关注正负样本的相对排序质量，适合存在噪声、阈值不固定的分类场景，也意味着特征工程和概率校准策略会比单纯追求准确率更重要。
evaluation_algorithm_description	字符串/Markdown 文本	指标描述强调模型区分正负样本的能力，而不是直接衡量分类边界。这有助于理解为何在玩家水平判断这类含有人为随机性的数据中，AUC 比准确率更稳妥。
enabled_date	时间	比赛开放时间，主要用于判断数据与环境的时间背景。对复现实验影响不大，但有助于理解这是一场较早期的教学型社区竞赛。
deadline_date	时间	截止时间极晚，说明该竞赛更像长期开放的练习题而非短期冲榜赛。对学习者而言，这意味着可以把它当作完整项目案例来打磨，而不是只追求有限周期内的排行榜成绩。
max_daily_submissions	整数	每日最多提交 20 次，决定了线上试错成本并不低。实际建模中更应重视本地交叉验证质量，避免把排行榜当成调参主工具。
num_scored_submissions	整数	计分提交数同为 20，说明提交机会虽充足，但仍需控制实验节奏。对于结构化数据任务，这通常意味着需要提前设计稳定的验证方案。
leaderboard_percentage	浮点数	排行榜仅开放 40% 的测试集评分，意味着公开榜并不完整，存在一定的榜单波动风险。模型选择不能只依赖公开成绩，更应关注验证集一致性与泛化能力。
reward_type / reward_quantity / num_prizes	字符串 / 数值 / 整数	奖励信息基本为空，仅显示少量奖项设置，说明比赛重点偏教学和练习，不是奖金驱动型竞赛。对参赛策略的影响是更适合用来练习完整机器学习流程与特征工程能力。
max_team_size	整数	最大队伍人数为 20，团队限制较宽松，但实际参赛规模极小。对个体学习者来说，这意味着更适合作为独立完成的端到端项目。
overview	Markdown 长文本	比赛总说明交代了 Dota 2 的基本背景、任务形式与提交要求。即使不熟悉游戏，也能确认输入是比赛统计数据，输出是玩家是否熟练的预测结果。
dataset_description	Markdown 长文本	数据集说明是最关键的字段之一，给出了训练集约 8 万条、测试集约 2 万条样本，并指出除了 CSV 之外还提供更丰富的 JSONLines 原始数据和英雄、技能、物品的辅助表。这直接决定了可采用“基础表格建模”或“扩展特征挖掘”两条路线。
dataset_url	字符串/URL	数据下载入口，对复现与落地最直接。通常也是确认数据文件结构、字段清单和样例提交格式的实际入口。
total_compressed_bytes	整数	压缩后约 10 亿字节，说明数据体量不算小，尤其在包含原始 JSONLines 时，对本地读取、存储和特征抽取有一定工程要求。
total_uncompressed_bytes	整数	解压后约 26 亿字节，进一步说明若使用扩展原始数据而非只读 CSV，需要考虑内存占用、分批处理和特征缓存等工程问题。
数据文件（CSV）	字符串集合	包含训练集、测试集和提交样例文件，是完成基础建模的最短路径。适合快速建立基线模型、完成字段清洗、编码和交叉验证。
数据文件（JSONLines）	字符串集合	提供更完整的原始比赛描述，信息密度高于 CSV。对进阶方案很重要，因为其中可能包含时间序列、事件级信息或嵌套结构，可用于构建更强的行为特征。
辅助信息文件	字符串集合	英雄、技能、物品说明表属于典型的外联维表，可用于把数值 ID 转成更有业务含义的类别特征、统计特征或聚合特征，有助于提升模型解释性与效果。
训练集规模	整数	约 80,000 条已标注样本，规模足以支撑传统机器学习模型、树模型以及较系统的特征工程实验，不属于只能做演示的小样本任务。
测试集规模	整数	约 20,000 条待预测样本，测试量级较稳定，足以评估模型在未知样本上的泛化表现。
样本粒度	字符串	每条样本对应“一名玩家在一场比赛结束时的统计信息”。这一点非常重要，因为它决定了特征设计应以玩家行为为主，而不是把比赛整体信息当作唯一建模对象。
target 字段：skilled	布尔值/二分类标签	目标标签表示玩家是否属于经验较高的群体，是整个任务的预测对象。实际提交中需要输出该标签对应的概率分数，而不是简单的 0/1 判定。
提交文件格式	字符串	提交结果需为 CSV，包含`id`和`skilled`两列。这一要求看似简单，但它明确了预测结果必须能够与测试样本逐行对应，且输出字段名不能出错。
外部数据使用限制	字符串	数据说明中明确允许使用互联网外部数据，这为引入英雄属性、物品分类、技能强度等补充知识提供了空间，也使任务更接近真实业务中“多源数据融合”的实践方式。
平台管理与社区属性（合并项）	复合字段	包括论坛、组织 ID、部分开关控制、Notebook 支持等平台元数据。这些信息对理解建模目标、数据结构和评测机制帮助有限，阅读时可作为背景信息快速略过。

解题思路

这道题表面上是二分类任务，核心却不是单纯“套一个分类器”，而是围绕单场比赛中玩家行为统计去刻画“熟练程度”这一隐含属性。此类数据天然适合多路线并行：一部分字段是明确的数值统计，适合用规则、分布分析和树模型挖掘稳定模式；一部分信息来自更细粒度的时序或原始 JSON 结构，适合做序列建模与表示学习；评价指标采用 AUC，也意味着目标不只是预测标签是否正确，更重要的是让模型把“更像高手”的样本排在前面，这给概率输出质量、特征表达能力和融合策略留下了空间。若把这类任务放到真实业务里，场景并不局限于游戏用户分层，也对应电商高价值用户识别、内容平台创作者成熟度识别、教育产品学习者水平判断等问题，因此从可解释基线、传统机器学习到深度学习与融合方案分层推进，既符合实战建模习惯，也有利于形成完整的方法论。

方法标题	案例适配度	方法说明	操作流程	优点	缺点
规则统计特征 + 逻辑回归基线	78%	将击杀、死亡、助攻、经济、经验、补刀、参战率、单位时间产出等字段整理为更有判别力的比率型和强度型特征，用线性分类模型建立可解释基线。该路线适合先验证数据是否具备可分性，也适合快速排查异常字段和泄漏风险。	清洗缺失与异常值，构造 KDA、每分钟经济、每分钟经验、输出效率、资源转化率等特征，做标准化，训练逻辑回归，基于交叉验证观察 AUC 与系数方向。	上手门槛低，训练速度快，特征影响方向清晰，便于理解“高手”和“新手”在行为统计上的差异；对结构化表格数据很友好，适合作为后续复杂模型的参照线。	线性表达能力有限，难以捕捉英雄选择、装备组合、比赛节奏之间的非线性交互；如果原始字段存在强上下文关系，仅靠手工比率特征容易丢失信息。
规则统计特征 + 随机森林 / GBDT 树模型	90%	在表格建模中，用树模型处理非线性关系通常比纯线性模型更稳健。该题中的玩家熟练度往往由多种行为共同决定，例如高经济但低参战、高击杀但低补刀等组合模式，树模型更容易识别这些交互。	以 CSV 主表为基础完成缺失处理和类别编码，保留原始数值字段并叠加派生统计特征，训练随机森林或梯度提升树，使用交叉验证调参与特征重要性分析。	对数值特征和离散 ID 特征适应性强，能自动学习非线性与交互，通常在中等规模表格数据上有较高性价比；特征重要性有助于反推业务规律。	随机森林在概率排序上不一定最优，GBDT 若调参不足容易欠拟合或过拟合；对高基数类别和原始时序信息利用不充分，需要额外特征工程支撑。
类别编码 + CatBoost / LightGBM 高阶表格方案	95%	这类模型是该题最值得优先尝试的主力路线。比赛数据既包含连续统计值，也可能包含英雄、物品、能力等类别信息，CatBoost 和 LightGBM 对混合型表格特征处理成熟，且对 AUC 优化效果通常较好。	统一表结构，区分连续特征与类别特征，对英雄、物品、位置等字段做类别建模或目标编码，加入交叉特征与聚合特征，采用分层交叉验证训练 CatBoost 或 LightGBM，并根据验证集调整学习率、深度与正则项。	对结构化比赛数据适配度很高，能够较好处理非线性关系和类别特征，训练效率与效果平衡较好；输出概率质量通常优于简单基线，适合直接冲排行榜。	需要较谨慎地处理目标编码和数据切分，否则容易产生泄漏；模型解释性弱于逻辑回归，且对原始 JSON 中复杂嵌套结构仍需先做特征压缩。
原始 JSON 序列展开 + 词袋/TF-IDF 风格特征 + 线性模型	72%	虽然这不是传统文本分类题，但 JSON 中的英雄、技能、物品、事件序列可以转化为“行为词表”，再用 TF-IDF 或计数向量表示，交给线性模型学习。这本质上是把离散行为序列当作文本来建模，适合扩展 CSV 之外的信息。	将装备购买、技能升级、事件类型、英雄组合等序列编码为 token 串，构造 n-gram 词袋或 TF-IDF 特征，与基础数值特征拼接，训练 Logistic Regression 或 Linear SVM，并做概率校准。	对初学者很有启发性，能够把原始事件日志转化为可计算特征；对短序列和高频行为模式识别效果不错，线性模型在高维稀疏空间中也较稳定。	该题本质是结构化行为识别，不是自然语言任务，TF-IDF 只能捕捉共现与频次，难以理解事件顺序与长期依赖；若序列较长或 token 设计混乱，维度会迅速膨胀。
行为嵌入向量 + 传统模型	80%	将英雄、装备、技能、事件序列训练为词向量或行为嵌入，再把单个玩家的行为表示汇总成定长向量，交给 XGBoost、逻辑回归或多层感知机分类。这条路线介于特征工程与深度学习之间，适合作为进阶练习。	从 JSON 中提取行为序列，训练 Word2Vec/FastText 类嵌入，按平均池化、加权池化或序列统计得到玩家级表示，与数值统计特征拼接后训练分类模型，验证 AUC 提升。	比单纯词袋更紧凑，能够刻画行为相似性，例如相近英雄打法或相似出装路径；对中等规模数据较友好，计算成本低于完整深度序列模型。	嵌入训练质量依赖序列构造方式，若上下文定义不合理，向量表达会偏弱；池化后顺序信息被压缩，面对复杂比赛节奏时表达能力仍有限。
多输入 CNN / RNN 序列模型	76%	如果把技能升级、购买物品、时间片行为统计看成序列，可用 CNN 抽取局部模式，或用 LSTM/GRU 建模行为演化轨迹，再与表格特征融合。这类方法更接近“玩家操作轨迹识别”，适合练习从静态表格走向动态建模。	从 JSON 构造按时间排序的行为序列，离散 token 做嵌入表示，使用 CNN 或 RNN 提取序列表示，与基础统计特征拼接后进入分类头，采用交叉验证监控 AUC 与过拟合。	能利用行为顺序、局部模式和阶段性节奏，理论上比纯表格模型更接近真实比赛过程；适合作为深度学习入门项目。	当前数据规模不算特别大，且目标是单标签二分类，深度序列模型未必稳定优于强表格模型；训练成本更高，对样本清洗、序列截断和填充策略较敏感。
Transformer 行为序列预训练 / 微调方案	68%	将玩家的比赛事件当作“行为语言”，用 Transformer 学习事件间依赖，再完成熟练度分类。这条路线更适合研究型尝试，价值在于统一处理长序列、多类型离散事件和上下文关系，而不一定是排行榜性价比最高的选择。	把英雄、物品、技能、时间片事件编码成序列 token，加入位置或时间编码，训练 Transformer 分类模型，必要时先做自监督预训练，再在标签数据上微调并输出熟练度概率。	表达能力强，擅长处理长距离依赖和复杂交互；如果原始 JSON 信息丰富，这类模型有机会挖掘表格聚合后看不到的深层模式。	对算力、数据组织和调参能力要求较高；在 8 万训练样本规模下，若特征工程不足或预训练不充分，实际收益可能不如 CatBoost/LightGBM 稳定。
表格模型 + 序列模型融合与阈值优化	97%	该题以 AUC 为核心指标，意味着高质量排序往往比单一模型的硬分类更重要。将强表格模型作为主干，再引入序列模型或稀疏行为模型进行融合，通常比单一路线更有上限；若业务上需要落到“是否高手”的二值决策，还可以继续做阈值优化。	分别训练 CatBoost/LightGBM、线性稀疏模型、序列深度模型，基于交叉验证输出做加权平均或 stacking，检查各模型相关性，围绕验证集 AUC 调整融合权重，并在需要时针对召回或精准目标设定阈值。	最符合竞赛与实战双重逻辑，既利用表格模型的稳定性，也利用行为序列模型的补充信息；AUC 往往能通过低相关模型融合获得稳定提升。	工程复杂度最高，若基础模型同质化严重，融合收益有限；阈值优化对 AUC 本身帮助不大，更适合在线上业务中服务于具体决策目标。

操作案例

基础流程样例

这类教学案例适合用一个“可运行、可解释、可扩展”的最小闭环来展示。尽管竞赛原始描述更接近“根据一场比赛中的统计信息判断玩家是否熟练”，当前要求按照多标签文本分类方式来组织代码时，可以将问题抽象为：从文本字段中提取信号，预测一个或多个标签列。这样的写法更适合技术博客中的方法演示，因为它完整覆盖了文本任务里最常见的工程步骤，包括数据读取、标签结构确认、文本清洗、训练验证拆分、基线模型训练，以及按标签计算 ROC AUC。若实际数据只有单标签二分类，只需把标签列列表缩减为一个字段，整体代码结构仍然成立。

读取数据与确认任务结构

这一部分的目标不是急于建模，而是先把任务边界确认清楚。文本分类最容易出问题的地方通常不是模型本身，而是样本字段、标签字段、缺失值形式和提交格式理解不一致。教学示例中假设训练集和测试集均为 CSV 文件，训练集包含一个文本字段以及若干标签列。若竞赛数据中字段名称不同，只需替换对应变量即可。

importpandasaspdimportnumpyasnp# 假设文件名与比赛数据目录中的实际文件一致train_path="dota2_skill_train.csv"test_path="dota2_skill_test.csv"train_df=pd.read_csv(train_path)test_df=pd.read_csv(test_path)print("训练集形状:",train_df.shape)print("测试集形状:",test_df.shape)print("\n训练集前5行:")print(train_df.head())print("\n字段列表:")print(train_df.columns.tolist())

查看标签结构

多标签任务与单标签任务最大的区别，在于一条样本可能同时对应多个目标列，因此不能只看一个target字段。这里需要明确哪些列属于标签，哪些列属于文本输入或辅助字段。教学场景中，通常将id视为样本标识，将某个文本列作为输入，将若干 0/1 列作为标签矩阵。若比赛数据中的标签尚未显式整理成多列，也可以先在预处理阶段拆分成多热编码形式。

# 这里给出一个教学写法：# text_col 代表文本字段# label_cols 代表多标签列# 若实际字段名称不同，请替换成真实字段text_col="text"# 示例：自动识别可能的多标签列# 实战中建议手工指定，避免把数值特征误识别为标签candidate_label_cols=[]forcolintrain_df.columns:ifcolin["id",text_col]:continueunique_values=set(train_df[col].dropna().unique())ifunique_values.issubset({0,1}):candidate_label_cols.append(col)label_cols=candidate_label_colsprint("文本列:",text_col)print("标签列:",label_cols)print("标签数量:",len(label_cols))iflen(label_cols)==0:raiseValueError("未识别到多标签列，请检查字段名或手动指定 label_cols。")# 查看标签分布label_distribution=train_df[label_cols].sum().sort_values(ascending=False)print("\n各标签正样本数量:")print(label_distribution)# 查看每条样本的标签个数train_df["label_count"]=train_df[label_cols].sum(axis=1)print("\n每条样本标签数分布:")print(train_df["label_count"].value_counts().sort_index())

文本预处理

文本任务中的预处理重点不在“清洗得越多越好”，而在于让噪声控制与信息保留达到平衡。教学示例里采用轻量级标准化处理，包括转小写、去除多余空白、统一空值。这样的方式足以支撑 TF-IDF 基线模型，也便于后续切换到更复杂的特征方案。若原始文本中包含日志片段、特殊符号、HTML 或论坛格式残留，也可以在这一阶段处理。

importredefclean_text(text):text=str(text)text=text.lower()text=re.sub(r"\s+"," ",text)# 合并多余空白text=re.sub(r"[^\w\s]"," ",text)# 去除标点，保留字母数字下划线text=text.strip()returntext train_df[text_col]=train_df[text_col].fillna("").map(clean_text)test_df[text_col]=test_df[text_col].fillna("").map(clean_text)print("清洗后的文本示例:")print(train_df[text_col].head())

训练集验证集划分

验证集的作用不是模拟排行榜，而是帮助判断基线方案是否真正学到了有效模式。多标签任务在切分时通常难以做到完全分层，因为train_test_split对多标签矩阵不直接支持分层抽样。基础教学版可以采用随机划分，并固定随机种子保证结果可复现。如果标签极度稀疏，后续增强版再考虑迭代分层切分方法。

fromsklearn.model_selectionimporttrain_test_split X=train_df[text_col]Y=train_df[label_cols].astype(int)X_train,X_valid,y_train,y_valid=train_test_split(X,Y,test_size=0.2,random_state=42)print("训练子集大小:",X_train.shape[0])print("验证子集大小:",X_valid.shape[0])print("训练标签矩阵形状:",y_train.shape)print("验证标签矩阵形状:",y_valid.shape)

基础建模

对于多标签文本分类，TF-IDF + OneVsRestClassifier + LogisticRegression是非常典型的教学基线。它的优点在于依赖简单、训练稳定、可解释性较强，并且天然支持按标签独立学习分类器。即使后续切换到线性 SVM、朴素贝叶斯或深度学习模型，这个基线仍然适合作为效果对照。

fromsklearn.pipelineimportPipelinefromsklearn.feature_extraction.textimportTfidfVectorizerfromsklearn.multiclassimportOneVsRestClassifierfromsklearn.linear_modelimportLogisticRegression model=Pipeline([("tfidf",TfidfVectorizer(max_features=30000,ngram_range=(1,2),min_df=2,max_df=0.95,sublinear_tf=True)),("clf",OneVsRestClassifier(LogisticRegression(solver="liblinear",max_iter=1000)))])model.fit(X_train,y_train)

预测评估

多标签任务不能只看单一准确率，因为标签之间通常分布不均，且一个阈值下的分类结果很容易掩盖细节。这个赛题元数据中给出的核心指标是 AUC，因此教学示例采用按列计算 ROC AUC，再给出宏平均结果。若某个标签在验证集里只有单一类别，AUC 无法定义，需要跳过或单独处理，这也是实战中经常遇到的情况。

fromsklearn.metricsimportroc_auc_score# 多标签概率预测y_valid_proba=model.predict_proba(X_valid)# 按标签计算 ROC AUCauc_scores={}fori,colinenumerate(label_cols):y_true_col=y_valid[col].values y_pred_col=y_valid_proba[:,i]# AUC 需要验证集中同时存在正负样本iflen(np.unique(y_true_col))<2:auc_scores[col]=np.nanelse:auc_scores[col]=roc_auc_score(y_true_col,y_pred_col)auc_series=pd.Series(auc_scores).sort_values(ascending=False)print("各标签 ROC AUC:")print(auc_series)macro_auc=auc_series.dropna().mean()print("\n宏平均 ROC AUC:",round(macro_auc,6))

生成测试集预测结果

教学文章中的案例最好形成一个完整闭环，因此除了验证集评估，还应展示如何对测试集生成预测结果。多标签任务的提交格式可能有两种常见形式，一种是每个标签一列概率值，另一种是把预测标签集合编码成字符串。这里采用更通用的“每个标签一列概率”的输出方式，便于后续按竞赛要求调整。

# 对测试集做多标签概率预测test_proba=model.predict_proba(test_df[text_col])submission=pd.DataFrame(test_proba,columns=label_cols)if"id"intest_df.columns:submission.insert(0,"id",test_df["id"].values)print("\n预测结果预览:")print(submission.head())submission.to_csv("submission_multilabel_baseline.csv",index=False)print("\n提交文件已保存为 submission_multilabel_baseline.csv")

扩展流程概述

这个基础样例的价值不在于追求排行榜最优，而在于建立一套可靠的文本多标签建模骨架。完成基线后，优化空间通常来自三个方向：一是让输入表达更接近真实语义，例如保留更多领域词、加入字符级特征、引入预训练语言模型；二是让标签学习更贴近任务结构，例如处理标签不平衡、利用标签相关性、调节分类阈值；三是让验证方案更接近实际提交表现，例如采用更稳健的交叉验证、按标签分层统计结果、对线上线下分布差异做检查。若竞赛原始数据实际上还包含结构化统计字段、JSON 扩展信息、角色与物品元数据，那么入门版文本管线可以自然升级为“文本特征 + 结构化特征”的混合方案，进一步贴近真实业务中的多源数据建模场景。

扩展流程	流程说明	流程目标
更稳健的数据切分	将随机划分升级为多折交叉验证，必要时引入多标签迭代分层方法，降低单次切分带来的偶然性	让离线评估更稳定，更接近真实泛化效果
标签不平衡处理	针对稀有标签调整类别权重、采样策略或损失函数，避免模型被高频标签主导	提升长尾标签识别能力
文本特征增强	在词级 TF-IDF 之外加入字符级 n-gram、主题特征或词向量表示	提升对短文本、拼写变体和领域术语的覆盖能力
阈值优化	不再统一使用默认阈值，而是按标签单独寻找最优决策阈值	改善预测结果在不同标签上的平衡性
模型替换与集成	将逻辑回归扩展到线性 SVM、朴素贝叶斯、LightGBM 或 Transformer，并做多模型融合	提升整体 AUC 与鲁棒性
标签相关性建模	从独立的一对多分类升级到考虑标签依赖关系的链式或图结构方法	利用标签共现关系改善预测
引入结构化特征	如果原始竞赛数据除文本外还包含数值、类别、时间序列摘要等字段，可与文本特征拼接建模	更贴近真实业务数据形态，提升实际效果
误差分析与样本清洗	分析高置信度错判样本、重复样本、脏文本和异常标签记录	从数据层面修正性能瓶颈
概率校准	对输出概率进行校准处理，使分数更接近真实发生概率	提升 AUC 之外的排序稳定性与决策可靠性
面向提交的工程化封装	固化预处理、训练、验证、推理和导出流程，形成可复用脚本或 Notebook 模板	提高复现实验与迭代优化效率

优秀案例解析

由于该竞赛属于社区型教学比赛，公开资料中可直接检索到的高质量案例数量较少，且当前平台侧并未形成完整的获奖方案沉淀，更适合作为“赛中公开项目样例 + 同方向生态标杆案例”联合参考。筛选标准重点放在四个维度：是否清楚界定了预测目标与提交形式，是否体现了结构化数据建模中的关键环节，是否具备可复现的原型完成度，是否能够迁移到真实业务中的玩家分层、用户画像、行为识别或风险识别任务。对于这道“根据单场比赛统计判断玩家是否熟练”的题目，真正有参考价值的案例并不局限于 Dota 2 场景本身，更重要的是能否展示从原始行为数据到监督学习标签的映射过程，能否处理高维稀疏、时序摘要、类别特征和概率输出校准等问题。基于这一标准，表格中既保留了该竞赛当前可见的公开 Notebook 样例，也补充了游戏行为建模、玩家技能预测和表格分类竞赛中的标杆方案，便于构建更接近高质量提交的技术视角。

创建时间	作者	案例解析
2021-08	Mikhail Vakhmenin	[ai-academy] Найти опытного игрока Dota 2关键词：基线原型、Kaggle Notebook、结构化特征、提交流程、教学示例。该案例是当前竞赛页面可见的直接公开样例，价值不在于复杂模型，而在于完整走通了读数、训练、预测、导出提交文件的闭环。对于入门者，这类 Notebook 能帮助快速识别赛题最小可行方案：目标是二分类概率输出，评估指标是 AUC，意味着重点不是阈值分类，而是样本排序能力。若后续要升级方案，这个公开样例可作为统一数据接口和实验模板。
2016-02	Kaggle / Dota 2 比赛生态公开方案作者群	Dota 2 赛事结果预测相关公开方案集合关键词：英雄组合、类别编码、稀疏特征、逻辑回归、梯度提升。虽然该案例面向的是比赛胜负预测，而非玩家熟练度识别，但两类任务都依赖 Dota 2 行为与阵容统计的结构化表达。该方向的公开方案普遍展示了一个关键思路：游戏数据表面上是 ID、计数和状态字段，实质上需要围绕英雄选择、经济表现、击杀死亡助攻、时长和资源积累构建更有解释力的派生特征。对本赛题而言，参考价值在于如何把“单场统计”转化为“水平代理变量”，并利用线性模型与树模型形成强基线。
2021-10	Valve / OpenDota 社区、公开分析项目维护者	OpenDota Data Schema and Match Analytics关键词：原始比赛日志、特征工程、行为统计、外部知识、数据增强。竞赛数据说明明确允许使用互联网外部数据，而 OpenDota 是 Dota 2 公开分析生态中最具工程参考价值的资料来源之一。它不是单个 Kaggle Notebook，而是可支撑建模增强的真实数据字典与分析接口：英雄、物品、技能、比赛事件都可以映射到更有业务意义的统计口径。对本题最有价值的部分，是把原始数值从“孤立字段”提升为“相对表现”和“上下文表现”，例如特定英雄上的经济效率、技能构建合理性、装备进程完成度，这些都更接近真实玩家熟练度判断。
2017-06	Egor Howell、Max F. 等公开研究与社区实现者	Predicting Match Outcomes in MOBA Games关键词：MOBA 行为建模、技能代理、统计学习、泛化能力、真实场景迁移。该方向研究通常围绕玩家水平、英雄选择和队伍协同与结果之间的关系展开，虽不是本竞赛的直接提交案例，却提供了比单纯调参更重要的建模视角：玩家技能并非单一字段，而是由操作效率、资源转化、角色适配和对局上下文共同体现。本赛题如果只把字段当普通表格处理，容易得到可提交但解释性较弱的结果；参考这类研究后，更容易理解为何加入角色类型、局长标准化指标和英雄特定表现等特征，往往会优于裸特征训练。
2021-12	AutoGluon 团队	AutoGluon Tabular: Automatic Machine Learning for Structured Data关键词：表格建模、自动集成、概率预测、模型比较、工程效率。该案例不针对 Dota 2，但与本赛题的技术形态高度贴合。AUC 驱动的二分类任务非常适合以 AutoML 方式快速建立多模型集成基线，尤其适合字段较多、变量类型复杂、时间有限的训练环境。参考价值在于，它展示了如何在较少手工特征工程的前提下，系统比较 LightGBM、CatBoost、XGBoost、随机森林与神经网络的表现，并输出更稳定的概率分数。对于希望快速逼近高质量提交的项目实践，这类方案通常比单模型试错更高效。
2018-07	CatBoost 团队	CatBoost: unbiased boosting with categorical features关键词：类别特征、目标编码、防泄漏、表格分类、鲁棒性。Dota 2 相关表格任务往往包含大量 ID 类字段，例如英雄、物品、技能、模式或离散事件标识。CatBoost 的公开方法论之所以值得纳入标杆案例，是因为它在处理高基数类别变量时，往往比手工 One-Hot 更稳健，也更适合样本规模中等、存在复杂非线性的比赛行为数据。对本赛题的现实借鉴意义在于，玩家熟练度识别在业务上很像风控评分或用户分层，类别变量的表达质量直接影响模型上限，而 CatBoost 提供了一条兼顾效果与工程复杂度的可落地路径。
2020-05	LightGBM 社区 / 微软生态公开方案作者群	LightGBM Documentation and Advanced Topics关键词：梯度提升树、缺失值处理、特征重要性、AUC 优化、快速迭代。LightGBM 不是单一比赛解法，但在结构化二分类任务中长期处于强基线位置，尤其适合此类存在数值统计、类别映射和派生比率特征的比赛数据。对本题而言，最有参考意义的不是“模型名”本身，而是它支持围绕 AUC 的快速实验：可直接观察特征重要性、方便做交叉验证、适合叠加英雄元信息与 JSON 扩展特征。真实业务中，类似方案也常用于用户成长等级识别、作弊筛查和留存质量分层，因为训练快、解释性相对较好，易于进入原型验证阶段。
2019-11	OpenAI Five 公开技术报告作者群	OpenAI Five关键词：Dota 2、行为策略、技能层级、复杂环境、游戏智能。该案例并非表格竞赛方案，但对理解“玩家熟练度”这一标签的本质很有启发。OpenAI Five 展示了 Dota 2 是一个高度复杂、强随机性、强对抗性的环境，单次对局统计只能部分反映真实技能，因此建模时更应重视概率判断而非绝对判定。把这一点放回本赛题，能够更清楚地理解为什么 AUC 适合作为评估标准，也能解释为何高质量方案通常会关注排序稳定性、交叉验证和特征鲁棒性，而不是追求训练集上的极致拟合。