Skip to main content

Exporter des données

Utilisez l’API publique pour exporter ou mettre à jour les données que vous avez enregistrées dans W&B. Avant d’utiliser cette API, journalisez des données depuis votre script. Pour plus de détails, consultez le Démarrage rapide. Cas d’utilisation de l’API publique
  • Exporter des données : récupérez un dataframe pour effectuer une analyse personnalisée dans un Jupyter Notebook. Une fois les données explorées, vous pouvez synchroniser vos constats en créant un nouveau run d’analyse et en y journalisant les résultats, par exemple : wandb.init(job_type="analysis")
  • Mettre à jour des runs existants : vous pouvez mettre à jour les données journalisées associées à un run W&B. Par exemple, vous pourriez vouloir mettre à jour la configuration d’un ensemble de runs pour y ajouter des informations supplémentaires, comme l’architecture ou un hyperparamètre qui n’avait pas été journalisé à l’origine.
Voir la documentation de référence générée pour plus de détails sur les fonctions disponibles.

Exporter les données d’un run

Téléchargez les données d’un run terminé ou actif. Cette fonctionnalité sert notamment à télécharger un dataframe pour effectuer une analyse personnalisée dans un notebook Jupyter, ou à appliquer une logique personnalisée dans un environnement automatisé.
Les attributs les plus couramment utilisés d’un objet run sont les suivants : Vous pouvez également modifier ou mettre à jour les données de runs antérieurs. Par défaut, une même instance d’un objet api met en cache toutes les requêtes réseau. Si votre cas d’usage nécessite des informations en temps réel dans un script en cours d’exécution, appelez api.flush() pour obtenir des valeurs à jour.

Interroger plusieurs runs

Cet exemple de script trouve un projet et génère un fichier CSV des runs contenant leur nom, leurs configurations et leurs statistiques de synthèse. Remplacez <entity> et <project> respectivement par votre entity W&B et le nom de votre projet.
L’appel à api.runs renvoie un objet Runs itérable qui se comporte comme une liste. Par défaut, l’objet charge les runs séquentiellement, par lots de 50, au fur et à mesure des besoins, mais vous pouvez modifier le nombre de runs chargés par page avec l’argument nommé per_page. api.runs accepte également un argument nommé order. L’ordre par défaut est -created_at. Pour trier les résultats par ordre croissant, indiquez +created_at. Vous pouvez aussi trier selon des valeurs de configuration ou de synthèse, par exemple summary.val_acc ou config.experiment_name.

Gestion des erreurs

Si des erreurs surviennent lors de la communication avec les serveurs W&B, une exception wandb.CommError est levée. Vous pouvez inspecter l’exception d’origine via l’attribut exc.

Obtenir le nom et l’ID d’un run pendant son exécution

Après avoir appelé wandb.init(), vous pouvez accéder depuis votre script à l’ID aléatoire du run ou à son nom lisible, comme suit :
  • ID unique du run (hachage de 8 caractères) : run.id
  • Nom aléatoire du run (lisible) : run.name
Si vous cherchez comment attribuer des identifiants utiles à vos runs, voici nos recommandations :
  • ID du run : conservez le hachage généré. Cet identifiant doit être unique parmi les runs de votre projet.
  • Nom du run : choisissez un nom court, lisible et de préférence unique, afin de pouvoir distinguer les différentes courbes de vos graphiques.
  • Notes du run : c’est l’endroit idéal pour décrire brièvement ce que fait votre run. Vous pouvez les définir avec wandb.init(notes="your notes here")
  • Tags du run : utilisez les tags du run pour suivre des informations de manière dynamique, et appliquez des filtres dans l’interface utilisateur pour n’afficher dans votre tableau que les runs qui vous intéressent. Vous pouvez définir des tags depuis votre script, puis les modifier dans l’interface utilisateur, aussi bien dans le tableau des runs que dans l’onglet Vue d’ensemble de la page du run. Consultez les instructions détaillées ici.

Exemples d’utilisation de l’API publique

Lire les métriques d’un run

Cet exemple affiche l’horodatage et la précision journalisés avec run.log({"accuracy": acc}) pour un run enregistré dans "<entity>/<project>/<run_id>".

Lire des métriques spécifiques d’un run

