AIの記事でよく見る数式、ここだけ読めば怖くない

AIの記事を読んでいると、急に数式が出てきてそこで閉じることがある。
ただ、実際には全部を解けるようになる必要はない。

この記事の目的は、数式を使ってAIを厳密に導出することではない。
「この式はこういう処理をまとめて書いているのか」と読めるようになることを目標にする。

ここでは微積は解かない。
学習のところで「間違いを減らす方向に少しずつ直している」と読めれば十分。

数式は「魔法の呪文」ではなく、処理の省略記法

AIでやっていることをかなり大ざっぱに書くと、流れはこうなる。

flowchart LR
    A[入力<br/>単語 画像 音声] --> B[数字にする]
    B --> C[重みをつけて足し合わせる]
    C --> D[途中で形を変える]
    D --> E[確率っぽい値にする]
    E --> F[出力を選ぶ]

「数字にする」「足す」「形を変える」「確率にする」。
拍子抜けするくらい単純に見えるが、基本はこの組み合わせだ。

このブログで書いてきたLLM、エンコーダー、画像生成、3Dモデルの記事も、奥にある計算を荒く見るとだいたいこの流れで説明できる。

まずは「数字の並び」で扱う

AIは文字や画像をそのまま触っているわけではない。
まず数字の並びに変える。

たとえば、

単語なら「この単語がどういう意味の近くにいるか」
画像なら「この部分に輪郭や色の変化があるか」
音声なら「どの周波数がどれくらい強いか」

のような情報を、長い数字の並びで持つ。

こういう数字の並びは、記事や論文では ベクトル と書かれることが多い。
難しそうに見えるが、まずは「数字が横に並んでいるだけ」と思っておけば十分。

この段階は、画像を見てJSONを返させたローカルVision LLMでキャラ画像からRPGパラメータを抽出できるか試したのような実験でも、画像から3Dをローカル生成したTRELLIS.2をM1 Max 64GBで動かしてみた検証ログのような話でも同じだ。

AIはまず「重要度つきの足し算」をする

最初に見る式はこれでいい。

y = w_1 x_1 + w_2 x_2 + \cdots + w_n x_n + b

記号の意味はこう読む。

記号	ざっくりした意味
$x$	入力の要素
$w$	その要素をどれだけ重く見るか
$b$	全体の位置を少しずらすための補正
$y$	最終的に出てくる値

やっていることは単純で、入力のそれぞれに重要度を掛けて足しているだけだ。

たとえば文章なら、

ある単語は強く効く
ある単語はほとんど効かない
組み合わせで効き方が変わる

という形で効いてくる。

画像でも同じで、輪郭や色や位置の情報に重みをかけて混ぜている。
AIが最初から「猫だ」と分かっているわけではなく、まずは特徴に点数をつけて集計しているイメージだ。

足し算だけでは境目が作れない

ただの足し算だけだと、AIはひたすら直線的にしか反応できない。
そこで途中に「形を変える処理」を入れる。

初心者向けに一番見やすい例が シグモイド だ。

入力が小さいと0寄り、大きいと1寄りになる。真ん中あたりでぐっと変わる。

式で書くとこうなる。

\sigma(x) = \frac{1}{1 + e^{-x}}

でも、式そのものよりグラフの形が分かれば十分だ。
要するにこれは、

すごく小さい値をほぼ0に寄せる
すごく大きい値をほぼ1に寄せる
真ん中あたりだけ敏感に反応する

というカーブだ。

これで「犬っぽいか」「猫っぽいか」「ある特徴が強いか弱いか」みたいな境目を、カクッではなくなめらかに作れる。

なお、最近のモデルで実際によく使われるのは別の関数であることも多い。
ここでは「足し算だけでは足りないので、途中で形を変える」という感覚を掴むためにシグモイドを例にしている。

ChatGPTっぽさの正体は「確率を並べること」

LLMの出力で一番大事なのはここだ。

P(y_i) = \frac{e^{z_i}}{\sum_j e^{z_j}}

これは Softmax と呼ばれる式で、候補それぞれに付いた生の点数を、確率っぽい比率に直す。

読み方はこうだ。

$z_i$ は各候補の生の点数
$P(y_i)$ はその候補が選ばれそうな度合い

たとえば次に来る単語の候補が3つあるとする。

候補	生の点数
「です」	高い
「ます」	そこそこ高い
「冷蔵庫」	低い

この「高い」「そこそこ高い」「低い」を、ちゃんと比率に直すのがSoftmaxだ。

だからChatGPTは、答えを棚から取り出しているわけではない。
「この文脈なら次はどれが自然そうか」を毎回計算している、という動きになる。

