RNN cell reset done one step too late ... about kerasgru4rec HOT 3 CLOSED

Hello Andrei,

Apologies for my late response, it seems I wasn't "watching" the repository, and so I only noticed this issue today.

You are absolutely right, to be honest I'm not sure when this bug was introduced on our implementation. In practice, this means that whenever there's a session replacement, the cell will learn that one step with an inherited (and unwanted) state, and given that session switches are fairly common events, I'm guessing results will be impacted in a noticeable way.

I'm currently training the model with this issue fixed, as soon as I can get a better idea of how it was affecting the performance I'll report it here. You can expect the fixed implementation to be pushed as well.

Thanks for your observation!

from kerasgru4rec.

Hello Andrei,

Apologies for my late response, it seems I wasn't "watching" the repository, and so I only noticed this issue today.

You are absolutely right, to be honest I'm not sure when this bug was introduced on our implementation. In practice, this means that whenever there's a session replacement, the cell will learn that one step with an inherited (and unwanted) state, and given that session switches are fairly common events, I'm guessing results will be impacted in a noticeable way.

I'm currently training the model with this issue fixed, as soon as I can get a better idea of how it was affecting the performance I'll report it here. You can expect the fixed implementation to be pushed as well.

Thanks for your observation!

Your are welcome, pleasure was mine.
This should have "nudged" the results a wee bit, but not a lot, as it only basically introduced noise in the correct labeling from time to time.

from kerasgru4rec.

Indeed,

after training with this bug fixed, the model now presents the following results:

Recall@20: 0.685397
MRR@20: 0.294843

from kerasgru4rec.