背景情報
モデルの反復とデプロイメントの過程で、新規または修正された特徴が期待どおりに機能するかどうかを確認する必要が頻繁にあります。オンラインで特徴が変更されても、モデルの最終的な出力スコアが変わらないことがあります。これにより、特徴の有効性を判断することが困難になります。このドキュメントでは、モデルが特徴を正しく受信し、処理していることを分析・検証するための体系的な方法について説明します。
前提条件
ソート用のモデルサービスがデプロイされていること (例:PAI-EAS 上)。
PAI-Rec エンジンサービスがデプロイされていること。エンジンまたは AB テストの構成で、モデルサービスを呼び出し、ターゲット特徴を使用するように設定されていること。
特徴の有効性の検証
コアとなるメソッドは、ライブリクエストをキャプchaし、その特徴データをローカルに保存し、特定の特徴値を修正してから、再度リクエストを送信することです。モデルに入力される前の特徴の変化を観察することで、特徴が正しく処理されているかどうかを判断できます。
ステップ 1:オンラインリクエストからの特徴データのキャプチャ
レコメンデーションエンジンサービスにデバッグリクエストを送信します。PAI-Rec コンソールにログインします。左側のナビゲーションウィンドウで、[トラブルシューティングツール] > [レコメンデーション診断] をクリックします。環境を選択し、デバッグモードを有効にして、[診断] をクリックしてリクエストを送信します。
例えば、ユーザーホワイトリストを使用したり、トラフィックを 100% に設定したりして、検証したいモデルサービスにリクエストがルーティングされるようにしてください。モデルサービスがデバッグリクエストを受信すると、エンジンからの特徴データが Protobuf (PB) フォーマットでサービスののマウントされたディレクトリに自動的に保存されます。

特徴ファイルを見つけてダウンロードします。PAI-EAS コンソールに移動し、対応するモデルサービスインスタンスを見つけます。
EAS コンソールでリクエストを表示します。関連する EAS モデルサービスを開きます。[ログ] ページで、リクエスト ID を使用してデバッグリクエストを検索し、対応する特徴名を表示します。

特徴ファイルをダウンロードします。リクエスト ID で検索しても分析に十分な情報が得られない場合は、モデルのマウントパスを見つけて PB フォーマットの特徴ファイルをダウンロードできます。


ステップ 2:ローカルでの解析と対照実験
以下の Python スクリプトを使用して、ダウンロードした PB ファイルを解析し、特徴を修正し、再度モデルにリクエストを送信して内部データの変化を観察します。
以下の解析スクリプトを実行します。
## eas_prediction パッケージをインストールするには、pip install -U eas-prediction --user を実行します 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' # リクエストから得られた生の特徴 (FG 適用前のすべての特徴) と生成された特徴 (FG 適用後のすべての特徴) を保存するパス # モデルの URL 設定 client = PredictClient('173xxxx.cn-beijing.pai-eas.aliyuncs.com', '{model_name}') # モデルのトークン 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 特徴を別の値に置き換えたりできます。取得されたコレクションには多くのアイテムが含まれていることがよくあります。アイテムの数を減らし、一部のアイテムの特徴のみを修正することができます。デバッグ出力を取得します。修正した
on_line.txtファイルを保存し、スクリプト内のpredict_new_pb関数を実行します。その際、read_pb_and_request_and_saveをコメントアウトすることを忘れないでください。この関数は、修正した特徴を使用してモデルに再度リクエストを送信し、raw_featuresとgenerate_featuresを含む詳細なデバッグ情報をon_score.txtに保存します。
結果の検証。
on_score.txtファイルを開き、2 つの主要な情報を確認します。raw_features:モデルサービスが受信した元の特徴。これらの特徴は前処理 (例えば、テーブルルックアップや連結) されていますが、特徴生成 (FG) オペレーターによるエンコーディングはされていません。generate_features:FG オペレーターによってエンコーディングされ、最終的にスコアリングのためにモデルに入力される特徴。
以下のチェック項目を用いて、特徴が有効であることを確認します。
raw_featuresの確認:修正した特徴とその新しい値がraw_featuresに正しく表示されていることを確認します。これにより、特徴がモデルサービスに正常に渡されたことが確認できます。generate_featuresの確認:FG エンコーディング後、特徴がgenerate_featuresでどのように表示されるかを観察します。修正 (例えば、0.1から0.9への変更) によってgenerate_features内の対応する埋め込み ID や数値が変化した場合、その特徴のオンライン処理ロジックは正しく機能しています。
トラブルシューティング:特徴は変化するがモデルスコアが変化しない場合
generate_features が修正に応じて変化するものの、最終的なモデルスコアが変わらない場合、通常はモデル内でのその特徴の重みがほぼゼロであることを意味します。これはエンジニアリングパイプラインの問題ではなく、モデルの性能の問題です。
しかし、raw_features を修正しても、複数回試行しても generate_features が変化しない場合、問題はオンライン FG オペレーターの処理ロジックが期待どおりに機能していない可能性が高いです。オフラインで検証を実行できます。
FG 設定ファイルを見つける:モデルプロジェクト内で、詳細なソートに使用される FG エンコーダーの特徴設定ファイルを見つけます。
オフライン実行をシミュレートする:
pyfgなどのツールを使用して、ローカルで FG 変換を実行します。入力としてraw_featuresで観察された特徴値を使用します。結果を比較する:オフラインの
pyfgツールからの出力と、オンラインのgenerate_featuresの値を比較します。一致する場合:オンラインの FG ロジックは設定を正しく実行しています。
一致しない場合:これは、オンライン環境とオフライン環境の間に乖離があることを示しており、さらなる調査が必要です。