[[324462]]

阿里妹導(dǎo)讀：隨著最近幾年數(shù)據(jù)計(jì)算力與機(jī)器智能算法的興起，基于大數(shù)據(jù) AI 算法的應(yīng)用愈來(lái)愈熱，大數(shù)據(jù)應(yīng)用在各個(gè)行業(yè)也不斷涌現(xiàn)。測(cè)試技術(shù)作為工程技術(shù)的一部分，也隨著時(shí)代的不斷變化在同步演進(jìn)，在當(dāng)下 DT 時(shí)代，如何測(cè)試和保障一個(gè)基于大數(shù)據(jù)的應(yīng)用的軟件質(zhì)量，成為測(cè)試界的一個(gè)難題。

本文通過(guò)系統(tǒng)性地介紹阿里巴巴 AI 中臺(tái)的技術(shù)質(zhì)量體系——搜索推薦廣告應(yīng)用的質(zhì)量是如何測(cè)試的，來(lái)嘗試回答一下這個(gè)問(wèn)題，希望能給大家?guī)?lái)一些借鑒，歡迎斧正，以便改進(jìn)。

一 前言

最近十年來(lái)，隨著移動(dòng)互聯(lián)網(wǎng)和智能設(shè)備的興起，越來(lái)越多的數(shù)據(jù)被沉淀到各大公司的應(yīng)用平臺(tái)之上，這些包含大量用戶特征和行為日志的數(shù)據(jù)被海量地存儲(chǔ)起來(lái)，先經(jīng)過(guò)統(tǒng)計(jì)分析與特征樣本提取，然后再經(jīng)過(guò)訓(xùn)練就會(huì)產(chǎn)出相應(yīng)的業(yè)務(wù)算法模型，這些模型就像智能的機(jī)器人，它可以精準(zhǔn)地識(shí)別和預(yù)測(cè)用戶的行為和意圖。

如果把數(shù)據(jù)作為一種資源的話，互聯(lián)網(wǎng)公司與傳統(tǒng)公司有著本質(zhì)的不同，它不是資源的消耗者，而是資源的生產(chǎn)者，在平臺(tái)運(yùn)營(yíng)的過(guò)程中不停地在創(chuàng)造新的數(shù)據(jù)資源，并且隨著平臺(tái)的使用時(shí)長(zhǎng)和頻率的增加，這些資源也在指數(shù)級(jí)地增長(zhǎng)。平臺(tái)通過(guò)使用這些數(shù)據(jù)和模型，又反過(guò)來(lái)帶來(lái)更好的用戶體驗(yàn)和商業(yè)價(jià)值。2016 年，AlphaGo，一個(gè)基于深度神經(jīng)網(wǎng)絡(luò)的圍棋人工智能程序，第一次戰(zhàn)勝圍棋世界冠軍李世石。這個(gè)由谷歌(Google)旗下 DeepMind 公司開(kāi)發(fā)的算法模型，背后使用的數(shù)據(jù)正是人類棋手所有的歷史棋譜數(shù)據(jù)。

阿里的搜索、推薦和廣告也是非常典型的大數(shù)據(jù)應(yīng)用的場(chǎng)景(高維稀疏業(yè)務(wù)場(chǎng)景)，在談如何測(cè)試之前我們需要先了解一下平臺(tái)處理數(shù)據(jù)的工程技術(shù)背景。搜索、推薦、廣告系統(tǒng)在工程架構(gòu)和數(shù)據(jù)處理流程上比較相近，一般分為離線系統(tǒng)和在線系統(tǒng)兩部分，見(jiàn)下圖 1(在線廣告系統(tǒng)一般性架構(gòu)，劉鵬《計(jì)算廣告》)。離線系統(tǒng)負(fù)責(zé)數(shù)據(jù)處理與算法模型的建模與訓(xùn)練，而在線系統(tǒng)主要用以處理用戶的實(shí)時(shí)請(qǐng)求。在線系統(tǒng)會(huì)使用離線系統(tǒng)訓(xùn)練產(chǎn)出的模型，用以實(shí)時(shí)的在線預(yù)測(cè)，例如預(yù)估點(diǎn)擊率。

用戶在訪問(wèn)手機(jī)淘寶或者其他 app 的時(shí)候會(huì)產(chǎn)生大量的行為數(shù)據(jù)，包括用戶的瀏覽、搜索、點(diǎn)擊、購(gòu)買(mǎi)、評(píng)價(jià)、停留時(shí)長(zhǎng)等，加上商家商品維度的各類數(shù)據(jù)(廣告還需要增加廣告主維度的數(shù)據(jù))，這些數(shù)據(jù)經(jīng)過(guò)采集過(guò)濾處理之后再經(jīng)過(guò)特征提取之后生成了模型所需的樣本數(shù)據(jù)，樣本數(shù)據(jù)在機(jī)器學(xué)習(xí)訓(xùn)練平臺(tái)上經(jīng)過(guò)離線訓(xùn)練之后就可以產(chǎn)生用以在線服務(wù)的各類算法模型(例如深度興趣演化網(wǎng)絡(luò) DIEN、Tree-based Deep Model、大規(guī)模圖表示學(xué)習(xí)、基于分類興趣的動(dòng)態(tài)相似用戶向量召回模型、等等)。在線系統(tǒng)中最主要的功能是數(shù)據(jù)的檢索和在線預(yù)測(cè)服務(wù)，一般使用信息檢索的相關(guān)技術(shù)，例如數(shù)據(jù)的正倒排索引、時(shí)序存儲(chǔ)等。

搜索推薦廣告系統(tǒng)在使用了上述維度的大數(shù)據(jù)，經(jīng)過(guò)深度學(xué)習(xí)之后，成為一個(gè)千人千面的個(gè)性化系統(tǒng)。對(duì)于不同的用戶請(qǐng)求，每次展現(xiàn)的商品和推薦的自然結(jié)果和商業(yè)結(jié)果都不盡相同，即便是同一個(gè)用戶在不同的時(shí)刻得到的結(jié)果也會(huì)隨著用戶的實(shí)時(shí)行為的不同而改變，這些背后都是數(shù)據(jù)和算法模型的魔力。

