电竞赛后文本看似只有一句话却常常是复盘系统里最有价值的信息入口。例如JDG 20 WEmonki状态持续低迷we逆天bp三线0控制 cube10楼蒙多被狂抽陀螺红q辛德拉毁天灭地这句话就包括了比赛双方、2 比 0 比分、胜方判断、选手 ID、BP 吐槽、控制链缺失、选手状态等好几类信息。如果靠人工把每条评论复制到 Excel不仅慢而且很难统一口径如果能把文本里的关键信息自动抽取成结构化 JSON后续做选手状态看板、BP 胜率统计、赛后文案辅助生成就都有了数据基础。这篇文章要做的不是讨论某一场比赛谁对谁错而是把这类赛后短讯当成一个可复现的数据样例搭建一条最小可用的中文电竞文本信息抽取管线。读者可以跟着文章完成词表配置、实体抽取、比分解析、标签识别和结果验证最终输入一段赛评或赛后文案输出一份带队伍、选手、英雄、比分、胜方和观测标签的 JSON 数据。这条管线适合赛事数据运营、电竞内容平台和想入门中文 NLP 信息抽取的开发者。1. 先回答为什么一条赛后评论需要结构化1.1 从一句评论到复盘数据缺的不是人工而是字段模型原始文本是人类语言数据分析系统无法直接按“战队过滤”或“按英雄聚合”。如果你想统计京东 JDG 在最近 30 场里选用蒙多的场景不能靠人工去搜“蒙多”两个字因为同样一个字可能出现在“蒙多被狂抽陀螺”里也可能出现在“蒙多防住了越塔”里。只有把句子里的战队、选手、英雄、行为、评价拆成独立字段后续查询才能执行。把JDG 20 WEmonki状态持续低迷we逆天bp三线0控制 cube10楼蒙多被狂抽陀螺红q辛德拉毁天灭地这句话做人工拆解可以得到下面这些信息对战双方是 JDG 和 WE。比分是 2 比 0。根据比分可以推断 JDG 是胜方。文本里出现了选手monki描述是“状态持续低迷”。文本里出现了 BP 决策评论“逆天 bp”。文本里出现了cube10楼蒙多说明cube选了蒙多且评论认为效果不好。文本里提到了另一个英雄辛德拉后面跟着“毁天灭地”。这些字段原本放在一句话里只能靠人眼阅读按字段拆开后运营人员可以快速筛选“今天哪些选手被标记为状态低迷”也可以把“逆天 bp”和“0 控制”这类负向标签归入 BP 风险清单。1.2 抽取任务的边界哪些必须做哪些只做提示信息抽取不是让程序理解整段话而是让程序先完成可验证的子任务。早期版本不需要做复杂的因果推断只要做好四类抽取任务说明典型输出机构实体识别识别战队名并归一化到官方名称JDG - JDG人物实体识别识别选手 IDmonki游戏实体识别识别英雄名蒙多,辛德拉比分事件抽取解析两队的整数比分JDG 2:0 WE主观标签识别抽取状态、BP 评价、高光表现低迷,逆天bp,毁天灭地看到“被狂抽陀螺”这样的词程序不需要真正理解线上被打崩的全过程只需要把这句话标记为performance_low证据同时保留原文片段让后续人工或模型做二次判断。这样的设计既降低抽取难度也保证结果可以追溯到原始出处。1.3 为什么输出里必须保留原文出处生产环境做数据清洗时最怕的是把一句话里的信息抽错了却没有办法查回原文。所以结构化的实体不能只存一个“名字”还要保存这段实体在句子里的起止位置和原始写法。比如WE和we可能是同一支队伍也可能只是第一人称代词“我们”。保留原始片段和位置后团队可以单独开发一份“待复核列表”让标注人员或运营人员确认。2. 设计字段模型和实体词表是规则抽取成功的一半2.1 用 JSON Schema 先定输出再写抽取逻辑很多开发者在写抽取代码时习惯先写一堆if WE in text再顺手输出一个 dict。这样写出来的代码在单条文本上能跑但换一批文本后字段经常对不上。更稳妥的做法是先定义输出结构再倒推需要哪些规则。一份最简输出可以设计成这样{ input: 原始赛评文本, score: { team_a: JDG, score_a: 2, team_b: WE, score_b: 0 }, winner: JDG, entities: [ { entity: JDG, type: teams, start: 0, end: 3, raw: JDG } ], pick_events: [ { player: cube, round: 10, champion: 蒙多 } ], observations: [ { type: performance_low, keyword: 低迷 } ] }字段设计有几个原则score里的战队名建议使用官方名称不要在 JSON 里出现“京东”“we”混用。entities里的raw保留文本原始写法方便和原始内容对齐。pick_events用来记录“第几楼选了哪个英雄”这是 BP 分析的重要输入。observations只记录打标结果不负责解释为什么这个标签成立。2.2 把词表拆到 YAML不要把字典埋在代码里电竞实体变化很快。一个选手会转会一个战队会改名新英雄会上线老英雄外号会流行。如果把词表写在 Python 代码里运营同学改一个选手 ID 就要提代码变更后续维护成本很高。推荐的做法是把词表抽成 YAML代码只做加载和匹配。示例configs/entities.yamlteams: - name: JDG aliases: - jdg - 京东 - name: WE aliases: - we players: - name: monki aliases: - monki - name: cube aliases: - cube champions: - name: 蒙多 aliases: - 蒙多 - 蒙多医生 - mundo - name: 从一句赛评到结构化JSON：中文电竞文本信息抽取管线
电竞赛后文本看似只有一句话却常常是复盘系统里最有价值的信息入口。例如JDG 20 WEmonki状态持续低迷we逆天bp三线0控制 cube10楼蒙多被狂抽陀螺红q辛德拉毁天灭地这句话就包括了比赛双方、2 比 0 比分、胜方判断、选手 ID、BP 吐槽、控制链缺失、选手状态等好几类信息。如果靠人工把每条评论复制到 Excel不仅慢而且很难统一口径如果能把文本里的关键信息自动抽取成结构化 JSON后续做选手状态看板、BP 胜率统计、赛后文案辅助生成就都有了数据基础。这篇文章要做的不是讨论某一场比赛谁对谁错而是把这类赛后短讯当成一个可复现的数据样例搭建一条最小可用的中文电竞文本信息抽取管线。读者可以跟着文章完成词表配置、实体抽取、比分解析、标签识别和结果验证最终输入一段赛评或赛后文案输出一份带队伍、选手、英雄、比分、胜方和观测标签的 JSON 数据。这条管线适合赛事数据运营、电竞内容平台和想入门中文 NLP 信息抽取的开发者。1. 先回答为什么一条赛后评论需要结构化1.1 从一句评论到复盘数据缺的不是人工而是字段模型原始文本是人类语言数据分析系统无法直接按“战队过滤”或“按英雄聚合”。如果你想统计京东 JDG 在最近 30 场里选用蒙多的场景不能靠人工去搜“蒙多”两个字因为同样一个字可能出现在“蒙多被狂抽陀螺”里也可能出现在“蒙多防住了越塔”里。只有把句子里的战队、选手、英雄、行为、评价拆成独立字段后续查询才能执行。把JDG 20 WEmonki状态持续低迷we逆天bp三线0控制 cube10楼蒙多被狂抽陀螺红q辛德拉毁天灭地这句话做人工拆解可以得到下面这些信息对战双方是 JDG 和 WE。比分是 2 比 0。根据比分可以推断 JDG 是胜方。文本里出现了选手monki描述是“状态持续低迷”。文本里出现了 BP 决策评论“逆天 bp”。文本里出现了cube10楼蒙多说明cube选了蒙多且评论认为效果不好。文本里提到了另一个英雄辛德拉后面跟着“毁天灭地”。这些字段原本放在一句话里只能靠人眼阅读按字段拆开后运营人员可以快速筛选“今天哪些选手被标记为状态低迷”也可以把“逆天 bp”和“0 控制”这类负向标签归入 BP 风险清单。1.2 抽取任务的边界哪些必须做哪些只做提示信息抽取不是让程序理解整段话而是让程序先完成可验证的子任务。早期版本不需要做复杂的因果推断只要做好四类抽取任务说明典型输出机构实体识别识别战队名并归一化到官方名称JDG - JDG人物实体识别识别选手 IDmonki游戏实体识别识别英雄名蒙多,辛德拉比分事件抽取解析两队的整数比分JDG 2:0 WE主观标签识别抽取状态、BP 评价、高光表现低迷,逆天bp,毁天灭地看到“被狂抽陀螺”这样的词程序不需要真正理解线上被打崩的全过程只需要把这句话标记为performance_low证据同时保留原文片段让后续人工或模型做二次判断。这样的设计既降低抽取难度也保证结果可以追溯到原始出处。1.3 为什么输出里必须保留原文出处生产环境做数据清洗时最怕的是把一句话里的信息抽错了却没有办法查回原文。所以结构化的实体不能只存一个“名字”还要保存这段实体在句子里的起止位置和原始写法。比如WE和we可能是同一支队伍也可能只是第一人称代词“我们”。保留原始片段和位置后团队可以单独开发一份“待复核列表”让标注人员或运营人员确认。2. 设计字段模型和实体词表是规则抽取成功的一半2.1 用 JSON Schema 先定输出再写抽取逻辑很多开发者在写抽取代码时习惯先写一堆if WE in text再顺手输出一个 dict。这样写出来的代码在单条文本上能跑但换一批文本后字段经常对不上。更稳妥的做法是先定义输出结构再倒推需要哪些规则。一份最简输出可以设计成这样{ input: 原始赛评文本, score: { team_a: JDG, score_a: 2, team_b: WE, score_b: 0 }, winner: JDG, entities: [ { entity: JDG, type: teams, start: 0, end: 3, raw: JDG } ], pick_events: [ { player: cube, round: 10, champion: 蒙多 } ], observations: [ { type: performance_low, keyword: 低迷 } ] }字段设计有几个原则score里的战队名建议使用官方名称不要在 JSON 里出现“京东”“we”混用。entities里的raw保留文本原始写法方便和原始内容对齐。pick_events用来记录“第几楼选了哪个英雄”这是 BP 分析的重要输入。observations只记录打标结果不负责解释为什么这个标签成立。2.2 把词表拆到 YAML不要把字典埋在代码里电竞实体变化很快。一个选手会转会一个战队会改名新英雄会上线老英雄外号会流行。如果把词表写在 Python 代码里运营同学改一个选手 ID 就要提代码变更后续维护成本很高。推荐的做法是把词表抽成 YAML代码只做加载和匹配。示例configs/entities.yamlteams: - name: JDG aliases: - jdg - 京东 - name: WE aliases: - we players: - name: monki aliases: - monki - name: cube aliases: - cube champions: - name: 蒙多 aliases: - 蒙多 - 蒙多医生 - mundo - name: