小叽导读&＃xff1a;在时间就是金钱的时代&＃xff0c;降低搜索时间成本&＃xff0c;迅速找到目标产品具有重要意义。如今的电商平台已不仅仅是一个摆放商品的货架&＃xff0c;“智能推荐”成为电商的一个重要功能。今天&＃xff0c;我们来看看强化学习是如何帮助用户与平台实现互动&＃xff0c;让用户在商品的海洋中迅速找到心仪的“它”。
交互搜索简介
智能交互搜索是一种新型的购物搜索方式&＃xff0c;用户可以在搜索中同时与系统进行交互&＃xff0c;我们希望可以在与用户的交互中提供帮助用户决策的信息。大致包含以下几种维度&＃xff1a;
细化需求&＃xff1a;用户购物需求比较确定的情况下&＃xff0c;系统会推荐有助于细化决策的维度&＃xff0c;比如“耳机”的Query下&＃xff0c;系统会让用户选择“佩戴方式”&＃xff0c;帮助用户更快成交。
探索发现&＃xff1a;解决逛和发现的需求&＃xff0c;在发现用户不是购买意图下&＃xff0c;推荐一些发散的Query。
知识问答&＃xff1a;解决用户之前通过第三方网站了解购物知识&＃xff0c;然后来淘宝直接搜索商品的问题&＃xff1b;提供一些知识解释&＃xff1b;最终希望引导用户在淘宝能流畅完成购前找买什么&＃xff0c;购买和购后分享的整个链路&＃xff1b;
某用户Session数据如下&＃xff1a;
初始Query为“无鞋带 男鞋”&＃xff0c;Agent给用户推荐了“颜色分类&＃xff1a;红色、白色、黑色、灰色”&＃xff0c;
用户选择了“销量排序”
用户选择了“黑色”&＃xff0c;Agent给用户推荐了一些发散性Query“发现&＃xff1a;皮鞋男、板鞋男、鞋子男、小白鞋男、布鞋男、帆布鞋男、休闲鞋男、豆豆鞋男、t恤男”
用户“翻页”
用户选择“小白鞋男”&＃xff0c;Agent同时给用户推荐了“鞋头款式&＃xff1a;尖头、扁头、圆头”
用户点了“尖头”
用户点了“圆头”
...
产品形态如下图&＃xff1a;
问题定义&相关工作&建模
问题定义
在当前问题中&＃xff0c;我们希望可以让用户尽可能多的和系统交互。更多的交互意味着更多的pv&＃xff0c;增加用户的停留时间和粘度&＃xff0c;pv增加也会提高广告的收入。在智能语音交互方面&＃xff0c;微软提出了一个统计指标——CPS&＃xff0c;即人类与人工智能“聊天机器人”的对话轮数。据微软统计显示&＃xff0c;目前小冰的CPS是23左右&＃xff0c;而Siri、Google Now 等以智能助手为目的开发的人工智能引擎&＃xff0c;CPS往往都不超过3。本文我们也采用这个Matrics作为优化目标。
当然我们也可以把这个问题看做一个Task Oriented Dialog System&＃xff0c;让用户以最少的交互次数完成购物&＃xff0c;目前我们把目标设定为前者。
强化学习在交互搜索场景的意义
强化学习work的场景必须有明确的delay reward&＃xff0c;典型的有棋类游戏中的放弃当前子来获取全局的优势&＃xff0c;竞技类游戏比如dota2中英雄放弃补刀的金钱收益去选择gank、打肉山&＃xff0c;强化学习擅长建模在序列决策中存在delay reward的问题&＃xff0c;即放弃当前局部最优的决策来获取更长期的收益。
交互搜索系统对用户的反馈是典型的序列决策过程&＃xff0c;有时需要放弃当前最高收益&＃xff0c;在这个问题中&＃xff0c;如果我们的优化目标是整体的CTR&＃xff0c;比如在耳机的搜索场景中&＃xff0c;有两个维度&＃xff08;品牌&＃xff09;,&＃xff08;佩戴方式&＃xff09;可以在context下用于决策&＃xff0c;用有监督的方法我们学到的是当前context下的最优选择&＃xff0c;为下图Greedy的思路&＃xff0c;这时我们学到的是“首次展示品牌”更好&＃xff0c;而实际上&＃xff0c;如果我们调换品牌&＃xff0c;佩戴方式的出现顺序&＃xff0c;虽然我们首次决策不是当前状态下最优的&＃xff0c;但序列决策下的期望却是最优的。
相对RL应用较成功的游戏、棋类、机器控制领域&＃xff0c;对话交互系统对“终止”的定义比较模糊&＃xff0c;在闲聊机器人中可以定义为用户退出&＃xff0c;在交互搜索里用户的意图切换是否定义为终止就与任务相关&＃xff0c;如果是希望用户增加PV&＃xff0c;我们可以整体交互的退出作为终止&＃xff0c;如果希望在细化类目做进一步导购直到成交&＃xff0c;终止则定义为退出或切换意图。
强化学习在任务型对话的一般思路
DM经典的做法是把问题看成一个槽填充问题&＃xff0c;在2007-2013&＃xff0c;基本做法是定义好一个任务&＃xff0c;并拆分为一系列的槽&＃xff08;slot&＃xff09;&＃xff0c;在对话交互过程中进行填充。而这种方法的最大问题在于&＃xff1a;错误传递&＃xff0c;上游错误会传递到下游导致下游直接错误&＃xff0c;比如NLU或DST的某步骤出错&＃xff0c;会直接导致DM输出错误的Action&＃xff0c;而且几乎无法修正。而端到端的方法可以做到一定程度的纠错&＃xff0c;基本思路为首先监督方法训练&＃xff0c;然后用深度强化学习调参&＃xff08;样本为真实用户&＃xff09;。比较代表性的工作有是Bing Liu在17年nips的文章&＃xff0c;结构如下&＃xff0c;优化同时考虑的slot filling和action。
交互搜索基于强化学习框架的建模
我们用强化学习的框架来对交互搜索场景建模。其中智能体&＃xff08;agent&＃xff09;是我们的服务进程。环境&＃xff08;env&＃xff09;是用户和平台的其他因素。具体地&＃xff0c;用户首先提交query&＃xff0c;例如“手机”。agent选择该类目的某个属性&＃xff0c;例如“品牌”。页面展示“品牌”的具体取值&＃xff0c;例如“华为”&＃xff0c;“小米”等。用户可能会选择/取消某个属性值&＃xff0c;也可能直接翻页&＃xff0c;这些操作都会跳转到下一个PV。agent与env不断交互直至用户退出会话&＃xff0c;构成一个episode。
我们记t时刻env给出状态&＃xff0c;agent做出动作&＃xff0c;env根据内生的动态&＃xff0c;反馈给agent奖励并跳转到状态。强化学习旨在为agent搜索最大化期望累积奖励的策略。
在交互搜索场景中&＃xff0c;我们将状态&＃xff0c;动作&＃xff0c;和奖励定义为&＃xff1a;
1、状态设计&＃xff1a;State的设计要考虑两点&＃xff0c;当前State足够学到合适的Action&＃xff0c;以及用户与环境交互的过程State要有明显变化去学Q函数&＃xff0c;这里我们考虑了以下几个方面&＃xff1a;
User State&＃xff1a;包括用户的性别、年龄、购买力。
User History、Agent History&＃xff1a;类目、页码&＃xff08;用户翻页&＃xff09;、用户点过的tag、Agent推荐过的tag。
Query State&＃xff1a;DST后Norm Query做Embedding&＃xff08;取语义粒度分词后embedding的均值&＃xff0c;当然这里也可以考虑用self-attention的方式考虑语义贡献&＃xff0c;但目前的数据量下我们没有这么做&＃xff09;作为当前的query state。
Tag静态分&＃xff1a;Query-Tag Score&＃xff0c;User-Tag Score等。&＃xff1a;包括用户信息&＃xff08;性别、年龄、购买力等&＃xff09;和会话信息&＃xff08;类目、页码、query、用户操作记录等&＃xff09;。
2、动作&＃xff1a;某个类目属性&＃xff0c;例如“品牌”&＃xff0c; “裤型”&＃xff0c; “材质”等。动作空间是所有合法的类目属性。
3、奖励&＃xff1a;如果用户没有离开&＃xff0c;否则。这样设计是因为最大化累积奖励等价于目前的业务目标&＃xff0c;即尽可能增加交互轮数。
此问题的难点在于&＃xff0c;所有类目属性的个数约有200K&＃xff0c;即动作空间的大小为200K&＃xff08;类目*维度&＃xff09;&＃xff0c;这势必导致搜索空间过于庞大&＃xff0c;难以求解最优策略。另一方面&＃xff0c;每个商品类目平均有约15种属性。这个动作空间的规模虽然可以接受&＃xff0c;但是我们共有约1500种类目&＃xff0c;如果分别训练1500个agent&＃xff0c;因为头部类目与尾部类目所拥有的流量严重失衡&＃xff0c;所以用机器学习的方法很难为尾部类目训练得到性能可观的agent。
我们注意到不同类目所拥有的属性集合是有大量交集的&＃xff0c;例如“连衣裙”和“裤子”都有“材质”这一属性。同一属性对于不同类目来说&＃xff0c;意义往往是无差别的。例如”品牌“是重视品质&＃xff0c;在乎品牌赋予同质化的商品的附加意义的用户会倾向于选择的属性。基于此&＃xff0c;我们通过共享模型参数&＃xff08;User History、Agent History、Action的embedding&＃xff09;&＃xff0c;联合训练&＃xff08;多任务&＃xff09;各类目的agent。具体模型如下&＃xff0c;另外一次输出这么高维度的打分向量显然是过度计算了&＃xff0c;所以这里我们根据类目对Action Space集合做了一个Mask&＃xff0c;只对当前类目下考虑的Action打分&＃xff0c;对最后的的计算我们采用了对Action做打分&＃xff1a;
系统
我们基于PAI TF&＃xff0c;使用Ali AI Agent&＃xff08;简称A3gent)强化学习组件实现的DQN算法来求解最优策略。
我们的神经网络的输入层包含多路输入&＃xff0c;且不同通道的状态分别有sparse/dense&＃xff0c;定长/变长&＃xff0c;数据的类型包括int, float, string多种类型。A3gent支持多路状态输入&＃xff0c;每个通道的数据类型及形状均可配置。
除了需要处理多路输入&＃xff0c;我们的神经网络结构也较为复杂&＃xff0c;包括embedding layer&＃xff0c;fully connected layer, concatenation layer。另外&＃xff0c;考虑到其中一路状态是agent在当前episode推荐过的属性集合且我们的动作空间正是属性集合&＃xff0c;我们让output layer与embedding layer共享参数。即对于属性P&＃xff0c;它的embedding向量会作为该P对应的output neuron的参数&＃xff1a;&＃xff0c;其中h表示output layer的输入。
由于不同类目的agent共享模型参数&＃xff0c;所以每个类目的agent的策略不能平凡地做一次forward。由于状态包含一个通道为类目的ID&＃xff0c;记为c&＃xff0c;我们首先根据c查询类目到属性列表的词典&＃xff0c;找到c所对应的合法属性集合。再根据Q值大小贪婪选取动作&＃xff1a;
A3gent组件中已经将上述逻辑通过计算图表达&＃xff0c;对于使用者不存在于普通forward的区别。
由于强化学习需要agent与env交互的过程中在线更新&＃xff0c;且基于QP的服务进程无法实现模型的训练&＃xff0c;所以我们采用基于PAI TF的准实时训练策略&＃xff1a;
训练
数据&＃xff1a;
我们首先用历史数据做预训练&＃xff0c;预训练的结果基本可以学到线上的策略&＃xff0c;作为模型的初始参数。baseline&＃xff08;top5的维度random&＃xff0c;所以random的结果也不差&＃xff09;对比&＃xff0c;从Query级别点击率来看DRL离线可以带来1.9%的提升&＃xff08;后面我们也分析了&＃xff0c;当前的Reward设定其实并不能显著提升CTR&＃xff09;&＃xff0c;而基于统计ensemble的版本有6.8%的提升。同时分析了不同策略下对全局指标的影响&＃xff0c;人均pv/uv降低0.5%&＃xff0c;一个大Session内的平均交互次数增长0.16%。具体如下&＃xff1a;
针对这个结果&＃xff0c;我们认为DRL只是在统计&＃43;random生成的样本上做了一轮训练&＃xff0c;而DRL需要与环境进行交互&＃xff0c;用当前策略(on-policy)去产生训练数据&＃xff0c;目前基于统计ensemble的版本用到了大量主搜数据&＃xff0c;所以效果会比较好。基于目前的分析&＃xff0c;我们尝试了准实时训练&＃xff0c;数据生成部分我们做到实时解析&＃xff0c;在porsche产生实时数据&＃xff08;pvlog&＃xff09;&＃xff0c;目前拼一个完整的EPISODE给模型训练&＃xff0c;需要拿到用户退出的操作&＃xff0c;而我们的数据量较小&＃xff0c;需要三小时才能产出足够的样本&＃xff0c;所以为了快速验证效果&＃xff0c;这一步目前我们是通过小时级离线解析&＃xff0c;然后用PAI去训练模型。我们也开发了一个实时Matrics&＃xff0c;实时监控小时级别的CTR和小时级别的平均CPS&＃xff08;平均交互次数&＃xff09;。
线上部署
DII&＃xff08;一个算法在线服务平台&＃xff09;在升级到0.33版本后内置了Tensorflow模型预测功能&＃xff0c;我们测试性能是可以满足需求的。在模型更新部分&＃xff0c;DII服务会在扫到模型文件切换index后重新加载模型&＃xff0c;目前唯一的缺点是&＃xff0c;没法做到实时&＃xff0c;实测1.4G的模型文件从产出、build、切换索引到生效大约需要半小时。我们的场景中&＃xff0c;目前流量下&＃xff0c;Replay Buffer积累数据也需要小时级&＃xff0c;所以这部分暂时是可接受的。
ps&＃xff1a;目前想实时生效只能通过写DII增量&＃xff0c;在DII的process里自己实现Inference&＃xff0c;考虑到我们的更新频率、以及模型切换后的开发成本&＃xff0c;我们暂时没有这么做。目前是采用定时调度的形式实现的。
结果
评价方式
RL在离线的评价一直是一个问题&＃xff0c;因为传统的AUC都是基于当前context下有监督的最优&＃xff0c;一般评价的方式有&＃xff1a;
模拟器&＃xff1a;根据真实数据产生一个Env的模拟器&＃xff0c;可以与训练的Agent进行交互&＃xff0c;用平均Reward评价。这对打游戏十分有效&＃xff0c;比如gym里的各种环境。在淘宝中也有很多模拟器的项目&＃xff0c;我们下一步也会考虑通过模拟器的方式快速迭代算法&＃xff0c;比如对话系统模拟器。
人工测试&＃xff1a;采用人工的方式与系统进行交互&＃xff0c;统计平均Reward&＃xff0c;这种方式人工反馈的量是比较有限的。
线上测试&＃xff1a;直接与真实环境进行交互&＃xff0c;然后统计随时间变化的平均Reward&＃xff0c;这种测试方式需要真实环境有大量交互行为&＃xff0c;我们也采用了这种评价方式。
线上效果
训练后的CPS相对ensamble的版本有明显提升。在新的交互系统中&＃xff0c;用户平均交互次数提升了1.5次&＃xff0c;提升30%&＃43;。
Tag的CTR并没有明显提升&＃xff0c;这里我们也分析了原因&＃xff0c;目前的Reward设定其实不一定展示给用户的是点击率最高的&＃xff0c;比如我们可能会出一个不是当前context下点击率最高的Tag&＃xff0c;但这个Tag点击后的商品对用户满意度最高&＃xff0c;用户会更多浏览&＃xff0c;这也会增加与系统的交互次数。
总结与展望
基于强化学习的Task-oriented Dialogue System已经在客服领域、医疗诊断等领域取得了巨大成功&＃xff0c;前者可以节省大量人力成本&＃xff0c;帮助用户快速完成任务&＃xff0c;后者则有望基于有经验的医疗诊断数据&＃xff0c;解决医疗资源不均的问题。
在商品导购领域&＃xff0c;消费者完成一笔订单&＃xff0c;用户通常会经过与销售客服交流&＃xff0c;自己查资料&＃xff0c;到决定购物的决策过程&＃xff0c;在淘宝海量购物数据中&＃xff0c;我们希望可以挖掘出“购物老司机”的购物路径&＃xff0c;并且在合适的时机给用户“有决策价值的解释”&＃xff0c;给消费者更好的导购体验。本任务中&＃xff0c;Action Space极大&＃xff0c;相对于传统的Task-Oriented Dialogue订机票、订餐、医疗的任务&＃xff0c;我们的Action Space包括确定当前的系统动作&＃xff0c;如&＃xff1a;商品属性的选择、内容解释等&＃xff0c;确认了动作后还要对具体动作的值进行排序&＃xff0c;如果候选空间有m个动作&＃xff0c;有n个是需要排序展示的&＃xff0c;那么动作空间会是维。这个量级的Action空间&＃xff0c;对于学术界和工业界都是巨大的挑战&＃xff0c;我们目前只是做了其中的一层&＃xff0c;动作空间有百万维。
本问题是一个典型的多层决策问题&＃xff0c;是否可以设计更好的HRL方式&＃xff0c;更全局的考虑全局的收益&＃xff1f;此外如何在有限的样本中做信息共享&＃xff1f;如何在真实线上环境中做高效率的探索&＃xff1f;如何够早一个合理的“experience replay”使online learning更“稳定、快速、有效”都是接下来要研究的问题&＃xff1f;
原文发布时间为&＃xff1a;2018-11-20
本文作者&＃xff1a;肖非、王桢
本文来自云栖社区合作伙伴“ 阿里技术”&＃xff0c;了解相关信息可以关注“ 阿里技术”。
京公网安备 11010802041100号