圖1 在線廣告系統(tǒng)一般性架構(gòu)圖

二 大數(shù)據(jù)應(yīng)用測(cè)試質(zhì)量域的六大挑戰(zhàn)

在思考搜索推薦廣告系統(tǒng)是如何測(cè)試的之前，我們首先要定義問(wèn)題域，即要解決的測(cè)試問(wèn)題是什么，我們的思路從以下幾個(gè)方向展開(kāi)。

1 功能性測(cè)試與驗(yàn)證

除了正常的請(qǐng)求與響應(yīng)的檢查之外，大數(shù)據(jù)的“大”主要體現(xiàn)在數(shù)據(jù)的完整性和豐富性。一個(gè)搜索推薦引擎的好壞很大程度上取決于其內(nèi)容是否足夠豐富，召回是否足夠多樣。另外，算法帶來(lái)搜索推薦結(jié)果的不確性，但也給我們的測(cè)試驗(yàn)證工作造成了麻煩。所以，數(shù)據(jù)的完整性和不確定性校驗(yàn)也是功能測(cè)試的要點(diǎn)。

2 數(shù)據(jù)更新的實(shí)時(shí)性如何測(cè)試

總所周知，對(duì)于一個(gè)搜索或者廣告的在線計(jì)算引擎，其內(nèi)部的數(shù)據(jù)在不停地發(fā)生更新，或者出于商家在商品信息上的變更，也可能是因?yàn)閺V告主在創(chuàng)意甚至投放計(jì)劃上的變化，這些更新需要實(shí)時(shí)反饋在投放引擎，否則會(huì)出現(xiàn)信息不一致甚至錯(cuò)誤。如何測(cè)試和驗(yàn)證這些變更的及時(shí)性，即保證一定的并發(fā)帶寬又保證更新鏈路的響應(yīng)時(shí)間，這是需要測(cè)試重點(diǎn)關(guān)注的一個(gè)問(wèn)題。

3 數(shù)據(jù)請(qǐng)求響應(yīng)的及時(shí)性如何測(cè)試

在線服務(wù)都要求低延遲，每次 query 服務(wù)端需要在幾十毫秒內(nèi)給出響應(yīng)結(jié)果，而整個(gè)服務(wù)端的拓?fù)鋾?huì)有大概 30 多個(gè)不同模塊構(gòu)成。如何測(cè)試后端服務(wù)的性能和容量就變得至關(guān)重要。

4 算法的效果如何驗(yàn)證

搜索推薦甚至廣告的返回結(jié)果需要與用戶的需求和興趣匹配，這樣才會(huì)保證更高的點(diǎn)擊率與成交轉(zhuǎn)化，但如何驗(yàn)證這種需求與結(jié)果的相關(guān)性，或者如何測(cè)試一個(gè)算法的效果，這是一個(gè)非常有趣且有挑戰(zhàn)的話題。

5 AI 算法系統(tǒng)的線上穩(wěn)定性如何保證

線下發(fā)布之前的測(cè)試是對(duì)代碼的測(cè)試驗(yàn)收，并隨著缺陷的發(fā)現(xiàn)與修復(fù)，提升的是代碼質(zhì)量。而線上的穩(wěn)定性運(yùn)營(yíng)是為了提升系統(tǒng)運(yùn)行的穩(wěn)定性，解決的問(wèn)題是：即便是一個(gè)代碼質(zhì)量一般的系統(tǒng)，如何通過(guò)技術(shù)運(yùn)維的方法來(lái)提升系統(tǒng)的高可用性與魯棒性，并降低線上故障的頻次與影響，這一部分也被稱為線上技術(shù)風(fēng)險(xiǎn)領(lǐng)域。

6 工程效率方向

這是對(duì)以上幾個(gè)部分的補(bǔ)充，甚至是對(duì)整個(gè)工程研發(fā)體系在效率上的補(bǔ)充。質(zhì)量與效率是一對(duì)孿生兄弟，也是同一個(gè)硬幣的兩面，如何平衡好兩者之間的關(guān)系是一個(gè)難題，質(zhì)量?jī)?yōu)先還是效率優(yōu)先，不同的產(chǎn)品發(fā)展階段有不同的側(cè)重點(diǎn)。我們的工程效率，力在解決 DevOps 研發(fā)工具鏈路，用以提升研發(fā)的工程生產(chǎn)力。

自此，我們基本定義完畢大數(shù)據(jù)應(yīng)用的測(cè)試問(wèn)題的六大領(lǐng)域，有些領(lǐng)域已經(jīng)超過(guò)了傳統(tǒng)的測(cè)試與質(zhì)量的范疇，但這也正是大數(shù)據(jù)應(yīng)用給我們帶來(lái)的獨(dú)特質(zhì)量挑戰(zhàn)，下面我們圍繞這六個(gè)問(wèn)題展開(kāi)講一講。

三 大數(shù)據(jù)應(yīng)用測(cè)試六個(gè)問(wèn)題的解法

1 AI 應(yīng)用的功能性測(cè)試驗(yàn)證

功能測(cè)試主要分三塊：端到端的用戶交互測(cè)試、在線工程的功能測(cè)試、離線算法系統(tǒng)的功能測(cè)試。

1) 端到端的用戶交互測(cè)試

