螞蟻金服過去十五年，重塑支付改變生活，爲全球超過十二億人提供服務，這些背後離不開技術的支撐。在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的鵲橋，更是鏈接數據與洞察的鵲橋，未來，我們期待無數的分析師能夠走過這個鵲橋，與科學和智慧相遇。
文中示例及運行環境，可以通過SQLFlow的docker 鏡像獲得
docker run -it -p 8888:8888 sqlflow/sqlflow:didi
SQLFlow官網：
http://sqlflow.org/
SQLFlow文檔：
https://sql-machine-learning....
SQLFlow Github：
https://github.com/sql-machin...
雲原生、TEE、共享智能、融合計算，這些都是什麼？螞蟻金服最前沿技術揭祕。乾貨細節盡在電子書《螞蟻金服在線金融技術解讀》，長按識別以下二維碼，關注“螞蟻金服科技”官方公衆號，並在對話框內回覆“在線”，即可免費下載。
