Surprisal Theory is Tautological（withoutに見るコンテキスト設計）

description: LLMの出力確率と人間の処理負荷を結びつける「Surprisal理論」が同語反復に陥る構造的問題を解説。RAGやプロンプト設計への実装上の含意と、コンテキスト設計の判断基準を整理します。

meta description: Surprisal理論の同語反復問題を起点に、LLM開発・RAG・プロンプトエンジニアリングにおけるコンテキスト設計の実装論点を解説。2026年7月時点の議論をもとに整理します。

---

何が出たのか

2026年7月25日時点で、言語モデル研究のコミュニティ（Hacker News・arXivの関連スレッド）で注目を集めているのが、「Surprisal理論は根拠なしには同語反復に過ぎない」という主張です。

Surprisal理論（驚き度理論）とは、ある言語単位（単語・トークン）を文脈の中で処理するときの人間の認知的負荷が、言語モデルが与えるその単位の対数確率の逆数——すなわちSurprisal値——のアフィン関数（一次変換）として表せる、という仮説です。式で書くと以下のようになります。

```

ProcessingDifficulty(w | context) = a × -log P(w | context) + b

```

この理論は心理言語学の分野で長く使われてきましたが、今回の議論が指摘するのは「どの言語モデルを使うか」を外部から制約しない限り、この式は何も予測していないに等しい、という点です。モデルを選ぶ自由度がある限り、任意の処理難易度データに対して事後的に「フィットするモデル」を見つけることができてしまいます。

LLM開発の文脈でこれが重要なのは、Surprisal値がプロンプト設計やRAG（Retrieval-Augmented Generation：検索結果を文脈として与えて生成する手法）のコンテキスト評価指標として流用されているケースが増えているためです。理論的な土台が同語反復であれば、その指標を信頼してシステムを設計することにはリスクが伴います。

---

技術的に面白い点

この議論の核心は、「評価指標の選択とモデルの選択が循環している」という構造的な問題です。

通常の科学的仮説であれば、モデルは独立に決定されており、そのモデルで計算したSurprisal値が人間の反応時間や読み誤り率と相関するかどうかを検証します。しかし実際には、どのモデル（n-gram、LSTM、GPT系など）を使うかによってSurprisal値は大きく変わります。

問題の構造を整理すると次のようになります。

• 循環性モデルMを選んでSurprisal値を計算し、それが人間データと合えば「Mが正しいモデルだ」と言う。しかし「正しいモデル」の基準がSurprisal値との一致そのものであれば、何も言っていないのと同じです。
• 自由度の問題GPT-4、Llama 3、Mistralなど、現在利用可能なLLMは多数あります。それぞれが異なるSurprisal分布を持つため、後からデータに合うモデルを選ぶことが容易です。
• アフィン変換の自由度係数aと切片bも自由パラメータです。モデルの選択と合わせると、フィッティングの自由度は実質的に非常に大きくなります。

LLMエンジニアリングの観点で面白いのは、この問題がプロンプトのコンテキスト設計にそのまま転写されることです。「このコンテキストはモデルにとって処理しやすいか」をSurprisal値で評価しようとする場合、どのモデルのSurprisal値を使うかによって結論が変わります。評価指標自体がモデル依存であるため、モデルを固定しない限り比較に意味がありません。

---

既存の流れとの違い

従来のプロンプト評価・コンテキスト評価のアプローチと、今回の議論が示す方向性を比較します。

従来の主流アプローチは、LLMのperplexity（パープレキシティ：モデルがどれだけ「驚く」かの平均的な指標）をコンテキストの品質指標として使うものです。RAGシステムでは、検索して取得したチャンクをコンテキストに入れたときのperplexityが下がれば「良いチャンクが取れた」と判断するロジックが実装されることがあります。

しかしこのアプローチは、Surprisal理論と同じ循環性を持っています。perplexityはモデル固有の値であり、モデルが変われば値も変わります。あるRAGシステムでGPT-4oのperplexityを最小化するよう最適化したコンテキストが、Claude 3.5 Sonnetでも同様に機能するとは限りません。

今回の議論が示す方向性は、「モデルに依存しない外部基準」を設けることです。具体的には以下のような制約が提案されています。

• 認知的合理性の制約人間の処理難易度を説明するモデルは、人間の認知アーキテクチャに関する独立した仮説（作業記憶の制限など）と整合していなければならない。
• 予測的妥当性の要件新しいデータに対して事前に予測を立て、それを検証する手順が必要。事後的なフィッティングは証拠にならない。
• モデル選択の事前固定評価に使うモデルを実験設計の段階で固定し、データを見てから変更しない。

これはLLM開発における評価設計全般に通じる原則です。ベンチマークを設計するときに「テストデータを見てからモデルを選ぶ」ことが汚染（contamination）と呼ばれるのと、構造的に同じ問題です。

---

実装・運用で気になる点

この議論をLLMアプリケーション開発・運用の文脈に落とし込むと、いくつかの実装上の判断ポイントが浮かび上がります。

コンテキスト評価指標の設計

RAGシステムでコンテキストの品質を自動評価する場合、perplexityやSurprisal値を使うなら、評価モデルを本番モデルと同一にするか、明示的に分離して管理する必要があります。評価モデルと本番モデルが異なる場合、評価スコアと実際の出力品質が乖離するリスクがあります。

