大きいモデルほど幻覚が減るは成り立つか — AA-Omniscience を運用者目線で読む

大きいモデルほど幻覚が減る、は成り立たない

結論から書きます。パラメータ数が大きいモデルほど幻覚（hallucination、事実でない内容を自信たっぷりに出力すること）が減る、という直感は、最近のベンチマークでは裏切られています。AA-Omniscience という幻覚率ベンチで、商用大型モデルの GPT-5.5 が幻覚率 86% を記録した一方、MIT ライセンスでより小さい GLM-5.2 は 28% にとどまりました。3 倍以上の開きです。

この比較を見つけたのは arrowtsx.dev の「Bigger Models Are Not the Way」 という記事でした。数字の出どころは Artificial Analysis が公開している 2 つの指標です。私はこれを「大型モデルはダメ」という話としてではなく、「ベンチの数字をどう読むか」の教材として読みました。運用者にとって効くのは、結論の一言よりも、その一言が立っている前提のほうです。

知能指数と幻覚率は、別の軸

まず押さえたいのは、ベンチマークには性格の違う指標が同居していることです。Artificial Analysis の Intelligence Index（知能指数、複数タスクの総合スコア）はモデルの「賢さ」を測りますが、AA-Omniscience が測る幻覚率は「知らないことを知らないと言えるか」を測ります。この二つは、似ているようで別の軸です。

賢い、つまり Intelligence Index が高いモデルが、同時に幻覚を出しにくいとは限りません。むしろ饒舌で自信があるぶん、知らない領域でも堂々と空白を埋めにきます。困ったことに、ベンチの棒グラフは上にあるほど安心という刷り込みを私たちに与えますが、幻覚率のグラフは下にあるほど安心です。同じ向きの目で眺めると、見事に逆を掴みます。

私は以前、Intelligence Index の高さだけでモデルを選び、社内ドキュメントの要約タスクで存在しない設定キーを堂々と書かれたことがあります。賢いモデルだから安全だろう、という雑な代入をしていました。賢さと正直さは、別々に測らないといけません。

86% と 28% の間にあるもの

記事が挙げている数字を並べると、差は一目で分かります。幻覚率は低いほど良い指標です。

モデル	幻覚率	パラメータ規模
DeepSeek V4 Pro	94%	1.6T（アクティブ 49B）
GPT-5.5	86%	推定 1〜2T
Fable 5	48%	非公開
Opus 4.8	36%	推定 1〜2T
GLM-5.2	28%	753B（アクティブ 40B）

ここで注意したいのは、この 86% と 28% の値は AA-Omniscience という集計ベンチの結果だという点です。記事の著者はさらに、OpenRouter 上で Python の asyncio イベントループポリシーに関するコーディング課題を 1 問だけ走らせ、両モデルに同じシステムプロンプトと高い推論努力（reasoning effort）、temperature=1 を与えて、同じ方向の差を再現しています。

ただしコーディング課題のほうは 1 問です。n=1 の再現は「方向の確認」には使えても、それ単体で 3 倍という比率を裏づけるものではありません。重みを持っているのは、あくまで複数タスクを集計した AA-Omniscience のスコアのほうです。ヘッドラインの「3 倍」を引用するときは、その 3 倍がどのベンチの、何件の集計から来たのかをセットで言う。これは運用者の最低限の礼儀だと思っています。

「大きさ」では説明できない

幻覚率の順位は、パラメータ数の順位とまったく揃っていません。最大の DeepSeek V4 Pro（1.6T）が最悪の 94%、最小クラスの GLM-5.2（753B、アクティブ 40B の MoE 構成）が最良の 28% です。大きさが幻覚率を決めるなら、この並びは説明できません。

では何が効いているのか。ここは断定を避けますが、有力なのは事前学習の規模ではなく post-training（事後学習、人間の選好に合わせる調整や拒否の校正）の質です。「知らない」と言える校正がどれだけ効いているかで、同じくらいの規模でも幻覚率は大きく動きます。モデルの振る舞いが事後学習で決まるという話は、別の記事で post-training がモデルの個性を決める として書きました。

もう一つ、GLM-5.2 が MIT ライセンスの公開重みである点も運用上は無視できません。重みが手元にあれば、推論の中身を覗いたり、自分のドメインで追加学習して幻覚を抑えたりできます。スコアが良いだけでなく、改善のハンドルを自分で握れる。ローカルで動かせるモデルが実務で「使える」水準に届いてきた流れは、以前 ローカル LLM が使えるに変わった 2026 年 で扱いました。

運用者は、自分のタスクで測る

ここまでをひとことにすると、モデル選定を Intelligence Index やパラメータ数の大きさだけで決めてはいけない、になります。公開ベンチは出発点であって、終着点ではありません。

実務でやるべきことは地味です。自分のタスクに近い小さな評価セット（30〜50 件あれば十分なことが多い）を用意して、候補モデルに同じ入力を流し、幻覚した回数を人の目で数える。OpenRouter のように複数モデルを同じインターフェースで叩ける環境なら、この A/B は半日で組めます。日本語の RAG（検索拡張生成）で同じことを実際にやった記録は 日本語 RAG をローカル SLM に任せていいか に残しました。

幻覚を減らす一番確実な方法は、そもそも危ない呼び方をしないことでもあります。曖昧な質問を曖昧なまま投げない、根拠を出させる、検証できない出力はそのまま使わない。コストと同じで、設計で防げる幻覚は設計で防ぐのが安いです。この発想は LLM API のコストを「呼ばない」で防ぐ と地続きだと思っています。

来年また新しい巨大モデルが出て、Intelligence Index の最高値を更新するでしょう。そのとき私は、賢さの数字に拍手を送りつつ、幻覚率のグラフを別の引き出しから取り出して、自分のタスクで測り直すつもりです。

この記事は AI が下書きを書き、運営者である私が公開前に内容を確認・編集して公開しています。