Skip to content

Retry with Feedback(フィードバック付きリトライ)

ツール呼出や構造化出力がハードな失敗(例外・スキーマ検証エラー・API 4xx・パース不能)を返したとき、そのエラー内容を文脈へ差し戻し、モデルに是正した再試行を生成させる。同じ入力の盲目的な再送では直らない、モデル起因の失敗を回復するパターンである。

別名

呼称出典
Error-Aware Retry / Self-Correcting Retry一般的呼称
Tool Error Feedback各種エージェントFW(ツールエラーの差し戻し)
意味論的リトライ古典 Retry の拡張としての位置づけ

問題

LLMが生成したツール呼出や構造化出力は失敗する——引数のスキーマ違反、不正なJSON、存在しない関数名、API が 400 を返す不正なリクエスト、実行時例外。古典的な Retry(同じリクエストを指数バックオフで再送する)は一時的障害には効くが、これらの失敗は一時的ではない。同じ入力を再送すれば同じ失敗を繰り返すだけである。

問題は、モデルが「なぜ失敗したか」を知らされないまま次を生成することにある。エラーの具体的な内容を文脈に戻さなければ、モデルは前回と同じ誤りを再生産する。

コンテキスト

適用する:

  • LLMがツール呼出・構造化出力を生成し、その正否を決定論的に判定できる場合(スキーマ検証、型チェック、APIのエラー応答、パーサ)
  • 副作用をコミットするに是正できる操作

適用しない(不要な)ケース:

  • 一時的障害(ネットワーク瞬断・レート制限・5xx)——これは古典 Retry(バックオフ付きの同一再送)で足り、LLMを介す必要はない
  • 既に副作用をコミットした後の失敗——巻き戻しと再計画が要る(Self-Heal Loop
  • 出力の品質の善し悪しの判断——ハードなエラーではなく評価の問題(Reflection / Evaluator-Optimizer

解決

失敗を捕捉し、具体的なエラー信号(検証メッセージ・例外・APIのエラー本文)を文脈へ差し戻して、是正した再試行を生成させる。まず失敗の種別を分類する——一時的障害なら古典 Retry(LLMを介さないバックオフ再送)、モデル起因のハード失敗ならフィードバック再試行。反復は上限で必ず打ち切る(Budget Guard)。

python
def call_with_feedback(prompt, max_attempts=3):
    error = None
    for attempt in range(max_attempts):
        action = llm(prompt, last_error=error)   # 前回のエラーを文脈に含めて再生成
        try:
            return execute(action)               # 検証・実行(決定論的に正否を判定)
        except TransientFault:
            backoff(attempt)                     # 一時的障害は同一再送(古典Retry)
            error = None
        except HardError as e:
            error = format_error(e)              # スキーマ違反・4xx・例外をそのまま差し戻す
    return escalate(reason=error)                # 上限到達は成功と偽らず報告する

実装の要点:

  • 失敗を分類してから対処する。 一時的障害は同一再送、モデル起因のハード失敗はフィードバック再試行。混同すると、直らない失敗をバックオフで空回りさせる
  • エラーは具体的に差し戻す。 「失敗しました」ではなく、検証メッセージ・スタックトレース・APIのエラー本文をそのまま文脈へ入れる。それが是正の材料になる
  • 上限で必ず打ち切る。 同じ誤りをモデルが繰り返すことがある。Budget Guard で反復を固定し、上限到達を成功と偽らない
  • コミット前に判定する。 副作用を伴う実行は、検証を通ってから確定する。確定後の失敗は Self-Heal Loop の領域

トレードオフ

  • ✅ スキーマ違反・不正な引数など、モデル起因の失敗の多くが数回の再試行で自己回復する
  • ✅ 決定論的な検証源(型・スキーマ・API応答)と組み合わせると、壊れた出力が下流へ漏れるのを防げる
  • ⚠️ 一時的障害と混同すると、直らない失敗を無駄に反復してコストを浪費する。失敗の分類が要る
  • ⚠️ 何度も同じ誤りを繰り返すモデルには効かない。上限とエスカレーションの設計が前提になる

クラウドパターンとの対応

クラウドパターン本パターンでの再定義
Retry「一時的障害に対し、同じリクエストを指数バックオフで再送する」から「モデル起因のハード失敗に対し、エラー内容を文脈へ差し戻し、是正した別の試行を生成する」へ。再送の単位が『同一リクエスト』から『エラーを踏まえた新しい試行』に変わった。一時的障害には従来の Retry を併存させる

関連パターン

  • Reflection — 境界は「トリガー」。Reflection は成果物の品質を自ら疑う能動的な自己批評、Retry with Feedback はハードなエラー信号を受けた受動的な回復。前者は品質、後者は実行の成功に責任を持つ
  • Self-Heal Loop — コミット後の多段失敗の回復。Retry with Feedback はコミット前の単一呼出の是正。失敗の深さで使い分ける
  • Budget Guard — 再試行上限の決定論的な強制。必ず併用する
  • Layered Guardrails — ツール応答の検証層が、差し戻すべきエラーの検出源になる

出典・参考

本文: CC BY 4.0 / コード片: MIT。GitHub で寄稿を受け付けています。