alibabacloud-pai-rec-diagnosis

PAI-Rec エンジンの診断と設定の検証

このスキルでは、インターフェイスのトラブルシューティングや設定の分析など、Alibaba Cloud PAI-Rec（プログラマブルレコメンデーションシステム）エンジンの包括的な診断および検証機能を提供します。

シナリオの説明

PAI-Rec は、インテリジェントなレコメンデーション機能を提供する Alibaba Cloud のプログラマブルレコメンデーションシステムです。このスキルでは、次のことができます。

1. PAI-Rec エンジンのインターフェイスの問題を診断する：エンジン API がエラーや予期しない結果を返した場合、EAS サービスログとエンジン設定を通じてリクエストを追跡し、根本原因を特定します。

2. エンジン設定を検証する：デプロイ前にエンジン設定ファイルを分析し、潜在的な問題や不整合、設定ミスを特定します。

アーキテクチャ：PAI-EAS サービス + PAI-Rec エンジン + エンジン設定管理

主なコンポーネント

• PAI-EAS サービス：レコメンデーションエンジンをホストする Elastic Algorithm Service
• PAI-Rec エンジン：リクエストを処理するレコメンデーションエンジン
• エンジン設定：エンジンの動作を定義する設定ファイル
• サービスログ：リクエストのトレースを含む EAS サービスログ

---

インストール

事前確認：Aliyun CLI >= 3.3.3 が必要です

aliyun version を実行して、バージョンが 3.3.3 以上であることを確認してください。未インストールの場合、またはバージョンが古い場合は、 curl -fsSL https://aliyuncli.alicdn.com/setup.sh | bash を実行してインストールまたは更新してください。 インストール手順については、references/cli-installation-guide.md を参照してください。

事前確認：Aliyun CLI プラグインの更新が必要です

[必須] aliyun configure set --auto-plugin-install true を実行して、プラグインの自動インストールを有効にしてください。 [必須] aliyun plugin update を実行して、既存のプラグインが常に最新の状態であることを確認してください。

---

認証

事前確認：Alibaba Cloud の認証情報が必要です

セキュリティルール：

• 絶対に AK/SK の値を読み取ったり、エコーしたり、出力したりしないでください（例：echo $ALIBABA_CLOUD_ACCESS_KEY_ID は禁止です）
• 絶対に会話中またはコマンドラインで AK/SK を直接入力するようユーザーに求めないでください
• 絶対にリテラルの認証情報を指定して aliyun configure set を使用しないでください
• 認証情報の状態確認には aliyun configure list のみを使用してください

aliyun configure list

出力を確認し、有効なプロファイル（AK、STS、または OAuth ID）があることを確認してください。

有効なプロファイルがない場合は、ここで停止してください。

1. Alibaba Cloud コンソールから認証情報を取得します
2. このセッション外で認証情報を設定します（ターミナルで aliyun configure を実行するか、シェルプロファイルに環境変数を設定します）
3. aliyun configure list に有効なプロファイルが表示されたら、戻って再実行します

---

RAM ポリシー

**[必須] 権限エラーへの対応：**実行中のいずれかの時点で、コマンドまたは API 呼び出しが権限エラーで失敗した場合は、次の手順に従ってください。

1. references/ram-policies.md を読み、この SKILL に必要な権限の一覧を確認します
2. ram-permission-diagnose スキルを使用し、必要な権限を申請する手順をユーザーに案内します
3. 必要な権限が付与されたことをユーザーが確認するまで待機します

このスキルに必要な RAM ポリシーの詳細については、references/ram-policies.md を参照してください。

---

パラメーターの確認

重要：パラメーターの確認 — コマンドまたは API 呼び出しを実行する前に、 ユーザーが変更できるパラメーター（例：RegionId、サービス名、インスタンス ID、 環境名、設定名など）をすべてユーザーに確認する必要があります。 ユーザーの明示的な承認なしに、値を推測したりデフォルト値を使用したりしないでください。

必須パラメーター

パラメーター名	必須／任意	説明	デフォルト値
service-name	必須	PAI-EAS サービス名	なし
cluster-id	必須	EAS クラスター／リージョン ID	なし
instance-id	必須	PAI-Rec インスタンス ID	なし
request-id	必須（診断時）	エンジン API のレスポンスに含まれるリクエスト ID	なし
config-name	任意	エンジン設定名	なし
environment	任意	エンジン環境（Prod／Pre）	なし
engine-config-id	任意	特定のエンジン設定バージョン ID	なし
region	任意	Alibaba Cloud のリージョン	なし

