何が起きたか
Google ResearchとTechnionの研究者らが、LLMの事実誤り（ハルシネーション）の多くは「知識が入っていない」のではなく「入っているのに取り出せない」想起の失敗だとする研究を発表しました。13のモデルを対象に400万件超の応答を分析し、Wikipediaから抽出した2,150件の事実からなるベンチマーク「WikiProfile」で検証しています。
結果は明快です。GPT-5やGemini-3のようなフロンティアモデルでは、事実の格納（エンコード）率は95〜98%と飽和に近づいている一方、その事実の26〜34%は、考える時間を与えない直接質問では答えられません。そして推論時に計算を追加すると、そのうち40〜65%が回復します。研究者はこれを人間の「喉まで出かかっている」状態になぞらえています。
なぜ重要か
これまで業界の標準的な対処は「モデルを大きくする」「学習データを増やす」「複雑な検索基盤を組む」の三択でした。研究チームはそのどれもが想起の失敗には効かないと指摘します。Google のResearch Scientistであるニタイ・カルデロン氏はVentureBeatに対し、事実が誤って出てきたときの定石はスケールだが、両方とも高価で、事実がすでにエンコードされているなら、どちらも効かないと述べています。
決定的なのがGemma3の実験です。10億から270億パラメータへスケールさせると、エンコード失敗は85%から23%へ大幅に減りました。ところが想起の失敗の割合はむしろ増え、思考なしの条件で最大40%に達しています。スケールが解決するのは「保管」であって「アクセス」ではない、という構図です。モデルが多くを覚えるほど、「エンコード済みだが到達できない」状態に閉じ込められる知識のプールが大きくなり、誤りの主因はデータ不足から想起失敗へと移っていきます。
評価の単位を「問題」から「事実」へ
研究チームが提案するのは、質問単位の正答率ではなく事実単位のプロファイリングです。ひとつの事実について、パラメータに格納されているか、異なる言い回しや逆方向の問いからも引き出せるか、取り出すのにどれだけの計算が必要か、を分けて測ります。ここで「encoded（学習時の文脈を与えれば再現できる）」と「known（多様な言い回し・方向で安定して答えられる）」を明確に区別する点が肝です。
論文はOasisがBoardwalkというクラブで初ライブを行ったという事実を例に、5つのプロファイルを整理しています。追加計算なしで答えられる直接想起、そもそも入っていない「空の棚」型のエンコード失敗、学習文の続きは書けるのに質問には答えられない「鍵の紛失」型の想起失敗、Chain-of-Thoughtなど推論時計算でようやく引き出せる型、そして格納していないのに他の事実（Oasisはマンチェスター出身、Boardwalkは90年代の有名クラブ、そこは新人バンドの初期ライブの場だった）を繋いで推論で当てる型です。この切り分けができれば、打ち手が事前学習側なのか事後学習・推論側なのかを取り違えずに済みます。
興味深いのは、レアな事実も人気の事実と同程度にエンコードされているのに、ロングテールと人気事実の想起ギャップはフロンティアモデルで25%を超えるという点です。逆方向の質問も同様で、「Oasisはどこで初ライブをしたか」には答えられても「Boardwalkで初ライブをしたのは誰か」には答えられない。それでも選択式にすると答えを知っていることが分かります。研究者は、想起は事実を学んだときの条件と強く結びついており、クエリが学習時のパターンから離れると劣化すると書いています。つまりこれらは記憶の欠落ではなく、想起の失敗として捉え直すべきだ、という主張です。
開発者への具体的な指針
論文と取材から導かれる実務的な指針は5点です。第一に、すべての事実誤りを検索の問題として扱わないこと。RAGは新しい情報や社内データには正しい打ち手ですが、ハルシネーション全般の万能薬として使うと、すでにパラメータ内にある事実のために余計なレイテンシとコストを払うことになります。第二に、推論時の思考は選択的に使うこと。実際に思考を要する事実は10〜20%程度で、全面的にオンにすれば計算予算を浪費します。ただし動的な振り分けは難しく、カルデロン氏は、計算をうまく使うには素の回答が失敗しそうだと事前に察知して答える前に引き上げる必要があり、その自己認識自体がひとつのスキルで、今のモデルは安定して得意ではないと語っています。Googleはモデル自身が確信度を測って深い推論を起動できるよう「faithful uncertainty」といった枠組みを開発中です。第三に、生成後に検証を挟むパイプライン。モデルは一から生成するより認識する方が得意だという性質を使います。第四に、ベンチマークの正答率ではなく意味的なアクセス可能性を、言い回し・文脈・方向を変えて測ること。第五に、クエリの言い換えや再試行、答える前に中間文脈や推論の連鎖を出させるといった工夫です。
注意点もあります。WikiProfileは百科事典的な事実に依存しているため、独自データや高度に専門的な業務ドメインにそのまま当てはまるとは限りません。カルデロン氏自身、Wikipedia上ではほぼ想起の問題だったが、ドメイン固有の事実は本当にエンコードされていない可能性があると述べています。ベンチマークはHugging Faceで公開され、構築に使ったプロンプトも含まれるため、自社コーパスでの再現が可能です。フロンティアモデルを完全にプロファイリングするコストは約500ドル、選択式を省くかサンプル数を減らせばさらに下げられます。
（出典：VentureBeat。記事はGoogleのコメントを追加して更新されたとされています）
💼 事業会社視点：これは自社にどう効くか
日本企業にとっての実利は「自社でモデルを作らなくても効く打ち手が残っている」点にあります。カルデロン氏は、ゼロからモデルを作らない企業にとってこれは良い知らせで、事前学習は高価で大半には手が届かないが、いま効くレバーはそうではない、事後学習は少ないデータと少ないステップで効き、思考・検証ステップ・検索といった推論時の道具はすでに多くのチームが使っていると述べています。
特に効くのは、社内FAQやマニュアルを片っ端からベクトルDBに突っ込んでRAG基盤を組んでいるSaaS・情報システム部門です。汎用知識で答えられる問いにまで検索を通していれば、レイテンシとAPI課金を二重に払っています。まずは自社の想定質問を「モデルが素で答えられるか／思考させれば答えられるか／本当に社内文書が要るか」の3層に分類し、RAGを通す範囲を絞るだけでコストは目に見えて下がります。約500ドルでプロファイリングできる手法が公開されている以上、これは検証可能な意思決定です。
EC事業者は逆方向の問いに注意すべきです。商品名から属性は引けても属性から商品名が引けないという非対称は、検索・レコメンド用途で直撃します。受託開発では、精度改善の見積もりを「モデル変更」「RAG増強」で出す前に、想起失敗かエンコード失敗かの切り分け工程を提案に組み込む方が、顧客に対して誠実で単価も正当化しやすくなります。役員が今問うべきは「精度は何%か」ではなく「その誤りは知識不足か、取り出し方の失敗か」です。
