サンプリング
読み: サンプリング
サンプリングとはAI出力の制御法
サンプリングとは、大規模言語モデルが次に生成する単語を確率分布の中から選択し、文章の創造性や正確性を意図的にコントロールする出力決定メカニズムを指す。TemperatureやTop-pといったパラメータを調整することで、出力の揺らぎを制御する。
かんたんに言うと
料理の味付けに例えられる。塩加減を固定すれば毎回同じ味の定食になるが、スパイスの量をランダムに変えれば日替わりの創作料理が生まれる。このスパイスのさじ加減を決めるのがサンプリングである。
LLMが次の単語を選ぶ確率と乱数によるトークン選択の裏側
LLMは文章を丸ごと記憶しているわけではない。直前の文脈から次に続く確率が最も高いトークンを予測し続ける単語のしりとりマシンである。ここで常に確率1位の単語を選び続けると、出力は極めて機械的で退屈なものになる。
そこでサンプリングの出番となる。
Temperatureというパラメータを上げると、確率が低い単語も選ばれやすくなる。Top-pは上位何パーセントの確率の単語までを候補に残すかを決めるフィルターである。これらをいじることで、AIの出力に人間らしい揺らぎを生み出せる。ただ、非エンジニアがこの数値を適当に弄るのは危険である。
法務と営業で全く異なる最適解
部門によって求める出力の性質は真逆になる。
法務部門が契約書の条文チェックを行う場合、Temperatureは限りなくゼロに近づけるべきである。Azure OpenAI ServiceでGPT-4oをデプロイし、厳密な事実確認をさせる設定にしなければ、存在しない判例をでっち上げるリスクがある。
逆に営業部門が新規顧客へのアプローチメールを量産するなら、Temperatureを0.7程度まで上げるといい。Claude 3.5 SonnetのAPIを叩き、少し高めの数値を設定すれば、相手の業界に合わせた多彩な言い回しを生成してくれる。同じモデルでも、パラメータ一つで別物になる。この設定を現場の誰が管理するのかは、かなり悩ましい。
事実誤認と表現の多様性が交差する境界線
サンプリング設定をいじれば、表現の幅は広がる。しかし、それは同時に事実誤認のリスクを跳ね上げる諸刃の剣である。
Temperatureを1.0以上に設定したAIに社内規定を質問してみるといい。もっともらしい嘘を平然と吐き出すはずである。プロンプトエンジニアリングでいくら「正確に答えろ」と指示しても、サンプリングの乱数設定が優先されてしまう。
現場の落とし穴はここにある。
クリエイティブなアイデア出しと、厳密なデータ抽出を同じ設定のAIチャット画面でやらせていないだろうか。用途ごとに裏側のパラメータを切り替える仕組みがないと、ユーザーはAIの回答を信用しなくなる。
API経由の制御とRAG構築における判断材料
企業がAIツールを選定する際、画面の使い勝手ばかり気にする担当者が多い。だが本当に見るべきは、裏側のサンプリングパラメータをどこまで制御できるかに懸かっている。
社内文書を検索して回答させるRAGを構築する場合、検索結果という事実ベースの情報を扱うため、出力の揺らぎは邪魔になる。Difyのようなプラットフォームを使えば、ワークフローのステップごとにTemperatureを細かく設定できる。
パッケージ化されたSaaS型のAIツールの中には、この設定をブラックボックス化しているものも少なくない。自社のガバナンス基準に照らし合わせたとき、出力を制御できないツールを全社導入してよいのか。判断が分かれるところである。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。