← 機械学習テキスト 一覧

🎓 レベル：標準　|　重要度：B（標準）

📎 前提：アラインメント　|　関連：評価指標（分類）とROC・AUC（評価の土台）

要点（BLUF）

• LLMは「正解が一意でない」ため評価が難しく、ベンチマークのデータ汚染とLLM-as-a-judge のバイアスが数字を歪めます。
• ハルシネーション（もっともらしい誤り・捏造）は、尤度最大化が真実性を保証しないことに由来する構造的な問題で、完全には消せません。
• 安全性（jailbreak・プロンプトインジェクション）は、学習時のアラインメントと推論時のガードレールの両輪で守りますが、攻防は続きます。

1. なぜ評価が難しいのか

分類や回帰なら、正解ラベルと突き合わせて精度や ROC-AUC を出せば済みました。LLMの生成タスクはそうはいきません。理由は単純で、「良い出力」が一意に定まらないからです。

• 翻訳・要約・対話の「正解」は無数にある。表現が違っても等価な答えが大量に存在します。
• 知識・推論を問う問題でも、過程が正しいか／たまたま当たったかを表面の正誤だけでは区別できません。

そこで実務では、次の3種類の評価を組み合わせます。

データ汚染（contamination）

テストの問題と答えが、事前学習データに混入してしまう現象です。Web全体を学習に使う以上（事前学習とスケーリング則）、有名ベンチマークがコーパスに紛れ込む確率は高くなります。

汚染が起きると、モデルは推論しているのではなく暗記を再生しているだけかもしれません。それでもスコアは上がるので、「賢くなった」ように見えてしまう。これがベンチマーク高得点＝賢い、とは言えない最大の理由です。

対策の方向は「汚染しにくいテストにする」こと。代表例が、最近の論文・コンペ・ニュースなど学習時点より後の新しい問題で継続的に更新する動的ベンチマークです（要最新確認：具体的なベンチマーク名・設計は流動的）。

LLM-as-a-judge のバイアス

人間評価の代替として、LLMに採点させる手法が広く使われます。速くて開放型の質問も扱えますが、判定者LLM自身の癖が混入します。代表的なものは次のとおりです。

• 自己優遇バイアス：自分（同系統のモデル）が書いた出力を高く評価する。GPT系がGPT系の出力を、Claude系がClaudeの出力を好む傾向が報告されています。評価者と生成者が近いと、循環的に自分を正当化してしまいます。
• 冗長性バイアス：長い回答ほど高く採点しがち。「丁寧さ」を「正しさ」と取り違える。
• 選好リーク（preference leakage）：採点データを作ったモデルと採点するモデルが関連していると、評価が汚染される。

要するに、LLM-as-a-judge は安いフィルタリングや初期スクリーニングには有用だが、高リスクな最終判定では人間の検証を置き換えられない、というのが現状の理解です。

flowchart TD
    OUT["モデルの出力"] --> Q{"評価の方法"}
    Q -->|"自動・客観"| B["ベンチマーク採点<br/>（正解と照合）"]
    Q -->|"人が判断"| H["人間評価<br/>（A/B比較・採点）"]
    Q -->|"LLMに採点させる"| J["LLM-as-a-judge"]
    B --> RB["落とし穴：データ汚染<br/>（暗記の再生・飽和）"]
    H --> RH["落とし穴：高コスト・主観"]
    J --> RJ["落とし穴：自己優遇・冗長性<br/>選好リーク"]
    RB --> SUM["どの方法も単独では不十分<br/>→ 複数を組み合わせる"]
    RH --> SUM
    RJ --> SUM

2. ハルシネーション：もっともらしい誤り

ハルシネーションとは、出力が流暢でもっともらしいのに、事実として誤っている／根拠なく捏造されている現象です。よく2種類に分けます。

• 内在的（intrinsic）：与えた入力・文脈と矛盾する出力（例：渡した文書に書いていないことを「文書によると」と言う）。
• 外在的（extrinsic）：入力からは検証できない捏造（例：実在しない論文・URL・人名をそれらしく作る）。

なぜ起きるのか（廃れにくい原理）

ハルシネーションは「バグ」ではなく、今の学習のやり方から自然に出てくるものです。原理は3層に整理できます。

