役立つ情報満載！カルパシーの2時間AIコースの最初のエピソードはテキスト形式で提供されます。新しいワークフローは、ビデオを自動的に記事に変換します。

少し前に、AIマスターのKarpathyが立ち上げたAIコースは、ネットワーク全体で15万回の視聴を獲得しました。

当時、一部のネットユーザーは、この2時間の講座の価値は大学4年間分に相当すると発言した。

ここ数日、カルパシーは新たなアイデアを思いつきました。

つまり、「GPT トークン セグメンターをゼロから構築する」という 2 時間 13 分のビデオを、「トークンのセグメンテーション」について具体的に説明する本の章 (またはブログ投稿) に変換します。

具体的な手順は次のとおりです。

- 動画に字幕やキャプションを追加します。

- ビデオを画像とテキストを添えてセグメントに分割します。

- 大規模言語モデルのヒントエンジニアリング技術を使用して段落ごとに翻訳します。

- 結果を、元のビデオの一部へのリンクを含む Web ページとして出力します。

もっと広い意味では、このようなワークフローはあらゆるビデオ入力に適用でき、読みやすく、閲覧しやすく、検索しやすい形式でチュートリアル用の「コンパニオン ガイド」のようなものを自動的に生成できます。

これは実現可能ではあるが、困難でもある。

彼は自分の想像力を説明するために、GitHub プロジェクト minbpe で例を書きました。

アドレス: https://github.com/karpathy/minbpe/blob/master/lecture.md

カルパシー氏は、これはビデオを見て、それをマークダウン形式で記事に翻訳するという、手作業で完了した作業だったと語った。

「ビデオはまだ4分ほどしか見ていません（つまり、3％完了）。これを書くのに30分ほどかかっています。このような作業が自動で行われるようになれば素晴らしいと思います。」

次は授業の時間です！

LLM 単語分割コース テキスト版

みなさんこんにちは。今日は、LLM における「単語分割」の問題について議論します。

残念ながら、単語の分割は、最も高度な大規模モデルの中でも比較的複雑で扱いにくいコンポーネントですが、詳細に理解する必要があります。

LLM の欠陥の多くはニューラル ネットワークやその他の一見不可解な要因に起因するものですが、これらの欠陥は実際には「単語の分割」にまで遡ることができます。

文字レベルのトークン化

では、分詞とは何でしょうか?

実際、前回のビデオ「GPT をゼロから構築しましょう」で単語のセグメンテーションを紹介しましたが、それは非常に単純な文字レベルのバージョンでした。

Google Colab にアクセスしてそのビデオを確認すると、トレーニング データ (Shakespeare) から開始していることがわかります。これは、Python で記述された大きな文字列です。

 First Citizen: Before we proceed any further, hear me speak. All: Speak, speak. First Citizen: You are all resolved rather to die than to famish? All: Resolved. resolved. First Citizen: First, you know Caius Marcius is chief enemy to the people. All: We know't, we know't.

しかし、LLM に文字列を入力するにはどうすればよいでしょうか?

まず、トレーニング セット全体のすべての可能な文字の語彙を構築する必要があることがわかります。

 # here are all the unique characters that occur in this text chars = sorted(list(set(text))) vocab_size = len(chars) print(''.join(chars)) print(vocab_size) # !$&',-.3:;?ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz # 65

次に、上記の語彙に基づいて、単一の文字と整数を変換するための参照テーブルを作成します。このルックアップ テーブルは単なる Python 辞書です。

 stoi = { ch:i for i,ch in enumerate(chars) } itos = { i:ch for i,ch in enumerate(chars) } # encoder: take a string, output a list of integers encode = lambda s: [stoi[c] for c in s] # decoder: take a list of integers, output a string decode = lambda l: ''.join([itos[i] for i in l]) print(encode("hii there")) print(decode(encode("hii there"))) # [46, 47, 47, 1, 58, 46, 43, 56, 43] # hii there

文字列を整数のシーケンスに変換すると、各整数がトレーニング可能なパラメータの 2D 埋め込みのインデックスとして使用されることがわかります。

語彙サイズは vocab_size=65 なので、この埋め込みテーブルにも 65 行が含まれます。

 class BigramLanguageModel(nn.Module): def __init__(self, vocab_size): super().__init__() self.token_embedding_table = nn.Embedding(vocab_size, n_embd) def forward(self, idx, targets=None): tok_emb = self.token_embedding_table(idx) # (B,T,C)

ここで、整数は、単語を表すベクトルである埋め込みテーブルから行を「取得」します。このベクトルは、対応するタイム ステップの入力として Transformer に送られます。

「文字ブロック」セグメンテーションにBPEアルゴリズムを使用する

これは、「文字レベル」の言語モデルの単純な設定にはすべて当てはまります。

しかし実際には、最先端の言語モデルでは、より複雑なスキームを使用してこれらの表現語彙を構築します。

具体的には、これらのスキームは文字レベルではなく、「文字ブロック」レベルで機能します。これらのチャンク語彙は、バイトペアエンコーディング (BPE) などのアルゴリズムを使用して構築されます。これについては、後で詳しく説明します。

この手法の歴史的発展を振り返ってみましょう。バイトレベルのBPEアルゴリズムを言語モデルのセグメンテーションに使用した論文は、2019年にOpenAIが発表したGPT-2論文「Language Models are Unsupervised Multitask Learners」です。

論文アドレス: https://d4mucfpksywv.cloudfront.net/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

