今日头条算法构架师：3亿用户每天的头条各不一样，靠数据是怎么做到的？

什么是数据思维，对数据思维概括最简练有力的一个说法，来源于今日头条创始人张一鸣：第一收集数据，第二作出决策，最后是高效执行。

今日头条的个性化推荐不靠人、靠技术

推荐时会兼顾用户、环境和文章本身特征

相比微信公众号，头条是更好的自媒体平台

今日头条是国内领先的新闻客户端，最大的特点是个性化推荐，真正的千人千面。我们现在有3亿的积累用户，日活用户超过三千万。我们不靠编辑人工推荐，而是技术算法。

大家有兴趣，头条是怎么推荐内容的？举个简单的例子，头条在给用户找一篇你可能喜欢的新闻的时候，他会考虑三方面的因素：

1

第一，用户特征，比如兴趣，职业，年龄，短期的点击行为。

2

第二，环境的特征。推荐是一个情景化的事。比如我自己早上，会看一看科技新闻。周末晚上会看搞笑视频。还有网络环境，你要有wifi的话，给你多推视频。

3

另外就是文章自身的特征，它有哪些主题词，命中了哪些标签，还有它的热度，是不是很多家媒体都转载了。包括文章时效性和相似文章推荐。

接下来五到十年的一个愿景，成为最懂你的信息平台，连接人与信息，促进创作和交流。

在开始一两年，我们对创作这块重视不够，也是资源不够，没有形成自己的壁垒。但是从14年版权风波之后，我们在这块投入的非常大的资源和精力。

今日头条的自媒体平台已经是国内互联网第二大的自媒体平台。它的增长速度要快于微信公众平台。

为什么呢？大家可能都有微信公众号，可能有这种体会，你在微信上做一个公众号，微信是不会帮你推广的。你要靠自己的资源，靠自己的人脉进行推广。

比如我专注于写历史故事的，我没有那个资源，我没有那个商业能力，他可能还在三线城市，怎么去推广？

头条希望最好的内容到达最适合的受众，我们有个系统帮你自动推荐，点击量多了我们还会给你钱。没有听说微信公众号还会给自媒体钱的。

归纳总结、A/B测试、双盲交叉验证

数据思维的三大工具

灵活交叉运用

介绍完头条，下面介绍一些案例，我先介绍数据思维几个比较重要的工具：

第一个工具是归纳总结，按照特定的维度进行排序，分析对象特性。这个可能反映出事物内在的一些规律，基于这个分析，去引导决策。

第二个叫A/B测试，把实验对象随机分组，把一个或多个测试组的表现与对照组比较，进行测试。

怎么做A/B测试，第一步我们线上流量进行分流，正常用户还是走正常的流量，一部分流量我们要保证样本无偏（不要样本全是女的或者全是90后），通过科学方法去划分出一些流量做实验，还要进行分组，分出对照组和实践组，对照组和线上的策略完全一样，实验组我们做一些小小的改变。

比如头条网页版的首页，新版加了一个链接，老版加了一个任务评论。我们看哪个好呢？通过A/B测试的方式，一部分人看到新版的结果，一部分是老版效果。事后统计分析，看到底哪个版本效果好。

第三个叫做双盲交叉验证。它是说在评估一项数据的时候，我可以把一部分样本抽样，让其他人再评估一下。根据抽样数据评估的一致性来判断该评估的可靠性怎么样，比如你审一些黄色反动的文章，机器做得再好，必须有人来把关。

这个事本身判断特别复杂，机器也不能做好，我们要保证评估的有效性，要引入争议复评机制。

今日头条从一诞生就有数据基因

到底取什么名字？

让数据来说话，用户来选择

头条的诞生怎么体现出浓浓数据思维的？一开始就有。大家都肯定经历过这种场景，APP怎么起名字。起名字的方法很多种：言简意赅琅琅上口，或者拟声，或者情怀。

头条面临几个问题，我们名字是哪种范儿？我们用了数据思维的工具，归纳总结。去苹果商店找各个免费榜单的前十名APP，做了一个归类，发现琅琅上口好记的名字，是最多的。

从当时的效果来看，大白话更好。我们调性已经定了，我们就要土，没情怀，比如一个初中文化的用户都能看懂。

我们列了几个名字，没有人敢打赌哪个更好，我们做个A/B测试吧。我们要选两个渠道，发现这些APP在这两个渠道上留存都差不多，花的钱差不多。

我拿这两个渠道做实验，选两个名字或者选N个渠道，N个名字，分别投放。这个界面功能都完全一样，就是名字不一样，就是用户看到在外面的列表名字不一样。

