今週、あなたのチームに必要なのは、より優れたAIモデルではない
新しいAIモデル探しはやめましょう。本当に必要なアップグレードは、ワークフローです。
多くのチームは、どのモデルがより賢そうかに注目します。新しいリリースをベンチマークし、知能について議論します。しかし、LLMを使って開発しているなら、本当の苦しみは分かっているはずです。問題はコードの質ではありません。実行（execution）の質の問題なのです。
次のような問題に直面していませんか：
- タスクの途中で止まってしまうエージェントのループ。
- 人を混乱させる承認プロンプト。
- リトライ中に壊れてしまうコンテキストチェーン。
- 自動化が状態（state）を失ったために、人間が後始末をする。
知能は向上していますが、運用のコントロールは追いついていません。私たちは「オーケストレーション税（orchestration tax）」の時代に突入しています。これに備えて計画を立てなければ、システム停止やサイレントな失敗という形で代償を払うことになります。
AIの出力が最終製品になることは稀です。それは、より大きなシステムにおける中間ステップに過ぎません。以下の問いを解決する必要があります：
- タイムアウト後にタスクを再開できるか？
- すべての承認を監査できるか？
- 重複したアクションを起こさずにステップを再実行できるか？
- 実行の途中で人間が介入できるか？
シニアエンジニアは、決済システムやバックグラウンドジョブにおいて、何年も前にこれらの問題を解決してきました。私たちは冪等性（idempotency）キー、チェックポイント、トランザクションログを使用してきました。AIがこれらの問題を作り出したわけではありません。ただ、それらが起こるスピードを速めただけなのです。
実行契約（execution contract）を決める前に、モデルを選んではいけません。それは、ブレーキのない車にレーシングエンジンを選ぼうとするようなものです。
以下のステップに従って、信頼性の高いワークフローを構築しましょう：
AIの作業を小さなステップに分割する 巨大なプロンプトを一つ使うのではなく、コンテキストの収集、変更の提案、チェックの実行、承認の依頼、変更の適用といった具合に細分化してください。
永続的なストレージを使用する データベースを使用して、ステータス、ステップ、試行回数を追跡します。ワーカーがクラッシュした場合、メモリではなく状態（state）から復旧できるようにします。
冪等性を強制する データを変更するすべてのアクションには、安定したキーが必要です。ステップが2回実行されても、結果は同じでなければなりません。
権限をティア（階層）で管理する 絶え間ない承認を求めるのはやめましょう。以下のようなティアを作成します：
- Tier 0: 読み取り専用タスク（自動承認）。
- Tier 1: 低リスクの書き込み（一括承認）。
- Tier 2: 高インパクトなタスク（人間によるチェックポイント）。
- 運用メトリクスを追跡する レイテンシやコストだけを見るのはやめましょう。タイムアウト率、リトライの成功率、ロールバックの頻度を追跡してください。
最良のAIチームは、魔法のようなプロンプトを自慢することはありません。彼らが運用するのは、退屈で、堅牢で、観測可能なパイプラインです。彼らの強みはモデルではなく、規律あるシステムエンジニアリングにあります。
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-29l4
Optional learning community: https://t.me/GyaanSetuAi