311      微软  windows

全流程规范__产品简介_推荐引擎-阿里云

前面已经提到，全流程规范化是RecEng实现客户自定义功能的基础。

日志埋点规范

环境准备好之后，最重要的对接工作接入客户日志，即让客户的日志满足RecEng的日志埋点规范。日志埋点规范定义客户终端产品需要采集的内容，以及实时上报日志的格式要求。RecEng支持两条日志上报通道，实时上报和离线上报。实时上报通过Restful API提交，离线上报按照数据格式规范的格式提交到MaxCompute（原ODPS）。日志埋点规范包括通过Restful接口提交的日志格式，不包括MaxCompute上离线日志表的格式。

一般情况下要遵从RecEng的日志埋点规范需要升级客户的终端产品，但在客户已有推荐服务的情况下可以暂不进行终端升级，详见下面的说明。

日志埋点规范包括内容和格式两方面的要求。RecEng将用户行为分为三类，第一类是交易行为，即用户的这类行为能够给网站或APP，也就是RecEng的客户带来收益的行为。对电商来说，交易行为是商品购买；对音乐或视频类网站来说，交易行为是音乐或视频的播放或下载。

第二类行为称作准备行为，它们虽然不能直接给网站带来收益，但是这些行为是实现交易的必要前提，比如用户对物品的浏览、点击、搜索、收藏等。客户需要区分这些行为，因为不同行为对交易的影响是不同的，细粒度的区分有助于更好的分析用户兴趣，达到更好的推荐效果。

第三类是与交易无关的行为，比如用户在网站上点击了其他网站的广告，跑掉了，这类行为RecEng不关注。

日志埋点规范在内容方面要求客户记录交易行为和准备行为，并且在记录用户行为日志时区分开这两种行为。和通常的日志一样，日志埋点规范也要求记录行为发生的一些上下文参数，比如时间，用户，物品等信息。此外为了便于计算由推荐服务带来的转换率，日志埋点规范要求客户记录traceid。traceid将用户在推荐坑位的点击与最终成交关联起来，用于判断成交是否是由推荐服务带来的。traceid由RecEng在返回实时返回推荐结果时返回，细节详见日志埋点规范。

客户如果不按照日志埋点规范记录traceid，唯一的影响是不能使用RecEng提供的效果报表功能，不影响推荐业务的正常使用。

如前所述，客户如果不在意效果报表，且之前已有推荐服务正在运行，且日志内容满足日志埋点规范的要求，可以在现有的推荐服务器上对日志遵照日志埋点规范进行格式转换，暂不升级终端产品，快速体验RecEng。

数据格式规范

数据格式规范定义了离线和在线计算所使用时的数据格式，其中离线数据的格式相对复杂一些，在线数据的格式相对简单。

离线数据规范

RecEng中，离线流程（rec_path->offline_flow）和效果流程（index_path）都是在离线计算的，离线数据规范中定义了这两类流程的数据规范。一般情况下，离线计算的输入和输出都是MaxCompute（原ODPS）表，所以离线数据规范其实上是一组MaxCompute表的格式规范，包括接入数据、中间数据和输出数据三类数据的格式规范。

接入数据指客户离线提供的用户、物品、日志等数据，RecEng最关注的是日志数据，其次是物品数据，最后是用户数据。日志数据离线和在线基本上一致，日志埋点规范中已有说明，参见规范的详细定义即可。物品数据由类别、属性和关键字几部分组成，其中类别和关键字含义明确，都很好理解；属性是多值字段，按key-value格式组织，如果有多个属性，都在属性字段里按照规范格式列出即可。RecEng要求这三个字段不全为空。

用户数据类似，有一个叫做tags的多值字段，同样按照key-value格式组织，和物品数据的属性字段不同的是，tags字段可以为空。

为了让RecEng了解物品的属性字段和用户的tags字段中各个key-value的数据类型，客户还需要补充两张数据结构说明表，分别解释物品的属性字段中每个key-value的数据类型，以及用户的tags字段中每个key-value的数据类型。当客户提供的物品数据、用户数据的内容没有变化时，这两张表可以一直沿用。

如果客户要自定义离线算法，需要了解中间和输出数据格式规范。RecEng定义了十多张离线MaxCompute（原ODPS）表的格式，涵盖离线流程和效果流程中所有用到的接入表、中间表和输出表，这些表被统称为标准表。所有离线计算的算法都必须以标准表作为输入输出表；对于效果流程中的算法，还需要将计算结果输出到RDS中，方便实时展示。

在线数据规范

RecEng的在线计算包括在线流程（rec_path->online_flow），以及实时修正流程（mod_path）两部分。

不像离线算法，天然以MaxCompute（原ODPS）表作为输入和输出，在线程序的输入数据可以来自多个数据源，如在线的表格存储（原OTS），以及用户的API请求，又或者是程序中的变量；输出可以是程序变量，或者写回在线存储，或者返回给用户。

