系统的人工分析

在进入第三步之前，学点课堂上没交的东西非常重要：如何维护和提升现有模型。这更像艺术而非技术，而且有很多的坑需要避免。

Rule 23 - 你不是一个典型用户

这也许是团队最容易陷入的泥潭了。让团队或者公司范围内的人来测试（使用）你的系统会是一个好主意。任何看起来还不错的改动都应该用这种方式事先测试一下，要么找外包团队来标注数据，要么用一个线上实验环境引入真实用户。如果是你的话，可能会刻意去找某些帖子，或者干脆感情用事（比如 确认偏差）。另外你的时间也很宝贵。比较一下9个工程师坐那开1小时的会的花费能在外包平台上雇多少人吧。

如果你真想拿到用户反馈，用用户研究的方法。在早期，创建用户画像（在 Bill Buxton 的书Sketching User Experiences中有描述），紧接着做可用性测试（在 Steve Krug的书Don't Make Me Think。用户画像是创造假想用户，比如，如果你团队都是男性，那么创建一个35岁的女性用户画像，然后看看产品这对这个典型用户的产出结果是什么就会挺有帮助的。把真实用户引入到你的站点（本地或远程），也会让你得到一些比较新颖的观点。

Rule 24 - 衡量模型间的差异

最简单并且尝尝很有效的办法之一，就是在用户真正用你的模型之前，和线上效果做一个对比。比如你在解决一个排序的问题，对比一下新老模型在排序最终效果上的差异。如果差异很小，那么你不用做线上实验也知道最终的效果差别不大。如果差异很大，那么做实验去验证这个差异是否一定带来很大的线上收益。查看差异较大的 query 结果，可以让你了解到变更的实际表现。但是要确保系统是稳定的。确保模型和自己比的时候，方差足够小（理想情况是0）。

Rule 25 - 选择模型的时候，关注最终效果而非模型预测效果

你的模型也许尝试预测 CTR（Click Through Rate)。但是最终，关键问题是你如何使用这个预测值。如果你用他来排序，那么最终的排序质量比预测本身更重要。如果你用来检测垃圾消息并且用来做屏蔽，那么放过内容的准确率就更重要。大多数情况下，这两件事情要达成一致（即模型预测目标也系统最终目标）：如果他们不一致，那么收益会很小。因此，如果某些变更使得log loss（交叉熵）变低，但是使得系统整体指标变差，那么就忽略这个变更吧。如果经常性的遇到这种问题，那么调整你模型的优化目标吧。

Rule 26 - 在预测错误的样本中找规律，创造新的特征

假设你在研究一个模型预测错了的样本。在一个分类任务中，这可能是一个 FP（False Positive) 或者 FN(False Negative) 样本。在一个排序人物中，这可能是一个 pair 预测错了排序顺序。重点是这是一个模型知道预测错了的样本，如果你提供了新的特征，模型可能就会用上。 反过来说，如果你再用一个分对了的样本中存在的特征，系统会把他忽略掉。比如在 Play 的 Apps Search 中对于"免费游戏"的搜索。你发现排在前面的都是不太相关的 gag 应用，所以你添加了一个gag 应用的特征。但是，如果你想最大化安装量，而搜索免费游戏的用户也会安装 gag 应用，那么是否是gag应用这个特征对你来说就是没用的。

一旦你拿到了模型分错了的样本，寻找那些目前没在你的特征集合中的趋势。比如如果系统现在对比较长的文章打压较大，那么加入文章长度特征。不要对特征太过细究。不要去详细追求长度的意义，直接加上几个相关特征，然后让模型自己去甄选判断（参见 Rule #21）。这是达成目标最简单的方式。

Rule 27 - 尝试去量化那些可观察到的不符合预期的行为

当一些大家不愿见到的东西存在于系统，但是当前的又没有损失函数去衡量他的时候，一些团队成员可能会开始沮丧了。这个时候，他们应该尽量去量化这些现象。比如，如果他们觉得在 app 搜索时候展现了太多的"gag"应用了，就应该用人肉把gag应用标出来。（你总是可以用上人肉--在这个 case 上是人肉标注，因为出 gag 应用的 query 量相对大盘来说很少）。如果你的问题可以被量化，那么尝试这把他们加入到特征中来。总的规则是：先量化，再优化。

Rule 28 - 注意短期表现不错不代表长期表现也良好

假如你有一个用来预测点击率的新系统，特征是文档 ID 和 query 本身。这个模型可能在历史数据上的离线和 A/B实验都很好，于是因为他很简单，你就上线了。但是你会发现新的 apps 就出不来了。为什么呢？因为系统只依靠 query 中历史出现过的信息做预测，没办法学到新来一个 app 应该怎么办。 想知道系统在长期的表现是否好，唯一的办法就是让他用上线之后的线上真实数据。但这很难实现。

Eric: 在我们的应用当中，线上时效性特征的采集，以及轮展采集样本是越来越重要的工作。