螞蟻金服過去十五年,重塑支付改變生活,為全球超過十二億人提供服務,這些背後離不開技術的支撐。在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.github.io/doc_index/sqlflow_getstarted/SQLFlow Github:
https://github.com/sql-machine-learning/sqlflow雲原生、TEE、共享智能、融合計算,這些都是什麼?螞蟻金服最前沿技術揭秘。幹貨細節盡在電子書《螞蟻金服線上金融技術解讀》,長按識别以下二維碼,關注“螞蟻金服科技”官方公衆号,并在對話框内回複“線上”,即可免費下載下傳。