Browse videos
Let's build the GPT Tokenizer
Study materials
Materials for this selected video are in preparation. Watch the video and use the public learning guide while they are being prepared.
Slides are a PPT outline, not a finished slide deck.
Overview
Andrej Karpathy builds the GPT tokenizer from scratch, implementing byte pair encoding along with encode and decode. He shows how many odd LLM behaviors trace back to tokenization, and covers Unicode byte encodings along the way.
Why HN discusses it
Recommended as the best deep dive on tokenizers, worth the two hours for anyone working with LLMs.
Before you watch
Basic Python and an understanding of how language models consume token sequences will help. This is a focused branch for learners curious about the representation of text.
A way to study this video
Try encoding a short phrase, punctuation and non-English text. Compare the token boundaries and explain why character counts and token counts differ before returning to a model-building lesson.
Follow the Andrej Karpathy learning guide · Original Zero to Hero course
LLMs & generative AI · Computer vision, speech & NLP · Machine learning & deep learning
Newest first
In discussion: UTF-8 is a brilliant design
Karpathy's "Let's build the GPT Tokenizer" also contains a good introduction to Unicode byte encodings, ASCII, UTF-8, UTF-16, UTF-32 in the first 20 minutes: [VIDEO]
In discussion: Why Does Claude Speak Byzantine Music Notation?
Andrej Karpathy goes into quite some depth about how tokenization works here: [VIDEO] tl;dr many of the LLMs use byte-pair encoding to create tokens. You take a set of documents, and then form tokens by repeatedly merging the most common pair of tokens. The initial set of tokens is 256 raw bytes. And the text is typically represented in utf-8. I expect that although the LLMs can understand arbitrarily but cleanly…Andrej Karpathy goes into quite some depth about how tokenization works here: [VIDEO] tl;dr many of the LLMs use byte-pair encoding to create tokens. You take a set of documents, and then form tokens by repeatedly merging the most common pair of tokens. The initial set of tokens is 256 raw bytes. And the text is typically represented in utf-8. I expect that although the LLMs can understand arbitrarily but cleanly offset unicode code points by (eventually) noticing the final byte of each sequence, they would do markedly worse on actually processing and completing on them, because they will not have been reduced to the normal set of tokens. However, if the text is actually output cleanly converted, either in internal thinking tokens or in the beginning of the response, they should do fine. Understanding tokenization is surprisingly useful, even if that video seems awfully long to devote to such a tedious subject. Even Karpathy doesn't like it!
In discussion: Probably pay attention to tokenizers
I finally understood the weirdness of tokenizers after watching the video Andrej Karpathy made: "Let's build the GPT Tokenizer" ( [VIDEO] ). He goes through why we need them instead of raw byte sequences (too expensive) and how the Byte Pair Encoding algorithm works. Worth spending 2h for the deeper understanding if you deal with LLMs.
In discussion: Artificial intelligence is losing hype
This is just an artefact of tokenisation though. The model simply isn’t ever shown the letters that make up words, unless they are spelled out explicitly. It sees tokens representing groups of words. This is a little like saying a human isn’t intelligent because they couldn’t answer your question that you asked in an ultrasonic wavelength. If you’d like to learn more this video is a great resource: [VIDEO]
In discussion: Notebooks Are McDonalds of Code
If there are complaints about code quality in a jupyter notebook, chances are that someone is doing it wrong -- either the author is using it for demonstration purpose, for production or near production environment, or the person looking at others' notebooks is taking them too seriously. Most code in jupyter notebook is bad, but that's fine, because nobody should waste time doing that unless they must reproduce the…If there are complaints about code quality in a jupyter notebook, chances are that someone is doing it wrong -- either the author is using it for demonstration purpose, for production or near production environment, or the person looking at others' notebooks is taking them too seriously. Most code in jupyter notebook is bad, but that's fine, because nobody should waste time doing that unless they must reproduce the results or they are sharing the notebook with others. Notable example of high quality notebook: [VIDEO]
Showing 5 of 8 comments