這是涉及到搜索推薦廣告系統(tǒng)的用戶交互部分的測(cè)試驗(yàn)證，既包括買(mǎi)家端(手機(jī)淘寶、天貓 app 和優(yōu)酷 app 等)的用戶體驗(yàn)和邏輯功能的驗(yàn)證，也包括針對(duì)廣告主和商家的客戶管理平臺(tái)(Business Platform)上業(yè)務(wù)流程邏輯的校驗(yàn)，涉及廣告主在廣告創(chuàng)意創(chuàng)作、投放計(jì)劃設(shè)定、計(jì)費(fèi)結(jié)算等方面的測(cè)試。端到端的測(cè)試保證了我們最終交付給用戶和客戶使用的產(chǎn)品質(zhì)量。端上的測(cè)試技術(shù)和工具，主要涉及端到端(native/h5)app/web 上的 UI 自動(dòng)化、安全、性能穩(wěn)定性(monkey test/crash 率)、流量(弱網(wǎng)絡(luò))、耗電量、兼容性和適配，在集團(tuán)其他團(tuán)隊(duì)的測(cè)試技術(shù)和開(kāi)源技術(shù)體系的基礎(chǔ)上我們做了一些改進(jìn)和創(chuàng)新，例如將富媒體智能化驗(yàn)證引入客戶端自動(dòng)化測(cè)試，完成圖像對(duì)比、文字 OCR、局部特征匹配、邊緣檢測(cè)、基于關(guān)鍵幀的視頻驗(yàn)證(組件動(dòng)畫(huà)、貼片視頻)等，解決了廣告推薦在客戶端上所有展現(xiàn)形式的驗(yàn)證問(wèn)題。另外，針對(duì) Java 接口和客戶端 SDK 的測(cè)試，除了常規(guī)的 API Service 級(jí)別測(cè)試之外，在數(shù)據(jù)流量回放的基礎(chǔ)上使用對(duì)比測(cè)試的方法，在接口對(duì)比、DB 對(duì)比、文件對(duì)比、流量對(duì)比的使用上有一些不錯(cuò)的質(zhì)量效果。端到端的測(cè)試驗(yàn)證，由于 UI 的改版速度非常快，測(cè)試策略上我們把自動(dòng)化的重點(diǎn)放在接口層面，UI 的 automation 只是簡(jiǎn)單的邏輯驗(yàn)證，全量的 UI 驗(yàn)證回歸(功能邏輯和樣式體驗(yàn))還是通過(guò)手動(dòng)測(cè)試，這里我們使用了不少的外包測(cè)試服務(wù)作為補(bǔ)充。

2) 在線工程系統(tǒng)的測(cè)試

這一部分是整個(gè)系統(tǒng)的功能測(cè)試的重點(diǎn)。搜索推薦廣告系統(tǒng)，本質(zhì)上是數(shù)據(jù)管理的系統(tǒng)，數(shù)據(jù)包括商品維度、用戶維度、商家和廣告主維度的數(shù)據(jù)。把大量的數(shù)據(jù)按照一定的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)在機(jī)器內(nèi)存之中，提供召回、預(yù)估、融合等服務(wù)，這些都是在線工程要去解決的問(wèn)題。這部分的功能測(cè)試，基本原理是通過(guò)發(fā)送 Request/Query 請(qǐng)求串、驗(yàn)證 Response 結(jié)果的模式，在此基礎(chǔ)上使用了比較多提升測(cè)試用例生成效率和執(zhí)行效率的技術(shù)。基于可視化、智能化等技術(shù)(智能用例生成、智能回歸、失敗智能歸因、精準(zhǔn)測(cè)試覆蓋、功能 A/B 測(cè)試)，把測(cè)試方法論融入其中，解決了大規(guī)模異構(gòu)的在線工程功能測(cè)試 case 編寫(xiě)成本高、debug 難、回歸效率低的問(wèn)題。搜索推薦廣告的在線服務(wù)工程基本上由 20 - 30 個(gè)不同的在線模塊組成，測(cè)試這些在線服務(wù)模塊極其消耗時(shí)間，用例的編寫(xiě)效率和回歸運(yùn)行效率是優(yōu)化的主要目標(biāo)，在這個(gè)方向上，我們?cè)谟美煞矫嫱ㄟ^(guò)用例膨脹和推薦技術(shù)、基于遺傳算法動(dòng)態(tài)生成有效測(cè)試用例、在用例執(zhí)行階段使用動(dòng)態(tài)編排的回歸技術(shù)，通過(guò)這些技術(shù)極大地提升了在線模塊的功能測(cè)試的覆蓋率。

此外，我們比較多地使用線上的 Query 做對(duì)比測(cè)試的方法，用以驗(yàn)證功能變更的差異，分析即將發(fā)布的系統(tǒng)與實(shí)際線上系統(tǒng)之間的結(jié)果一致率和數(shù)據(jù)分布可以很好地找到系統(tǒng)的功能性問(wèn)題。在線上測(cè)試領(lǐng)域，除了對(duì)比測(cè)試，我們把近期 Top-N 的 Query 在線上定時(shí)做巡檢監(jiān)察，一方面起到功能監(jiān)控的作用，另一方面 Query 量級(jí)到一定程度(例如最近一周 80% 的長(zhǎng)尾 Query)，可以很輕松地驗(yàn)證引擎數(shù)據(jù)的完整性和多樣性。最后，這一部分的測(cè)試策略也需要強(qiáng)調(diào)一下，由于算法的邏輯(例如召回和排序的業(yè)務(wù)邏輯)非常復(fù)雜，涉及不同的業(yè)務(wù)和分層模型，這些邏輯是算法工程師直接設(shè)計(jì)實(shí)現(xiàn)的，所以算法邏輯的測(cè)試用例的設(shè)計(jì)和執(zhí)行也是由算法工程師來(lái)做，只有他們最清楚模型的功能邏輯和如何變化。結(jié)合著線上 debug 系統(tǒng)的使用，算法工程師可以很清楚目前線上運(yùn)行的算法和線下即將上線的算法之間的邏輯差異，測(cè)試用例也就比較容易編寫(xiě)。測(cè)試工程師在其中主要負(fù)責(zé)整個(gè)測(cè)試框架和工具環(huán)境的搭建，以及基本測(cè)試用例的編寫(xiě)與運(yùn)行。這個(gè)測(cè)試策略的調(diào)整，在本文最后關(guān)于測(cè)試未來(lái)的預(yù)判部分也有介紹。

3) 離線系統(tǒng)的測(cè)試，或者算法工程測(cè)試

從數(shù)據(jù)流程的角度看，算法工程包括算法模型的建模流程和模型訓(xùn)練上線兩部分，從特征提取、樣本生成、模型訓(xùn)練、在線預(yù)測(cè)，整個(gè)pipeline離線流程到在線的過(guò)程中如何驗(yàn)證特征樣本的質(zhì)量和模型的質(zhì)量。所以算法測(cè)試的關(guān)鍵在于三個(gè)地方：

