我们已经看到，置信传播使我们能够在图 3.10 的模型中计算变量 Jskill 的精确边缘后验分布。虽然 Jskill 的先验分布是一个由两个参数描述的高斯，但后验分布不是高斯，而是一个需要四个参数的更复杂分布。为阻止参数数量在每局游戏后不断增加，我们需要一种方法用具有固定数量参数的分布来近似这个真实的后验，为此我们选择高斯。这样后验分布就会与先验具有相同的函数形式，模仿共轭先验的行为。如果我们能做到这一点，就能把所得的近似后验分布当作下一局游戏的先验分布。这样，每个玩家的技能将始终由一个仅受两个参数支配的高斯分布表示。

第一个问题是如何用一个高斯来近似一个非高斯分布。一个简单的解法是求出该非高斯分布的均值和方差，然后选一个具有相同均值和方差的高斯作为我们的近似。事实证明这是一个合理的近似，它可以通过优化两个概率分布不相似性的某种度量来形式化地推导出来 [Bishop, 2006; Minka, 2005]。

我们也许会因此想干脆直接用一个高斯来近似 Jskill 的精确后验分布。虽然这对图 3.10 的因子图会令人满意地奏效，但当我们转向更复杂的因子图（例如本章后面将遇到的那些）时，它又会失效。具有简单函数形式的消息在穿过因子后往往会变得更复杂。当我们把模型扩展到更大、更精巧的图时，很快就会遇到消息无法被精确计算的情形。这类问题可以通过在每个因子节点处局部地做近似来避免，从而使所有消息都具有所需的分布类型。这确保了只要每个因子都能使用适当的分布类型向所有相邻的变量节点发送近似消息，因子就可以被组合成任意的图。

下面这一小节会深入这类近似推断算法的数学细节。如果你想跳过这些细节，尽可直接看下一节。

推断深入探讨

在这个可选小节中，我们引入期望传播这一近似推断技术，我们将在本书中广泛使用它。如果你想专注于建模，尽可跳过本小节。

回到图 3.12（为方便起见在图 3.21 中重现），我们看到消息 (6) 是我们遇到的第一个非高斯消息。

……

阅读全文

到目前为止，我们假设已经知道 Jill 和 Fred 的技能，并用这些技能计算了每个玩家成为胜者的概率。在实践中，我们必须反向推理：我们观察到谁赢得了游戏，并需要用这个信息来了解玩家的技能值。因此，我们转向学习玩家技能这一问题。

在任何游戏中，看到谁胜谁负都会告诉我们关于玩家技能的信息。

给定一局游戏的结果，提高胜者的技能值、降低败者的技能值似乎是合理的。然而，不太清楚的是我们应当做多大的调整。直觉上我们可以这样推理。假设 Jill 是这局游戏的胜者。如果 Jill 的技能显著高于 Fred，那么 Jill 获胜并不令人意外，因此技能值的变化应当相对较小。如果技能相近，那么较大的变化就有道理。然而，如果 Jill 的技能显著低于 Fred，那么这个游戏结果就非常令人意外。这个结果表明我们当前对技能值的评估不太准确，因此我们应当对技能值做大得多的调整。简而言之，意外的程度指示了应当对技能值做多大的改变。我们将看到，在一个合适的模型中执行推断会自动给出这种行为。

阅读全文

我们的目标是构建一个能够评估在线游戏玩家技能的系统。作为迈向这一目标的第一步，我们需要先考察一个更简单的问题：在已经知道相关玩家技能的情况下，预测一局游戏的结果。这将使我们发展出解决“确定技能”这一更复杂问题所需的许多概念。

假设 Jill 将在 Xbox Live 上与 Fred 玩一局《光环》。在第 2 章中，我们用一个二值变量来表示一个人的软件开发技能，指示此人是否具备某项特定技能。当我们考虑一个人在《光环》这类典型 Xbox 游戏中的技能时，这种做法就不够用了，因为可能的技能水平存在很宽的谱系。相反，用一个连续值来表示一个人的技能更为合适。因此，我们的第一条建模假设是：

阅读全文

