AI時代のオブザーバビリティはどうあるべきか
LLMを組み込んだシステムの運用には、従来の障害対応とは異なる戦い方が必要だとわかった。とはいえ、挙動は確率的で再現性がなく、出力にも揺らぎがあり、モデルの内部はブラックボックスというLLMの特性を鑑みると、もはやあきらめるしかないようにも思えてくる。
けれども萩野氏は、「対処法は意外とシンプルで、見るもの(=観測対象)を変えればいいだけだ」と強調する。
AI時代のオブザーバビリティは、「壊れたら気づく」「障害が起きたら気づく」といった単純な話ではない。なぜそうなっているのか、「“説明できる状態”をつくること」がゴールとなる。
さらに言えば、LLMを組み込んだシステムでは、従来システムのように「壊れたor壊れていない」という二元論で捉えることはできない。より複合的なものとして、障害という概念そのものを再定義する必要があるのだ。
そのうえで萩野氏は、LLMを組み込んだシステムの場合、最低限見るべきシグナルとして、次の4つを挙げた。
レイテンシ
どのくらい遅いのか。その遅さは、毎回コンスタントなのか、それとも揺らぎがあるのか。LLMは、外部APIのようにクラウド経由で呼び出されるものであり、膨大な計算を行う推論エンジンでもある。そのため、応答時間の遅延が発生しやすいコンポーネントだと言える。したがってLLMを組み込んだ時点でレイテンシは主要な観測対象になる。
エラー
タイムアウトやレート制限といった従来のシステムでも生じていたエラーに加え、トークン超過やポリシー違反など、LLMの利用に伴って顕在化しやすいエラーも増えてくる。これらを監視し、発生の有無を観測する必要がある。
入出力の関係
これも従来のシステムとは大きく異なる点だ。同じ入力に対して出力が揺らいでいないか、揺らいでいるならどの程度揺らいでいるのか。入力の細微な変化に対して、出力が過度に変わっていないか。こうしたふるまいを観測しなければならない。
コスト
サービスの提供形態上、LLMは使用量が増えれば増えるほど、コストが増えていく。そのため、従来のシステムでいうところの障害や不具合、エラーや性能劣化によって、想定外にトークンが増加するとコストがかさみ、運用ダメージとして着実に蓄積されていく。
LLMを組み込んだシステムでは、CPUやメモリだけを見ていても、その変化に気づけない場面が増えている。もはや問題の中心は、インフラのような物理的・技術的レイヤーから、ふるまいや出力に影響を与える“意味のレイヤー”へと移ってきているからだ。

