モデルは会話を記憶しない
ChatGPT のように滑らかに続く会話であっても、モデルの立場からすれば毎ターンが初めてです。アプリケーションは毎回、直前までの会話全体を一つの入力として改めてつなぎ合わせて送り、モデルはその塊を初めて見るテキストのように読んだうえで、次のトークンを一つ予測します。「記憶」のように見えるものは、モデルの性質ではなく、会話履歴を繰り返し載せ直して送るサービス設計の結果です。
この構造は、二つの実務的な帰結を生みます。会話が長くなるほど送り直すべきテキストが積み上がってコンテキストウィンドウが埋まっていき、入力トークンが増えた分だけ毎ターンのコストもふくらみます。そのため、長い会話を扱うサービスでは、履歴をどこまで載せ、どこで要約するかは、便利機能ではなく最初から設計すべき課題になります。
トークナイザーを開けば韓国語の不利が見えてくる
モデルは文字をそのまま読むのではなく、トークンという断片に切り分けて読みます。トークナイザーを自分で開いてみると、言語ごとの違いが目に入ります。韓国語のあいさつ「안녕（アンニョン）」はトークン二つに分かれますが、「안녕하세요, 어떻게 지내세요?」は八つに切られ、近い意味の英語「How are you?」は六つで終わります。
トークナイザーの語彙が英語中心のコーパスから作られているため、韓国語は同じ意味を担うのにより多くのトークンを使います。その結果、同じ大きさのコンテキストウィンドウには、韓国語は英語より少ない内容しか収められず、トークン単位で課金されるコストも高くつきます。韓国語の AI サービスを企画するなら、この不利は機能を載せる前に、スタートラインの時点で織り込んでおくべき制約です。
ハルシネーションと出力のばらつきは数行のコードで再現できる
存在しない 2019 年の論文の貢献をもっともらしく述べる場面さえ、数行のコードがあれば自分で作ってみることができます。モデルにとっては、「知らない」と答えるよりも、文脈に合う次のトークンをつなぐほうが自然だからです。ハルシネーションはモデルが故障した信号ではなく、事実かどうかではなく、もっともらしさを基準に次のトークンを選ぶという動作の仕方が、表に現れた結果です。
同じ質問であっても、出力は設定と指示によって大きく揺れます。temperature を 0.1 から 1.8 に上げれば同じ入力でも答えが完全に分かれ、システムプロンプトの一行を変えれば、同じブラックホールの質問に対して理科の先生とソクラテスがそれぞれ異なる口調で答えます。出力が唯一の正解ではなく、設定と指示の関数だと分かれば、プロンプトやパラメータへの向き合い方が変わります。
説明として聞くことと、画面で見ることは重みが違う
こうした現象は、言葉で説明を聞くときと、画面で直接見るときとで重みが違います。トークナイザーが韓国語をより細かく刻む場面や、temperature を上げたときに答えが分かれる場面を一度でも目で確かめた人は、ハルシネーションをモデルのせいにする代わりに、出力に検証の手順を付け、長い会話の履歴管理を設計課題として扱い始めます。
SH Consulting の AX 研修で、非開発者に対してもコードの実演にこだわるのは、まさにこのためです。原理を抽象的に知っていることと、数行のコードでその原理を自ら再現してみることとでは、その後の意思決定が変わります。ツールを神秘化することも、漠然と恐れることもなく、限界を知ったうえで制御しながら使う——その姿勢はそこから始まります。