Aperçu

/recommend-next-experiment

Recommandation : exécuter une expérience « entraînement plus long + évaluation sur un jeu de validation distinct »
avant de modifier l’architecture du modèle ou d’effectuer un sweep sur le LR.

Utilisez la meilleure configuration actuelle, mais entraînez plus longtemps :

hyperparameter_config = {
    "learning_rate": 0.1,          # conserver tel quel
    "epochs": 2000,                # était 1000
    "model_type": "Multivariate_neural_network_classifier",
    "torch_seed": 0,               # ajouter pour la reproductibilité
}
Ajoutez également la journalisation pour le split de validation existant à chaque époque ou
toutes les 10 à 50 époques :

train/train_loss
train/train_acc
test/test_loss
test/test_acc

et enregistrez le meilleur point de contrôle selon test/test_loss, pas uniquement
selon la perte d’entraînement.

Pourquoi il s’agit de l’expérience suivante la plus prometteuse
Le projet contient 16 runs terminés, mais seulement 4 sont de véritables runs d’entraînement ;
tous les quatre ont utilisé la même configuration d’entraînement :

learning_rate = 0.1
epochs = 1000
same model: Multivariate_neural_network_classifier

Il n’y a donc pas encore de véritable comparaison d’hyperparamètres. Le
signal le plus fort vient des courbes d’apprentissage : les quatre
pertes d’entraînement continuent de s’améliorer à la dernière époque, et
la perte d’entraînement minimale est atteinte à l’époque 1000 dans chaque run.

J’exécuterais :

learning_rate: 0.1
epochs: 2000
model_type: inchangé
random_state: conserver le split de dataset existant, 42
ajouter torch.manual_seed(0) et l’enregistrer comme torch_seed
évaluer sur X_test, y_test à chaque époque ou toutes les 10 époques
point de contrôle sur la valeur la plus basse de test/test_loss

Run that experiment for me.

Quelles tendances observez-vous sur l’ensemble de mes runs ?

J’envisage d’exécuter une analyse de répartition des états avec des
comptages par état à l’aide de filtres serveur spécifiques. Je vais examiner
le tableau des états : ['finished', 'running', 'crashed', 'failed', 'killed',
'pending', 'preempting'] et déterminer la longueur de chacun. En additionnant
ces métriques, je pourrais obtenir des informations utiles. Je dois aussi
me concentrer sur l’identification des métriques d’objectif à partir de clés
d’exemple, tout en excluant celles qui commencent par "_" ou "system/".
Il est également important de calculer les meilleures valeurs min/max pour les
métriques de synthèse numériques.

Pouvez-vous m’aider à mettre à jour mon script Python pour qu’il enregistre aussi les métriques de validation ?

Je veux effectuer un sweep pour réduire la perte de mon modèle pendant l’entraînement. Avez-vous des suggestions sur les hyperparamètres que je devrais essayer ?

 L’utilisateur cherche des informations pour améliorer la perte d’entraînement, je
 devrais donc suggérer des plages pour le taux d’apprentissage, l’optimizer, la taille de lot,
 la décroissance des poids et d’autres paramètres pertinents.

Comme l’utilisateur souhaite effectuer un sweep, je dois montrer le code ou
l’instrumentation avec une configuration YAML ou Python claire mais concise.
Je pourrais également suggérer d’utiliser des techniques aléatoires ou
bayésiennes pour une sélection plus efficace des hyperparamètres.

Create a report to share my findings with my team.

I’m looking to query the recent 50 runs, summarizing key frequencies 
and counts by using api.runs to slice them down. I'll be counting
lengths with lazy evaluation and weaving together the stats
for a proper report.  I need to include a description that might
require importing different report libraries.