a.樣本特征質(zhì)量的評(píng)估

b.模型質(zhì)量的評(píng)估

c.模型在線預(yù)估服務(wù)的質(zhì)量保障

a 和 b 涉及數(shù)據(jù)質(zhì)量與特征功效放在一起在第四部分介紹，主要使用數(shù)據(jù)質(zhì)量的各種指標(biāo)來(lái)評(píng)估質(zhì)量。

這里重點(diǎn)說(shuō)一下 c，算法在線預(yù)估服務(wù)上線前的測(cè)試，因?yàn)槠渖婕暗侥Ｐ妥罱K服務(wù)的質(zhì)量，比較重要。我們這里使用了一種小樣本離線在線打分對(duì)比的方法，可以最終比較全面地驗(yàn)證模型上線質(zhì)量的問(wèn)題。詳細(xì)過(guò)程是：在模型上線正式服務(wù)之前，需要對(duì)模型做測(cè)試驗(yàn)證，除了準(zhǔn)備常規(guī)的 test 數(shù)據(jù)集，我們單獨(dú)分離出一部分樣本集，稱之為小樣本數(shù)據(jù)集，通過(guò)小樣本數(shù)據(jù)集在線系統(tǒng)的得分與離線分?jǐn)?shù)的對(duì)比的差異，驗(yàn)證模型的在線服務(wù)質(zhì)量，這種小樣本打分實(shí)際上也提供了類似于灰度驗(yàn)證的能力。流程見(jiàn)下圖 2。

圖2 小樣本測(cè)試

關(guān)于離線系統(tǒng)的測(cè)試，我們同時(shí)在深度學(xué)習(xí)訓(xùn)練平臺(tái)的質(zhì)量保障上也做了一些探索，目前深度學(xué)習(xí)平臺(tái)質(zhì)量主要面臨三大難點(diǎn)：

• 由于種種復(fù)雜狀況，在集群上訓(xùn)練的模型存在訓(xùn)練失敗的風(fēng)險(xiǎn)，如何提前預(yù)警深度學(xué)習(xí)平臺(tái)當(dāng)前存在的潛在風(fēng)險(xiǎn)。
• 由于神經(jīng)網(wǎng)絡(luò)天然局部最優(yōu)解基因和 Tensorflow Batch 的設(shè)計(jì)思路，每次訓(xùn)練的模型，如何保障它是否滿足上線的質(zhì)量要求。
• 如何驗(yàn)證在大規(guī)模數(shù)據(jù)集和分布式系統(tǒng)下深度學(xué)習(xí)平臺(tái)提供的各種深度學(xué)習(xí)功能的準(zhǔn)確性。

針對(duì)這三大問(wèn)題，我們嘗試了三個(gè)解法：

• 實(shí)驗(yàn)預(yù)跑法，設(shè)計(jì)特別的模型和訓(xùn)練數(shù)據(jù)，15 分鐘內(nèi)訓(xùn)練完畢。可以快速發(fā)現(xiàn)和定位訓(xùn)練平臺(tái)的問(wèn)題，在大規(guī)模的生產(chǎn)模型正式訓(xùn)練之前就發(fā)現(xiàn)問(wèn)題。
• Model on Model 的模型驗(yàn)證法，把模型生產(chǎn)的中間數(shù)據(jù)指標(biāo)(除 auc 之外，還包括神經(jīng)元激活率、梯度在各層傳到均方差等)透?jìng)骷庸そ?，監(jiān)控生產(chǎn)模型的質(zhì)量。
• Model Based 功能校驗(yàn)法，針對(duì)性地設(shè)計(jì)樣本格式和測(cè)試模型網(wǎng)絡(luò)，使模型 variable 的理論值能夠精確計(jì)算出，根據(jù)訓(xùn)練模型的結(jié)果驗(yàn)證平臺(tái)的質(zhì)量。

2 數(shù)據(jù)更新的實(shí)時(shí)性如何測(cè)試的問(wèn)題

這一部分主要包含兩個(gè)子問(wèn)題：

1) 引擎數(shù)據(jù)的實(shí)時(shí)更新鏈路的測(cè)試

對(duì)于一個(gè)實(shí)時(shí)更新鏈路，從上游的數(shù)據(jù)源/數(shù)據(jù)表(TT/MetaQ/ODPS，阿里的消息中間件與離線數(shù)據(jù)表)讀取數(shù)據(jù)，經(jīng)過(guò) Streaming 計(jì)算平臺(tái)(Bayes 引擎、Blink 等，阿里的實(shí)時(shí)計(jì)算平臺(tái))的實(shí)時(shí)計(jì)算任務(wù)處理產(chǎn)出引擎可以接受的更新消息，引擎在收到此類消息之后再做數(shù)據(jù)的更新操作。這個(gè)鏈路主要驗(yàn)證的點(diǎn)在于：

• 數(shù)據(jù)的正確性驗(yàn)證
• 數(shù)據(jù)的一致性驗(yàn)證
• 數(shù)據(jù)的時(shí)效性驗(yàn)證
• 數(shù)據(jù)的并發(fā)性能測(cè)試

在這幾個(gè)問(wèn)題的解決上，我們使用了流式數(shù)據(jù)實(shí)時(shí)對(duì)比、全量對(duì)比可以解決數(shù)據(jù)的正確性和一致性驗(yàn)證的問(wèn)題;數(shù)據(jù)的時(shí)效性更多地依賴計(jì)算平臺(tái)底層的資源來(lái)保證毫秒級(jí)別的更新速度，我們這里通過(guò)記錄更新時(shí)間戳來(lái)驗(yàn)證更新的時(shí)效性;性能測(cè)試通過(guò)偽造上游數(shù)據(jù)和流量復(fù)制來(lái)驗(yàn)證整個(gè)鏈路的響應(yīng)時(shí)間和并發(fā)處理能力。

2) 模型的實(shí)時(shí)更新(Online Deep Learning)鏈路如何測(cè)試

