次の方法で共有

プロンプト フローのトラブルシューティング ガイダンス

この記事では、プロンプト フローの使用方法に関してよく寄せられる質問について説明します。

"XXX という名前のモジュールがありません" エラーで実行が失敗したのはなぜですか?

この種類のエラーは、必要なパッケージがないコンピューティング セッションに関連しています。 既定の環境を使用する場合は、コンピューティング セッションのイメージで最新バージョンが使用されていることを確認します。 カスタム 基本イメージを使用する場合は、Docker コンテキストに必要なすべてのパッケージがインストールされていることを確認します。

コンピューティング セッションで使用されるサーバーレス インスタンスを見つけるにはどうすればよいですか?

コンピューティング セッションで使用されるサーバーレス インスタンスは、コンピューティング ページの [コンピューティング セッションの一覧] タブで表示できます。 サーバーレス インスタンスを管理する方法の詳細については、「 コンピューティング セッションの管理」を参照してください。

さらに調査するために LLM ツールの生の入力と出力を見つけるにはどうすればよいですか?

プロンプトフローでは、フロー ページの成功した実行および実行詳細ページにて、出力セクションにLLMツールの生データ入力と出力を見つけることができます。 [ 完全な出力の表示] を選択して、完全な出力を表示します。

LLM ノードの [完全な出力の表示] ボタンを示すスクリーンショット。

[トレース] セクションには、LLM ツールに対する各要求と応答が含まれています。 LLM モデルに送信された未加工のメッセージと、LLM モデルからの未加工の応答を確認できます。

LLM モデルへの未加工の要求送信と LLM モデルからの応答を示すスクリーンショット。

Azure OpenAI からの 429 エラーを修正するにはどうすればよいですか?

Azure OpenAI から 429 エラーが発生する可能性があります。 このエラーは、Azure OpenAI のレート制限に達したことを意味します。 エラー メッセージは、LLM ノードの出力セクションで確認できます。 レート制限の詳細については、 Azure OpenAI のレート制限に関するページを参照してください。

Azure OpenAI からの 429 レート制限エラーを示すスクリーンショット。

最も多くの時間を消費するノードを特定するにはどうすればよいですか?

  1. コンピューティング セッション ログを確認します。

  2. 次の警告ログ形式を見つけてください: <node_name> has been running for <duration> seconds。

    例えば次が挙げられます。

    • ケース 1: Python スクリプト ノードが長時間実行される。

      タイムアウト実行記号を示すスクリーンショット。

      この場合、 PythonScriptNode が長時間 (ほぼ 300 秒) 実行されていたことがわかります。 ノードの詳細を確認して、問題の原因を確認します。

    • ケース 2: LLM ノードは長時間実行されます。

      LLM タイムアウトによって発生したタイムアウト ログを示すスクリーンショット。

      ログにメッセージ request canceled が表示される場合は、OpenAI API 呼び出しに時間がかかりすぎてタイムアウト制限を超えている可能性があります。

      ネットワークの問題や処理時間が長い複雑な要求により、OpenAI のタイムアウトが発生する可能性があります。

      数秒待ってから、要求を再試行してください。 通常、ネットワークの問題であればこのアクションで解決します。

      再試行が機能しない場合は、 gpt-4-32kなどの長いコンテキスト モデルを使用しているかどうかを確認し、 max_tokensに大きな値を設定します。 もしそうであれば、想定内の動作です。プロンプトで、対話型モードの上限しきい値よりも長い時間がかかる長い応答が生成される可能性があるためです。 このような場合は、このモードにはタイムアウト設定がないため、 Bulk test を試してみることをお勧めします。

アップストリーム要求のタイムアウトの問題を解決するにはどうすればよいですか?

Azure CLI または SDK を使用してフローをデプロイすると、タイムアウト エラーが発生する可能性があります。 既定では、request_timeout_ms は 5000です。 最大 5 分 (300,000 ミリ秒) を指定できます。 次の例は、デプロイ .yaml ファイルで要求タイムアウトを指定する方法を示しています。 詳細については、 デプロイ スキーマを参照してください。

request_settings:
  request_timeout_ms: 300000

OpenAI API で認証エラーが発生した場合はどうすればよいですか?

Azure OpenAI キーを再生成し、プロンプト フローで使用される接続を手動で更新すると、「Unauthorized.」というエラーが発生する可能性があります。 アクセス トークンが見つからない、無効、対象ユーザーが正しくない、または有効期限が切れている。キーが再生成される前に作成された既存のエンドポイントを呼び出すと、これらのメッセージが表示されることがあります。

