Categories
程式開發

大數據算法應用的測試發展之路(二)


在上一篇文章中,我們介紹了大數據應用在測試領域的六大問題,分別是功能性測試與驗證、數據更新的實時性、數據請求響應的及時性、算法的效果、AI算法系統的線上穩定性和工程效率。本文,我們就來講講這六大問題應該如何解決?

一、AI應用的功能性測試驗證

功能測試主要分為三部分:端到端的用戶交互測試、在線工程的功能測試、離線算法系統的功能測試。

1)端到端的用戶交互測試

搜索推薦廣告系統中的用戶交互測試,既包括了買家端(手機淘寶、天貓app和優酷app等)的用戶體驗和邏輯功能的驗證,也包括了針對廣告主和商家的客戶管理平台( Business Platform)上業務流程邏輯的校驗,其中會涉及廣告主在廣告創意創作、投放計劃設定、計費結算等方面的測試。

端到端的測試保證了最終交付給用戶和客戶使用的產品質量。端上的測試技術和工具,主要涉及端到端(native/h5)app/web上的UI自動化、安全、性能穩定性(monkey test/crash率)、流量(弱網絡)、耗電量、兼容性和適配。我們在集團其他團隊的測試技術和開源技術體系的基礎上做了一些改進和創新,例如將富媒體智能化驗證引入客戶端自動化測試,完成圖像對比、文字OCR、局部特徵匹配、邊緣檢測、基於關鍵幀的視頻驗證(組件動畫、貼片視頻)等,解決了廣告推薦在客戶端上所有展現形式的驗證問題。另外,針對Java接口和客戶端SDK的測試,除了常規的API Service級別測試之外,在數據流量回放的基礎上使用對比測試的方法,在接口對比、DB對比、文件對比、流量對比的上有一些不錯的質量效果。

由於UI的改版速度非常快,所以在端到端的測試策略方面,我們把自動化的重點放在接口層面,UI的automation只是簡單的邏輯驗證,全量的UI驗證回歸(功能邏輯和样式體驗)還是通過手動測試。這裡我們使用了不少的外包測試服務作為補充。

2)在線工程系統的測試

在線工程系統測試是整個系統功能測試的重點。

以搜索推薦廣告系統為例,其本質上是數據管理的系統,數據包括商品維度、用戶維度、商家和廣告主維度的數據。把大量的數據按照一定的數據結構存儲在機器內存之中,提供召回、預估、融合等服務,這些都是在線工程要去解決的問題。

在線工程系統測試的基本原理是通過發送Request/Query請求串、驗證Response結果的模式,並在此基礎上使用多種提升測試用例生成效率和執行效率的技術。基於可視化、智能化等技術(智能用例生成、智能回歸、失敗智能歸因、精準測試覆蓋、功能A/B測試),把測試方法論融入其中,解決大規模異構的在線工程功能測試case編寫成本高、debug難、回歸效率低的問題。

搜索推薦廣告的在線服務工程基本上由20—30個不同的在線模塊組成,測試這些在線服務模塊極其消耗時間,用例的編寫效率和回歸運行效率是優化的主要目標。我們在用例生成階段,通過用例膨脹和推薦技術、基於遺傳算法動態生成有效測試用例,在用例執行階段,使用動態編排的回歸技術,來提昇在線模塊功能測試的覆蓋率。此外,我們比較多地使用線上的Query做對比測試的方法,用以驗證功能變更的差異,分析即將發布的系統與實際線上系統之間的結果一致率和數據分佈,來很好地找到系統的功能性問題。

在線上測試領域,除了對比測試,我們把近期Top-N 的Query在線上定時做巡檢監察,一方面起到功能監控的作用,另一方面Query量級到一定程度(例如最近一周80%的長尾Query),可以很輕鬆地驗證引擎數據的完整性和多樣性。

最後,這一部分的測試策略也需要強調一下,由於算法的邏輯(例如召回和排序的業務邏輯)非常複雜,涉及不同的業務和分層模型,這些邏輯是算法工程師直接設計實現的,所以算法邏輯的測試用例的設計和執行也是由算法工程師來做,只有他們最清楚模型的功能邏輯和如何變化。結合著線上debug系統的使用,算法工程師可以很清楚目前線上運行的算法和線下即將上線的算法之間的邏輯差異,測試用例也就比較容易編寫。測試工程師在其中主要負責整個測試框架和工具環境的搭建,以及基本測試用例的編寫與運行。這個測試策略的調整,在本文最後關於測試未來的預判部分也有介紹。

