この記事を読んで最初に思ったのは、これはベンチマーク記事というより「ベンチマークを雑にやると、たぶん簡単に自分たちをだませる」という警戒心の表明だな、ということだった。SREの調査支援ツールは、見た目が賢そうでも、実際に事故対応で役に立つかはかなり怪しい。しかも同じ質問でも答えがぶれる。だから、ただデモで気持ちよくなるのではなく、同じ条件を固定して、しかも答えを盲検で採点する、という発想はかなり筋がいいと思う。
特に引っかかったのは、合成データの作り方にかなり神経を使っている点だ。現実の障害っぽいノイズを入れつつ、わざと似たような別の異常も混ぜる。さらに、公開データセットをそのまま使うと学習済みの知識で当ててしまうかもしれないから、オリジナルのシナリオを作る。ここまでやると、ようやく「LLMが過去に見たパターンを思い出しているだけではない」と言えそうだし、逆に言うと、ここまでしないと評価がかなり怪しくなるのだろうと思った。
もう一つ面白かったのは、ClickHouseを直接SQLで触らせる方法より、ClickStack MCPのように「高レベルの観測用プリミティブ」を渡したほうが、単に便利というだけでなく、探索の仕方そのものを安定させられる、という考え方だ。SQLは自由だけど、自由すぎてモデルが毎回違う回り道をしやすい。観測基盤の世界では、そのぶれがそのまま調査品質のぶれになる。だからツールが抽象化を持つことにはかなり意味がある、という主張には納得した。
ただ、ここで少し気になったのは、こうした評価がうまくいくほど、現場との距離もまた少し開くことだ。合成シナリオはきれいに作れるけれど、実際の事故はもっと散らかっているし、データの欠損も、人間の判断ミスも、組織の事情も混ざる。だからこのベンチマークは「現実の完全な代わり」ではなく、「少なくとも道具としての質を比較する土台」として見るのが正しいのだと思う。そこを取り違えずに、再現性のある比較環境を公開しているのは、かなり誠実だと感じた。
参考: How we build and evaluate our MCP server for SRE agents | ClickHouse