我们看哪个留存高，相应的变成了哪个名字的单位获取用户成本低，这是一个最重要的，最后发现今日头条是表现最好的。

数据思维怎么指导算法演化？

大的推荐模型和推荐找回模型交叉运用

很多因素都会影响推荐效果

刚才讲了我们头条的诞生是怎么运用这个数据思维的。接下来可能会更硬一点，这是我的老本行，怎么用数据思维去指导算法的演化。

我们先简单看一下头条的推荐算法，头条最核心的是怎么利用这些数据。怎么提升呢？不断改进我的算法，让它更聪明，更好利用这些数据。头条算法是一个非常庞大复杂的算法策略的组合。我们需要把这个系统的演化放在可控的情况下，让它不断朝着优化的方向去演化。

头条的推荐算法分两层。最上面一层，一个大的推荐模型，就是说模型做决策依据的维度，包括性别、年龄、兴趣等都是维度，我们有数百亿特征，涵盖你能想到的一切可以帮助做判断的信息，这个还在不断的增加，

还有一层就是推荐召回模型，他是干什么的呢？上面那个模型特别强大，但是它的计算资源也很大，成本结构压力也会非常大，不要所有的事情都让这个模型去做。

所以有一个召回模型，各个策略独立的负责判断哪些内容有资格进入排序侯选。比如判断这个文章的来源是不是我喜欢的，这个人是不是总爱看虎嗅的文章，就推荐虎嗅的。有的更简单，就看性别、年龄。这个模型可以过滤掉90%的无效信息，最上面推荐模型的负担就降下来了。

在这个系统中，对推荐效果造成影响的因素有哪些呢？

第一是候选内容集合的变化。

因为头条最早我们是只推荐正规的新闻，不敢推短时效的东西，怕推不好，有时候文本看不太出来，但实际上这个事可能是过气了。

现在，我们希望我们能推一些天气预报预警。还有一些生活有用信息，比如家装。这些东西都推的话，有可能给线上的体验带来改变，这个改变有可能是正向的，有可能是负向的。它是不是好呢，我们要试了才知道。

第二个是召回模块的改进和增加。

有些事拿不准，让高级的人去判研一下。另外一个是增加人手。

还有一个是推荐特征的增加。

刚才讲到我们有几百亿特征了，可能涵盖了目前能想到的对推荐有影响的所有的因素。但是是不是穷尽呢？这肯定是没有穷尽的，加进去好不好呢？也不一定，让系统复杂性变高了。计算机算要花时间的，一秒钟过去了，都没算出来，用户体验可能变差。

另外就是规则策略，所有的线上产品涉及到机器学习的，大数据的，不可能完全用模型解决，要有人干预的。

最好有一个沟通机制，实验太多了，我们需要高效的管理和分配流量。

还有特殊的过滤条件，有的人说你不能随机给我流量，我就是看女性用户变化的。

这个是我们实际的A/B测试系统的工作流程，非常直观。首先我们会把流量进行分桶，我们降低系统的复杂性。如果你每次要考虑三亿用户怎么分，复杂度太高了。

然后就是实验分组，这些桶还分两组，有实验组和测试组，像这个就是四个桶分了，黄色的是对照组，绿色的你把改进在绿色的用户身上可以起到效果。

这个PPT就是讲了我们这个数据实验是怎么分析的，先把数据拿过来，再做日志处理，存到日志，发到服务端，我们会有一个分布式的文件系统，保证这个东西不丢。

结果出来之后，我们写入数据库，我们需要一个很好的数据可视化的系统，因为你都出来数字，大家看着也不方便。给产品经理给高层老板看一堆数字很烦，就看曲线就行了。

快速迭代，但怎么保证方向正确？

用数据实验，去测试需求

数据思维可以帮你把每一项能力发挥到极致

头条从上线以来，经历了几十个版本的更新。产品的发展肯定要不断迭代的，我们怎么让迭代快，而且朝着正确的方向走呢？这是一个很大的问题。

大家都知道需求从哪来，有一类的需求其实很简单，我们叫战略需求。以我们头条自己来说，我们最终要实现一切都可以推荐。

第二件事叫确定性需求。这是常识。不能卡，用户用低端的机器也能很流畅的跑。省流量，还有记录更精细的用户动作。

剩下的需求从哪里来？其实就是怎么把提高用户粘性，提高用户体验，怎么提炼出更多具体的需求，去支撑上面的这个战略。头条收集剩下需求，最重要的一个方向就是从用户反馈中去收集。

有一个专门的用户反馈组，会选一些非常有产品想法的年轻人，不断和用户做沟通。

