[RAG] Propagating of n_docs as parameter to all RagModel's related functions
Author: lalitpagaria
Pull request: yes



# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

Fixes #7874


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dimiss 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 the 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?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors which may be interested in your PR.

<!-- Your PR 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, XLM: @LysandreJik 
 GPT2: @LysandreJik, @patrickvonplaten
 tokenizers: @mfuntowicz
 Trainer: @sgugger
 Benchmarks: @patrickvonplaten
 Model Cards: @julien-c
 Translation: @sshleifer
 Summarization: @sshleifer
 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, Bart, Marian, Pegasus: @sshleifer
 T5: @patrickvonplaten
 Rag: @patrickvonplaten, @lhoestq
 EncoderDecoder: @patrickvonplaten
 Longformer, Reformer: @patrickvonplaten
 TransfoXL, XLNet: @TevenLeScao, @patrickvonplaten
 examples/seq2seq: @sshleifer
 examples/bert-loses-patience: @JetRunner
 tensorflow: @jplu
 examples/token-classification: @stefan-it
 documentation: @sgugger
 -->
@patrickvonplaten

Comments:
@lhoestq would be great if you can review as well

@patrickvonplaten Thanks for the review.

while working on this PR I found that in `RagTokenForGeneration` we are computing `batch_size` as follows -
```
batch_size = context_input_ids.shape[0] // n_docs
```
So still issue can come when `((context_input_ids.shape[0] % n_docs) != 0)`, but I can't think of solution to address this.

> @patrickvonplaten Thanks for the review.
> 
> while working on this PR I found that in `RagTokenForGeneration` we are computing `batch_size` as follows -
> 
> ```
> batch_size = context_input_ids.shape[0] // n_docs
> ```
> 
> So still issue can come when `((context_input_ids.shape[0] % n_docs) != 0)`, but I can't think of solution to address this.

`context_input_ids` is always supposed to have a size of `n_docs` times the number of input questions 

> > @patrickvonplaten Thanks for the review.
> > while working on this PR I found that in `RagTokenForGeneration` we are computing `batch_size` as follows -
> > ```
> > batch_size = context_input_ids.shape[0] // n_docs
> > ```
> > 
> > 
> > So still issue can come when `((context_input_ids.shape[0] % n_docs) != 0)`, but I can't think of solution to address this.
> 
> `context_input_ids` is always supposed to have a size of `n_docs` times the number of input questions

It would be better if we mention it explicitly by assert. WDYT? 
In one of my test case I used `n_docs=3` for retriever and `n_docs=2` for generator and it failed

> It would be better if we mention it explicitly by assert. WDYT?
> In one of my test case I used `n_docs=3` for retriever and `n_docs=2` for generator and it failed

Yes indeed. Also if `((context_input_ids.shape[0] % n_docs) != 0)` then we should raise an error otherwise some retrieved documents will be ignored for generation.

Yes @lalitpagaria - it would be nice if you can add an asserte statement verifying that `n_docs` is correctly set. `n_docs` should be the same for both retriever and generator.

@patrickvonplaten @lhoestq Added assert at two places please verify, along with supporting unit test. Pardon my naming convention for test function, and please suggest proper name :) 

> n_docs should be the same for both retriever and generator.

This can't be check if `generator` does not know about `retriever` hence using this `((context_input_ids.shape[0] % n_docs) != 0)`

@patrickvonplaten and @lhoestq Thanks for the review. I liked the test coverage of this project. Initially I struggled but letter all worked nicely. You can merge when you want.

Slow tests pass => ready to merge

Good job @lalitpagaria !