大規模言語モデルについて学び始めると、まず注目されやすいのは対話性能や文章生成の自然さです。実際、利用者の目に見える価値は、質問に答えられること、文章を要約できること、あるいは指示に沿って自然な出力を返せることにあります。しかし、その見えている性能は、いきなり後段の調整だけで成立しているわけではありません。モデルがそうした振る舞いを取れるようになる前に、非常に大きな土台作りの工程が存在します。それが事前学習です。事前学習は、単に学習の最初に行う作業という意味ではなく、モデルが言語をどのように理解し、どの程度まで汎用的に扱えるかを決める中心工程として位置づけるべきものです。

また、事前学習を正しく理解すると、大規模言語モデルの性能差をどこで見るべきかも見えやすくなります。後から行う微調整や指示追従の工程はたしかに重要ですが、それらが効きやすいかどうかは、事前学習によってどれだけ豊かな基盤能力が形成されているかに強く依存します。つまり、事前学習は表に見えにくい工程でありながら、実際にはモデルの性格そのものを形作っている部分です。本記事では、この事前学習とは何かという基本から、自己教師あり学習の仕組み、コーパス設計、トークン化、スケーリング則、計算資源、限界、そして実務での位置づけまでを、つながりを意識しながら順に整理していきます。

大規模言語モデル（LLM）は高い性能を持つ一方で、モデルサイズが非常に大きく、実運用ではメモリ使用量と推論レイテンシが大きな課題になります。たとえば、モデルをそのまま高精度の浮動小数点形式で保持すると、GPUメモリやメインメモリの消費が大きくなり、単純に「試してみる」だけでも環境要件が重くなりがちです。さらに、推論時には大量の重みを読み出して計算し続ける必要があるため、計算そのものの速度だけではなく、メモリ帯域やハードウェア資源の制約が全体の応答速度に強く影響します。つまり、LLMではモデルそのものの賢さだけではなく、それをどの精度で保持し、どの形で実行するかが、実用性を大きく左右します。

実務で大規模言語モデル（LLM）を使おうとすると、多くのチームが早い段階で同じ壁にぶつかります。汎用モデルは非常に高い汎用性を持っている一方で、自社固有の業務知識、社内用語、独自ルール、望ましい応答スタイルまではそのままでは十分に扱えないことが多いからです。たとえば、社内FAQに正確に答えてほしい、法務文書の社内ルールに沿って返してほしい、問い合わせ対応で自社の言い回しに合わせてほしい、あるいはコード生成で特定の実装規約に寄せてほしい、といった要求が出てきます。このとき現場では、「モデルに業務ドメインを理解させたい」という同じ目的に対して、主に二つの選択肢が浮かびます。それがファインチューニングとRAGです。

大規模言語モデル（LLM）が文章を生成するとき、内部では次に出すべきトークン候補に対して確率分布（Probability Distribution）を作り、その中から一つを選び続けています。この「どう選ぶか」は、モデルの性能そのものと同じくらい、出力品質を大きく左右します。たとえば、常にもっとも確率の高いトークンだけを選ぶ Greedy Search では、文としては安定しやすい一方で、同じ言い回しを繰り返したり、表現が単調になったりしやすくなります。特に長めの文章生成や創造性が求められる用途では、出力が早い段階で硬直し、結果として不自然な反復や多様性の欠如が起こることがあります。

大規模言語モデルの議論では、しばしば「モデルは大きいほど強い」という見方が前面に出ます。実際、パラメータ数を増やすことで表現力が広がり、より複雑な言語パターンや知識の関係を学習しやすくなるのは確かです。しかし、実際のモデル開発や運用の現場では、その直感だけで設計を進めるとすぐに限界へぶつかります。モデルを大きくしたのに期待したほど性能が伸びない、学習コストだけが急激に上がる、十分なデータが用意できず巨大モデルを活かしきれない、推論コストが高すぎて実用化しにくい、といった問題が次々に現れるからです。つまり、LLM開発では「どこまで大きくするか」以上に、「何をどの比率で増やすか」のほうが重要になります。