1. 目的関数が真実性を罰しない。事前学習は次トークンの**尤度最大化（クロスエントロピー最小化）**です（事前学習とスケーリング則）。これは「もっともらしい続き」を作る訓練であって、「真実だけを言う」訓練ではありません。確率的に尤もらしければ、事実でなくても生成されます。

2. 知識の欠落を埋めようとする。世界の知識を有限のパラメータに圧縮する以上、抜けは必ず残ります。問われると、モデルは空白を統計的にありそうな値で補完してしまう。これが捏造の温床です。

3. 評価インセンティブが「当てずっぽう」を促す。多くのベンチマークは0/1の二値採点で、「分かりません（IDK）」を不正解と同じ0点にします。すると、

   $\mathbb{E}[\text{スコア}] = P(\text{正解}) \times 1 + P(\text{不正解}) \times 0$

   となり、少しでも当たる見込みがあるなら、棄権するより推測した方が期待スコアが高い。つまり評価のルール自体が「自信満々に答える＝当てずっぽう」を学習段階・後学習段階の両方で報酬として強化してしまうのです（2025年のOpenAIらの議論。要最新確認）。

   裏を返せば対策の方向も見えます。自信のある誤りを、棄権より重く罰する採点（例：正解 +1、誤り −2、棄権 0、「75%以上確信があるときだけ答えよ」）にすれば、モデルは適切に棄権・不確実性の表明を学べます。これは 分類の校正（キャリブレーション） の発想を生成に持ち込んだものです。

⚠️ ハルシネーションは理論的に完全には消せないという主張（“Hallucination is Inevitable”）があります。有限パラメータ・尤度目的・未知への外挿という構造上、ゼロにはできない。だから目標は「根絶」ではなく「減らして・検出して・正直に表明させる」ことです。

flowchart LR
    subgraph 原因
        C1["尤度最大化は<br/>真実性を罰しない"]
        C2["知識の欠落を<br/>統計的に補完"]
        C3["二値採点が<br/>当てずっぽうを報酬化"]
    end
    subgraph 対策
        M1["RAG：外部知識で根拠付け"]
        M2["引用・出典の提示"]
        M3["不確実性の表明・棄権"]
        M4["生成後の検証<br/>（自己検証・別モデル照合）"]
        M5["採点を校正<br/>（自信ある誤りを重く罰）"]
    end
    C2 --> M1
    C1 --> M2
    C3 --> M5
    C1 --> M3
    C1 --> M4

対策

• RAG（検索拡張生成）：質問に関連する文書を検索して文脈に入れ、それを根拠に答えさせる。知識の欠落（原因2）を外部知識で埋めるアプローチで、外在的ハルシネーションに特に効きます。詳細は 検索拡張生成。
• 引用・出典の提示：答えに根拠の出所を添えさせ、人が検証できるようにする。
• 不確実性の表明・棄権：分からないときは「分からない」と言わせる。上の採点の校正と組み合わせると効果的です。
• 生成後の検証：出力を別経路（自己再検証・別モデル・ツール・複数エージェントの合議）で照合し、矛盾を弾く。

ただし RAG も万能ではありません。検索が外せば誤った文脈で自信満々に答える（内在的ハルシネーションがむしろ悪化する）ので、検索の質が前提になります。

3. 安全性：有害出力と攻撃

評価・事実性とは別軸で、「悪用・有害出力をどう防ぐか」という安全性の問題があります。アラインメント（アラインメント）で「無害であれ」を学習させても、それをかいくぐる攻撃が存在します。

代表的な脅威

• 脱獄（jailbreak）：プロンプトの工夫で、安全装置を上書きさせ、本来拒否すべき有害な応答を引き出す攻撃。「ロールプレイのふりをさせる」「禁止指示を段階的に分割する」など手口は多数あります（要最新確認：手法は日々更新される）。
• プロンプトインジェクション：外部から流れ込むデータ（Webページ・メール・ツールの出力など）に攻撃者が指示を紛れ込ませ、モデルを乗っ取る攻撃。RAGやエージェントのように外部入力を読む構成で特に危険です。jailbreak が「ユーザーが直接だます」のに対し、injection は「信頼して読んだデータの中に命令が埋まっている」点が本質的に厄介です。