為了拿到實(shí)時(shí)行為帶來(lái)的算法收益，Online Deep Learning(ODL)最近兩年興起，用戶實(shí)時(shí)行為特征數(shù)據(jù)也需要實(shí)時(shí)地訓(xùn)練到模型之中，在 10-15 分鐘的時(shí)間間隔里，在線服務(wù)的模型會(huì)被更新替代，留給模型驗(yàn)證的時(shí)間最多只有 10 分鐘的時(shí)間，這是 ODL 帶來(lái)的質(zhì)量挑戰(zhàn)。解這個(gè)問(wèn)題，我們有兩個(gè)方法同時(shí)工作。

(1)最主要的方法是建立 ODL 全鏈路質(zhì)量指標(biāo)監(jiān)控體系，這里的鏈路是指從樣本構(gòu)建到在線預(yù)測(cè)的全鏈路，包括樣本域的指標(biāo)校驗(yàn)和訓(xùn)練域指標(biāo)校驗(yàn)。

指標(biāo)選取上主要看是否跟效果相關(guān)聯(lián)，例如對(duì)于 ctr 預(yù)估方向，可以計(jì)算測(cè)試集上的 auc、gauc(Group auc，分組后的 auc)、score_avg(模型打分均值)等指標(biāo)，甚至計(jì)算train_auc & test_auc，pctr & actual_ctr 之間的差值(前者看是否過(guò)擬合，后者看打分準(zhǔn)度)是不是在一個(gè)合理的范圍內(nèi)。這里也有一個(gè)關(guān)鍵的點(diǎn)在于測(cè)試集的選取，我們建議測(cè)試集除了取下一個(gè)時(shí)間窗口的數(shù)據(jù)(用未見(jiàn)的數(shù)據(jù)測(cè)試模型的泛化性能)，還可以包含從過(guò)去一段時(shí)間(比如一周)的數(shù)據(jù)里面隨機(jī)抽樣的一部分?jǐn)?shù)據(jù)(用已見(jiàn)但全面的數(shù)據(jù)測(cè)試模型是否跑偏)。同時(shí)，這也降低了局部的異常測(cè)試樣本對(duì)評(píng)估指標(biāo)帶來(lái)的擾動(dòng)影響。

(2)除了指標(biāo)體系之外，我們?cè)O(shè)計(jì)了一個(gè)離線仿真的系統(tǒng)，在模型正式上線之前在仿真環(huán)境模擬打分校驗(yàn)。

簡(jiǎn)單來(lái)說(shuō)就是把需要上線的模型，在線下測(cè)試環(huán)境利用線上流量通過(guò)在線服務(wù)的組件打分模塊進(jìn)行一個(gè)提前的預(yù)打分，在這個(gè)打分過(guò)程中出現(xiàn)任何錯(cuò)誤都算校驗(yàn)不通過(guò)，打分正常的模型再對(duì)分?jǐn)?shù)進(jìn)行均值和分布的校驗(yàn)，打分校驗(yàn)不通過(guò)會(huì)直接拒絕上線。通過(guò)以上兩種方案，結(jié)合樣本與模型的監(jiān)控與攔截，可以極大概率低降低 ODL 的質(zhì)量風(fēng)險(xiǎn)。

3 性能壓測(cè)

對(duì)于由離線、在線兩部分構(gòu)成的AI系統(tǒng)，在線是響應(yīng)的是用戶實(shí)時(shí)訪問(wèn)請(qǐng)求，對(duì)響應(yīng)時(shí)間要求更高，在線系統(tǒng)的性能是這一部分的重點(diǎn)。離線的性能很大程度上取決于訓(xùn)練平臺(tái)在計(jì)算資源方面的調(diào)度使用，我們一般通過(guò)簡(jiǎn)單的源頭數(shù)據(jù)復(fù)制來(lái)做驗(yàn)證。對(duì)于在線系統(tǒng)，分為讀場(chǎng)景和寫(xiě)場(chǎng)景的性能測(cè)試，寫(xiě)場(chǎng)景的性能在第二部分實(shí)時(shí)更新鏈路的時(shí)效性部分已有介紹，這里主要講一下在線場(chǎng)景的讀場(chǎng)景的性能容量測(cè)試。

在線系統(tǒng)一般由二三十個(gè)不同的引擎模塊組成，引擎里的數(shù)據(jù) Data 與測(cè)試 Query 的不同都會(huì)極大的影響性能測(cè)試結(jié)果，同時(shí)也由于維護(hù)線下的性能測(cè)試環(huán)境與線上環(huán)境的數(shù)據(jù)同步工作需要極大的代價(jià)，我們目前的策略都是選擇在線上的某個(gè)生產(chǎn)集群里做性能容量測(cè)試。對(duì)于可以處理幾十萬(wàn) QPS(Query Per Second)的在線系統(tǒng)，難點(diǎn)在于如何精準(zhǔn)控制產(chǎn)生如此量級(jí)的并發(fā) Query，使用簡(jiǎn)單的多線程或多進(jìn)程的控制已經(jīng)無(wú)法解決，我們?cè)谶@里使用了一個(gè)爬山算法(梯度多倫迭代爬山法)來(lái)做流量的精準(zhǔn)控制，背后是上百臺(tái)的壓力測(cè)試機(jī)器遞增式地探測(cè)系統(tǒng)性能水位。

另外一個(gè)建設(shè)的方向是整個(gè)壓測(cè)流程的自動(dòng)化以及執(zhí)行上的無(wú)人值守，從基于場(chǎng)景的線上 Query 的自動(dòng)選取、到壓力生成、再到均值漂移算法的系統(tǒng)自動(dòng)化校驗(yàn)工作，整個(gè)壓測(cè)流程會(huì)如行云流水一般的按照預(yù)設(shè)自動(dòng)完成。配合著集群之間的切流，可以做到白+黑(白天夜間)的日常壓測(cè)，對(duì)線上水位和性能瓶頸的分析帶來(lái)了極大的便利。

4 效果的測(cè)試與評(píng)估

這是大數(shù)據(jù)應(yīng)用算法的重頭戲，由于算法的效果涉及到搜索廣告業(yè)務(wù)的直接受益(Revenue & GMV)，我們?cè)谶@個(gè)方向上也有比較大的投入，分為以下幾個(gè)子方向。

1) 特征與樣本的質(zhì)量與功效評(píng)估

通過(guò)對(duì)特征質(zhì)量(有無(wú)數(shù)據(jù)及分布問(wèn)題)，以及特征效用(對(duì)算法有無(wú)價(jià)值)兩個(gè)角度出發(fā)，在特征指標(biāo)計(jì)算上找到一些比較重要的指標(biāo)：缺失率占比、高頻取值、分布變化、取值相關(guān)性等。同時(shí)，在訓(xùn)練和評(píng)估過(guò)程中大量中間指標(biāo)與模型效果能產(chǎn)生因果關(guān)系，通過(guò)系統(tǒng)的分析建模張量、梯度、權(quán)重和更新量，能夠?qū)λ惴ㄕ{(diào)優(yōu)、問(wèn)題定位起到輔助決策作用。

而且，通過(guò)改進(jìn) AUC 算法，分析 ROC、PR、預(yù)估分布等更多評(píng)估指標(biāo)，能夠更全面的評(píng)估模型效果。隨著數(shù)據(jù)量級(jí)的增加，最近兩年我們?cè)诮：陀?xùn)練過(guò)程中使用了千億參數(shù)、萬(wàn)億樣本，Graph Deep Learning 也進(jìn)入百億點(diǎn)千億邊的階段，在如此浩瀚的數(shù)據(jù)海洋里，如何可視化特征樣本以及上述的各種指標(biāo)成為一個(gè)難點(diǎn)，我們?cè)?Google 開(kāi)源的 Tensorboard 的基礎(chǔ)上做了大量的優(yōu)化與改進(jìn)，幫助算法工程師在數(shù)據(jù)指標(biāo)的可視化、訓(xùn)練過(guò)程的調(diào)試、深度模型的可解釋性上給與了較好的支持。

2) 在線流量實(shí)驗(yàn)

算法項(xiàng)目在正式上線之前，模型需要在實(shí)驗(yàn)環(huán)境中引入真實(shí)的線上流量進(jìn)行效果測(cè)試和調(diào)優(yōu)，在第一代基于Google分層實(shí)驗(yàn)架構(gòu)的在線分層實(shí)驗(yàn)(原理 Google 論文“Overlapping Experiment Infrastructure More, Better, Faster Experimentation”)的基礎(chǔ)上，我們?cè)诓l(fā)實(shí)驗(yàn)、參數(shù)管理、參數(shù)間相互覆蓋、實(shí)驗(yàn)質(zhì)量缺乏保障、實(shí)驗(yàn)調(diào)試能力缺失、實(shí)驗(yàn)擴(kuò)展能力不足等方面做了很多的改進(jìn)，極大地提升了流量的并發(fā)復(fù)用與安全機(jī)制，達(dá)到真正的生產(chǎn)實(shí)驗(yàn)的目的。在效果上，通過(guò)在線實(shí)驗(yàn)平臺(tái)引入的真實(shí)流量的驗(yàn)證，使得模型的效果質(zhì)量得到極大的保障。

3) 數(shù)據(jù)效果評(píng)測(cè)

這里分兩塊：相關(guān)性評(píng)測(cè)與效果評(píng)測(cè)。相關(guān)性是相關(guān)性模型的一個(gè)很重要的評(píng)估指標(biāo)，我們主要通過(guò)數(shù)據(jù)評(píng)測(cè)來(lái)解決，通過(guò)對(duì)搜索展示結(jié)果的指標(biāo)評(píng)測(cè)，可以得到每次搜索結(jié)果的相關(guān)性分?jǐn)?shù)，細(xì)分指標(biāo)包括：經(jīng)典衡量指標(biāo) CSAT (Customer Satisfaction，包括非常滿意、滿意、一般、不滿意、非常不滿意)、凈推薦值 NPS (Net Promoter Score，由貝恩咨詢企業(yè)客戶忠誠(chéng)度業(yè)務(wù)的創(chuàng)始人 Fred Reichheld 在 2003 年提出，它通過(guò)測(cè)量用戶的推薦意愿，從而了解用戶的忠誠(chéng)度)、CES (Customer Effort Score，“客戶費(fèi)力度”是讓用戶評(píng)價(jià)使用某產(chǎn)品/服務(wù)來(lái)解決問(wèn)題的困難程度)、HEART 框架(來(lái)源于 Google，從愉悅度 Happiness、Engagement 參與度、Adoption 接受度、Retention 留存率、Task success 任務(wù)完成度)。

效果評(píng)估方面，我們采用了數(shù)據(jù)統(tǒng)計(jì)與分析的方法。在一個(gè)算法模型真正全量投入服務(wù)之前，我們需要準(zhǔn)確地驗(yàn)證這個(gè)模型的服務(wù)效果。除了第一部分介紹的離在線對(duì)比之外，我們需要更加客觀的數(shù)據(jù)指標(biāo)來(lái)加以佐證。這里我們采用了真實(shí)流量的 A/B 實(shí)驗(yàn)測(cè)試的方法，給即將發(fā)布的模型導(dǎo)入線上 5% 的流量，評(píng)估這 5% 流量和基準(zhǔn)桶的效果對(duì)比，從用戶體驗(yàn)(相關(guān)性)、平臺(tái)收益、客戶價(jià)值三個(gè)維度做各自實(shí)際指標(biāo)的分析，根據(jù)用戶的相關(guān)性評(píng)測(cè)結(jié)果、平臺(tái)的收入或者 GMV、客戶的 ROI 等幾個(gè)方面來(lái)觀測(cè)一個(gè)新模型對(duì)于買(mǎi)家、平臺(tái)、賣(mài)家的潛在影響到底是什么，并給最終的業(yè)務(wù)決策提供必要的數(shù)據(jù)支撐。流量從 5% 到 10%，再到 20% 以及 50%，在這個(gè)灰度逐漸加大至全量的過(guò)程中，無(wú)論是功能問(wèn)題、還是性能的問(wèn)題，甚至效果的問(wèn)題都會(huì)被探測(cè)到，這種方法進(jìn)一步降低了重大風(fēng)險(xiǎn)的發(fā)生。這是一個(gè)數(shù)據(jù)統(tǒng)計(jì)分析與技術(shù)的融合的方案，與本文所介紹的其他技術(shù)方法不同，比較獨(dú)特，但效果甚佳。

5 線上穩(wěn)定性

與其他業(yè)務(wù)的穩(wěn)定性建設(shè)類似，通過(guò)發(fā)布三板斧(灰度、監(jiān)控、回滾)來(lái)解決發(fā)布過(guò)程的質(zhì)量，通過(guò)線上的容災(zāi)演練、故障注入與演練(我們也是集團(tuán)開(kāi)源的混沌工程 Monkey King 的 C++ 版本的提供者)、安全紅藍(lán)對(duì)抗攻防來(lái)提升系統(tǒng)線上的穩(wěn)定性和可用性。另外在 AI Ops 和 Service Mesh 為基礎(chǔ)的運(yùn)維管控方向上，我們正在向著智能運(yùn)維、數(shù)據(jù)透視分析、自動(dòng)切流、自動(dòng)擴(kuò)縮容等方向努力。我們預(yù)測(cè)結(jié)合 Service Mesh 技術(shù)理念在 C++ 在線服務(wù)的演進(jìn)，系統(tǒng)會(huì)具備對(duì)業(yè)務(wù)應(yīng)用無(wú)侵入的流量標(biāo)定及變更標(biāo)定的能力，也就能夠?qū)崿F(xiàn)流量調(diào)度能力和隔離的能力。另外，紅藍(lán)攻防也將進(jìn)一步發(fā)展，自動(dòng)化、流程化將逐步成為混沌工程實(shí)施的標(biāo)準(zhǔn)形式。由于這一部分尚處于起步階段，這里不再過(guò)多介紹還沒(méi)有實(shí)現(xiàn)的內(nèi)容，但我們判定這個(gè)方向大有可為，與傳統(tǒng)運(yùn)維工作不同，更接近 Google 的 SRE(Site Reliability Engineering)理念。

6 AI 應(yīng)用的工程效能

主要解決在測(cè)試階段和研發(fā)階段提升效率的問(wèn)題，這個(gè)方向上我們以 DevOps 工具鏈建設(shè)為主，在開(kāi)發(fā)、測(cè)試、工程發(fā)布、模型發(fā)布(模型 debug 定位)、客戶反饋(體感評(píng)估、眾測(cè)、客戶問(wèn)題 debug)整個(gè)研發(fā)閉環(huán)所使用到的工具方面的建設(shè)。在我們?cè)O(shè)想的 DevOps 的場(chǎng)景下，開(kāi)發(fā)同學(xué)通過(guò)使用這些工具可以獨(dú)立完成需求的開(kāi)發(fā)測(cè)試發(fā)布及客戶反饋的處理。鑒于這個(gè)方向與測(cè)試本身關(guān)系不大，篇幅原因，這里也略過(guò)。

四 大數(shù)據(jù)應(yīng)用測(cè)試的未來(lái)

至此，關(guān)于大數(shù)據(jù)應(yīng)用測(cè)試的幾個(gè)主要問(wèn)題的解法已經(jīng)介紹完畢。關(guān)于大數(shù)據(jù)應(yīng)用測(cè)試的未來(lái)，我也有一些自己初步的判斷。

1 后端服務(wù)測(cè)試的工具化

這涉及到服務(wù)端的測(cè)試轉(zhuǎn)型問(wèn)題，我們的判斷是后端服務(wù)類型的測(cè)試不再需要專職的測(cè)試人員，開(kāi)發(fā)工程師在使用合理的測(cè)試工具的情況下可以更加高效地完成測(cè)試任務(wù)。專職的測(cè)試團(tuán)隊(duì)，未來(lái)會(huì)更多地專注于偏前端與用戶交互方面產(chǎn)品質(zhì)量的把控，跟產(chǎn)品經(jīng)理一樣，需要從用戶的角度思考產(chǎn)品質(zhì)量的問(wèn)題，產(chǎn)品的交付與交互的驗(yàn)證是這個(gè)方向的重點(diǎn)。多數(shù)的服務(wù)端的測(cè)試工作都是可以自動(dòng)化的，且很多 service 級(jí)別的驗(yàn)證也只有通過(guò)自動(dòng)化這種方式才能驗(yàn)證。相比較測(cè)試同學(xué)，開(kāi)發(fā)同學(xué)在 API 級(jí)別的自動(dòng)化代碼開(kāi)發(fā)方面能力會(huì)更強(qiáng)，更重要的是開(kāi)發(fā)同學(xué)自己做測(cè)試會(huì)減少測(cè)試同學(xué)與開(kāi)發(fā)同學(xué)之間的大量往返溝通的成本，而這個(gè)成本是整個(gè)發(fā)布環(huán)節(jié)中占比較大的部分。再者，第一部分介紹過(guò)，算法工程師在業(yè)務(wù)邏輯的理解上更加清晰。

所以，我們更希望后端的測(cè)試工作由工程或者算法工程師獨(dú)立完成，在這種新的生產(chǎn)關(guān)系模式下，測(cè)試同學(xué)更加專注于測(cè)試工具的研發(fā)，包括自動(dòng)化測(cè)試框架、測(cè)試環(huán)境部署工具、測(cè)試數(shù)據(jù)構(gòu)造與生成、發(fā)布冒煙測(cè)試工具、持續(xù)集成與部署等。這種模式也是目前 Google 一直在使用的測(cè)試模式，我們今年在這個(gè)方向下嘗試了轉(zhuǎn)型，在質(zhì)量變化和效率提升方面這兩方面效果還不錯(cuò)。作為國(guó)內(nèi)互聯(lián)網(wǎng)公司的率先進(jìn)行的測(cè)試轉(zhuǎn)型之路，相信可以給到各位同行一些借鑒。這里需要強(qiáng)調(diào)一點(diǎn)的是，雖然測(cè)試團(tuán)隊(duì)在這個(gè)方向上做了轉(zhuǎn)型，但后端測(cè)試這個(gè)事情還是需要繼續(xù)做，只是測(cè)試任務(wù)的執(zhí)行主體變成了開(kāi)發(fā)工程師，本文介紹的大量后端測(cè)試的技術(shù)和方向還會(huì)繼續(xù)存在。后端服務(wù)類測(cè)試團(tuán)隊(duì)轉(zhuǎn)型，除了效能工具之外，第五部分的線上穩(wěn)定性的建設(shè)是一個(gè)非常好的方向。

