ほとんどのAIデモは動く。ほとんどのAIシステムは動かない。
この2つの文の差が、チームに数週間のコストをかける。時には数ヶ月。モデルは問題ない。ノートブックではプロンプトも良く見える。そして実データが届き、パイプラインが崩壊する。
これはモデルの問題ではない。パイプライン設計の問題だ。
動くデモと動くシステムの差
デモはキュレーションされた入力で動く。システムはあらゆる入力で動く。
デモでは、ドキュメントの長さ、レスポンスのフォーマット、タイミングを自分でコントロールできる。本番では、ユーザーが午前2時に40,000トークンの決算説明会トランスクリプトを送信し、分類ステップがタイムアウトし、下流の処理は何も理由を知らない。
チームがここで数週間を失うのは、デバッグの方向が間違っているからだ。プロンプトを調整する。モデルを入れ替える。実際の問題は、誰も失敗パスを設計しなかったことだ。
動くシステムは各ステップが失敗したときに何が起きるかを定義する。動くデモはそれを必要としない。
3つの具体的な失敗モード
1. トークン予算の超過
要約ステップを構築する。テストセット——平均800トークンの記事——では動く。リリースする。3日後、SECファイリングのバッチがパイプラインに到達する。平均長さ：18,000トークン。実行コストが20倍に跳ね上がる。レイテンシが3倍になる。200トークンの要約を期待していた下流ステップが1,400トークンを受け取り、自身のコンテキストウィンドウを壊す。
修正策はより良いモデルではない。修正策はLLM呼び出しの前に置くバジェットゲートだ——入力長を計測し、長いドキュメントをチャンキングパスにルーティングし、出力長の制約を明示的に適用するステップ。一度書けば、静かに永遠に動き続ける。
2. タイムアウトのカスケード
ステップAがLLMを呼び出す。ステップBはステップAを待つ。ステップCはステップBを待つ。ステップAに30秒のタイムアウトを設定する。負荷がかかると、LLMプロバイダーが35秒かかる。ステップAがタイムアウトする。ステップBは何も受け取らずnull参照エラーを投げる。ステップCは実行されない。どのステップも明示的に失敗していないため、パイプラインは成功を報告する——ただ止まっただけだ。
これがカスケードだ。各ステップが独立して設計されたために起きる。
修正策はステップ間の明示的な失敗コントラクトだ。各ステップは3つの状態を処理しなければならない：成功、失敗、無応答。リリース前に無応答パスをテストする。1時間に300記事を処理するニュース取り込みパイプラインでは、1つの未処理タイムアウトが誰も気づかないうちに40記事をサイレントにドロップする可能性がある。
3. サイレントな分類ドリフト
これは遅く、発見が難しい。
受信リードを業界別にルーティングする分類器を構築する。1ヶ月目はうまく動く。3ヶ月目までに入力分布がシフトする——営業チームが新しい業種をターゲットにし、インバウンドメッセージの言語が変わり、分類器はリードの18%を誤ルーティングするようになる。エラーなし。アラートなし。ただ間違った出力だけ。
サイレントドリフトは危険だ。システムが健全に見えるからだ。ログはクリーン。レイテンシは正常。ダメージはダッシュボードではなく、ビジネス成果に蓄積される。
修正策はスケジュールされた再評価を伴うリファレンスセットだ。50個のラベル付きサンプルを保持する。スケジュールに従って分類器をそれらに対して実行する——週次で通常は十分だ。精度が閾値を下回ったときにアラートを出す。分類器を固定されたままのコンポーネントではなく、劣化するコンポーネントとして扱う。
実際の修正はどのように見えるか
ニュース取り込みと分類のパイプラインを例にとる。12のRSSフィードから記事を取得し、トピック別に分類し、下流のコンシューマーにルーティングする。
強化前：
- 入力長チェックなし。1つの長い記事がバッチを止める。
- タイムアウトはHTTPレイヤーのみに設定。LLMレベルのハングは見えない。
- 分類精度はリリース時に一度、手動で確認。
強化後：
- 入力ゲートが4,000トークンを超える記事をモデルに到達する前に拒否またはチャンク化。バッチ停止がゼロになる。
- 各LLM呼び出しに15秒のハードタイムアウトとログ付きフォールバック。カスケード障害が止まる。
- 60記事のリファレンスセットが毎週日曜日に実行。精度が88%を下回るとSlackアラートが発火。ドリフトは数ヶ月ではなく数日で検出される。
これらの修正はいずれも、より良いモデルを必要としなかった。パイプラインをプロンプティングの問題ではなくエンジニアリングの問題として扱うことを必要とした。
パターン
上記のすべての失敗モードは根本原因を共有している：パイプラインがハッピーパスのために設計されていた。
本番システムはアンハッピーパスの明示的な設計を必要とする——予算超過、レスポンスの欠如、緩やかな劣化。その設計作業は華やかではない。デモを良くしない。初日と同じように90日目も動くシステムを作る。
地味なものが勝つ。
AIパイプラインを構築していて、リリース前に失敗パスについて第三者の目が欲しい場合は、会話を始める →