すべてのプロダクト
Search
ドキュメントセンター

Artificial Intelligence Recommendation:特徴の有効性の検証

最終更新日:Mar 01, 2026

背景情報

モデルの反復とデプロイメントの過程で、新規または修正された特徴が期待どおりに機能するかどうかを確認する必要が頻繁にあります。オンラインで特徴が変更されても、モデルの最終的な出力スコアが変わらないことがあります。これにより、特徴の有効性を判断することが困難になります。このドキュメントでは、モデルが特徴を正しく受信し、処理していることを分析・検証するための体系的な方法について説明します。

前提条件

  • ソート用のモデルサービスがデプロイされていること (例:PAI-EAS 上)。

  • PAI-Rec エンジンサービスがデプロイされていること。エンジンまたは AB テストの構成で、モデルサービスを呼び出し、ターゲット特徴を使用するように設定されていること。

特徴の有効性の検証

コアとなるメソッドは、ライブリクエストをキャプchaし、その特徴データをローカルに保存し、特定の特徴値を修正してから、再度リクエストを送信することです。モデルに入力される前の特徴の変化を観察することで、特徴が正しく処理されているかどうかを判断できます。

ステップ 1:オンラインリクエストからの特徴データのキャプチャ

  1. レコメンデーションエンジンサービスにデバッグリクエストを送信します。PAI-Rec コンソールにログインします。左側のナビゲーションウィンドウで、[トラブルシューティングツール] > [レコメンデーション診断] をクリックします。環境を選択し、デバッグモードを有効にして、[診断] をクリックしてリクエストを送信します。

    例えば、ユーザーホワイトリストを使用したり、トラフィックを 100% に設定したりして、検証したいモデルサービスにリクエストがルーティングされるようにしてください。モデルサービスがデバッグリクエストを受信すると、エンジンからの特徴データが Protobuf (PB) フォーマットでサービスののマウントされたディレクトリに自動的に保存されます。

    image.png

  2. 特徴ファイルを見つけてダウンロードします。PAI-EAS コンソールに移動し、対応するモデルサービスインスタンスを見つけます。

    1. EAS コンソールでリクエストを表示します。関連する EAS モデルサービスを開きます。[ログ] ページで、リクエスト ID を使用してデバッグリクエストを検索し、対応する特徴名を表示します。

      image.png

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

      image.png

      image.png

ステップ 2:ローカルでの解析と対照実験

以下の Python スクリプトを使用して、ダウンロードした PB ファイルを解析し、特徴を修正し、再度モデルにリクエストを送信して内部データの変化を観察します。

  1. 以下の解析スクリプトを実行します。

    ## 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)
    
    1. 読み取り可能な特徴ファイル on_line.txt を生成します。pathstr_path を設定し、read_pb_and_request_and_save を呼び出します。これにより、リクエストのすべての特徴が明確で読み取り可能な形式で含まれる on_line.txt ファイルが生成されます。

    2. 特徴を修正し、対照実験を実施します。on_line.txt ファイルを開き、対象の特徴を見つけて手動で値を修正します。例えば、数値特徴を 0.1 から 0.9 に変更したり、ID 特徴を別の値に置き換えたりできます。取得されたコレクションには多くのアイテムが含まれていることがよくあります。アイテムの数を減らし、一部のアイテムの特徴のみを修正することができます。

    3. デバッグ出力を取得します。修正した on_line.txt ファイルを保存し、スクリプト内の predict_new_pb 関数を実行します。その際、read_pb_and_request_and_save をコメントアウトすることを忘れないでください。この関数は、修正した特徴を使用してモデルに再度リクエストを送信し、raw_featuresgenerate_features を含む詳細なデバッグ情報を on_score.txt に保存します。

  2. 結果の検証on_score.txt ファイルを開き、2 つの主要な情報を確認します。

    • raw_features:モデルサービスが受信した元の特徴。これらの特徴は前処理 (例えば、テーブルルックアップや連結) されていますが、特徴生成 (FG) オペレーターによるエンコーディングはされていません

    • generate_featuresFG オペレーターによってエンコーディングされ、最終的にスコアリングのためにモデルに入力される特徴。

    以下のチェック項目を用いて、特徴が有効であることを確認します。

    • raw_features の確認:修正した特徴とその新しい値が raw_features に正しく表示されていることを確認します。これにより、特徴がモデルサービスに正常に渡されたことが確認できます。

    • generate_features の確認:FG エンコーディング後、特徴が generate_features でどのように表示されるかを観察します。修正 (例えば、0.1 から 0.9 への変更) によって generate_features 内の対応する埋め込み ID や数値が変化した場合、その特徴のオンライン処理ロジックは正しく機能しています。

トラブルシューティング:特徴は変化するがモデルスコアが変化しない場合

generate_features が修正に応じて変化するものの、最終的なモデルスコアが変わらない場合、通常はモデル内でのその特徴の重みがほぼゼロであることを意味します。これはエンジニアリングパイプラインの問題ではなく、モデルの性能の問題です。

しかし、raw_features を修正しても、複数回試行しても generate_features が変化しない場合、問題はオンライン FG オペレーターの処理ロジックが期待どおりに機能していない可能性が高いです。オフラインで検証を実行できます。

  1. FG 設定ファイルを見つける:モデルプロジェクト内で、詳細なソートに使用される FG エンコーダーの特徴設定ファイルを見つけます。

  2. オフライン実行をシミュレートするpyfg などのツールを使用して、ローカルで FG 変換を実行します。入力として raw_features で観察された特徴値を使用します。

  3. 結果を比較する:オフラインの pyfg ツールからの出力と、オンラインの generate_features の値を比較します。

    • 一致する場合:オンラインの FG ロジックは設定を正しく実行しています。

    • 一致しない場合:これは、オンライン環境とオフライン環境の間に乖離があることを示しており、さらなる調査が必要です。