目錄
7 策略框架總結
7.1 召回+排序架構
7.1.1 物體檢測算法
7.1.2 FAQ智能問答
7.2 召回+排序+規(guī)劃框架
7.2.1 O2O供需匹配
7.2.2 激勵分配問題
7.2.3 搜索流量分配
7.3 LIME架構
7.4 可控模型架構
7.5 級聯(lián)架構
7.6 未完待續(xù)...
7 算法框架總結
一直覺得模型解決的是一個“點”(ctr、cvr預估等)的問題；而框架解決的至少是一條“線”的問題，是一系列模型和策略相互協(xié)作的結果。
7.1 召回+排序架構
在“算法工程師≈推薦算法工程師”的年代，相信對上圖所示流程都不會陌生。另外貼一張Paper(Alibaba 2019 Privileged Features Distillation for E-Commerce Recommendations?https://arxiv.org/pdf/1907.05171.pdf)中的原圖，與上圖如出一轍。
以一個具體的實例介紹上述各個階段的職責:
Triger:一個用戶瀏覽一本圖書。
Match:瀏覽過這本圖書的用戶也看了很多別的圖書。
Rank:對關聯(lián)得到的N件圖書用個性化模型做點擊率預估，取Top-K圖書。
Rerank:對品牌、類目等因素做一些打散操作，避免推薦結果過于集中導致推薦系統(tǒng)窄化。
如果非要回溯歷史，覺得召回-排序框架并非起源于推薦系統(tǒng)，在圖像、NLP等AI系統(tǒng)中也屢屢出現(xiàn)。下面舉些例子。
7.1.1 物體檢測算法
上圖是根據(jù)對物體檢測算法的理解畫的Pipeline。個人理解無論是傳統(tǒng)的Cascade+HOG/DPM+Haar/SVM還是現(xiàn)在的End-2-End(Fast R-CNN、Faster R-CNN、SSD、Mask R-CNN、YOLO等)的方法，其本質內核還是召回-排序的思路。優(yōu)化思路基本上有:
特征提取器，比如各種深度網(wǎng)絡、多尺度融合等。
proposal生成方式，比如滑窗、先驗框、RPN網(wǎng)絡等。
多任務并行，比如proposal任務、分類任務與回歸框refine任務并行等。
等等…
參考地址:https://www.leiphone.com/news/201902/VD5O19RmEBXIKJox.html?uniqueCode=cZgbKkCGzezwEDJS
7.1.2 FAQ智能問答
一種“基于檢索的QA問答系統(tǒng)”的流程可能是這樣的:
整體是看也是“召回-排序”架構。
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 召回+排序+規(guī)劃框架
相比于上一小節(jié)提到的“召回-排序”框架，本小節(jié)所介紹的只是在最后添加了“Plan”。Plan這里翻譯為“統(tǒng)籌規(guī)劃”吧?，F(xiàn)實世界中資源總是有限的，如何在有限資源限制下從全局考慮最大化我們的目標(GMV、ROI等)，就是“Plan”階段存在的意義。
7.2.1 O2O供需匹配
比如在出行中需要完成“訂單”和“司機”的匹配。
Match Phase:根據(jù)乘客的發(fā)單位置，召回乘客一定半徑范圍內的司機集合。
Rank Phase? :評價每一對<司機,乘客>“好”的程度。至于“好”的如何定義，不同業(yè)務線、不同階段可能是不一樣的。
Plan Phase? :假設運力無限豐富，Plan階段是沒有必要的?？少Y源是有限的，總有人打不上車，也總有人匹配不上心中最理想的司機，就好比有人孤獨一生，也有人只是在婚姻中。所以，Plan階段所要做的就是選擇和舍棄，從而在某種現(xiàn)實意義下最大化我們的目標。Plan階段往往建模為“運籌優(yōu)化”問題。滴滴在2018年在KDD發(fā)表的<< Large-Scale Order Dispatch in On-Demand Ride-Hailing Platforms: A Learning and Planning Approach>>將上述問題形式化為如下:
同時KM算法求解上述0-1規(guī)劃問題。滴滴2017年KDD發(fā)表的<< 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/88790617?blog.csdn.net
? ? 2). 2-opt求解TSP（旅行商）問題的python實現(xiàn)
https://blog.csdn.net/qq_33256688/article/details/75642525?blog.csdn.net
7.2.2 激勵分配問題
本小節(jié)內容參考:?https://eng.lyft.com/how-to-solve-a-linear-optimization-problem-on-incentive-allocation-5a8fb5d04db1
激勵分配解決的是“怎么花錢?”的問題，即花最少的錢辦最多的事，再專業(yè)點的說法就是“最大化錢效”。同一個人對不同激勵的敏感度不同；不同人對同一種激勵的敏感度也不同。正是由于獎勵個體與各種獎勵之間敏感性以及效用差異化的存在為提高“錢效”提供了優(yōu)化空間。形式化表達如下圖所示:
將xij(0-1變量，要么分配要么不分配)松弛為正實數(shù)變量后，顯然原問題變 為Linear Programming(線性規(guī)劃)問題。同時原文引入了一個先驗約束:
作者從“對偶問題(The Dual LP optimization algorithm)”出發(fā)推導出最終算法(可以點擊放大圖片查看)。
完整的算法描述如下:
其實算法過程非常簡單直觀，一句話“優(yōu)先分配性價比高的獎勵”。前面那么多的數(shù)學公式無非是證明這么做是對的！諸如“激勵分配”、“資源分配”、“智能補貼”等問題都可以用此框架建模。至于價值xij和成本cij的定義根據(jù)場景自己定義就好了!
關于拉格朗日對偶問題:
https://blog.csdn.net/qq_34564612/article/details/79974635?blog.csdn.net
7.2.3 搜索流量分配
經(jīng)營好互聯(lián)網(wǎng)流量不能只考慮單方的利益，還要控制好“貧富差距”，不能“撐的撐死，餓的餓死”。比如在電商搜索業(yè)務中，我們的目標是最大化平臺的GMV，如果按照貪心策略，僅按照點擊率預估排序的，頭部商家會一直排在前面，導致馬太效應加劇，小商家參與不進來，久而久之會損害平臺的長期生態(tài)。再比如在外賣搜索業(yè)務中，搜索還要擔負起“供需調節(jié)”的重任，如果頭部商家承接的訂單過多，會導致出餐時長不可控，直接影響的是用戶體驗和平臺留存。同樣在出行業(yè)務中，如果司機流量分配不均，導致司機收入不均衡，對于司機的感知和留存也是極大的傷害。
本小節(jié)以電商搜索分配為例簡單復述下解決思路。
作者同時也給出了求解方法的物理含義:
流程圖大概如上。在相關性排序的基礎上融合流控排序(xij)，起到調控商家流量的作用。據(jù)了解在阿里國際技術部(ICBU)的搜索業(yè)務中也用到了類似的機制。
上文參考自知乎達人楊旭東的博文 :
楊旭東：電商平臺商家流量分配機制算法?zhuanlan.zhihu.com
無獨有偶，在合約廣告流量匹配中同樣存在類似問題。在線廣告有很大一部分是通過擔保式合約來售賣的。這類廣告的特點是：廣告系統(tǒng)要保證廣告主要求的定向條件的曝光量，有時間限制，超過時間沒有完成可能會賠償。這對廣告系統(tǒng)意味著，當一次曝光機會到來時，可能會有多個廣告主的單子滿足曝光要求，廣告系統(tǒng)需要決定這次曝光該展示哪一個合約，并且保證其他所有合約也完成。這個問題有兩個挑戰(zhàn)：（1）問題的數(shù)量級，可能會有百萬級別的廣告主合約和百萬級別的流量；（2）不可預見性，合約通常是提前簽訂，因此需要預估流量。同時在分配流量時，也無法得知當天總流量的分布?？梢詫⑸鲜鰡栴}抽象成二部圖形式如下:
雅虎的工程師們提出了一種對擔保式投放系統(tǒng)的“啟發(fā)式”的分配方案，HWM(High Water Mark)。
https://arxiv.org/pdf/1203.3593.pdf?arxiv.org
上述問題可以形式化如下:
HWM 算法:
參考資料:
拂柳殘聲：計算廣告@合約廣告?zhuanlan.zhihu.com
計算廣告筆記(2)--合約廣告系統(tǒng)?wulc.me
基于對偶的競爭性在線算法設計?www.docin.com
7.3 LIME架構
https://arxiv.org/pdf/1602.04938v1.pdf?arxiv.org
LIME-Local Interpretable Model-Agnostic Explanations. 不知道該怎么翻譯，是一種用來解釋機器學習算法如何做出決策的算法。非線性模型(樹模型、深度模型等)在以損失預測性能為代價取得較好預測性能。為了理解非線性模型如何做出決策? LIME假設在復雜非線性模型的“局部”區(qū)域是“線性分布”的，因此可以用代理模型(線性模型等)擬合“局部”區(qū)域，通過“代理模型”解釋非線性模型的決策過程。看一個論文中的例子:
把LIME放在這里，只是因為比較喜歡這種思路。下面YY一個應用場景。在視頻網(wǎng)站中，一般會有“倒記時”的展示廣告(下圖), 那這個時長該如何確定呢?
首先確定下我們的目標:在不影響播放率情況下，盡量拉長廣告時長。這里涉及用戶、平臺和廣告主三者之間的利益平衡。同時假設用戶之間是相互獨立的，因此整體目標的最大化等價于個體目標最大化。
不考慮算法策略，這件事件的優(yōu)化空間在哪呢? 大概是有的人比較有耐心對廣告的容忍度比較高，在不影響后續(xù)視頻播放的情況下，拉長廣告時長對平臺營收是有利的。同時，有的人對廣告缺乏耐心，縮短廣告時長對用戶體驗和平臺留存是有利的。哎，果然是在欺負“老實人”！
基于以上討論，問題解決思路就比較明確了。就是預估用戶對廣告的“忍耐程度”，這里的“忍耐程度”可以借用經(jīng)濟學中的“彈性(價格變動Delta P時，需求的變化量)”概念來表達。首先可以設計一個“退出率”模型，來預估“用戶在特定場景下對指定時長廣告的忍耐程度”，可以選用DNN、樹模型非線性模型。非線性模型的優(yōu)勢是擬合能力強，但是缺少可解釋性，不利于因果推斷和在線決策。所以可以借用上面提到的LIME架構，用一個可解釋模型擬合非線性模型的決策過程。如下圖所示:
上圖最后擬合得到的k可以看作“彈性”，彈性越大說明用戶對“廣告時長”的忍耐力越高，反之越低。
7.4可控模型架構
AI如果失控，世界將會怎樣?”。實在想不清起什么名字合適，其實也算不上一種架構。個人以為一個線上實用的系統(tǒng)除穩(wěn)定性等基本要求外至少還要滿足如下要求:
“可解釋”是“可干預”的基礎，“可干預”又是“可運營”的基礎。所謂“可運營”是系統(tǒng)設計要對業(yè)務方同學友好，讓業(yè)務方同學參與到系統(tǒng)的迭代中。舉個例子，在阿里巴巴國際站(m.aliabab.com) 的頂部搜索框中，當用戶輸入“dress”時，會提示與“dress”相關的類目。本質上是一個多類目識別或多意圖識別問題。
那背后的策略框架是怎么樣的呢? 大體上分為如下三層:
規(guī)則層:通過直接詞典映射，賦予整體策略“可干預”的能力。比如，對于上圖提到的輸入“dress”，可以直接將與“dress”相關的展示類目作為輸出。而運營同學可以改變與“dress”相關的展示類目，實現(xiàn)對流量的調控。同時，對于模型層出現(xiàn)的不可解釋的Badcase也可以在規(guī)則層強制提權修正。
簡單模型層:充分利用各種先驗(用戶行為等)保證結果的準確性和可解釋性。
復雜模型層:保證結果的多樣性和整體策略的泛化能力。
學界和工業(yè)界追求的目標還是有很大差異的，無論看上去多“高大上”的算法，真正落地時也避免不了凡塵的無奈。原本此心只關“風花雪月(AUC、PREC、Recall)”，奈何還要留意“柴、米、油、鹽(可解釋、可干預、可運營)”。
7.5 級聯(lián)架構
在人臉檢測任務中，傳統(tǒng)方法為了加速通常采用多個簡單模型串聯(lián)的方法。
同樣在風控任務中，決策客戶是否準入需要經(jīng)過層層把關，此時也可以采用級聯(lián)架構。
參考文檔:
1.信貸風控中也有“幸存者偏差”？
https://www.weiyangx.com/316204.html?www.weiyangx.com
https://blog.csdn.net/u013948010/article/details/80520540?blog.csdn.net
2. 級聯(lián)分類器
級聯(lián)分類器 - 一只有恒心的小菜鳥 - 博客園?www.cnblogs.com
7.6 未完待續(xù)...
