搭建强化推荐的决策服务架构

在线推荐、广告投放等场景中,强化学习推荐系统需要依据当前的用户与环境信息(上下文)即时选择最合适的动作,也就是决定展示哪条新闻或广告。微软研究院发表的论文《Making Contextual Decisions with Low Technical Debt》针对这类"上下文决策"问题,提出了一套通用的决策服务框架------Decision Service。论文链接如下:

Decision Service框架将整条强化学习链路拆解为探索(Explore)、记录(Log)、学习(Learn)、部署(Deploy)四个可独立演进却首尾相接的模块:

图1. 使用Decision Service框架进行有效的上下文学习的完整循环

1. 引言

在监督学习里,流程是线性的:先拿到完整的情境,接着让模型做出预测,最后拿到真实标签。因为真实标签对"所有可能的预测"都是已知的,因此可以直接衡量每个预测的好坏,并据此训练模型。

推荐系统这样的"上下文决策"场景则完全不同。系统必须先看用户当前的上下文(年龄、地域、兴趣等等),再从若干可选动作里挑一个,决定把政治新闻还是体育新闻摆在首页最显眼的位置。向用户展示的新闻最终会产生用户点击或不点击的反馈,其余未展示的新闻怎样就没人知道了。这种"部分反馈",让问题瞬间升级为强化学习难度。

首先,系统必须主动"探索"未被选中的动作,否则永远学不到它们的效果;其次,当前策略会影响未来收集到的数据,引入反馈偏差;最后,奖励往往还是延迟到来的(点击、购买、观看时长),进一步增加了数据不一致的风险。

所以说想要学到"成年人偏好政治新闻、青少年偏好体育新闻"这类映射,就不能再用传统监督学习的思路,而需要借助上下文多臂赌博机(contextual bandit)等强化学习方法,通过精心涉及的系统来解决探索、偏差和延迟带来的挑战。

2.系统架构

完整的决策服务架构如下图所示:

图2. Decision Service的架构

各个组件的作用是:

  • 探索(Explorer) :探索组件负责与应用程序交互,它接收上下文特征 x x x(如用户信息、设备特征、候选项目等)和唯一标识符 k k k作为输入,根据当前的探索策略输出具体的动作a(如推荐的文章、广告等)。同时,该组件将包含决策信息的元组 < k , ( x , a , p ) > <k,(x, a, p)> <k,(x,a,p)>发送给Log组件进行记录,其中 p p p表示探索策略选择动作 a a a的概率。当应用程序后续收到用户反馈时,会将奖励 r r r,会形成 < k , ( r ) > <k,(r)> <k,(r)>一起传递给Log组件。
  • 记录(Log) :记录组件用于将决策数据与奖励信息进行匹配,生成完整的探索数据集。考虑到奖励信息往往存在延迟到达的情况,Log组件接收带有标识符的观测数据流 ( k , o ) (k,o) (k,o),并输出拼接的观测数据流。对于具有相同标识符k的观测数据,若它们在时间窗口[ t t t, t t t+exp_unit]内到达( t t t为该标识符首次出现的时间),则会被连接成完整的训练样本;若在窗口期内未收到奖励信息,则默认赋值为0。
  • 学习(Learn):学习组件负责在线策略训练,它持续接收来自Log组件的探索数据流,利用强化学习算法(上下文多臂机)进行增量学习,并输出带有唯一标识的模型(id, model)。系统可以在每接收到新数据后立即更新模型,也可以采用批量处理方式定期更新。
  • 部署(Deploy):部署组件通过标准的get/put接口管理模型版本,Learn组件通过put操作将新训练的模型(id, model)存储到系统中,而Explorer组件则通过get操作获取指定版本的模型进行决策。当未指定模型版本时,系统自动返回最新的可用模型,确保决策过程始终使用最优策略。

