Closed tarekgh closed 2 months ago
CC @ericstj @luisquintanilla
Just thinking out loud, I'm wondering if rather than failing if we don't match a model name, if we should instead just default to the most recent vocab data we have.
Just thinking out loud, I'm wondering if rather than failing if we don't match a model name, if we should instead just default to the most recent vocab data we have.
I don't think that's right. Someone might have had a typo and actually needs different data. For example: gpt-2
instead of gpt2
Just thinking out loud, I'm wondering if rather than failing if we don't match a model name, if we should instead just default to the most recent vocab data we have.
I don't think that's right. Someone might have had a typo and actually needs different data. For example:
gpt-2
instead ofgpt2
Yup, that's the downside. The upside is as new models are added, there's a higher liklihood they'll just work, and typos on the models folks mostly care about right now would just work.
Maybe what I'm really wondering about is having this be so loosey-goosey with supplying an arbitrary string name. Is there something better we can think of?
We previously discussed allowing for the encoding names to be used as well. That could help if some new model came along with an existing encoding we knew about. If it's brand new then they need to provide the files and other info.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 68.44%. Comparing base (
4d5317e
) to head (f0aab77
). Report is 1 commits behind head on main.
I agree with @ericstj. I am seeing it is better to fail instead of returning something that may not match what the user want. Also, we can enhance the exception message to point at the table we are mapping so users can know the supported model names and which encoding files are used. This should make it easy for users to try one other supported name and move on.
Adding
gpt-35-turbo
model names used by Azure deployment.