オーケストレーションの負債がモデルの負債の前に表示される

モデルの品質は重要です。しかし、多くのシステムでは、最初の高額な債務形態はオーケストレーション債務です。

クリーンな運用モデルを持たずにチームがツール、プロンプト、再試行、条件分岐を積み重ねると、その負債が蓄積します。システムは出荷を続けていますが、ソース コードを読んだりログを再構築したりすることなく、入力からアクションまでの完全なパスを説明できる人は誰もいません。

警告サイン

• 共有ロジックを使用せずにフロー間でコピーされた再試行
• メインのワークフローと矛盾するフォールバック パス
• ツールの障害の責任者が不明瞭
• ビジネス ポリシーを暗黙的にエンコードするプロンプト

なぜ高価になるのか

オーケストレーションの負債により、運用上の不確実性が広がります。すべての新機能は、以前の機能から不明瞭な動作を引き継いでおり、デバッグ時間は製品の機能よりも速く増加します。

より良いルール

ワークフロー設計をコードを接着するのではなく、アーキテクチャとして扱います。フローがクリティカルである場合、明示的な状態、明示的な遷移、および明示的な人間によるチェックポイントが必要になります。

結論

多くのチームは、最初に別のモデルを必要としません。彼らは、すでに持っているモデルを中心としたより明確なシステムを必要としています。