同じ考え方は、OCR向けにBERTを使ったエンコーダーモデル+ローカルLLMでOCR誤字を自動検出・修正するのような実験でも出てくる。
候補文字それぞれの点数を確率に直して、「この文字はどれくらい怪しいか」を見ている。

以前書いた「ChatGPTは27%嘘をつく」の元ネタを調べたのような話も、根っこのところではこの「もっともらしさを並べて次を出す」仕組みと繋がっている。

学習データがそのまま入っているわけではない、とはどういうことか

ここまでの話を見ると、AIが持っているのは文章そのものというより、

どんな特徴にどんな重みを付けるか
どういうときにどの候補が高くなるか

という形の数字だと分かる。

なので、基本的には学習データの文章をそのまま倉庫のように保存して、必要なときに引っ張り出しているわけではない。
つながり方や傾向が重みに染み込んだ状態で持っている、というイメージだ。

ただし、ここは完全にゼロイチではない。
特定の断片を強く覚えてしまうことはあるし、長い固有表現や定型文がそのまま出てくることもある。
それでも基本構造としては「丸ごと保存」より「パターンが重みに反映される」と捉える方が、AIの動きは追いやすい。

学習は「外したら少し直す」の繰り返し

学習は、ものすごく乱暴に言うと次の2行で見られる。

L = - \log p

w_{\text{new}} = w_{\text{old}} - \eta g

1つめの $L$ は「どれくらい外したか」。
ここでの $p$ は、正解に付けた確率だと思えばいい。
正解なのに低い確率しか出せていなければ、損失は大きくなる。

2つめは重みの更新だ。
「新しい重み = 今の重み - 調整量」と読めばいい。

記号	ざっくりした意味
$w_{\text{old}}$	今の重み
$w_{\text{new}}$	更新後の重み
$\eta$	1回でどれだけ動かすか
$g$	間違いを減らす向き

つまり、

まずどれだけ外したかを測る
次に外し方を減らす向きへ少し動かす
それを大量に繰り返す

だけだ。

本当はここで微分が出てくる。
でも入口としては、「正解との差を見て、少しずつ直している」で十分だと思う。

ここまで分かると、他の記事も読みやすくなる

このくらいの数式が読めるようになると、AI系の記事で何が書いてあるかがかなり追いやすくなる。

種類	ざっくりした役割
エンコーダー	入力から特徴を抜いて、扱いやすい数字にしている
LLM	次に来る単語やトークンの確率を連鎖させている
VLM	画像とテキストをまとめて扱っている
画像生成	ノイズを少しずつ「それっぽい画像」に寄せている
3Dモデル	画像や動画の特徴を数字にして、形に戻している

たとえばZ-Image（造相）をRunPodで動かせるか調べた — キャラ造形の安定性に期待のような実働記事でも、裏ではテキストや画像の特徴を数字として扱っている。
また、ローカルVision LLMでキャラ画像からRPGパラメータを抽出できるか試したのようなマルチモーダルの実験も、画像とテキストを同じように数字空間で扱う、という考え方の延長にある。

気になった人向けの用語メモ

この節は読み飛ばしてOK。
本文で出てきた言葉だけ、最低限の意味を置いておく。

AI全般

用語	意味
ベクトル	数字が横に並んだもの。AIでは、単語や画像の特徴をこういう並びで持つことが多い
重み	どの情報を強く見るかを決める係数。同じ入力でも、重みが違うと結果が変わる
活性化関数	足し算だけでは作れない曲がり方を入れる処理。シグモイドはその一例
Softmax	点数の並びを、比率や確率っぽい形に直す処理。LLMの「次にどれを出すか」だけでなく、別の場面では「どこをどれだけ見るか」の重み付けにも出てくる
損失関数	どれだけ外したかを数字にしたもの。大きいほど「まだ直し足りない」と見ればいい
学習率	1回の修正でどれだけ動かすか。大きすぎると荒れやすく、小さすぎると進みが遅い
エンコーダー	入力を扱いやすい特徴に変える側のモデル。意味や形を数字に写す役だと思えば十分

画像生成でよく見る言葉

用語	意味
テキストエンコーダー	プロンプトを、画像モデルが読める数字の並びに変える部分。ComfyUIだと `CLIP Text Encode` 系のノードで見かける
VAE	画像をいったん扱いやすい形に圧縮したり、最後に画像へ戻したりする部分。`VAE Encode` や `VAE Decode` がそれ
latent	画像そのものではなく、VAEの内側で使う途中の表現。ComfyUIで `latent` と書いてあったら「まだ画像になる前の数字」と思えばいい
CFG	プロンプトをどれくらい強く効かせるかの強さ。高すぎると不自然になり、低すぎると指示が弱くなる
step	ノイズから画像に戻す反復回数。多いほど丁寧になりやすいが、その分遅い
sampler	ノイズの減らし方の手順。ComfyUIの `KSampler` で触る部分だと思えば十分