出于安全性考虑，RecEng提供了一组SDK供客户自定义在线代码读写在线存储（Table Store），不允许直接访问，所以需要定义每类在线存储的别名和格式。

对于需要频繁使用的在线数据，无论其来自在线存储还是用户的API请求，RecEng会预先读好，保存在在线程序的变量中，客户自定义代码可以直接读写这些变量中的数据。

综上，在线数据规范定义的是在线程序所使用的数据集的规范。这里的数据集是一个抽象的概念，可以是在线存储中的表的格式规范，也可以是在线程序中某个全局或局部变量的结构定义，称之为标准数据集。规范会定义各个标准数据集的可读写性，当客户自定义程序违背了读写性要求时，将无法通过代码审查，不能上线。

算法规范

在RecEng中，算法是把数据串接起来的逻辑。这里的数据指离线的标准表，或在线的标准数据集。算法除了输入输出数据之外，通常还会包括一系列参数，RecEng的算法模型如下图所示：

更确切的说，输入数据指的是算法需要处理的信息，输出数据是算法处理后的结果，而参数，则是算法为了在不同的输入数据上都能取得比较好的效果而提供的一组可供算法使用者调整的开关。从面向对象的角度看，如果我们把算法看成对象，那么算法参数是算法本身的属性，而输入输出数据则定义了算法的接口。

为了简化算法流程的定义，RecEng要求每个算法只能有一份输出数据，不限制输入数据的数目。

所谓符合RecEng规范的算法，就是以这些标准表或标准数据集作为输入输出数据的算法。具有完全相同的输入数据、输出数据的算法是同类算法，RecEng定义了一组常用的算法类别，能满足大部分需求，未来还允许客户自定义算法类别。RecEng的算法规范，指的就是上面的算法模型，以及这一组算法类别。

RecEng只要求同类算法具有相同的输入输出数据，即接口相同；不要求同类算法的参数相同，参数是算法的内部属性，RecEng算法规范对此不做要求。

客户在自定义算法时可以把算法参数注册到RecEng中，在使用自定义算法时RecEng会自动将这些自定义参数展示出来，方便客户调整。

RecEng不设算法版本的概念，如果要升级现有算法，RecEng的方法是把新版本的算法注册为新算法，注册之后就可以使用。老版本的算法可以在无人使用后下线。目前在删除算法时还不能提示算法是否正在被使用，正式上线的版本会完善这些功能。

算法流程

在概念解释一节中大致介绍了算法流程的概念，包括两种流程，推荐流程（rec_path）和实时修正流程（mod_path），本节进一步介绍这些流程的技术细节。算法流程中使用的数据和算法遵从数据格式规范和算法规范。

RecEng中的算法流程

RecEng中的算法流程是一个有向无环图，图中节点为算法，算法A到算法B的边则表明算法A的输出是算法B的输入。由于算法规范要求每个算法只有一份输出数据，所以算法流程图中可以不标明数据节点。

RecEng提供可视化界面用来编辑这个有向无环图，这个过程就是自定义算法流程。RecEng还预先实现了一组相对标准的推荐算法供客户使用，若客户觉得系统提供的这些算法不满足需求，可以遵循算法规范自行开发，并注册到RecEng即可使用。

RecEng中的算法流程包括离线流程（rec_path->offline_flow）、在线流程（rec_path->online_flow）、数据修正流程（data_mod_path），和用户修正流程（user_mod_path），这些算法流程都支持客户自定义，即支持通过可视化界面来编辑算法流程的有向无环图。

在RecEng中还包括一个效果流程（index_path），和上面几个算法流程不同，客户在定义效果流程时只需要选择效果指标即可，RecEng会自动根据客户选择的指标生成算法流程，不需要通过可视化界面进行编辑。

在RecEng中，推荐流程（rec_path）属于场景（scn），客户可在场景下新建推荐流程，每个推荐流程由离线流程（offline_flow）和在线流程（online_flow）组成，是相对独立的两个部分。所以每个rec_path由两个有向无环图组成。

实时修正流程（mod_path）则属于业务，两类mod_path各自最多只有一个实例，所以每个业务下最多只有两个实时修正流程的有向无环图。

考虑到实际实现的一些因果关系，下面的介绍按照离线流程（rec_path->offline_flow），实时修正流程（mod_path），在线流程（rec_path->online_flow）的顺序进行，即在介绍推荐流程（rec_path）的中间插入了实时修正流程（mod_path）。

离线流程（rec_path -> offline_flow）

离线流程整体示意图：

上图，以及本节各流程图元素说明：

• 橘黄色双曲边矩形表示接入数据表
• 黄色双曲边矩形表示中间数据表
• 蓝色双曲边矩形表示输出数据表
• 蓝色单曲边矩形表示输出模型
• 青色方框表示计算逻辑

