JSON返信から信頼できるワークフローへ

受け取るシステムから始める

モデルにJSONを求める前に、次のシステムが何を必要としているかを決めます。フィールド名、型、必須フィールド、欠落情報の表現を選びます。予測可能なオブジェクトは、その意味がタスクに合う場合にのみ有用です。受け取るアプリケーションとともに、小さなバージョン管理されたスキーマを保守してください。

明示的な形を求める

playgroundでJSONを選択し、期待するフィールドを記述します。たとえば、summary文字列、next_steps文字列配列、missing_information配列を求めます。結果は外部の推測ではなく、提供されたソースを使用しなければならないことを明記します。以下のオブジェクトは説明用であり、モデルが生成した結果ではありません。

{
  "summary": "The launch date has not been supplied.",
  "next_steps": ["Confirm the owner and launch date."],
  "missing_information": ["owner", "launch_date"]
}

構文、構造、根拠を検証する

まずJSONをパースします。次に、予期しない型、省略された必須フィールド、ビジネス上の制限を超える文字列を拒否します。最後に、事実に関するフィールドをソースと照合します。スキーマはオブジェクトの形を検証しますが、日付や所有者が真実であることは確立できません。次のステップでトレーサビリティが必要な場合は、ソース識別子を保持してください。

不完全な出力は不完全として扱う

停止したレスポンスは、文字列やオブジェクトの途中で終わることがあります。それを実行したり、自信を持って黙って修復したりしないでください。プロバイダー統合では、完了ステータスを確認し、エラーを保持します。推論は出力トークンを消費するため、高負荷を使用する場合はそれを予算に含めてください。APIガイドでレスポンス処理について説明しています。

副作用の前に境界を設ける

パースされたオブジェクトは、自動的にメールを送信したり、注文を変更したり、コマンドを実行したりすべきではありません。権限とビジネスアクションを独立して検証してください。アプリケーションで必要な場合は承認ステップを使用してください。自動化を有効にする前に、負のケース（誤った型、不明な識別子、余分なフィールド、中断されたストリーム）をテストしてください。アプリケーションの責任についてはツール呼び出しセクションをお読みください。