前言
这半个月除了工作上的事，一直忙于学习机器学习基础理论，每天背着四五本书上下班，还蛮有读书时的感觉。之前写了一篇文章，叫 基于用户画像的实时异步化视频推荐系统，应该说只是完成了一个心脏，整个数据集经过心脏的起博，开始流动起来，并且能够对外提供服务。然而此时的系统依然是瞎的，我们不知道它的效果如何，给我们带来了什么收益，会不会出现糟糕的推荐结果，以及我们有没有途径按照自己的想法去调教它。
我们不仅仅希望算法工程师，研发工程师能了解推荐系统的状态，影响推荐系统的效果，我们还希望客户，运营人员也有能力去了解并且影响它。
整个后台由四部分组成：
这个是衡量推荐系统效果的。推荐系统衡量的核心标准是，我给你推荐的，你会不会进行点击。当然，不同场景可能要求是不一样的，比如电商可能核心的效果是购买转化率。以点击曝光转化率为例，我们会计算每个五分钟的值，从而形成一个点击转化率曲线，可以看到趋势。点击转化率是如何计算的呢？点击转换率通常是针对一个推荐位而言的，当然我们也可以计算总的效果。
除了这个，比较重要的还有 用户转化率。另外，我们知道，一个页面假设是一个城市，每一个栏目块就像一个商圈了。不同商圈的流量差异是比较大的，有一个指标叫 曝光推荐转化率 可以衡量是不是有异常情况发生，比如在一个热门的城市，接口请求量可能特别大，但是发现曝光率却很小，那么可能是这个推荐位落在了一个流量非常小的商圈里，比如可能在页面某个疙瘩处。这个指标可以帮助我们校正产品的一些问题。否则流量那么小，你推荐效果再好，也起不到太大作用。
如果我们只推热门的视频，转化率肯定应该是不错的。然而互联网的一个典型情况是，长尾视频的流量之和可能大于一些热门的视频流量之和。当然这个结论目前我也没有数据去证实，搜搜的一个LDA 系统(peacock)，说是能覆盖百万的主题，长尾的搜索词产生的流量其实大于一些热门搜索词的流量之和的，我想这个应该是可以顺延到很多场景中。
既然是千人千面的推荐，也就是大致大家看到的都是自己喜欢的，重叠度理论上不应该太高。这个时候说明我们的推荐出去的视频要覆盖相当一部分媒资里的视频。我们做了一个新的指标定义：
推荐系统应该是个可以由运营人员来tunning的一个系统。我们将推荐算法，程序计算周期等各种参数暴露给到后台，抽象成元信息管理。通过调整这些参数，我们不但可以让算法研发去调整，还可以让运营充分利用自己的经验，还有结合我们前面各种转化率指标，覆盖率指标，制定更加合理的规则。
比较典型的是，各个候选集的大小，用户私有队列的大小以及生存周期，每个算法的每次请求可吐出的数据的数量等。
另外在该界面，你可以做数据探索，获得包括一个视频的访问人数或者一个用户的访问轨迹等。这个主要是我们会将用户行为存储到ES里，借助ES-SQL和Spark-SQL我们可以做非常大规模的探索式查询。
按之前在基于用户画像的实时异步化视频推荐系统的描述，其实我们推荐系统分成了三大部分：
后台的开发成本其实远远高于推荐系统对外的功能。考验我们对推荐系统有更好的理解和抽象能力。
这半个月除了工作上的事，一直忙于学习机器学习基础理论，每天背着四五本书上下班，还蛮有读书时的感觉。之前写了一篇文章，叫 基于用户画像的实时异步化视频推荐系统，应该说只是完成了一个心脏，整个数据集经过心脏的起博，开始流动起来，并且能够对外提供服务。然而此时的系统依然是瞎的，我们不知道它的效果如何，给我们带来了什么收益，会不会出现糟糕的推荐结果，以及我们有没有途径按照自己的想法去调教它。
我们不仅仅希望算法工程师，研发工程师能了解推荐系统的状态，影响推荐系统的效果，我们还希望客户，运营人员也有能力去了解并且影响它。
所以一个强大的推荐系统后台是极其重要的，如果没有他，真个推荐系统就是一个瞎子，并且是不受控制的。
整个后台由四部分组成：
- 转化率指标
- 覆盖率指标
- 元信息管理
- 系统状态监控
这四个模块分别是解决什么问题的呢？
这个是衡量推荐系统效果的。推荐系统衡量的核心标准是，我给你推荐的，你会不会进行点击。当然，不同场景可能要求是不一样的，比如电商可能核心的效果是购买转化率。以点击曝光转化率为例，我们会计算每个五分钟的值，从而形成一个点击转化率曲线，可以看到趋势。点击转化率是如何计算的呢？点击转换率通常是针对一个推荐位而言的，当然我们也可以计算总的效果。
- 点击曝光转化率 = 一个统计时间区间内,点击数/曝光次数
- 曝光次数 = 一个统计时间区间内，视频被曝光的次数
- 点击数 = 一个统计时间区间内,视频被点击的次数
除了这个，比较重要的还有 用户转化率。另外，我们知道，一个页面假设是一个城市，每一个栏目块就像一个商圈了。不同商圈的流量差异是比较大的，有一个指标叫 曝光推荐转化率 可以衡量是不是有异常情况发生，比如在一个热门的城市，接口请求量可能特别大，但是发现曝光率却很小，那么可能是这个推荐位落在了一个流量非常小的商圈里，比如可能在页面某个疙瘩处。这个指标可以帮助我们校正产品的一些问题。否则流量那么小，你推荐效果再好，也起不到太大作用。
- 曝光推荐转化率 = 一个统计时间区间内，视频曝光次数/视频推荐数次数
其中食品推荐数来源接口层的日志。
如果我们只推热门的视频，转化率肯定应该是不错的。然而互联网的一个典型情况是，长尾视频的流量之和可能大于一些热门的视频流量之和。当然这个结论目前我也没有数据去证实，搜搜的一个LDA 系统(peacock)，说是能覆盖百万的主题，长尾的搜索词产生的流量其实大于一些热门搜索词的流量之和的，我想这个应该是可以顺延到很多场景中。
既然是千人千面的推荐，也就是大致大家看到的都是自己喜欢的，重叠度理论上不应该太高。这个时候说明我们的推荐出去的视频要覆盖相当一部分媒资里的视频。我们做了一个新的指标定义：
- 推荐覆盖率 = 一个统计时间区间内,总推荐视频数/总视频数
此外还有曝光覆盖率等指标，新视频覆盖率，用户覆盖率等各种指标。
推荐系统应该是个可以由运营人员来tunning的一个系统。我们将推荐算法，程序计算周期等各种参数暴露给到后台，抽象成元信息管理。通过调整这些参数，我们不但可以让算法研发去调整，还可以让运营充分利用自己的经验，还有结合我们前面各种转化率指标，覆盖率指标，制定更加合理的规则。
比较典型的是，各个候选集的大小，用户私有队列的大小以及生存周期，每个算法的每次请求可吐出的数据的数量等。
另外在该界面，你可以做数据探索，获得包括一个视频的访问人数或者一个用户的访问轨迹等。这个主要是我们会将用户行为存储到ES里，借助ES-SQL和Spark-SQL我们可以做非常大规模的探索式查询。
以前我也不相信一个推荐系统是可以tunning的，他应该完全依赖于研发和算法工程师。但是之前和一个做搜索的人接触，他在美国两家知名的搜索服务提供商工作过，对方的搜索系统抽象做的非常好，售后支持可以无需通过编程，和客户一起当场tunning搜索结果，直到客户满意。推荐系统也是一个高度成熟和经过实践的系统，能做到和我刚刚描述的那样，算是一个较高的境界了吧。
按之前在基于用户画像的实时异步化视频推荐系统的描述，其实我们推荐系统分成了三大部分：
- 计算/推荐引擎，由众多的spark 批处理和流式任务组成，也包括一些存储引擎，包括HDFS,ElasticSearch,HBase,Redis Cluster(其实是Codis)等。
- API服务，单独的无状态可实现负载均衡的接口服务。主要功能是操作Redis队列。
- 后台服务。后台服务包括前面的两个指标体系，一个原信息管理，还有就是这个系统状态监控。其实还有一个，就是一个模拟服务，在该页面上你可以看到一个推荐位，并且选定一个虚拟用户，你的包括点击行为都会在该页面看得到。包括短期兴趣模型等实施的变化情况。
在后台，我们还可以看到计算/推荐引擎的工作状态是不是正常。这个主要针对 计算/推荐引擎模块。以为这些模块是有若干个逻辑上有依赖的任务组成，我们可以在后台的系统状态监控模块看到这些任务是不是都按预期的运行了。并且结合前面的指标体系，我们也能看出 API服务是不是正常的服务。
后台的开发成本其实远远高于推荐系统对外的功能。考验我们对推荐系统有更好的理解和抽象能力。
