315      微信

测试__产品简介_推荐引擎-阿里云

集成测试

自定义算法开发完成后，还需要经过集成测试才能正式上线。集成测试是单元测试的延伸，单元测试验证算法内部的逻辑是否达到目的，集成测试则关注把新开发的算法加入算法流程后，整体表现是否有异常。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其实是非常简单的。

最后更新：2016-11-23 16:04:08

  上一篇： 自定义算法开发__产品简介_推荐引擎-阿里云

  下一篇： 运维和运营__产品简介_推荐引擎-阿里云