Skip to content
This repository has been archived by the owner on Feb 16, 2022. It is now read-only.

Model types #12

Open
duckontheweb opened this issue Apr 7, 2021 · 4 comments
Open

Model types #12

duckontheweb opened this issue Apr 7, 2021 · 4 comments
Assignees
Labels
change Involves change to existing spec discussion needed Requires further discussion/input before implementing
Milestone

Comments

@duckontheweb
Copy link
Collaborator

The main model spec defines a list of allowed Model Type values that are designed to capture the type of model in more detail than than the Algorithm Type.

Opening this issue to discuss the following:

  • Is "Model Type" is the appropriate name for this field?
  • Should there be any changes to the listed values?
  • Should we allow other, user-defined values or require one of the listed values?
  • Should we be more explicit about relationships between this field and the Algorithm Type field?
@duckontheweb duckontheweb added discussion needed Requires further discussion/input before implementing change Involves change to existing spec labels Apr 7, 2021
@duckontheweb duckontheweb added this to the v0.1.0 milestone Apr 7, 2021
@duckontheweb duckontheweb self-assigned this Apr 7, 2021
@calebrob6
Copy link
Collaborator

calebrob6 commented May 14, 2021

Is "Model Type" is the appropriate name for this field?

It seems reasonable! "Target type" might be another appropriate name.

Two thoughts here:

  • Multi-task models do not fit well. For example, models trained on the xBD dataset (https://arxiv.org/pdf/1911.09296.pdf) might need to segment buildings and predict image level damage labels. Here a model might be segmentation and classification!
  • Unsupervised models that use some sort of contrastive loss also do not fit well. For example, if an unsupervised model uses a triplet loss what should its "Model type" be?

@HamedAlemo
Copy link
Collaborator

Good points Caleb.

  • For the Multi-task models, the solution can be to allow "Model Type" to have a list of types.
  • For the unsupervised example, doesn't fall under "Dimensionality Reduction"? We can also add "Embedding", but it's kind of the same thing.
    Also note that the value for "Model Type" has a set of pre-defined values but for edge cases like this modeler can use/suggest a different type.

@duckontheweb
Copy link
Collaborator Author

  • For the unsupervised example, doesn't fall under "Dimensionality Reduction"?

#21 changed the model_type field to a prediction_type field in the model_type object. We don't currently have "Dimensionality Reduction" listed as an option in the "Prediction Type" section, but maybe we should. @calebrob6 if we add this, it seems like your suggestion of using target_type might be more appropriate than using prediction_type since dimensionality reduction doesn't really represent a "prediction."

@duckontheweb duckontheweb modified the milestones: v0.1.0, v0.2.0 May 19, 2021
@sfoucher
Copy link

sfoucher commented Sep 7, 2021

In computer vision, The term task, instead of model_type, is more usual in the ML field, regarding the the listed values, we can sometimes find also the term Instance detection / Instance segmentation.:

image

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
change Involves change to existing spec discussion needed Requires further discussion/input before implementing
Projects
None yet
Development

No branches or pull requests

4 participants