目录
7 策略框架总结
7.1 召回+排序架构
7.1.1 物体检测算法
7.1.2 FAQ智能问答
7.2 召回+排序+规划框架
7.2.1 O2O供需匹配
7.2.2 激励分配问题
7.2.3 搜索流量分配
7.3 LIME架构
7.4 可控模型架构
7.5 级联架构
7.6 未完待续...
7 算法框架总结
一直觉得模型解决的是一个“点”(ctr、cvr预估等)的问题；而框架解决的至少是一条“线”的问题，是一系列模型和策略相互协作的结果。
7.1 召回+排序架构
在“算法工程师≈推荐算法工程师”的年代，相信对上图所示流程都不会陌生。另外贴一张Paper(Alibaba 2019 Privileged Features Distillation for E-Commerce Recommendations https://arxiv.org/pdf/1907.05171.pdf)中的原图，与上图如出一辙。
以一个具体的实例介绍上述各个阶段的职责:
Triger:一个用户浏览一本图书。
Match:浏览过这本图书的用户也看了很多别的图书。
Rank:对关联得到的N件图书用个性化模型做点击率预估，取Top-K图书。
Rerank:对品牌、类目等因素做一些打散操作，避免推荐结果过于集中导致推荐系统窄化。
如果非要回溯历史，觉得召回-排序框架并非起源于推荐系统，在图像、NLP等AI系统中也屡屡出现。下面举些例子。
7.1.1 物体检测算法
上图是根据对物体检测算法的理解画的Pipeline。个人理解无论是传统的Cascade+HOG/DPM+Haar/SVM还是现在的End-2-End(Fast R-CNN、Faster R-CNN、SSD、Mask R-CNN、YOLO等)的方法，其本质内核还是召回-排序的思路。优化思路基本上有:
特征提取器，比如各种深度网络、多尺度融合等。
proposal生成方式，比如滑窗、先验框、RPN网络等。
多任务并行，比如proposal任务、分类任务与回归框refine任务并行等。
等等…
参考地址:https://www.leiphone.com/news/201902/VD5O19RmEBXIKJox.html?uniqueCode=cZgbKkCGzezwEDJS
7.1.2 FAQ智能问答
一种“基于检索的QA问答系统”的流程可能是这样的:
整体是看也是“召回-排序”架构。
7.1.3 文本纠错算法
参考论文:https://arxiv.org/pdf/1812.02303.pdf 更详细的资料可以参考: 1.基于语言模型的拼写纠错 https://cloud.tencent.com/developer/article/11567922.中文(语音结果)的文本纠错综述 https://blog.csdn.net/lipengcn/article/details/82556569 3.中文文本纠错算法走到多远了? https://www.wandouip.com/t5i42083/ 4. NLPCC Chinese Grammatical Error Correction https://juejin.im/entry/5b98c67fe51d450e7e513443
相比于“人类大脑”，机器最擅长“穷举”、“遍历”和“计算”。因此“召回-排序”框架之所以用处广泛本质来看是把很多问题转换成了“穷举-遍历-计算”，只不过穷举的更聪明一些。
上面举的例子多是些common sense，没有什么让人眼前一亮的灵魂trick。之所以要做这样的总结，只是要提醒自己不要仅仅“看山是山，看水是水”，还要“看山不是山，看水不是水”。当面临一个新的领域新的问题时，套用最普通最common sense的框架可能会柳暗花明。
7.2 召回+排序+规划框架
相比于上一小节提到的“召回-排序”框架，本小节所介绍的只是在最后添加了“Plan”。Plan这里翻译为“统筹规划”吧。现实世界中资源总是有限的，如何在有限资源限制下从全局考虑最大化我们的目标(GMV、ROI等)，就是“Plan”阶段存在的意义。
7.2.1 O2O供需匹配
比如在出行中需要完成“订单”和“司机”的匹配。
Match Phase:根据乘客的发单位置，召回乘客一定半径范围内的司机集合。
Rank Phase :评价每一对<司机,乘客>“好”的程度。至于“好”的如何定义，不同业务线、不同阶段可能是不一样的。
Plan Phase :假设运力无限丰富，Plan阶段是没有必要的。可资源是有限的，总有人打不上车，也总有人匹配不上心中最理想的司机，就好比有人孤独一生，也有人只是在婚姻中。所以，Plan阶段所要做的就是选择和舍弃，从而在某种现实意义下最大化我们的目标。Plan阶段往往建模为“运筹优化”问题。滴滴在2018年在KDD发表的<< Large-Scale Order Dispatch in On-Demand Ride-Hailing Platforms: A Learning and Planning Approach>>将上述问题形式化为如下:
同时KM算法求解上述0-1规划问题。滴滴2017年KDD发表的<< A Taxi Order DispatchModel based On Combinatorial Optimization>>论文中用“爬山法”贪心策略求解上述问题。
在这里强势贴下之前写的一篇博文,感兴趣的可以看下(个人YY版)。
基于 “ 滴滴 KDD 2018 论文：基于强化学习技术的智能派单模型 ” 再演绎mp.weixin.qq.com
更多内容可以参考如下:
1). 自适应大邻域搜索(Adaptive Large Neighborhood Search)入门到精通超详细解析
https://blog.csdn.net/Rivalsx/article/details/88790617blog.csdn.net
2). 2-opt求解TSP（旅行商）问题的python实现
https://blog.csdn.net/qq_33256688/article/details/75642525blog.csdn.net
7.2.2 激励分配问题
本小节内容参考: https://eng.lyft.com/how-to-solve-a-linear-optimization-problem-on-incentive-allocation-5a8fb5d04db1
激励分配解决的是“怎么花钱?”的问题，即花最少的钱办最多的事，再专业点的说法就是“最大化钱效”。同一个人对不同激励的敏感度不同；不同人对同一种激励的敏感度也不同。正是由于奖励个体与各种奖励之间敏感性以及效用差异化的存在为提高“钱效”提供了优化空间。形式化表达如下图所示:
将xij(0-1变量，要么分配要么不分配)松弛为正实数变量后，显然原问题变 为Linear Programming(线性规划)问题。同时原文引入了一个先验约束:
作者从“对偶问题(The Dual LP optimization algorithm)”出发推导出最终算法(可以点击放大图片查看)。
完整的算法描述如下:
其实算法过程非常简单直观，一句话“优先分配性价比高的奖励”。前面那么多的数学公式无非是证明这么做是对的！诸如“激励分配”、“资源分配”、“智能补贴”等问题都可以用此框架建模。至于价值xij和成本cij的定义根据场景自己定义就好了!
关于拉格朗日对偶问题:
https://blog.csdn.net/qq_34564612/article/details/79974635blog.csdn.net
7.2.3 搜索流量分配
经营好互联网流量不能只考虑单方的利益，还要控制好“贫富差距”，不能“撑的撑死，饿的饿死”。比如在电商搜索业务中，我们的目标是最大化平台的GMV，如果按照贪心策略，仅按照点击率预估排序的，头部商家会一直排在前面，导致马太效应加剧，小商家参与不进来，久而久之会损害平台的长期生态。再比如在外卖搜索业务中，搜索还要担负起“供需调节”的重任，如果头部商家承接的订单过多，会导致出餐时长不可控，直接影响的是用户体验和平台留存。同样在出行业务中，如果司机流量分配不均，导致司机收入不均衡，对于司机的感知和留存也是极大的伤害。
本小节以电商搜索分配为例简单复述下解决思路。
作者同时也给出了求解方法的物理含义:
流程图大概如上。在相关性排序的基础上融合流控排序(xij)，起到调控商家流量的作用。据了解在阿里国际技术部(ICBU)的搜索业务中也用到了类似的机制。
上文参考自知乎达人杨旭东的博文 :
杨旭东：电商平台商家流量分配机制算法zhuanlan.zhihu.com
无独有偶，在合约广告流量匹配中同样存在类似问题。在线广告有很大一部分是通过担保式合约来售卖的。这类广告的特点是：广告系统要保证广告主要求的定向条件的曝光量，有时间限制，超过时间没有完成可能会赔偿。这对广告系统意味着，当一次曝光机会到来时，可能会有多个广告主的单子满足曝光要求，广告系统需要决定这次曝光该展示哪一个合约，并且保证其他所有合约也完成。这个问题有两个挑战：（1）问题的数量级，可能会有百万级别的广告主合约和百万级别的流量；（2）不可预见性，合约通常是提前签订，因此需要预估流量。同时在分配流量时，也无法得知当天总流量的分布。可以将上述问题抽象成二部图形式如下:
雅虎的工程师们提出了一种对担保式投放系统的“启发式”的分配方案，HWM(High Water Mark)。
https://arxiv.org/pdf/1203.3593.pdfarxiv.org
上述问题可以形式化如下:
HWM 算法:
参考资料:
拂柳残声：计算广告@合约广告zhuanlan.zhihu.com
计算广告笔记(2)--合约广告系统wulc.me
基于对偶的竞争性在线算法设计www.docin.com
7.3 LIME架构
https://arxiv.org/pdf/1602.04938v1.pdfarxiv.org
LIME-Local Interpretable Model-Agnostic Explanations. 不知道该怎么翻译，是一种用来解释机器学习算法如何做出决策的算法。非线性模型(树模型、深度模型等)在以损失预测性能为代价取得较好预测性能。为了理解非线性模型如何做出决策? LIME假设在复杂非线性模型的“局部”区域是“线性分布”的，因此可以用代理模型(线性模型等)拟合“局部”区域，通过“代理模型”解释非线性模型的决策过程。看一个论文中的例子:
把LIME放在这里，只是因为比较喜欢这种思路。下面YY一个应用场景。在视频网站中，一般会有“倒记时”的展示广告(下图), 那这个时长该如何确定呢?
首先确定下我们的目标:在不影响播放率情况下，尽量拉长广告时长。这里涉及用户、平台和广告主三者之间的利益平衡。同时假设用户之间是相互独立的，因此整体目标的最大化等价于个体目标最大化。
不考虑算法策略，这件事件的优化空间在哪呢? 大概是有的人比较有耐心对广告的容忍度比较高，在不影响后续视频播放的情况下，拉长广告时长对平台营收是有利的。同时，有的人对广告缺乏耐心，缩短广告时长对用户体验和平台留存是有利的。哎，果然是在欺负“老实人”！
基于以上讨论，问题解决思路就比较明确了。就是预估用户对广告的“忍耐程度”，这里的“忍耐程度”可以借用经济学中的“弹性(价格变动Delta P时，需求的变化量)”概念来表达。首先可以设计一个“退出率”模型，来预估“用户在特定场景下对指定时长广告的忍耐程度”，可以选用DNN、树模型非线性模型。非线性模型的优势是拟合能力强，但是缺少可解释性，不利于因果推断和在线决策。所以可以借用上面提到的LIME架构，用一个可解释模型拟合非线性模型的决策过程。如下图所示:
上图最后拟合得到的k可以看作“弹性”，弹性越大说明用户对“广告时长”的忍耐力越高，反之越低。
7.4可控模型架构
AI如果失控，世界将会怎样?”。实在想不清起什么名字合适，其实也算不上一种架构。个人以为一个线上实用的系统除稳定性等基本要求外至少还要满足如下要求:
“可解释”是“可干预”的基础，“可干预”又是“可运营”的基础。所谓“可运营”是系统设计要对业务方同学友好，让业务方同学参与到系统的迭代中。举个例子，在阿里巴巴国际站(m.aliabab.com) 的顶部搜索框中，当用户输入“dress”时，会提示与“dress”相关的类目。本质上是一个多类目识别或多意图识别问题。
那背后的策略框架是怎么样的呢? 大体上分为如下三层:
规则层:通过直接词典映射，赋予整体策略“可干预”的能力。比如，对于上图提到的输入“dress”，可以直接将与“dress”相关的展示类目作为输出。而运营同学可以改变与“dress”相关的展示类目，实现对流量的调控。同时，对于模型层出现的不可解释的Badcase也可以在规则层强制提权修正。
简单模型层:充分利用各种先验(用户行为等)保证结果的准确性和可解释性。
复杂模型层:保证结果的多样性和整体策略的泛化能力。
学界和工业界追求的目标还是有很大差异的，无论看上去多“高大上”的算法，真正落地时也避免不了凡尘的无奈。原本此心只关“风花雪月(AUC、PREC、Recall)”，奈何还要留意“柴、米、油、盐(可解释、可干预、可运营)”。
7.5 级联架构
在人脸检测任务中，传统方法为了加速通常采用多个简单模型串联的方法。
同样在风控任务中，决策客户是否准入需要经过层层把关，此时也可以采用级联架构。
参考文档:
1.信贷风控中也有“幸存者偏差”？
https://www.weiyangx.com/316204.htmlwww.weiyangx.com
https://blog.csdn.net/u013948010/article/details/80520540blog.csdn.net
2. 级联分类器
级联分类器 - 一只有恒心的小菜鸟 - 博客园www.cnblogs.com
7.6 未完待续...