ベクトル検索や埋め込み活用を学び始めると、かなり早い段階で出会うのが「コサイン類似度とユークリッド距離は何が違うのか」という問いです。どちらもベクトル同士の近さを測る代表的な指標であり、検索、推薦、分類、まとまり分けなど幅広い場面で使われています。そのため、見た目には似た役割を持っているように感じられます。しかし実際には、両者が見ているものはかなり異なります。コサイン類似度はベクトルの向きの近さを見ており、ユークリッド距離は空間上での位置の差を見ています。この違いを曖昧なまま理解していると、埋め込み検索で不自然な検索結果が出たときに理由が分からなかったり、距離関数の選定を感覚で済ませてしまったりしやすくなります。

検索拡張生成は、小さく始める段階では非常に魅力的に見えます。数千件から数万件ほどの文書を用意し、埋め込みを作り、ベクトル検索で関連文書を取得し、大規模言語モデルへ渡して回答を生成する。この流れは試作段階では比較的素直に動きやすく、少人数の開発体制でも価値検証までたどり着きやすいです。特に、社内向けのナレッジ検索、FAQ支援、問い合わせ補助のような用途では、最初の段階で「かなり使えそうだ」という感触を得やすく、検索拡張生成は導入効果が見えやすい仕組みだと言えます。しかし、その状態のままデータ件数が増え、利用者が増え、更新頻度が上がり、本番での安定運用が求められるようになると、途端に別の難しさが前面に出てきます。試作では問題にならなかった待ち時間が利用者体験を損ねるようになり、同時アクセスが増えると処理が詰まり、文書更新が頻繁になるとインデックス更新や整合性維持が負担になり、さらに費用と品質の両方を維持し続けることが難しくなっていきます。

生成AI、意味検索、推薦、画像検索、検索拡張生成の広がりによって、データを「完全一致」で探すのではなく、「意味が近いもの」や「特徴が似ているもの」を探す仕組みが、実務の中で急速に重要になっています。このとき中心になるのが、文章や画像、音声、行動履歴などを埋め込みベクトルへ変換し、その近さをもとに候補を探すベクトル検索です。ただし、ベクトル検索は、単にベクトルを保存しておけば自動的に速く動くわけではありません。件数が増えるほど、問い合わせベクトルとすべての保存ベクトルを比較する計算は重くなり、実務で求められる応答速度を満たしにくくなります。そこで必要になるのが、近い候補をなるべく少ない探索で見つけるための索引構造、すなわちベクトルインデックスです。

生成AI、意味検索、推薦、検索拡張生成の普及にともなって、文章や画像を埋め込みベクトルへ変換する処理は、多くのシステムで日常的に呼び出される基盤処理になりました。ユーザーの質問を受け取るたびに埋め込みを生成し、文書検索のために大量の文書片をベクトル化し、必要に応じて再検索や再順位付けの前段で再び埋め込みを使うという構成は、もはや特殊なものではありません。しかし、この埋め込み計算は常に無料でも瞬時でもありません。外部の埋め込み生成サービスを使っているなら呼び出し回数に応じて費用が発生しますし、自前でモデルを動かしている場合でも計算資源、待ち時間、同時実行数、メモリ帯域といった負荷が無視できません。特に、同じ問い合わせやほぼ同じ文書が繰り返し処理される環境では、毎回あらためて埋め込みを計算すること自体が大きな無駄になりやすくなります。

生成AI、意味検索、推薦、社内知識活用の広がりによって、文章や画像を単なる文字列や画素の集合として扱うのではなく、「意味が近いかどうか」で扱う設計が、実務の中で急速に重要になっています。このとき中心になるのが埋め込みです。埋め込みは、文章、画像、音声、表形式データなどを多次元の数値ベクトルへ変換し、それらの位置関係を使って近さや関連性を判断できるようにする仕組みです。たとえば、単語が完全には一致していなくても、意味として近い問い合わせと文書を結びつけたり、似た内容の事例を探したり、質問と関連の深い根拠文書を取り出したりできるのは、埋め込み表現が意味の近さをある程度保っているからです。つまり、埋め込みは、現代の意味検索や検索拡張生成を支える土台であり、単なる前処理ではありません。