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.
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é.
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
- DataFrame et CSV
- Style MongoDB
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.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 exceptionwandb.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
- 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 avecrun.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’argumentkeys. 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 entrerun1 et run2.
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.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, utilisezrun.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, utilisezrun.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é.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 dansmodel.h5.