作者| 阿里文娛測試開發(fā)專家 熙閆責編 | 夕顏

簡介

優(yōu)酷搜索承擔著內容分發(fā)場的頭部兵的重任，海量的視頻內容都要依賴搜索觸達和呈現給 用戶，而且逐漸擴大范圍，開始向阿里文娛全系產品提供搜索服務和能力。

面對如此復雜且對穩(wěn)定性、精準性要求極高的系統，質量保障工作顯得尤為重要和極具挑 戰(zhàn)性。本文將為大家介紹視頻搜索的質量體系是如何構建和發(fā)揮作用的。

業(yè)務特點

1. 視頻搜索架構特點

• 支持復雜多樣的上層業(yè)務場景，業(yè)務邏輯復雜；

• 從搜索開始到結果返回的整個業(yè)務鏈路長，涉及的模塊及外部依賴多；

• 算法依賴數據，底層數據變更會引起上層算法結果變化。

2. 測試難點

• 業(yè)務鏈路長且復雜，用例覆蓋率等難以進行有效度量；

• 離線和實時數據變更如何影響業(yè)務，數據質量的監(jiān)控如何和業(yè)務緊密結合；

• 算法模塊存在復雜性及不可解釋性，算法效果難以進行有效評估；

• 海量數據中單個 badcase 無法說明問題，如何有效發(fā)掘共性的 badcase。

3. 質量保障方案

工程質量

1．回歸

回歸測試主要是上線發(fā)布前的測試，目的在于提前發(fā)現 bug，保證發(fā)布質量。目前各模塊 的回歸測試均已作為研發(fā)流程的一環(huán)，交由研發(fā)自行進行冒煙，不管是否走提測流程，均能在 一定程度上把控業(yè)務質量。

我們根據鏈路的分層，針對各層模塊進行了各模塊自身的功能回歸建設。各模塊測試用例 的自動化回歸依托于冒煙平臺，其可實現任意環(huán)境的快速回歸，目前已積累回歸用例 5000+， 定時線上巡檢，分鐘級發(fā)現問題。

2．監(jiān)控

1）功能監(jiān)控 仍然是根據鏈路的模塊劃分，進行分層監(jiān)控。監(jiān)控仍依托于冒煙平臺，并存儲各模塊日常。

冒煙監(jiān)控數據以及真實 bug 數據。目前通過巡檢已累計發(fā)現線上 bug50+。具體冒煙監(jiān)控數據大盤如下圖所示。

2）效果監(jiān)控線上效果監(jiān)控的目的在于快速發(fā)現線上效果問題，保證線上質量；此外通過固化每次效果

監(jiān)控數據，監(jiān)控線上效果問題的長期變化趨勢，以輔助研發(fā)進行算法迭代優(yōu)化，最大化利用人工評測數據。已經形成了生成監(jiān)控集合->定時監(jiān)控->發(fā)現問題->解決問題閉環(huán)的處理機制。

算法質量

1．數據

1）離線

借助集團已有平臺的監(jiān)控能力，定制業(yè)務細則，監(jiān)控流程基本分為幾個階段：存在原始表，創(chuàng)建對應表的分區(qū)及監(jiān)控規(guī)則，訂閱分區(qū)規(guī)則，原始表周期任務執(zhí)行結束自動觸發(fā) dqc 上對應表的對應分區(qū)的規(guī)則，如果異常會根據訂閱內容報警。

step1: 確定監(jiān)控哪些表。比如我們監(jiān)控 A 表，該節(jié)點監(jiān)控規(guī)則一旦失敗是否要中斷后續(xù)的 生產流程，如果需要中止后續(xù)的生產流程，那 stepn 配置強規(guī)則即可,此時要保證監(jiān)控規(guī)則是業(yè) 務合理的，當然一旦中止數據生產流程，我們要承受住多方的考驗，節(jié)點多次失敗賬號健康分 會受影響，任務的執(zhí)行也會受影響；如果不需要中止后續(xù)的生產流程，有兩種方案，一是創(chuàng)建 影子表，監(jiān)控影子表(浪費一個存儲周期的空間)；二是所有規(guī)則置為弱規(guī)則(短信告警無法判斷 報警的嚴重程度)。實踐中，重要的寬表數據我們采用了監(jiān)控影子表方案，次重要的表采用了對 原始表全部配置弱規(guī)則的方案。

