cocolog:96055360
斎藤康毅『ゼロから作るDeep Learning 6 - LLM編』を読んだ。GPT2 レベルの LLM を実装していくのがこの本。GPT2 レベルの xxLLM 作成のあたりを付けてみようと思ったが、その規模感に作る自信を失った。 (JRF 0866)
JRF 2026年7月 3日 (金)
私は『ゼロから作る Deep Learning』のシリーズの 1巻を [cocolog:87181973](2017年4月) で、2巻を [cocolog:90214777](2018年11月) で、5巻を [cocolog:94787819](2024年4月) で読んでいた。3 と 4 はまだ買っていない。3 と 4 を読んでいなくても 6 は問題なく読めた。基本的には 6 を読むには以前の本の知識はいらないそうである。ただ、Python の知識はもちろん必要。
JRF2026/7/31753
……。
GPT2 レベルの LLM を実装していくのがこの本。最初に Python コードを生成する CodeBot を作る。SFT で質問応答できるようにし、強化学習で簡単な足し算が合うようにする…という流れ。
次にお話を生成する StoryBot を作る。主に高速化の工夫をし、強化学習では、RLHF の考え方を紹介しながら、報酬モデルの作成を短絡した DPO を説明する。
さらに Web から広くデータを集めた巨大なデータセットから、WebBot を作ろうとする。しかし、これはヒントのみ…というかトピックの紹介のみになる。
JRF2026/7/35977
……。
私は xxLLM (JSON を出力する xLLM に対し、JSON を出力するプログラムを出力する LLM) を GPT2 レベルで実装できないか…とあたりを付けながら読んだ。JSON の生成は特別な DSL (Domain Specific Language) の仕様を作って記述する予定なのだが、それは Gemma とかで生成できないかと考えている。
keyword: xxLLM
JRF2026/7/30515
しかし、もっとも小さい CodeBot 作成において、その 6MB の codebot/tiny_codes.txt をのぞいてみて驚いた。文がとんでもなく多いのである。6MB のサイズ感でこれなのか…と。これを無料とは言え Gemma の LLM で変換していくのは、かなり無理があるのではないのか…とたじろいでいる。
JRF2026/7/32796
……。
codebot/tiny_codes.txt はほとんどがプログラムまたは説明付きのプログラムで会話なんてほとんどないのに、SFT で会話を訓練するとうまくいくらしいのが、ちょっと信じられない。これは、会話に反応しているわけでなく、単にコピペ的に SFT された内容を繰り返しているだけなのかもしれないが…。
JRF2026/7/30182
……。
p.164 にある ch03/09_grpo.py で、all_prompts と all_responses から get_batch でバッチを作っているのに、アドバンテージに関しては all_advantages のまま使っているところで混乱した。
JRF2026/7/39251
Gemini さんに聞いたところ判明したのは、p.159-160 の get_batch をちゃんと読むと、そこではバッチを数個取り出すという処理はしておらず、all_prompts と all_responses と数は変わらないということだ。だったら、get_batch じゃなく fix_batch みたいにしてくれてたらよかったのに！…まぁ、これはその後の章で同名でちゃんとバッチを作ってるみたいだから、しかたないのかもしれないけど。
JRF2026/7/38625
……。
RLHF とか DPO などの強化学習については不思議に思っていることがあった。ある特定の生成列を覚えさせるなら、そればっかり覚えるようになるんじゃないだろうか？ また、正例・負例で生成したものが決まっているなら、たまたまそれが乱数的に生成されるのが重ならない限り、学習できないのではないか…と。
前者については、温度が高い中でやるから、モデルの「性格」レベルのところに作用して、コピペ的効果が薄いのかな…という印象。
JRF2026/7/33526
Gemini:＞強化学習（RLHF/DPO）では、特定の「正解の文字列」そのものを丸暗記させるのではなく、モデル全体の「出力の傾向（ポリシー）」をじんわりと傾ける操作をしています。これを支える決定的な仕組みが「KLダイバージェンス（KL散乱）ペナルティ」です。＜
JRF2026/7/39130
後者については、生成がすべての単語に対する確率としていったん求められているので、そこから拾えば常に生成列の報酬が求まるということに気付けた。
Gemini:＞「完全に正解の文が出るのを待つ」のではなく、「出力された文の、どの単語の確率を『上げれば』 or 『下げれば』、全体としてマシな出力になったか」という確率の重みの引っ張り合いを、常に全単語の選択肢に対して同時に行っている。
だからこそ、たまたま出た偶然の1回を待つ必要はなく、どんなに打率が低くても「出力されたすべての試行」から効率よく、常に学習を進めることができるわけです。
＜
JRF2026/7/33892
……。
高速化やメモリなどの効率化はモデルを大規模にしようとしたら必ず必要で、LLM はスケーリング則こそ本質だから、大規模化のそういう工夫こそが本丸…というのはわかるのだが、やはり私はモデルの設計…トポロジーを見直せないか…と考えてしまう。その意味では一番参考になったのは最初の CodeBot (その Attention や Transformer)の説明だった。
JRF2026/7/30580
……。
xxLLM については作る自信が消えているが、アイデアはできているので、アイデアの公開だけのためにも、いちおう(簡単な)実験はしてみようと思う。
JRF2026/7/36635
『ゼロから作るDeep Learning 6 - LLM編』(斎藤 康毅 著, オライリー・ジャパン, 2026年6月)
https://www.amazon.co.jp/dp/4814401612
https://7net.omni7.jp/detail/1107710741
サンプルコードは↓
《GitHub - oreilly-japan/deep-learning-from-scratch-6》
https://github.com/oreilly-japan/deep-learning-from-scratch-6
JRF2026/7/34068