LLM

LLM とは

LLM (Large Language Model) は、大量のテキストデータで事前学習された大規模な言語モデルである。Transformer アーキテクチャをベースに、テキスト生成、要約、翻訳、分類、コード生成など多様なタスクをこなす。

規模の目安として、パラメータ数を公開しているモデルでは数十億から数千億の範囲が多い。層ごとに一部のパラメータだけを使う疎な混合エキスパート構成を採ると 1 兆規模まで積めることは、2021 年の Switch Transformer の論文が示している。ただし商用モデルはパラメータ数を公表しないものが多く、この数字だけでモデルの優劣は測れない。実際の選定で効くのは、扱えるコンテキスト長、トークン単価、応答速度、そして自分のタスクでの精度である。

2026 年 8 月時点の代表的なモデルファミリーは GPT (OpenAI)、Claude (Anthropic)、Nova (Amazon)、Gemini (Google)。この分野は世代交代が速いため、特定のモデル名やベンチマーク順位を前提に設計を固めると作り直しになる。呼び出しを薄い層で包み、モデルを差し替えられる形にしておくのが安全である。

Transformer アーキテクチャ

2017 年の論文「Attention Is All You Need」(Vaswani ら) で提案された Transformer が LLM の基盤技術である。それまでの主流は再帰型ニューラルネットワークによるエンコーダー・デコーダー構成だったが、この論文は再帰も畳み込みも使わず注意機構だけで系列を扱えることを、機械翻訳のタスクで示した。自己注意機構 (Self-Attention) は、文中のある位置が他の全位置とどれだけ関係するかを重みとして計算する。

入力: 「猫が魚を食べた」
       ↓
[トークン化] → [埋め込み] → [Self-Attention × N層] → [出力]
                                    ↑
                            各単語が他の全単語との
                            関連度を計算

RNN/LSTM は前の単語の計算が終わるまで次に進めないが、Transformer は文中の全位置を同時に計算できる。この並列性が GPU での大規模学習を現実的にし、データとパラメータを増やす方向の競争を成立させた。なお原論文の構成は翻訳向けのエンコーダー・デコーダー型で、文章を続けて生成する用途ではデコーダー側だけを積み重ねた構成が広く使われる。

事前学習と事後学習

LLM の学習は 2 段階に分かれる。前段の事前学習は大量のテキストで「次のトークンを当てる」課題を解かせるもので、ここで文法・語彙・世界の知識がパラメータに入る。ただし事前学習を終えただけのモデルは指示に従う振る舞いを持たず、質問に答える代わりに質問の続きを書いてしまうことがある。

その差を埋めるのが後段の事後学習である。2022 年の InstructGPT の論文 (Ouyang ら) は、人手で書いた模範解答による教師ありファインチューニングと、出力の順位付けを学習した報酬モデルによる強化学習 (RLHF) を組み合わせる手順を報告した。同論文の人手評価では、13 億パラメータの InstructGPT の出力が 1750 億パラメータの GPT-3 より好まれており、指示追従の良さはパラメータ数だけでは決まらないことが示されている。今の対話型 LLM が「頼んだ形で答える」のはこの段階の産物である。

この二段構造は使う側の打ち手も分ける。知識は事前学習の時点で固定され、学習データの締め切り以降の出来事は知らないため、不足は外部から与えるしかない。一方で口調や出力形式は事後学習で付いた癖なので、プロンプトで比較的動かせる。知識の穴は RAG、振る舞いの調整はプロンプト、と切り分けて考えると手を選びやすい。

LLM の利用形態

自社システムへの組み込み方は、運用の重さと制御できる範囲のトレードオフで 4 通りに分かれる。

形態	説明	AWS サービス
API 利用	プロバイダーのモデルを API で呼び出す	Bedrock
ファインチューニング	自社データで追加学習	Bedrock / SageMaker
RAG	外部知識を検索して回答に組み込む	Bedrock + OpenSearch
セルフホスト	オープンソースモデルを自前で運用	SageMaker Endpoints

検討は上の行から順に進めるのが定石である。まず API 利用で試し、精度が足りないときは原因を切り分ける。足りないのが知識なら RAG、出力の形式や口調ならプロンプトの作り込み、それでも埋まらない業務固有の判断基準ならファインチューニングという順になる。セルフホストが正当化されるのは、データを外部に出せない制約があるか、推論量が大きく従量課金より自前運用が安くなる場合に限られる。GPU インスタンスは待機中も課金されるため、間欠的な負荷では API 利用の方が安く済むことが多い。

トークンとコスト

LLM はテキストをトークン (単語の断片) に分割して処理する。課金も入力トークン数と出力トークン数をそれぞれ別の単価で数える形が一般的で、どちらが支配的になるかは用途で変わる。長い資料を読ませて短く答えさせる用途は入力側が、短い指示から長文を書かせる用途は出力側が効く。

日本語が英語より割高になるのは、トークナイザーの語彙が英語中心に作られているためである。UTF-8 では日本語 1 文字が 3 バイトを占め、語彙に無い文字列はより短い単位まで分解される。そのため日本語は 1 文字が 1 トークンに収まらず複数トークンに割れることがあり、同じ内容でも英語よりトークン数が増える。どこまで割れるかはモデルごとのトークナイザー次第なので、見積もりは使うモデルで実測する。

コスト設計の要点は 3 つある。1 つ目は階層化で、分類や抽出のような定型処理は小型モデルに任せ、判断を要する処理だけ上位モデルへ回す。2 つ目はプロンプトの棚卸しで、毎回送っている長い共通指示が本当に必要か見直す。3 つ目はキャッシュで、同じ問い合わせが繰り返される用途では応答を保存して再利用する。効果の大小は入力と出力のどちらが支配的かで変わるため、まずトークン数を計測してから手を打つ。

ハルシネーション

LLM が出力を選ぶ基準は「次に来る確率が高いトークン」であり、その内容が事実かどうかを照合する仕組みは推論の中に無い。この構造上、学習データに無い固有名詞や数値を尋ねられても空白にはならず、文脈に馴染む形をした誤りが埋まる。流暢さと正しさが別々に決まるため、誤りが自信のある文体で出てくる。これがハルシネーションと呼ばれる現象で、2022 年の調査論文 (Ji ら) が生成タスク横断で計測手法と緩和策を整理している。

崩れやすいのは、めったに現れない固有名詞、年号や金額のような数値、存在しない API 名や引数である。いずれも形だけは正しそうに見えるため、人のレビューでも通り抜けやすい。

対策は 2 方向ある。1 つは根拠を与える方向で、RAG で外部知識を検索させ、参照した文書を出力に添えさせる。検索が的を外せば誤りは残るので、どの文書を根拠にしたか追跡できる形にしておくことが前提になる。もう 1 つは検証する方向で、出力を機械的に確かめられる形式に寄せる。コードならコンパイルや実行、構造化データならスキーマ検証、固有名詞なら手元の台帳との突合で、人手を介さずに落とせる。

temperature を下げるのはハルシネーション対策ではない。下がるのは出力のばらつきであり、同じ誤りを毎回安定して繰り返すようになるだけである。再現性が欲しい場面では有効だが、正しさの担保とは別の話として扱う。