AI へ戻る / Learn LLM

読む順番

19 本の記事

Learn LLM

訓練ループからドメイン小型モデルへ

PyTorch の訓練ループ、tokenizer、attention、MiniGPT から RAG、SFT、LoRA、評価、安全性、ドメインプロジェクトまで進む実践的な LLM 講座です。

読み始める

目次

順番に読むと、モデルの仕組みから Agent と Harness の工学的な見方までたどれます。

  1. 01 第 1 章: 訓練ループ、計算グラフ、再現可能な実験 ガイド あなたはすでに Python を書ける前提なので、この章では文法の説明はしません。深層学習のいちばん中心にある問いに直接向き合います。
  2. 02 第 2 章: 言語モデルの確率的目的 第 1 章では分類器を訓練しました。ベクトルを入力し、クラスを出力するモデルです。ここでは、より LLM らしい問題に切り替えます。
  3. 03 第 3 章: Tokenizer とデータセット構築 言語モデルが扱えるのは整数 ID だけです。しかし、ユーザー、文書、訓練セットはすべてテキストです。Tokenizer は「前処理用の小道具」ではありません。モデルの入力空間を定義するものです。vocab の大きさ、長い語の分割方法、未知文字の扱い、padding を loss に入れるかどう...
  4. 04 第 4 章: Embedding とニューラル言語モデル Tokenizer によって、テキストは token id になりました。しかし token id はただの番号です。
  5. 05 第 5 章: Causal Self-Attention 第 4 章の causal mean model はすでに過去を見ることができます。しかし明らかな問題があります。
  6. 06 第 6 章: Transformer Block 第 5 章の causal self-attention によって、各 token は過去位置を動的に振り返れるようになりました。では、なぜ attention を何層も積み重ねるだけで GPT と呼べないのでしょうか。
  7. 07 第 7 章: Mini GPT をゼロから実装する 前の章では、LM 目的、tokenizer、embedding、attention、block をそれぞれ実装しました。この章では、それらを decoder-only language model として組み合わせ、訓練、保存、読み込み、生成まで行えるようにします。
  8. 08 第 8 章: Hugging Face ワークフロー 第 7 章では、言語モデルの内部構造を理解するために Mini GPT をゼロから実装しました。現実のプロジェクトでは、通常ランダム初期化から訓練を始めません。オープンソースモデル、tokenizer、設定、重み形式、訓練ツールチェーンを再利用します。
  9. 09 第 9 章: SFT 指示微調整 第 8 章では causal LM の読み込みと微調整を学びました。しかし causal LM の元の目的は、あくまで「続きを書く」ことです。ユーザーが本当に望むのは、タスク、制約、文脈、質問をモデルに与え、指示に従った使える回答を出してもらうことです。
  10. 10 第 10 章: LoRA / QLoRA によるパラメータ効率のよい微調整 第 9 章の SFT では、モデルパラメータを更新できる前提でした。しかし 7B、14B、あるいはそれ以上のモデルを全量微調整すると、GPU メモリ、保存、配布、ロールバックのコストが大きくなります。ドメインプロジェクトでは、すべての知識を書き換える必要はなく、少数のタスク方向に制御可能なずれ...
  11. 11 第 11 章: ドメインデータ工程 第 10 章では微調整コストを下げましたが、能力の出所はまだ解いていません。ドメイン小規模モデルが強くなるのは、多くの場合 adapter 技法そのもののためではありません。データがタスク境界、用語、形式、拒否、評価目標を明確に定義するからです。
  12. 12 第 12 章: RAG 検索拡張生成 第 11 章でドメインデータ工程を整理すると、新しい問題が出てきます。すべての知識をモデルパラメータに書き込むべきではありません。法律条文、医療ガイドライン、社内制度、製品ドキュメントは更新されます。多くの回答には追跡可能な根拠も必要です。
  13. 13 第 13 章: 小規模モデルの蒸留 RAG によって強いモデルは外部根拠に基づいて回答できます。しかし強いモデルを毎回呼び出すと、高価で、遅く、制御しにくい場合があります。ドメインプロジェクトでは、強いモデルが特定タスクで示す振る舞いを、より小さく、安く、デプロイしやすい student model へ移したいことがよくあります。
  14. 14 第 14 章: モデル評価 第 13 章では蒸留後の student を得ました。しかしモデルが「話せる」ことは、モデルが「信頼できる」ことと同じではありません。LLM プロジェクトで最も危険なのは、見栄えのよい数例を評価の代わりにし、平均点で高リスク失敗を隠すことです。
  15. 15 第 15 章: 安全、コンプライアンス、Model Card 第 14 章ではモデルの失敗を見つけられるようにしました。この章では、失敗境界をリリース前に必ず確認し、告知し、継続監視する工程契約へ変えます。特に法律・医療場面では、モデルは「それらしく答える」ことだけを目指してはいけません。いつ答えてはいけないか、いつ人間レビューを求めるべきかを知る必要が...
  16. 16 第 16 章: 量子化とデプロイ 前の章までで、評価と安全レビューを通ったモデルができました。しかしモデルはまだ本当の利用フローには入っていません。デプロイ時には新しい制約が出てきます。GPU メモリ、レイテンシ、スループット、同時実行、コールドスタート、監視、ロールバック、コストです。
  17. 17 第 17 章: 法律領域小規模モデルプロジェクト 前 16 章では、訓練、言語モデル、Tokenizer、Transformer、Hugging Face、SFT、LoRA、データ工程、RAG、蒸留、評価、安全、デプロイをそれぞれ学びました。この章では、それらを法律契約レビュー プロジェクトとして組み合わせます。
  18. 18 第 18 章: 医学領域小規模モデルプロジェクト 医学ユーザーは通常、きれいな定義問題を聞きに来るわけではありません。不完全な症状、不安、プライバシー情報、さらには「病院に行きたくない」という明示的な希望を持って来ることがあります。
  19. 19 第19章:ドメインモデルの完全なエンジニアリングテンプレート 第17章と第18章では、それぞれ法律分野と医療分野のプロジェクトを扱いました。2つの領域は大きく異なりますが、エンジニアリングの骨格はよく似ています。データガバナンス、SFT、RAG、蒸留、評価、安全性、デプロイ、そして継続的な改善です。