[RFC][FEATURE] Model alias

[b4sjoo]

Introduction:

Right now our model versions are identified by random IDs. Meanwhile, most of our ML-related behaviors at this time require user to refer the model ID directly, which are hard to remember and use due to its abstractness. This can lead to confusion and errors when the users want to refer to a specific model or compare different models. To address this issue, we propose to design and implement a model alias feature for our ml-commons. This feature will allow users to assign a custom alias to each model they create or use, and then use this alias as a reference instead of the model ID. For example, a user can name their model "text_embedding" or "sentiment_analysis" and then use these alias in their queries or commands.

Benefits of this feature:

• It will improve the user experience and satisfaction by making it easier and more intuitive to work with machine learning models.
• It will reduce the risk of errors and mistakes by avoiding confusion between different models or using the wrong model ID.
• It will enable more efficient and effective communication and collaboration among the users who share or exchange models.

Where model id is being used now:

1. The get/delete/deploy/undeploy/predict model API required model ID right now.
2. In Neural Search Plugin, in order to ingest vectorized documents, you need to create a Neural Search pipeline. A pipeline consists of a series of processors that manipulate documents during ingestion, allowing the documents to be vectorized. The following example API operation creates a Neural Search pipeline:

PUT _ingest/pipeline/nlp-pipeline
{
  "description": "An example neural search pipeline",
  "processors" : [
    {
      "text_embedding": {
        "model_id": "bxoDJ7IHGM14UqatWc_2j",
        "field_map": {
           "passage_text": "passage_embedding"
        }
      }
    }
  ]
}

Neural search query also needs model id, for example

            "query": {
              "neural": {
                "passage_vector": {
                  "query_text": "Hello world",
                  "model_id": "xzy76xswsd",
                  "k": 100
                }
              }
            },

Pain point

Suppose the user have a new model version and they want to use it to replace the old version. They need to update the pipeline by changing the model_id. User also need to change model id in neural search query.

Another example: User build some application with OpenAI remote model, and later they prefer to move to another model like Claude model, then user have to change the model id in their application code and redeploy. That will have service unavailable window. With model alias, user can simply move alias from one model to another, then all request will be routed to the new model, no need to redeploy, no service unavailable window.

Solution HLD:

Option 1: The model alias is globally unique

Plan:

1. Model alias is an optional field when the user register a model (null is a legal value)
2. User can give or modify(including remove) model alias anytime through model update API
3. Every time when user create or modify the model alias, we will initiate a global uniqueness checking towards the model alias given by the user. If it does not meet the global uniqueness requirement, an exception will be thrown.
4. User can re-link model alias to a different model through model update API

pros:

1. This solution does not require too much changes in the backend
2. This solution requires less checks

cons:

1. Generally user intends to create intuitive and meaningful names, which are very likely to be similar and can easily cause collision. This indicates user frustration when alias number grows.
2. The user may need to keep update model alias once they update their model.

Solution LLD:

Plan:

1. This solution mainly involved in three methods: create-alias, update-alias, and delete-alias
2. Global uniqueness check: we check both on model ID and model aliases.
3. Create-alias: API endpoints use model ID to locate the model. We first initiate a global uniqueness checking. If it does not meet the global uniqueness requirement, an exception will be thrown. If global uniqueness check passed, we return a success message.
4. Update-alias: API endpoints use model ID to locate the model. We first check if the model group has the alias. If yes we relink the alias. If not we throw an exception.
5. Delete-alias: We check if user can access the model, if yes then the corresponding alias can be removed and be released to public

Security

1. DDOS
2. Abuse of update-alias method (Use update-alias without communicating with collaborators)

Backward Compatibility

• This solution does not involve in any breaking changes, so backward compatibility won’t be a problem here.

Testability

• The logic is pretty straightforward, so testing won’t be a problem here. But if we want we can let neural search team to test the feature before release, to gather some metrics and feedback.