推薦系統是效果導向的資料應用服務，在功能的“有”和“無”之間，有很長的效果“好”和“壞”的光譜。本文以使用者請求的粒度建立質量模型，通過資料血緣關聯了資料表、演算法模型、系統服務和使用者請求，並結合美團綜合業務的實踐進行了擴充泛化，希望能對大家有所幫助或啟發。
1 前言
美團到店綜合業務（以下簡稱到綜）是美團到店業務的重要板塊之一，涵蓋洗浴、KTV、美業、醫美、親子、結婚、運動健身、玩樂、教育培訓、家居、寵物、酒吧、生活服務等數十個重點細分行業，滿足數以億計使用者多樣化的本地生活需求。推薦系統在其中是實現供給和需求高效匹配的重要環節，是傳遞資料價值的出口，而推薦系統的質量決定了匹配效果的折損。如下圖 1 所示，資料經過數倉處理、演算法加工，再通過資料服務到各個業務系統，最後通過客戶端埋點又重新流轉回數倉，形成了資料的“飛輪效應”，而質量恰恰是這條鏈路中齒輪齧合的關鍵點，是提升效率和保障效果的重要前提。
質量保障要圍繞著度量開展，才能“看得見”、“理得清”、“改得準”。但是傳統的後臺服務質量指標並不能很好地描述當前“資料飛輪”的質量。我們希望通過綜合業務推薦系統的質量模型建設，為類似多業務線、效果導向的系統質量度量提供一種新的思考角度和實踐參考。
2 現狀分析
推薦系統是效果類系統，質量特點與功能類系統有所不同。功能類系統一般降級後會較為顯性地影響使用者體驗，但推薦結果返回 A 或者 A'，使用者很難有明顯感知。但實際上，如果匹配效果變差，就會直接影響到使用者的隱性體驗，需要被識別。功能類系統一般以可用性為核心來構建質量指標體系，在綜合業務推薦系統的業務實踐中，我們發現可用性等指標存在以下的侷限性：
- 可用性對部分缺陷不敏感：可用性是中斷頻率和持續時間的函式，體現的是系統持續提供服務的能力。只要系統的缺陷不影響對外提供服務，就不影響可用性，但有些實際上影響了使用者體驗。這裡的缺陷可能是意料中的（如主動降級），也可能是意料外的（模型更新延遲），都應該被納入質量的度量中。
- 可用性難以覆蓋資料的全鏈路：推薦系統的鏈路涵蓋了資料生產、加工、應用、分析等環節。一是可用性並不涉及資料表的質量，二是在可用效能度量的地方無法反應資料質量的全貌。資料質量需要考慮完整性、準確性、時效性、安全性等特徵，超出了可用性的範疇。國際知名學者吳恩達曾說過，人工智慧的價值 80% 取決於資料，推薦系統交付推薦效果（點選轉化率、交易轉化率、使用者停留時長等）的質量，也主要取決於資料的質量。
- 可用性難以反映業務差異性：美團到綜覆蓋上百個行業、幾十個頻道頁，推薦系統出於效率和成本考慮，業務間無法完全進行隔離，可用性的串並聯計算方式難以區分業務進行單獨評價。到綜不同業務差異很大，訪問頻次、流量高峰期、業務策略各不相同，從而質量的特點和問題分佈也不同。目前可用性的指標缺乏業務維度資訊，不利於指導精細化的質量運營。
在質量建設中，過去以故障等級作為目標，驗證週期長，具備偶然性，且目標和動作邏輯推導關係不強。另外，故障本身偏事後，這種問題驅動的思路不利於持續運營。總的來說，以可用性為目標，在實際落地計算時存在種種問題，所以我們考慮進行推薦系統的質量模型建設，以可用性為基礎，然後調整計算方式，進而指導精細化的質量運營。
3 建設思路
3.1 業務語境下的質量
建設質量模型，先回到對質量本質的理解。根據國際標準化組織（ISO）的定義，質量是反映實體滿足明確或隱含“需要”能力的特徵總和。另一個常用的質量概念是穩定性，穩定性的核心是讓系統長時間地執行在“預期”狀態。無論是質量還是穩定性，都要搞清楚系統需要滿足誰的需要和預期。在推薦的場景下，這個物件是產品和演算法。業務產品通過理解使用者場景，抽象使用者需求，向推薦團隊提出產品需求，體現為對外的產品迭代；同時推薦系統團隊內部相互協作，學習最佳優化模型策略，體現為資料團隊內部的演算法迭代。
如下圖 2 所示，在可用性的計算公式中，強調了長時間，而“需要” 和“預期” 只體現在對外提供服務上。這裡具有一定的合理性，一是可用性作為業界通用的指標，定義必然是泛化的，那麼質量的共性和底線就是對外提供服務；二是大多數後臺系統交付功能，對外提供服務大多在“有”和“無”之間，也有一定的空間給到服務降級。但是對於以效果為核心目標的推薦系統，在功能“有”和“無”之間，存有很長的效果“好”和“壞”的光譜。我們對推薦系統質量的思考迭代，核心改變就是從對外提供服務的“有”“無”，變更到對外提供服務的“好”“壞”，這也是改造可用性計算方式的出發點。
3.2 缺陷的考量和選擇
不滿足“需要”或者“預期”則會產生缺陷，缺陷是質量折損的原因。ISO/IEC 25010 Software Quality Model (2011) 軟體質量模型定義了軟體缺陷，可以看作是缺陷的全集，它包含了功能適用性、效能效率、相容性、可用性、可靠性、安全性、可維護性、可移植性 8 個特徵及 31 個子特徵。這裡面有一些質量特徵後臺服務不涉及（使用者介面美學、易學性等），有一些在當下認知中不構成 C 端質量的突出要素（模組性、共存性、不可抵賴性、可重複使用性等）。結合推薦系統的業務特色和高頻質量問題，現階段我們重點考慮如下圖 3 所示的質量特徵作為缺陷來源。
我們發現傳統可用性的度量，大多集中在可靠性、功能完整性、正確性方面，但是對於大部分的功能準確性、適當性以及安全性都缺乏度量，這些都與推薦的質量和效果緊密相關。準確性、適當性對效果的影響比較直觀，其他則較間接。比如安全性，以安全性中的爬蟲訪問為例，爬蟲由於訪問行為不符合真實人類的行為習慣，會影響 UVCTR 等核心指標的回收，從而造成效果誤判；同時如果不能識別和剔除爬蟲資料，噪聲會進一步影響模型訓練的準確性。資料質量問題是資料“飛輪效應”中的“毒丸”，會產生正反饋不斷放大缺陷。我們將在第四章計算規則中，量化上述的缺陷，擴充可用性的外延。
3.3 度量和計算的選型
可用性可以分為度量方式和計算方式：度量即我們常說的 N 個 9，計算則用平均故障間隔時間和平均恢復時間的函式來衡量。在度量方式上，業界常用的質量度量方式如下圖 4 所示：
度量方式選幾分制，不是現階段質量分的重點，可用性本身採用的 N 個 9 也足夠簡單可比較，我們重點考慮計算方式。由於到綜業務線眾多，推薦系統作為平臺型產品，系統與業務是 N:N 的關係，當下系統的可用性難以去計算每個行業、專案和業務的可用性。一個流量位置，它可以歸屬於休閒玩樂這個業務，可以歸屬於劇本殺這個專案，可以歸屬於核心展示主路徑的一環，也可以歸屬於內容推薦的一種，這種靈活的歸屬性，用請求來聚合計算是最合適的。如下圖 5 所示，如果可用性是請求的函式，它既可以包括上一節中我們關心的質量特徵，也可以在多個維度統計有業務意義的質量情況。
4 計算方式
根據上一章節的建設思路，從故障到缺陷，從推薦結果的“有”、“無”到推薦效果的“好”、“壞”，從整體到各個業務，我們描述了一個好的質量分應該有的特徵。這一章節我們著重在指標的計算邏輯上，選取關鍵缺陷，定義“成功的請求響應”，並增加質量分的業務聚合維度。
4.1 計算公式
結合 3.2 章節中描述的質量特徵，從成功請求佔比的角度評估系統質量，在實際落地計算時可以分成以下四個層面的缺陷：
- 系統層面：該請求觸發了系統異常，則為缺陷響應。常見的如召回超時、召回失敗、召回空結果等。
- 資料層面：該請求用到的資料出現異常，則為缺陷響應。常見的如供給數量異常、標籤分佈異常等，資料對使用者請求的實際影響，依賴資料血緣關係的建立和影響面評估。
- 演算法層面：該請求在召回和排序過程中，使用的特徵、模型、策略異常，則為缺陷響應。常見的如模型更新延遲、特徵缺失等，影響推薦的效果表達。
- 業務層面：該請求觸發了業務適當性或安全合規要求，則結果中包含以上結果的請求均為缺陷響應。常見的如運營反饋有供給質量、內容安全等嚴重的 Bad Case。
一條請求，在生命週期的任意環節經歷了缺陷，則在結果上定義為缺陷響應，具體的缺陷環節是分析下鑽的維度。我們從 3.2 章節的質量特徵和上述缺陷的四個層面選取典型問題（業務痛點、高頻質量問題）進行計算，以下圖 6 為例：
4.2 業務泛化
到綜推薦系統的業務特色是多業務線，行業差異大，推薦物料位置多，這折射到質量度量上，我們需要各個層次的聚合分析，進而指導精細化的運營，如下圖 7 所示：
到綜有很多中低頻業務，此時比值的波動受請求絕對值影響較大。針對這些場景，可以聚合部分小流量位，只在行業或者專案層面進行分鐘級的監控。
4.3 指標體系
如下圖 8 所示，我們將推薦系統響應的一條請求作為一次產品交付行為看待，這些請求中無缺陷的比例，就是推薦系統的質量分，是頂層的質量輸出指標。可以根據請求的生命週期，建立一級輸入指標，衡量核心流程的質量現狀，如召回缺陷率、排序缺陷率等。還可以再將一級指標進一步拆解，得到二級輸入指標，比如召回缺陷率比較高時，可以再去衡量召回空值率、召回超時率等。使用者的請求還可以根據業務進行垂直、橫向、時間維度聚合，得到有業務屬性的質量分，這樣會更有針對性，更加聚焦。
這套改進後的質量分，以請求為基本單位，相較於最初的可用性計算方式，在一定範圍內解決了它的侷限性：對缺陷敏感，可以包括資料鏈路帶來的影響，方便進行多業務維度的聚合分析。
4.4 血緣擴充
質量分以請求的粒度統計，在資料應用服務中，請求只是資料對外輸出的形式之一。在完成基礎的質量分後，請求的生命週期應該延展到資料全鏈路，這樣對質量的度量才完整。這時就依賴資料的血緣關係，將資料表 - 業務系統 - C 端流量關聯起來，構建全景的質量畫像，如下圖 9 所示：
血緣關係是人類社會由婚姻和生育產生的人際關係，如父母和子女的關係、兄弟和姐妹的關係，以及由此派生出的其他親屬關係，資料也可以通過融合、轉換產生資料的血緣關係。資料的血緣關係分資料庫、資料表、欄位不同級別，一般用於資料資產（引用熱度計算、理解資料上下文）、資料開發（影響分析、歸因分析）、資料治理（鏈路狀態追蹤、數倉治理）、資料安全（安全合規檢查、標籤傳播）四個方面。在目前推薦系統質量分的思路下，主要用影響分析去擴充質量分，將所有途徑故障節點的請求都打上標記，扣除相應分數。
在推薦系統的業務語義下，我們定義了六種業務後設資料：快照、方案、元件、索引、模型、特徵，基於後設資料我們構建血緣，可以分為任務接入、血緣解析、資料匯出。任務接入分為採集模組和入庫模組，當任務接入完成後，將通過圖資料庫儲存節點及節點的關係，利用圖演算法建立血緣。建立血緣之後，節點本身的異常支援系統發現和人工標記，影響分析則可以自動完成。當節點出現異常則進行訊息通知，異常資訊會沿著血緣傳播，繼而影響下游環節的質量分計算。
當異常波及到使用者端，我們嘗試用業務語言重新描述損失。根據到綜收入模型，可以計算出各個業務線每個意向 UV 的價值（使用者訪問商戶詳情頁、團單詳情頁稱之為意向訪問），再利用該流量位周同比的訪問情況，自動推導業務損失。
5 指標運營
5.1 系統實現
質量分的系統實現方式依賴於埋點和診斷。推薦全鏈路包含引數輸入、召回前置處理、召回、召回後置處理、粗排、精排、重排等多個環節，每個環節都有可能出故障，因此資料採集需要覆蓋執行時異常、各環節的關鍵輸入輸出資訊等。如下圖 10 所示，我們通過 Kafka 非同步收集埋點資料，然後分場景進行資料處理：生產環境下，近實時 ES 構建索引，提供近 4 天快速查詢服務，4 天前的日誌入 Hive 歸檔，另外通過 Flink 引擎解析埋點資料，經過必要的診斷後，實時計算分數並推送告警資訊；測試環境下，日誌實時分揀至 MySQL，方便測試排查。最後，結構化展示推薦不同階段的質量情況，提高了結果的可讀性。
分數體系的完善需要逐步推進，對於推薦系統，沒有推薦結果是最嚴重的質量問題。我們首先採集和計算的是推薦空結果，對應一級指標裡的結果缺陷率、召回缺陷率和二級指標裡的結果空值率、召回空值率等。同時由於到綜的業務特性，行業眾多、供給時空分佈不均，大量可交叉的篩選條件也會有空結果，影響質量分的計算。
如何剔除符合業務預期的空結果，消除質量分噪聲，在實現埋點的基礎上，診斷就變得非常重要。以空結果為例，我們主要從引數診斷、資料診斷、鏈路診斷三個環節去識別。其中資料診斷指的是當線上篩選條件出現空結果時，回源二次校驗底層資料，查詢底表資料是否為空。如果底表確實沒有相關供給，則沉澱免告警規則，設定免告警有效期，在一段時間內，當前城市當前行業確實缺少相關供給，該空結果不納入質量分計算。如果底表存在供給，則說明是資料加工或者服務過程中出現了異常，導致無法召回，則再經過鏈路診斷確定出錯環節，納入相應質量分計算。
如何建立規則匹配機制（即規則引擎）是診斷引擎的關鍵。當下的規則引擎選擇非常多，例如 EasyRule、Drools、Zools、Aviator 等。根據上文分析，診斷引擎需要能夠對請求引數、推薦鏈路以及底層資料進行規則診斷。對於請求引數、推薦鏈路的診斷均可通過記憶體引數進行診斷，而資料診斷則需要從第三方儲存中獲得資訊，因此必然有一部分需要定製開發。考慮人員工具使用成熟度以及便利性來說，Aviator 表示式引擎較為合適。為契合需要診斷的內容，設計的表示式診斷原語如下：
//引數診斷-原語表達
//是否符合一定引數的診斷原語
global:check=aviator[cityId !=nil && include(string.split('1,2,3,4,5,6,7,8,9,10,16,17',','),str(cityId))]
//鏈路診斷-原語表達
//1、召回異常診斷原語
global:recallException=param[${recall#exception#}],
global:check=aviator[recallException!=nil && recallException !='' ]
//2、召回空無異常的診斷原語
global:recallEmpty=param[${recall#after#}],
global:check=aviator[recallEmpty!=nil && recallEmpty !='' ]
//3、召回不為空，過濾規則執行後為空的診斷原語
global:recallEmptyCode=param[${recall#after#}],
global:predictFiltersEmptyCode=param[${predict#after#filters#}],
global:check=aviator[(recallEmptyCode ==nil || recallEmptyCode =='') && predictFiltersEmptyCode !=nil]
//4、執行某一具體過濾規則後，導致無結果的匹配
global:filterEmptyCode=param[${PredictStage#filter#after#_compSkRef#}],
global:check=aviator[filterEmptyCode !=nil && filterEmptyCode =='deleteItemByConditionalFilter' ]
//資料診斷-原語表達（判斷底層是否有資料，若沒有則為true，否則為false）
global:keys=keySpread[@prefix 138_ymtags_][@crossOrder city_${cityId}_platform_${platformNo}_surgery_prj_${genericLvlIds}],
global:cnt=cellar@cellar[@count ${keys}],
global:check=aviator[cnt !=nil && cnt !='' && long(cnt) <= 0 ]5.2 告警跟進
質量分可以用於實時監控和運營覆盤，需要團隊成員及時跟進異動。一般公司通用的告警系統，都是基於服務名稱粒度配置告警接收人。推薦系統這類平臺型的服務，通過統一的介面提供服務，但是模型策略卻是由不同的同學維護，業務間存在一定的行業知識和理解門檻。預設廣播式的告警，容易引起告警風暴，每個人無法專注於自己模組的問題，有時也會遺漏告警。
出於跟進率的考量（如下圖 11 所示），我們基於現有告警二次開發了跟進功能，將特定流量位的告警路由到專屬負責人，並記錄跟進狀態流轉，便於及時周知及事後覆盤。在運營方面，我們通過資料包表搭建質量分看板，定期回顧不同業務的質量波動情況。
5.3 治理效果
質量分的落地以結果空值率為抓手，按流程拆解採集召回空值率、模型預測空值率、重排運算元空值率，並按業務聚合成平臺、業務、形態、專案、流量位多個維度。治理動作和成果分為以下幾個方面：
- 通過埋點和診斷，判斷當前的空結果是供給問題還是質量問題，排除 98% 的空結果不納入質量分計算，避免誤告警，日均空結果告警數從 40 個降低到 5 個。
- 基於分析鏈路過程中各環節的空值率，採取治理措施，包括資料規範（資料分層標準化、標籤打標規範）、服務架構（業務隔離、底層資料雙介質、降級）、變更規範（配置上線流水線檢查、流量回放），將空結果系統發現率保持在 60% 以上。
- 定製化開發告警路由，避免告警廣播，支援標記跟進狀態，空結果告警跟進率由無法統計，到核心流量位 100% 跟進。
經過空結果的治理和識別，目前核心流量位空值率為 0.01%，即保證核心流量位 99.99% 的請求有結果，在建設質量分的同時，保證系統發現率和告警跟進率。
5.4 資產沉澱
推薦系統傳遞的是資料的價值，只有資料被資產化，這種價值才是可持續可增值的。建設推薦系統質量模型的過程，其實也在做資料資產化沉澱。資料在採集後變成資產，一般要滿足以下四個條件：可流動、可計量、可管控、可增值，這些在第四章計算方式中都有所涉及。
指標運營的過程，同時也是沉澱質量知識資產的過程。軟體缺陷模型究竟如何影響最終的產品交付質量，他們之間是否有相關性、因果性，這種影響是顯式地參與分數計算，還是間接影響的。在質量分運營過程中，我們可以逐漸填補腦海中的質量地圖，形成指標間、缺陷間、指標和缺陷間的拓撲關係，這是一個將質量資產化的過程。比如通過推薦系統的業務實踐，我們發現 80% 的線上故障是由於釋出引起的，釋出故障中的 80% 又是由於資料釋出引起的，這可以指導我們通過治理資料釋出減少線上故障。
6 未來規劃
我們以可用性為基礎，調整計算方式，建立了多層次的推薦系統質量分，並擴充到各種推薦物料、各個業務模組，核心是我們完成了從對外提供服務的“有無”到對外提供服務的“好壞”的認知迭代，這也是質量精細化運營的基礎。後續的規劃，一方面是繼續充實質量模型的計算和鏈路覆蓋；另一方面，我們會基於質量模型做更多的質量治理工作，後續將重點思考與迭代的一些方向包括：
- 通過完善埋點和診斷，逐步落地質量分體系中的各層指標，豐富質量分的內涵，容納更多的質量問題。
- 通過建設多層次的推薦柔性降級，迭代對於質量分的理解，量化不同降級對於系統的影響。
- 優化資料血緣的準確性、覆蓋率和時效性，更加正確快速評估某一個環節質量問題的影響面。
7 本文作者
勇皓、根根、王欣、賀賀、俐聰等，均來自美團到店平臺技術部/到綜業務資料團隊。
閱讀美團技術團隊更多技術文章合集
前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試
| 在公眾號選單欄對話方塊回覆【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。
| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。