Understanding GPT tokenizers • Hacker News Board

Re: Understanding GPT tokenizers

#31

Post by pmoriarty » Thu, Jun 08, 2023, 10:29 PM UTC

gwern wrote: post #11

Worth mentioning the many other consequences of BPE tokenization: gwern.net/gpt-3#bpes https://www.lesswrong.com/posts/t9svvNPNmFf5Qa3TA/mysteries-...

In the article on your blog, you wrote:

"GPT-3 rhymes reasonably well and often when appropriate, but the improvement is much smaller on rhyming than it is on pretty much everything else. Apparently it is easier for GPT-3 to learn things like arithmetic and spreadsheets than it is to learn how to rhyme."

I've experimented extensively with Claude, and a bit with Claude+, ChatGPT (GPT 3.5) and GPT4 on poe.com, and I've had not the slightest problem in getting them to rhyme. However, once they've started writing rhyming poetry it's hard to get them to stop rhyming. They seem to have formed a strong association between rhyming and poetry. I've also been unable to get them to obey a specific rhyming scheme like ABBAB.

Re: Understanding GPT tokenizers

#32

Post by sandinmyjoints » Thu, Jun 08, 2023, 10:29 PM UTC

api wrote: post #29

Has anyone ever tried a GPT trained on, say, 256 tokens representing bytes in a byte stream or even more simply binary digits? I imagine there are efficiency trade-offs but I just wonder if it works at all.

Not a GPT, but I think Megabyte does that.

Re: Understanding GPT tokenizers

#33

Post by bpiche » Thu, Jun 08, 2023, 10:29 PM UTC

jcims wrote: post #7

I really really wish someone would try tokenizing off of a phonetic representation rather than textual one. I think it would be interesting to compare the output

spacy's sense2vec gets pretty close to that

https://spacy.io/universe/project/sense2vec/

granted, it is 8 years old, but it's still interesting

Re: Understanding GPT tokenizers

#34

Post by binarymax » Thu, Jun 08, 2023, 10:32 PM UTC

throwaway2016a wrote: post #30

Pardon the n00b question, but... How does this relate to vectors? It was my understanding that the tokens were vectors and this seems to show them as an integer. It's probably a really obvious question to anyone who knows AI but I figured if I have it someone else does too.

Very basic overview: A token is assigned a number, that number gets passed into the encoder model with other token numbers, and the encoder model transforms those number sequences into embeddings (vectors)

Re: Understanding GPT tokenizers

#35

Post by nighthawk454 » Thu, Jun 08, 2023, 10:43 PM UTC

throwaway2016a wrote: post #30

Pardon the n00b question, but... How does this relate to vectors? It was my understanding that the tokens were vectors and this seems to show them as an integer. It's probably a really obvious question to anyone who knows AI but I figured if I have it someone else does too.

The tokens are an integer. The first layer of the model is an 'embedding', which is essentially a giant lookup table. So if a string gets tokenized to Token #3, that means get the vector in row 3 of the embedding table. (Those vectors are learned during model training.)

More completely, you can think of the integers as being implicitly a one-hot vector encoding. So say you have a vocab size of 20,000 and you want Token #3. The one-hot vector would be a 20,000 length vector of zeros with a one in position 3. This vector is then multiplied against the embedding table/matrix. Although in practice this is equivalent to just selecting one row directly, so it's implemented as such and there's no reason to explicitly make the large one-hot vectors.

Re: Understanding GPT tokenizers

#36

Post by burnished » Thu, Jun 08, 2023, 10:45 PM UTC

pmoriarty wrote: post #31

gwern wrote: post #11

Worth mentioning the many other consequences of BPE tokenization: gwern.net/gpt-3#bpes https://www.lesswrong.com/posts/t9svvNPNmFf5Qa3TA/mysteries-...

In the article on your blog, you wrote: "GPT-3 rhymes reasonably well and often when appropriate, but the improvement is much smaller on rhyming than it is on pretty much everything else. Apparently it is easier for GPT-3 to learn things like arithmetic and spreadsheets than it is to learn how to rhyme." I've experimented extensively with Claude, and a bit with Claude+, ChatGPT (GPT 3.5) and GPT4 on poe.com, and I've…

That seems incredibly challenging, I'd expect some fundamental difficulty due to rhyming being determined by how a word sounds and not what it means.

Re: Understanding GPT tokenizers

#37

Post by z3c0 » Thu, Jun 08, 2023, 10:48 PM UTC

throwaway2016a wrote: post #30

Pardon the n00b question, but... How does this relate to vectors? It was my understanding that the tokens were vectors and this seems to show them as an integer. It's probably a really obvious question to anyone who knows AI but I figured if I have it someone else does too.

The integers represent a position within a vector of "all known tokens". Typically, following a simple bag-of-words approach, each position in the vector would be toggled to 1 or 0 based on the presence of a token in a given document. Since most vectors would be almost completely zeroed, the simpler way to represent these vectors is through a list of positions in the now abstracted vector, aka a sparse vector, ie a list of integers.

In the case of more advanced language models like LLMs, a given token can be paired with many other features of the token (such as dependencies or parts-of-speech) to make an integer represent one of many permutations on the same word based on its usage.

Re: Understanding GPT tokenizers

#38

Post by TechBro8615 » Thu, Jun 08, 2023, 10:49 PM UTC

Kudos to simonw for all the LLM content you've been publishing. I like reading your perspective and notes on your own learning experiences.

Re: Understanding GPT tokenizers

#39

Post by jiggawatts » Thu, Jun 08, 2023, 10:51 PM UTC

simonw wrote: post #19

bluepoint wrote: post #17

So the space character is part of the token?

Yup. Most common words have several tokens - the word, the word with a capital letter, the word with a leading space and sometimes the word all in caps too. Try searching for different words using the search box here: https://observablehq.com/@simonw/gpt-tokenizer#cell-135

I wonder if the embeddings could be explicitly configured to account for these “symmetries”. E.g.: instead of storing seperate full copies of the “variants”, maybe keep a reduced representation with a common prefix and only a small subset of the embedding vector that is allowed to be learned?

This could force the model to correctly learn how to capitalise, make all-caps, etc…

Re: Understanding GPT tokenizers

#40

Post by SkyPuncher » Thu, Jun 08, 2023, 11:03 PM UTC

whimsicalism wrote: post #20

SkyPuncher wrote: post #18

Earlier quoted context omitted.

Tokens are the primitives that most LLMs (and broadly a lot of NLP) works with. While, you and I would expect whole-words to be tokens, many tokens are shorter - 3 to 4 characters - and don't always match the sentence structure you and I expect. This can create some interesting challenges and unexpected behavior. It also makes certain things, like vectorization, a challenge since tokens may not map 1:1 with the words…

You are using the word vectorization in an idiosyncratic way, you are referring to the process of embedding words?

Because I’m not an expert in this area. I know it well enough to build products around it, but it’s not my deep area of expertise.

Just trying to provide an example.