推荐系统ABTest测试

测试

集成测试

自定义算法开发完成后，还需要经过集成测试才能正式上线。集成测试是单元测试的延伸，单元测试验证算法内部的逻辑是否达到目的，集成测试则关注把新开发的算法加入算法流程后，整体表现是否有异常。RecEng中用于集成测试的手段是测试路径。

客户在RecEng中新建了一个算法流程――不妨称之为F――后，默认F是处于“未发布”状态的，这有两层意思：

1.启动离线计算API时F不会被启动

2.F的计算结果无法被推荐API获取

既然1，未发布的算法流程不会被离线计算API启动，所以RecEng在产品界面上提供了手工启动未发布算法流程的按钮。离线计算完成后，RecEng会将F的离线计算结果同步到在线存储，但是由于2，推荐API是无法获取F的计算结果的，测试流程的计算结果目前只能通过RecEng的API调试功能在产品界面上进行观察，目前还不能支持以API的方式访问测试流程的计算结果。

集成测试通过后，客户需要在产品界面上点击“发布”按钮，将未发布的算法流程发布上线，这样才真正进入了生产，上面说的1和2这两条限制都会被取消掉。

另外，有的时候客户可能需要对发布上线的算法流程进行调整，这时怎么办呢？RecEng为每个已经发布上线的算法流程其实都还保存有一份线下测试版，这时客户只需要修正对应的线下测试版即可，按照上面的过程，先调整算法逻辑，然后手工启动离线计算，

再在API调试中观察计算结果。集成测试通过之后，点击“发布”按钮，这时会提示是否需要覆盖线上数据，意思是需不需要用测试流程的计算结果去覆盖之前的生产流程的计算结果，客户可以根据实际情况自行判断。

效果测试

集成测试只能验证自定义算法在算法流程中是否能够正常工作；然而作为算法，仅仅能够正常工作是不够的，效果才是算法的最终目的。RecEng支持以算法流程为单位的A/B Testing，直接对最终效果进行比较，为决策提供参考。

要进行A/B Testing，必须要先明确指标；要计算指标，首先要采集日志。下文从日志采集开始说明。

日志采集

在度量推荐系统的效果时，RecEng只关心和推荐有关的行为。为了和其他无关的行为区分开来，RecEng在每次推荐API的返回结果中都附带有一个Trace ID（该次推荐API返回的所有物品共享这一个Trace ID），客户需要按照一定的规范把这些Trace ID埋入日志，这样才能利用阿里云推荐引擎提供的效果报表功能，具体埋点和日志的规范细节参见日志埋点规范

Trace ID的埋点有三个原则：

1.在推荐列表展示时，需要把对应的Trace ID埋入推荐列表中所有物品的链接里

2.如果用户点击了包含有Trace ID的物品链接，需要把这个Trace ID带入下一个页面，且要在新页面中所有该物品的链接里都埋入这个Trace ID

3.如果用户点击了不含Trace ID的物品，或点击了包含有其他Trace ID的物品链接，之前的Trace ID失效

要注意的是，不是所有的日志中都会有Trace ID信息，Trace ID只负责对RecEng返回的推荐结果进行跟踪。客户网站或应用中大部分的用户行为可能都和RecEng并没有关系，为了更好的刻画用户画像，这些用户行为也是需要上传到RecEng的。

日志埋点完成之后，把日志通过日志API提交到RecEng，日志采集就算完成了。但日志API的功能可不仅仅只限于上传采集的日志。细心的用户可能会注意到，在RecEng的业务配置界面中，有一个不起眼的复选框：

即客户可以通过日志API实现离线数据上传，要实现这个功能，一方面需要在产品界面上打开这个开关；另一方面各种user、item的数据都需要从日志API传上来。和离线上传不同，通过日志API上传user、item数据是增量方式的，每天只需要把新增的数据发送给RecEng即可。

业务配置页中的“自动数据预处理”复选框如果选中了，那么在新的一天开始的时候，会自动启动对前一天数据的离线计算任务。

效果报表

在RecEng中，与效果报表紧密相关的概念主要有三个：效果算法、效果指标、效果流程。

效果算法专门用于计算效果指标，其输入和输出表都是固定的，输入表是行为表

（user_behavior），输出表则是指标结果表。效果算法的逻辑比较简单，一般就是简单的统计，或者在统计的基础上进行四则运算。麻烦之处在于统计是要有统计口径的，口径包括时间粒度、业务粒度等。

RecEng中所有这些统计口径都是一致的，时间上支持日、周、月三个粒度，业务上支持按场景、按算法流程统计。时间粒度的需求要靠效果算法实现：通常只需要输出当日指标，在周一或每月一号的时候还要额外输出上周、上月的指标。如果效果算法中没有包含对周指标、月指标的计算，RecEng会自动用0填充。业务粒度的需求由RecEng统一实现：RecEng 会将行为表按业务粒度进行拆分之后再交给效果算法去计算，所以效果算法不需要考虑业务粒度的问题。

效果算法以行为类型为参数，不针对具体的行为类型；效果指标则需要明确行为类型。所以效果指标可以理解为效果算法+行为类型的组合。比如专门用于统计PV的效果算法，可以统计任意行为的PV，view，click，consume，都可以；但说到指标的时候一定要明确是view的PV，还是click的PV。

效果指标只需要定义即可，选择一个效果算法，明确行为类型就好了。定义了效果指标，我们还需要每天执行一遍效果流程（index_path），把这些指标算出来。效果流程不需要配置算法节点的流程图，只需要选择效果指标就好了，RecEng会自动生成效果流程的流程图，客户可以通过效果计算API启动效果流程。

最后，是关于效果报表的配置，只需要为效果指标选择一个展示图表就好，比如折线图，饼图，柱状图等。效果流程计算完成后，客户就可以在效果报表中看到了。

RecEng默认提供了一些简单的效果算法，也预先定义了一些效果指标，客户可以根据自己的需求开发新的效果算法，注册到RecEng即可。

A/B Testing

A/B Testing是常见的效果测试方法，也是RecEng唯一的效果测试的手段。经过前面的准备，现在我们可以获知每个算法流程的效果指标，那么，通过比较不同流程的指标，就可以进行效果优化了。

RecEng允许一个场景下存在多条推荐流程（rec_path），A/B Testing也是针对同属于一个场景的不同推荐流程来进行的，在进行A/B Testing时，同一个场景下的每个推荐流程都会被分配一定的流量比例，这个比例是可以在产品界面中配置的。在执行推荐API时，RecEng第一步就会按照比例随机分配流量，把当前用户分配到某个推荐流程中，然后再执行这个推荐流程的在线流程。RecEng在分配流量时是完全随机的，不遵从任何规则，如某个用户一定要分配到某一条推荐流程中这样的规则。

无论是否开启A/B Testing，客户调用推荐API的参数都是完全一致的，推荐API的参数中只包括场景参数，不需要，也不能指定推荐流程（rec_path），为了在进行效果统计时明确推荐的物品来自哪个推荐流程，所以RecEng在每次答复推荐API时会附带Trace ID，这样才能准确的统计出每个推荐流程的效果指标。

纵观整个流程，使用A/B Testing的工作量主要在前期，日志埋点、配置效果报表，完成了这些之后，使用A/B Testing其实是非常简单的。

系统规格

约束

RecEng不限制客户创建业务（biz）的数目。

规模

RecEng的计算能力取决于公共云MaxCompute（原ODPS）集群规模，现阶段RecEng 支持的典型数据规模在百万级别，即百万用户，百万物品。未来公共云MaxCompute扩容后，RecEng可以支持数据量更大的业务，届时会及时更新在本文中。

性能

RecEng提供了丰富的自定义功能，这里列出的是利用RecEng的默认算法构造的典型场景的性能指标，这些指标也可用于客户在开发自定义算法时参考。

?离线计算时间：<=2小时

?在线RT：<=50ms（不含网络传输时间）

?在线qps：>=10000

?实时日志生效时间：<=5分钟

API说明

RecEng提供7个API供客户用于对接，如下：

1.

启动数据预处理任务API：启动离线任务之前需要执行数据预处理任务。数据预处理任务是针对业务的，数据上传完成后整个业务只需要执行一次预处理任务即可

2.

启动离线任务API：客户把离线数据导入输入表完成后，通过本API启动离线计算。本API 是针对场景的，且只能启动场景中已发布的推荐流程。本API执行成功时除了完成离线计算，还负责把离线计算结果导入在线存储

3.

启动效果计算任务API：客户在完成行为数据上传后可以启动效果计算API。要注意的是行为数据必须要符合RecEng的埋点要求，即埋入Trace ID，否则的话计算是不会成功的4.

查询任务状态API：可查询最近一次启动的离线任务和效果计算任务的状态，共有正在运行，计算完成，运行失败三种状态。客户可以根据实际情况自行选择是否使用本API。

5.

在线获取推荐结果API（推荐API）：推荐API集成在终端产品或推荐服务器中，当用户浏览相应页面，如首页或详情页时，可通过推荐API向RecEng请求展示给用户的物品列表。

推荐API是RecEng中最重要的API，通常需要用户ID，物品ID等参数，客户可以根据业务需求增加参数。如推荐O2O服务时，可以增加用户的位置坐标参数，方便进行位置过滤，优先推荐附近的商家或服务提供者。

6.

在线数据更新API：当客户有新物品上架，或老物品下架，希望能够及时体现在推荐物品中，可以通过本API通知RecEng，实时生效。

系统日志采集API（日志API）：日志API用于实时收集用户的行为日志，用于实时修正。

建议每次调用日志API时处理多条日志，压缩后上传，提高性能，节省带宽。通常情况下建议在一次日志API调用中上传100-1000条打包压缩后的日志。日志API除了可以提交日志，客户也可以通过这个API向RecEng提交用户和物品数据，从而可以不再需要离线把数据导入MaxCompute（原ODPS）。

8.

这些API需要客户集成，如前所述，RecEng建议客户端将这些API统一集成在RecEng Client中，通常部署在推荐服务器上。下图展示了一个典型的API集成场景：

图中用不同的颜色表示API的类型。

下方紫色的日志API和红色的数据修正API是实时API，前者用于实时日志采集，后者用于实时修正数据。

?

中间一组蓝色的API（离线数据上传没有API，需要客户自己通过tunnel或DataX工具实现）实现数据上传和离线计算，两个计算跟踪的API是可选的，如果不接入，通过设置告警也能获得任务运行异常信息。

?

?

上方黑色的推荐API是使用频率最高的，也是业务最关注的，用于获取推荐结果。

?

事实上，推荐API和日志API是可以直接从终端对接到RecEng的，但是这样做的话对未来的扩展性不好；而且从图中也能看到，推荐服务器的角色是必不可少的，数据上传，离线计算，以及数据修正都需要在推荐服务器上发起，所以还是那句话，建议客户把所有对RecEng的访问都集中起来，部署在推荐服务器上。

关于默认流程模板的推荐效果

默认流程模板的效果取决于用户行为的丰富程度，如果用户的行为能够很好的反映用户的偏好，默认流程模板的效果会比较好；当用户的行为很少，不能反映用户兴趣时，默认流程模板效果不会理想，甚至于无法给出推荐物品。这有些类似于冷启动的情形，这时需要客户提供默认推荐策略，通常是热门推荐，即向冷启动用户推荐热门物品。RecEng的预置算法中包括热门物品推荐的算法，客户可直接使用。

默认流程模板会根据用户在过去三十天的行为分析用户兴趣，当客户首次接入RecEng时，通常只导入了最近一天的用户行为数据，这时就会出现上述冷启动的情况。客户可以追加补入历史数据，也可等待数据积累，以丰富用户行为，获得更好的推荐结果。

RESTful接口+微服务

转自:闪购网站Gilt从Rails迁移到Scala

从Gilt迁移到Scala以及Paypali迁移到Node.js，我认为原因有两个，这两个代表了现在和未来的一种趋势：

1. Node.js和Play框架倡导的微服务。

微服务这种架构使得维护拓展方便，打破了原来Java和Rails的铁板一块的整体式系统，这种微服务架构特点是RESTful接口+微服务。而传统Java和Rails是一种“MVC+服务"传统架构，为什么“MVC+服务”容易导致铁板一块的系统呢？MVC 是一种面向前端的模式，当你使用这种组合时，你的重点就不免放在MVC的实现上，“服务”变成一种附加的次要的为MVC服务的架构，而轻量的RESTful接口使得我们重点又会到“服务”上，我们可以专注将我们的服务设计成一种微服务。

从可测试角度看，MVC架构因为比RESTful多了一个页面视图，也就是直接绑定了终端页面，或者说绑定了前端页面，这就难于方便进行后端业务逻辑的测试，见要么TDD死，要么后端MVC死，而对RESTful的URL进行测试，或者对微服务进行测试都是非常轻量方便易观察的，不和具体框架绑定，基本都是纯粹业务。

2. Node.js和Play框架倡导的异步Reactive编程。

异步编程最大的特点是吞吐量大，延迟小，因为没有堵塞，这就容易挖掘现有硬件和操作系统等底层系统的潜力，同样的成本投入，异步系统要比传统铁板一块的同步系

统更能应付爆发式涌潮的瞬间大流量。

基于异步的Reactive编程引入事件驱动概念，是一种自发式Reactor，能够将原来在一个请求中完成的繁重工作分发成并行等多任务方式完成，大大提高了系统的可扩展性可伸缩性，当一台服务器硬件已经挖掘到极致，也就是说这种垂直扩展已经完全挖掘了多核CPU的潜力，可以再通过水平扩展假设多台服务器提升整个系统的处理能力。

这种垂直和水平立体式的扩展能力完全颠覆了传统Rails和Java Spring的顺序编程模型，因为顺序编程方式很容易导致同步堵塞式系统，具体可参考：https://www.360docs.net/doc/da11233476.html,/46372，这个贴虽然使用了Node.JS作为异步编程案例说明，同样也适合Scala的Play框架和Akka的异步Reactive编程。

总之，微服务体现了面向对象的细粒度松耦合原则，发挥了设计上的优势；而异步编程则体现面向函数编程的精确能力，发挥了性能上的优势。一个架构如果兼顾设计与性能两者能不是一种优秀的架构吗？