算法 自动采集列表(集成自定义算法开发完成后，需要经过集成才能正式上线)

　　算法 自动采集列表(集成自定义算法开发完成后，需要经过集成才能正式上线)

　　集成测试

　　自定义算法开发完成后，需要经过集成测试，才能正式上线。集成测试是单元测试的扩展。单元测试验证算法内部的逻辑是否达到其目的，而集成测试则关注新开发的算法加入算法流程后整体性能是否异常。在 RecEng 中用于集成测试的方法是测试路径。

　　客户在RecEng中创建了一个新的算法流程后——姑且称之为F-，F默认处于“未发布”状态，有两个含义：

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

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

　　由于1，离线计算API不会启动未发布的算法流程，所以RecEng在产品界面提供了一个按钮来手动启动未发布的算法流程。离线计算完成后，RecEng会将F的离线计算结果同步到在线存储中。但是由于2，推荐的API无法获得F的计算结果，测试过程的计算结果只能通过RecEng的API调试功能在产品界面中使用。根据以上观察，目前无法通过API的方式访问测试过程的计算结果。

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

　　此外，有时客户可能需要调整发布和上线的算法流程。我们应该做什么？

　　RecEng 实际上为每个已经在线发布的算法流程保存了一个离线测试版本。此时客户只需要修改相应的离线测试版本即可。按照上述流程，先调整算法逻辑，然后手动启动离线计算，然后在API调试中观察计算结果。集成测试通过后，点击“发布”按钮，会提示是否需要覆盖在线数据，即需要使用测试过程的计算结果覆盖之前生产的计算结果过程。客户可根据实际情况自行判断。.

　　效果测试

　　集成测试只能验证自定义算法在算法流程中是否能正常工作；但是，作为一个算法，仅仅能正常工作是不够的，效果才是算法的最终目的。RecEng支持基于算法流程的A/B测试，直接对比最终结果，为决策提供参考。

　　要进行 A/B 测试，您必须首先明确指标；要计算指标，必须先采集日志。下面的描述从日志采集开始。

　　日志采集

　　在衡量推荐系统的有效性时，RecEng 只关心与推荐相关的行为。为了区别于其他无关行为，RecEng会在每个推荐API的返回结果中附加一个Trace ID（推荐API返回的所有项目都共享这个Trace ID），客户需要遵循一定的规范。日志中嵌入了Trace ID，可以使用阿里云推荐引擎提供的效果报告功能。具体嵌入点和日志规范请参考日志嵌入规范

　　埋设Trace ID的三个原则：

　　1.推荐列表显示时，需要在推荐列表中所有item的链接中嵌入对应的Trace ID

　　2. 如果用户点击了收录Trace ID的item链接，需要将Trace ID带到下​​一页，并且Trace ID应该嵌入到新页面的item的所有链接中

　　3. 如果用户点击不收录Trace ID的item，或者点击收录其他Trace ID的item链接，之前的Trace ID将失效

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

　　日志埋没后，通过日志API将日志提交给RecEng，日志采集就完成了。但是日志API的功能不限于上传采集的日志。细心的用户可能会注意到，RecEng的业务配置界面中有一个不显眼的复选框：

　　即客户可以通过日志API上传离线数据。要实现这个功能，一方面需要在产品界面打开这个开关；另一方面，需要从日志 API 上传各种用户和项目数据。与离线上传不同，通过日志API上传用户和商品数据是增量的。您只需每天将新数据发送到 RecEng。

　　如果在业务配置页面勾选了“自动数据预处理”复选框，则当新的一天开始时，将自动启动前一天数据的离线计算任务。

　　业绩报告

　　在 RecEng 中，与效果报告密切相关的三个主要概念是：效果算法、效果指标和效果过程。

　　效果算法专门用于计算效果指标。它的输入输出表是固定的，输入表是行为表（user_behavior），输出表是索引结果表。效果算法的逻辑比较简单，通常是简单的统计，或者在统计的基础上进行四次算术运算。麻烦的是，统计必须有统计口径，包括时间粒度、业务粒度等。

　　RecEng 中的所有这些统计口径都是相同的。时间支持日、周、月三种粒度，业务支持按场景和算法统计。时间粒度的需要取决于效果算法：通常只需要输出当天的索引，而在星期一或每个月的第一天额外输出上周和上个月的索引。如果周指标和月指标的计算没有收录在效果算法中，RecEng会自动补0。 业务粒度的要求由RecEng统一实现：RecEng会根据业务粒度拆分行为表然后交给到效果算法进行计算，

　　效果算法以行为类型为参数，不针对具体的行为类型；效果指标需要明确行为类型。因此，效果指标可以理解为效果算法+行为类型的组合。例如，专门用于PV统计的算法可以统计任何行为、查看、点击和消费的PV。但是说到指标，一定要搞清楚到底是view的PV还是点击的PV。

　　只需要定义效果指数。选择效果算法并阐明行为类型。定义了性能指标后，我们还需要每天执行一次性能过程（index_path）来计算这些指标。效果过程不需要配置算法节点的流程图，只需选择效果指标即可。RecEng会自动生成效果处理流程图，客户可以通过效果计算API启动效果处理。

　　最后是关于性能报告的配置。您只需要为业绩指标选择一个展示图表，如折线图、饼图、条形图等，业绩流程计算完成后，客户可以在业绩报告中看到。

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

　　A/B 测试

　　A/B测试是效果测试的常用方法，也是RecEng唯一的效果测试方法。经过前面的准备，我们现在可以知道每个算法过程的性能指标了。然后，通过比较不同工艺的指标，可以优化效果。

　　RecEng 允许在一个场景中进行多个推荐过程 (rec_path)。对属于同一场景的不同推荐流程也进行 A/B 测试。在进行A/B测试时，同一场景下的每个推荐流程都会分配一定的流量，可以在产品界面进行配置。在执行推荐API时，RecEng会在第一步随机按比例分配流量，将当前用户分配到某个推荐流程，然后执行这个推荐流程的在线流程。RecEng分配流量时，完全是随机的，不遵循任何规则。例如，某个用户必须被分配到某个推荐过程。

　　无论是否开启 A/B 测试，客户调用推荐 API 的参数完全相同。推荐API的参数只收录场景参数，推荐流程（rec_path）不是必须的，也不能指定，以便在进行效果统计时做出明确的推荐。item来自哪个推荐流程，所以RecEng每次响应推荐API都会附上Trace ID，这样我们就可以准确统计每个推荐流程的性能指标。

　　在整个过程中，使用A/B Testing的工作量主要在前期、日志埋点、配置效果报告。完成这些之后，使用 A/B 测试其实很简单。