这也许是让团队陷入困境的最简单的方法。虽然 fishfood（在团队内部使用原型）和 dogfood（在公司内部使用原型）有许多优点，但员工应该看看是否符合性能要求。虽然应避免应用明显比较糟糕的更改，但在临近生产时，应对任何看起来比较合理的更改进行进一步测试，具体方法有两种：请非专业人员在众包平台上回答有偿问题，或对真实用户进行在线实验。
这样做的原因有如下两点。首先，您与代码的关系太密切了。您关注的可能是帖子的某个特定方面，或者您只是投入了太多感情（例如确认偏差）。其次，您的时间很宝贵。考虑一下九名工程师开一个小时会议所花的费用可以在众包平台上购买多少签约的人工标签。
如果您确实想获得用户反馈，请使用用户体验方法。在流程的早期阶段创建用户角色（请参阅比尔·布克斯顿的 Sketching User Experiences 一书中的描述），然后进行可用性测试（请参阅史蒂夫·克鲁格的 Don’t Make Me Think 一书中的描述）。用户角色是指创建假想用户。例如，如果您的团队成员都是男性，则有必要设计一个 35 岁的女性用户角色（使用用户特征完成），并查看其生成的结果，而不是只查看 10 位 25-40 岁男性的结果。在可用性测试中请真实用户体验您的网站（通过本地或远程方式）并观察他们的反应也可以让您以全新的视角看待问题。
第 24 条规则：衡量模型间的差异。
在向任何用户展示您的新模型之前，您可以进行的最简单（有时也是最有用）的一项衡量是，评估新模型的结果与生产有多大差别。例如，如果您有一项排名任务，则在整个系统中针对一批示例查询运行这两个模型，并查看结果的对称差分有多大（按排名位置加权）。如果差分非常小，那么您无需运行实验，就可以判断不会出现很大变化。如果差分很大，那么您需要确保这种更改可以带来好的结果。查看对称差分较大的查询有助于您了解更改的性质。不过，请确保您的系统是稳定的。确保模型与自身之间的对称差分较低（理想情况下为零）。
第 25 条规则：选择模型时，实用效果比预测能力更重要。
您的模型可能会尝试预测点击率。但归根到底，关键问题在于您用这种预测做什么。如果您使用该预测对文档进行排名，那么最终排名的质量比预测本身更重要。如果您要预测一个文档是垃圾内容的概率，然后选择一个取舍点来确定要阻断的内容，那么允许的内容的精确率更为重要。大多数情况下，这两项应该是一致的：当它们不一致时，带来的优势可能会非常小。因此，如果某种更改可以改善对数损失，但会降低系统的性能，则查找其他特征。当这种情况开始频繁发生时，说明您该重新审视模型的目标了。
第 26 条规则：在衡量的错误中寻找规律，并创建新特征。
假设您看到模型“弄错”了一个训练样本。在分类任务中，这种错误可能是假正例，也可能是假负例。在排名任务中，这种错误可能是假正例和假负例，其中正例的排名比负例的排名低。最重要的是，机器学习系统知道自己弄错了该样本，如果有机会，它会修复该错误。如果您向该模型提供一个允许其修正错误的特征，该模型会尝试使用它。
另一方面，如果您尝试根据系统不会视为错误的样本创建一个特征，该特征将会被系统忽略。例如，假设某人在 Play 应用搜索中搜索“免费游戏”。假设排名靠前的搜索结果中有一个是相关性较低的搞笑应用。因此，您为“搞笑应用”创建了一个特征。但是，如果您要最大限度地增加安装次数，并且用户在搜索免费游戏时安装了搞笑应用，那么“搞笑应用”特征不会达到您想要的效果。
如果模型弄错了您的某些样本，请在当前特征集之外寻找规律。例如，如果系统似乎在降低内容较长的帖子的排名，那么添加帖子长度。不要添加过于具体的特征。如果您要添加帖子长度，请不要试图猜测长度的具体含义，只需添加十多个特征，然后让模型自行处理（请参阅第 21 条规则）。这是实现目标最简单的方式。
第 27 条规则：尝试量化观察到的异常行为。