---

オブザーバビリティ（すべての aliyun コマンドで必須）

このスキルを読み込んだら、セッション全体で一度だけ、ランダムなセッション ID（32 文字の小文字の 16 進数文字列）を生成します。以下の {session-id} として使用してください。

ルール：クラウド API を呼び出すすべての aliyun CLI コマンドに --user-agent フラグを含める必要があります。 ローカルユーティリティコマンド（例：configure、plugin、version）はこのフラグをサポートしていないため、対象外とします。

--user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-rec-diagnosis/{session-id}

例（セッション ID が a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 の場合）：

aliyun eas describe-service --cluster-id cn-hangzhou --service-name my_service --user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-rec-diagnosis/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

aliyun API コマンドの実行時に、--user-agent を省略したり、書式を変更したり、付け忘れたりしないでください。

---

コアワークフロー

[MUST] セッションごとに作業ディレクトリを割り当ててください — 一時的なアーティファクト （生の設定ダンプ、ログダンプ、サニタイズ済みの出力）はすべて、並行して実行されるスキル呼び出し間での上書きを避けるため、 セッションごとに一意のディレクトリの下に書き込む必要があります。アーティファクトを生成する CLI の呼び出しより前に、 ワークフローの開始時に次のコマンドを実行し、セッション全体で $WORKDIR を再利用してください。 テンプレート全体を位置引数として渡してください（BSD／macOS と GNU/Linux の両方の mktemp で動作します）。-t prefix は使用しないでください。これは $TMPDIR（macOS の /var/folders など）にフォールバックし、 サンドボックス化されたシェルでは失敗する場合もあります。

export WORKDIR=$(mktemp -d /tmp/pairec-diag-XXXXXX)

以下に示すすべてのファイルパス（$WORKDIR/engine_configs_list.json など）はこのディレクトリ内に配置し、 ハードコードされた /tmp/... のパスに置き換えてはいけません。

[MUST] 以下に定義されたワークフローのみを使用してください。 追加の手順（例：インスタンスのリソース確認、ネットワークプローブ）を考案したり、 定義されたワークフローの手順を手動分析に置き換えたりしないでください。

ワークフロー 1：PAI-Rec エンジンインターフェースの診断

このワークフローでは、PAI-Rec エンジン API がエラーまたは予期しない結果を返した場合の問題を診断します。

入力例：

Service Name: embedding_recall
API Response:
{
    "code": 299,
    "msg": "items size not enough",
    "request_id": "941b4e14-d1c5-489f-a184-b2b17f8b4fdb",
    "size": 0,
    "experiment_id": "",
    "items": []
}

手順 1：EAS サービス情報の取得

EAS サービスの詳細を取得して、EAS サービス ID と設定を確認します。

aliyun eas describe-service \
  --cluster-id <cluster-id> \
  --service-name <service-name>

抽出する情報：

• Resource：EAS サービスのリソース ID（例：eas-r-1v4qb1yan3qmnjwxqe）
• ServiceConfig.envs：以下を含む環境変数：
  • REGION：リージョン
  • INSTANCE_ID：PAI-Rec インスタンス ID
  • CONFIG_NAME：エンジン設定名
  • PAIREC_ENVIRONMENT：環境（product／prepub）

手順 2：API レスポンスからリクエスト ID を抽出

API レスポンスの JSON を解析し、request_id フィールドを取得します。これはサービスログの検索に使用します。

ステップ 3：EAS サービスログを検索する

リクエスト ID のみをフィルターとしてサービスログを検索します。PAI-Rec のビジネスログを検索するときに --start-time ／ --end-time は渡さないでください。

aliyun eas describe-service-log \
  --cluster-id <cluster-id> \
  --service-name <service-name> \
  --keyword <request-id> \
  --page-size 500

[CRITICAL] --keyword <request-id> は必須です。ローカルでの後処理は禁止されています：

