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

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

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

從SQLFlow的願景說起

如果你還對SQLFlow還不瞭解，可以閱讀我們之前的介紹文章，或者檢視專案官網：

簡單理解的話，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解讀模型洞悉使用者行為影響因素並量化影響力度。經過一系列的模型建模之後，可以看到對於前面所列的各種資訊，在每一個使用者身上都打了一個點，縱軸是每一個維度，橫軸是featurevalue值。透過這張圖可以找到對於每個人在每個維度上的影響力是什麼樣的。所有的資訊可以輸出一個大的Hive表，運營專家可以根據這些表格來找到運營場景，提升運營效率。無論是生成SHAPvalue還是查詢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官網：

SQLFlow文件：

SQLFlow Github：

---

雲原生、TEE、共享智慧、融合計算，這些都是什麼？螞蟻金服最前沿技術揭秘。 乾貨細節盡在電子書《螞蟻金服線上金融技術解讀》，關注 “螞蟻金服科技”官方公眾號，並在對話方塊內回覆 “線上”，即可免費下載。