「LLM Observability」で観測可能になるものとは
続いて萩野氏は、DatadogのLLM Observabilityの有用性へと、話を進めた。
従来のオブザーバビリティは、CPU・メモリ・エラー率・レスポンスタイムといったものを見ることで、多くの障害原因を特定し、解決策を導いてきた。
だが、LLMが組み込まれると、APIは正常でインフラも問題なく、エラー率も上がっていないにもかかわらず、「なぜか変な回答が返ってきてしまう」という事象が起きる。
つまり、「壊れているかどうか」ではなく、「期待通りにふるまっているかどうか」へと問題が変わってきているのだ。「その判断材料が、従来のオブザーバビリティには存在しない」と萩野氏は指摘する。
そこで有効なのがDatadogのLLM Observabilityだ。これは単なるログ拡張ではなく、LLMを“観測可能なコンポーネント”として取り扱うための仕組みである。Overview・Traces・Experiment・Playground・Evaluationsといった項目が並び、LLMを評価・分析・改善できる対象として設計していることがわかる。
LLM Observabilityで見えるようになるものとしては、「Prompt：どんなプロンプトを投げたのか」「Completion：どんなレスポンスがあったのか」「Tokens：トークンがいくつ使われたのか」「Latency／Errors：どこで遅くなったのか」が挙げられる。特長的なのは、これらが紐づき、“1つのコンテキストを持った観測データ”として見られる点だ。
「LLMの挙動は再現できない。この事実は受け入れるしかない。だからこそ、再現実験に時間をかけるのではなく、そのとき何が起きていたのかを正確に記録しておくという発想に切り替えることが重要だ」と語る萩野氏。
たとえば、DatadogのTracesを見てみると、漠然とLLMが遅いのではなく、「どのモデルで呼び出した、どのプロンプトの処理が重いのか」「どの外部ツールからの呼び出しがボトルネックになっているのか」といった部分を特定できる。
また、LLMは壊れていなくても知らぬ間に品質が落ちていることもあるが、DatadogのEvaluationsを見れば、回答の正確性、一貫性、ポリシー準拠といった観点から、LLMの出力品質を定量的に評価することができる。
さらに、DatadogのTokensでは、トークンの使用量をトレース単位やプロンプト単位で把握できるため、「どの機能が金食い虫なのか」が一目瞭然になる。
このように、DatadogのLLM Observabilityを活用して、再現性ではなく説明可能性の観点から情報を記録・収集しておくことで、障害対応のストレスを大きく低減できるだけでなく、経営の観点から次の一手を考えるうえでも大いに役立てられるという。
「DatadogのLLM Observabilityを正しく活用すれば、LLMを観測対象とすることができる。障害対応も勘に頼るのではなく、分解・分析したうえで具体的な説明に落とし込むことが可能だ。見えないAIは怖いが、見えるAIなら、効率的に運用できるシステムになる」と語り、萩野氏はセッションを締めくくった。
Datadog Japanからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