• --keyword <request-id>（サーバー側フィルター。request_id 全体に対する大文字と小文字を区別した完全一致）を必ず渡してください。API はキーワードに一致するログ行のみを返します。
• --keyword を省略してからローカルでフィルター（head、grep、python3、jq、スクリプト経由でのパイプ処理など）してはいけません。
• 関連する行を見つけようと、--keyword なしで describe-service-log を複数回呼び出してログストリーム全体を検索してはいけません。
• --keyword を指定した呼び出しで結果が空の場合は、一致するログが見つからなかったと報告してください。フィルターなしのログ取得に切り替えてはいけません。
• --page-size 500 を指定するとトレース全体を 1 ページで取得できます。1 件のリクエストに一致するエントリは通常 30 件未満です。

❌ 誤り（すべてのログを取得してローカルでフィルターしています。禁止されています）：

aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall | head -300
aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall | grep "request_id"

✅ 正しい方法（サーバー側のキーワードフィルター。必須です）：

aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall --keyword 0c6cbd91-5618-4705-8e08-9126bf4600f7 --page-size 500

[CRITICAL] 時間範囲を指定すると、ビジネスログが通知なく除外されます：

• --keyword のみ（時間範囲なし）を指定すると、CLI は request_id に一致する PAI-Rec アプリケーションのトレース全体（controller.go ／ feed.go ／ recall.go ／ rank_service.go など）を返します。
• --start-time ／ --end-time を追加すると、実際のタイムスタンプを含む時間範囲であっても、ビジネスログが通知なく除外され、インフラストラクチャのノイズ（/bin/sh のハートビート、502 Bad Gateway の再試行、postgres.go dbstat）のみが返されます。
• 時間範囲を使うのは、--keyword なしで広範囲を検索する場合に限ってください。形式は UTC の yyyy-MM-dd HH:mm:ss です（T と Z は付けません）。2025-04-28T00:00:00Z のような ISO-8601 形式は InvalidParameter で拒否されます。

ステップ 4：エンジン設定を一覧表示する

環境を対応付け、一致する設定を一覧表示します。

環境の対応付け：

• product → Prod
• prepub → Pre

aliyun pairecservice list-engine-configs \
  --instance-id <instance-id> \
  --environment <Prod|Pre> \
  --status Released \
  --name <config-name> > "$WORKDIR/engine_configs_list.json" 2>&1

[MUST] サーバー側でフィルターするため、必ず --name <config-name> を渡してください： <config-name> はステップ 1（ServiceConfig.envs.CONFIG_NAME）ですでにわかっているため、--name として渡してください。これを省略すると、インスタンスの設定一覧全体（関連のない項目が数百件に及ぶこともあります）が返され、クライアント側でのフィルターが必要になり、トークンを浪費するうえ、CLI のデフォルトのページネーションにより対象の行が通知なく欠落するおそれがあります。--name はサーバー側での完全一致フィルターです。後処理として grep ／ jq select に置き換えてはいけません。このスキル内の list-engine-configs のすべての呼び出し（ワークフロー 2 のステップ 1 を含む）にも、同じルールが適用されます。

抽出する情報：

• Status: Released の設定を見つけます
• EngineConfigId と Version を取得します

ステップ 5：エンジン設定の詳細を取得する

aliyun pairecservice get-engine-config \
  --instance-id <instance-id> \
  --engine-config-id <engine-config-id> > "$WORKDIR/raw_engine_config.json" 2>&1

[MUST] 表示前にサニタイズしてください — 設定には平文のパスワードやアクセスキーが含まれる場合があります。ターミナルに出力する前に、必ずサニタイザーにパイプしてください。そこに表示するのは、認証情報が ***REDACTED*** に置き換えられた、サニタイズ済みの出力のみとしてください。$WORKDIR/raw_engine_config.json の生ファイルは、認証情報の値を出力しない scripts/validate.py に直接渡せます。

python3 scripts/sanitize_config.py "$WORKDIR/raw_engine_config.json"

抽出する情報：

• ConfigValue：実際のエンジン設定（JSON/YAML）

ステップ 5.5（任意）：静的な設定の妥当性チェック

取得した ConfigValue に対して scripts/validate.py を実行し、構造上のエラーや参照エラーがないか確認します。詳しくは references/config-validation.md を参照してください。

printf '%s' "$CONFIG_VALUE" | python3 scripts/validate.py --stdin

実行する場合： ログが設定要素を示している場合、または設定を初めて調査する場合。 スキップする場合： ログが設定以外の根本原因（scene_id の欠落、上流の 5xx）を示している場合。 [MUST NOT] validate.py を置き換えたり、重複して作成したりしないでください（Workflow 2 § Step 3 と同じ制約です）。 [MUST] スコープ規則： 現在の request_id に関するログの証拠と結び付いている場合に限り、調査結果を最終診断に含めてください。