用户有可能提出一个新的东西，不在你原来的需求列表里。你改变之后是不是伤害了那些不反馈的用户呢？不知的，只能做实验的需求池。

我们产品每个需求都要做A/B测试，移动客户端有两类，一类是原生的功能，这个实现起来成本比较高，另一类是WAP需求，这些页面的改动不用发版，效率会更高。

我们说前者，第一我们会发小渠道的版本测试，比如特别小的应用市场，我们先放上去，跟老版本比比，看看效果怎么样。如果没有大问题，因为这种小流量你是测不出来精确改变的，你保证不要出错。如果说波动正负1之间，这个东西可能有用，我们现在大流量的试一下。

大渠道发版A/B测，像360助手我们统一发一版，我们通过客户端自己的代码来调整。从应用市场提交同一个版本，用户下载之后，通过远程控制，让每个人看到的界面是不一样的。

这边有一个典型的例子，其实现在视频推荐是有两种界面。一种是有赞有踩有评论，另一种我们更强调视频的PC作者，我们希望给他导更多的流量，刺激他的订阅。

我们对比这两种哪个效果更好，这些都是客户端实现的，远程一键可以让这些用户全部从左边换到右边。

这个是成本比较高的，因为相当于客户端要实现不同的素材，不同的代码。会影响你的下载和转化率，因为流量还是比较敏感的。一个11兆的东西和19兆的东西，转化率会非常不一样。

我们尽量用下面这个方法：直接去改WAP页面，比如头条的详情页，你点一篇文章进去了，下面评论是用客户端原生实现的，中间文章那一段只是一个页面而已，你可以灵活在里面调样式。

这种改进比较简单了。让用户到功能入口，看到的页面是不一样的。

有了实验的结论，这个页面改动很好，我们切入到全流量，让所有的用户都能看到这个页面。

我们总结一下WAP页的优势和劣势，优势是开发试错成本低，比发版简单的多，很好改，一旦发现问题，直接把页面换掉就好了。劣势也很简单，流畅度稍差，H5大家一直在说，但实际上大家都明白它的性能和原生的还是有差距。

第二WAP和客户端通信比较复杂，有些很高级的交互H5是做不了的。另外缓存失效后体验不好。

这是我们典型的一个case，这应该是一个反面的例子。我们很早期还没有大规模启用客户端的A/B测试，拍脑袋作出一个决策。头条有一个频道栏，除了推荐首页之外，把科技、体育、视频这些内容分门别类标签，你想看科技新闻，到科技里面去。

这些分门别类的标签这里面的内容也是个性化的，比如科技新闻，有的看O2O，有的看数码产品。大家觉得有这个标签，这个界面会比较乱，不好看。我们能不能做的更好看一点呢，我把这个东西去掉，下面有四个按钮，“推荐”第一个按钮，单独用一个“发现”，这个不是当时最终原型，“发现”里面放各种各样的频道。

如果你想随便看看，就到第一个里面看，今天就想特别看体育新闻，你给我推荐的体育新闻还不够多，我就到第二个里面看。

结果教训是非常惨痛的，用户的留存和用户频道的DEU都下降非常多。这算一个产品事故。如果我们有足够的能量做客户端的A/B测试，我们可以把影响放到最小，就不会造成那么大的损失，产品经理也不会走，这就是一个惨痛的教训。

我们看一下交叉验证在头条是怎么实现的。交叉验证用的最多的场景涉及到人工运营的场景，在头条刚才提到有些业务需要人工的评估。因为你文章如果分类分不准的话，可能就会影响你的推荐。有很多东西要人去审的，审核和评估都有一个问题，什么问题呢？它依赖人。

大家印象中人比机器靠谱的，从大的面上来说，机器比人更靠谱，机器不求回报。在互联网公司，审核和评估投入这块肯定比工程师低很多，这就造成两个后果，第一个就是审核人员敬业或者他的能力上可能跟工程师相比，他会有一定的差距，这是客观存在的。因为我们的人力成本也比较低。

第二个就是他的流动性可能比较大，另外标准经常变来变去。我们一定要用机器去监控人的工作怎么样，需要有一个预警。这块我们需要引入一个双盲的交叉验证，帮助我们去看这些运营同学他们工作的稳定性怎么样，同时去激励不断提升自己的判断力，得到机器更好的评估。

最后再强调一下，为什么创业者运用这个数据思维是如此重要，张一鸣说，初创公司产品的核心竞争力是一个乘积能力，产品核心竞争力=拉新能力×留存能力×变现能力。数据思维就是可以帮助团队把每一项能力发挥到极致，增加了生存下来的概率。