2 測(cè)試的線上化，既 TIP(Test In Production)

這個(gè)概念大概十年前由微軟的工程師提出。TIP 是未來(lái)測(cè)試方法上的一個(gè)方向，主要的考慮是以下三點(diǎn)。

1)一方面由于線下測(cè)試環(huán)境與真實(shí)線上環(huán)境總是存在一些差異，或者消除這種差異需要較大的持續(xù)成本，導(dǎo)致測(cè)試結(jié)論不夠置信。使用最多的就是性能測(cè)試或容量測(cè)試，后端服務(wù)的拓?fù)浞浅?fù)雜，且許多模塊都有可擴(kuò)展性，帶有不同的數(shù)據(jù)對(duì)性能測(cè)試的結(jié)果也有很大的影響，測(cè)試環(huán)境與生產(chǎn)環(huán)境的這種不同會(huì)帶來(lái)測(cè)試結(jié)果的巨大差異。另外，目前的生產(chǎn)集群都是異地多活，在夜里或者流量低谷的時(shí)候，單個(gè)集群就可以承擔(dān)起所有流量請(qǐng)求，剩下的集群可以很方便地用來(lái)壓測(cè)，這也給我們?cè)诰€上做性能測(cè)試帶來(lái)了可能性。最具典型的代表就是阿里的雙十一全鏈路壓測(cè)，今年基本上都是在白加黑的模式下完成的。

2)另外，許多真實(shí)的演練測(cè)試也只能在線上系統(tǒng)進(jìn)行，例如安全攻防和故障注入與演練，在線下測(cè)試環(huán)境是無(wú)法做到的。

3)最后，從質(zhì)量的最終結(jié)果上看，不管是發(fā)布前的線下測(cè)試，還是發(fā)布后的線上穩(wěn)定性建設(shè)，其目的都是為了減少系統(tǒng)故障的發(fā)生，把這兩部分融合在一起，針對(duì)最終的線上故障的減少去做目標(biāo)優(yōu)化工作，可以最大程度地節(jié)約和利用人力資源。我們判斷，線下測(cè)試與線上穩(wěn)定性的融合必將是一個(gè)歷史趨勢(shì)，這一領(lǐng)域統(tǒng)稱為技術(shù)風(fēng)險(xiǎn)的防控。

3 測(cè)試技術(shù)的智能化

見(jiàn)圖 3。類似對(duì)自動(dòng)駕駛的分級(jí)，智能化測(cè)試也有不同的成熟度模型，從人工測(cè)試、自動(dòng)化、輔助智能測(cè)試、高度智能測(cè)試。機(jī)器智能是一個(gè)工具，在測(cè)試的不同階段都有其應(yīng)用的場(chǎng)景，測(cè)試數(shù)據(jù)和用例設(shè)計(jì)階段、測(cè)試用例回歸執(zhí)行階段、測(cè)試結(jié)果的檢驗(yàn)階段、線上的指標(biāo)異常檢測(cè)諸多技術(shù)風(fēng)險(xiǎn)領(lǐng)域都可以用到不同的算法和模型。智能化測(cè)試是發(fā)展到一定階段的產(chǎn)物，前提條件就是數(shù)字化，自動(dòng)化測(cè)試是比較簡(jiǎn)單一種數(shù)字化。沒(méi)有做到數(shù)字化或者自動(dòng)化，其實(shí)是沒(méi)有智能分析與優(yōu)化的訴求的。

另外，在算法的使用上，一些簡(jiǎn)單算法的使用可能會(huì)有不錯(cuò)的效果，比較復(fù)雜的深度學(xué)習(xí)甚至強(qiáng)化學(xué)習(xí)算法的效果反而一般，原因或者難點(diǎn)在兩個(gè)地方，一個(gè)是特征提取和建模比較困難，第二個(gè)原因是測(cè)試運(yùn)行的樣本與反饋的缺失。但無(wú)論如何，運(yùn)用最新的算法技術(shù)去優(yōu)化不同的測(cè)試階段的效率問(wèn)題，是未來(lái)的一個(gè)方向。但我們同時(shí)判斷，完全的高度智能測(cè)試與無(wú)人駕駛一樣，目前還不成熟，主要不在算法與模型，而是測(cè)試數(shù)據(jù)的不足。

圖3 測(cè)試技術(shù)的智能化

阿里的搜索推薦與廣告系統(tǒng)的質(zhì)量建設(shè)之路，經(jīng)過(guò)近 10 年的不斷發(fā)展，在許多前輩的不斷努力付出之下，才能在如此眾多的細(xì)分領(lǐng)域方向上開(kāi)花結(jié)果，本文所介紹的方法也都濃縮在內(nèi)部的工具兵器之中，后面我們的想法還是逐漸開(kāi)源，回饋社區(qū)。限于篇幅，內(nèi)容又較雜多，很多技術(shù)細(xì)節(jié)這里并沒(méi)有辦法細(xì)細(xì)展開(kāi)。如果想了解更多，后繼可以關(guān)注即將由阿里經(jīng)濟(jì)體技術(shù)質(zhì)量小組主導(dǎo)出版的測(cè)試書(shū)籍《阿里巴巴測(cè)試之道》(電子工業(yè)出版社，暫定書(shū)名)，本文所介紹的大數(shù)據(jù)AI算法應(yīng)用測(cè)試被收錄在第六章。如果還是需要更加詳盡的了解，也歡迎大家加入我們的團(tuán)隊(duì)或者開(kāi)源社區(qū)，一起在以上的幾個(gè)方向做更加深入的研究與建設(shè)。