ステップ 5a（条件付き）：実験設定を取得する

条件： API レスポンスの experiment_id が空でない場合（例："ER14_L21_L26#EG21_L38#EG38#E44_GL36_GL37"）。

解析： 文字列から EG{id}（実験グループ）と E{id}（実験）の数値 ID を抽出します。ER、L、GL のプレフィックスは設定を持たないため、無視してください。

# For each EG{id}:
aliyun pairecservice get-experiment-group \
  --instance-id <instance-id> \
  --experiment-group-id <id> > "$WORKDIR/experiment_group_<id>.json" 2>&1
# For each E{id}:
aliyun pairecservice get-experiment \
  --instance-id <instance-id> \
  --experiment-id <id> > "$WORKDIR/experiment_<id>.json" 2>&1

抽出する項目： Config フィールド。基本エンジン設定より優先されるオーバーライドパラメーター（例：default.RecallNames、rankconf、filterNames、default.SortNames）が含まれています。

オーバーライドの優先順位（低 → 高）： 基本エンジン設定 < ExperimentGroup.Config < Experiment.Config。実際のランタイム動作を把握するため、ステップ 6 で適用してください。

基本設定に対して実験設定を検証します（参照先の存在確認）。

python3 scripts/validate.py "$WORKDIR/raw_engine_config.json" \
  --experiment-config "$WORKDIR/experiment_group_<id>.json" \
  --experiment-config "$WORKDIR/experiment_<id>.json"

ステップ 6：包括的な分析

以下のコンポーネントをまとめて分析します。

1. API レスポンス：エラーコード、メッセージ、返されたデータ
2. サービスログ：処理の流れを示す、該当する request_id のトレースログ
3. エンジン設定：動作に影響する可能性のある設定
4. 実験オーバーライド（experiment_id が空でない場合）：有効な設定 = 実験パラメーターを上書き適用した基本設定

確認する一般的な問題：

• 設定の不一致（例：リコール設定、フィルタリングルール）
• 実験オーバーライド（例：実験によって RecallNames / rankconf が基本設定から変更された）
• リソースの制限（例：アイテム不足、タイムアウト設定）
• データソースの問題（例：テーブルへのアクセス、特徴量の利用可否）
• 環境間の不整合（例：prepub 環境での prod 設定）

[MUST] 証拠のみに基づく報告規則：

ユーザーに提示する最終診断は、EAS サービスログとエンジン設定に直接示されている内容のみに厳密に基づかなければなりません。以下の制約を適用してください。

• 観測された内容だけを報告してください。 主張を裏付ける正確なログ行（ファイル名:行番号、レベル、メッセージ）と、正確な設定断片を引用してください。
• ログの証拠から API レスポンスに至る直接的な因果関係を示し、そこで説明を止めてください。
• ユーザーから明示的に求められない限り、以下の内容を追加しないでください。
  • ログや設定に表れていない推測上の根本原因（例：「クライアントが誤った X を送信した可能性が高い」）
  • 修正の推奨事項や是正手順
  • 条件付きのシナリオ（「X の場合は Y」）
  • 本筋と関係のないベストプラクティスの助言（セキュリティ、フォールバック設計、命名など）
  • ログや設定で扱われていない上流システム、クライアントコード、データソースについての推測
• 証拠が不十分で結論に至れない場合は、 推測するのではなく、必要な追加データ（特定のログ行、他の設定バージョン、他の環境など）を明示してください。
• 推奨事項は、明示的に求められた場合に限ります。 修正案や提案は、ユーザーが後続のやり取りで明示的に求めた場合にのみ提示してください。

---

ワークフロー 2：PAI-Rec エンジン設定の検証

このワークフローでは、エンジン設定に潜在的な問題がないか検証します。

入力： 設定名と環境（Prod/Pre）

ステップ 1：構成バージョンの一覧表示

ユーザーが engine-config-id を指定しない場合は、利用可能なバージョンを一覧表示します。

aliyun pairecservice list-engine-configs \
  --instance-id <instance-id> \
  --environment <Prod|Pre> \
  --name <config-name>

ユーザーへの表示：

• Version：バージョン番号
• Status：構成のステータス（Released／Draft／Archived）
• GmtCreateTime：作成日時
• EngineConfigId：バージョン ID

バージョンを選択するか、engine-config-id を指定するようユーザーに尋ねます。