每一天，全世界数以百万计的玩家登录 Xbox Live®，在数百款不同的游戏里彼此对战。他们的乐趣取决于是否能被匹配到实力相当的其他玩家，从而获得良好的游戏体验。那么，我们如何用基于模型的机器学习来自动匹配实力相近的玩家呢？

对于游戏而言，在线世界的一大优势在于随时随地都能找到对手，无论白天黑夜。Xbox Live 的一项重要需求，是能够找到技能水平相当的对手，以便让玩家获得愉快的游戏体验。这一需求意味着系统必须有办法估计玩家的技能。然而，要做到这一点会面临一些重大挑战——尤其是，实力更强的玩家并不总能赢得一局游戏。许多游戏都带有运气成分，在某一局中运气可能会偏向较弱的玩家。更普遍地说，一名玩家的表现会因疲劳或热情起伏等因子而在不同对局之间发生变化。因此，我们不能假设某一局的胜者一定比败者技能更高。另一方面，我们确实预期实力更强的玩家在与较弱玩家的对局中，赢的次数会多于输的次数，所以对局结果确实能提供关于玩家相对技能的有用信息。

阅读全文

回到第 1 章处理谋杀之谜时，我们首先从犯罪现场收集证据，然后运用我们自己的知识来构建这起谋杀的概率模型。我们以观测变量的形式，把犯罪现场的证据整合进模型，并执行推断来回答我们关心的查询：每个嫌疑人是凶手的概率是多少？随后我们评估推断的结果是否足够好——也就是说，概率是否高到足以认定谋杀已被侦破？当结果不够好时，我们便收集更多数据、扩展模型、重新运行推断，最终达到了我们的目标概率。

在第 2 章评估求职者技能时，我们从参加真实测试的人那里收集数据并对这些数据进行了可视化。然后我们基于对人们如何做测试的知识建立了一个模型。我们运行了推断，并评估出结果不够好。我们诊断了问题、扩展了模型，然后对原始模型和扩展后的模型都进行了评估，以量化改进程度，并检查改进后的模型是否达到了我们的成功标准。

我们可以从这两个例子出发进行归纳，定义出任何基于模型的机器学习应用所需的步骤：

1. 收集用于训练和评估模型的数据。
2. 收集知识，以帮助做出恰当的建模假设。
3. 可视化数据，以更好地理解它、检查数据问题，并获得对有用建模假设的洞见。
4. 构建一个模型，使其捕捉关于问题领域的知识，并与你对数据的理解相一致。
5. 执行推断，利用数据来固定其他变量的取值，从而对我们关心的变量做出预测。
6. 使用某种评估指标来评估结果，看它们是否满足目标应用的成功标准。

在（通常的）系统第一次未能满足成功标准的情况下，还需要额外的两个步骤：

阅读全文

你可能以为，推断猜测概率需要用到与我们目前所用完全不同的技术。事实上，我们的做法将完全相同：我们把想要学习的概率值作为新的连续随机变量加入模型，并用概率推断来计算它们的后验分布。这展示了基于模型方法的威力——每当我们想知道某个东西时，我们就把它作为一个随机变量引入模型，然后用概率推断去求出它。

让我们看看如何修改模型，把猜测概率作为随机变量纳入进来。为了保持一致，我们也会为犯错概率（实际上是不犯错概率）添加一个变量，但我们会把它固定在 10% 的犯错几率上。首先，我们要改变书写 AddNoise 因子的方式。

(a) 内置概率的自定义因子

(b) 通用的 Table 因子

图 2.25：书写 AddNoise 因子的两种方式：(a) 作为一个把猜测和犯错概率“内置”其中的自定义因子。(b) 使用一个通用的 Table 因子，它带有两个参数：给定父节点为 false 时子节点为 true 的概率（左参数），以及给定父节点为 true 时子节点为 true 的概率（右参数）。这种书写因子的方式让我们可以把这些概率作为变量提供给因子。

图 2.25 展示了如何把现有的 AddNoise 因子（其中猜测和不犯错概率被硬编码为 0.2 和 0.9）替换为一个通用的 Table 因子，后者把这些概率作为额外的参数。然后我们可以用两个新的随机变量来设置这些参数，我们把它们命名为 probGuess 和 probNoMistake。推断这些变量的后验分布，就会给出我们所需的猜测和不犯错概率的学习值——但为此，我们首先需要一种能表示这类变量不确定性的分布。