Pour récupérer des métriques spécifiques d’un run, utilisez l’argument keys. Par défaut, run.history() renvoie 500 échantillons. Les steps journalisés qui ne contiennent pas une métrique donnée apparaissent dans le dataframe de sortie avec la valeur NaN. L’argument keys indique à l’API d’échantillonner plus fréquemment les steps qui contiennent les clés de métriques indiquées.

Comparer deux runs

Ce code affiche les paramètres de configuration qui diffèrent entre run1 et run2.
Sorties :

Mettre à jour les métriques d’un run une fois celui-ci terminé

Cet exemple définit la précision d’un run précédent à 0.9 :

Renommer une métrique dans un run terminé

Cet exemple renomme une colonne de synthèse dans vos tableaux.
Le renommage d’une colonne ne s’applique qu’aux tableaux. Les graphiques continueront de se référer aux métriques par leur nom d’origine.

Mettre à jour la configuration d’un run existant

Cet exemple met à jour l’un de vos paramètres de configuration.
Pour plus d’informations, consultez Configurer des expériences.

Exporter la consommation des ressources système vers un fichier CSV

L’extrait de code ci-dessous permet de trouver la consommation des ressources système d’un run, puis de l’enregistrer dans un fichier CSV.

Obtenir les données de métriques non échantillonnées

Lorsque vous récupérez des données depuis l’historique, elles sont échantillonnées par défaut à 500 points. Pour obtenir l’ensemble des points de données journalisés, utilisez run.scan_history(). Voici un exemple qui télécharge tous les points de données loss journalisés dans l’historique.

Obtenir des données paginées depuis l’historique

Pour récupérer l’historique complet et non échantillonné d’un run, utilisez run.scan_history(). L’historique non échantillonné contient tous les enregistrements d’historique du run. À l’inverse, la vue échantillonnée renvoyée par run.history() peut omettre certains enregistrements. Le paramètre page_size définit le nombre maximum d’enregistrements d’historique récupérés par requête API. Sa valeur par défaut est 1000. Si les requêtes sont lentes ou expirent, essayez une taille de page plus petite. Des pages plus petites réduisent le risque d’expiration, mais nécessitent davantage de requêtes API. Le paramètre keys permet, indépendamment, de filtrer les métriques renvoyées.

Exporter les métriques de tous les runs d’un projet vers un fichier CSV

Ce script récupère les runs d’un projet et génère un dataframe ainsi qu’un fichier CSV répertoriant les runs avec leurs noms, leurs configurations et leurs statistiques de synthèse. Remplacez <entity> et <project> respectivement par votre entity W&B et le nom de votre projet.

Obtenir l’heure de début d’un run

Cet extrait de code récupère l’heure de création du run.

Téléverser des fichiers dans un run terminé

L’extrait de code ci-dessous téléverse le fichier sélectionné dans un run terminé.

Télécharger un fichier depuis un run

Cet exemple recherche le fichier “model-best.h5” associé au run d’ID uxte44z7 dans le projet cifar, puis l’enregistre localement.

Télécharger tous les fichiers d’un run

Ce code récupère tous les fichiers associés à un run et les enregistre en local.

Obtenir les runs d’un sweep spécifique

Cet extrait télécharge tous les runs associés à un sweep donné.

Obtenir le meilleur run d’un sweep

L’extrait de code suivant récupère le meilleur run d’un sweep donné.
Le best_run est le run qui obtient la meilleure métrique, telle que définie par le paramètre metric de la configuration du sweep.

Télécharger le fichier du meilleur modèle d’un sweep

Cet extrait télécharge le fichier de modèle ayant la meilleure précision de validation dans un sweep dont les runs ont enregistré leurs fichiers de modèle dans model.h5.

Supprimer d’un run tous les fichiers ayant une extension donnée

Cet extrait supprime d’un run les fichiers ayant une extension donnée.

Télécharger les données des métriques système

Cet extrait génère un dataframe contenant toutes les métriques de consommation des ressources système d’un run, puis l’enregistre dans un fichier CSV.

Mettre à jour les métriques de synthèse

Vous pouvez transmettre un dictionnaire pour mettre à jour les métriques de synthèse.

Obtenir la commande qui a lancé le run

Chaque run capture la commande qui l’a lancé et l’affiche sur la page d’aperçu du run. Pour récupérer cette commande depuis l’API, vous pouvez exécuter :
Dernière modification le 30 septembre 2026