この問題に最初に遭遇したのは、実際のどのシナリオでしたか?
今年の初め、私は自動コードレビューツールの開発に取り組んでいました。目標は、エージェントがテスト失敗情報に基づいてコードを自動的に修復し、再送信できるようにすることでした。最初の解決策は非常に簡単でした。エージェントは LLM を 1 回呼び出し、修復の提案を取得し、パッチを適用し、テストを実行します。しかし、問題はすぐに発見され、初めて生成された修正は多くの場合不正確であったり、新たなバグが導入されたりすることもありました。
このとき、私は本当に Loop Engineering にぶつかりました。単純に「LLM を呼び出して結果を取得する」のではなく、出力を評価し、フィードバックを修正し、終了条件に合格するか到達するまで再評価するループを設計する必要があります。多くの記事では理論上の「閉ループ」について語られていますが、私が直面しているのは実際のリトライキュー、終了条件の判定、ステータス管理です。
これを実行した後に私の判断を大きく変えたいくつかの結論
1. サイクルが多いほど良いため、重要なのは信号の品質です。
あと何回か挑戦すれば合格できるだろうと最初は max_retries=5 に設定しました。実際、3 回目以降、エージェントは句読点を微調整したり、同義語を変更したりするだけで、実質的な改善は見られないことがよくあります。その後、終了条件を「固定回数」から「信号変化率」に変更しました。2 つの連続する修復ソリューションの意味的類似性が 90% を超える場合、直接終了され、「自動的に修復できない」とマークされます。
2. コンテキストのインフレは目に見えない殺人者です
各ループは完全な会話履歴をモデルに送信し、コンテキスト ウィンドウがすぐにいっぱいになり、モデルは元のコードを「忘れ」始めます。この落とし穴を踏んでからは、現在のコードブロック、最新の障害情報、前回の修復差分のみを保持するように変更しました。その結果、修理成功率は12%向上しました。
3. テストの信頼性がサイクルの有効性を決定します
テスト自体にネットワーク ジッターやタイミングの問題など不安定な要因がある場合、ループは間違った信号に対して何度も試行を繰り返すことになります。このループが本当に有益になるまで、不安定なテストの比率を 8% から 1% 未満に上げるのに 2 週間かかりました。
その時に遭遇した落とし穴とその後の修正方法
ピット 1: 「再試行可能なエラー」と「再試行不可能なエラー」の区別はありません
最初に、コンパイル エラー (インポートの欠落など) を含むすべての失敗を再試行します。これらの 10 回の再試行では改善されず、時間とトークンを無駄にするだけです。修正方法は、構文エラー、依存関係の欠落、ロジック エラーといったエラー カテゴリを事前に定義することです。最初の 2 つのカテゴリはエラーを直接報告して終了し、「完全ではないロジック」のみがループに入ることができます。
ピット 2: 循環ログが厚すぎるためデバッグできません
初期状態では「リトライ1：失敗、リトライ2：失敗」のみが記録されており、失敗の原因は全く分かりません。その後、各ループ ノードで元のエラー、モデル出力の差分、テスト出力の概要を出力しました。このログを使用すると、問題を特定する時間が数時間から数分に短縮されます。
ピット 3: コスト制限を考慮していない
複雑な修復ジョブは 8 サイクル実行され、2 ドルの費用がかかる場合があります。実験段階では持続可能ではありません。私の修正計画は、トークンの予算を設定し、現在のサイクルで蓄積されたトークンがエントリの期待値 (このバグを修正するための推定人件費など) を超えると、自動的に単純な LLM にダウングレードするか、直接一時停止することです。
同様の作業を行っている場合は、最初にコピーするのが最も価値のあるステップです
このチェック (疑似コード) を修復ループのエントリに直接追加します。
def should_retry(error, history):
if error.type in UNRECOVERABLE_ERRORS:
return False
if len(history) >= 2 and similarity(history[-1], history[-2]) > 0.9:
return False
if total_tokens_used > BUDGET:
return False
return True
これらの 3 点チェックは、修復不可能なエラー、モデルの空回り、制御不能なコストなどの最も一般的な問題をカバーします。ループの最外層に配置すると、不必要な消費を少なくとも 30% 節約できます。
いつ投資を継続し、いつ路線を変更する必要がありますか?
投資継続のシグナル:
- たとえ遅い場合でも、改善を続けているという明確なシグナル (例: テスト合格率、実際の修正率) がある。
- 上記の終了および劣化ロジックをループ設計に追加しており、コストは制御可能です。
- チームにはテストの安定性とバグ分類リストを維持するエネルギーがあります。
ルート変更の信号:
- 失敗のほとんどが、依存関係のバージョンの競合や API の変更など、同じ種類の「再試行不可能な」エラーであることがわかります。ループではなく、ソースの問題を修正する時期です。
- サイクル数は増加しましたが、修復成功率は慢性的に 30% を下回っています。これは、LLM 自体がこのタスクが苦手であり、モデルを変更するか、プロンプト戦略を変更する必要があることを意味する可能性があります。
- タスク自体を改善するのではなく、ループ パラメーター (max_retries、温度、top_p) の調整に時間の 80% を費やしていることに気づきました。
これらの信号に遭遇したとき、私は思い切って自動修復ループを停止し、半自動ソリューションに変更しました。ループは提案の生成のみを担当し、手動で確認した後に提案を実装します。 2 か月後、モデルのバージョンがアップグレードされるのを待ってから、完全自動化を再度試みました。
概要
Loop Engineering は特効薬ではなく、「明確なフィードバック信号、再試行の余地、および許容可能なコスト」でタスクを解決します。シナリオでこれらの条件が満たされない場合でも、厳格に考えないでください。しかし、この種の問題に遭遇した場合は、上記の経験、特に終了条件の設計、コンテキスト管理、エラー分類、予算管理を直接使用できます。
次に、コンテキスト ウィンドウ戦略、サイクル コスト モデル、エラー回復モデルなど、より体系的なエージェント エンジニアリング方法論を取得したい場合は、有料の記事やコースに参加してください。
コメントはまだありません