ローカルLLMを自分の質問セットで評価する方法

公開ベンチマークは候補を絞る材料になるが、自分が毎日行う作業でも同じ順位になるとは限らない。

コード生成、要約、文章校正、JSON生成、日本語での会話では、必要な能力も失敗したときの重さも違うからだ。

候補を2〜3モデルまで絞れたら、自分の作業を代表する質問セットを作り、同じ条件で比べる。大切なのは質問数を増やすことより、採点基準と実行条件を先に決めることだ。

図を拡大して見る

図: 判断材料を1枚に整理。用途ごとの優先順位は本文の条件分岐で確認する。

質問は普段本当に使う作業から作る

最初は10件前後でもよい。実際に繰り返す作業を複数種類入れる。

コード用途なら、たとえば次のようなものがある。

• 小さな不具合の修正
• 既存コードの説明
• テストケースの追加
• 指定形式での変更案

文章用途なら、

• 長文の要約
• 事実を落とさず短くする
• 指定した文体への書き換え
• 表から条件を抜き出す

といった質問を使える。

一つの質問へ多くの能力を詰め込みすぎず、「何ができれば合格か」を後から判定できる形にする。

採点基準は回答を見る前に決める

モデルAの回答を見てから基準を作ると、その回答に都合のよい条件へ寄せてしまうことがある。

たとえばJSON生成なら、次のように決められる。

作業: JSON生成
必須条件:
- 正しいJSONである
- 必須キーを4つすべて含む
- 余分な説明文を付けない

採点:
2 = 全条件を満たす
1 = 内容は正しいが形式違反がある
0 = 内容の欠落・誤りがある

文章品質のように主観が入りやすい作業でも、「事実を落とさない」「指定文字数に入る」「禁止語を使わない」のような確認可能な条件を混ぜると比較しやすい。

モデル名を隠して比べる

可能なら出力をA、B、Cのように保存し、どのモデルか見ない状態で採点する。

パラメータ数や提供元、普段の評判を知っていると、「大きいモデルの方が良いはず」という期待が判定へ入ることがある。

完全な実験環境でなくても、回答を採点してからモデル名を開く手順だけで先入観を減らせる。

実行条件をそろえて記録する

同じ質問でも、実行環境や生成設定が違えば結果は変わる。最低限、次を保存する。

項目	記録する内容
モデル	正確なID・リビジョン
配布ファイル	GGUFなどの形式・量子化
実行環境	名前・バージョン・バックエンド
コンテキスト	コンテキスト長
生成設定	temperatureなど主要設定
ハードウェア	GPU・CPU・RAM
質問セット	バージョンを付けた固定内容
日付	実行日

速度測定と回答品質の評価は目的が違うが、条件を残していない数字を代表値にしないという点は共通している。

llama.cppのllama-benchも、モデルやプロンプト処理、トークン生成などの条件を指定して測定するための道具だ。別条件の数字を一つの表へ混ぜない。

出力にばらつきがあるなら複数回試す

temperatureを0以外にするなど、出力へばらつきが出る設定では、1回の成功や失敗だけでモデル全体を判断すると偶然の影響が大きい。

重要な作業なら複数回実行し、成功率や失敗の種類を残す。反対に、ほぼ同じ出力を再現できる設定なら、まず同じ条件で結果が安定するかを見る。

「終了コードが0だった」「返答が返ってきた」だけでは回答品質の評価にならない。

公開ベンチマークと自分の評価を両方使う

自分の質問セットだけを見ると、狭い用途へ偏った選択になることもある。公開ベンチマークは一般的な能力の参考として残し、自分の評価は「この作業で使えるか」を確かめる材料にする。

結果は総合点だけでなく、失敗の種類も残す。

モデルA
- JSON: 9/10
- 要約: 7/10
- コード: 5/10
- 主な失敗: 形式から外れる

モデルB
- JSON: 7/10
- 要約: 8/10
- コード: 8/10
- 主な失敗: 条件の読み落とし

用途によって重大な失敗は違う。すべてを一つの総合順位へ押し込まず、自分が必要とする作業ごとに見る。

まだ候補モデルを絞れていない場合は、3B・4Bと7B・8BのローカルLLMはどう選ぶ？から始めると比較対象を減らせる。