💡 jailbreak とインジェクションの違い：jailbreak は会話相手（ユーザー）が安全装置を破ろうとする。プロンプトインジェクションは第三者が用意したデータ経由で、ユーザーもモデルも気づかないうちに命令が注入される。後者は「データと命令の境界が曖昧」というLLMの根本構造に起因します。

守り方

防御は「いつ守るか」で2層に分かれます。

• ガードレール：デプロイ済みモデルの入力と出力を監視し、有害・攻撃的な内容を検出・遮断する外付けの仕組み（例：プロンプトインジェクション検出器、出力の有害性フィルタ）。アラインメントが「モデル本体のしつけ」なら、ガードレールは「門番」です。
• レッドチーミング（red teaming）：デプロイ前に、自ら攻撃者になってモデルを攻めることで弱点を洗い出すプロセス。ガードレールが「運用後に守る」のに対し、レッドチーミングは「事前に壊して直す」役割を担います。
• 業界では OWASP の GenAI 向けリスク一覧などが、脅威の共通言語として参照されます（要最新確認）。

flowchart LR
    A["攻撃<br/>jailbreak・<br/>プロンプトインジェクション"] --> G1["入力ガードレール<br/>（攻撃を検出・遮断）"]
    G1 --> LLM["アラインメント済み<br/>LLM<br/>（拒否を学習済み）"]
    LLM --> G2["出力ガードレール<br/>（有害出力をフィルタ）"]
    G2 --> SAFE["利用者へ"]
    RT["レッドチーミング<br/>（事前に攻めて弱点発見）"] -.->|改善| LLM
    RT -.->|改善| G1
    RT -.->|改善| G2

4. アラインメントとの関係：両輪で守る

安全性は、**学習時の対策（アラインメント）と推論時の対策（ガードレール）**の両輪で成り立ちます。

• アラインメント（アラインメント）はモデルの内側を変える。RLHF や DPO で「有害要求は拒否する」価値観そのものを学習させます。土台が良ければ、そもそも危険な出力が出にくくなります。
• ガードレールはモデルの外側を固める。学習で漏れた攻撃や、運用中に現れる新手の jailbreak を、入出力の検査で食い止めます。

どちらか一方では不十分です。アラインメントは完璧にできない（必ず破られる例が見つかる）し、ガードレールも誤検出・突破がある。**多層防御（defense in depth）**として重ねるのが基本方針で、その穴をレッドチーミングで継続的に探します。

⚠️ よくある誤解・要最新確認

• 「ベンチマークで高得点＝賢い」ではない。データ汚染で暗記を再生しているだけかもしれず、飽和したベンチでは差も見えません。複数の評価軸（できれば汚染しにくい動的なもの＋人間評価）で見るべきです。
• 「ハルシネーションはいずれ完全に消える」とは限らない。尤度目的・有限パラメータ・未知への外挿という構造に由来するため、根絶ではなく低減・検出・正直な表明が現実的な目標です。RAGも検索が外せば誤ります。
• 「安全対策をすれば安全」ではない。jailbreak とプロンプトインジェクションは攻防が続く領域で、ガードレール自体が突破された事例もあります。最新の攻撃・防御手法は流動的なので要最新確認です。
• LLM-as-a-judge は人間評価の完全な代替ではない。安いスクリーニングには使えますが、自己優遇・冗長性などのバイアスがあり、高リスクな判定では人間の検証が要ります。

まとめ

LLMの信頼性は、**測る（評価）・正す（ハルシネーション対策）・守る（安全性）**の3点で考えます。評価は正解が一意でない難しさと汚染・judgeバイアスを抱え、ハルシネーションは尤度最大化と評価インセンティブに根ざす構造的問題で、安全性は学習時アラインメントと推論時ガードレールの両輪＋レッドチーミングで支えます。いずれも「完成」はなく、継続的に測り直し・攻め直すことが運用の前提になります。

関連ノート

• 大規模言語モデル 目次
• アラインメント
• 検索拡張生成
• 事前学習とスケーリング則
• 評価指標（分類）とROC・AUC
• 機械学習テキスト 全体目次