算法 自动采集列表(化是RecEng实现客户自定义功能的基础--日志埋点规范)

　　算法 自动采集列表(化是RecEng实现客户自定义功能的基础--日志埋点规范)

　　如前所述，整个流程的标准化是RecEng实现客户自定义功能的基础。

　　原木埋点规范

　　环境准备好后，最重要的连接工作就是访问客户日志，即使客户日志符合RecEng的日志嵌入规范。日志嵌入规范定义了客户终端产品所需的采集内容以及日志实时上报的格式要求。 RecEng 支持两种日志上报通道，实时上报和离线上报。实时报表通过Restful API提交，离线报表按照数据格式规范提交给MaxCompute（原ODPS）。日志嵌入规范包括通过Restful接口提交的日志格式，但不包括MaxCompute离线日志表的格式。

　　一般来说，为了符合RecEng的日志嵌入规范，需要对客户的终端产品进行升级。但是，如果客户有推荐的服务，则可能暂时不进行终端升级。详情请参考以下说明。

　　日志嵌入规范包括对内容和格式的要求。 RecEng 将用户行为分为三类。第一类是交易行为，即可以给网站或APP带来利益的用户行为，即RecEng的客户。对于电子商务，交易行为是购买商品；对于音乐或视频网站，交易行为为音乐或视频的播放或下载。

　　第二种行为称为准备行为。虽然不能直接给网站带来利益，但这些行为是实现交易的必要前提，比如用户的浏览、点击、搜索、采集等。客户需要区分这些行为，因为不同的行为对交易的影响不同。细粒度的区分有助于更好地分析用户兴趣并获得更好的推荐。

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

　　在内容上，日志嵌入规范要求客户记录交易行为和准备行为，并在记录用户行为日志时区分这两种行为。与通常的日志一样，日志嵌入规范也要求记录行为的一些上下文参数，例如时间、用户、项目等信息。另外，为了方便计算推荐服务带来的转化率，日志嵌入规范要求客户记录traceid。 Traceid 将用户在推荐坑上的点击与最终的交易关联起来，用于判断该交易是否由推荐服务带来。 traceid是RecEng在实时返回推荐结果时返回的。详情请参考日志嵌入规范。

　　如果客户没有按照日志嵌入规范记录traceid，唯一的影响是无法使用RecEng提供的效果报告功能，不影响推荐业务的正常使用。

　　如上所说，如果客户不关心效果报告，并且推荐的服务之前运行，并且日志内容符合日志嵌入规范的要求，则可以在现有推荐上遵循日志嵌入规范server 进行格式转换，暂不升级终端产品，快速体验RecEng。

　　数据格式规范

　　数据格式规范定义了离线和在线计算中使用的数据格式。离线数据的格式比较复杂，在线数据的格式比较简单。

　　离线数据规范

　　在RecEng中，离线过程（rec_path->offline_flow）和效果过程（index_path）是离线计算的。离线数据规范定义了这两种进程的数据规范。一般离线计算的输入输出都是MaxCompute（原ODPS）表，所以离线数据规范其实就是一套MaxCompute表格式规范，包括访问数据、中间数据、输出数据三种数据格式规范。

　　访问数据是指客户线下提供的用户、物品、日志等数据。 RecEng 最关注日志数据，其次是项目数据，最后是用户数据。离线和在线日志数据基本相同。日志嵌入点规范中有说明，请参考规范的详细定义。项目数据由类别、属性和关键字组成。类别和关键字含义明确，易于理解；属性是多值字段，并以键值格式组织。如果有多个属性，它们都在属性字段中。只需以标准格式列出即可。 RecEng 要求这三个字段不能都为空。

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

　　为了让RecEng了解item的属性字段和用户的tags字段中每个key-value的数据类型，客户还需要添加两个数据结构描述表来解释每个key-value的数据在项目的属性字段中。类型，以及用户标签字段中每个键值的数据类型。在客户提供的商品数据和用户数据的内容没有变化的情况下，这两个表可以一直使用。

