noamaanMulla-03/transformers-issues huggingface dataset:
Extracting Neutral sentiment from Hugginface model
Author: banyous
Pull request: no

Hi, I am using Hugging-face pipeline for the sentiment analysis task, which gives me Positive/Negative sentiment along with a confidence score. In my case, I need three outputs (Positive/Neutral/Negative). The problem is that hugging-face is giving me high confidence score even with neutral sentences (such as : 'He have she has')? Any suggestions? 

    from transformers import pipeline
    model = pipeline(task = 'sentiment-analysis')
    sentence = 'some text to evaluate'
    predicted = model(sentence)
    print(predicted)

Here are some output samples:

    ----------------------------------------------
    sentence = 'I love you'
    predicted = model(sentence)
    predicted
    [{'label': 'POSITIVE', 'score': 0.9998656511306763}]
    ----------------------------------------------
    sentence = 'I hate you'
    predicted = model(sentence)
    predicted
    [{'label': 'NEGATIVE', 'score': 0.9991129040718079}]
    ----------------------------------------------
    sentence = 'I have she had'
    predicted = model(sentence)
    predicted
    [{'label': 'POSITIVE', 'score': 0.9821817874908447}]
    ----------------------------------------------
    sentence = 'I go to work'
    predicted = model(sentence)
    predicted
    [{'label': 'POSITIVE', 'score': 0.9457777738571167}]
    ----------------------------------------------
    sentence = 'This movie was actually neither that funny, nor super witty.'
    predicted = model(sentence)
    predicted
    [{'label': 'NEGATIVE', 'score': 0.9997298121452332}]



Comments:
Hello @banyous! The pipeline can be configured to use any model on the hub that works with this task. If the current model isn't working well for you, I invite you to take a look at the different models on the model hub and select one that fits your use-case: https://huggingface.co/models

Thanks @LysandreJik 

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.
Is there any pre-training example code?
Author: tmchojo
Pull request: no

