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 option to select and provision pretrained text embedding models #137

Merged
merged 8 commits into from
Apr 18, 2024

Conversation

ohltyler
Copy link
Member

@ohltyler ohltyler commented Apr 18, 2024

Description

This PR adds the ability to select existing models, or select from available pretrained models, in the text embedding processor component. Specifically:

  • adds and updates several ML commons interfaces and constants
  • enhances search model logic on server-side to parse out more details from the API responses
  • adds some pretrained model constants to be optionally used when building flows
  • adds a ModelField field type to process all of the logic around model selection, including only showing valid deployed models, and available pretrained models. Note: the final props and how customizable this field will need to be is TBD. For example, we can customize it to be tailored towards text embedding models vs. other types of models in the future
  • updates form state and form validation to persist more model info instead of just model ID (now model ID + model type (pretrained vs. existing/deployed) + open door for more)
  • updates toTemplateNodes to dynamically handle the template node creation based on a pretrained vs. existing/deployed model. If a pretrained model is selected, we add a previous step to register and deploy that model, and use the produced model ID in the downstream create_ingest_pipeline step. Else, use the existing logic and just use the user/form-supplied model ID directly in a single create_ingest_pipeline step.

Misc:

  • cleans up routing and URL logic when navigating to the plugin from the global sidebar, in addition to the default rerouting to the workflows page
  • removes hyperlink in the base Flow Framework breadcrumb
  • changes the provisioned workflow state slightly by removing the readonly guardrails and allowing the components to be selectable to see the details. Adds a warning callout when values are changed but the workflow is provisioned, and still enforces the workflow to be deprovisioned before changes can be saved. Adds TODOs if we want to revert this change
  • enforces uniqueness on resource ID list to prevent duplicates which can happen on backend in certain edge cases (comments in code about it)

Demo video:

  • creates workflow with pretrained model
  • provisions workflow to create the model and use it in the downstream creation of an ingest pipeline
  • views the workflow resources, including the newly created model
screen-capture.29.webm

Issues Resolved

Makes progress on #73

Check List

  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@amitgalitz
Copy link
Member

Might have missed it in the code but also if its a pretrained model it has the info like dimensions in the model metadata for further steps that need that

@ohltyler ohltyler merged commit 76584f4 into opensearch-project:main Apr 18, 2024
6 checks passed
@ohltyler ohltyler deleted the add-use-cases branch April 18, 2024 22:10
opensearch-trigger-bot bot pushed a commit that referenced this pull request Apr 18, 2024
ohltyler added a commit that referenced this pull request Apr 18, 2024
…137) (#138)

Signed-off-by: Tyler Ohlsen <[email protected]>
(cherry picked from commit 76584f4)

Co-authored-by: Tyler Ohlsen <[email protected]>
@ohltyler
Copy link
Member Author

Might have missed it in the code but also if its a pretrained model it has the info like dimensions in the model metadata for further steps that need that

Right. I have this in line 196 in common/interfaces. Now that we have it persisted, we can utilize it dynamically during template construction later on. I still have it hardcoded atm, but there's a TODO tracker for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants