鲍捷 | 知识表示——面向实战的介绍

本文转载自文因互联 2016 年 6 月份组织的第一期北京知识图谱学习小组 Wiki。

---

• 知识表示（Knowledge Representation，KR，也译为知识表现）是如何将结构化数据组织，以便于机器处理和人的理解的方法。从结构推导出新的结构，这就是推理。传统上KR属于逻辑的分支，但在实践中我们会用很简单、可读、可维护的数据结构。

  
  

  经典的教科书中的 KR，主要关注的是如何方便机器处理。但是在现实的工程中，如何方便人的理解也是极为关键的。在工程实践中，人才是知识不能被处理好、不能快速交换、不能规模化的核心。

  
  

  知识表现的瓶颈不在于机器处理能力的不足，而在于人的认知能力的不足。因此，我们在学习知识表现方法的时候，要始终牢记知识的可读性、可维护性要远远比它的表达力、计算速度重要。知识是为人阅读而设计的，只是偶尔被机器执行。

  
  

  数据优先，逻辑靠边

  
  

  作为工程师，我们时时刻刻把可行性放在心中。传统的知识图谱的 KR，从逻辑和推理讲起，有一阶逻辑(first-order logic)和描述逻辑(description logic)，后来又有逻辑程序(logic program)和生成规则（Production Rule）。但是我反对从逻辑开始理解知识图谱。语义网和知识图谱是关于数据的，关于结构促进数据的流动，用结构化数据增进其他系统的自动化能力的。逻辑只是很小的一个插件。

  
  

  语义网，或者现在的知识图谱，在应用中，核心问题不是“应该怎么样”，而是“不得不怎么样”。语义推理对数据质量的要求很高，在工程上成本就承受不了。现实的应用，只能逐步提高数据的质量，从数据清洗开始就要承担巨额的投入，然后做实体抽取，实体链接，对齐，消歧，关系抽取，对齐，词库提取，本体建模，这每一步都是海一样的银子砸进去。

  
  

  然后在推理中，推理规则都需要人生成。现在机器生成规则的能力很弱，几乎不可用。仅仅是属性和直接关系的查找可以机器做，稍微复杂的长程关系都需要人来写。这在工程部署中有巨大的困难，因为这样的工程师很少，写出来的东西可维护性，性能，普适性都成问题。所以现实中的系统，很少有做推理的。即使是做推理，也很少是一阶逻辑推理，一般也就是if then else，命题逻辑。很多时候还要容忍数据中的噪声，和正则表达式等结合在一起用。所以学术派的推理机，一般都用不了。

  
  

  所以我们会了解 RDF 和 OWL，但是并不推荐使用这些 W3C 标准作为工程的选择。我们认为 JSON 和关系数据库是工程中成本较小的解决方案。在某些特定场合，图的表示也是合理的。这会在之后的“知识存储”的章节继续讨论。

  
  

  其他一些我的个人观点

  • 我对关联数据的看法 http://baojie.org/blog/2014/12/21/on-linked-data/

  • 语义网的工具演化 http://baojie.org/blog/2014/02/12/semantic-tool-evolution/

  • 语义网不需要描述逻辑 http://baojie.org/blog/2013/02/05/semantic-web-and-description-logic/

  
  

  知识表现的数据结构

  
  

  在知识提取之后，如何表示知识？其实知识并不神秘，只是一些数据之间的关系。在计算机中的表示，就是数据结构。传统上，我们把那些能够导出新的关系的关系（比如“爸爸的爸爸是爷爷”，这里面“爸爸”和“爷爷”都是关系）看成知识。但是在目前的知识图谱实践中，并不会有严格的区分，我们把各种结构都可以看成广义的知识。

  
  

  不过不是所有的数据结构我们会用知识工程的方法来处理，比如集合、哈希表、队列、堆栈、链表等等，一般丢给软件工程去处理。另一类特殊的结构，二维表，我们丢给数据工程去解决。当然数据工程和知识工程之间没有严格的界限，二维表和复杂知识结构表示之间也有交叉，暂留后述。

  知识表现的数据结构，一般来说是那些“复杂”的结构，最常见的就是图（graph）和树（tree）。

  
  

  知识表现的图，是“有类型的边”（typed edge），分析方法和一般的图论和社交关系图谱中分析的无类型的边很不相同。传统的Web结构只有“链接”这一种关系。在2000年代中，语义网试图给链接加上类型说明，如某人主页声明工作于某公司，这就有“工作”关系。这里，类型就是边的“元数据”（metadata）。后来，发现在应用中还需要给边，当然还有节点，添加更多的元数据，这就形成了有类型的边构成的图谱结构，上面每个边和每个节点都拥有元数据。

  
  

  图的知识表现，演化出两个流派。一个是 RDF 图，一个是属性图（Property Graph）。RDF 图是 W3C 的官方标准，得到了政府资金和一些大公司的大力支持，但是最终市场表现平平。属性图是草根自发的，最终得到了市场的认可，现在主要是中小企业、创业公司在用。RDF 图是科学顶层设计出来的，属性图是工程实战中总结出来的。它们发展轨迹的不同也再次证明，好的架构一般是总结出来的，不是凭空设计出来的。

  
  

  RDF 图的基础是三元组，用 URI 命名节点和连接节点，有严格的语义，约束比较多。属性图没有严格的语义，可以比较自由地声明节点和边的属性。RDF 的优势在于推理，但是三元组的组织使稍复杂的关系的表达很困难，具体后述。属性图不定义推理，但是可以通过查询语言（如Gremlin）来做模式（pattern）的查找和图上的遍历（traverse），可以实现特设的(ad-hoc)的推理。也待到图数据库部分细说。

  
  

  用图表示知识，丰富的知识结构主要表现为图上的边，各种推理算法就是在图上推导出边的算法。在传统图论里，有可达性（reachabil