离线流程从用户输入的用户、物品、日志数据开始，经过简单的处理后生成用户/物品的原始特征，接下来是推荐的核心算法，计算用户和物品的关系，生成用户/物品耦合特征。所谓耦合特征，指包含了用户对物品兴趣的特征，即利用耦合特征可以计算出用户对每个物品的兴趣偏好。接下来就是计算用户的候选推荐集合，以及物品的相似物品集合。

对于一般的客户，可被推荐物品不是特别多，到这里基本上就可以了，也就是左边蓝色虚线框内的基本推荐流程。基本推荐流程通过分析用户行为，给用户展示其最感兴趣的物品，即兴趣是其优化的目标。

如果客户可被推荐的物品非常多，或者客户的优化目标不是用户对物品的兴趣，而是其他指标，比如转换率，成交金额等，可以引入右侧红色虚线框中的排序建模流程，针对优化目标建立起每个用户的模型，并基于此生成推荐候选集。

排序建模流程需要的样本从用户日志中根据优化目标抽取，排序模型方面目前RecEng只提供了基于Logistic Regression的Learning to Rank模型，未来会加入更多的排序模型，如曾经在聚划算导购业务中大放异彩的biLinear模型等。

最终，offline_flow的所有计算结果会被导入在线存储，保存在离线计算结果表中。

实时修正流程（mod_path）

mod_path整体流程示意图：

mod_path由两个并列的流程，数据修正流程（data_mod_path）和用户修正流程（user_mod_path）组成。

客户将需要更新的实时输入，如新上线物品，或已下线物品通过数据修正API提交到数据修正线程，数据修正流程将这些信息保存到在线存储中，供在线流程（rec_path->online_flow）使用。

客户还可以通过实时日志，在用户信息修正线程中实时分析用户的感兴趣物品和不感兴趣物品，优化推荐效果。目前由于在线程序都由Node.js编写，在线学习能力较弱，未来会引入专门的实时计算平台，届时可以实现真正意义上的online training。

实时修正流程都是可选的，最终产出的结果供在线流程（rec_path->online_flow）在响应用户的推荐请求时使用。

每个实时流程，包括实时修正流程（mod_path）和下文的在线流程（online_flow），都工作在独立的线程中，只不过有的线程是后台定时线程（如用户修正流程，不断轮询实时日志），有的线程是事件触发线程（如数据修正流程，当有API请求时才会工作，处理完成就结束了）。RecEng将每个实时处理线程都分成了三个阶段，如下图所示：

参数解析阶段负责读取和解析处理时需要用到的参数，包括API传入的参数，实时日志，系统配置等；执行处理阶段是实时处理流程的核心，负责实现实时流程的业务；输出阶段则把实时流程处理的结果输出出去，可以是在线存储，也可以以返回给用户。几个阶段之间的参数传递由在线数据规范定义，图中以CTX（上下文环境变量）代表，下一节中的CTX含义与此相同。

为简化客户自定义开发，聚焦业务，以上三个阶段中，RecEng只允许客户自定义第二阶段的程序，参数和输出的工作都由RecEng承担，这也提高了系统的安全性。

在线流程（rec_path -> online_flow）

online_flow负责响应来自终端产品（用户）的推荐API请求，图中“表格存储（原OTS）离线计算结果表”正是offline_flow的最终输出，属于不同rec_path的offline_flow产出的表格存储离线计算结果表不同，online_flow以这种方式和offline_flow一起组成rec_path。

在推荐处理线程的参数解析阶段，除了读取参数，RecEng还做了这么几件事：

1. 检查请求是否来自测试用户，并记录在CTX（上下文环境变量）中。测试用户指访问测试路径的用户，详见“测试”一节中关于“测试路径”的说明。

2. 对有A/B Testing需求的场景，根据客户的A/B Testing流量配置分配rec_path，并记录在CTX中

3. 从离线计算结果表中读取当前用户的相关数据，包括用户特征，推荐候选集；如果API请求参数中包括物品id，那么把与该物品相似的物品也都读取出来

在执行处理阶段，客户自定义算法从CTX中获取RecEng预先读好的数据，判断当前对应的rec_path，选择相应的算法进行处理，通常是对离线计算结果进行过滤和排序；如果客户定制了实时修正，在这个过程中可以利用实时修正的结果进行计算，并将最终结果写回CTX。返回阶段的代码将客户自定义算法处理结果返回给请求用户，完成推荐。

效果流程（index_path）

RecEng中，效果流程是不需要客户配置的，只需要选择效果指标即可。关于效果指标和效果报表的自定义开发、配置，详见效果报表。

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

  上一篇： 部署和接入__产品简介_推荐引擎-阿里云

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