これ、自分でも作れるの？

ChatGPTそのものや画像生成AIをExcelで作るのは無理だ。
でも、この記事で見た基本計算のミニ版なら、表計算でも追える。

たとえば、2つの入力に重みを付けて足すだけならこうなる。

$x_1 = 0.8$
$x_2 = 0.3$
$w_1 = 1.2$
$w_2 = -0.5$
$b = 0.1$

y = w_1 x_1 + w_2 x_2 + b

これなら、Excelやスプレッドシートでそのまま計算できる。

=1.2*0.8 + (-0.5)*0.3 + 0.1

さらに、出力を0〜1っぽい値にしたければシグモイドも入れられる。

=1/(1+EXP(-A1))

ここで A1 は、さっき計算した $y$ が入っているセルだと思えばいい。

これだけでも、

重みがプラスなら出力を押し上げる
重みがマイナスなら逆方向に効く
値をそのまま出すのではなく、最後に形を変えることがある

という感覚はかなり掴める。

なんちゃって天気予想AIならどうなるか

もう少しAIっぽく見せるなら、
「明日、雨っぽいか」を出す超ミニ版も考えられる。

ここでは説明のために学習用データを表にしている。
ただし、予測のときにこの表をそのまま参照するわけではない。
学習で調整されるのは「どの要素をどれくらい重く見るか」という重みだ。

たとえば学習用データがこんな感じだとする。

前日雨	湿度高い	気圧下がる	明日雨
1	1	1	1
1	1	0	1
0	1	1	1
1	0	0	0
0	0	1	0
0	0	0	0

学習が進んだ結果、重みがこうなったとする。

要素	値
前日雨の重み	0.6
湿度高いの重み	1.0
気圧下がるの重み	1.3
補正 $b$	-1.4

ここで、学習用データにはなかった新しい入力を入れてみる。

前日雨	湿度高い	気圧下がる
1	0	1

計算はこうなる。

y = 0.6 \times 1 + 1.0 \times 0 + 1.3 \times 1 - 1.4 = 0.5

シグモイドに通すと、

\sigma(0.5) \approx 0.62

なので、「雨っぽさ 62% くらい」と読める。

Excelやスプレッドシートなら、たとえばこう書ける。

=0.6*1 + 1.0*0 + 1.3*1 - 1.4

=1/(1+EXP(-0.5))

もちろん実際の天気予報はこんな単純ではない。
でも、

学習用の表がある
学習後には重みが残る
予測時はその重みで新しい入力を計算する

という流れを見るには十分だと思う。

ここで大事なのは、学習データの行をそのまま探しているわけではないことだ。
「湿度が高いと雨寄り」「気圧が下がるとさらに雨寄り」のような傾向が、重みに反映されていると見る方が近い。

要するに、巨大モデルは無理でも「AIの基本にある計算」は人力で追える。
数式が急に記号の羅列ではなく、ただの計算に見えてくるはずだ。

なんちゃって競馬予想AIのようなものも、大まかな仕組みは同じだ。
気になったら遊びで作ってみると、入力を数字にして重みを付ける感覚が掴みやすいかもしれない。
ただし実際は見るべき要素が多いので、自分で試すなら競艇のほうがまだ整理しやすそう、という気はしている。

実際に動かした関連記事

このブログ内で、数式の裏側がどう挙動に見えるかを追いやすいのはこのあたり。

エンコーダーモデル+ローカルLLMでOCR誤字を自動検出・修正する
エンコーダーが各位置の確率を見る、という話の実例
ローカルVision LLMでキャラ画像からRPGパラメータを抽出できるか試した
画像を見てJSONを返す、マルチモーダル実験の例
Z-Image（造相）をRunPodで動かせるか調べた — キャラ造形の安定性に期待
画像生成モデルを実際に回しながら見る入口
TRELLIS.2をM1 Max 64GBで動かしてみた検証ログ
画像の特徴から3Dをローカル生成する実験

補足で読むなら

MoonshotAI（Kimi）がTransformerの残差接続をAttentionで置き換えるAttnResを提案、1.25倍の計算効率
Softmax が「どこをどれだけ見るか」の重み付けに出てくる例
Z-Image — FLUXを超えたと言われるAlibaba発の画像生成AI
Z-Image の位置づけや構成を先に整理した記事