ハルシネーションはなぜ起きる — 仕組みと現実的な対策

LLMが平然と嘘をつくのはバグではなく、次トークン予測という学習目的の素直な帰結。損失関数に真偽の項がないこと、圧縮された知識が端から崩れること、サンプリングが裾を引くこと、採点方法が当てずっぽうに報酬を与えることを1から分解し、RAG・引用照合・不確実性推定という現場で実際に効く順に対策を並べる。

Survey of Hallucination in Natural Language Generation

白紙で提出できない試験

穴埋め試験を受けているところを想像してください。ただしルールが一つだけ変わっていて、空欄のまま提出することは許されません。分からない問題も、それらしい答えで埋めなければ次に進めない。あなたは知識の断片と語感を頼りに、「たぶんこういう名前だった気がする」という答えを書き込むはずです。

大規模言語モデルが置かれているのは、まさにこの状況です。ハルシネーション（hallucination、幻覚）とは、モデルが事実でないことを、事実であるかのような自然な文章で出力する現象を指します。厄介なのは、嘘の部分だけ文章が崩れてくれないことです。実在しない論文のタイトルも、存在しないAPIのメソッド名も、正解とまったく同じ流暢さで出てきます。読み手に見分ける手がかりが残らない。

そしてこれはバグではありません。次の単語を予測するという学習の仕方から素直に導かれる帰結です。以下では仕組みを4つの層に分けて分解し、そのうえで現場で実際に効く対策と、効くと思われがちだが効かない対策を切り分けます。

まず2種類を分ける

対策を考える前に、混ぜてはいけない2つを分けておきます。

• 事実性（factuality）のハルシネーション: 世界の事実と食い違う。「エッフェル塔はロンドンにあります」
• 忠実性（faithfulness）のハルシネーション: 与えた入力と食い違う。要約に原文にない数字が混ざる、翻訳で原文にない一文が生える

この2つは検出の仕方がまったく違います。前者は外部の知識源と照合しなければ判定できませんが、後者は入力テキストとだけ照合すれば済みます。要約・翻訳・議事録生成のような業務で起きる事故はほとんど後者なのに、事実チェックのつもりで外部検索を足しても一切捕まりません。自分がいまどちらを相手にしているのかを、設計の最初に決めてください。

直感: 学習目的に「真偽」の欄がない

言語モデルの事前学習でやっていることは、突き詰めると1つです。膨大なテキストを流し込み、各位置で次のトークンの確率を当てさせ、外したぶんだけ罰する。

$x_t$ は $t$ 番目のトークン（単語の断片）、$x_{<t}$ はそれより前に出た全トークン、$p_\theta$ はパラメータ $\theta$ を持つモデルが付ける確率です。式が言っているのは「実際に来たトークンに高い確率を割り当てていれば損失は小さい、低い確率しか割り当てていなければ大きく罰する」だけです。この損失がどこから来たのかはエントロピーと交差エントロピーで扱っています。

注目してほしいのは、この式のどこにも「その文が真か」を測る項がないことです。モデルが最大化しているのは真実性ではなく、もっともらしさです。学習データの中で「〜という論文で示されている」という言い回しの後には、たいてい実在の論文タイトルが続いていました。モデルが学ぶのは「その位置には論文タイトルの形をした文字列が来る」というパターンであって、「実在する論文だけを書け」という制約ではありません。

だから危ない場所はいつも同じです。固有名詞・数字・日付・URL・引用・型番。どれも「形」は極めて規則的なのに、中身は一つひとつ個別に覚えるしかない低頻度の情報です。形だけが学習され中身が学習されていないとき、モデルは形のほうを埋めます。

層1: 圧縮された知識は、端から崩れる

もう一つの見方は圧縮です。モデルのパラメータ数は有限で、そこに学習データを非可逆に押し込んでいます。頻繁に登場する事実は太い経路として残り、1回しか出てこない事実は近いパターンに吸収されて消えます。