I want to pre-train BERT with my own data.
[#124](https://github.com/huggingface/pytorch-pretrained-BERT/pull/124), [#170](https://github.com/huggingface/pytorch-pretrained-BERT/issues/170) say the model can pre-training.
But I can't find pre-training example code.
Is there any pre-training example code?
If there is no example code, I wonder [modeling.py](https://github.com/huggingface/pytorch-pretrained-BERT/blob/master/pytorch_pretrained_bert/modeling.py)'s BertForPreTraining is enought to pre-tranining.

Comments:
Hi @tmchojo there are now several detailed examples [here](https://github.com/huggingface/pytorch-pretrained-BERT/tree/master/examples/lm_finetuning) thanks to @Rocketknight1 and #392 

Thanks.
But it still needs pre-trained model.
My data is another domain (not English or Chinese), so I can't use pre-trained model.
Do I have to use [Google's](https://github.com/google-research/bert) to pre-train?

I'm also interested in pre-training. Did you make any progress on this, @tmchojo?

There is an example provided [here](https://huggingface.co/blog/how-to-train) with colab (this is for pre-training from scratch), however, I'm still trying to figure the continual pre-training and not pretraining from scratch (using a pre-trained model as initial checkpoint). 

Hope https://github.com/huggingface/transformers/tree/master/examples/pytorch helps! The language modelling notebook trains  a gpt model. This notebook also gives an idea on labelling the dataset for the LM task.
Function `ByT5Tokenizer.convert_tokens_to_string()` fails with certain tokens
Author: versae
Pull request: no

## Environment info

- `transformers` version: 4.13.0.dev0
- Platform: Linux-5.11.0-37-generic-x86_64-with-glibc2.29
- Python version: 3.8.10
- PyTorch version (GPU?): not installed (NA)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: No
- Using distributed or parallel set-up in script?: No

### Who can help
@patrickvonplaten 

## Information

After fine-tuning `ByT5`, the pipeline for `text2text-generation` fails when certain tokens are predicted and passed to the `ByT5Tokenizer.convert_tokens_to_string()` function.

## To reproduce

Steps to reproduce the behavior:

```python
from transformers import pipeline

generate = pipeline("text2text-generation", model="versae/modernisa-pre")
generate("presuncion")
```

Which produces a string missing some characters:
```
[{'generated_text': 'presuncin'}]
```

## Expected behavior

I would have expected not to miss any of the characters is supposed to generate.

The error seems related to the way tokens are treated. A possible fix could be:

```python
from transformers import ByT5Tokenizer

class FixByT5Tokenizer(ByT5Tokenizer):

    def convert_tokens_to_string(self, tokens):
        """Converts a sequence of tokens (string) in a single string."""
        bstring = b""
        for token in tokens:
            if token in self.special_tokens_decoder:
                tok_string = self.special_tokens_decoder[token].encode("utf-8")
            elif token in self.added_tokens_decoder:
                tok_string = self.special_tokens_decoder[token].encode("utf-8")
            elif token in self.special_tokens_encoder:
                tok_string = token.encode("utf-8")
            elif token in self.added_tokens_encoder:
                tok_string = token.encode("utf-8")
            else:
                tok_string = bytes(token, encoding="utf8")  # bytes([ord(token)])
            bstring += tok_string
        string = bstring.decode("utf-8", errors="ignore")
        return string

generate2 = pipeline("text2text-generation",
    model="versae/modernisa-pre",
    tokenizer=FixByT5Tokenizer("versae/modernisa-pre")
)
generate("presuncion")
```
Which correctly produces:
```
[{'generated_text': 'presunción'}]
```

However, it also makes other tests fail 🤷🏼 



Comments:
Maybe related: https://github.com/huggingface/transformers/issues/13779.

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.
[WIP] DeBERTav2 Fast Tokenizer - fixes #14712
Author: mingboiz
Pull request: yes

# What does this PR do?
Added DeBERTav2Converter for tokenizer of 
- DeBERTav2
- DeBERTav3
- mDeBERTav3

Wish to add a DeBERTav2TokenizerFast classes and test but require guidance on this, thanks!

Fixes # (issue)
#14712 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.

https://github.com/huggingface/transformers/issues/14712
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

@SaulLu @LysandreJik 

 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.


Comments:
Merry xmas! Currently using the Converter to instantize the Fast DebertaV2 Tokenizer from a PreTrainedTokenizerFast serves as a workaround for now, but I'm finding it difficult to write up the DebertaV2TokenizerFast class 
 for `tokenization_deberta_v2_fast.py` such that it wraps the SPMTokenizer class. 

An alternative approach I want to try is where it's based on PreTrainedtokenizerFast instead of SPMTokenizer but I'm not sure how to start putting this together. Would appreciate any guidance, thank you!

Closing this as @alcinos PR is more feature rich than mine, and I would wish to contribute to his efforts on his PR instead, thanks!

Hi @mingboiz , first of all thank you very much for offering to work on this issue! It is very much appreciated. :hugs: 

I'll let you coordinate directly with @alcinos if you want to work together on it? :smile:
Add `ElectraForCausalLM` to enable constructing Electra-based `EncoderDecoderModel`
Author: stancld
Pull request: no

# 🚀 Feature request

Add `ElectraForCausalLM` model to enable constructing `EncoderDecoderModel` based on Electra.

## Motivation

Currently, there are many encoder-only models, such as BERT or RoBERTA, which have already been supported for encoder-decoder settings. Even though Electra is pre-trained in a different fashion, I found out the fine-tuning an Electra2Electra model works as well.
Also, there are publicly available checkpoints for a small configuration of the model and thus one can try to train a model which is an order of magnitude smaller than e.g. Bert2Bert or RoBERTa2RoBERTa.

## Your contribution

I have already prepared an implementation for myself. If there's a desire to add this module I'll be happy to work on the PR. :]

Comments:
Add `ElectraForCausalLM` -> Enable Electra encoder-decoder model
Author: stancld
Pull request: yes

# What does this PR do?

This PR adds `ElectraForCausalLM` and thus enable to use `Electra` model in the encoder-decoder setting.

Fixes #14269


## Before submitting
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

@patrickvonplaten 

**Additional context:** I've already tried to fine-tune Electra model as an encoder-decoder model on our use case and it proved to be working.

Comments:
This looks good to me as well! Regarding the docs, could you try to follow @sgugger 's suggestion [here](https://github.com/huggingface/transformers/pull/13967#issuecomment-999565664) on how to fix it? 

Let me know if you need any help :-)

Merging as failing test has been fixed on master and other failures are unrelated. Thanks a lot for you work @stancld !
Sampling sequences similar to a given sequence
Author: zgerrard
Pull request: no

# 🚀 Feature request

Sampling sequences similar to the previously generated sequence. 

Example: 

A language model produces the following "I went for a walk with my dog". During the next step we request a model to produce a similar sequence. It produces: "He went for a walk with his cat".

## Motivation

Very useful for downstream applications.

## Your contribution

Can review PR and help with implementation.


Comments:
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.
Patrick von Platen
Author: aheirich
Pull request: no

Dear Patrick von Platen
I have some questions about the use of Helsinki-NLP models in commercial projects, can you please contact me by email?  alan.heirich@gmail.com

Sorry to use this issue tracker, I know of no other way to reach Patrick.

Comments:
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.
Add documentation for exporting TorchScript model to accelerator
Author: kct22aws
Pull request: no

# 🚀 Feature request

Add examples about how to trace a TorchScript transformer model and deploy it in an accelerator such as [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/ "Inferentia accelerator"). 

## Motivation
Communicated with @philschmid. HuggingFace transformer models can be traced to TorchScript models and run on accelerators. We would like to help HF transformer users save the cost of deploying and running HF transformer models at scale. We wish to upstream additional documentation showing minimal code updates to deploy traced TorchScript model in an accelerator. 

## Your contribution

Example code snippet to trace and deploy a TorchScript model in an accelerator such as [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/ "Inferentia accelerator")


Comments:
That sounds good! We'd welcome a section about deploying a TorchScript model in AWS Inferentia! Ideally this would be under a new documentation page "deployment". You can take inspiration from either the RST [serialization page](https://github.com/huggingface/transformers/blob/master/docs/source/serialization.rst) or the MD [migration page](https://github.com/huggingface/transformers/blob/master/docs/source/migration.md).

You should then add a link to it in the index [here](https://github.com/huggingface/transformers/blob/master/docs/source/index.rst). Thank you, and let @philschmid or I know if you need any help!

Hi @kct22aws ,

Please let me know if you need any help regarding this as we also have several huggingface and custom models running in AWS inferentia !!

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.
fix to issue #14833 in data_collator - consider no labels
Author: kleinay
Pull request: yes

# What does this PR do?
Fixing `DataCollatorForSeq2Seq.__call__` to not preparing decoder_input_ids when `labels` is None.

Fixes # (issue)
#14833

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

@patil-suraj 



Comments:
Fix duplicate call to save_checkpoint when using deepspeed 
Author: MihaiBalint
Pull request: yes

# What does this PR do?

Drop duplicate call to deepspeed.save_checkpoint(), the trainer.save_model() function already handles that case.

Following this change: https://github.com/huggingface/transformers/pull/14652/files#diff-ed55888e6665791fe92cc8fc0c499da54f4ace6738551cd9a2591881cda076deR1986
The call to save_checkpoint() was duplicated.

I found this issue after seeing the following logs (note the last 4 lines):
```
[INFO|trainer.py:2033] 2021-12-26 19:42:00,421 >> Saving model checkpoint to finetuned-ro-en-dev/checkpoint-2
[INFO|configuration_utils.py:425] 2021-12-26 19:42:00,423 >> Configuration saved in finetuned-ro-en-dev/checkpoint-2/config.json
[INFO|modeling_utils.py:1070] 2021-12-26 19:44:09,064 >> Model weights saved in finetuned-ro-en-dev/checkpoint-2/pytorch_model.bin
[INFO|tokenization_utils_base.py:2043] 2021-12-26 19:44:09,110 >> tokenizer config file saved in finetuned-ro-en-dev/checkpoint-2/tokenizer_config.json
[INFO|tokenization_utils_base.py:2049] 2021-12-26 19:44:09,112 >> Special tokens file saved in finetuned-ro-en-dev/checkpoint-2/special_tokens_map.json
[2021-12-26 19:44:09,596] [INFO] [logging.py:69:log_dist] [Rank 0] Saving model checkpoint: finetuned-ro-en-dev/checkpoint-2/global_step2/mp_rank_00_model_states.pt
[2021-12-26 19:59:09,484] [INFO] [engine.py:2964:_save_zero_checkpoint] zero checkpoint saved finetuned-ro-en-dev/checkpoint-2/global_step2/zero_pp_rank_0_mp_rank_00_optim_states.pt
[2021-12-26 19:59:09,575] [INFO] [logging.py:69:log_dist] [Rank 0] Saving model checkpoint: finetuned-ro-en-dev/checkpoint-2/global_step2/mp_rank_00_model_states.pt
[2021-12-26 20:16:17,005] [INFO] [engine.py:2964:_save_zero_checkpoint] zero checkpoint saved finetuned-ro-en-dev/checkpoint-2/global_step2/zero_pp_rank_0_mp_rank_00_optim_states.pt
```

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?

## Who can review?
- @stas00 @LysandreJik 



Comments:
Closed PR as it was created from the wrong branch

continued in https://github.com/huggingface/transformers/pull/14946
[doc] consistent True/False/None default format
Author: stas00
Pull request: yes

This PR sets True/False/None default format in a consistent manner of backticks.

```
find . -type d -name ".git" -prune -o -type f -exec perl -pi -e 's#\*(True|False|None)\*#`$1`#g' {} \;
```

Fixes: https://github.com/huggingface/transformers/issues/14949

@sgugger 


Comments:
Done
[doc] post-conversion: incosistent "default to"
Author: stas00
Pull request: no

After the conversion we ended up with inconsistent values for `defaults to` - sometimes it's `formatted`, other times it's *italics*, with former being the prevailing form. Example:
```
src/transformers/generation_tf_utils.py:            use_cache: (`bool`, *optional*, defaults to `True`):
src/transformers/generation_tf_utils.py:            output_attentions (`bool`, *optional*, defaults to *False*):
```
but there is a lot more of these

@sgugger 

Comments:
It's not the conversion fault, those were inconsistent before. Meaning some were properly set with an :obj: marker or double backticks while other had simple backticks and were thus converted in italics.

By all means, if you want to do a batch conversion, the proper format is \`False\` (or \`True\`)

Will do,

Also while fixing this I see there are still quite a few `:obj:` leftovers - is it still a WIP?

```
grep -Ir :obj: src
src/transformers/models/t5/modeling_t5.py:            assert self.is_decoder, f":obj:`use_cache` can only be set to `True` if {self} is used as a decoder"
src/transformers/models/tapas/modeling_tapas.py:        input_mask_float (:obj: *torch.FloatTensor* of shape `(batch_size, seq
[...]
```

No. The first example is not a docstring, so not touched by the conversion scripts. The second one seemed to have a space between the :obj: and the \` so was not properly converted (the torch.FloatTensor is not supposed to be in italics).

You should wait a tiny bit more before doing any conversion as I'm in the process of changing lots of docstrings in #14950 (will merge it when it's green).

That was just a small snippet, the full match is 44 lines. should be easy to reproduce.

Please take your time, I was just flagging these in case it was missed.

OK PR is merged!
If you want to hunt down all the remaining :obj:/:class:/:meth:/:func: that would be amazing (and leave me more time to work on #14032 this week :-) )

Sure, once you approve https://github.com/huggingface/transformers/pull/14951 and it is merged to avoid conflicts.

Done. I think there might also be some incomplete :obj or obj: in the wild (saw one on #14951).

So what of all these `:obj:` that are not in the doc string - do we simply remove those?

e.g.:

```
src/transformers/models/t5/modeling_t5.py:            assert self.is_decoder, f":obj:`use_cache` can only be set to `True` if {self} is used as a decoder"
examples/research_projects/quantization-qdqbert/utils_qa.py:        prefix (:obj:`str`, `optional`):
examples/research_projects/deebert/src/modeling_highway_roberta.py:            loss (:obj:`torch.FloatTensor` of shape :obj:`(1,)`, `optional`, returned when :obj:`label` is provided):
```



Yes, we use Markdown style everywhere. Would just not touch the research projects. as I haven't converted the docstrings there.
[doc] :obj: hunt
Author: stas00
Pull request: yes

I think it'd be easier to review if we focus on one type at a time. So this PR is about `obj`:

it catches all the invalid `:obj:` versions, reformats the next field as if they were normal and then removes them all.

```
find . -type d -name ".git" -prune -o -type f -exec perl -pi -e 's#:?obj: ?\*([^\*]+)\*#`$1`#g' {} \;
find . -type d -name ".git" -prune -o -type f -exec perl -pi -e 's#:?obj: ?##g' {} \;
git checkout utils/check_repo.py src/transformers/tokenization_utils_base.py src/transformers/models/marian/convert_marian_tatoeba_to_pytorch.py
git checkout examples
make fixup
```
mods reset for `research_projects` as requested, but it should be easy to replay these later.

@sgugger

Comments:
Redone w/o examples and utils
Doc styler examples
Author: sgugger
Pull request: yes

# What does this PR do?

Last bit of the new style-doc script, blackify all code examples which:
- insures they don't have bacis Python errors
- are on par with our usual code format

This PR fixes a few code examples mistakes (see first commit for the docstrings and [this commit](https://github.com/huggingface/transformers/pull/14953/commits/999b9fd9f4a00da10353b6b95a4c842d0153da0b) for the MDX files) that were identified by black not being happy. Only code samples marked with `py` or `python` are blackified, so it's easy to turn off this feature if it becomes too annoying on some docstrings.

Comments:
Cool! Good to merge for me once all tests pass