step2：在監(jiān)控平臺創(chuàng)建分區(qū)，用來指定是要監(jiān)控哪天的數據。

step3:配置規(guī)則，規(guī)則可分為通用規(guī)則和特性規(guī)則。數據量重要度屬于 P0 級，采用數據量 絕對值>閾值；同時采用了 7 天趨勢絕對值變動在預警值在 10%，20%(不同業(yè)務閾值根據業(yè)務 需要設定)。表數據量突增和突降在優(yōu)酷場都不合理，所以采用了 7 天平均值波動+絕對值模式。 通用規(guī)則是各字段通用的規(guī)則，基本包含是否非空，是否為 0 等等，體現在數據監(jiān)控上面就是 非空的數據量|數據占比變化趨勢是否符合預期，值域非 0 的的數據量|數據占比變化趨勢是否符 合預期。特性規(guī)則需要視業(yè)務特性而定，采取單字段 max、min、均值、總量，組合特征數量、 變化率、空置率等個性化定制規(guī)則。

step4：訂閱，支持短信、釘釘機器人、郵件等等。

2）實時

把握整個實時流式計算的業(yè)務系統有幾個關鍵點：流式計算、數據服務、全鏈路、數據業(yè) 務（包括索引和摘要）。結合質量保障體系的線上、線下全鏈路閉環(huán)的理論體系去設計我們的整 體質量保障方案，如下圖所示：

2．算法

1）特征算子組件單測

UDF 在算法數據特征計算過程中是特別普遍的開發(fā)組件單元，實時和離線都有自己的 UDF 定義，UDF 也支持多種語言，UDF 本質上是一個函數，它以不同的工程資源形式附加到各個平 臺的項目中使用，UDF 的測試就可以簡化成函數的測試，歸結為輸入輸出的類函數單測的模式。 我們復用統一框架的執(zhí)行能力設計 UDF 單測模式如下：

UDF 從功能輸出來說分為三類：

第一類是有固定規(guī)則和處理邏輯的，這種可以通過輸入輸出來構建 case，判斷時候則判斷 固定的輸入是否等于輸出就行；

第二類則是一些通用的規(guī)則類或者一下非固定業(yè)務含義輸出的，這一類我們則通過正則匹 配或者通用規(guī)則來去校驗結果；

第三類則是算法模型類，這種我們通過構建算法的評測集合，去執(zhí)行評測集，獲得recall&accuracy 指標閾值來進行是是否通過校驗。

2）feature 列級測試

列級特征則是將整個列的計算邏輯以 UDF 算子為單元組件進行 DAG 邏輯編排，然后通過 編譯生成圖化邏輯來流式構建特征列。計算引擎原理如圖：

列級特征本質上就是一個圖化的 UDF 組合邏輯，可以看做是一個復雜圖化的計算函數，包 含了很多子 UDF 的圖化遍歷的邏輯。構建編譯器在列級圖化邏輯編排完成之后進行編譯會得到 該列的 DAG 信息。這個 DAG 信息就會作為列級的圖化邏輯屬性。當列級 feature 進行邏輯執(zhí)行 的時候會解析該 DAG 信息進行圖的遍歷依次執(zhí)行 UDF 算子。同樣的原理，我們在測試構建時 候我們構造列級特征檢測的 case 集合。

特征既有數據含義，同時也具備部分業(yè)務應用上的含義， 特征檢測我們可以結合數據規(guī)則和業(yè)務含義內容共同制定特征檢測機制。通過構建特征輸入集 來進行圖化邏輯執(zhí)行得到特征值，通過特征值的檢測、特征分布、特征業(yè)務屬性檢測幾個維度 去完成特征檢測。這個時候我們會通過統一的 trace 策略機制去記錄每個 UDF 的調用執(zhí)行情況， 以供追查 UDF 執(zhí)行錯誤和異常情況。

3）全圖化索引測試

