Project Updates
TI 2026 Dota 2 数据分析复盘：模型做对了什么，又错在了哪里
从 1,054 张地图、严格的数据泄漏控制，到五局总决赛的公开复盘。
2026-08-23
先说结果
Team Spirit 在 TI 2026 总决赛中以 3–2 击败 Team Vision。这个项目没有获得公开高置信度赛前胜率的资格：v3 模型没有超过 Elo 基线，post-draft 模型没有带来可验证的增量价值，校准门禁也没有通过。
所以，这篇文章不是“预测成功”的庆功稿，而是一份更有价值的工程复盘：数据治理有效，战略英雄池判断有一定价值，精确 BP 动作较弱，而模型在证据不足时继续保持 research-only。
经过脱敏的代码、方法、聚合证据和自动化门禁已经整理到 TI 2026 Dota 2 Analytics GitHub 仓库。
研究时间窗与数据边界
项目注册的研究时间窗是 2026 年 4 月 7 日至 8 月 14 日，最后的总决赛系列赛只用于赛后评估。受控研究数据包括：
- 目标集合中的 1,054 张职业比赛地图；
- 其中 147 张 TI 地图；
- 私有质量流水线中的 10,540 条选手覆盖核验记录；
- 1,051 张完整 BP 地图，以及 3 张因历史 BP 缺失而被隔离的地图；
- frozen-v1 阶段 966 张地图，live-v2 留出集 88 张地图。
OpenDota 提供比赛元数据和比赛详情中的 BP 动作；TI 官方页面用于确认赛程和结果；Liquipedia 只用于人工交叉核验，没有复制其表格、正文、图片或 Logo。
公开仓库有意排除了原始与整理后数据、玩家标识、模型二进制、私有 Prompt、AI 原始回复、单场胜率、冠军概率、战队排名和本地路径。
建模之前，先保证数据可信
每张候选地图都必须通过数据契约，包括比赛 ID、UTC 开始时间、战队身份、胜方阵营、十名选手覆盖、BP 动作顺序、来源一致性和稳定输入哈希。
最终质量审计结果为：
- 重复比赛 ID：0；
- 选手覆盖失败：0；
- 未解决来源冲突：0；
- 未来时间记录：0；
- 哈希不一致：0；
- 6 个历史时长异常值经过人工检查，而不是被静默删除。
关键经验是：行数看起来干净并不等于数据真的可用。阵容变更、临时替补、版本边界、API 延迟更新和历史 BP 缺失，全部都是带时间语义的数据问题。
防止最容易得到的“高准确率”
项目禁止随机切分训练集和测试集。只有当特征的生效时间不晚于预测时间时，才允许连接到样本。预处理、特征选择、拟合和校准都只能使用过去的数据折。
目标地图的结果、时长、最终系列比分、赛事名次和当局 BP 都不得进入赛前特征。post-draft 模型是独立任务：它可以看到已经完成的 BP，但仍然不能看到比赛结果。
这也是红队最重要的职责。电竞模型很容易通过未来战队排名、最新阵容快照、版本标签或赛后聚合数据“获得”漂亮成绩。这里的规则是：无法解释时间边界的数据连接必须失败关闭，不能被当成方便的特征。
Elo 战胜了更复杂的候选模型
88 张地图的 live-v2 留出集产生了以下聚合结果：
- Elo：log loss 0.6773、Brier 0.2419、accuracy 0.6023、ROC-AUC 0.6047、expected calibration error 0.0647；
- v3 赛前模型：log loss 0.6830、Brier 0.2448、ROC-AUC 0.5845；
- post-draft 模型：log loss 0.7103、Brier 0.2583、ROC-AUC 0.4997。
log loss 和 Brier 越低越好，ROC-AUC 越高越好。v3 没有超过 Elo，post-draft 更差，也没有表现出增量价值；校准结果同样没有达到门槛。
正确做法不是换一个更有利的指标，也不是只展示最终猜中的部分。三项失败都被保留下来，发布状态继续是 research_only。
BP 复盘到底说明了什么
解释 BP 结果之前，必须先明确统计粒度。我检查了 4 个焦点英雄在 5 张地图中的出现情况，总共构成 20 个“英雄 × 地图”机会：
- Treant Protector：5/5；
- Earth Spirit：5/5；
- Keeper of the Light：4/5；
- Lone Druid：2/5。
合计是 16/20 的焦点英雄池覆盖，即 80% 的战略池重叠度。它不是“BP 预测准确率 80%”。
精确动作的表现明显更弱：
- Team Vision 首阶段禁用：18 个预测动作命中 3 个，覆盖 3 张地图；
- Team Spirit 首阶段禁用：17 个预测动作命中 4 个，覆盖 2 张地图；
- 双方首选英雄都只命中 1/5。
项目识别出了有战略意义的英雄组，但没有可靠地把精确禁用、首选和顺序分配给各支战队。“英雄池级别的赛前关注”与“动作级 BP 预测”是两个问题，把它们合并成一个准确率会掩盖失败。
四个分析席位与一个发布决定
我在 Codex 担任 AI Chief 的框架下设置了四个 DeepSeek 分析席位：
- 数据分析师检查比赛 ID、阵容变更、重复、来源冲突和异常值；
- 版本/BP 分析师跟踪英雄优先级、阵容克制和版本漂移；
- 战队分析师审查阵容连续性、近期状态、英雄池和对手强度；
- 红队审核员挑战数据泄漏、过度自信、模型漂移和分析矛盾。
Codex 负责提供数据、审核需求与结论，并把发布决策交给我这个所有者。公开证据是结构化、可独立核查的结果，而不是模型服务商的私有推理或原始会议记录。
六项门禁阻止了不合理发布
发布流程检查六项控制：数据质量、时间完整性、相对 Elo 的价值、校准、post-draft 增量价值，以及所有者明确授权。
数据质量与时间完整性通过；基线、校准和 BP 增量价值没有通过。所有者批准的是这份透明复盘，而不是把失败模型包装成可以发布的胜率产品。
下一轮我会怎么改
- 在赛事开始前注册英雄、阶段、动作、顺序和战队等不同粒度的 BP 指标；
- 扩大版本内样本，并直接建模版本切换的不确定性；
- 按生效时间管理阵容和替补，而不是使用最新快照；
- 使用嵌套时间验证完成特征选择和校准；
- 让 BP 模型与简单的战队频率基线、版本优先级基线比较；
- 将冻结的赛前预测产物与赛后评估严格分开。
这个项目不是投注建议。它真正有用的输出，是一套知道什么时候不应该发布数字的透明流程。