滴滴經驗分享：SQLFlow如何讓運營專家用上AI？

時間 2019-12-30

標籤滴滴經驗分享 sqlflow 如何運營專家用上简体版

原文原文鏈接

螞蟻金服過去十五年，重塑支付改變生活，爲全球超過十二億人提供服務，這些背後離不開技術的支撐。在2019杭州雲棲大會上，螞蟻金服將十五年來的技術沉澱，以及面向將來的金融技術創新和參會者分享。咱們將其中的優秀演講整理成文並將陸續發佈在「螞蟻金服科技」公衆號上，本文爲其中一篇。

自從今年4月份開源以來，SQLFlow受到了業界和社區的普遍關注。SQLFlow項目以社區主導，與外部開發者進行合做與共建的形式運營。滴滴出行做爲螞蟻金服當前共建回饋開源社區的重要合做夥伴之一，從本身的場景實際應用出發將SQLFlow進行了落地應用。git

9月27日，滴滴數據科學部首席數據科學家謝梁和螞蟻金服研究員王益在雲棲大會上就SQLFlow的產品形態、產品使命願景、在滴滴的落地應用、將來前景展望等幾個部分給你們進行了詳細的介紹。github

從SQLFlow的願景提及

若是你還對SQLFlow還不瞭解，能夠閱讀咱們以前的介紹文章，或者查看項目官網：
https://sqlflow.org算法

簡單理解的話，SQLFlow = SQL + AI，你能夠把SQLFlow看作一個編譯器，它能夠把通過擴展的SQL語句翻譯成AI引擎可以運行的代碼。sql

SQLFlow的願景是：推動人工智能大衆化、普及化，也就是隻要懂商業邏輯就能用上人工智能, 讓最懂業務的人也可以自由地使用人工智能。docker

傳統建模流程中，一般由業務專家（分析師、運營專家、產品專家等）提出具體需求，經過產品、數據科學、算法、開發、測試等多個角色配合完成具體建模任務。不少狀況下，因爲你們的專業背景不一樣，如業務專家不懂AI的原理細節、算法工程師也很難理解業務邏輯的巧妙之處，就會致使溝通成本太高。而即便是基於上述條件完成的模型，每每也不能抽象成應用更普遍的通用模型。數據庫

若是要讓SQLFlow解決前面的問題，就涉及到三個核心要素，第一是數據描述商業邏輯，這個在SQLFlow語句上已經獲得了比較好的實現；第二，用AI來賦能深度的數據分析。當前數據分析師的大量工做是獲取原始數據，而後把它們整理加工成爲能夠對業務現狀進行描述和評估的指標，可是數據分析師的核心工做毫不僅僅只是數據的簡單彙總和加工，他們須要花更多的時間或者發展更好的能力去創建預測模型，進而解讀數據並研究數據的內在關係，SQLFlow賦予了他們極強的能力，幫助他們對這些數據進行深度的挖掘，從而正確地解讀數據背後用戶的行爲以及更好抽象出合理的行爲規律或商業邏輯；最後，它必須是一個很是易用的工具，讓使用者的學習成本或者學習門檻降到最低。服務器

SQLFlow的潛在用戶包括了運營專家、商業分析師和數據分析師，他們很是瞭解業務，只須要直接去調用對應的AI解決方案，一句話、一段SQL的代碼就完成一次建模任務，這樣的流程只須要業務專家經過SQL同SQLFlow打交道，下降了溝通成本、溝通損耗。建模成本下降，業務專家也能夠進行更加激進的探索和更富想象力的嘗試；同時高價值的代碼和抽象出的智慧會以模型的具象形式沉澱在SQLFlow模型池裏面。例如，一個西寧的運營專家看到北京的分析師頻繁地調用這個模型，他也能夠去調用這個模型進行遷移學習解決本地區的相似問題，所以他的建模成本和經驗成本都會進一步下降，知識的傳播在SQLFlow的幫助下很容易就能打破地域和行業的限制。網絡

SQLFlow都用在了哪裏？

SQLFlow已經在螞蟻金服和滴滴獲得了大規模的落地並獲得了較好的反饋。在滴滴，它被用在商業智能業務場景，在螞蟻金服，SQLFlow則被用在精準營銷場景，這些場景都符合業務專家需求靈活多變的狀況。SQLFlow也會探索更豐富的使用場景。機器學習

