ベンチマークへのアプローチの仕方が、ちょっと問題があるように思います。フロンティアラボがモデルをベンチマークする方法について読んでみると、彼らは本質的には新しいモデルを作り、ハーネスを設定し、そのうえで、わずかな改善を示すだけのために大規模なベンチマークスイートを実行しているようです。
このやり方にはいくつか問題があります。モデルを反復するのに多大なリソースを浪費しており、実質的に炭素を自信と引き換えにしているのではないかと心配しています。たとえば最新のGeminiのベンチマークを見ると、30,000件のプロンプトを適用しています。結果の頑健性を確保することには言い分があるとしても、彼らは反復するたびに同じベンチマークを単にもう一度実行し続けて、リソースを使い続けないのでしょうか？
さらに、他の組織が自分たちのMLOpsのためにこれらの習慣を模倣するなら、それも懸念です。コミュニティとして、モデルに対する「自信がある」という印象を持たせるために、ただリソースを消費し続けているように感じます。しかし、これらのベンチマークを通じて実際に何が読み取られているのかには、私は必ずしも納得していません。通常の指標はpass@kですが、それはモデルの能力に対する確信をあまり生みませんし、改善を効果的に伝えることもできません。つまり要点は、モデルが成功するまでに何回試行が必要かを見ているだけ、ということです。
こうした考慮を踏まえて、より筋の良いベンチマークを作るためのさまざまな枠組みを考え始めました。ベイズ的手法は、一般的なユースケースにおける結果の「自信」をモデル化するのに有用かもしれないと思いました。たとえば、「反復A」が「反復B」より本当に優れているかを判断する、といったことです。理想的には、必要な自信レベルに到達するのに、ベンチマーク一式の丸ごとのアッセイを使う場合よりも少ないサンプルで済むはずです。
いくつかの潜在的な解決策を探るために、私はPythonパッケージbayesbenchを作っていて、人気のツールチェーンに組み込むためのアダプタを作成しています。
これは特に、膨大な量のデータを収集する必要なくエージェントを評価するのに役立つのではないかと考えています。パフォーマンスの推移を早い段階で判断する手助けになるはずです。アイデアやパッケージを試せるように、デモはHugging Face上で作成しました。いくつかの制約があることも示しています。たとえば、モデルがあまりにも似ている、あるいは性能が十分に差別化されていない場合、シグナルを抽出するのが難しくなります。しかし、モデルが十分に異なっていれば、大幅にリソースを節約できます。
他の皆さんがベンチマークについてどのように考えているのか気になります。tinyBenchmarksには馴染みがありますが、評価対象のモデルがより強力になり、維持コストが高くなっていくにつれて、評価はどのように変化していくと思いますか？ また、パッケージやアダプタの開発を手伝ってくれる人がいれば、ぜひここにいる方々と一緒に取り組めたら嬉しいです。
[link] [comments]