阅读全文

当一个机器学习系统不工作时，通常有三个可能的原因：坏数据、坏模型或坏推断。以下是这三个类别下各自一些常见的问题成因：

• 坏数据（Bad data）：数据项被错误地录入、存储或加载；数据项不完整或标注错误；数据值噪声太大而无用；数据有偏或不能代表系统将被使用的方式；这是任务的错误数据；数据不足以做出准确预测。
• 坏模型（Bad model）：一个或多个建模假设是错的——即与实际生成数据的过程不一致；模型做了太多简化假设；给定可用数据量，模型包含的假设不足以做出准确预测。
• 坏推断（Bad inference）：推断代码含有 bug；消息传递调度不好；推断尚未收敛；存在数值问题（例如舍入、溢出）；近似推断算法不够准确。

在我们的情形中，我们可以相当有信心地认为数据是好的，因为我们已经仔细地检查和可视化过它。所以看起来问题很可能出在模型或推断上。我们将从检查推断算法——即循环置信传播——是否正确工作开始。

阅读全文

既然我们已经在示例数据上充分试验过模型，现在就可以用一些真实数据来工作了。我们请了 22 位志愿者完成一份由 48 道题组成的测评测试，用以评估七种不同的开发技能。许多题目需要两项技能，因为它们既需要某个软件开发概念的知识（例如面向对象编程），又需要该题所用编程语言的知识（例如 C#）。

除了完成测试之外，我们还请每位志愿者说明他们认为自己具备哪些开发技能。这些自评技能将作为技能变量的真实标注（ground truth）——也就是说，我们把它们当作变量的真实取值。这类真实标注数据将用于评估我们的系统从志愿者答案中自动推断技能的准确性。真实标注数据应当相当可靠，因为志愿者没有夸大自己技能的动机：结果是匿名的，所报告的技能和答案无法与任何特定志愿者关联。然而，某些志愿者也有可能高估或低估自己的技能，我们在用这些数据评估准确性时需要牢记这一点。

阅读全文

现在让我们把模型稍微扩展一下，添加第四道需要两项技能的题目。这张新的因子图如图 2.14 所示，我们为这道新题添加了新的 isCorrect4 和 hasSkills4 变量。在这张仅仅略微变大的图上，我们当然也可以用置信传播来做推断吧？其实，我们不能。

环可能很棘手。

问题在于，置信传播只有在某个（未观测）节点的所有其它边上都收到了消息之后，才能从该节点发出一条消息（算法 2.1）。在这个约束下，只有当图中没有环时，我们才能把图中的所有消息都发送出去；这里的环是指一条穿过图、从同一个节点出发又回到该节点的路径（且不重复经过同一条边）。如果图中有一个环，那么我们无法沿着环上的任何一条边发送消息，因为这总是要求先计算出环上的另一条消息。

阅读全文

构建好一个模型之后，首先要做的就是用一些简单的示例数据来试验它，检查它的行为是否合理。假设有一位候选人懂 C# 但不懂 SQL——我们会预期他答对第一题，而答错另外两题。那么让我们针对这种情况试验一下模型，看看对于这样的答题模式它会推断出哪些技能。为方便起见，我们用 isCorrect 来指代数组 [isCorrect1, isCorrect2, isCorrect3]，因此我们要考虑的是 isCorrect 为 [true, false, false] 的情形。

我们想在给定这一组特定的 isCorrect 取值的条件下，推断候选人具备 csharp 和 sql 技能的概率。这是一个推断查询的例子，它由我们想要推断的变量（csharp、sql）以及我们所条件化的变量（isCorrect）连同它们的观测值共同定义。由于这个例子相当小，我们可以用手工方式求出这个推断查询的答案。

手动进行推断

作为开始，我们先来看看在只给定第一题答案的情况下，如何推断 csharp 技能的概率。舍去其它变量后，就得到图 2.6 所示的简化因子图。

阅读全文