-
Notifications
You must be signed in to change notification settings - Fork 27.4k
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
Add default template warning #26637
Conversation
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. |
There was a problem hiding this 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.
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? |
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 The problem right now is if a user uses 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. |
Ok, sounds good to me in that case. Thanks for the explanation! |
Sure! Also @ArthurZucker to respond to your comments, I'm probably going to start with this, then maybe we can begin deprecating The |
|
8d9e9d7
to
2f79bd3
Compare
Update: After testing, I took |
c55f505
to
9db9b39
Compare
There was a problem hiding this 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!
9db9b39
to
780f3d9
Compare
780f3d9
to
c6b8a5d
Compare
* Add default template warnings * make fixup * Move warnings to FutureWarning * Move warnings to FutureWarning * fix make fixup * Remove futurewarning
* Add default template warnings * make fixup * Move warnings to FutureWarning * Move warnings to FutureWarning * fix make fixup * Remove futurewarning
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 useapply_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 whenapply_chat_template
orConversationalPipeline
is called for a model without achat_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 levelchat_template
attributes. This PR starts that process, while still retaining the feature for backward compatibility.