3)算法工程測試與離線系統測試

從數據流程的角度看,算法工程包括算法模型的建模流程和模型訓練上線兩部分,我們可從特徵提取、樣本生成、模型訓練、在線預測,整個pipeline離線流程到在線的過程,來驗證特徵樣本的質量和模型的質量。

算法測試的關鍵在於三個部分:

  • 樣本特徵質量的評估
  • 模型質量的評估
  • 模型在線預估服務的質量保障

樣本特徵質量的評估和模型質量的評估,涉及數據質量與特徵功效放在一起在第四部分效果評估部分介紹,主要使用數據質量的各種指標的設計與實現來評估它們的質量。這裡重點說一下第三個:模型在線預估服務的質量保障,即算法在線預估服務上線前的測試,因為其涉及到模型最終服務的質量,比較重要。我們採用了一種小樣本離線在線打分對比的方法,較為簡單地解決了模型上線質量的問題。

具體的驗證過程是這樣的:在模型上線正式服務之前,需要對模型做測試驗證,除了準備常規的test數據集,我們單獨分離出一部分樣本集,稱為小樣本數據集,對比小樣本數據集在線系統的得分與離線分數異,驗證模型的在線服務質量,這種小樣本打分實際上也提供了類似於灰度驗證的能力。見下圖2。

大數據算法應用的測試發展之路(二) 1

圖2 小樣本測試流程示意圖

關於離線系統的測試,我們在深度學習訓練平台的質量保障上也做了一些探索。

目前深度學習平台質量主要面臨三大難點:

  • 由於種種複雜狀況,集群上訓練的模型存在訓練失敗的風險,如何提前預警深度學習平台當前存在的潛在風險;
  • 由於神經網絡天然局部最優解基因和Tensorflow Batch的設計思路,​​每次訓練的模型,如何保障其滿足上線的質量要求;
  • 如何驗證在大規模數據集和分佈式系統下,深度學習平台提供的各種深度學習功能的準確性;

針對以上三個問題,我們也嘗試了三個解決方法:

  • 實驗預跑法,設計特別的模型和訓練數據,15分鐘內訓練完畢。可以快速發現和定位訓練平​​台的問題,在大規模的生產模型正式訓練之前就發現問題;
  • Model on Model的模型驗證法,把模型生產的中間數據指標(除auc之外,還包括神經元激活率、梯度在各層傳到均方差等)透傳加工建模,監控生產模型的質量;
  • Model Based功能校驗法,針對性地設計樣本格式和測試模型網絡,精確計算出模型variable的理論值,根據訓練模型的結果驗證平台的質量。

二、數據更新的實時性測試

測試數據更新的實時性,其中主要是解決兩個子問題,即引擎數據實時更新鏈路的測試和模型實時更新(Online Deep Learning)鏈路的測試。

1)引擎實時更新鏈路的測試

一個實時更新鏈路,從上游的數據源/數據表(TT/MetaQ/ODPS,阿里的消息中間件與離線數據表)讀取數據,經過Streaming計算平台(Bayes引擎、BLINK等,阿里的實時計算平台)的實時計算任務處理產出引擎可以接受的更新消息,引擎在收到此類消息之後再做數據的更新操作。

這個鏈路主要驗證的點在於:

  • 數據的正確性驗證
  • 數據的一致性驗證
  • 數據的時效性驗證
  • 數據的並發性能測試

如何解決這幾個問題?我們使用了流式數據實時對比、全量對比來解決數據的正確性和一致性驗證的問題;數據的時效性更多地依賴計算平台底層的資源來保證毫秒級別的更新速度,通過記錄更新時間戳來驗證更新的時效性;性能測試通過偽造上游數據和流量複製來驗證整個鏈路的響應時間和並發處理能力。

2)模型實時更新鏈路的測試

最近兩年,Online Deep Learning(ODL)逐漸興起,用戶實時行為特徵數據也需要實時地訓練到模型之中,在10-15分鐘的時間間隔裡,在線服務的模型會被更新替代,留給模型驗證的時間最多只有10分鐘的時間,而這成為了ODL帶來的質量挑戰。

為了解決這個問題,我們使用了兩種方法。

第一種方法是建立ODL全鏈路質量指標監控體系,這裡的鏈路是指從樣本構建到在線預測的全鏈路,包括樣本域的指標校驗和訓練域指標校驗。指標選取上主要看是否跟效果相關聯,例如對於ctr預估方向,可以計算測試集上的auc、gauc(Group auc,分組後的auc)、score_avg(模型打分均值)等指標,甚至計算train_auc&test_auc, pctr&actual_ctr之間的差值(前者看是否過擬合,後者看打分準度)是不是在一個合理的範圍內。

這裡的關鍵點是測試集的選取。我們建議測試集除了取下一個時間窗口的數據(用未見的數據測試模型的泛化性能),還可以包含從過去一段時間(比如一周)的數據裡面隨機抽樣的一部分數據(用已見但全面的數據測試模型是否跑偏)。這樣可以降低局部的異常測試樣本對評估指標帶來的擾動影響。

第二種方法是設計一個離線仿真的系統,模型正式上線之前,先在仿真環境模擬打分校驗。簡單來說就是把需要上線的模型,在線下測試環境利用線上流量,通過在線服務的組件打分模塊進行一個提前的預打分,在這個打分過程中出現任何錯誤都算校驗不通過,打分正常的模型再對分數進行均值和分佈的校驗,打分校驗不通過會直接拒絕上線。

通過以上兩種方案,結合樣本與模型的監控與攔截,可以極大概率降低ODL的質量風險。

三、性能壓測

對於由離線、在線兩部分構成的AI系統,在線響應的是用戶實時訪問請求,對響應時間要求更高,因此,性能是在線系統的重點。離線的性能很大程度上取決於訓練平台在計算資源方面的調度使用,我們一般通過簡單的源頭數據複製來做驗證。

在線系統可分為讀場景和寫場景的性能測試,寫場景的性能在第二部分實時更新鏈路的時效性部分已有介紹,這裡主要講一下在線系統讀場景的性能容量測試。在線系統一般由二三十個不同的引擎模塊組成,引擎裡的數據Data與測試Query的不同都會極大的影響性能測試結果,同時由於維護線下的性能測試環境與線上環境的數據同步工作需要極大的代價,我們目前的策略都是選擇在線上的某個生產集群裡做性能容量測試。

對於可以處理幾十萬QPS(Query Per Second)的在線系統,難點在於如何精準控制產生如此量級的並發Query,使用簡單的多線程或多進程的控制已經無法解決,我們在這裡使用了一個爬山算法(梯度多倫迭代爬山法)來做流量的精準控制,背後是上百台的壓力測試機器遞增式地探測系統性能水位。

另外一個建設方向是整個壓測流程的自動化以及執行上的無人值守,從基於場景的線上Query的自動選取、到壓力生成、再到均值飄逸算法的系統自動化校驗工作,整個壓測流程會按照預設自動完成。並且,配合著集群之間的切流,可以做到白+黑(白天夜間)的日常壓測,為線上水位和性能瓶頸的分析帶來了極大的便利。

四、效果的測試與評估

效果的測試與評估是大數據應用算法的重頭戲,由於算法效果涉及到搜索廣告業務的直接受益(Revenue & GMV),我們在這個方向上也有比較大的投入,主要分為以下幾個子方向。

1)特徵與樣本的質量與功效評估

從特徵質量與特徵效用兩個角度出發,我們可以在特徵指標計算中發現一些重要指標:缺失率佔比、高頻取值、分佈變化、取值相關性等。在訓練和評估過程中,大量中間指標與模型效果能產生因果關係,通過系統的分析建模張量、梯度、權重和更新量,能夠對算法調優、問題定位起到輔助決策作用。並且,通過改進AUC算法,分析ROC、PR、預估分佈等更多評估指標,能夠更全面的評估模型效果。

隨著數據量級的增加,最近兩年我們在建模和訓練過程中使用了千億參數、萬億樣本,Graph Deep Learning也進入百億點千億邊的階段,在如此浩瀚的數據海洋裡,如何可視化特徵樣本以及各種指標就成為一個難點。