滴滴是如何用SQLFlow的

在應用SQLFlow的時候，滴滴首先須要解決的問題就是與數據的整合。工具

滴滴的大數據平臺基於Hive進行打造，SQLFlow主要與Hive集羣進行對接。圖上藍色的部分就是SQLFlow服務器，圍繞服務器有三個部分，第一部分在上面是滴滴的Notebook，全部的數據分析師和運營專家都在Notebook上操做和編寫SQL代碼，而後經過SQLFlow服務器鏈接數據服務器。

下面SQLFlow的服務器會和兩個部分產生交集，左下角是數據服務器，它會把SQL代碼解析爲一系列的Parse代碼，並驗證其中的數據部分。右下角是神經網絡庫，好比說支持的有keras、XGBoost等等模型庫，這些模型庫拿到Parse代碼以後會根據解析出來的Date到數據庫裏面取相應的數據。

數據服務器和神經網絡庫之間是雙向互通的，也就說模型會去取數據進行訓練或預測，那預測後的結果以及訓練獲得的模型，會返回到這個數據服務器裏存儲，供下一次使用，或者供運營專家作精準營銷的時候篩選。最後任務的信息也會經過模型庫返回到SQLFlow的服務器裏面，在滴滴的Notebook裏進行交互。

滴滴首席數據科學家謝梁從滴滴和螞蟻合做開源的模型出發，闡述了在滴滴的業務場景中如何應用SQLFlow來幫助業務提高效能,其中包括：

利用DNN神經網絡分類模型在精細化補貼券發放中的應用；
經過SHAP+XGBoost可解釋模型洞悉用戶行爲影響因素及影響力度，從而幫助運營人員定位運營點；
使用帶聚類分析的自編碼器分析司機運力的時間分佈，挖掘司機行爲模式。

下面分別進行介紹。

用SQLFlow進行有監督分類建模

分類模型是快捷的分類器，是機器學習的一個重要方向。這裏介紹滴滴的一個優惠券目標乘客識別預測的案例。

滴滴的優惠券是怎麼選出來的呢？後臺運營的專家會根據乘客歷史打車的行爲信息看來發券，好比說要對吃喝玩樂的場景進行促銷，就會看什麼樣的用戶在什麼樣的場景下更有可能去進行吃喝玩樂相關的消費，這時候定向給乘客發送優惠券，最大可能地轉換出行需求，從而創造用戶價值和收益。

在之前，完成以上整個建模的過程很是繁瑣的，既須要有大量的跨團隊配合，又須要有不一樣領域專家的時間投入，當整個建模全流程走完並花費很長時間訓練好模型後，投放的最佳時機已經錯過，因此業務的高速增加和發展對於公司數據和業務部門的相互合做以及模型的研發上線速度和流程都提出了更高的要求。

用SQLFlow恰好能夠知足這一需求。分析師只須要把待分類的用戶數據告訴SQLFlow，就能夠去作一個頗有效的分類選擇器，中間特徵的篩選以及特徵的組合均可以經過bucketize或者vocabularize作一個處理，最後把訓練獲得的模型輸出到一個叫作income_model的數據集裏面。上圖的一些方框所表示的代碼甚至進一步簡化，只用最後一行的代碼就能夠完成整個模型的訓練過程。這樣一來，對分析師來說幾乎不存在學習曲線。

用SQLFlow作黑盒模型解釋

更多的時候，對於數據分析師和運營專家來說，只知道what是不夠的，更須要知道why和how。例如，當滴滴的分析師進行乘客活躍度影響因素分析的時候，咱們須要針對乘客過去的打車行爲來創建預測乘客活躍度的模型，以分析影響他們打車的因素有哪些，從而把這些因素都嵌入到整個營銷方案的定製，實現更好的用戶留存。

在這個案例中，咱們須要肯定用戶當前處在生命週期的階段，包括註冊天數、等級、行爲分等等；從用戶對於出行需求性上，咱們須要知道這個用戶歷史上打車時所接受的預估里程以及平臺累積里程；此外，用戶的乘車體驗也是咱們必需要了解的，包括用戶需求次數、接駕距離、應答時長、是否有排隊等等。因爲這些數據量綱和業務含義的差別化，致使運營同窗很難經過簡單的數據彙總和先後比分析去決定哪一個因素在哪些業務場景下更能影響用戶的發單和留存，所以咱們必須藉助模型的方式對這些信息進行抽象後再將信息的重要程度排序後顯現出來。

