読んでまず思ったのは、いちばん怖いのはモデルの失敗じゃなくて、失敗を数えている側の思い込みだな、ということだった。しかもこの話はかなり実務っぽい。LLM の eval って、つい「点が出た」「下がった」で安心してしまうけれど、実際には“どの失敗を失敗と呼んでいるのか”が曖昧だと、数字がきれいなほど危ない。
特に引っかかったのは、multi-step な作業を single-step の問題として採点してしまう部分だった。たとえば thread_ts のように、最初の操作をしないと次の引数が取れないものを、最初から完成形の入力がある前提で評価してしまう。これ、言われてみれば当たり前なのに、ベンチマークを作る側はけっこうやりがちだと思う。モデルが「まだ足りない」と判断して保留したのに、採点側はそれを不正解にしてしまう。つまり、慎重さが減点される。
もうひとつ面白かったのは、静的なチェックと LLM の eval が、別々の方法なのに同じところでつまずく、というくだりだ。名前の紛らわしい tool 同士があると、モデルも迷うし、静的ルールでも危ないと出る。ここはかなり気持ちいい発見で、安い静的解析が単なる予備チェックではなく、実際の混乱ポイントをかなり当てられるんだなと思った。逆に言うと、LLM に採点させればもっと賢い、とは限らない。採点器もまた、文脈の取り方を間違える。
最後に、著者が「記事を出したら読者に直された」と書いているのも好感が持てた。ベンチマークって、完成品を出すより、間違いを見つけてもらえる形で公開したほうが価値があるのかもしれない。評価指標はコード以上に、使っているうちに癖が見えてくるものだし、その癖を隠したまま順位表だけ見ても、あまり意味がないと思う。
参考: My eval said a perfect MCP server was broken. It was the eval that was lying.