ステップ 2：構成の詳細を取得

aliyun pairecservice get-engine-config \
  --instance-id <instance-id> \
  --engine-config-id <engine-config-id> > "$WORKDIR/raw_engine_config.json" 2>&1

【必須】表示前にサニタイズする — ターミナルに出力する前に、必ずサニタイズします。

python3 scripts/sanitize_config.py "$WORKDIR/raw_engine_config.json"

ステップ 3：スキーマとルールの検証を実行

【必須】 抽出した ConfigValue JSON を scripts/validate.py に渡します。このスクリプトは JSON Schema（references/schema.json）と参照整合性ルールを適用し、成功時はステータス 0、失敗時は 1 で終了します。

# From a saved JSON file (recommended)
python3 scripts/validate.py "$WORKDIR/raw_engine_config.json"
# Or pipe ConfigValue directly via stdin
printf '%s' "$CONFIG_VALUE" | python3 scripts/validate.py --stdin

jsonschema が必要です（pip install jsonschema）。見つからない場合、スクリプトはスキーマチェックを行わず、ルールのみの検証にフォールバックします。

【禁止】validate.py を置き換えたり、重複する処理を追加したりしないでください：

• スクリプトを省略しないでください。Python、jq、grep、その他のツールで同等のチェックを手書きしないでください。このスクリプトが正式なバリデーターです。
• スクリプトの実行後に、ルールを再実装、再チェック、または「二重確認」しないでください。0 error(s), 0 warning(s) という問題のない結果も含め、出力をそのまま信頼してください。
• スクリプトを実行できない場合（Python がない、依存関係の問題など）は、環境を修正して再実行してください。手動チェックに切り替えないでください。
• スクリプトの対象範囲外の検査は引き続き実施できます（ステップ 4 を参照）。

スクリプトがチェックする内容（概要）：

1. 構造 — JSON の整形式性、必須フィールド、型（RecallConfs、 FilterConfs、SortConfs、AlgoConfs、SceneConfs、RankConf、 FeatureConfs、UserFeatureConfs、DebugConfs、FeatureLogConfs、 CallBackConfs、PipelineConfs など）
2. 列挙値 — RecallType／FilterType／SortType／ DebugConfs.OutputType／GeneralRankConfs.ActionConfs[].ActionType
3. 参照整合性 — SceneConfs.RecallNames → RecallConfs； FilterNames → FilterConfs；SortNames → SortConfs； RankConf.RankAlgoList → AlgoConfs；任意の DaoConf.AdapterType と *Name → 対応する *Confs（Hologres／Redis／MySQL／TableStore／ FeatureStore／…）
4. ビジネスルール
   • User2ItemExposureFilter で WriteLog=true かつ FeatureStore アダプターを使用する場合：TimeInterval > 0 を設定する必要があります
   • accumulator モードの PriorityAdjustCountFilter：Count は厳密に増加する必要があります（リコールごとに上限を個別に設定する場合は Type="fix" を使用）
   • PipelineConfs.*.Name はグローバルに一意である必要があります
   • DebugConfs.Rate は [0, 100] の整数である必要があります
5. RecallConfs、FilterConfs、SortConfs、AlgoConfs 内の名前の重複検出

詳しい使い方、終了コード、出力例、ルールの全一覧は references/config-validation.md にあります。

Step 4: 根拠に基づくレポート

[必須] レポートの先頭行： validate.py の標準出力をそのまま引用します。引用するのは Validation passed: configuration is well-formed または Validation finished: N error(s), M warning(s) のいずれかです。この正確な行が含まれていないレポートは無効です。Step 3 からやり直してください。

手動での確認が許可されるのは、 validate.py の対象範囲外の懸念事項に限られます。具体的には、環境／リージョン／モデル署名の不一致、バージョン間の差分、RankScore 変数とモデル出力フィールドの間の名前の衝突、およびスクリプトが人間による判断を求める [WARNING] の根本原因の調査です。これらの対象範囲外の懸念事項のいずれかに関連付けられない限り、スクリプトが報告していない指摘を追加しないでください。

レポートの構成：