このエラーは、エンドポイント/デプロイで使用される接続が自動的に更新されないために発生します。 意図しないオフライン操作が原因でオンライン運用展開に影響を与えないようにするため、デプロイ内のキーまたはシークレットの変更を手動で更新する必要があります。

  • エンドポイントが Azure AI Foundry ポータルにデプロイされている場合は、同じデプロイ名を使用して、フローを既存のエンドポイントに再デプロイします。
  • エンドポイントが SDK または Azure CLI を使用してデプロイされた場合は、ダミー環境変数の追加など、デプロイ定義に変更を加えます。 次に、 az ml online-deployment update を使用してデプロイを更新します。

プロンプト フローデプロイの脆弱性の問題を解決するにはどうすればよいですか?

プロンプト フローランタイム関連の脆弱性については、次の方法を試してください。

  • フロー フォルダー内の requirements.txt ファイル内の依存関係パッケージを更新します。
  • フローにカスタマイズされた基本イメージを使用する場合は、プロンプト フロー ランタイムを最新バージョンに更新し、基本イメージを再構築します。 次に、フローを再デプロイします。

マネージド オンライン デプロイに関するその他の脆弱性がある場合は、毎月、Azure AI によって問題が修正されます。

"MissingDriverProgram" または "Could not find driver program in the request" (要求でドライバー プログラムが見つかりませんでした) エラーが発生した場合、どうすればよいですか?

フローをデプロイし、次のエラーが発生した場合は、デプロイ環境に関連している可能性があります。

'error': 
{
    'code': 'BadRequest', 
    'message': 'The request is invalid.', 
    'details': 
         {'code': 'MissingDriverProgram', 
          'message': 'Could not find driver program in the request.', 
          'details': [], 
          'additionalInfo': []
         }
}

Could not find driver program in the request

このエラーを修正するには、次の 2 つの方法があります。

  • 推奨: カスタム環境の詳細ページでコンテナー イメージ URI を見つけます。 flow.dag.yaml ファイル内のフロー基本イメージとして設定します。 UI でフローをデプロイする場合は、[ 現在のフロー定義の環境を使用する] を選択します。 バックエンド サービスは、この基本イメージとデプロイの requirement.txt に基づいてカスタマイズされた環境を作成します。 詳細については、 フロー定義で指定された環境を参照してください。
  • カスタム環境定義に inference_config を追加します。

次の例は、カスタマイズされた環境定義の例です。

$schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
name: pf-customized-test
build:
  path: ./image_build
  dockerfile_path: Dockerfile
description: promptflow customized runtime
inference_config:
  liveness_route:
    port: 8080
    path: /health
  readiness_route:
    port: 8080
    path: /health
  scoring_route:
    port: 8080
    path: /score

モデルの応答に時間がかかりすぎる場合はどうすればよいですか?

デプロイメントの応答時間がかかりすぎることに気付くことがあります。 この遅延は、いくつかの潜在的な要因が原因で発生します。

  • フローで使用されるモデルは十分に強力ではありません。 (たとえば、 text-adaではなく GPT 3.5 を使用します)。
  • インデックス クエリは最適化されておらず、時間がかかりすぎます。
  • フローには、処理する多くの手順があります。

上記の考慮事項を使用してエンドポイントを最適化して、モデルのパフォーマンスを向上することを検討してください。

デプロイ スキーマをフェッチできない場合はどうすればよいですか?

エンドポイントをデプロイしたら、デプロイの詳細ページの [ テスト ] タブでテストする必要があります。 [ テスト ] タブに移動するには、左側のウィンドウの [ マイ アセット] で [ モデルとエンドポイント] を選択します。 次に、デプロイを選択して詳細を表示します。 [ テスト ] タブに デプロイ スキーマをフェッチできないと表示される場合は、次の 2 つの方法を試してこの問題を軽減してください。

デプロイの詳細ページの [テスト] タブを示すスクリーンショット。

  • エンドポイント ID に対する適切なアクセス許可が付与されていることを確認します。 詳細については、 エンドポイント ID にアクセス許可を付与する方法を参照してください。
  • 古いバージョンのランタイムでフローを実行した後、フローをデプロイしたので、デプロイで古いバージョンのランタイムの環境が使用された可能性があります。 ランタイムを更新するには、「UI でランタイムを 更新する」の手順に従います。 最新のランタイムでフローを再実行し、フローをもう一度デプロイします。

"Access denied to list workspace secret" (ワークスペース シークレットを一覧表示するためにアクセスが拒否されました) エラーが発生した場合はどうすればよいですか?

"ワークスペース シークレットを一覧表示するためにアクセスが拒否されました" のようなエラーが発生した場合は、エンドポイント ID に正しいアクセス許可を付与したかどうかを確認します。 詳細については、 エンドポイント ID にアクセス許可を付与する方法を参照してください。