ダッシュボードは何が起きたかを示す。フィードバックループはそれに対処する。
この違いは本番AIにおいて重要だ。多くのチームはシステムを十分に計装して事後的に障害を確認できる。しかし、ユーザーがエラーに遭遇する前にループを閉じる修正経路を構築しているチームは少ない。
この記事では、本番フィードバックループの実際の構成要素、実装する価値のある3つのループ設計、そして脆弱なカスタムインフラを構築せずにそれらを連携させる方法を解説する。
本番AIにおけるフィードバックループとは
フィードバックループには3つの要素がある。
- 入力シグナル — 何か問題がある可能性を示す計測可能なイベント
- 分類 — そのシグナルがノイズか実際のエラーかを判断するロジック
- 修正経路 — 更新されたコンテキストやパラメータとともにシステムへ再入力する自動アクション
修正経路こそが、ループとアラートを区別するものだ。アラートは人間に通知する。ループは行動する。人間はレビューするが、システムは人間が気づくのを待たない。
修正経路がなければ、それはモニタリングだ。モニタリングは必要だが、フィードバックループではない。
構築する価値のある3つのループ設計
1. ハートビートチェック
ハートビートチェックは、既知の入力を一定のスケジュールでシステムに送り、出力を既知の正常ベースラインと比較する。
例：10分ごとに、決定論的な期待出力を持つテストプロンプトを送信する。レスポンスが定義された閾値——たとえばコサイン類似度0.85未満——を超えて逸脱した場合、ループはその実行にフラグを立て、差分をログに記録し、次の実際のリクエストをフォールバックモデルまたはキャッシュされたレスポンスへルーティングする。
これにより、モデルのドリフト、上流APIの劣化、エラーをスローしないサイレント障害を検出できる。重要なのはテスト入力を安定させることだ。テストを変更するとベースラインが失われる。
ハートビートチェックは、新規性よりもレイテンシと出力の一貫性が重要なシステム——分類タスク、構造化抽出、ルーティング判断——に最も適している。
2. 出力分類監査
すべての不正な出力がハード障害というわけではない。技術的には有効でも、コンテキストに対して誤っている出力——トピックから外れている、不完全、または自信を持って誤っている——も存在する。
出力分類監査は、ライブ出力のサンプルに対して軽量なセカンダリモデルを実行し、ルーブリックに基づいてスコアリングする。ルーブリックはシンプルでよい：出力に必要なフィールドが含まれているか、定義されたトピックスコープ内に収まっているか、フラグされたパターンを回避しているか。
例：毎時10%の出力を監査する。そのサンプルのエラー率が5%を超えた場合、ループはバージョン管理されたプロンプトストアからプロンプト修正をトリガーし、デプロイなしでそれを差し替える。
この設計には2つのものが必要だ：テスト済みフォールバックを持つバージョン管理されたプロンプトストアと、プライマリモデルより高速かつ安価なスコアリングモデル。ファインチューニングされた分類器や小型のinstruction-tunedモデルが機能する。GPT-4がGPT-4を監査するのはコストが高く、相関した障害を引き起こす。
3. 負荷下でのバッチサイズチューニング
AIシステムは負荷下で明らかでない形で劣化する。スループットが低下し、レイテンシが上昇し、出力品質が落ちる——多くの場合、エラー率が急上昇する前に。エラーが見えるようになった時点では、すでにダメージが生じている。
バッチサイズチューニングは、リアルタイムのレイテンシシグナルに基づいてシステムが同時処理するリクエスト数を調整する。ループは次のように機能する。
- 60秒のローリングウィンドウでp95レイテンシを計測する
- p95がSLA閾値を超えた場合、バッチサイズを20%削減する
- p95が5つの連続ウィンドウで閾値を下回り続けた場合、バッチサイズを10%増加する
これは静的な設定ではなく、制御ループだ。システムをサイレントに劣化させるのではなく、品質エンベロープ内に保つ。
上記の数値は出発点だ。実際のSLAと負荷下でのシステムの観測されたレイテンシカーブに対してチューニングすること。
脆弱なインフラなしにこれらを連携させる
3つのループが独立して動作すると、3つのメンテナンス面が生まれる。目標は、3つのループすべてが書き込みと読み込みを行う単一のイベントバスだ。
各ループは構造化されたイベントを発行する：ループタイプ、シグナル値、閾値、実行されたアクション。中央ルーターがそれらのイベントを読み取り、優先度ロジックを適用する——ハートビート障害は監査トリガーより優先され、監査トリガーはバッチサイズ調整より優先される。
これにより修正経路の競合を防ぐ。ハートビート障害がトラフィックをフォールバックモデルへルーティングした場合、バッチサイズループはプライマリのレイテンシではなく、フォールバックモデルのレイテンシで動作すべきだ。
イベントスキーマはフラットでバージョン管理されたものにすること。複雑なネストされたスキーマはループロジックが変更されると壊れる。バージョンフィールドを持つフラットなスキーマの方が移行しやすい。
すでに運用していない限り、汎用ワークフローオーケストレーターの上に構築することは避けること。新しいオーケストレーションレイヤーの学習とメンテナンスのオーバーヘッドは、シンプルなメッセージキューといくつかのワーカーのコストを通常上回る。
実際にはどのように見えるか
3つのループすべてを実行するシステムは、人間の介入なしに、発生から1〜2分以内にほとんどのエラークラスを検出・修正できる。人間はイベントログをレビューし、閾値をチューニングし、プロンプト修正を承認する。個々の障害のトリアージは行わない。
それが目標だ：ソフトウェアの速度で自己エラー修正を処理し、人間の判断が必要な決定だけを浮上させるシステム。
ここでは地味さが勝つ。6ヶ月間静かに動作してユーザーが見る前に40件のエラーを検出するループは、誰も行動しない美しいダッシュボードを生成する洗練されたオブザーバビリティスタックより価値がある。