You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should we split model into Model & SequentialModel?
Right now the Model class does 2 things:
Overwrite methods like fit, evaluate to allow for data passed in as merlin.io.Dataset.
Take in one or multiple blocks/layers to call sequentially.
This begs the question whether we should split up model in 2 different classes:
Model (just with the methods to overwrite)
SequentialModel which inherits from Model and calls it's inputs sequentially.
A big advantage of this split is that we would be able to handle users wanting to create their model using the sub-class API for more control. This is technically possible currently as well but a bit awkward. A user could create a two-tower model with something like:
One implication of this change would be that our RetrievalModel class becomes a bit weird. Right now we are only using that to add some extra methods to export embeddings. One way to deal with this is to remove this class & to move these methods to standard functions that take the model in as first arg.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Should we split model into Model & SequentialModel?
Right now the Model class does 2 things:
fit
,evaluate
to allow for data passed in asmerlin.io.Dataset
.This begs the question whether we should split up model in 2 different classes:
Model
(just with the methods to overwrite)SequentialModel
which inherits fromModel
and calls it's inputs sequentially.A big advantage of this split is that we would be able to handle users wanting to create their model using the sub-class API for more control. This is technically possible currently as well but a bit awkward. A user could create a two-tower model with something like:
One implication of this change would be that our
RetrievalModel
class becomes a bit weird. Right now we are only using that to add some extra methods to export embeddings. One way to deal with this is to remove this class & to move these methods to standard functions that take the model in as first arg.Beta Was this translation helpful? Give feedback.
All reactions