> Give me a five letter word, beginning with e, and having third letter be t. Not including I, l, u or h.
>> etchy
> Does etchy contain h?
>> No, etchy does not contain h.
> which letters do etchy contain?
>> Etchy contains the letters e, t, c, h, and y.
> what were the criteria?
>> The criteria specified that the word must have five letters, begin with e, and have the third letter be t. The word was not allowed to include the letters i, l, u, or h.
> Does the word etchy meet the criteria?
>> Yes, the word etchy meets the criteria because it has five letters, begins with e, has the third letter be t, and does not include the letters i, l, u, or h.
Ed: note that insists that the third letter of etchy is t, not c. From what I've seen both of these errors are typical.
I have noticed that it struggles with ordinality and cardinality, which might be part of what's going wrong here.
But the other issue with this type of interaction is that once it makes a mistake (claiming etchy meets the criteria), it has a tendency to double down on it and go crazy inventing the reasoning for why.
That's because it's mistake gets baked into the input window and becomes a very strong influence over the output. In this case, you probably would have gotten completely different answers if you informed it etchy was an incorrect answer before asking why it got the answer.
"Enter is a five letter word beginning with e and having t as the third letter."
Try again.
"Ether is a five-letter word that begins with e, has t as its third letter, and does not include the letters i, l, u, or h. It is a colorless, highly volatile, and flammable liquid that is used as a solvent, especially for gases."
Try again.
"Emit is a five letter word that begins with e and has the third letter t. It means to give off or produce (something, especially a gas or sound)."
So it was correct only the first time.
"Print each letter of the word "Artificial intelligence" on a new line. Each line should contain a single letter."
But the following doesn't:
"Print the ROT13 encoding of each letter of the word "Artificial intelligence" on a new line. Each line should contain a single letter."
So it gets hung up specifically on ROT13.
Prompt: Print each letter of the word "Artificial intelligence" on a new line. Each line should contain a single letter.
ChatGPT: [prints "Artificial intelligence", each letter on its own line]
Prompt: Awesome! Now do ROT-13 for each letter.
ChatGPT: ROT-13 is a simple substitution cipher that replaces a letter with the letter 13 letters after it in the alphabet. For example, A becomes N and B becomes O. Since the alphabet has only 26 letters, when we reach the end of the alphabet we simply wrap around to the beginning.
To perform ROT-13 on each letter of "Artificial intelligence", we would do the following:
A becomes N r becomes e t becomes g i becomes v f becomes s i becomes v c becomes p i becomes v a becomes n l becomes y
i becomes v n becomes a t becomes g e becomes r l becomes y l becomes y i becomes v g becomes l e becomes r n becomes a c becomes p e becomes r
So the resulting string would be "Nvevpngvnyvgryvra".
---
So letter by letter, is almost nailed it (except it encoded g as y instead of t), but then horribly failed joining back in (it says Airicatialitelien). I've tried it a couple more times and it seems crucial that it prints input letters (otherwise it becomes distracted and prints nonsense), but it absolutely can't join it back:
Prompt: Awesome! Now do ROT-13 for each letter. Print each letter of input, then ->, then the ROT-13 for that letter.
ChatGPT: [... produces mostly correct output]
Prompt: Now join that back in.
ChatGPT: Artificial intelligence -> Nvgvpnyyl ynathntrzrag
---
(That's “Aitically languagement”)
UPD: Here's another one: https://u.ale.sh/Nrtevfvpv.png
When I ask it to reverse your string, it fails miserably:
> Write the words "Artificial Intelligence" backwards
>
> eecneiretxe laitinumretA
Interestingly, it cannot produce text with the order or characters reversed or guess that's what is going on. And if you explain it, it's able to produce code that would reverse the characters but is still not able to apply it for long sentences.
This isn’t actually true, and is a persistent myth. Or rather, you should back up the claims with evidence.
It’s a bit like saying that you perform poorly on character manipulation tasks because you don’t read individual letters.
Biology analogies aside, I haven’t seen anything to suggest that utf8 level tokenization causes a significant decrease in perplexity across large datasets. (Note that the “large dataset” criteria is required. It’s certainly possible to demonstrate improvements in restricted cases, but no one is really interested in the restricted case unless you have a very specialized task. In which case, sure, specializations make sense — ChessGPT being an obvious example where tokenization just harms learning.)
So the tradeoff isn’t the large context window, but rather the desire to have a deep understanding of a massive amount of data. Specialized models will always have a place as a small component of the whole, but suggesting that this is a problem solved by superior architectures seems a little bit of a stretch.
I think what’s going on here is that OpenAI spent a lot of time giving feedback to their model about specific use cases, and ROT-13 was obscure enough (both in usage and in the data) that its performance is limited. I’d bet that if OpenAI did a few rounds of RL on this objective, the model would perform as well as its cousins.
The analogy doesn’t hold because while you might not parse specific characters by default, you are trained on the character level and you can switch to that parsing mode. This simply is not possible for LLMs without hacks like inserting spaces, which then suffers from poor performance due to this being rare in pretraining.
The reason byte level models aren’t as popular is because inference speed is significantly slower for a given completion length, and training for the same context window in characters is significantly more expensive
I say this as someone who’s deployed ByT5 vs normal T5 in prod, having found this to be true in real world use cases. No reasonable amount of fine tuning can save GPT from performing poorly on a space insertion task (“WHOLEFDSMKT” -> “Whole Foods Market”), while ByT5 just works.
I don’t know why people feel so strongly that the tokenization is a weakness, but ultimately there’s not much choice but to agree to disagree.
Agree that tokenization isn’t a weakness for most general applications, disagree that it isn’t a weakness for the specific string manipulation task that the blog post is referencing
How about the reply posted 5 minutes before yours. Appears like pretty good evidence.
https://news.ycombinator.com/item?id=33915690 even points out a counterexample demonstrating that it can do character level tasks just fine.
It did not go well: https://imgur.com/a/5g2e9Ld
.-""""""-.
/ /|
/ / |
/ / |
/ / |
/ / |
/________/ |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
|________| /
| | /
| | /
| | /
| |/
'_______'
Still not a banana, but it's certainly ascii artWe have AIs that are good at System 2 thinking, that is, symbolic AI. But they don't do System 1 thinking at all. We haven't managed to integrate the two meaningfully and I don't think anyone has a clue how to do it. It's not enough to just have the ML-based system make calls into a symbolic AI when it needs to do reasoning, that's like you have a child who doesn't know how to multiply, so you give them a calculator and declare "this child now knows how to multiply".
This is a solved problem with models trained on byte-level objectives without tokenization like ByT5 (if you tried this task on one of those, it would probably work perfectly with a few samples). In GPT’s case, there’s a trade off between having a long context window vs being good at character level tasks, and OpenAI picked the former.