关于知识表示

# 论知识表示 来源：https://sifter.org/~simon/journal/20130713.h.html \[<< (https://sifter.org/~simon/journal/20121218.h.html)\|上一篇 (https://sifter.org/~simon/journal/20130125.html)\|目录 (https://sifter.org/~simon/journal/index.html)\|下一篇 (https://sifter.org/~simon/journal/20130714.html)\|\>\> (https://sifter.org/~simon/journal/20130905.2.h.html)\] ## 2013年7月13日，星期六 #### *论知识表示* 将电话号码存入通讯录这项任务表面上看似极其简单，却让我困扰多年。问题的关键当然不在于存储号码本身，而在于表示该号码适用的语境。常规做法是将所有人归类到常见场景——工作、家庭、手机，或者设置一个灵活的标签号码列表。但若我希望通讯录程序能“理解”我的意思——比如当我说“八月期间约翰的电话号码在晚上6点到9点之间是555-1234，但下雨天或我从外州来电时除外”——程序能否在合适的时机给出正确的号码？ 人类擅长用自然语言描述事物，但让计算机理解则是另一回事。尽管很少被公开承认，真正的问题并非编写一个理解自然语言的程序，而是编写一个能理解**任何事物**的程序。而这又主要涉及如何在程序内部表示知识——不是为了交流，而是为了程序自身的“思考”。本文将探讨这个话题，旨在为人工智能定义一种良好的“机器语言”，同时也从更广泛的视角理解常见的知识表示范式（尤其是编程语言中使用的那些）。 **什么是知识？** 粗略地说，知识可分为两类：模型与状态。模型表示事物运行的方式、可能性、事物间的契合关系，以及普适真理。状态则表示特定时空下事物的状况。用更数学化的语言描述：模型是所有可能状态的统计分布，指明哪些状态可能、哪些不可能等。你对世界的模型就是你关于世界运作方式的直觉认知。你的状态则是此刻你所见所闻所思所感，以及你周围宇宙其余部分的状态。 相应地，我们的记忆至少分为两种不同类型：概念记忆（随时间推移学习如何建模世界——从识别树木到预测被挠痒痒时会咯咯笑）和实例记忆（让你回忆过去的状态，即对特定事物和时光的记忆，比如朋友被挠痒痒时咯咯笑的那个场景）。 我们头脑中的表示显然非常通用。即使面对单张照片，我们也能聚焦于某个点的颜色、汽车的型号，或两只狗的相对大小。我们对场景的理解远不止其中的物品，还包括它们彼此之间的关系，以及场景之外的许多事物。如果场景的某部分被污渍遮挡，我们也能轻松想象那里可能有什么。如果被要求描述，我们能相当简洁地传达，而他人也能在脑海中形成近似的影像。 那么我们是如何做到的？为什么这对计算机来说很困难？我们又该如何改进？让我们从状态表示开始探讨，因为如上所述，模型只能被理解为可能状态的分布——如果我们无法表示状态，就很难表示模型。 **状态** 或许从童年学习代数开始，我们就学会了通过“容器中的事物”这一类比来有意识地表示状态。“X = 10”意味着某个特定事物——数字10——位于X容器中。我们可以想象杯中有十颗石子。我们称X为“变量”，因为它可以容纳不同的东西；我们称这些事物为“值”，因为容器里最初放的是交易物品，而我们关心的是其价值。 在代数中，我们的目标通常是推断容器或变量所持有的值。后来在办公室工作中，我们可能会创建带有填写值空格的表格。在计算机程序中，我们构建复杂的、分层的容器结构，创建指向其他容器的新型值，在数据库中存储值集合，等等——这种范式渗透了计算机科学。 这种类比如此普遍，以至于当它无法完成某些任务时，我们总想着如何扩展或补充它，而不是彻底改用其他方法。但即使在童年代数中，我们也见过“X < 10”这样的表达式。根据现有类比，我们理解这是在约束X可能的值。一切似乎都很好，类比也成立，除了一点我们习以为常的事：我们关于X的这条新知识**无法放入X内部**。在得知X的具体值之前，我们已有“X < 10”这个事实，而X本身（一个整数容器）无法容纳它。如果你想用杯子表示数字五，可以在杯中放五颗石子；如果用表格字段表示，可以写“5”。但如何表示“< 10”？你或许想在杯子或表格字段上写“< 10”，但如果我们还知道X是质数、非负数，或是某种我们手头不知道的“Metaturian norgblat的中位寿命”呢？ 虽然“小于”本身可能是一个概念，但“X < 10”显然是一个事实——它告诉我们关于特定状态（X是其中一部分）的信息，而我们表示事实的基本方式——容器中的事物——却无法优雅地处理它。我说“优雅地”是因为显然我们可以设计方法来实现，我们也确实这样做了：我们可以创建一种新的容器，用于存放关于其他容器的事实表示。于是整个表达式“X < 10”本身以某种形式成为了一个“值”，恰好告诉我们关于另一个值的信息。我们把它写在容器侧面或表格的脚注里。 一方面，这非常巧妙，因为这种元表示允许我们写出关于事实的事实，这可能非常强大。另一方面，真糟糕！这里我们有了最基本的概念——童年就学过的东西——而我们普遍的知识表示法却无法直接编码它。我们可以在X中存储10，但为了存储“X < 10”，我们需要创建另一个容器X'，用于存放关于X的陈述，然后当我们想了解X时需要知道去查看X'…… 公平地说，数学符号确实将“X = 10”和“X < 10”置于同等地位，但我会回到这一点。值得注意的是，没有任何主流计算机编程语言允许你将“X < 10”作为一个陈述句提出。它们都只允许作为问题：一旦X包含特定值，你可以询问该值是否小于十。但你不能直接说“我知道X小于十”！非程序员读到本文可能会感到惊讶——程序员读者则应该反思这一点。 这里很容易说“X < 10”是规则，属于模型而非状态。但虽然说“一个能装9颗石子的杯子只能装9颗石子”可能是规则，但观察到“石子装在一个能装9颗石子的杯子里，所以数量必定少于十”这不是规则，而是关于当前状态的推断事实。更普遍地说：我们拥有的关于状态的*知识*大多来自观察或推断，而这两者通常都是不完整的。如果我们读体重是七十公斤，我们观察到的并非“X = 70”，而更像是“~69.5 < X < ~70.5”。甚至量子物理学的奇特性质也在挑战一种假设——即在某种分辨率下，宇宙存在真实确定的状态。 但无论是否存在，我们关于任何特定变量X的知识通常不是它包含的值，而是它与其他变量的各种关系。那么我们如何表示这些知识？我们童年的代数似乎能很好地处理“X < 10”，那么这是怎么回事？ 放大来看，数学符号实际上只是谓词表示法的另一种语法。在谓词表示法中，我们可能将“X < Y”写作 LessThan(X, Y)，将“X = Y”写作 Equals(X, Y)，以此类推。像“X + Y < Z”这样的等式有一个表示X和Y之和的隐藏变量：Sum(X, Y, A), LessThan(A, Z)。在这种形式下，情况突然反转：所有信息现在都位于变量外部而非内部。变量不再是容纳值的容器，而是被包含于或参与各种与其他变量的谓词关系中。或者说，在我们遇到那个麻烦的常数10之前，看起来是这样。当我们写 LessThan(X, 10) 时，变量似乎仍然是值的持有者。 相应地，许多谓词系统（如Prolog）植根于变量和值（容器中的事物）。例如，在Prolog中说玛丽25岁，你可能会说 AgeOf(mary, 25)。这里，就像常数25一样，mary是一个唯一的常数值（在Prolog中称为原子），它永远指代玛丽，因此我们可能在其他地方说 OlderThan(mary, john) 表示玛丽比约翰年长，等等。 这个问题微妙但关键：当我们直接对永恒值（如原子 mary 这样的常数）创建关系时，我们失去了将知识情境化的能力。例如，EmailOf(john, [email protected]) 可能表示“约翰的邮箱是 [email protected]”。那么我们如何说“约翰在Xcorp的销售部门邮箱是 [email protected]，作为技术支持的邮箱是 [email protected]，而在Zcorp的邮箱是 [email protected]”？通常的答案都很痛苦。最不痛苦的是关系型数据库方法，但出于我将要说明的原因，这只是一个不完整的解决方案。 解决方法是完全放弃变量中的值这一范式，转向真正纯粹的谓词表示法。这意味着将任何常数移出参数列表，例如 AgeOf(mary, 25) 变为 Mary(M), 25(V), AgeOf(M, V)。这里M和V不再是容纳事物的变量，而纯粹是仅用于参与关系的接口。类型概念并未丢失：V可以被视为一个整数接口，能够参与任何需要整数接口的地方。但在这种表示中，它本质上并非值的持有者，因为关于它的所有关系事实都处于同等地位，并且都只是引用它而不深入其内部。 考虑“玛丽比约翰年长”：Mary(M), John(J), AgeOf(M, V), AgeOf(J, U), Greater(V, U)。这里我们对V的唯一了解是 AgeOf(M, V) 和 Greater(V, U)。我们的表示并未在V中存储任何东西。 谓词的激增似乎有问题，但注意这里的Mary只是与Prolog示例中的 mary 一样的新常数。只不过这里，该常数被引入了谓词空间——*这本身已是一个永恒常数的集合*。数字21这样的谓词同样可以在幕后以本质上与Prolog处理整数相同的方式处理：使用二进制表示。这里我们可以使用一组标准的位谓词：Bit0(V), !Bit1(V), Bit2(V), ...（其中 !Bit1(V) 表示我们知道 Bit1(V)*不*为真；同样我们可以说 !Less(V, U) 等）。这再次将谓词保持为永恒常数，将参数保持为瞬态接口——始终如一，无一例外。 想一想，如果我们试图表示的状态知识是一个运行中的C程序的状态。我们可能在联合体（union）中有两个字段指向相同的四个字节内存——例如，一个是整数，另一个是短字符串。两者的底层接口是相同的字节数组，但两个字段对这些字节呈现不同的接口，分别表现为整数和字符串“行为”。联合体的例子说明很清晰，但同样适用于我们所有的程序变量。实际上，我们的变量本身并非值的持有者，而只是对接口的接口，最终才连接到内存芯片或CPU寄存器中真正持有0和1的接口。 当我们（人类）表示关于这些变量的知识时，这是关于它们作为接口的**关系信息**，而非存放在容器中的值。同样，即使是一个优化编译器也主要以关系术语思考变量，并可能得出结论、生成代码，完全依赖相对事实而从不确定某个变量的“值”（该值最终可能根本未在最终程序中显式表示）。 回到我们最初的问题，这一切对我们很有帮助，因为现在我们的接口本身是独特且可靠的上下文。而之前，我们隐式地锚定在变量值的同一性上（注意即使大多数谓词系统在确定两个变量持有相同值时也会将它们“统一”为一个）。现在我们锚定在接口本身的身份上。我们不再使用 EmailOf(john, [email protected])，而是使用 John(J), EmailOf(J, E), "[email protected]"(E)。这允许我们在不影响约翰的其他实例的情况下补全J的上下文：Company(J, C), Xcorp(C), Role(J, S), Sales(S)。注意我们还能情境化J之外的其他接口，例如 Country(C, I), Ireland(I)，以表明我们只讨论Xcorp的爱尔兰部分。 对于约翰的下一个事实，我们创建一个新的接口K：John(K), Role(K, T), TechSupport(T)，等等。在这种表示中，等价关系变得像其他关系一样普通。两个复数接口A和B相等，仅仅意味着它们代表同一个复数。这并不意味着它们是同一个接口：其中一个可能基于极坐标表示，而另一个基于笛卡尔坐标表示，这告诉我们关于它们在不同区域的相对精度等信息。我们可以同时知道它们作为复数相等，但作为复数接口却不同，并且我们可以在一个统一、简单的表示中表达所有这些：Equal(A, B), Cartesian(A), Polar(B)。 关系型数据库实际上也实现了类似的组织结构，如果我们把表视为类型，把（通常是隐式的）唯一行ID视为接口： | 行 | 人 | 公司 | 角色 | 邮箱 | |----|----|------|------|------| | J | john | Xcorp | 销售 | [email protected] | | K | john | Xcorp | 技术支持 | [email protected] | | L | john | Zcorp | 厨师 | [email protected] | | M | mary | Zcorp | 助理 | [email protected] | | N | rob | Xcorp | 销售 | [email protected] | 这并非完全相同的表示，但它阐明了关系型数据库方法与纯粹谓词表示法之间的结构相似性。 谓词表示法可以追溯到很久以前，但无论出于什么原因，它通常在原子集合（在概念上由变量作为值持有）的框架下分析和实现，而非作为无质量接口之间的纯粹关系。这是一个微妙的区别，却带来了不幸的包袱——尤其是在身份和等式概念方面。 那么当我们说一个为真或为假的谓词关系“意味着”某事时，我们指的是什么？ **模型** 模型编码了状态的各部分之间如何相互关联，以及状态如何随时间演变。（如果我们选择将状态视为在时间上复制或展开，那么这两者是相同的：展开状态的某一部分代表一个时间点，另一部分代表另一个时间点。）虽然状态可能编码了X为1，但模型编码了1 + 1等于2。并且通过编码状态如何演化