生成AIの条件付き確率モデル基礎

種別：基礎理論 / 簡略モデル / 設計原則適用対象：生成AI、RAG、QAチャット、コード生成、AIエージェント対象工程：モデル理解 / Context設計 / 生成条件 / 評価

目的

生成AIの出力が、入力、Context、指示、モデル、生成条件によってなぜ変化するのかを、確率的な見方から整理します。

このページの目的は、AIの内部動作を完全に説明することではありません。

確率モデルとしての性質を、プロンプト、Knowledge、RAG、ガードレール、評価などの実務設計へ接続することです。

結論

生成AIは、一つの入力から一つの正解を検索する装置ではありません。

与えられた条件の下で、次のトークンに対する確率分布を計算し、選択したトークンを次の入力へ加えながら文章を生成します。

したがって、実務上のAI設計では、

望ましい出力の確率を高める
望ましくない出力の確率を下げる
確率的な制御だけでは防げない出力を、外部システムで止める
出力を評価し、必要なら人間へ戻す

という複数の制御を組み合わせる必要があります。

プロンプトやRAGは、正しさを保証する仕組みではない。
AIが出力を生成するときの条件を変える仕組みである。

言語モデルは系列の確率を扱う

出力するトークン列を

Y=(y_1,y_2,\ldots,y_T)

Contextを含む入力条件を $C$ とすると、自己回帰型言語モデルは、系列全体の確率を次のように分解して扱えます。

P(Y\mid C) = \prod_{t=1}^{T} P(y_t\mid y_1,\ldots,y_{t-1},C)

各時点では、それまでに生成したトークンとContextを条件に、次のトークンの分布を計算します。

入力・Context
    ↓
次トークンの確率分布
    ↓
トークンを選択
    ↓
選択結果をContextへ追加
    ↓
次の確率分布を計算

この処理を繰り返すことで、一つの回答が生成されます。

ただし、トークン列の確率と、回答内容の正しさは同じではありません。

文章として自然に続きやすいことは、その内容が事実であることを保証しません。

設計上の説明として使う「確率空間」

数学における確率空間は、一般に次の三つ組で表されます。

(\Omega,\mathcal{F},P)

記号	意味
$\Omega$	起こり得る結果の集合
$\mathcal{F}$	確率を扱う事象の集合
$P$	各事象へ確率を割り当てる確率測度

言語生成へ単純化して対応させるなら、 $\Omega$ は生成可能なトークン列、 $P$ は条件に応じて各トークン列へ与えられる確率と考えられます。

ただし、実際の言語モデルは、完成した回答を最初から一覧化して選んでいるわけではありません。各生成時点で次トークンの条件付き分布を計算しています。

そのため、このサイトで「確率空間を狭める」「方向付ける」と表現する場合、それは厳密な内部実装の説明ではなく、

条件を変えることで、生成されやすい出力と生成されにくい出力の分布を変える

という設計上の説明モデルを意味します。

出力分布を決める条件

AIシステム全体の出力を、次のように簡略化します。

P(Y\mid X,C,I,M,D)

記号	意味
$X$	利用者の質問や依頼
$C$	会話履歴、仕様、検索結果などのContext
$I$	役割、制約、出力形式などの指示
$M$	モデルとそのパラメータ
$D$	Temperature、top-pなどの生成条件
$Y$	生成される出力

この式は、実装を完全に表すものではありません。

実務上、同じモデルでも条件によって結果が変わることを整理するための簡略モデルです。

例えば、モデル $M$ を変更しなくても、

関連仕様をContextへ追加する
出典の提示を指示する
回答可能な範囲を限定する
不明時の停止条件を与える
Temperatureを変更する

ことで、出力分布は変化します。

Temperatureは分布の形を変える

モデルが次トークン候補ごとに出力する値をロジット $z_i$ とします。

Temperature $T>0$ を用いた単純なsoftmaxは、次のように表せます。

P(y_t=i) = \frac{\exp(z_i/T)} {\sum_j \exp(z_j/T)}

$T$ が低い：高いロジットを持つ候補へ確率が集中しやすい
$T$ が高い：候補間の確率差が小さくなりやすい

Temperatureは、事実の正しさを直接制御する値ではありません。

低くすれば常に正確になるわけでも、高くすれば必ず創造的になるわけでもありません。モデル、入力、デコーディング方法、タスクによって効果は変わります。

また、実際の生成ではtop-pなど、他の方式と組み合わせられる場合があります。

プロンプトは条件付けである

プロンプトへ役割、目的、制約、例を追加すると、それらもContextの一部としてモデルへ与えられます。

例えば、

根拠として提示された資料だけを使用し、
資料から確認できない場合は「確認できない」と回答する。