客户端库(Client Library)是探索的实现,集成了多种探索策略,能够有效解决了部分反馈和偏差的问题,并确保向Log组件记录准确的数据从而解决数据采集错误问题。该库严格执行"在决策点进行日志记录"的原则(详见原文4.1节)。客户端库会以可配置的频率从部署组件中下载最新模型;在首个模型可用之前,系统执行默认策略或默认动作。为满足不同应用场景的需求,客户端库可以直接链接到以实现低延迟决策,也可以通过可移植、可扩展的 Web API 访问。

图3. Decision Service API可以通过跨平台web API(左)或低延迟客户端库(右)访问

连接服务(Join Service)通过将奖励信息与对应的决策数据进行匹配连接,生成正确的探索数据集,有效解决了数据采集错误问题。同时,在向学习组件发布数据前会强制实施统一的延迟等待机制(exp_unit),避免因奖励到达时间差异而产生的偏差,进一步解决了部分反馈和偏差问题。此外,生成的探索数据会同步复制到存储系统中,为后续的离线实验提供数据支持。

在线学习器(Online Learner)采用支持上下文多臂机在线学习的机器学习框架来实现。它能够持续整合新到达的数据,并按可配置的频率将训练好的模型检查点保存到部署组件中,实现了持续学习的目标并能够有效应对环境变化问题。为确保系统兼容性,客户端库必须使用兼容的机器学习框架来调用这些模型进行预测。在线学习器基于逆倾向评分(IPS)公式实现了对任意策略的实时评估能力,这正是多世界测试(MWT)功能的核心。这些实时统计信息为高级监控和安全保障机制提供了支撑,有效解决了监控调试问题。

ips ( π ) = 1 N ∑ t = 1 N I { π ( x t ) = a t } r t / p t ( 1 ) \text{ips}(\pi)=\frac{1}{N}\sum_{t=1}^{N}\mathbb{I}\{\pi(x_t)=a_t\}r_t/p_t\ (1) ips(π)=N1t=1∑NI{π(xt)=at}rt/pt (1)

公式(1)是Decision Service通过重要性加权来估计任意策略 π \pi π的平均奖励。其中,π表示待评估的策略; N N N表示探索数据的总数量;指示函数表示当策略 π \pi π在 t t t时刻的上下文 x x x下选择的动作与实际记录的动作 a a a相同时为1,否则为0。

存储系统(Store)为模型和数据提供统一的存储服务。离线学习器利用存储的数据进行各类离线实验,包括超参数调优、不同学习算法或策略类别的评估、奖励指标的调整等。这些离线实验具有反事实准确性保证。通过使用新的策略或参数设置重启在线学习器,即可将离线实验的改进成果无缝集成到在线学习循环中,这提升了系统的可用性和可定制性。

特征生成器(Feature Generator)通过为特定类型的内容自动生成特征,进一步降低了系统的使用门槛,提升了易用性。

相关推荐
打码人的日常分享4 小时前
物联网智慧医院建设方案(PPT)
大数据·物联网·架构·流程图·智慧城市·制造
何双新4 小时前
第23讲、Odoo18 邮件系统整体架构
ai·架构
雪碧聊技术4 小时前
将单体架构项目拆分成微服务时的两种工程结构
微服务·架构·module·project·工程结构
从零开始学习人工智能5 小时前
Doris 数据库深度解析:架构、原理与实战应用
数据库·架构
程序员JerrySUN6 小时前
[特殊字符] 深入理解 Linux 内核进程管理:架构、核心函数与调度机制
java·linux·架构
Theodore_10227 小时前
大数据(2) 大数据处理架构Hadoop
大数据·服务器·hadoop·分布式·ubuntu·架构
米粉03057 小时前
深入剖析Nginx:从入门到高并发架构实战
java·运维·nginx·架构
什么都想学的阿超7 小时前
【Redis系列 04】Redis高可用架构实战:主从复制与哨兵模式从零到生产
数据库·redis·架构
hello早上好10 小时前
BeanFactory 实现
后端·spring·架构