背景
在模型迭代和上線過程中,我們常常需要確認新添加或修改的特徵是否按預期生效。有時,即使特徵已線上上發生變化,模型的最終輸出分數卻沒有變化,這使得判斷特徵的有效性變得困難。本文檔旨在提供一套系統化的方法,通過深層分析來校正特徵是否被模型正確接收和處理。
前置要求
已成功部署用於排序的模型服務(例如,在PAI-EAS上)。
已成功部署PAI-Rec引擎服務,並且在引擎或AB實驗配置中,已配置調用上述模型服務並使用了目標特徵。
校正特徵是否生效
核心思路是:捕獲一次真實的線上請求,將其特徵資料本地化,然後通過修改特定特徵值並重新請求,觀察特徵進入模型前的變化來判斷特徵是否被正確處理。
步驟一:捕獲線上請求的特徵資料
向Recommendation Engine服務發送Debug請求。登入PAI-Rec控制台,左側菜單單擊排查工具 > 推薦結果診斷,選擇相應環境,開啟偵錯模式,單擊診斷發送請求。
請確保該請求能夠路由到您要驗證的模型服務(例如,通過使用者白名單或設定為100%流量)。當模型服務接收到Debug請求時,它會自動將引擎傳入的特徵資料以Protobuf(PB)格式儲存到服務的掛載目錄中。

定位並下載特徵檔案。進入PAI-EAS 控制台,找到對應的模型服務執行個體。
在EAS控制台查看請求。開啟使用的EAS模型服務,在日誌頁面根據requestid搜尋Debug請求,並可看到對應的特徵名稱。

下載特徵檔案。如果根據requestid的尋找不能滿足分析需求,則可以查看模型掛載路徑下載pb格式的特徵檔案。


步驟二:本地分析與對照實驗
使用以下 Python 指令碼來解析下載的 pd 檔案、修改特徵並重新請求模型,以觀察內部資料變化。
執行如下分析指令碼。
## pip install -U eas-prediction --user 安裝eas_prediction的包 from eas_prediction import PredictClient from eas_prediction.torchrec_request import TorchRecRequest from eas_prediction.torchrec_predict_pb2 import PBRequest from google.protobuf import text_format def read_pb_and_request_and_save(path, str_path, client, req): with open(path, 'rb') as f: pb_data = f.read() pb_req = PBRequest() pb_req.ParseFromString(pb_data) req.request_data = pb_req resp = client.predict(req) print(resp) with open(str_path,'w',encoding='utf-8') as f: f.write(str(pb_req)) def predict_new_pb(str_path,debug_feature_path,client,req): with open(str_path, 'r', encoding='utf-8') as f: pb_data = f.read() pb_req = PBRequest() text_format.Merge(pb_data, pb_req) req.request_data = pb_req req.set_debug_level(2) resp = client.predict(req) with open(debug_feature_path, 'w', encoding='utf-8') as f: f.write(str(resp)) if __name__ == '__main__': path = 'torch_req/on_line.pb' # 下載的本地pb路徑 str_path = 'torch_req/on_line.txt' # 本地解析pb為字串要儲存的路徑 debug_feature_path = 'torch_req/on_score.txt' # 請求儲存下來的raw feature(fg前的所有特徵)和generate(fg後的所有特徵) # 模型url配置 client = PredictClient('173xxxx.cn-beijing.pai-eas.aliyuncs.com', '{model_name}') # 模型token client.set_token('eas_token==') client.init() req = TorchRecRequest() # 1.先調用read_pb_and_request_and_save,發送一次請求並儲存pb成字串 # 2.修改要變化的特徵 # 3.注釋調read_pb_and_request_and_save,運行predict_new_pb read_pb_and_request_and_save(path,str_path,client,req) # predict_new_pb(str_path,debug_feature_path,client,req)產生可讀的特徵檔案on_line.txt。配置
path,str_path調用read_pb_and_request_and_save。這會產生一個on_line.txt檔案,其中包含了所有請求特徵,格式清晰可讀。修改特徵並進行對照實驗。開啟
on_line.txt檔案,找到您關心的特徵,手動修改其值。例如,將一個數值特徵從0.1改為0.9,或將一個 ID 特徵替換為另一個值。召回的集合通常條目數量較多,您可以減少集合數量,只修改其中幾條的特徵。擷取Debug輸出。儲存修改後的
on_line.txt,然後運行指令碼中的predict_new_pb函數(注意注釋掉read_pb_and_request_and_save)。該函數會用您修改後的特徵重新請求模型,並將詳細的調試資訊(包含raw_features和generate_features)儲存到on_score.txt
結果驗證。開啟
on_score.txt檔案,可以看到兩組關鍵資訊:raw_features:模型服務收到的、經過特徵預先處理(如查表、拼接)但未經過 FG (Feature Generation) 運算元編碼的原始特徵。generate_features:經過 FG 運算元編碼後,最終輸入模型進行打分的特徵。
通過以下檢查來確認特徵是否生效:
檢查
raw_features:確認您修改的特徵及其新值是否正確出現在raw_features中。這證明特徵已成功傳遞到模型服務。檢查
generate_features:觀察該特徵經過 FG 編碼後,在generate_features中的表現。如果您的修改(例如,從0.1到0.9)導致了generate_features中對應 Embedding ID 或數值的變化,那麼證明特徵的線上處理邏輯是生效的。
問題排查:更換特徵,模型分數未變化
如果您確認 generate_features 已經隨您的修改而變化,但最終的模型分數(score)依然不變,這通常意味著該特徵對於模型的權重幾乎為零,屬於模型效果問題,而非工程鏈路問題。
但如果您發現修改了 raw_features,generate_features 卻保持不變,且多次嘗試都是同樣效果。則問題可能是線上 FG 運算元的處理邏輯與預期不符,您可以嘗試進行離線驗證:
找到 FG 設定檔:在您的模型專案中,找到用於精排的fg encoder特徵設定檔。
類比離線執行:使用
pyfg等工具,將在raw_features中觀察到的特徵值作為輸入,在本地離線執行 FG 轉換。比對結果:將離線
pyfg的輸出結果與線上generate_features的值進行比對。如果一致:說明線上 FG 邏輯正確執行了您的配置。
如果不一致:說明線上環境與離線環境可能存在差異,需要進一步排查環境問題。