各LLMベンダーがモデルと一緒に公開しているLLMベンチマークテストの結果を見て調子に乗り、実際に使ってみるととてもあのテスト結果を叩き出したとは思えないほど性能が低かった、という経験は、一度や二度ではないはずです。ベンチマークテストで不当に高いスコアが出ているということです。明らかに何らかの方法(これから説明します)でテストはハックされ、スコアが水増しされています。
(今回はベンチマークテストで目的のLLMにだけ下駄を履かせるようなハックではなく、学習時点での不正について言及します)
ハックの経路は別の視点から別々に記述できます(つまりこれから紹介する経路はMECEではありません)。
学習データへのテストの混入
意図してか否かは置いておいて、学習のためのデータセットにベンチマークテストの問題が混入することがあります。これは事前学習とファインチューニングの両方の段階で混入する可能性があるだけでなく、デプロイ後のユーザーとの会話を学習に利用することによっても混入しえます。元の問題と完全に同じ文章なら機械的にこれらのデータを弾くことができますが、翻訳されていたり微妙に変更されていたりすると途端に検出が困難になります。
対策として、学習に使ってはいけないということを示す特殊な文字列を埋め込んだりもしましたが、スクレイピングの際に無視されたり削除されたりしたようです。
テスト特有のパターンを暗記してしまう
C-BOD(Chameleon Benchmark Overfit Detector)という手法によって判明した問題です。有名なベンチマークの意味や正解を変えずに言い回しだけを変えて出題してみたところ、その正答率は、26のLLMのうちほとんどで優位に低下したとのことです。これはベンチマークの文章と答えをそのまま暗記しており、意味を変えないようなちょっとした変更でも混乱し、せっかく暗記した答えを引き出せなくなったということを意味しています。
また、パラメータサイズが大きく元のスコアが高いモデルほど、このテストでの性能の低下が大きかったといいます。これは私の推測ですが、大きいパラメータのモデルはそれだけ多くの知識を詰め込めるということから考えるに、小さいモデルは暗記していないため素の推論能力が試された(だからその分初めからスコアが低い)のに対して、大きいモデルはその膨大な知識の中にベンチマークに関する知識を持っているために表面上のスコアが上がりやすかった、ということではないでしょうか。
こういったことがあって、ベンチマークテストでは高いスコアが出るにも関わらず、実際に使ってみると期待を裏切られるのです。
どうすんのこれ？
テストが静的なのが悪い
テストの問題が毎回同じなのがいけないのです。同じだから文章をそのまま学習されることの弊害としてテストのハックが行われるのです。
動的なテストを作る
時間的カットオフ
できる限り新しい情報を使ってテストを作成することで、モデルの知識だけでは太刀打ちできないようにします。
ルールに則った動的生成
数学の問題の数字だけを変更したり、テスト時にプロンプトのフォーマットを動的に生成して出題する手法です。
LLMの利用
別のLLMを用意すると、既存のテスト問題の構造をその場で改変させたり、面接官として対話させ受け答えの過程を評価したりといったことができます。
利用者それぞれが独自の非公開テストを作る
LLMに学習されていない情報を用いるという発想は時間的カットオフと共通しています。ベンチマークテストをしたい人それぞれが独自のテストを作成することで、独自の指標で性能を評価しようという考えです。
実際に私は自分が知っている様々な分野のドメイン知識を問う問題集を作成しました。実際の問題はお見せできませんが、「東方風神録の4面に登場する中ボスの名前は？(犬走椛)」「問題の原因を人の悪意に求める傾向をなんといいますか？(敵意帰属バイアス)」といった短い知識問題の詰め合わせです。これを作ってわかったのは、知識の乏しい分野を尋ねられるとReasoningモデルは「これはAだ、いやAだ、いやAだ、いや……(実際はAではない)」といった感じでハルシネーションの無限ループに陥ること、小さいモデルほど詳細な知識を答えられないことなどです。
もう一つ、かつて用いていたテストを紹介します。「クライアントがJavaScriptを使えない状況で動作するBBSをnodejsとjsonで作ってください」というものです。最近のローカルLLMは(小さいものを除いて)大体これを難なく実装するようになってきたので、今は使っていません。このテストでは、言われたことをきっちり実装できるかを測り、これがクリアできたら、ある程度雑な要求でも当然必要になる機能を推測して提案・実装できるかを測ります。詳細な要件は提示せず、しかし裏できっちり定義しておき、それらの項目をいくつクリアできるかをスコア化します。これを作ってわかったのは、Reasoningが後者の能力に貢献するということです。
このように、問題の形式によって計測できるLLMの性能が当然ながら変わってくるということを意識してテストを作成する必要があります。
引用・参考文献
A Survey on Data Contamination for Large Language Models
Forget What You Know about LLMs Evaluations — LLMs are Like a Chameleon
コメント