logo资料库

知识图谱技术原理介绍.docx

第1页 / 共12页
第2页 / 共12页
第3页 / 共12页
第4页 / 共12页
第5页 / 共12页
第6页 / 共12页
第7页 / 共12页
第8页 / 共12页
资料共12页,剩余部分请下载后查看
知识图谱技术原理介绍 近两年来,随着 Linking Open Data1等项目的全面展开,语义 Web 数据源的 数量激增,大量 RDF 数据被发布。互联网正从仅包含网页和网页之间超链接的 文档万维网(Document Web)转变成包含大量描述各种实体和实体之间丰富关 系的数据万维网(Data Web)。在这个背景下,Google、百度和搜狗等搜索引擎 公司纷纷以此为基础构建知识图谱,分别为 Knowledge Graph、知心和知立方, 来改进搜索质量,从而拉开了语义搜索的序幕。下面我将从以下几个方面来介绍 知识图谱:知识图谱的表示和在搜索中的展现形式,知识图谱的构建和知识图谱 在搜索中的应用等,从而让大家有机会了解其内部的技术实现和各种挑战。 知识图谱的表示和在搜索中的展现形式 正如 Google 的辛格博士在介绍知识图谱时提到的:“The world is not made of strings , but is made of things.”,知识图谱旨在描述真实世界中存在的各种实体或 概念。其中,每个实体或概念用一个全局唯一确定的 ID 来标识,称为它们的标 识符(identifier)。每个属性-值对(attribute-value pair,又称 AVP)用来刻画实 体的内在特性,而关系(relation)用来连接两个实体,刻画它们之间的关联。知 识图谱亦可被看作是一张巨大的图,图中的节点表示实体或概念,而图中的边则 由属性或关系构成。上述图模型可用 W3C 提出的资源描述框架 RDF2或属性图 (property graph)3来表示。知识图谱率先由 Google 提出,以提高其搜索的质量。 为了更好地理解知识图谱,我们先来看一下其在搜索中的展现形式,即知识卡 片(又称 Knowledge Card)。知识卡片旨在为用户提供更多与搜索内容相关的信 息。更具体地说,知识卡片为用户查询中所包含的实体或返回的答案提供详细的 结构化摘要。从某种意义来说,它是特定于查询(query specific)的知识图谱。 例如,当在搜索引擎中输入“姚明”作为关键词时,我们发现搜索结果页面的右 侧原先用于置放广告的地方被知识卡片所取代。广告被移至左上角,而广告下面 则显示的是传统的搜索结果,即匹配关键词的文档列表。这个布局上的微调也预 示着各大搜索引擎在提高用户体验和直接返回答案方面的决心。图 1 从左到右依 次是 Google、百度和搜狗在搜索结果首页中所展现的与姚明相关的知识卡片。 1 http://linkeddata.org/ 2 http://www.w3.org/TR/rdf-concepts/ 3 https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model
图 1. 当搜索“姚明”时,Google、百度和搜狗所展示的知识卡片 虽说三大搜索引擎在知识卡片的排版和内容展现上略有不同,但是它们 都列出了姚明的身高、体重、民族等属性信息。此外,它们均包含“用户还 搜索了”或“其他人还搜”的功能来展现相关的人物。该功能允许用户去浏 览其他与姚明相关的人物的详细信息。细心的读者也发现 Google 在其知识卡 片中也展示了很多与姚明相关的图片,以图文并茂的方式来展示姚明的方方 面面。百度则结合了百度风云榜的信息,列出了姚明的类别(体坛人物)及 其百度指数(今日排名和今日搜索热度等信息)。在搜索结果页面的左上角(在 图中未给出),百度还展示了其特有的专题搜索,包含了与姚明相关的百科、 图片、微博、新闻、音乐、贴吧和视频等七大类的结果,基本涵盖了用户最 基本的需求。搜狗在列出与姚明相关的百科、图片,电影和最新相关消息等 专题的同时,其知识卡片额外显示了诸如“主持电视节目”、“效力篮球队”、 “人物关系”等各种细粒度的语义关系。当遇到含有歧义的用户查询时,知 识卡片还会列出其他可能的查询目标对象。在上面的例子中,搜狗还列出了 一项“您是否要找”的功能,列出一位也叫姚明的一级作曲家。该功能用于 去歧义,在显示最相关实体的同时也给出其他可能的对象,达到去歧义的作 用。当搜索“李娜”或“长城”时,Google 和百度也在其知识卡片下方展现
了类似的功能。除了给出著名网球运动员李娜和万里长城之外,它们还列出 歌手李娜和长城汽车供用户选择和浏览。更值得一提的是,当在搜狗知立方 中输入“姚明的老婆的女儿的身高”如此复杂的查询时,其会直接返回其女 儿的姓名(姚沁蕾)以及其身高(110cm),并给出推理说明“叶莉的女儿是 姚沁蕾”。如此详实的说明不仅为返回的答案提供了很好的解释,从另一个侧 面也展示了知识图谱的强大,其不仅能识别出运动员姚明,也能抽取出关系 “老婆”和“女儿”和属性“身高”等信息。当我们将查询修改为“姚明的 妻子的女儿的身高”时,依然返回相同的结果,这也意味着知识图谱知道“妻 子”和“老婆”代表相同的含义。 通过上述的介绍,大家应该对知识图谱的表示以及其在搜索中的展现形 式有了更深的了解。接着,我将介绍知识图谱的构建以及如何在搜索中应用 知识图谱返回相应的知识卡片以及答案。 知识图谱的构建 1. 知识图谱的规模 据不完全统计,Google 知识图谱到目前为止包含了 5 亿个实体和 35 亿 条事实(形如实体-属性-值,和实体-关系-实体)。其知识图谱是面向全球的, 因此包含了实体和相关事实的多语言描述。不过相比占主导的英语外,仅包 含其他语言(如中文)的知识图谱的规模则小了很多。与此不同的是,百度 和搜狗主要针对中文搜索推出知识图谱,其知识库中的知识也主要以中文来 描述,其规模略小于 Google 的。 2. 知识图谱的数据来源 为了提高搜索质量,特别是提供如对话搜索和复杂问答等新的搜索体验, 我们不仅要求知识图谱包含大量高质量的常识性知识,还要能及时发现并添 加新的知识。在这种背景下,知识图谱通过收集来自百科类站点和各种垂直 站点的结构化数据来覆盖大部分常识性知识。这些数据普遍质量较高,更新 比较慢。而另一方面,知识图谱通过从各种半结构化数据(形如 HTML 表格) 抽取相关实体的属性-值对来丰富实体的描述。此外,通过搜索日志(query log) 发现新的实体或新的实体属性从而不断扩展知识图谱的覆盖率。相比高质量 的常识性知识,通过数据挖掘抽取得到的知识数据更大,更能反映当前用户
的查询需求并能及时发现最新的实体或事实,但其质量相对较差,存在一定 的错误。这些知识利用互联网的冗余性在后续的挖掘中通过投票或其他聚合 算法来评估其置信度,并通过人工审核加入到知识图谱中。 a) 百科类数据 维基百科4,通过协同编辑,已经成为最大的在线百科全书,其质量 与大英百科媲美。可以通过以下方式来从维基百科中获取所需的内容:通 过文章页面(Article Page)抽取各种实体;通过重定向页面(Redirect Page) 获得这些实体的同义词(又称 Synonym);通过去歧义页面(Disambiguation Page)和内链锚文本(Internal Link Anchor Text)获得它们的同音异义词 (又称 Homonym);通过概念页面(Category Page)获得各种概念以及其 上下位(subclass)关系;通过文章页面关联的开放分类抽取实体所对应 的类别;通过信息框(Infobox)抽取实体所对应的属性-值对和关系-实体 对。类似地,从百度百科和互动百科抽取各种中文知识来弥补维基百科中 文数据不足的缺陷。此外,Freebase5是另一个重要的百科类的数据源,其 包含超过 3900 万个实体(其称为 Topics)和 18 亿条事实,规模远大于维 基百科。对比之前提及的知识图谱的规模,我们发现仅 Freebase 一个数据 源就构成了 Google 知识图谱的半壁江山。更为重要的是,维基百科所编 辑的是各种词条,这些词条以文章的形式来展现,包含各种半结构化信息, 需要通过事先制定的规则来抽取知识;而 Freebase 则直接编辑知识,包括 实体及其包含的属性和关系,以及实体所属的类型等结构化信息。因此, 不需要通过任何抽取规则即可获得高质量的知识。虽然开发 Freebase 的母 公司 MetaWeb 于 2010 年被 Google 收购,Freebase 还是作为开放的知识管 理平台独立运行。所以百度和搜狗也将 Freebase 加入到其知识图谱中。 b) 结构化数据 除了百科类的数据,各大搜索引擎公司在构建知识图谱时,还考虑其 他结构化数据。其中,LOD 项目在发布各种语义数据的同时,通过 owl:sameAs 将新发布的语义数据中涉及的实体和 LOD 中已有数据源所包 含 的 潜 在 同 一 实 体 进 行 关 联 , 从 而 实 现 了 手 工 的 实 体 对 齐 (entity 4 http://www.wikipedia.org/ 5 http://www.freebase.com/
alignment)。LOD 不仅包括如 DBpedia6和 YAGO7等通用语义数据集,还 包括如 MusicBrainz8和 DrugBank9等特定领域的知识库。因此,Google 等 通过整合 LOD 中的(部分)语义数据提高知识的覆盖率,尤其是垂直领 域的各种知识。此外,Web 上存在大量高质量的垂直领域站点(如电商网 站,点评网站等),这些站点被称为 Deep Web10。它们通过动态网页技术 将保存在数据库中的各种领域相关的结构化数据以 HTML 表格的形式展 现给用户。各大搜索引擎公司通过收购这些站点或购买其数据来进一步扩 充其知识图谱在特定领域的知识。这样做出于三方面原因:其一、大量爬 取这些站点的数据会占据大量带宽,导致这些站点无法被正常访问;其二、 爬取全站点数据可能会涉及知识产权纠纷;最后,相比静态网页的爬取, Deep Web 爬虫需要通过表单填充(Form Filling)技术来获取相关内容, 且解析这些页面中包含的结构化信息需要额外的自动化抽取算法,具体细 节在下一节描述。 c) 半结构化数据挖掘 AVP 虽然从 Deep Web 爬取数据并解析其中所包含的结构化信息面临很大 的挑战,各大搜索引擎公司仍在这方面投入了大量精力。一方面,Web 上存在大量长尾的结构化站点,这些站点提供的数据与最主流的相关领域 站点所提供的内容具有很强的互补性,因此对这些长尾站点进行大规模的 信息抽取(尤其是实体相关的属性-值对的抽取)对于知识图谱所含内容 的扩展是非常有价值的。另一方面,中文百科类的站点(如百度百科等) 的结构化程度远不如维基百科,能通过信息框获得 AVP 的实体非常稀少, 大量属性-值对隐含在一些列表或表格中。一个切实可行的做法是构建面 向站点的包装器(Site-specific Wrapper)。其背后的基本思想是:一个 Deep Web 站点中的各种页面由统一的程序动态生成,具有类似的布局和结构。 利用这一点,我们仅需从当前待抽取站点采样并标注几个典型详细页面 (Detailed Pages),利用这些页面通过模式学习算法(Pattern Learning) 自动构建出一个或多个以类 Xpath 表示的模式,然后将其应用在该站点的 6 http://dbpedia.org/ 7 http://www.mpi-inf.mpg.de/yago-naga/yago/ 8 http://musicbrainz.org/ 9 http://www.drugbank.ca/ 10 相对以静态网页和超链接关联的浅层 Web(Shallow Web)而言,称为深层 Web。
其他详细页面中从而实现自动化的 AVP 抽取。对于百科类站点,我们可 以将具有相同类别的页面作为某个“虚拟”站点,并使用类似的方法进行 实体 AVP 的抽取。自动学习获得的模式并非完美,可能会遗漏部分重要 的属性,也可能产生错误的抽取结果。为了应对这个问题,搜索引擎公司 往往通过构建工具来可视化这些模式,并人工调整或新增合适的模式用于 抽取。此外,通过人工评估抽取的结果,将那些抽取结果不令人满意的典 型页面进行再标注来更新训练样本,从而达到主动学习(Active Learning) 的目的。 d) 通过搜索日志进行实体和实体属性等挖掘 搜索日志是搜索引擎公司积累的宝贵财富。一条搜索日志形如<查询, 点击的页面链接,时间戳>。通过挖掘搜索日志,我们往往可以发现最新 出现的各种实体及其属性,从而保证知识图谱的实时性。这里侧重于从查 询的关键词短语和点击的页面所对应的标题中抽取实体及其属性。选择查 询作为抽取目标的意义在于其反映了用户最新最广泛的需求,从中能挖掘 出用户感兴趣的实体以及实体对应的属性。而选择页面的标题作为抽取目 标的意义在于标题往往是对整个页面的摘要,包含最重要的信息。据百度 研究者的统计,90%以上的实体可以在网页标题中被找到。为了完成上述 抽取任务,一个常用的做法是:针对每个类别,挑选出若干属于该类的实 体(及相关属性)作为种子(Seeds),找到包含这些种子的查询和页面标 题,形成正则表达式或文法模式。这些模式将被用于抽取查询和页面标题 中出现的其他实体及其属性。如果当前抽取所得的实体未被包含在知识图 谱中,则该实体成为一个新的候选实体。类似地,如果当前被抽取的属性 未出现在知识图谱中,则此属性成为一个新的候选属性。这里,我们仅保 留置信度高的实体及其属性,新增的实体和属性将被作为新的种子发现新 的模式。此过程不断迭代直到没有新的种子可以加入或所有的模式都已经 找到且无法泛化。在决定模式的好坏时,常用的基本原则是尽量多地发现 属于当前类别的实体和对应属性,尽量少地抽取出属于其他类别的实体及 属性。上述方法被称为基于 Bootstrapping 的多类别协同模式学习。 3. 从抽取图谱到知识图谱
上述所介绍的方法仅仅是从各种类型的数据源抽取构建知识图谱所需的 各 种 候 选 实 体( 概 念) 及 其 属性 关 联, 形 成 了一 个 个 孤立 的 抽取 图 谱 (Extraction Graphs)。为了形成一个真正的知识图谱,我们需要将这些信息 孤岛集成在一起。下面我对知识图谱挖掘所涉及的重要技术点逐一进行介绍。 a) 实体对齐 实体对齐(Object Alignment)旨在发现具有不同 ID 但却代表真实 世界中同一对象的那些实体,并将这些实体归并为一个具有全局唯一标 识的实体对象添加到知识图谱中。虽然实体对齐在数据库领域被广泛研 究,但面对如此多异构数据源上的 Web 规模的实体对齐,这还是第一次 尝试。各大搜索引擎公司普遍采用的方法是聚类。聚类的关键在于定义 合适的相似度度量。这些相似度度量遵循如下观察:具有相同描述的实 体可能代表同一实体(字符相似);具有相同属性-值的实体可能代表相 同对象(属性相似);具有相同邻居的实体可能指向同一个对象(结构相 似)。在此基础上,为了解决大规模实体对齐存在的效率问题,各种基于 数据划分或分割的算法被提出将实体分成一个个子集,在这些子集上使 用基于更复杂的相似度计算的聚类并行地发现潜在相同的对象。另外, 利用来自如 LOD 中已有的对齐标注数据(使用 owl:sameAs 关联两个实 体 ) 作 为 训练 数 据 , 然 后 结 合 相 似度 计 算 使 用 如 标 签 传 递(Label Propagation)等基于图的半监督学习算法发现更多相同的实体对。无论 何种自动化方法都无法保证 100%的准确率,所以这些方法的产出结果将 作为候选供人工进一步审核和过滤。 b) 知识图谱 schema 构建 在之前的技术点介绍中,大部分篇幅均在介绍知识图谱中数据层 (Data Level)的构建,而没有过多涉及模式层(Schema Level)。事实上, 模式是对知识的提炼,而且遵循预先给定的 schema 有助于知识的标准化, 更利于查询等后续处理。为知识图谱构建 schema 相当于为其建立本体 (Ontology)。最基本的本体包括概念、概念层次、属性、属性值类型、 关系、关系定义域(Domain)概念集以及关系值域(Range)概念集。 在此基础上,我们可以额外添加规则(Rules)或公理(Axioms)来表示
模式层更复杂的约束关系。面对如此庞大且领域无关的知识库,即使是 构建最基本的本体,也是非常有挑战的。Google 等公司普遍采用的方法 是自顶向下(Top-Down)和自底向上(Bottom-Up)相结合的方式。这 里,自顶向下的方式是指通过本体编辑器(Ontology Editor)预先构建本 体。当然这里的本体构建不是从无到有的过程,而是依赖于从百科类和 结构化数据得到的高质量知识中所提取的模式信息。更值得一提的是, Google 知识图谱的 Schema 是在其收购的 Freebase 的 schema 基础上修改 而得。Freebase 的模式定义了 Domain(领域),Type(类别)和 Topic(主 题,即实体)。每个 Domain 有若干 Types,每个 Type 包含多个 Topics 且和多个 Properties 关联,这些 Properties 规定了属于当前 Type 的那些 Topics 需要包含的属性和关系。定义好的模式可被用于抽取属于某个 Type 或满足某个 Property 的新实体(或实体对)。另一方面,自底向上 的方式则通过上面介绍的各种抽取技术,特别是通过搜索日志和 Web Table 抽取发现的类别、属性和关系,并将这些置信度高的模式合并到知 识图谱中。合并过程将使用类似实体对齐的对齐算法。对于未能匹配原 有知识图谱中模式的类别、属性和关系作为新的模式加入知识图谱供人 工过滤。自顶向下的方法有利于抽取新的实例,保证抽取质量,而自底 向上的方法则能发现新的模式。两者是互补的。 c) 不一致性的解决 当融合来自不同数据源的信息构成知识图谱时,有一些实体会同时 属于两个互斥的类别(如男女)或某个实体所对应的一个 Property11(如 性别)对应多个值。这样就会出现不一致性。这些互斥的类别对以及 Functional Properties 可以看作是模式层的知识,通常规模不是很大,可 以通过手工指定规则来定义。而由于不一致性的检测要面对大规模的实 体及相关事实,纯手工的方法将不再可行。一个简单有效的方法充分考 虑数据源的可靠性以及不同信息在各个数据源中出现的频度等因素来决 定最终选用哪个类别或哪个属性值。也就是说,我们优先采用那些可靠 性高的数据源(如百科类或结构化数据)抽取得到的事实。另外,如果 11称为 Functional Property,即仅允许和一个值关联。如果该 property 是属性,那么就只能和一个属性值关 联,如果是关系,则只能关联一个对象。
分享到:
收藏