作者：勇皓 根根 王欣等

1 前言

美團到店綜合業務（以下簡稱到綜）是美團到店業務的重要板塊之一，涵蓋洗浴、KTV、美業、醫美、親子、結婚、運動健身、玩樂、教育培訓、家居、寵物、酒吧、生活服務等數十個重點細分行業，滿足數以億計用戶多樣化的本地生活需求。

推薦系統在其中是實現供給和需求高效匹配的重要環節，是傳遞數據價值的出口，而推薦系統的質量決定了匹配效果的折損。如下圖 1 所示，數據經過數倉處理、算法加工，再通過數據服務到各個業務系統，最后通過客戶端埋點又重新流轉回數倉，形成了數據的“飛輪效應”，而質量恰恰是這條鏈路中齒輪嚙合的關鍵點，是提升效率和保障效果的重要前提。

質量保障要圍繞著度量開展，才能“看得見”、“理得清”、“改得準”。但是傳統的后臺服務質量指標并不能很好地描述當前“數據飛輪”的質量。我們希望通過綜合業務推薦系統的質量模型建設，為類似多業務線、效果導向的系統質量度量提供一種新的思考角度和實踐參考。

圖1 推薦系統的“數據飛輪”

2 現狀分析

推薦系統是效果類系統，質量特點與功能類系統有所不同。功能類系統一般降級后會較為顯性地影響用戶體驗，但推薦結果返回 A 或者 A'，用戶很難有明顯感知。但實際上，如果匹配效果變差，就會直接影響到用戶的隱性體驗，需要被識別。功能類系統一般以可用性為核心來構建質量指標體系，在綜合業務推薦系統的業務實踐中，我們發現可用性等指標存在以下的局限性：

• 可用性對部分缺陷不敏感：可用性是中斷頻率和持續時間的函數，體現的是系統持續提供服務的能力。只要系統的缺陷不影響對外提供服務，就不影響可用性，但有些實際上影響了用戶體驗。這里的缺陷可能是意料中的（如主動降級），也可能是意料外的（模型更新延遲），都應該被納入質量的度量中。
• 可用性難以覆蓋數據的全鏈路：推薦系統的鏈路涵蓋了數據生產、加工、應用、分析等環節。一是可用性并不涉及數據表的質量，二是在可用性能度量的地方無法反應數據質量的全貌。數據質量需要考慮完整性、準確性、時效性、安全性等特征，超出了可用性的范疇。國際知名學者吳恩達曾說過，人工智能的價值 80% 取決于數據，推薦系統交付推薦效果（點擊轉化率、交易轉化率、用戶停留時長等）的質量，也主要取決于數據的質量。
• 可用性難以反映業務差異性：美團到綜覆蓋上百個行業、幾十個頻道頁，推薦系統出于效率和成本考慮，業務間無法完全進行隔離，可用性的串并聯計算方式難以區分業務進行單獨評價。到綜不同業務差異很大，訪問頻次、流量高峰期、業務策略各不相同，從而質量的特點和問題分布也不同。目前可用性的指標缺乏業務維度信息，不利于指導精細化的質量運營。

在質量建設中，過去以故障等級作為目標，驗證周期長，具備偶然性，且目標和動作邏輯推導關系不強。另外，故障本身偏事后，這種問題驅動的思路不利于持續運營。總的來說，以可用性為目標，在實際落地計算時存在種種問題，所以我們考慮進行推薦系統的質量模型建設，以可用性為基礎，然后調整計算方式，進而指導精細化的質量運營。

3 建設思路

3.1 業務語境下的質量

建設質量模型，先回到對質量本質的理解。根據國際標準化組織（ISO）的定義，質量是反映實體滿足明確或隱含“需要”能力的特征總和。另一個常用的質量概念是穩定性，穩定性的核心是讓系統長時間地運行在“預期”狀態。無論是質量還是穩定性，都要搞清楚系統需要滿足誰的需要和預期。在推薦的場景下，這個對象是產品和算法。業務產品通過理解用戶場景，抽象用戶需求，向推薦團隊提出產品需求，體現為對外的產品迭代；同時推薦系統團隊內部相互協作，學習最佳優化模型策略，體現為數據團隊內部的算法迭代。

如下圖 2 所示，在可用性的計算公式中，強調了長時間，而“需要” 和“預期” 只體現在對外提供服務上。這里具有一定的合理性，一是可用性作為業界通用的指標，定義必然是泛化的，那么質量的共性和底線就是對外提供服務；二是大多數后臺系統交付功能，對外提供服務大多在“有”和“無”之間，也有一定的空間給到服務降級。但是對于以效果為核心目標的推薦系統，在功能“有”和“無”之間，存有很長的效果“好”和“壞”的光譜。我們對推薦系統質量的思考迭代，核心改變就是從對外提供服務的“有”“無”，變更到對外提供服務的“好”“壞”，這也是改造可用性計算方式的出發點。

圖2 對缺陷的認知影響質量度量

3.2 缺陷的考量和選擇

不滿足“需要”或者“預期”則會產生缺陷，缺陷是質量折損的原因。ISO/IEC 25010 Software Quality Model (2011) 軟件質量模型定義了軟件缺陷，可以看作是缺陷的全集，它包含了功能適用性、性能效率、兼容性、可用性、可靠性、安全性、可維護性、可移植性 8 個特征及 31 個子特征。這里面有一些質量特征后臺服務不涉及（用戶界面美學、易學性等），有一些在當下認知中不構成 C 端質量的突出要素（模塊性、共存性、不可抵賴性、可重復使用性等）。結合推薦系統的業務特色和高頻質量問題，現階段我們重點考慮如下圖 3 所示的質量特征作為缺陷來源。

圖3 推薦系統的質量特征

我們發現傳統可用性的度量，大多集中在可靠性、功能完整性、正確性方面，但是對于大部分的功能準確性、適當性以及安全性都缺乏度量，這些都與推薦的質量和效果緊密相關。準確性、適當性對效果的影響比較直觀，其他則較間接。比如安全性，以安全性中的爬蟲訪問為例，爬蟲由于訪問行為不符合真實人類的行為習慣，會影響 UVCTR 等核心指標的回收，從而造成效果誤判；同時如果不能識別和剔除爬蟲數據，噪聲會進一步影響模型訓練的準確性。數據質量問題是數據“飛輪效應”中的“毒丸”，會產生正反饋不斷放大缺陷。我們將在第四章計算規則中，量化上述的缺陷，拓展可用性的外延。

3.3 度量和計算的選型

可用性可以分為度量方式和計算方式：度量即我們常說的 N 個 9，計算則用平均故障間隔時間和平均恢復時間的函數來衡量。在度量方式上，業界常用的質量度量方式如下圖 4 所示：

圖4 度量方式

度量方式選幾分制，不是現階段質量分的重點，可用性本身采用的 N 個 9 也足夠簡單可比較，我們重點考慮計算方式。由于到綜業務線眾多，推薦系統作為平臺型產品，系統與業務是 N:N 的關系，當下系統的可用性難以去計算每個行業、項目和業務的可用性。一個流量位置，它可以歸屬于休閑玩樂這個業務，可以歸屬于劇本殺這個項目，可以歸屬于核心展示主路徑的一環，也可以歸屬于內容推薦的一種，這種靈活的歸屬性，用請求來聚合計算是最合適的。如下圖 5 所示，如果可用性是請求的函數，它既可以包括上一節中我們關心的質量特征，也可以在多個維度統計有業務意義的質量情況。

圖5 從請求的角度度量質量

4 計算方式

根據上一章節的建設思路，從故障到缺陷，從推薦結果的“有”、“無”到推薦效果的“好”、“壞”，從整體到各個業務，我們描述了一個好的質量分應該有的特征。這一章節我們著重在指標的計算邏輯上，選取關鍵缺陷，定義“成功的請求響應”，并增加質量分的業務聚合維度。

4.1 計算公式

結合 3.2 章節中描述的質量特征，從成功請求占比的角度評估系統質量，在實際落地計算時可以分成以下四個層面的缺陷：

• 系統層面：該請求觸發了系統異常，則為缺陷響應。常見的如召回超時、召回失敗、召回空結果等。
• 數據層面：該請求用到的數據出現異常，則為缺陷響應。常見的如供給數量異常、標簽分布異常等，數據對用戶請求的實際影響，依賴數據血緣關系的建立和影響面評估。
• 算法層面：該請求在召回和排序過程中，使用的特征、模型、策略異常，則為缺陷響應。常見的如模型更新延遲、特征缺失等，影響推薦的效果表達。
• 業務層面：該請求觸發了業務適當性或安全合規要求，則結果中包含以上結果的請求均為缺陷響應。常見的如運營反饋有供給質量、內容安全等嚴重的 Bad Case。

一條請求，在生命周期的任意環節經歷了缺陷，則在結果上定義為缺陷響應，具體的缺陷環節是分析下鉆的維度。我們從 3.2 章節的質量特征和上述缺陷的四個層面選取典型問題（業務痛點、高頻質量問題）進行計算，以下圖 6 為例：

圖6 質量分計算方法

4.2 業務泛化

到綜推薦系統的業務特色是多業務線，行業差異大，推薦物料位置多，這折射到質量度量上，我們需要各個層次的聚合分析，進而指導精細化的運營，如下圖 7 所示：

圖7 各業務層次的聚合分析

到綜有很多中低頻業務，此時比值的波動受請求絕對值影響較大。針對這些場景，可以聚合部分小流量位，只在行業或者項目層面進行分鐘級的監控。

4.3 指標體系

如下圖 8 所示，我們將推薦系統響應的一條請求作為一次產品交付行為看待，這些請求中無缺陷的比例，就是推薦系統的質量分，是頂層的質量輸出指標。可以根據請求的生命周期，建立一級輸入指標，衡量核心流程的質量現狀，如召回缺陷率、排序缺陷率等。還可以再將一級指標進一步拆解，得到二級輸入指標，比如召回缺陷率比較高時，可以再去衡量召回空值率、召回超時率等。用戶的請求還可以根據業務進行垂直、橫向、時間維度聚合，得到有業務屬性的質量分，這樣會更有針對性，更加聚焦。

圖8 質量指標體系

這套改進后的質量分，以請求為基本單位，相較于最初的可用性計算方式，在一定范圍內解決了它的局限性：對缺陷敏感，可以包括數據鏈路帶來的影響，方便進行多業務維度的聚合分析。

4.4 血緣拓展

質量分以請求的粒度統計，在數據應用服務中，請求只是數據對外輸出的形式之一。在完成基礎的質量分后，請求的生命周期應該延展到數據全鏈路，這樣對質量的度量才完整。這時就依賴數據的血緣關系，將數據表 - 業務系統 - C 端流量關聯起來，構建全景的質量畫像，如下圖 9 所示：

圖9 推薦系統的數據血緣

血緣關系是人類社會由婚姻和生育產生的人際關系，如父母和子女的關系、兄弟和姐妹的關系，以及由此派生出的其他親屬關系，數據也可以通過融合、轉換產生數據的血緣關系。數據的血緣關系分數據庫、數據表、字段不同級別，一般用于數據資產（引用熱度計算、理解數據上下文）、數據開發（影響分析、歸因分析）、數據治理（鏈路狀態追蹤、數倉治理）、數據安全（安全合規檢查、標簽傳播）四個方面。在目前推薦系統質量分的思路下，主要用影響分析去拓展質量分，將所有途徑故障節點的請求都打上標記，扣除相應分數。

在推薦系統的業務語義下，我們定義了六種業務元數據：快照、方案、組件、索引、模型、特征，基于元數據我們構建血緣，可以分為任務接入、血緣解析、數據導出。任務接入分為采集模塊和入庫模塊，當任務接入完成后，將通過圖數據庫存儲節點及節點的關系，利用圖算法建立血緣。建立血緣之后，節點本身的異常支持系統發現和人工標記，影響分析則可以自動完成。當節點出現異常則進行消息通知，異常信息會沿著血緣傳播，繼而影響下游環節的質量分計算。

當異常波及到用戶端，我們嘗試用業務語言重新描述損失。根據到綜收入模型，可以計算出各個業務線每個意向 UV 的價值（用戶訪問商戶詳情頁、團單詳情頁稱之為意向訪問），再利用該流量位周同比的訪問情況，自動推導業務損失。

5 指標運營

5.1 系統實現

質量分的系統實現方式依賴于埋點和診斷。推薦全鏈路包含參數輸入、召回前置處理、召回、召回后置處理、粗排、精排、重排等多個環節，每個環節都有可能出故障，因此數據采集需要覆蓋運行時異常、各環節的關鍵輸入輸出信息等。如下圖 10 所示，我們通過 Kafka 異步收集埋點數據，然后分場景進行數據處理：生產環境下，近實時 ES 構建索引，提供近 4 天快速查詢服務，4 天前的日志入 Hive 歸檔，另外通過 Flink 引擎解析埋點數據，經過必要的診斷后，實時計算分數并推送告警信息；測試環境下，日志實時分揀至 MySQL，方便測試排查。最后，結構化展示推薦不同階段的質量情況，提高了結果的可讀性。

圖10 質量分的系統實現