これは「よく似た嘘」が生まれる理由を説明します。実在する著者名と実在する論文タイトルが、実在しない組み合わせで出てくる。日付が1年だけずれる。関数名が別ライブラリのものと混ざる。完全なでたらめよりも近傍からの取り違えが圧倒的に多いのは、これが圧縮の副作用だからです。検証する側から見ると、この性質はかなり意地悪です。もっともらしさの検査では通ってしまい、実際に照合しないと分かりません。

層2: サンプリングが分布の裾を引く

学習が終わっても、生成のたびにもう一段リスクが乗ります。モデルが出力するのは1つの答えではなく語彙全体の確率分布で、そこからサンプリングして1トークンを選ぶからです。温度 $T$ を上げると分布は平らになり、低確率の候補が選ばれやすくなります。

大事なのは、この抽選が1トークンごとに独立に引かれることです。1トークンあたりの事故率が0.5%でも、300トークンの回答なら「どこかで1回は起きる」ほうが普通になります。長い回答ほど誤りを含みやすいのは、モデルが長文で息切れするからではなく、単に試行回数が多いからです。

そして重要な注意点。温度を0にしてもハルシネーションは消えません。毎回いちばん確率の高いトークンを選ぶようになるだけなので、モデルが実在しない論文タイトルに最大確率を割り当てていれば、それがそのまま確定的に出続けます。温度0が消すのはばらつきであって、誤りではない。「temperature=0 だから安全」という前提で組まれた実装は、この取り違えの上に立っています。

層3: 採点方法が当てずっぽうに報酬を与える

3つ目の層は、学習でも生成でもなく評価の側にあります。

多くのベンチマークは、正解に1点、不正解に0点、そして無回答にも0点を与えます。この採点表のもとで、答えが分からないときに期待値を最大化する戦略は明白です — 推測する。棄権の点数が不正解と同じなら、当たる可能性があるぶんだけ推測が得です。減点なしのマークシート試験で、分からない問題も全部塗るのと同じ理屈です。

人間の好みに合わせる事後学習でも同じ圧力がかかります。自信を持って言い切った回答と「分かりません」を並べて評価者に選ばせれば、前者が選ばれやすい。こうして学習の全工程を通じて、推測できるモデルのほうが良いスコアを取る環境が出来上がります。モデルは「知らないと言わない」ように育てられているわけです。ベンチマークをどう疑いながら読むかはLLM評価を1からで扱っています。

裏返すと、これは対策の方向も示しています。棄権を不正解と同点にしない採点、つまり「分かりません」に部分点を与える評価軸を自分たちのタスクで作れば、モデル選定と後段のチューニングの向きが変わります。

モデルは自分の不確かさを部分的に知っている

救いもあります。モデルの内部には、正しく答えられそうかどうかの情報が部分的に残っています。同じ質問を温度を上げて何度も生成させると、本当に知っていることについては答えが揃い、知らないことについては毎回違う名前が出てきます。このばらつきを検出器として使うのが自己整合性チェック（SelfCheckGPTの系統）の発想です。

実装は驚くほど素朴です。

def flag_hallucination(ask, question, n=5, thresh=0.6):
    answers = [ask(question, temperature=1.0) for _ in range(n)]
    base = answers[0]
    # baseの主張が他のサンプルからも支持されるか（NLIモデルで含意判定）
    agree = sum(entails(a, base) for a in answers[1:]) / (n - 1)
    return agree < thresh, base, agree

コストは素直にn倍になりますが、外部の知識ベースが一切要らないのが強みです。金額・投薬量・法令番号のように誤りが高くつく箇所にだけ掛ける、という使い方が現実的です。

対策1: 思い出させるのをやめて、読ませる

いちばん効果が大きいのは、記憶からの再構成をやめさせることです。検索で関連文書を引き、プロンプトに入れてから答えさせる。これが検索拡張生成（RAG）で、思い出す問題を読解の問題に置き換えます。読解なら、答えの根拠がその場にあるので照合できます。

ただしRAGは魔法ではなく、設計を誤ると事態を悪化させます。

