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

✨ Text generation input inference data models #151

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tharapalanivel
Copy link
Contributor

Supports #140

Signed-off-by: Thara Palanivel <130496890+tharapalanivel@users.noreply.github.com>
caikit_nlp/data_model/generation.py Outdated Show resolved Hide resolved
Signed-off-by: Thara Palanivel <130496890+tharapalanivel@users.noreply.github.com>
top_k: int
top_p: int
typical_p: float
seed: Optional[int]
Copy link
Collaborator

@alex-jw-brooks alex-jw-brooks Aug 29, 2023

Choose a reason for hiding this comment

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

It might be a good idea to set some default! TGIS defaults are here.

Most of the time this doesn't matter, because 0 temperature (in the IBM fork) indicates greedy decoding, so top_k, top_p, typical_p, etc won't be used, as they're sampling only.

TGI doesn't use temperature 0 as a toggle though, so it would be also be nice in case those APIs are ever more unified - currently there are some small divergences with stuff like prompt IDs. I'm not sure if our raw generation modules are compatible with it or not

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Haven't seen us setting defaults on the data models themselves, only in the inference methods. I don't really have a strong opinion on this, trying to understand if that is the general direction caikit is moving in

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think even if we set defaults on the DM, they won't propagate to proto, so the default here would be guided by the .run function themselves.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Good point - my main concern with leaving it up to run is that it's easy for defaults to get out of sync if we have multiple modules relying on them.

I guess an alternate is to either have a building for getting these objects with their default values that make sense, or to have consts be passed to the run function 🤔 is the intent with this type to have a parameter that is this DM object type, or to take primitives and build this object in the requests?

@gkumbhat
Copy link
Collaborator

gkumbhat commented Sep 1, 2023

We decided to go with flattened API for now. This may be revisited, so we are keeping this PR open

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.

3 participants