-
Notifications
You must be signed in to change notification settings - Fork 309
Expose token_embedding as a Backbone Property
#676
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
Expose token_embedding as a Backbone Property
#676
Conversation
mattdangerw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one comment!
token_embedding as a Backbone Property
|
These test failures are interesting, changing the layers we set on self changes our checkpoints structure. We may need to dig into this more, let's talk tomorrow! |
Very weird. I haven't changed the names of the layers! And it is happening only for those for which I have broken the call into two: instead of |
|
Just a guess with a very limited log (only saw the error message or Roberta), it could be because of the self._token_embedding. Even when you don't use it, Keras tries to load its weights. after running this code, I added a new layer with self, say self.layer_b = LayerA(). But I will not use it. Even when I use the layer_b inside layer_a it will not work For now, the only solution that comes into my mind is using get_layer method of the model like this: But with this approach, all token embeddings must have the name 'token_embedding'. I'm definitely not a fan of this approach 😄 |
jbischof
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great @abheesht17!
Could you update the Bert pretraining example (link) and file an Issue to update our "Getting Started" guide (link)?
| ) | ||
| return config | ||
|
|
||
| @property |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @NusretOzates, the self._token_embedding approach seems cleaner than relying on a specific layer name. We already have several other similar class variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbischof - it doesn't work for models with TokenAndPositionEmbedding layer. Keras considers self._token_embedding as a separate embedding layer, and errors out when we try to load preset checkpoints. Hence, this elaborate-ish solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think what we are facing here is setattr tracking on all keras layers. Basically anytime you are setting a layer attribute on self, if gets added to a list of resources used for serialization. It looks like this can affect our checkpoint compatibility! Which is not good, we don't want to be affecting our checkpoints just to expose something like this. Relevant code -> https://github.com/keras-team/keras/blob/2727df09aa284a94ce8234ad1279d9659cdf2064/keras/engine/base_layer.py#L3215-L3229
The solution laid our here seems like a nice way to avoid the setattr tracking entirely. This LGTM.
The alternate I see would be to add a line self._auto_track_sub_layers = False to the backbone base class. But this could run us into hot water if we ever had non-functional Backbones (not everything can be a functional model -> https://keras.io/guides/functional_api/#functional-api-weakness). So the solution here seem most robust!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I am dumping too much context, but for those interested in going deeper...
The __setattr__ tracking is deduped, so for Bert, where the token embedding is already a sublayer of the model directly, there is no issue here. self.some_properly = direct_layer_of_model has no issues. But Roberta for example will have the token embedding as a nested layer. self.some_property = nested_layer_of_model will change our checkpoint structure! This is what @NusretOzates was mentioning above.
Also thanks @NusretOzates for that writeup! Very helpful!
mattdangerw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just the one comment re switching returning the tf.Variable to the keras.layers.Embedding
|
|
||
| @property | ||
| def token_embedding(self): | ||
| return self.get_layer("token_embedding").embeddings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should just return the embedding layer here, that is what you are documenting on the base class below! So leave off the .embeddings part, that can be done by calling code as required.
Expose the layer seems the more general case here. It doesn't preclude getting the weights out, but also gives you a callable layer if you want it!
| ) | ||
| return config | ||
|
|
||
| @property |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think what we are facing here is setattr tracking on all keras layers. Basically anytime you are setting a layer attribute on self, if gets added to a list of resources used for serialization. It looks like this can affect our checkpoint compatibility! Which is not good, we don't want to be affecting our checkpoints just to expose something like this. Relevant code -> https://github.com/keras-team/keras/blob/2727df09aa284a94ce8234ad1279d9659cdf2064/keras/engine/base_layer.py#L3215-L3229
The solution laid our here seems like a nice way to avoid the setattr tracking entirely. This LGTM.
The alternate I see would be to add a line self._auto_track_sub_layers = False to the backbone base class. But this could run us into hot water if we ever had non-functional Backbones (not everything can be a functional model -> https://keras.io/guides/functional_api/#functional-api-weakness). So the solution here seem most robust!
mattdangerw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
This little "cleanup PR" turned into quite a complex issue, but I def think it was good to work through!


self.token_embedding = token_embedding_layer.__init__args.Edit:
token_embeddingas a property.