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, enregistrez des données à partir de votre script. Consultez le Démarrage rapide pour plus de détails. Cas d’utilisation de l’API publique
  • Exporter des données : récupérez un dataframe pour effectuer une analyse personnalisée dans un notebook Jupyter. Une fois les données explorées, vous pouvez synchroniser vos résultats en créant un nouveau run d’analyse et en enregistrant les résultats, par exemple : wandb.init(job_type="analysis")
  • Mettre à jour des Runs existants : vous pouvez mettre à jour les données enregistrées pour un run W&B. Par exemple, vous pouvez vouloir mettre à jour la configuration d’un ensemble de runs afin d’y inclure des informations supplémentaires, comme l’architecture ou un hyperparamètre qui n’avait pas été enregistré à 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 en cours. Les cas d’usage courants incluent le téléchargement d’un dataframe pour une analyse personnalisée dans un notebook Jupyter, ou l’utilisation d’une logique personnalisée dans un environnement automatisé.
Les attributs les plus couramment utilisés d’un objet run sont : Vous pouvez également modifier ou mettre à jour les données de runs passés. Par défaut, une seule instance d’un objet API met en cache toutes les requêtes réseau. Si votre cas d’utilisation nécessite des informations en temps réel dans un script en cours d’exécution, appelez api.flush() pour obtenir des valeurs mises à jour.

Interroger plusieurs runs

Ce script d’exemple recherche un projet et génère un CSV des runs avec leur nom, leur configuration et leurs statistiques de synthèse. Remplacez <entity> et <project> par votre entité W&B et le nom de votre projet, respectivement.
L’appel à api.runs renvoie un objet Runs itérable qui se comporte comme une liste. Par défaut, l’objet charge 50 runs à la fois, séquentiellement et selon les besoins, mais vous pouvez modifier le nombre chargé 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 également trier par des valeurs de config 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 examiner l’exception d’origine via l’attribut exc.

Obtenir le nom et l’ID d’un run pendant un run actif

Après avoir appelé wandb.init(), vous pouvez accéder depuis votre script à l’ID aléatoire du run ou à son nom lisible, comme ceci :
  • ID unique du run (hachage de 8 caractères) : run.id
  • Nom aléatoire du run (lisible) : run.name
Si vous cherchez un bon moyen de définir des identifiants utiles pour vos runs, voici ce que nous recommandons :
  • ID du run : laissez le hachage généré tel quel. Il doit être unique parmi les runs de votre projet.
  • Nom du run : il doit être court, lisible et de préférence unique, afin que vous puissiez distinguer les différentes lignes sur vos graphiques.
  • Notes du run : c’est l’endroit idéal pour ajouter une brève description de ce que vous faites dans ce run. Vous pouvez les définir avec wandb.init(notes="your notes here")
  • Tags du run : utilisez les tags du run pour suivre des éléments de manière dynamique, puis utilisez des filtres dans l’UI pour n’afficher dans votre tableau que les runs qui vous intéressent. Vous pouvez définir les tags depuis votre script, puis les modifier dans l’UI, à la fois dans le tableau des Runs et dans l’onglet Vue d’ensemble de la page du run. Voir les instructions détaillées ici.

Exemples d’utilisation de l’API publique

Lire les métriques d’un run

Cet exemple affiche le timestamp et la précision enregistrés avec run.log({"accuracy": acc}) pour un run enregistré sous "<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. Le nombre d’échantillons par défaut lors de l’utilisation de run.history() est de 500. Les étapes enregistrées qui n’incluent pas de métrique spécifique apparaîtront dans le dataframe de sortie sous la forme de NaN. L’argument keys fera en sorte que l’API échantillonne plus fréquemment les étapes qui incluent les clés de métrique listées.

Comparer deux runs

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

Mettre à jour les métriques d’un run après la fin du run

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

Renommer une métrique dans un run terminé

Cet exemple renomme une colonne « summary » dans vos tableaux.
Le changement de nom d’une colonne s’applique uniquement aux tableaux. Les graphiques continueront d’utiliser les noms d’origine des métriques.

Mettre à jour la configuration d’un run existant

Cet exemple met à jour un de vos paramètres de configuration.
Voir Configurer les expériences pour en savoir plus.

Exporter l’utilisation des ressources système vers un fichier CSV

L’extrait ci-dessous permet de trouver l’utilisation des ressources système, puis de l’enregistrer dans un fichier CSV.

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

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

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

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

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

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

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

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

Importer des fichiers dans un run terminé

L’extrait de code ci-dessous importe un fichier sélectionné dans un run terminé.

Télécharger un fichier d’un run

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

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

Cette commande récupère tous les fichiers associés à un run et les enregistre localement.

Obtenir les runs d’un balayage spécifique

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

Obtenir le meilleur run d’un balayage

L’extrait suivant récupère le meilleur run d’un balayage donné.
Le best_run correspond au run présentant la meilleure métrique, telle que définie par le paramètre metric dans la configuration du balayage.

Télécharger le fichier du meilleur modèle depuis un balayage

Cet extrait télécharge le fichier de modèle avec la meilleure précision de validation depuis un balayage contenant des runs qui ont enregistré des fichiers de modèle sous 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 du summary

Vous pouvez transmettre un dictionnaire pour mettre à jour les métriques du summary.

Obtenir la commande qui a lancé le run

Chaque run enregistre la commande qui l’a lancé sur la page d’aperçu du run. Pour récupérer cette commande depuis l’API, vous pouvez exécuter :