← 概念辨析に戻る

Concept Contrast Fable

モデルに問題があれば予備に替えることと、システムに問題があっても何とか使えること

先に結論:モデルフォールバックは問題のあるモデルだけを交換し、デグレードはシステム全体が一部機能の失效後も限定的だが利用可能なサービスを提供し続ける必要がある。高可用性Agentを設計する時、予備モデルへの交換はエンジン故障しか解決できないが、デグレードは依存チェーン上のどの環が切れても解決できる。

モデルフォールバックは問題のあるモデルだけを交換し、デグレードはシステム全体が一部機能の失效後も限定的だが利用可能なサービスを提供し続ける必要がある。高可用性Agentを設計する時、予備モデルへの交換はエンジン故障しか解決できないが、デグレードは依存チェーン上のどの環が切れても解決できる。

寓話

帆を替え、壊れた船が岸に着く

山道郵駅はもともと一套の慣れた方法で運営されていた。主路が順調な時は、駅長が速馬で袋ごと手紙を送り、旧来のリズムで事を運べばめったに問題は起きなかった。

その後、事態は大きくなった。本道が崩落しても手紙は届けなければならず、催促の声は早朝から夕方まで並んだ。新人はこれは数量の問題だと思い、人を増やし時間を延ばせばよいと考えた。しかし古参は、多くの細部がすでに旧来の方法で耐えられる境界を越えているのを見ていた。

掌事人は最初の方法を試した。急場しのぎで別の一番速い馬を探すというものだ。最初の数日は確かに改善が見え、隊列は短くなり、外部の者もこの技芸がついに新しい局面に追いついたと思った。

しかし厄介ごとはすぐに姿を変えた。進度を急ぐために検査を省く者、不適切な仕事を無理に古いプロセスに押し込む者、最も熟練した者がかえって雑事に足を取られた。誤りは常に表に見えるとは限らず、納品後に初めて現れることが多い。 古い帳簿は来歴を説明できても、次にどう直すべきかは説明できない。

主事人はさらに規則を加え、各人にもっと署名し、もっと報告し、保護の層をもう一枚補うよう求めた。紙の上では周到に見えたが、現場はさらに遅くなった。職人たちは自分に非がないことを証明するのに忙しく、本当の亀裂は依然として元の場所で広がっていた。傍観者には結果が良くなったり悪くなったりするようにしか見えず、現場の者は速度、品質、責任のどれを先に救うべきかますます判断しにくくなった。 誰もが自分は少し多くやったと思っていたが、全体としての物事はそれによってより安定することはなかった。

寡黙な老職人はいくつかの失敗を机の上に並べた。彼は誰も責めず、皆に同じ細部を見せた。新しい制限は日常の練習にまったく入らず、納品直前に突然現れるだけだった。彼は数回の手戻りを発生順に並べ、そこで皆は、誤りがいつも同じ曲がり角で拡大されることに気づいた。

そこで工房は新しい規則に改めた。速馬にも道がなければ、要約を送る、重い荷は後回しにする、急ぎの便を優先する。最初は誰も慣れず、手足を縛られたように感じた。しかし何度か繰り返すうちに、粗い近道はふさがれ、本当に堅実な動きがゆっくりと残っていった。

同じようなプレッシャーに再び直面したとき、デリバリーは派手にはならなかったが、明らかに信頼性が増した。駅長はついに理解した:同等の道に切り替えることは一つのこと、コアを守るために降格することは別のことである。最後になってから補救しようとすると、コストはすでに前のすべての選択に埋め込まれていることが多い。この新しい道はコストを消滅させたわけではないが、コストを早めに可視化し、まだ変更できるうちに対処できるようにした。

モデルのロールバック

主モデルが利用不可、タイムアウト、または品質基準を満たさないとき、自動的に予備モデルへ切り替えるか、あらかじめ設定した結果を返すことは、モデル層の可用性戦略である。

降級

システムの一部機能または依存関係が失効したとき、全体としては能力を低下させ、機能を減らし、または経路を簡素化する形で限定的なサービスを提供し続ける。

物語の対応

  • 予備帆への交換:モデルフォールバック、モデル層で故障コンポーネントを差し替える
  • 船倉に浸水、ポンプが半減、ナビゲーションが断続:複数システムが同時に損傷する複雑な故障
  • 船全体の降級方案:降級戦略におけるリソース、機能、経路の再配分
  • デグレード表:各依存の失敗後のトリガー条件と退化動作をあらかじめ定義する
  • まず帆が壊れたのか船が壊れたのかを判断する:まず故障の階層を特定してから戦略を選ぶ

Agent の高可用性アーキテクチャに落とし込む

Agent システムの高可用性はモデルのフォールバックだけに頼ることはできない。検索、ツール、承認、ストレージ、メッセージチャネルなど各層の縮退動作を同時に計画する必要がある。たとえば検索が落ちたら会話履歴で無理に答えさせるのか、ツールがタイムアウトしたらスキップしてユーザーに伝えるのか、承認がタイムアウトしたら緊急チャネルを使うのか。

京ICP备2026014272号