Roberta python Tokenizer encodes differently across transformers==2.11 and transformers==4.0.1
## Environment info
<!-- You can run the command `transformers-cli env` and copy-and-paste its output below.
     Don't forget to fill out the missing fields in that output! -->
     
- `transformers` version: 2.11 vs 4.0.1
- Platform: Any
- Python version: 3.8.3
- PyTorch version (GPU?): Any
- Tensorflow version (GPU?):
- Using GPU in script?:
- Using distributed or parallel set-up in script?:

### Who can help
<!-- Your issue will be replied to more quickly if you can figure out the right person to tag with @
 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.
  albert, bert, GPT2, XLM: @LysandreJik 
 tokenizers: @mfuntowicz
 Trainer: @sgugger
 Speed and Memory Benchmarks: @patrickvonplaten
 Model Cards: @julien-c
 TextGeneration: @TevenLeScao 
 examples/distillation: @VictorSanh
 nlp datasets: [different repo](https://github.com/huggingface/nlp)
 rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)
 Text Generation: @patrickvonplaten @TevenLeScao
 Blenderbot: @patrickvonplaten
 Bart: @patrickvonplaten
 Marian: @patrickvonplaten
 Pegasus: @patrickvonplaten
 mBART: @patrickvonplaten
 T5: @patrickvonplaten
 Longformer/Reformer: @patrickvonplaten
 TransfoXL/XLNet: @TevenLeScao
 RAG: @patrickvonplaten, @lhoestq
 FSMT: @stas00
 examples/seq2seq: @patil-suraj
 examples/bert-loses-patience: @JetRunner
 tensorflow: @jplu
 examples/token-classification: @stefan-it
 documentation: @sgugger
 -->
@mfuntowicz
## Information

I am attaching two samples below. In short, the word "suicide" gets encoded with different tokens across 2 different transformers versions. This leads to the same finetuned model behaving differently if using different transformers versions. Which is alarming in a sense.

![2_11](https://user-images.githubusercontent.com/22024955/102495115-5f11ef80-407e-11eb-8478-888f6a6ecf15.png)
![4](https://user-images.githubusercontent.com/22024955/102495118-60431c80-407e-11eb-9af8-1748894621c9.png)


Model I am using (Bert, XLNet ...): Roberta-base

The problem arises when using:
* [ ] the official example scripts: (give details below)
* [ ] my own modified scripts: (give details below)

The tasks I am working on is:
* [ ] an official GLUE/SQUaD task: (give the name)
* [ ] my own task or dataset: (give details below)

## To reproduce

Steps to reproduce the behavior:
Run the following code with transformers==2.11 and 4.0.1
`from transformers import AutoTokenizer`

`tokenizer = AutoTokenizer.from_pretrained('roberta-base', use_fast=False)`

`tokenizer.encode(' suicide ')`

`tokenizer.encode('suicide')`

`tokenizer.encode(' suicide')`


<!-- If you have code snippets, error messages, stack traces please provide them here as well.
     Important! Use code tags to correctly format your code. See https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks#syntax-highlighting
     Do not use screenshots, as they are hard to read and (more importantly) don't allow others to copy-and-paste your code.-->

## Expected behavior
A tokenizer for the same pretrained model, should tokenize words identically.
<!-- A clear and concise description of what you would expect to happen. -->

Hi, note that 'suicide' and ' suicide' are indeed different tokens with respect to SentencePieces, which is used by Roberta.

SentencePieces keeps white space intact. So we expect different tokens from 'suicide' and ' suicide'. 

I assume in the old transformers 2.x, strip was applied in the tokenizer before it was passed to SentencePiece, which is incorrect. <|||||>Thank you for letting me know. Regardless, the above creates some pretty big inconsistency issues and for example I end up with a model trained with 2.x, when used to predict in an env with transformers >= 3.x to have major discrepancy in predicting accuracy.
This should be at least flagged somewhere and there should be some "backward compatibility" option here.<|||||>You could call `text.strip()` before passing it to the tokenizer. <|||||>Sorry, just to clarify. This doesn't have to do on how I can personally solve my issue with a hack. Of course I can do that or simply use the same transformers version when training/predicting. 
This has to do on how a production system might get affected by this, in my view, major discrepancy. Tokenization behaviour shouldn't change "silently" across versions.
Think of the following case: a product trained to do sentence similarity. The model is trained to understand similarity of sentences, thus tokens. Now if you happily change tokenization across versions, you end up with a model that won't work properly when you upgrade transformers library. That should not happen, or at least get flagged somewhere.<|||||>The old tokenization was buggy and incorrect (based on the info here). I don't see a point to add an option to enable back buggy / incorrect behavior of a component. That would be quite bad to have flags that re-enable all kind of buggy behavior you had in old versions. 

If you need stable results in production then there is no other way than to stay at one version or otherwise have sufficient tests to ensure the functionality of your system when you upgrade your framework. 

It is the same with every framework, that between major versions that there can be significant changes that can impact your software. 

(Just my personal opinion, I don't work for huggingface. I don't know if the bug in the old tokenizer was known and fixed (then it is likely mentioned in the release notes) or if the fix was just a by product by some other commit.)


It appears to be fixed here
https://github.com/huggingface/transformers/pull/5287

And was mentioned in the subsequent release <|||||>Thank you this slipped my attention, it was nevertheless a pretty significant issue. Apparently it's connected to that: https://github.com/huggingface/transformers/issues/5256
I guess this should be expected with a framewrok developing so quickly!<|||||>@ypapanik I am a bit surprised that it makes such a big difference for your use case. You wouldn't expect this as the only difference is a potential white space at the beginning of the text.

My roberta models changed performance in downstream tasks only slightly between the old tokenizer and the newer tokenizer (performance improved like 0.1 percentage points actually).