在滴滴，咱們使用SQLFlow中的SQL語言提取出用戶過去一段時間內的出行數據，經過可解釋的擴展讓SQL調用DNN，而後採用SHAP + XGBoost解讀模型洞悉用戶行爲影響因素並量化影響力度。通過一系列的模型建模以後，能夠看到對於前面所列的各類信息，在每個用戶身上都打了一個點，縱軸是每個維度，橫軸是feature value值。經過這張圖能夠找到對於每一個人在每一個維度上的影響力是什麼樣的。全部的信息能夠輸出一個大的Hive表，運營專家能夠根據這些表格來找到運營場景，提高運營效率。不管是生成SHAP value仍是查詢Hive表，利用SQLFlow，運營專家用簡單的SQL語句就能夠實現一般一個高度專業化的AI算法工程師才能處理的複雜建模任務。

用SQLFlow進行無監督聚類

第三個例子是無監督聚類，這裏的實際場景是司機出車的偏好分層，也就是根據司機一段時間內的出車時長特徵，對司機羣體進行聚類，識別出不一樣類別的司機，爲後續策略投放和管理提供信息。

滴滴須要根據司機出車習慣來合理安排運力，平臺的活躍司機數以萬計，如何對這些司機進行打分或者區別呢？這是比較難的問題。

之前滴滴根據歷史的經驗和常識認知，主觀地對司機羣體進行分類 – 即天天工做8小時以上的司機叫作高運力司機，8小時如下就叫中等運力司機。亦或是用基於規則來進行劃分，好比根據過去30天在線時長多少，是否有指派等一系列很是複雜的規則，把司機分紅了五類，變成高運力司機、活躍中等運力司機、低頻中等運力司機、活躍低運力司機、偶發出車司機等等。但這樣作有不少問題。由於同是高運力中等運力司機，但他們在不一樣時空的出車習慣，出車時間分佈都是具備很大差別的，這也意味着咱們須要在不一樣時段對運力的刻畫作到更細的顆粒度。

上圖表明瞭一天中一個區域內16萬司機的出車時長分佈，橫軸是一天24小時的144個10分鐘，顏色表示該時段通過標準化的出車時長，顏色越鮮豔表明出車時長越長。也許你也發現了，上圖光譜比較雜亂，咱們很難看出司機出車的規律。

爲了解決這個難題，滴滴的數據科學家們利用SQLFlow中的Deep Learning Technique中的AutoEncoder將司機的出車時長進行了非監督聚類，在這個模型中自動的把16萬的司機出車模式分紅了五大類，通過聚類後，具備相同行爲模式的司機被很好劃分在了一組，組與組之間具備很是明顯的區分。

能夠看出，大約有4萬個司機就是真正的偶發出車司機，基本上不出車，出車之後基本上也是作一單就不作的司機；第二類司機是編號總4萬到6萬左右的，他們是典型的高峯出車司機，有一部分則是偏向於在晚高峯出車；第三類司機就是真正的所謂高運力司機，由於他們從早上作單到晚上，因此這些司機更有多是把滴滴做爲了一個職業；第四類司機是低頻中等司機，他們偶爾作一單，雖然比第一類司機接單更多一些，但出車也沒有固定的規律；最後一類就是夜貓子司機，他們從半夜出車凌晨回家睡覺，這羣司機是夜間運力的有力補充。

經過數據挖掘出來的這些不一樣出車習慣偏好的司機羣體, 怎麼樣設計合理的激勵和運營策略去合理地部署運力知足乘客需求，就是司機運營同窗平時最重要的工做。從前很是複雜和繁瑣的工做，如今只須要經過簡單的SQL代碼就可以有效地幫助運營專家把運力的特徵和全天的運力結構分解開來，從而大大提升運營策略的成功率和業務人員工做效率。

從前面這三個例子能夠看出，SQLFlow是真正的數智驅動產品，可以以最簡單的邏輯賦能業務同窗解決最複雜的業務問題。