分數體系的完善需要逐步推進，對于推薦系統，沒有推薦結果是最嚴重的質量問題。我們首先采集和計算的是推薦空結果，對應一級指標里的結果缺陷率、召回缺陷率和二級指標里的結果空值率、召回空值率等。同時由于到綜的業務特性，行業眾多、供給時空分布不均，大量可交叉的篩選條件也會有空結果，影響質量分的計算。

如何剔除符合業務預期的空結果，消除質量分噪聲，在實現埋點的基礎上，診斷就變得非常重要。以空結果為例，我們主要從參數診斷、數據診斷、鏈路診斷三個環節去識別。其中數據診斷指的是當線上篩選條件出現空結果時，回源二次校驗底層數據，查詢底表數據是否為空。如果底表確實沒有相關供給，則沉淀免告警規則，設置免告警有效期，在一段時間內，當前城市當前行業確實缺少相關供給，該空結果不納入質量分計算。

如果底表存在供給，則說明是數據加工或者服務過程中出現了異常，導致無法召回，則再經過鏈路診斷確定出錯環節，納入相應質量分計算。如何建立規則匹配機制（即規則引擎）是診斷引擎的關鍵。當下的規則引擎選擇非常多，例如 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 所示），我們基于現有告警二次開發了跟進功能，將特定流量位的告警路由到專屬負責人，并記錄跟進狀態流轉，便于及時周知及事后復盤。在運營方面，我們通過數據報表搭建質量分看板，定期回顧不同業務的質量波動情況。

圖11 告警跟進流程

5.3 治理效果

質量分的落地以結果空值率為抓手，按流程拆解采集召回空值率、模型預測空值率、重排算子空值率，并按業務聚合成平臺、業務、形態、項目、流量位多個維度。治理動作和成果分為以下幾個方面：

• 通過埋點和診斷，判斷當前的空結果是供給問題還是質量問題，排除 98% 的空結果不納入質量分計算，避免誤告警，日均空結果告警數從 40 個降低到 5 個。
• 基于分析鏈路過程中各環節的空值率，采取治理措施，包括數據規范（數據分層標準化、標簽打標規范）、服務架構（業務隔離、底層數據雙介質、降級）、變更規范（配置上線流水線檢查、流量回放），將空結果系統發現率保持在 60% 以上。
• 定制化開發告警路由，避免告警廣播，支持標記跟進狀態，空結果告警跟進率由無法統計，到核心流量位 100% 跟進。

經過空結果的治理和識別，目前核心流量位空值率為 0.01%，即保證核心流量位 99.99% 的請求有結果，在建設質量分的同時，保證系統發現率和告警跟進率。

5.4 資產沉淀

推薦系統傳遞的是數據的價值，只有數據被資產化，這種價值才是可持續可增值的。建設推薦系統質量模型的過程，其實也在做數據資產化沉淀。數據在采集后變成資產，一般要滿足以下四個條件：可流動、可計量、可管控、可增值，這些在第四章計算方式中都有所涉及。指標運營的過程，同時也是沉淀質量知識資產的過程。軟件缺陷模型究竟如何影響最終的產品交付質量，他們之間是否有相關性、因果性，這種影響是顯式地參與分數計算，還是間接影響的。在質量分運營過程中，我們可以逐漸填補腦海中的質量地圖，形成指標間、缺陷間、指標和缺陷間的拓撲關系，這是一個將質量資產化的過程。比如通過推薦系統的業務實踐，我們發現 80% 的線上故障是由于發布引起的，發布故障中的 80% 又是由于數據發布引起的，這可以指導我們通過治理數據發布減少線上故障。

6 未來規劃

我們以可用性為基礎，調整計算方式，建立了多層次的推薦系統質量分，并拓展到各種推薦物料、各個業務模塊，核心是我們完成了從對外提供服務的“有無”到對外提供服務的“好壞”的認知迭代，這也是質量精細化運營的基礎。后續的規劃，一方面是繼續充實質量模型的計算和鏈路覆蓋；另一方面，我們會基于質量模型做更多的質量治理工作，后續將重點思考與迭代的一些方向包括：

• 通過完善埋點和診斷，逐步落地質量分體系中的各層指標，豐富質量分的內涵，容納更多的質量問題。
• 通過建設多層次的推薦柔性降級，迭代對于質量分的理解，量化不同降級對于系統的影響。
• 優化數據血緣的準確性、覆蓋率和時效性，更加正確快速評估某一個環節質量問題的影響面。

7 本文作者

勇皓、根根、王欣、賀賀、俐聰等，均來自美團到店平臺技術部/到綜業務數據團隊。