pytorch / pytorch/vision

[RFC] How to handle BC breaking changes on Model weights or hyper-parameters

Open
#2,955 3 comments 0 reactions 1 assignee View on GitHub

@datumbox is already working on this.

Since Sep 4, 2021.

needs discussion version incompatibility
Dominant language
Python
Stars
17.9k
Forks
7.3k
Avg merge
1d 15h
Merged PRs (30d)
13

Description

🚀 Feature

In order to fix bugs we are sometimes forced to introduce BC breaking changes. While the process of such introductions is clear when it comes to code changes, it's not when it comes to model weights or hyper-parameters. Thus we should define when, why and how to introduce BC-breaking changes when it comes to model weights or model hyper-parameters.

Motivation

We have recently bumped to a few issues that motivate this. Here are a few examples:

  • On #2326 we discovered a bug in the initialization of some weights of all detection models. If we fix the bug on code, we should probably retrain the models. What happens if their accuracy improves? How do we make them available to our users?
  • How do we handle cases such as #2599 where in order to fix a bug we need to update the hyper-parameters of the model?

Approaches

There are quite a few different approaches for this:

  1. Replace the old parameters and Inform the community about the BC breaking changes. Example: #2942
    • Reasonable approach when the accuracy improvement is substantial or the effect on the model behaviour is negligible.
    • Keeps the code-base clean from workarounds and minimizes the number of weights we provide.
    • Can potentially cause issues to users who use transfer learning.
  2. Write code/workarounds to minimize the effect of the changes on existing models. Example: #2940
    • Reasonable approach when the changes lead to slight decrease in accuracy.
    • Minimizes the effects on users who used pre-trained models.
    • Introduces ugly workarounds on the code and increases the number of weights we provide.
  3. Introduce versioning on model weights:
    • Appropriate when introducing significant changes on the models.
    • Keeps the code-base clean from workarounds.
    • Forces us to maintain multiple versions of weights and model config.

It's worth discussing whether we want to adapt our approach depending on the characteristics of the problem or if we want to go with one approach for all cases. Moreover it's worth investigating whether we need to handle differently changes on weights vs changes on hyper-parameters used on inference.

cc @fmassa @cpuhrsch @vfdev-5 @mthrok

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.