• 検索が外すと、誤りが強化される。無関係な文書を渡されたモデルは、それを根拠に読める形へ加工してしまう。ハルシネーションが「出典付き」になるぶん、素のモデルより見抜きにくい
• 文脈に入れても使われないことがある。長い文脈の中ほどに置かれた情報は端に置かれたものより無視されやすい傾向が報告されています
• 文書同士が矛盾していると、どちらかを黙って選んで断定する。矛盾を報告してはくれません

組み方の詳細はRAGの基礎と設計パターンにあります。

対策2: 引用を強制し、機械で照合する

実務で最も費用対効果が高いのはここです。

1. 回答には必ず、渡した文書のIDと引用スパンを伴わせる
2. 生成後に、その引用文字列が本当にその文書に存在するかを単純な文字列一致で確認する
3. 一致しない文には印を付けるか、落とす

肝は手順3がモデルを使わないことです。文字列照合は決定的で、速く、それ自体は幻覚しません。逆に最悪なのは「URLを出させる」だけの実装です。モデルは実在しないURLを平然と組み立てますし、ドメインもパスも本物らしく見えます。出力してよいのはこちらが渡した文書のIDだけに限ってください。

対策3: 出力の自由度を下げる

散文は最も幻覚が起きやすい形式です。可能なら答えの形を先に固定します。JSONスキーマ、選択肢の列挙、「該当なし」を含む固定ラベル。選択肢にない答えは、構造上そもそも出せません。

同じ理由で、1回のプロンプトに複数の質問を詰め込まないほうがいい。分解して1問ずつ根拠を要求するほうが、検証の粒度が上がります。

現場ではこう使う

誰が、いつ 社内文書検索やサポート応答のバックエンドを組むアプリケーションエンジニアが、LLMの出力をそのままユーザーに見せる直前に必ず通る関門です。医療・法務・金融のように誤りが実害になる領域では、これがリリース判定の主要基準そのものになります。

触るパラメータとツール名 生成側は temperature と top_p、それに logprobs（トークンごとの対数確率）。低い確率で通過した固有名詞は要注意箇所として拾えます。検索側は top_k、チャンクサイズと重なり幅、リランカ。評価側はFActScore（長文を原子命題に割って1つずつ検証する）、TruthfulQA（人間が引っかかる俗説をどれだけ再生産するか）、そして含意判定用のNLIモデル。多くのAPIには決定性を上げる seed がありますが、これは再現性のための道具であって、正しさの道具ではありません。

知らないと事故になる落とし穴

• temperature=0 を「安全モード」と呼ばない。出力が固定されるだけで、誤りは固定されたまま出続けます
• RAGを入れた直後に評価をやめない。検索精度の低いRAGは、素のモデルより自信のある誤答を出します
• 忠実性の事故を事実チェックで測らない。要約が原文から離れたかどうかは、外部知識ではなく原文との照合でしか分かりません
• 事実性の採点をLLM-as-a-judgeだけに任せない。判定側も同じ分布から同じ思い違いを引きます
• 「参考文献を付けて」という指示をハルシネーション対策と数えない。根拠を渡していなければ、参考文献ごと生成されます
• 出力長を無制限にしない。同じモデルでも、長い回答は含まれる主張の数だけ誤りの機会が増えます

面接や設計レビューで問われる形 「temperature を 0 にすればハルシネーションは止まりますか」— 止まりません、と答えたうえで、サンプリング由来のばらつきと事前学習由来の誤りが別の層の問題だと切り分けられれば十分です。「RAGを入れれば解決しますか」— 検索が当たっている限りは、と答え、外したときにどう振る舞わせるか（棄権させるのか、確信度を返すのか）まで設計に入っているかが本当の論点になります。

まとめ

• ハルシネーションはバグではなく、次トークン予測という学習目的の帰結。損失関数に真偽の項がない
• 危ないのは常に固有名詞・数字・日付・引用。形は規則的で中身は低頻度、という条件が揃う場所
• 温度を下げても消えない。消えるのはばらつきだけ
• 効く順は、根拠を外から渡す（RAG）→ 引用を機械で照合する → 出力の形を縛る → 不確かさを測って棄権させる
• 「分かりません」に点を与える採点を自分のタスクで作ると、モデル選定と改善の向きが変わる