Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special tokens have been added in the vocabulary #32

Open
kwalcock opened this issue Jul 26, 2023 · 2 comments
Open

Special tokens have been added in the vocabulary #32

kwalcock opened this issue Jul 26, 2023 · 2 comments

Comments

@kwalcock
Copy link
Member

During manipulating the tokenizers, this error message can appear:

Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
.../convert_slow_tokenizer.py:446: UserWarning: The sentencepiece tokenizer that you are converting to a fast tokenizer uses the byte fallback option which is not implemented in the fast tokenizers. In practice this means that the fast version of the tokenizer can produce unknown tokens whereas the sentencepiece version would have converted these unknown tokens into a sequence of byte tokens matching the original piece of text.
  warnings.warn(
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.

It's somewhat unclear what this means, but a example can illustrate the issue. If the Python tokenizer for microsoft/deberta-v3-bas is run the text of a certain unicode character 䀀, it is tokenized as

['[CLS]', '▁', '[UNK]', '[SEP]']
[1, 507, 3, 2]
-1, 0, 0, -1

There shouldn't be four tokens here, but aside from that, note the [UNK]. The Python version is not able to to do mapping back to the strange character. It goes to the special token that has been added to the vocabulary. The Rust version gets

['[CLS]', '▁', '䀀', '[SEP]']
[1, 507, 3, 2]
-1, 0, 0, -1

so it is able to map back to the original text using the byte fallback option. It doesn't seem like this should affect processors because I think we are keeping the original texts around. The 0 for the word index should refer back to the original word. During training, we're only concerned with the numbers (wordIds), and they match up.

@kwalcock
Copy link
Member Author

kwalcock commented Jul 26, 2023

For a different tokenizer, xlm-roberta-base, it looks like this:

['<s>', '▁', '<unk>', '</s>']
[0, 6, 3, 2]
-1, 0, 0, -1

and

['<s>', '▁', '䀀', '</s>']
[0, 6, 3, 2]
-1, 0, 0, -1

@MihaiSurdeanu
Copy link
Contributor

Thanks @kwalcock ! Unclear to me why the mapping fails in Python... They should access exactly the same token vocabulary, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants