螞蟻金服過去十五年，重塑支付改變生活，為全球超過十二億人提供服務，這些背后離不開技術的支撐。在2019杭州云棲大會上，螞蟻金服將十五年來的技術沉淀，以及面向未來的金融技術創新和參會者分享。我們將其中的優秀演講整理成文并將陸續發布在“螞蟻金服科技”公眾號上，本文為其中一篇。

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

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

從SQLFlow的愿景說起

如果你還對SQLFlow還不了解，可以閱讀我們之前的介紹文章，或者查看項目官網：
https://sqlflow.org

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

SQLFlow的愿景是：推進人工智能大眾化、普及化，也就是只要懂商業邏輯就能用上人工智能, 讓最懂業務的人也能夠自由地使用人工智能。

傳統建模流程中，通常由業務專家（分析師、運營專家、產品專家等）提出具體需求，通過產品、數據科學、算法、開發、測試等多個角色配合完成具體建模任務。很多情況下，由于大家的專業背景不同，如業務專家不懂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中通過AutoEncoder-based Clustering實現聚類

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

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

通過數據挖掘出來的這些不同出車習慣偏好的司機群體, 怎么樣設計合理的激勵和運營策略去合理地部署運力滿足乘客需求，就是司機運營同學平時最重要的工作。從前非常復雜和繁瑣的工作，現在只需要通過簡單的SQL代碼就能夠有效地幫助運營專家把運力的特征和全天的運力結構分解開來，從而大大提高運營策略的成功率和業務人員工作效率。

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

SQLFlow的價值與未來

我們知道，在計算機科學里，計算單元越接近數據單元，效率越高。SQLFlow的意義就在于它也想要實現同樣的目的，讓人工智能計算單元與業務主體合體，實現生產力提升。

這個方向的終點，就是所想即所得。

鋼鐵俠在構建自己的新反應堆時，他只需要去抓取這些影像，抓出來放到系統里看看合不合適，不適合就放回去換另外一個，其實SQLFlow已經無限接近于這種狀態了，這也是我們認為SQLFlow所需要達到的終態。

運營專家不需要花時間精力去學習AI模型的搭建，而是應該更大得利用自己的業務專長明確預測標的以及數據輸入，嘗試不同模型，通過SQLFlow探索解決方案，實現了所想即所得。

最后，SQLFlow是連接業務分析人員和AI的鵲橋，更是鏈接數據與洞察的鵲橋，未來，我們期待無數的分析師能夠走過這個鵲橋，與科學和智慧相遇。

iPhone 11 Pro、衛衣、T恤等你來抽，馬上來試試手氣 https://www.aliyun.com/1111/2019/m-lottery?utm_content=g_1000083877

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的滴滴经验分享：SQLFlow如何让运营专家用上AI？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。