PCMR flows - unshift/unshuffle tasks

[opeltre]

En suivant grossièrement le modèle de experiments/twins.py, écrire un script d'entraînement sur les tâches de recalage temporel / réidentification des canaux.

Usage

Regarder en particulier l. 45--62 et utiliser la même convention de nommage pour l'option --writer et l'endroit ou sauvegarder l'état final du modèle (éventuellement générer automatiquement l'argument en question). L'argument --state servirait quant à lui à charger l'état initial du modèle qui viendrait d'un réseau préentraîné (par exemple sur la tâche unshuffle)

$ python unshift_flows.py -w "convnet-xxx"      # avec 'xxx' = 'apr19-1', 'apr19-2' ... par défaut 
$ python unshift_flows.py   
# => création de 2 fichiers:
#      - "runs/convnet-xxx"         pour tensorboard
#      - "models/convnet-xxx.pt"    pour l'état final du modèle 
$ python unshift_flows.py -s "convnet-xxx" -w "convnet-yyy"
# => chargement du modèle existant convnet-xxx

Définition des tâches

Dans un deuxième temps, lla fonction main() pourra prendre en argument l'enchaînement des tâches prétextes et leurs paramètres (arguments stdev pour les shifts, learning rates et decay rates, nombre d'époques, etc.), en s'inspirant de la fonction episodes() l.76

On pourra ensuite lire ces arguments depuis un json ou autre format, pour en exécuter à la suite, et surtout sauvegarder ce fichier json dans tensorboard ou à côté afin de pouvoir retrouver les hyperparamètres associés à chaque run.

Architecture du modèle

Un des principes de l'apprentissage auto-supervisé est d'entraîner des réseaux de la forme f = h . g de la forme

          g            h
f :  X  ----->   Y  ------> Z
#  entrée  >  représ°  >  sortie

où la représentation interne y in Y est conservée au cours du temps tandis que la sortie z in Z est adaptée à chaque tâche prétexte. Plus la représentation est meilleure, plus il est facile de prédire la sortie à partir d'une architecture simple de la "tête" du réseau h : Y -> Z. Ainsi chaque tâche prétexte force le réseau à améliorer l'expressivité de sa représentation interne, et la diversité des tâches contribuera à la qualité du préentraînement.

Il est important d'avoir une invariance par translations globales de la représentation du réseau. Cela forcerait le convnet g : X -> Y à avoir une couche de sortie de la forme (Nc, Npts) = (Nc, 1), i.e. de provenir d'un argument layers de la forme:

layers = [[Npts, 6, w_in],   # Npts = 32 ou 64
          ...
          [1, dim_out, 1]]    

model = ConvNet(layers, ...)

Il faut ensuite le composer avec un autre modèle, par exemple de la forme:

head = ConvNet([[1, dim_out, 1], [1, dim_task, 1]]) 

qui se comporte comme une couche dense de taille (dim_out, dim_task).

• documentation nn.Sequential : https://pytorch.org/docs/stable/generated/torch.nn.Sequential.html

En plus de stocker l'état de g dans "models/convnet-xxx.pt" on pourra aussi stocker celui de h dans un fichier
"models/head-xxx.pt" voire prompter l'utilisateur pour lui demander lesquels stocker.

[opeltre]

@AdrienHannon @b-brebion mettez ici des petits compte-rendus de ce que donnent vos expériences ;)