我們在google開源的Tensorboard的基礎上做了大量的優化與改進,幫助算法工程師可視化數據指標、調試訓練過程,同時在深度模型的可解釋性上給予了較好的支持。

2)在線流量實驗

算法項目在正式上線之前,模型需要在實驗環境中引入真實的線上流量進行效果測試和調優。

在第一代基於Google分層實驗架構的在線分層實驗(原理Google論文“Overlapping Experiment Infrastructure More, Better, Faster Experimentation”)的基礎上,我們在並發實驗、參數管理、參數間相互覆蓋、實驗質量缺乏保障、實驗調試能力缺失、實驗擴展能力不足等方面做了很多的改進,極大地提升了流量的並發復用與安全機制,達到了真正的生產實驗的目的。從效果看,通過在線實驗平台引入的真實流量的驗證,使得模型的效果質量得到極大的保障。

3)數據效果評測

數據效果評測主要分為兩部分:相關性評測與效果評測。

相關性是相關性模型的重要評估指標,我們主要通過數據評測來解決,通過對搜索展示結果的指標評測,可以得到每次搜索結果的相關性分數。細分指標包括:經典衡量指標CSAT(Customer Satisfaction,包括非常滿意、滿意、一般、不滿意、非常不滿意)、淨推薦值NPS(Net Promoter Score,由貝恩諮詢企業客戶忠誠度業務的創始人Fred Reichheld在2003提出,它通過測量用戶的推薦意願,從而了解用戶的忠誠度)、CES(Customer Effort Score,“客戶費力度”是讓用戶評價使用某產品/服務來解決問題的困難程度。) 、HEART框架(來源於Google,從愉悅度Happiness、Engagement參與度、Adoption接受度、Retention留存率、Task success任務完成度)。

效果評估方面,我們採用了數據統計與分析的方法。在一個算法模型真正全量投入服務之前,我們需要準確地驗證這個模型的服務效果。除了前面介紹的離在線對比之外,我們需要更加客觀的數據指標來加以佐證。這裡我們採用了真實流量的AB實驗測試方法,給即將發布的模型導入線上5%的流量,評估這5%流量和基準桶的效果對比,從用戶體驗(相關性)、平台收益、客戶價值三個維度做各自實際指標的分析,根據用戶的相關性評測結果、平台的收入或者GMV、客戶的ROI等幾個方面來觀測一個新模型對於買家、平台、賣家的潛在影響到底是什麼,並給最終的業務決策提供必要的數據支撐。當流量從5%增加到10%、20%,甚至50%後,無論是功能問題、還是性能的問題,甚至是效果的問題都會被探測到。這種方法進一步降低了重大風險的發生,這是一個數據統計分析與技術的融合的方案,與本文所介紹的其他技術方法不同,比較獨特,但效果甚佳。

五、線上穩定性

與其他業務的穩定性建設類似,線上穩定性也是通過發布三板斧(灰度、監控、回滾)來解決發布過程的質量,通過線上的容災演練、故障注入與演練、安全紅藍對抗攻防來提升系統線上的穩定性和可用性。

在AIOps和Service Mesh為基礎的運維管控方向上,我們正​​在向著智能運維、數據透視分析、自動切流、自動擴縮容等方向努力。我們預測結合Service Mesh技術理念在C++在線服務的演進,系統會具備對業務應用無侵入的流量標定及變更標定的能力,也就能夠實現流量調度能力和隔離的能力。

另外,紅藍攻防也將進一步發展,自動化、流程化將逐步成為混沌工程實施的標準形式。由於這一部分尚處於起步階段,這裡不再過多介紹還沒有實現的內容,但我們判定這個方向大有可為,與傳統運維工作不同,更接近Google的SRE(Site Reliability Engineering)理念。

六、AI應用的工程效能

AI應用的工程效能主要是解決在測試階段和研發階段提升效率的問題,這個方向上我們以DevOps工具鏈建設為主,包括開發、測試、工程發布、模型發布(模型debug定位)、客戶反饋(體感評估、眾測、客戶問題debug)整個研發閉環所使用到的工具方面的建設。

在我們設想的DevOps的場景下,開發同學通過使用這些工具可以獨立完成需求的開發測試發布及客戶反饋的處理。鑑於這個方向與測試本身關係不大,篇幅原因,這裡也略過。

相關閱讀:

大數據應用的測試發展之路(一)