1996年是个不平凡的一年.. 那年, Nicholas Negroponte 的“数字化生存”成为IT界热议的焦点, 现今的IP大作“冰与火之歌”开始出版, PS (Sony) 与 Saturn (SEGA) 厮杀于32位主机市场.. 同年! 处于黄昏的 Gameboy (Nintendo) 却静静地开辟了一个神话: 任天堂推出了一款平淡而不易被留意的电子游戏作品 — “Pokémon - 赤/绿”.
虽然 “Pokémon” 在初登场时并未引发反响, 但在很短的时间里, 这部作品就凭借众多的元素与精巧的设计得到了广大掌机玩家的一致好评, 这种包含多元素的规则关系的表示也使其成为了知识图谱感兴趣且易于研究的对象. 从那时起, “Pokémon” 的内涵便逐渐从便携式游戏扩散到了动漫、电影、集换式卡牌、动漫周边、主题公园等产业上..
然而，20多年来“Pokémon”一直以掌机系列游戏作为其核心内容，并不断发展进化这一基础，其官方和非官方的知识数据库也处于不断地迭代更新中：赤绿蓝黄、金银水晶、宝石、火红叶绿、钻石珍珠白金、心金魂银、黑白1\2、XY、终始宝石、日月1\2、Let’sGo…
设计需求
在Pokémon知识系统的设计中，有对于关系分析的需求，将知识图谱派上用场。这里利用作为语义网络的知识库的知识图谱来解决这个问题，试图构造以Pokémon里的精灵和其特性为主要实体的多关系图
对于构建一个Pokémon知识系统，有许多知识结构和细节包括:
- 每只精灵拥有一到二种系别；
- 每种技能拥有一个系别；
- 每只精灵拥有一到四种技能；
- 系别之间存在克制与抵抗等关系：如果使用技能的系别克制对方精灵的系别，会造成较大的伤害；如果被对方的系别抵抗，伤害就比较小；如果对对方的系别无效的攻击更是无法带来伤害。
- 当精灵使用招式的系别与自身的系别相同时，造成的伤害会更高。
- 如果计算顺序(考虑存在两系别的精灵)，18种系别总共有289种组合方式，但在已知的精灵中，存在的系别组合只有124种。
- 如果不计算顺序，18种系别总共有153种组合方式，但在已知的精灵中，存在的系别组合只有110种。
这里面临的问题主要是所针对的数据，为在知识图谱中表示Pokémon知识系统，要处理的是:
- 关系复杂的数据：不同的精灵以及精灵的一些属性会和某些技能或道具间的反应不固定，这涉及对于同一个技能(如诅咒)或道具(如电珠)和精灵间关系的不同理解;
- 类型繁多的数据：精灵的种类有809种，技能道具分五大类每类各20余种，系别现有18种，而技能种类更是五花八门(如图(1)所示);
- 结构多变的数据：对于精灵拥有的特性、携带的道具以及一些辅助类技能，其表现有时倾向于修改六项基本数值，有时倾向于在系别效果上的调整(引火特性相当于增加无效火系技能，神秘守护特性相当于将对系别不克制转化为对系别无效…)
|
|
| 图(1): Pokémon的招式(技能)数目分布图 |
设计过程
定义问题
由于Pokémon内涉及的元素过多，且网上没有可下载的数据库，本文就Pokémon的系别和一些典型的精灵作为实体，类型克制关系作为研究和设计的对象。目的是处理Pokémon多样的元素，回答Pokémon中常见的一些包含关系搜索的问题(例如选择出场精灵和精灵配招)，并可以直接且迅速地提供所求得的解的可视化表示。两个常见的真实问题是：
- 当对手选择了一只精灵时，我该选择什么精灵应对；
- 当我决定让某只精灵出战时，应为其选择哪四个技能。
数据生成
为了用知识图谱来描述Pokémon中包含的知识系统，需要生成所需的Pokémon的数据，一般数据的生成分为以下三步：
- 寻找数据源：包括结构化的数据源(数据库)以及一些非结构的数据源(网页百科)
- 获取生数据：知识图谱构建的前提是需要把数据从不同的数据源中抽取出来。
- 预处理并生成所需数据
对于数据源，我们所需的Pokémon的数据其实主要来自于Pokémon图鉴和wiki，官方的数据库是不开放的，网络上公开非官方的(仅供学习交流使用)目前包括：
对于生数据的获取，由于无法直接访问这些网站的数据库，这里只能通过爬虫技术从网页上将所需的数据进行信息抽取：包括一部分精灵以及其系别的数据，一部分技能以及其系别的数据，系别之间相克关系的数据以及精灵对技能能否习得关系的数据。
- 对于数据的预处理，基本将爬下来的数据(包含一些非结构化数据)精灵、技能和系别的三张表里即可。表里包含的属性信息只涉及需要进一步的处理的相关数据(一些精灵共通的属性，系别的相克关系等等)。同时，不同网页对于某些实体的称呼可能略有不同，比如“灾难兽”，“灾兽”，“阿勃梭鲁”以及“アブソル”这几个名称其实指向的是同一个实体，这里需要对涉及这个问题的数据做实体对齐。数据处理涉及实体命名识别、关系抽取、实体统一、指代消解等。
知识图谱的表示
知识图谱也有两种主要的表示方法：RDF三元组(RDF-Triples)表示法和属性图表示法。RDF三元组使得数据易于发布和分享，有完整的推理体系，其常用于学术场景，但处理拥有属性值的实体则需要较繁琐的设计。在Pokémon的世界中，精灵、技能、种系这三类实体和进化关系都拥有各自的属性，比如对于精灵这一类实体可以有“名称”、“系别”、“身高”、“体重”、“特性”、“捕获率”、“体能值”、“攻击值”、“防御值”、“特攻值”、“特防值”和“速度值”等属性。鉴于Pokémon这种多元实例以及属性丰富的特点，我们用知识图谱里的属性图(Property Graph)来表示精灵、技能以及系别。这里展示了一个简单的Pokémon属性图, 如图(2)所示:
|
|
| 图(2): 一个简单的Pokémon属性图表示 |
图(2)中，对于三种精灵：妙蛙花、妙蛙草和妙蛙种子，它们都是草系和毒系精灵，妙蛙花是妙蛙草的进化型，妙蛙草又是妙蛙种子的进化型，进化所需等级为32；妙蛙花各项属性值都很高，其特攻值为100。再对于三种技能：日光束、破坏光线和花瓣舞，妙蛙花和妙蛙种子都可以学习日光束（妙蛙花可自学，妙蛙种子可用学习机学），妙蛙花可自学草系技能花瓣舞并用学习机学习破坏光线，而妙蛙种子这两个技能皆不能学会；其中破坏光线是普通系特殊(Spc)技能，且有很高的威力150。这里可以看出属性图非常契合Pokémon的知识系统，可以很好地描述其中所包含的逻辑
知识图谱应用的前提是已经构建好了知识图谱，而知识图谱的设计需要理解要解决的问题以及问题未来的演化。这里考虑下列六种基本查询:
- 某一系别所包含的精灵
- 某一系别所包含的技能
- 某一系别被哪些系别克制
- 某一系别克制哪些系别
- 某个精灵能学会哪些技能
- 某个技能能被哪些精灵学会
知识图谱的设计满足BAEF原则:
- 业务(Business)原则: 六种基本查询体现了需要的业务的本质，知识图谱围绕这些来设计。
- 分析(Analytics)原则: 我们要查询(分析关系)的只有精灵、技能和系别，这些显然是实体。
- 效率(Efficiency)原则: 六种基本查询基本需要用图谱表示，此外的信息不需要图谱表示。
- 冗余(Redundancy)原则: 六种基本查询十分简洁，相同的指代以及复杂的属性均忽略。
由此，设计的知识图谱是以精灵、技能和系别为实体，系别间的克制，精灵和技能间的匹配以及精灵和技能各自是什么系别这些都作为关系。
在知识图谱的表示中，这里通过BAEF原则尽量去除无关信息，并从筛选的数据中抽离实体、关系和属性，同时考虑哪些属性以做为实体，哪些实体可以作为属性。本文由于只试图回答选择出场精灵和精灵配招这些基本问题，所以从六种基本查询出发构建的知识图谱基本满足需求。
知识图谱构建(应用)
我们采用Neoj4图数据库,将获得的数据(已经存在Excel表内，包括精灵、技能和系别三张表)用之前作业的方法转化为图，实际上是将处理好的数据库表的结构数据转成图。
|
|
| 图(3): 从数据到属性图的构建过程 |
知识图谱实验
Pokémon知识图谱的操作以及结果
增加一个新的精灵”DongDuck”:
查询一只精灵”妙蛙种子”:
创建一个新系别”妖”，属性注明属于一种系别(”Class”):
创建一个关系, 说明”妖”攻击”钢”效果减半(0.5), 是一种弱于(weak)的关系:
查询系别相克表:
图(4) Neo4j生成的部分系别相克表属性图
结论
本文构建的Pokémon知识图谱效果不错：能够表示精灵以及技能间的一些关系，在一定程度上辅助爱好者们快速得到他们想要的数据。知识图谱领域目前仍充满挑战，对于本文构建的Pokémon知识图谱，我感受到了知识图谱构建的趣味性和复杂性，以及其用于分析实体关系的便捷性。类似于Pokémon的大型多角色游戏是图数据库很契合的应用场景，知识图谱在其中所能发挥的作用包括规则设定、任务判定、AI辅助等。然而，像Pokémon一样，这类游戏有很多细节性的内容，这对于第三方的数据抽取以及数据构建仍有很大难度，故本文也未能对Pokémon所有信息进行完全建库。希望随着知识工程方法的深入研究，在这方面可以解放人类的生产力，在游戏领域使得爱好者们能够更专注于游戏策略而不是内容整理，更进一步地在各个领域使得人们能够关注于如何利用资料在各自领域做决策而不是疲于整理情报以及进行繁琐的知识推理。
1778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
