もっともらしい分析を、まるごと作り上げて答えるAIエージェント
Grafana LabsのSenior Developer AdvocateであるNicole van der Hoeven氏は、Grafanaに特化したAIエージェント「Grafana Assistant」の開発を振り返るところから講演を始めた。
「Grafana Assistant」は、Grafana上のあらゆるデータについて質問に答え、ダッシュボードを作成・管理し、本番のインシデントを調査し、GitHubへのPR作成やk6での負荷テストといったツールとも連携できる。公開データベースRAWG.ioのゲーム情報をもとに「ダッシュボードを作って」と一言頼むだけで、クエリを一切書かずにダッシュボードが出来上がる──それがAssistantの当初のビジョンだった。
もっとも、Assistantは元々ハッカソン発のプロジェクトで、フロントエンドのE2Eテスト（エンドツーエンドテスト：システム全体の動作を検証するテスト）と、バックエンドは手動テストしかない状態でリリースされていた。転機になったのは、社員のWilliam Dumont氏が見つけたバグだった。Assistantにはトレーシングバックエンドである「Tempo」からトレースを取得して分析するツールがあったが、ルートスパンが欠けているケースでは、そのトレース自体がAssistantに渡すコンテキストに含まれていなかった。
問題は、トレースがないという事実そのものではない。Assistantが、あたかもトレースを受け取ったかのように振る舞い、もっともらしい分析をまるごと作り上げて答えてしまったことだ。「トレースが見つかりません」と言ってほしいところを、Assistantは何も疑わずに嘘の分析を返した。van der Hoeven氏は「自分たちが作ったシステムを自分たちで信頼できないなら、顧客に信頼してもらえるはずがない」と、この出来事が「大いなる疑い」の始まりだったと語る。
LLM、LLM-as-judge──「二重の不確実性」がもたらす難しさ
チームが最初に取り組んだのは「LLM Spec」という社内ベンチマーク兼評価基盤の構築だ。本番の運用会話を蒸留して作った「ゴールデンデータセット」をシナリオとして用意し、Prometheus・Loki・TempoをDocker上で動かした完全に合成された環境で、あらかじめ正解が分かっているタスクとしてAssistantに解かせる。評価の枠組みは、テストにあたる「シナリオ」、その出来を判定する「ジャッジ」（LLM-as-judgeを含む）、そして数値化した「スコア」の3要素で構成されていた。Tempoのバグも、これがあれば検出できたはずだった。
ところが、ここでも問題が見つかる。1つ目は、LLM Specがすべて緑（合格）と表示していても、個別に応答を確認すると明らかに間違っているケースがあったこと。2つ目は、同じテストを2回実行しただけで結果が変わってしまうことだった。LLMの非決定性がそのまま信頼性の測定を難しくしていた上に、判定に使うLLM-as-judge自体も非決定的だったため、これは「二重の不確実性」だったとvan der Hoeven氏は表現する。一度だけ成功したことを示せても、それは「確実にできる」ことの証明にはならない。
そこでチームは「pass@3」（3回中1回以上成功）、「pass^3」（3回とも成功）、「0-for-3」（3回とも失敗）という新しい基準を導入した。3回とも失敗する「0-for-3」をあえて2番目に良い結果として扱うのがポイントだ。間違っているとしても、常に同じように間違っているなら対処のしようがある。本当に厄介なのは、成功したり失敗したりを繰り返す「ときどき正しい」状態だ。この基準の導入で、Assistantの挙動とテスト結果のばらつきはかなり抑えられるようになった。
