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

Add default template warning #26637

Merged
merged 6 commits into from
Oct 18, 2023
Merged

Add default template warning #26637

merged 6 commits into from
Oct 18, 2023

Conversation

Rocketknight1
Copy link
Member

Lots of user repos use common tokenizers like LlamaTokenizer even for non-LLaMA models. Unfortunately, these tokenizers come with default chat templates, which may result in user confusion if they use apply_chat_template. We want to avoid a scenario where users think they're getting the right template but actually aren't!

This PR raises a short warning the first time a default_chat_template is read, which happens when apply_chat_template or ConversationalPipeline is called for a model without a chat_template set. The warning tells the user what's happening, and suggests adding an explicit chat template.

Over time, the goal is to eventually deprecate and remove default_chat_template, because we want to avoid using class-level templates entirely, and move to explicit repo level chat_template attributes. This PR starts that process, while still retaining the feature for backward compatibility.

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Copy link
Collaborator

@ArthurZucker ArthurZucker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep this, let's leverage the futur warning. But I am not sure I fully understand what this add, the default template was always used by default for a few of these models, and if we want to improve/grow the template feature we should probably raise and error to make sure the repo owners push a default template (instead of defaulting in the class) which is breaking but helps moving towards template on the hub.
Also if the template is a default template but pushed to the hub should not warn / raise anything.

@LysandreJik
Copy link
Member

Hmmm I'm not sure this warning will be useful for the majority of users; wouldn't it be better as an INFO level?

I think having class-level templates is better than not having anything, and IMO it would make sense to have a sensible default (original architecture training scheme) rather than forcing each checkpoint to have their own definition. Or do you expect every checkpoint to have a different template?

@Rocketknight1
Copy link
Member Author

Just from looking at models on the Hub, I think a lot of models use templates totally different from the default class one. For example, if you look at the top trending models on the Hub today, the top model is Mistral-7B-instruct, which uses LlamaTokenizer with a custom chat template, and the second place model is Mistral-7B-OpenOrca, which also uses LlamaTokenizer but with a ChatML template. Neither of these templates match the class-level template.

The problem right now is if a user uses apply_chat_template with a model like that which doesn't have a chat_template attribute, it will appear to work, but they'll silently get the wrong, class-level template instead! This is exactly what we want to avoid with chat templates.

I think raising a warning is the right approach - it won't break existing workflows, but it will flag a potential source of issues, and it might notify users and maintainers to add proper chat templates to the models they're using.

@LysandreJik
Copy link
Member

Ok, sounds good to me in that case. Thanks for the explanation!

@Rocketknight1
Copy link
Member Author

Sure! Also @ArthurZucker to respond to your comments, I'm probably going to start with this, then maybe we can begin deprecating default_class_template over time, but I want to do it slowly because it breaks old workflows.

The FutureWarning suggestion was good, though, I'll add that now!

@Rocketknight1
Copy link
Member Author

FutureWarning added!

@Rocketknight1 Rocketknight1 force-pushed the add_default_template_warning branch from 8d9e9d7 to 2f79bd3 Compare October 9, 2023 16:48
@Rocketknight1
Copy link
Member Author

Update: After testing, I took FutureWarning out because it clashes with warning_once, and I don't want to spam these messages too much!

@Rocketknight1 Rocketknight1 force-pushed the add_default_template_warning branch 2 times, most recently from c55f505 to 9db9b39 Compare October 16, 2023 16:28
Copy link
Member

@LysandreJik LysandreJik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge it!

@Rocketknight1 Rocketknight1 force-pushed the add_default_template_warning branch from 9db9b39 to 780f3d9 Compare October 18, 2023 12:31
@Rocketknight1 Rocketknight1 force-pushed the add_default_template_warning branch from 780f3d9 to c6b8a5d Compare October 18, 2023 15:35
@Rocketknight1 Rocketknight1 merged commit d933818 into main Oct 18, 2023
3 checks passed
@Rocketknight1 Rocketknight1 deleted the add_default_template_warning branch October 18, 2023 16:38
staghado pushed a commit to staghado/transformers that referenced this pull request Oct 24, 2023
* Add default template warnings

* make fixup

* Move warnings to FutureWarning

* Move warnings to FutureWarning

* fix make fixup

* Remove futurewarning
EduardoPach pushed a commit to EduardoPach/transformers that referenced this pull request Nov 19, 2023
* Add default template warnings

* make fixup

* Move warnings to FutureWarning

* Move warnings to FutureWarning

* fix make fixup

* Remove futurewarning
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

Successfully merging this pull request may close these issues.

4 participants