【要約】Claude は 3 回、Qwen は 6 回：model ごとに fix_verify の retry cap を変える設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
Codens Purpleの開発チームは、AIエージェントの修正ループにおけるリトライ回数の設定が、モデルごとに最適ではないという課題に直面した。
- ・全モデル共通で cap = 5 としていたため、コストと成功率のバランスが崩れていた。
- ・Claudeは精度が高く、4回目以降のリトライは仕様理解の誤りに起因する無駄なコスト消費となっていた。
- ・Qwenはリトライを重ねることで成功率が上がる特性があるが、5回での打ち切りにより本来成功したはずのタスクを逃していた。
// Approach
開発チームは、モデルの特性（fix rate curve）の違いに基づき、モデルのプレフィックスによってデフォルトのリトライ回数を切り替える仕組みを導入した。
- ・_default_fix_verify_cap(model) ヘルパー関数を新設し、モデル名に応じて 3 / 6 / 5 回を返すようにした。
- ・DBの purple_projects テーブルに、プロジェクト単位で設定を上書きできる fix_verify_retry_cap カラムを追加した。
- ・APIスキーマにて、リトライ回数の範囲を 1〜20 回に制限するバリデーションを実装した。
// Result
この設計変更により、マルチモデル運用におけるコスト効率とタスク成功率の最適化を実現した。
- ・Claude系タスクにおいて、成功率に寄与しない4〜5回目の無駄なクレジット消費を削減した。
- ・Qwen系タスクにおいて、リトライ不足による失敗を減らし、fix rateを向上させた。
- ・モデルごとの特性に合わせた柔軟な制御が可能となり、プロダクション環境でのバランスが改善した。
Senior Engineer Insight
> モデルの「性能」だけでなく「失敗のパターン」に着目した点が極めて実践的である。単一のパラメータで全モデルを制御しようとするのは、マルチモデル環境では非効率だ。新モデル導入時にデータ観測を要する運用負荷は残るが、これは「判断を伴う運用」として許容すべきコストだろう。スケーラビリティとコスト効率のトレードオフを、コードの単純さを保ちつつ解決している。