　　如果客户想要定制离线算法，他们需要了解中间和输出数据格式规范。 RecEng定义了十多个离线MaxCompute（原ODPS）表的格式，涵盖了离线过程和效果过程中使用的所有访问表、中间表和输出表。这些表统称为标准表。所有离线计算算法必须使用标准表作为输入和输出表；对于效果过程中的算法，需要将计算结果输出到RDS进行实时显示。

　　在线数据规范

　　RecEng的在线计算包括两部分：在线过程（rec_path->online_flow）和实时修正过程（mod_path）。

　　与离线算法自然使用MaxCompute（原ODPS）表作为输入输出不同，在线程序的输入数据可以来自多个数据源，例如在线表存储（原OTS）、用户API请求等。或者程序中的一个变量；输出可以是程序变量，也可以写回在线存储，也可以返回给用户。

　　出于安全考虑，RecEng 提供了一套 SDK 供客户自定义在线代码读写在线存储（表格存储）。不允许直接访问，因此需要定义每种类型的在线存储的别名和格式。

　　对于需要频繁使用的在线数据，无论是来自在线存储还是用户的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）

　　离线流程总体*敏*感*词*：

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

　　离线流程从用户输入的user、item、log数据开始，经过简单的处理，生成user/item的原创特征。接下来是推荐核心算法，计算用户和物品的关系，生成用户/物品耦合特征。所谓耦合特征，是指收录用户对物品兴趣的特征，即利用耦合特征可以计算出用户对每个物品的兴趣偏好。下一步是计算用户的候选推荐集和相似项集。

　　对于一般客户来说，可以推荐的商品并不多。基本上到这里就够了，就是左边蓝色虚线框内的基本推荐流程。基本推荐流程分析用户行为，向用户展示他们最感兴趣的项目，即兴趣是其优化的目标。

　　如果客户可以推荐很多物品，或者客户的优化目标不是用户对物品的兴趣，而是其他指标，比如转化率、交易金额等，可以在右侧红色虚线框在此过程中，为优化目标建立了每个用户的模型，并在此基础上生成推荐候选集。

　　排序建模过程所需的样本是根据优化目标从用户日志中提取的。目前 RecEng 在排序模型方面只提供了基于 Logistic 回归的 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编写的，在线学习能力比较弱。未来将引入专用的实时计算平台，实现真正意义上的在线培训。

　　实时修正过程是可选的，最终输出用于响应用户推荐请求的在线过程（rec_path->online_flow）。

　　每个实时进程，包括下面的实时纠错进程（mod_path）和在线进程（online_flow），都工作在一个单独的线程中，但有些线程是后台定时线程（比如用户纠错进程，连续polling Real-time log），有些线程是事件触发的线程（比如数据纠错过程，只有在有API请求的时候才会工作，处理完成就结束）。 RecEng 将每个实时处理线程分为三个阶段，如下图所示：

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

　　为了简化客户自定义开发，专注于业务，在以上三个阶段，RecEng只允许客户自定义程序的第二阶段，RecEng负责参数和输出工作，这也提高了系统安全。

　　在线流程（rec_path -> online_flow）

　　online_flow 负责响应终端产品（用户）推荐的 API 请求。图中的“Table Store（原OTS）离线计算结果表”是offline_flow的最终输出，属于不同rec_path的offline_flow产生的表存储的离线计算。结果表不一样，online_flow和offline_flow就是这样形成rec_path的。

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

　　检查请求是否来自测试用户并记录在CTX（上下文环境变量）中。测试用户是指访问测试路径的用户。详情请参考“测试”部分“测试路径”的说明。

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

　　从离线计算结果表中读取当前用户的相关数据，包括用户特征，推荐候选集；如果 API 请求参数中收录 item id，则所有与 item 相似的 item 也会被读取

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

　　效果过程（index_path）

　　在RecEng中，效果过程不需要客户配置，只需选择效果索引即可。绩效指标和绩效报告的自定义开发和配置，详见绩效报告。