• ✅ 合格したチェック — validate.py の 0 error(s), 0 warning(s) の行を引用します
• ⚠️ 警告 — スクリプトの各 [WARNING] <path>: <message> をコピーし、手動確認で見つかった対象範囲外の不整合も追加します
• ❌ エラー — スクリプトの各 [ERROR] <path>: <message> をコピーします
• 根拠不足に関する注記 — ⚠️ 警告が1件以上ある場合に限り、その警告を確定したエラーとするために必要な追加データを記載します。警告が0件の場合、このセクションは省略してください。一般的な対象範囲外の免責事項（バージョン間の差分、リモート接続性、リージョン／エンドポイントの整合性）で埋めないでください。これらは自発的なベストプラクティスの助言であり、根拠のみを扱うルールで禁止されています。

推測に基づく修正案やベストプラクティスに関する余談を追加しないでください。提案を行うのは、ユーザーから明示的に求められた場合のみです。

---

成功確認方法

詳しい確認手順については、references/verification-method.md を参照してください。

簡易確認：

1. 診断ワークフローの場合：

   • サービス情報が正常に取得された
   • request_id を含むログが見つかった
   • 設定が正しく読み込まれた
   • 根本原因が特定された

2. 検証ワークフローの場合：

   • 設定が正常に取得された
   • すべての検証チェックが実行された
   • 問題が明確に報告された
   • 該当する場合、推奨事項が提示された

---

クリーンアップ

このスキルは読み取り専用の Alibaba Cloud API 呼び出しを実行し、リモートリソースは作成しません。一時的なアーティファクトは、/tmp 配下のセッションごとのローカル $WORKDIR に保存されます（Core Workflow の前置き部分を参照）。このスキルは $WORKDIR を自動的に削除しません。OS レベルの一時ファイルポリシーによって回収されます（macOS では /tmp が定期的にクリーンアップされ、多くの Linux ディストリビューションでは再起動時または systemd-tmpfiles によってクリーンアップされます）。より早くディスク領域を空けるには、ワークフローの外で手動で rm -rf /tmp/pairec-diag-* を実行してください。

---

ベストプラクティス

1. ログのクエリ — キーワードのみ、時間範囲なし、ローカルでのフィルタリングなし：リクエスト単位の診断では、aliyun eas describe-service-log に --keyword <request_id> を渡し、--start-time／--end-time は指定しないでください。--keyword を省略してローカルで後処理（例：| head、| grep、| python3）することは絶対に避けてください。サーバー側のフィルタリングが無効になり、トークンを浪費するうえ、最初のページより後のログを見落とす可能性があります。キーワードと時間範囲を併用すると、CLI の仕様上の問題によりビジネスログが除外されます（ワークフロー 1、ステップ 3 を参照）。時間範囲は、リクエスト単位ではない広範なスキャンに限って使用し、形式は yyyy-MM-dd HH:mm:ss の UTC 形式のみを使用してください（T／Z は付けません）。
2. validate.py を信頼する：ワークフロー 2 では、scripts/validate.py を、そのカタログに記載されたルールの唯一の信頼できる情報源として扱ってください。これを実行せずに手作業でチェックを記述してはならず、実行が問題なく完了した後に、ルールを手作業で再検証してもいけません。手動での確認は、その対象範囲外の懸念事項（環境／リージョン／モデルのシグネチャ、バージョン間の差分、RankScore とモデル出力の命名）に限ります。
3. 環境を把握する：設定が対象環境（Prod と Pre）に合致していることを常に確認してください。問題が続く場合は、正常な既知のバージョンと比較してください。
4. ログの保持期間：EAS サービスログの保持期間は限られています。問題が発生したら、速やかに診断してください。
5. 証拠に基づく結論のみを示す：すべての記述は、具体的なログ行または設定の断片に基づいてください。エラーメッセージだけから結論を急がず、体系的なワークフローに従ってください。推測したり、修正案を提示したり、ユーザーから明示的に求められていないベストプラクティスの助言を自発的に述べたりしないでください。証拠が不十分な場合は、推論するのではなく、何が不足しているかを伝えてください。

---

参考リンク

参考ドキュメント	説明
RAM ポリシー	PAI-Rec および EAS API に必要な RAM 権限
関連コマンド	CLI コマンドの完全なリファレンス
検証方法	詳細な検証手順
CLI インストールガイド	Alibaba Cloud CLI のインストール手順
設定例	エンジン設定のサンプルと一般的なパターン
設定の検証	scripts/validate.py の使用方法、終了コード、ルールカタログ
トラブルシューティングガイド	よくある問題と解決策
設定のサニタイズ	LLM による分析前の認証情報のマスキング