実装上の対策として、以下が考えられます。

• 評価モデルの固定とバージョン管理評価に使うモデルのバージョンをコードベースに明記し、本番モデルのアップデートと評価モデルのアップデートを独立して管理する。
• モデル非依存の評価指標の併用BERTScore、ROUGE、あるいはタスク固有のルールベース評価など、特定のLLMに依存しない指標を組み合わせる。
• ログとフォールバックの設計コンテキスト評価スコアが閾値を下回った場合のフォールバック（別の検索戦略への切り替えや、ユーザーへの確認要求）をログとセットで実装する。

プロンプトエンジニアリングへの含意

「モデルが処理しやすいプロンプト」を設計しようとするとき、Surprisal値を直接最小化しようとするアプローチは、上記の循環性の問題を持ちます。代わりに有効なのは、以下のような実証的なアプローチです。

• A/Bテストによる実測プロンプトのバリアントを複数用意し、タスク固有の評価指標（正解率、F1スコア、ユーザー評価など）で比較する。
• モデルをまたいだ一貫性の確認複数のモデルで同じプロンプトを試し、一貫して良い結果が出るプロンプトを採用する。特定モデルのSurprisal値に最適化されたプロンプトは、モデル更新時に劣化するリスクがあります。

推論コストとのトレードオフ

Surprisal値の計算には、対象モデルでの推論が必要です。大規模なRAGシステムでコンテキスト評価を毎回行う場合、推論コストとレイテンシへの影響を事前に見積もる必要があります。評価専用の軽量モデルを使う場合は、前述の「評価モデルと本番モデルの乖離」問題が発生します。この二律背反を認識した上でシステム設計を行うことが重要です。

セキュリティ・権限の観点

評価パイプラインが外部APIを呼び出す構成の場合、評価用のAPIキーと本番用のAPIキーを分離し、評価パイプラインからは本番データへの書き込み権限を持たせないことが基本です。コンテキスト評価のログには入力テキストが含まれる場合があるため、個人情報・機密情報の取り扱いポリシーと整合させる必要があります。

---

Spectralの見解

1. 技術的な読み

今回の議論が示すのは、「LLMの内部確率を評価指標として使うこと」の限界です。perplexityやSurprisal値は、特定のモデルの特性を反映しているに過ぎず、それ自体が「良いコンテキスト」や「良いプロンプト」の普遍的な基準にはなりません。これはLLM評価全般に通じる問題であり、ベンチマーク設計・RAGのリトリーバル評価・プロンプト最適化のいずれにも関係します。

実装上の結論として、「モデル固有の確率指標」と「タスク固有の外部評価指標」を明確に分けて管理する設計が求められます。前者はモデルのデバッグや挙動分析に使い、後者をシステムの品質基準として採用する、という役割分担が現実的です。

2. PoCで確認すべき点

• 評価指標とモデルの依存関係の可視化使用しているSurprisal値やperplexityが、どのモデルのどのバージョンに依存しているかをPoCの段階でドキュメント化する。モデルを変えたときに評価スコアがどう変わるかを実測する。
• タスク固有指標との相関確認Surprisal値やperplexityが、実際のタスク成功率や人間評価と相関しているかをPoCで検証する。相関が弱い場合、その指標をシステムの自動評価に使うことは避ける。
• フォールバック動作の検証コンテキスト評価が機能しない場合（APIエラー、タイムアウト）のフォールバック動作を明示的にテストする。

3. 業務・プロダクト実装に移す時のリスク

最大のリスクは、「モデルに最適化された評価指標」でシステムを構築した後に、モデルのバージョンアップや乗り換えが発生した場合です。評価スコアが変動し、既存のしきい値設定が無効になる可能性があります。これは運用コストの増大と品質の不安定化につながります。

対策として、評価指標の選択理由と依存モデルをADR（Architecture Decision Record：設計判断の記録）として残し、モデル更新時の再評価手順をCI/CDパイプラインに組み込むことを推奨します。また、意思決定者の視点では、「どのモデルを使っているか」がシステムの評価品質に直結するため、モデルのガバナンス（利用モデルの承認・変更管理）をプロセスとして整備することが、長期的な運用安定性に寄与します。

---

まとめ

Surprisal理論の同語反復問題は、LLM開発における評価設計の根本的な問いを改めて浮き彫りにしています。モデルが計算する確率値は、そのモデルの特性を反映したものであり、人間の処理難易度やタスク品質の普遍的な指標ではありません。

RAGシステムやプロンプト最適化においてこの問題が実装上の影響を持つのは、「評価指標の選択」と「モデルの選択」が循環してしまうリスクがあるためです。この循環を断ち切るには、評価モデルの事前固定、タスク固有の外部評価指標の採用、そしてモデル非依存の評価手法との組み合わせが有効です。

2026年7月25日時点でこの議論が注目されている背景には、LLMの選択肢が増え、モデル乗り換えや複数モデル併用が現実的な選択肢になってきたことがあります。評価設計の堅牢性は、今後のLLMアプリケーション開発においてより重要な論点になっていくと考えられます。

関連論点として The Many Senses of Visual Similarity A: LLMアプリ実装で見る設計論点 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。