Pythonで関数を書くとき、最初に覚えるのはdefの書き方やreturnの使い方かもしれません。しかし、実際にコードの品質を左右するのは、文法を知っているかどうかよりも、「この関数は何を受け取り、何を返すべきか」をどれだけ明確に設計できるかです。引数と戻り値は、関数の入口と出口にあたります。そのため、ここが曖昧だと、関数の責務も曖昧になり、呼び出し側との約束も不明確になります。すると、使うたびに中身を読まないと挙動が分からない関数や、思わぬ副作用を持つ関数が増えやすくなります。つまり、引数と戻り値の理解は、Pythonの基礎文法の一部であると同時に、関数設計そのものの基礎でもあります。

Pythonを学び始めた段階では、まず変数、条件分岐、繰り返し、関数といった基本構文を使いながら、小さな処理を順番につないでいくことが多いです。この方法は非常に自然で、短いスクリプトや簡単な自動化であれば十分に実用的です。たとえば、CSVファイルを読み込んで整形する、ログファイルを解析する、定型的な通知を送るといった処理では、関数をいくつか定義して流れを組み立てるだけでも問題なく動きます。しかし、機能が増え始めると事情は変わります。扱うデータの種類が増え、状態管理が必要になり、処理の分岐が複雑になり、さらに将来的な機能追加や修正まで考える必要が出てくると、単に関数を追加していくだけの設計では全体像を保ちにくくなります。どの関数がどのデータを前提にしているのか、どの変更がどこへ影響するのかが見えにくくなり、最初は簡単だったコードが少しずつ保守しにくいものへ変わっていきます。

大規模言語モデルを実務へ導入しようとするとき、多くの組織が最初に直面するのが、「どのモデルを使うべきか」という問いです。しかし、この問いは単に性能ベンチマークを見て決められるほど単純ではありません。あるモデルが高精度に見えても、運用コストが想定以上に重いことがありますし、逆に導入しやすいモデルであっても、制御性やデータ管理の面で要件を満たせないことがあります。特に近年は、API経由で手軽に使えるプロプライエタリLLMと、自前環境で動かせるオープンソースLLMの両方が現実的な選択肢になっているため、比較の軸が一気に増えています。つまり、モデル選定とは単なる性能競争の勝者を選ぶことではなく、自社の要件と制約に対してどの選択肢が最も整合的かを見極める作業です。

自然言語処理や検索の文脈で「埋め込み」という言葉が使われるとき、多くの場合、それは言葉や文章を数値ベクトルへ変換し、意味的な近さや機械学習上の扱いやすさを得るための技術を指しています。しかし、実務ではこの埋め込みという言葉がかなり広く使われているため、「単語埋め込み」と「文埋め込み」の違いが曖昧なまま扱われることが少なくありません。すると、語の類義性を見たいのに文ベクトルを使ってしまったり、意味検索をしたいのに単語ベクトルの平均だけで済ませてしまったりと、目的と表現手法がずれた設計が起こりやすくなります。つまり、埋め込みを正しく使いこなすためには、まず「何を埋め込んでいるのか」という単位の違いをはっきり意識する必要があります。

大規模言語モデルは高い性能を持つ一方で、そのまま運用しようとすると、推論コスト、応答速度、必要メモリ、配備環境の制約といった問題に直面しやすくなります。研究用途や高性能なサーバー環境であれば巨大なモデルをそのまま使えることもありますが、実務の現場では、常に最大規模のモデルが最適とは限りません。社内業務支援、チャットボット、モバイル利用、エッジ環境、高頻度アクセスAPIのような場面では、一定以上の性能を維持しながら、より軽く、より速く、より安く動くモデルが求められます。そこで重要になるのが、AIの蒸留という考え方です。AIの蒸留は、性能の高い大きなモデルが持っている知識や振る舞いを、より小さなモデルへ移し替えることで、単純な小型化以上の性能を引き出そうとする知識転移手法です。

RAGは、検索と生成を組み合わせることで、単体の大規模言語モデルでは扱いにくい最新情報や社内知識、ドメイン固有情報を活用できる仕組みとして広く使われるようになっています。しかし、実務でRAGを導入すると、多くの現場で最初に表面化する問題の一つがレイテンシです。検索を挟まない単純な生成であれば、入力を与えてそのまま応答を返す流れで済みますが、RAGでは問い合わせの前処理、埋め込み生成、検索、再ランキング、文脈構築、最終生成という複数段階が追加されます。そのため、個々の処理が少しずつ重なるだけでも、体感上の遅さは想像以上に大きくなります。

検索システムを設計したり評価したりするとき、多くの人はまず「正しい文書が見つかるかどうか」に注目します。しかし、検索という処理は単に文書を探し当てるだけの単純な操作ではありません。利用者がどのような言葉で質問するのか、文書側がどのような表現で情報を保持しているのか、どの程度のレイテンシが許されるのか、なぜその結果が返ってきたのかを説明できる必要があるのか、といった条件によって、最適な検索手法は大きく変わります。つまり、検索は常に「何を探すか」だけでなく、「どのように探すか」を同時に問う技術です。その中でも、近年特に比較対象として語られることが多いのが、疎ベクトル検索と密ベクトル検索です。

大規模言語モデルについて調べ始めると、早い段階で「事前学習」と「ファインチューニング」という言葉に出会います。ただし、この二つはどちらも学習の一種であるため、表面的には似たものに見えやすく、違いが曖昧なまま使われることも少なくありません。けれども、実際にはこの二つは役割も、目的も、必要なデータも、かかる計算資源もかなり異なっています。しかも、その違いは単なる技術用語の整理にとどまらず、モデルをどう作るのか、どう改良するのか、どのくらいの費用でどこまで実現できるのか、といった実務判断そのものに直結します。つまり、事前学習とファインチューニングの違いを理解することは、モデルの仕組みを知るためだけでなく、現実的な設計や導入の判断力を持つためにも重要です。

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

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

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