セクション 2.2「入力表現」に目を通すと、このアルゴリズムの説明と目的が説明されています。このセクションの最後には、次のように書かれています。

語彙は50,257語にまで拡大しました。また、コンテキスト サイズを 512 トークンから 1024 トークンに増やし、より大きなバッチ サイズ 512 を使用します。

Transformer の注意層では、各トークンはシーケンス内の前のトークンの有限リストに関連付けられていることを思い出してください。

この論文では、GPT-2 モデルのコンテキスト長が GPT-1 の 512 トークンから 1024 トークンに増加したことを指摘しています。

言い換えれば、トークンは LLM の入力における基本的な「原子」です。

「単語分割」とは、Python の生の文字列をトークン リストに変換するプロセス、およびその逆のプロセスです。

この抽象化の普遍性を示すもう 1 つの一般的な例として、Llama 2 の論文で「token」を検索すると、63 件の一致が見つかります。

例えば、論文では 2 兆個のトークンでトレーニングしたなどと主張しています。

論文アドレス: https://arxiv.org/pdf/2307.09288.pdf

単語分割の複雑さについての簡単な説明

実装の詳細に入る前に、単語分割プロセスを詳細に理解する必要性について簡単に説明しましょう。

トークン化は LLM における数多くの奇妙な問題の中心にあるため、これを無視しないことをお勧めします。

ニューラル ネットワーク アーキテクチャに関連していると思われる多くの問題は、実際には単語の分割に関連しています。以下にいくつかの例を挙げます。

- LLM はなぜ単語を綴ることができないのですか? - 分詞

- LLM はなぜ、文字列の反転などの非常に単純な文字列処理タスクを実行できないのでしょうか? - 分詞

- LLM はなぜ英語以外の言語 (日本語など) でのタスクが苦手なのでしょうか? - 分詞

- なぜLLMは簡単な算数が苦手なのでしょうか？ - 分詞

GPT-2 を Python でコーディングすると、なぜ問題が多くなったのでしょうか? - 分詞

- 文字列 <|endoftext|> を検出すると、LLM が突然停止するのはなぜですか? - 分詞

- 「末尾の空白」に関するこの奇妙な警告は何ですか? - 分詞

- SolidGoldMagikarp について LLM に質問すると、なぜクラッシュするのでしょうか? - 分詞

- LLM では JSON ではなく YAML を使用する必要があるのはなぜですか? - 分詞

- LLM が真のエンドツーエンドの言語モデリングではないのはなぜですか? - 分詞

これらの質問については、ビデオの最後で再度取り上げます。

単語分割の視覚的なプレビュー

次に、単語分割 WebApp を読み込みます。

アドレス: https://tiktokenizer.vercel.app/

この Web アプリの優れた点は、トークン化が Web ブラウザーでリアルタイムに実行されるため、入力にテキスト文字列を簡単に入力して、右側にトークン化の結果を表示できることです。

上部を見ると、現在 gpt2 トークナイザーを使用していることがわかります。また、この例で貼り付けられた文字列が現在 300 個のトークンにトークン化されていることがわかります。

ここでは色で明確に示されています:

たとえば、文字列「Tokenization」は token30642 にエンコードされ、その後に token 1634 が続きます。

トークン「is」（先頭のスペースを含めて 3 文字なので重要です）は 318 です。

スペースは文字列内に必ず存在するため、他のすべての文字とともに単語分割する必要があるため、スペースの使用に注意してください。しかし、わかりやすくするために、視覚化では省略されることがよくあります。

アプリの下部で視覚化のオン/オフを切り替えることができます。同様に、トークン「at」は 379、「the」は 262 などとなります。

次に、簡単な算術の例を示します。

ここで、トークナイザーが数値を一貫性なく分解できることがわかります。たとえば、数字 127 は 3 文字のトークンですが、数字 677 は 2 文字のトークン (6 (先頭のスペースに注意) と 77) です。

この恣意性を説明するために、LLM に依存します。

内部パラメータとトレーニング中の両方で、これら 2 つのトークン (6 と 77 が実際に組み合わさって 677 という数字が形成される) を理解する必要があります。

もう一度言いますが、LLM がこの合計の結果が 804 であると予測したい場合、2 つの時間ステップでそれを出力する必要があることがわかります。

まずトークン「8」を発行し、次にトークン「04」を発行する必要があります。

これらの分割はすべて完全に恣意的であるように見えることに注意してください。次の例では、1275 は「12」と「75」、6773 は実際には 3 つのトークン「6」、「77」、「3」、8041 は「8」、「041」であることがわかります。

（つづく...）

(TODO: ビデオからテキストを自動的に生成する方法がわからない限り、テキスト バージョンを続行します)

ネットユーザーはオンラインでアドバイスを提供している

ネットユーザーたちは「それは素晴らしい。私は実際に動画を見るよりもこうした投稿を読む方が好きで、自分のペースをコントロールしやすい」とコメントした。

ネットユーザーの中にはカルパシーにアドバイスする人もいる。

「難しそうに感じますが、LangChain を使えば実現できるかもしれません。ウィスパー トランスクリプションを使用して、明確な章がある高レベルのアウトラインを作成し、これらの章ブロックを並列処理して、全体のアウトラインのコンテキストで各章ブロックの特定のコンテンツに焦点を当てる (並列処理された各章の図も生成する) ことができるのではないかと思います。次に、生成されたすべての参照マーカーを LLM を通じて記事の最後にコンパイルします。」

誰かがこれ用のパイプラインも作成しており、まもなくオープンソース化される予定です。