前面 UDF 是算子組件維度的，而特征 feature 是列維度的，索引全列則是以行為維度的， 每行綜合多列。而全列索引特征構建是綜合多列 feature 的圖化邏輯形成的一個 pipline。pipline 以引擎索引分類為一個完整的 Pipline，比如 OCG 就是一個全列的完整 Pipline。所以 Pipline 級 別的數據測試則是以行維度的數據。

3．效果

1）效果基線 對搜索整條鏈路以及鏈路上影響算法的重要模塊如意圖分析模塊都建設了效果基線。

a）搜索鏈路效果基線建設。

效果測試集必須是動態(tài)的，這里采用 case 放在云文件或者數據平臺，當流量出現新詞的時 候隨時添加。要作為效果基線，必須保證測試集對應的預期結果必須是準確的，這里采用的機 制是評測同學維護。總體流程是評測同學在數據平臺維護效果基線 query、預期結果，代碼加載 數據進行規(guī)則判斷，噪音消除，失敗報警。

• 規(guī)則：檢測 TOP n 召回某種類型卡片，TOP n 只能召回某些 showids，聚合卡片中 TOPN 只能召回某些 showids，n 可配、showids 可配、卡片類型可配等等；

• 噪音消除：失敗重試、運營數據剔除、showid 可能出現在多種卡片，每種都需要相應業(yè) 務邏輯。

使用場景：

• 搜索鏈路所有模塊發(fā)布卡口；

• 被列為 AB test 期間關注的指標之一，指標一旦失敗，實驗回滾；

• 大流量桶的日常監(jiān)控，成功率要求 100%，一旦失敗必須及時修正。

b）意圖模塊

QP 的效果基線建設。方案：方案主要涉及意圖類型、測試集構建、驗證規(guī)則。效果基線要 check 哪些意圖呢？主要是從產品形態(tài)和算法使用情況來確定，每個意圖都涉及正樣本和負樣本；樣本數據取自線上已經識別出的意圖數據然后人工審核后分別放在對應的正樣本和負樣本，負樣本還有一部分 數據來自互斥意圖的正樣本數據；規(guī)則：同一個意圖對于不同的算法使用意圖不同，比如人物， “郭德綱于謙”切詞后這個詞屬于人物，但是不應該出人物卡。

使用場景：

• 發(fā)布卡口；

• 線上定時監(jiān)控：對于意圖模塊數據回流、代碼發(fā)布都會影響效果，數據回流是自動觸發(fā)， 數據是否正確未知，也就說明線上定時監(jiān)控的必要性。

2）搜索效果影響面自動評估

• 測試集構建：線上真實流量按照 SQV 進行分層、采樣(越偏頭部采樣密度越大)，線上流 量映射到測試集；

• 評測規(guī)則：分析用戶使用搜索的習慣，對用戶經常點擊的位置分別進行比對；

• 影響面計算：異常請求的 sqv 總和/所有 sqv 總和；

• 噪音消除：異常重試、去掉算法無關卡片，來保證影響面評測的準確度。

3）指標看板

將評測能力集成到監(jiān)控中，分鐘級運行，產出效果指標大盤，及時發(fā)現算法問題并能指導算法優(yōu)化。

用戶體驗

1．badcase 分類和挖掘

分析線上流量， badcase 挖掘主要集中在腰尾部高跳詞。除了流量分層還有一個重要的流 量就是實效性極高的熱點。

1）高跳 badcase 挖掘：通過競品對比等手段檢測出多種類型的 badcase，badcase 會映射到 具體原因上，直接進行專項優(yōu)化，優(yōu)化后的 case 會放入每次迭代，未優(yōu)化的 case 以 badcase 形 式存在 badcase 庫，后續(xù)效果迭代會運行這些數據，以檢測 badcase 的效果；

2）時效性分析：分析各大平臺的熱點內容，與自身做對比，并加入了相關性過濾邏輯。運 行機制：一天兩次，研發(fā)會及時處理報警內容，同時會進行長期優(yōu)化，現在 badcase 比例已明 顯下降。

2．輿情處理閉環(huán)

依托優(yōu)酷輿情發(fā)現和處理平臺優(yōu)酷聲音，聚合用戶觀點，針對搜不到、搜不好等問題，做專項優(yōu)化，已解決 5 大類 badcase。