という指示は、根拠を示す回答や回答拒否を生成しやすくする可能性があります。

しかし、自然言語で制約を書いただけでは、禁止した出力の確率が厳密に0になるとは限りません。

P(\text{prohibited output}\mid I) \neq 0

となる可能性は残ります。

禁止出力を確実に止めたい場合は、プロンプトだけでなく、

出力形式の検証
許可値の検査
権限制御
実行前承認
禁止操作のハードコード

など、AIの外側に決定論的な制御を置く必要があります。

Knowledgeは、利用可能になって初めて条件となる

Knowledgeを保存しただけでは、その情報が常にAIの判断へ使われるわけではありません。

Knowledgeが出力へ影響するには、少なくとも、

対象Knowledgeが選択される
モデルが利用できるContextへ入る
モデルが質問との関係を読み取る
生成時にその情報が反映される

必要があります。

したがって、Knowledge設計では情報の内容だけでなく、

いつ読み込むか
どの情報を優先するか
古い情報をどう除外するか
矛盾時にどう停止するか

まで設計対象になります。

RAGは検索結果で生成を条件付ける

RAGでは、質問 $X$ に対して関連文書 $Z$ を検索し、その文書を条件として回答 $Y$ を生成します。

簡略化すると、次のように表せます。

P(Y\mid X) = \sum_Z P(Z\mid X)P(Y\mid X,Z)

$P(Z\mid X)$ ：質問に対して文書 $Z$ が選ばれる確率
$P(Y\mid X,Z)$ ：質問と文書を条件に回答 $Y$ が生成される確率

この式から、RAGには少なくとも二つの誤りの入口があると分かります。

必要な文書を取得できない
取得した文書を使って回答を正しく構成できない

また、古い文書、矛盾した文書、無関係な文書が取得されれば、それらも生成条件になります。

したがって、RAGは単純に「知識を追加する仕組み」ではありません。

どの情報を取得し、どの情報をモデルの条件として採用するかを設計する仕組み

と捉える必要があります。

「確率を変える制御」と「出力を止める制御」を分ける

AIシステムの制御は、大きく二つに分けられます。

制御	役割	例
確率的制御	望ましい出力を生成しやすくする	プロンプト、例示、RAG、Temperature
決定論的制御	許可しない出力・操作を止める	スキーマ検証、権限制御、ルール、承認

プロンプトで「実行しないでください」と依頼することと、システム側で実行権限を与えないことは同じではありません。

高いリスクを持つ処理ほど、確率的制御だけに依存せず、決定論的制御とHuman in the Loopを組み合わせます。

評価対象は一つの回答ではなく出力分布

生成AIは、入力や生成条件によって出力が変わります。

そのため、一つの質問に一度正しく答えたことだけでは、品質を判断できません。

実務評価では、

通常質問
情報不足の質問
対象外の質問
矛盾する資料を含む質問
表現を変えた同義質問

など、入力の集合を用意し、複数の評価軸で確認します。

評価すべきものは、単発の成功例ではなく、想定利用範囲における出力傾向です。

AIが「理解しているか」は、この数式だけでは決められない

自己回帰的にトークンを生成するという説明から、直ちに

AIは意味を理解していない

と結論付けることはできません。

そもそも「理解」を何と定義するかによって議論が変わるためです。

実務設計で必要なのは、AIに理解があるかを断定することではありません。

出力が確率的であり、事実性や業務上の妥当性が自動的には保証されないという性質を前提に、検証可能なシステムを作ることです。

実務への接続

要素	確率的な役割	追加で必要な設計
プロンプト	出力分布を条件付ける	禁止事項の外部検証
Knowledge	継続的な前提を与える	選択、優先順位、更新管理
RAG	検索結果を生成条件へ加える	検索評価、出典、矛盾処理
Temperature	トークン分布の形を変える	タスクごとの評価
ガードレール	出力傾向または許可範囲を制御する	確率的制御と決定論的制御の分離
HITL	AIだけで確定しない	判断者、移管条件、記録

まとめ

生成AIは、Contextを条件としてトークン列を確率的に生成します。

プロンプト、Knowledge、RAG、生成条件は、その出力分布へ影響します。しかし、それだけで正しさや安全性が保証されるわけではありません。

したがって、AI設計では、

確率的に望ましい出力へ導く設計と、望ましくない結果を確実に止める設計を分ける

必要があります。

AIを数学的に捉える目的は、AIを単純化して過信することではありません。

どこまで確率的に制御でき、どこから外部システムと人間の判断が必要になるのかを明確にすることです。

参考資料

Brown et al., Language Models are Few-Shot Learners, 2020.
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.