Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Notebooks Microsoft Fabric pour l’entraînement IA : des modèles directement sur les données du Lakehouse, sans chaos CSV (Doublage IA)

Transcript

Notebooks Microsoft Fabric pour l’entraînement IA : des modèles directement sur les données du Lakehouse, sans chaos CSV (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours de Microsoft 365 Copilote, l'IA, Azure
0:04
Speaker 2: et les personnes qui façonnent l'avenir du travail M. En janvier,
0:08
Speaker 2: la M365ON est de retour et elle va plus loin.
0:11
Speaker 2: Et elle va plus loin. Rejoignez-nous pour des sessions en direct,
0:14
Speaker 2: des démonstrations concrètes et des connaissances pratiques de MVP et
0:17
Speaker 2: d'experts du secteur du monde entier. Pas de diapositives génériques.
0:20
Speaker 2: Pas de mots à la mode sans fin. Nous nous
0:22
Speaker 2: attaquons aux vrais défis. Copilote Studio, agent d'IA, fabrique, sécurité,
0:27
Speaker 2: gouvernance et automatisation. Que vous soyez un professionnel de l'informatique,
0:31
Speaker 2: un développeur ou un chef d'entreprise, des sessions sont conçues
0:34
Speaker 2: pour vous. Pendant 10 jours complets, vous pouvez explorer de
0:37
Speaker 2: multiples technologies et vous connecter à une communauté mondiale. Regardez
0:41
Speaker 2: en direct et rapportez des informations pratiques à votre organisation.
0:45
Speaker 2: Du 20 au 27 janvier, 10 jours, une communauté Microsoft.
0:49
Speaker 2: Les inscriptions sont ouvertes dès maintenant. Rendez-vous sur m365con. net et
0:53
Speaker 2: réservez votre place dès aujourd'hui. C'est m365con. net... Rejoignez-nous dès maintenant
1:01
Speaker 2: sur m365one. net et nous vous donnons. Rendez-vous en direct en janvier.
1:05
Speaker 3: Allez-vous déjà. Essayez d'entraîner un modèle d'IA sur votre ordinateur
1:07
Speaker 3: portable pour le voir ensuite ramper pendant des heures ou
1:09
Speaker 3: planter complètement. Ou planter complètement. N'êtes pas seul. La plupart
1:12
Speaker 3: des ensembles de données d'entreprise sont devenus trop volumineux pour
1:14
Speaker 3: notre matériel local. Mais que se passerait-il si l'intégralité de
1:17
Speaker 3: votre ensemble de données de plusieurs terres octets était instantanément
1:19
Speaker 3: accessible dans votre bloc-notes d'entraînement? Pas d'extrait, pas de chaos CSV. Aujourd'hui,
1:23
Speaker 3: nous entrons dans les blocs-notes intégrés de Microsoft Fabric, où
1:26
Speaker 3: l'entraînement de votre modèle se déroule juste à côté de
1:28
Speaker 3: vos données Lakehouse. Nous allons expliquer en détail comment cette
1:32
Speaker 3: configuration peut vous faire gagner des jours de traitement tout
1:34
Speaker 3: en vous permettant de travailler en Python ou R sans compromis.
1:38
Speaker 3: Lorsque le Big Data devient trop volumineux, pour votre ordinateur portable, imaginez,
1:42
Speaker 3: le ventilateur de votre ordinateur portable tourne suffisamment fort pour
1:44
Speaker 3: courir votre réunion pendant que vous travaillez sur une feuille
1:46
Speaker 3: de calcul. Maintenant, remplacez cette feuille de calcul par 12
1:48
Speaker 3: Teraoctets de transactions clients brutes réparties sur des années d'activité
1:51
Speaker 3: avec des dizaines d'activités, avec des dizaines de champs par enregistrement.
1:55
Speaker 3: Avant même d'appuyer sur Exécuter, vous savez déjà que cela
1:57
Speaker 3: va faire mal. C'est exactement là où se trouvent de
1:59
Speaker 3: nombreuses équipes marketing Elles disposent d'une base de données transactionnelles
2:02
Speaker 3: qui pourrait facilement constituer l'épine dorsale d'un projet d'IA avancé.
2:07
Speaker 3: Prédire le taux de désabonnement, segmenter les audiences, personnaliser les
2:10
Speaker 3: campagnes en temps quasi réel, mais leurs outils restent bloqués
2:14
Speaker 3: sur leurs ordinateurs de bureau. Ils ouvrent des fichiers dans
2:17
Speaker 3: Excel ou un notebook Jupyter local, découpent et filtrent par
2:20
Speaker 3: petits morceaux. Juste pour éviter de bloquer la machine, espère
2:22
Speaker 3: que tout tiendra suffisamment longtemps pour obtenir des résultats exploitables.
2:25
Speaker 3: Lorsque les équipes tentent de faire cela localement, les fissures
2:27
Speaker 3: apparaissent rapidement. Le traitement ralentit considérablement, les éléments de l'interface
2:34
Speaker 3: utilisateur accusent un décalage de quelques secondes par rapport au
2:35
Speaker 3: cliquet d'excapture d'exportation qui prenait autrefois quelques minutes. L'exportation qui
2:37
Speaker 3: prenait autrefois quelques minutes s'exécute désormais pendant des heures. Pire encore,
2:40
Speaker 3: les charges de travail plus importantes ne ralentissent pas seulement,
2:41
Speaker 3: elles s'arrêtent. Les erreurs de mémoire, les pannes de disques
2:43
Speaker 3: durs ou les redémarrages du noyau signifient que les exécutions
2:45
Speaker 3: d'entraînement ne prennent pas seulement plus de temps, elles ne
2:47
Speaker 3: se terminent souvent jamais. Et lorsqu'il s'agit d'entraîner un modèle d'IA,
2:50
Speaker 3: cela représente du calcul gaspillé, du temps perdu et des
2:53
Speaker 3: opportunités gâchées. Une tentative de prédiction du taux de désabonnement
2:57
Speaker 3: que 20 heures plus tard, le processus a finalement échoué
3:03
Speaker 3: car la dernière partie de l'ensemble de données a poussé
3:05
Speaker 3: l'utilisation de la RAM au-delà de la limite. L'équipe a
3:08
Speaker 3: perdu une journée entière sans même récupérer un ensemble de
3:11
Speaker 3: mesures d'entraînement. Si cela semble extrême, c'est de plus en
3:13
Speaker 3: plus courant. Les ensembles de données marketing d'entreprise se sont
3:17
Speaker 3: étoffés d'année en année grâce à un suivi plus riche,
3:19
Speaker 3: à des expériences omnicanales et à l'essor de la journalisation
3:22
Speaker 3: basée sur les événements. Même une configuration assez standard, les
3:26
Speaker 3: journaux de performance des campagnes, les analyses web et les
3:29
Speaker 3: données CRM peuvent facilement atteindre des centaines de gigaoctets. Les
3:32
Speaker 3: grands comptes avec plusieurs gammes de produits finissent souvent par
3:34
Speaker 3: atteindre plusieurs teraoctets. Le problème ne réside pas seulement dans
3:36
Speaker 3: la capacité de stock. Les charges d'entraînement de modèles volumineuses
3:39
Speaker 3: mettent à rude épreuve toutes les limites d'une machine locale.
3:41
Speaker 3: Les processeurs tournent à 100% pendant de longues périodes et
3:44
Speaker 3: même les GPU haut de gamme finissent par être inactifs
3:46
Speaker 3: lorsque les données arrivent trop lentement. Les entrées et sorties
3:50
Speaker 3: de disques deviennent un point d'étranglement constant, en particulier si
3:53
Speaker 3: l'ensemble de données réside sur un disque externe ou un
3:55
Speaker 3: partage réseau. Et puis il y a la couche logicielle.
3:59
Speaker 3: Une fois que les fichiers deviennent suffisamment volumineux, même un
4:01
Speaker 3: ordinateur portable Jupiter aussi polyvalent commence à repousser ses limites.
4:04
Speaker 3: Vous ne pouvez pas simplement charger des données CSV en
4:06
Speaker 3: mémoire lorsque les données CSV sont plus volumineuses que votre SSD.
4:09
Speaker 3: C'est pourquoi de nombreuses équipes ont essayé de fractionner les fichiers,
4:11
Speaker 3: d'échantillonner les données ou de créer des substituts légers pour
4:14
Speaker 3: les ensembles de données de production réelles. C'est un compromis
4:17
Speaker 3: qui permet de maintenir votre ordinateur portable en vie, mais
4:19
Speaker 3: au prix d'une perte de visibilité. L'échantillonnage peut laisser tomber
4:21
Speaker 3: des schémas subtils qui auraient amélioré les performances du modèle.
4:25
Speaker 3: La fractionnement des fichiers introduit toutes sortes d'incohérences et rend
4:27
Speaker 3: le réentraînement plus pénible qu'il ne devrait l'être. Il existe
4:31
Speaker 3: un moyen plus intelligent d'éviter tout ce cycle de téléchargement
4:33
Speaker 3: et d'importation. Microsoft Fabric transfère entièrement le gros du travail
4:37
Speaker 3: de votre environnement local. L'entraînement est transféré dans le cloud,
4:40
Speaker 3: où les ressources de calcul se trouvent juste à côté
4:42
Speaker 3: des données stockées dans le lakehouse. Vous ne transférez pas
4:45
Speaker 3: des teraoctets dans les deux sens, vous transférez votre code
4:47
Speaker 3: là où se trouvent déjà les données mains. Au lieu
4:51
Speaker 3: de vous soucier de savoir quelle partie de votre historique
4:53
Speaker 3: client tiendra dans la RAM, vous pouvez vous concentrer sur
4:55
Speaker 3: la structure et la logique de votre exécution d'entraînement. Et
4:58
Speaker 3: voici la partie que la plupart des équipes négligent. Le
5:01
Speaker 3: véritable avantage n'est pas seulement la puissance supplémentaire du calcul
5:04
Speaker 3: dans le cloud. C'est le fait que vous n'avez plus
5:06
Speaker 3: du tout à déplacer les données. Accès direct au lakehouse,
5:09
Speaker 3: plus de chaos CSV. Si votre notebook pouvait extraire des
5:13
Speaker 3: teraoctets de données instantanément, sans jamais afficher de barres de
5:16
Speaker 3: progression de téléchargement, pas besoin d'exporter au format CSV, pas
5:20
Speaker 3: besoin de regarder un spinner de chargement défiler à l'écran.
5:22
Speaker 3: Il suffit de saisir la requête, de l'exécuter et de
5:25
Speaker 3: commencer à travailler avec les résultats directement. C'est la différence
5:27
Speaker 3: lorsque la couche de données n'est pas une étape externe,
5:29
Speaker 3: mais qu'elle est intégrée à l'environnement dans lequel vous codez déjà.
5:34
Speaker 3: Dans Fabric, le Lakehouse n'est pas simplement un compartiment de
5:36
Speaker 3: stockage distinct auquel vous vous connectez de temps en temps.
5:40
Speaker 3: C'est la couche de données native des notebooks. Cela signifie
5:43
Speaker 3: que votre code s'exécute dans le même environnement que celui
5:45
Speaker 3: où se trouvent physiquement les données. Vous ne transférez pas
5:48
Speaker 3: des millions de lignes sur le réseau dans votre session.
5:51
Speaker 3: Vous envoyez des instructions aux données à leur emplacement d'origine.
5:54
Speaker 3: Le pipeline d'entrée du modèle n'est pas un exercice de
5:56
Speaker 3: jonglage entre les exportations et les importations. C'est une ligne
5:58
Speaker 3: directe entre le stockage, Spark, et la logique Python ou
6:01
Speaker 3: R que vous écrivez. Si vous avez déjà utilisé un
6:03
Speaker 3: workflow traditionnel, vous connaissez déjà les points faibles habituels. Quelqu'un
6:07
Speaker 3: crée un extrait de l'entrepôt de données, l'écrit dans un
6:09
Speaker 3: fichier CSV et le transmet à l'équipe de science des données.
6:12
Speaker 3: Le schéma est désormais figé dans le temps. La semaine suivante,
6:15
Speaker 3: les données sources changent et l'extrait est déjà obsolète. Dans
6:18
Speaker 3: certains cas, deux équipes différentes créent chacune leurs propres exportations
6:21
Speaker 3: légèrement différentes. Vous vous retrouvez donc avec un stockage dupliqué
6:24
Speaker 3: avec des définitions incompatibles. Dans le meilleur des cas, il
6:27
Speaker 3: s'agit simplement d'inefficacité. Dans le pire des cas, c'est la
6:29
Speaker 3: raison pour laquelle deux modèles entraînés sur les mêmes données
6:31
Speaker 3: donnent des prédictions contradictoires. Une équipe avec laquelle j'ai travaillé
6:34
Speaker 3: avait besoin d'un ensemble filtré d'enregistrements d'activités clients pour un
6:37
Speaker 3: nouveau modèle de désabonnement. Ils ont tout extrait de l'entrepôt
6:40
Speaker 3: dans une base de données SQL locale, l'ont filtré puis
6:42
Speaker 3: ont exporté. L'ensemble de résultats dans un fichier CSV pour
6:44
Speaker 3: l'environnement d'entraînement. Cette opération a pris à elle seule près
6:47
Speaker 3: d'une journée entière sur leur réseau. Lorsque de nouveaux enregistrements
6:50
Speaker 3: d'activités ont été chargés la semaine suivante, ils ont dû
6:52
Speaker 3: recommencer tout le processus depuis le début. Au moment où
6:54
Speaker 3: ils ont pu commencer l'entraînement proprement dit, ils avaient passé
6:57
Speaker 3: plus de temps à trier les fichiers qu'à écrire du code.
6:59
Speaker 3: La baisse de performance ne concerne pas seulement le temps
7:01
Speaker 3: de transfert. Des études menées dans plusieurs entreprises montrent des
7:05
Speaker 3: gains constants. Lorsque les transformations sont exécutées, là où les
7:07
Speaker 3: données sont stockées, lorsque vous pouvez effectuer les jointures, les
7:11
Speaker 3: filtres et les agrégations sur place plutôt qu'en aval, vous
7:13
Speaker 3: réduisez les frais généraux les sauts de réseau et les
7:16
Speaker 3: lectures redondantes. Les notebooks Fabric exploitent Spark en coulisses pour
7:19
Speaker 3: rendre cela possible. Ainsi, au lieu d'extraire 400 millions de
7:23
Speaker 3: lignes dans votre session de notebook, Spark exécute cette agrégation
7:26
Speaker 3: dans l'environnement Lakehouse et ne renvoie que les résultats dont
7:29
Speaker 3: votre modèle a besoin. Si vous travaillez en Python ou R,
7:33
Speaker 3: vous ne partez pas non plus d'une coquille nue. Fabric
7:37
Speaker 3: est fourni avec une pile de bibliothèques déjà intégrées pour
7:39
Speaker 3: les travaux à grande échelle. PySpark, Pandas sur Spark, Sparkleer, etc.
7:43
Speaker 3: Le traitement distribué et donc une option dès l'ouverture d'un
7:47
Speaker 3: nouveau notebook. Cela est important lorsque vous joignez des tables
7:51
Speaker 3: de faits et de dimensions de plusieurs centaines de gigaoctets
7:55
Speaker 3: ou lorsque vous devez calculer des fenêtres glissantes sur plusieurs
7:57
Speaker 3: années d'historique client. Dès que la requête est terminée, l'ensemble
8:01
Speaker 3: de des agrégés nettoyés est prêt à être directement transféré
8:04
Speaker 3: dans votre processus d'ingénierie des fonctionnalités. Il n'y a pas
8:06
Speaker 3: de phase intermédiaire d'enregistrement sur disque, de vérification du schéma
8:09
Speaker 3: et de réimportation dans un notebook d'entraînement local. Vous avez
8:12
Speaker 3: sauté une étape de préparation entière. équipes passaient auparavant des
8:15
Speaker 3: jours à aligner les colonnes et à réexécuter les filtres
8:17
Speaker 3: lorsque les données sources changeaient. Avec cette configuration, elles peuvent
8:20
Speaker 3: explorer des combinaisons de fonctionnalités pour le modèle, dans l'heure
8:23
Speaker 3: même où les données brutes étaient mises à jour. Et
8:26
Speaker 3: c'est là que cela devient intéressant, car une fois que
8:27
Speaker 3: vous avez des ensembles de données volumineux et propres, qui
8:30
Speaker 3: circulent directement dans votre session de notebook, votre façon de penser,
8:33
Speaker 3: la création de fonctionnalités commence à changer, à générer des
8:37
Speaker 3: fonctionnalités sélection de modèles à grande échelle. Votre ensemble de
8:39
Speaker 3: données peut être suffisamment volumineux pour prédire à peu près tout,
8:41
Speaker 3: mais cela ne signifie pas que chaque colonne qu'il contient
8:43
Speaker 3: appartient à votre modèle. La différence entre un modèle qui
8:47
Speaker 3: produit des prédictions significatives et un autre qui crache du
8:49
Speaker 3: bruit se résume souvent à la manière dont vous sélectionnez
8:51
Speaker 3: et façonnez vos fonctionnalités. L'échelle vous offre des possibilités, mais
8:55
Speaker 3: elle amplifie également les erreurs. Avec des ensembles de données volumineux,
8:59
Speaker 3: envoyer tous les champs bruits à votre algorithme n'est pas
9:01
Speaker 3: seulement désordonné, cela peut également éroder activement les performances. Plus
9:05
Speaker 3: de colonnes signifie plus de paramètres à estimer et plus
9:08
Speaker 3: d'opportunités pour votre modèle d'adapter des bizarreries dans les données
9:12
Speaker 3: d'entraînement qui ne se généralisent pas. Le surapprentissage devient plus
9:16
Speaker 3: facile et non plus difficile lorsque l'ensemble de caractéristiques est surchargé.
9:19
Speaker 3: De plus, chaque variable supplémentaire signifie plus de calculs. Même
9:23
Speaker 3: dans un environnement cloud bien provisionné, 500 caractéristiques brutes ralentiront l'entraînement,
9:27
Speaker 3: augmenteront l'utilisation de la mémoire et compliqueront chaque étape en
9:30
Speaker 3: aval par rapport à un ensemble réduit de 50 caractéristiques
9:32
Speaker 3: bien conçues. Le coup caché n'est pas toujours évident à
9:35
Speaker 3: voir à partir de l'horloge. Cette exécution de 500 caractéristiques
9:38
Speaker 3: peut se terminer sans erreur, mais elle peut vous laisser
9:40
Speaker 3: avec un modèle légèrement plus précis sur les données d'entraînement
9:43
Speaker 3: et nettement moins précis sur les nouvelles données. Lorsque vous
9:48
Speaker 3: réduisez et affinez ces caractéristiques, fusionnez des variables associées et
9:51
Speaker 3: encodez des catégories plus efficacement ou créez des agrégats qui
9:54
Speaker 3: capturent des modèles au lieu de valeur brute, vous réduisez
9:56
Speaker 3: le temps de calcul tout en améliorant réellement la capacité...
10:00
Speaker 3: du modèle à prédire l'avenir. Certaines formes de données rendent
10:05
Speaker 3: cela plus difficile. Les fonctionnalités à cardinalité élevées telles que
10:08
Speaker 3: les références de produits uniques ou les identifiants de clients
10:11
Speaker 3: peuvent exploser en milliers de colonnes codées si elles sont
10:13
Speaker 3: traitées de manière naïve. Les données éparses où la plupart
10:17
Speaker 3: des champs sont vides pour la plupart des enregistrements peuvent
10:20
Speaker 3: masquer des signaux utiles, mais consomment des ressources pour stocker
10:23
Speaker 3: et traiter principalement les valeurs manquantes. Dans un domaine comme
10:27
Speaker 3: la prédiction du taux de désabonnement des clients, vous pouvez
10:29
Speaker 3: également avoir des modèles temporels, des sigles d'achat, une activité saisonnière,
10:33
Speaker 3: des phases d'intégration qui n'apparaissent pas dans les champs statiques ordinaires.
10:38
Speaker 3: L'ingénierie des fonctionnalités à cette échelle implique de concevoir des
10:41
Speaker 3: transformations qui condensent et font apparaître les modèles sans inonder
10:43
Speaker 3: l'ensemble de données de bruit. C'est là que les outils
10:46
Speaker 3: d'automatisation et de traitement distribués commencent à porter leurs fruits.
10:50
Speaker 3: Des bibliothèques telles que Feature Tools peuvent automatiser la génération
10:52
Speaker 3: d'agrégats et de fonctionnalités glissantes sur de grands ensembles de
10:54
Speaker 3: données relationnelles. Dans Fabric, ces transformations peuvent s'exécuter sur Spark,
10:59
Speaker 3: ce qui vous permet de créer à grande échelle des
11:00
Speaker 3: centaines de fonctionnalités candidates, sans tout mettre dans la mémoire
11:03
Speaker 3: d'une seule machine. Les regroupements basés sur le temps, les
11:07
Speaker 3: agrégats au niveau du client, les ratios entre les métriques associées,
11:10
Speaker 3: tout cela peut être créé et testé de manière itérative,
11:12
Speaker 3: sans interrompre votre flux de travail. Une fois que vous
11:15
Speaker 3: avez organisé votre ensemble de fonctionnalités, la sélection du modèle
11:17
Speaker 3: devient un exercice d'équilibre en soi. Différents algorithmes interagissent avec
11:21
Speaker 3: des données à grande échelle de différentes manières. Les frameworks
11:24
Speaker 3: de boosting de Grady, tels que XGBoost ou LightJBM, peuvent
11:26
Speaker 3: gérer efficacement de grands ensembles de données tabulaires, mais ils
11:29
Speaker 3: paient toujours le coup par fonctionnalités, en termes de mémoire
11:31
Speaker 3: et de temps d'itération. La régression logistique évolue bien et
11:35
Speaker 3: s'entraîne rapidement, mais elle ne capturera pas les relations non
11:38
Speaker 3: linéaires complexes, à moins que vous ne les intégriez vous-même
11:40
Speaker 3: dans les fonctionnalités. Les modèles d'apprentissage profond peuvent en théorie
11:44
Speaker 3: découvrir des modèles plus riches, mais ils nécessitent également plus
11:46
Speaker 3: de réglages et de calculs. Dans l'environnement fabrique, vous pouvez
11:49
Speaker 3: provisionner cela, mais vous devrez évaluer si les gains justifient
11:52
Speaker 3: le coût de la formation. La bonne nouvelle est qu'avec
11:55
Speaker 3: les notebooks fabriques directement liés à votre lakehouse, vous pouvez
11:57
Speaker 3: tester ces stratégies sans les goulots d'étranglement traditionnels. Vous pouvez
12:01
Speaker 3: lancer plusieurs cycles d'entraînement avec différents ensembles de fonctionnalités et
12:04
Speaker 3: algorithmes en utilisant-les, même données sous-jacentes sans avoir à les
12:08
Speaker 3: recharger ou à les remodeler à chaque tentative. Cette capacité
12:11
Speaker 3: à itérer rapidement signifie que vous n'êtes pas obligé de
12:13
Speaker 3: deviner quelle approche fonctionnera le mieux. Vous pouvez mesurer et décider.
12:18
Speaker 3: Des fonctionnalités bien conçues et adaptées à la bonne architecture
12:20
Speaker 3: de modèle peuvent réduire considérablement les temps d'exécution, diminuer l'utilisation
12:23
Speaker 3: de la mémoire et améliorer la précision des données invisibles.
12:27
Speaker 3: Vous obtenez des cycles d'expérimentation plus rapides et des résultats
12:29
Speaker 3: plus fiables. Et vous consacrez votre budget des calculs à
12:32
Speaker 3: la formation qui compte réellement plutôt qu'au traitement de tâches inutiles. A.
12:37
Speaker 3: Vient ensuite l'étape qui permet de maintenir la productivité de
12:39
Speaker 3: ces exécutions à grande échelle, en les surveillant et en
12:41
Speaker 3: les évaluant en temps réel afin que vous sachiez exactement
12:43
Speaker 3: ce qui se passe pendant que le modèle s'entraîne dans
12:45
Speaker 3: le cloud. B. Formation, surveillance, évaluation à l'échelle du cloud.
12:50
Speaker 3: La formation sur des gigaoctets de données semble être un
12:52
Speaker 3: rêve jusqu'à ce que vous vous demandiez si la tâche
12:53
Speaker 3: est toujours en cours d'exécution ou si elle s'est arrêtée
12:55
Speaker 3: il y a une heure. Lorsque tout se passe dans
12:58
Speaker 3: le cloud, vous perdez le retour d'informations instantanées que vous
13:00
Speaker 3: obtenez en regardant les journaux défiler dans un terminal local.
13:04
Speaker 3: C'est bien si la tâche se termine en quelques minutes.
13:06
Speaker 3: C'est un problème lorsque le temps passe en heures et
13:08
Speaker 3: que vous ne savez pas si vous progressez. L'exécution de
13:11
Speaker 3: la formation dans un environnement distant change votre façon de
13:14
Speaker 3: penser la visibilité. Dans une session locale, vous détectez immédiatement
13:17
Speaker 3: les problèmes. Valeurs manquantes dans un champ? Incompatibilité de type
13:21
Speaker 3: de données ou blocage d'importation. Sur un cluster cloud, cette
13:25
Speaker 3: même erreur peut être enfouie dans un fichier journal que
13:27
Speaker 3: vous ne vérifiez que bien plus tard. Comme les ressources
13:30
Speaker 3: sont provisionnées et construites pendant que le processus est techniquement
13:32
Speaker 3: en cours d'exécution, chaque minute d'une exécution qui échoue représente
13:35
Speaker 3: quand même une dépense d'argent. Le coût d'une détection tardive
13:38
Speaker 3: d'un problème s'accumule rapidement. J'ai vu une tâche de prédiction
13:41
Speaker 3: de désabonnement qui a été lancée un vendredi soir avec
13:43
Speaker 3: une estimation de 8 heures, 1 à 1. Le lundi matin,
13:47
Speaker 3: l'équipe s'est rendue compte qu'elle avait échoué, avant même que
13:49
Speaker 3: la première époque ne commence, car une colonne qui aurait
13:51
Speaker 3: dû être numérique avait été chargée en tant que texte.
13:54
Speaker 3: Le temps d'exécution va être? 10 minutes perdues au départ,
13:56
Speaker 3: 8 heures facturées au compteur. C'est le genre d'erreur qui
13:59
Speaker 3: érode la confiance dans le processus et ralentit considérablement les
14:02
Speaker 3: cycles d'itération. Fabric s'attaque à ce problème grâce à une
14:06
Speaker 3: surveillance des tâches. En temps réel que vous pouvez ouvrir
14:08
Speaker 3: avec votre notebook. Vous obtenez des mesures en direct sur
14:12
Speaker 3: la consommation de mémoire, l'utilisation du processeur et la progression
14:15
Speaker 3: au cours des époques d'entraînement, Les journaux sont transmis au
14:18
Speaker 3: fur et à mesure de l'exécution de la tâche, ce
14:20
Speaker 3: qui vous permet de repérer les avertissements ou les erreurs
14:22
Speaker 3: avant qu'ils ne se transforment en échec complet. Si quelque
14:25
Speaker 3: chose ne va pas, vous pouvez arrêter l'exécution immédiatement au
14:27
Speaker 3: lieu d'apprendre à vos dépens plus tard. Mais il ne
14:30
Speaker 3: s'agit pas seulement d'observer. Vous pouvez configurer des points de
14:32
Speaker 3: contrôle pendant l'entraînement afin que l'état du modèle soit enregistré périquement.
14:35
Speaker 3: Si la tâche s'arrête, que ce soit en raison d'une erreur,
14:38
Speaker 3: d'une limite de ressources ou d'une interruption intentionnelle, vous pouvez
14:40
Speaker 3: redémarrer à partir du dernier point de contrôle au lieu
14:42
Speaker 3: de tout recommencer à zéro. Le contrôle de version joue
14:45
Speaker 3: également un rôle ici. En enregistrant les versions de modèles
14:47
Speaker 3: entraînées avec leurs paramètres et les divisions de données associées,
14:50
Speaker 3: vous pouvez revoir une configuration passée sans avoir à recréer
14:53
Speaker 3: l'intégralité de l'environnement qui l'a produite. Les sauvegardes intermédiaires ne
14:58
Speaker 3: sont pas seulement une bonne protection, elles rendent les expérimentations
15:00
Speaker 3: à grande échelle possibles. Vous pouvez bifurquer vers un point
15:04
Speaker 3: de contrôle prometteur et essayer différents hyperparamètres sans avoir à
15:06
Speaker 3: payer le temps nécessaire au rechargement et à la réentraînement
15:09
Speaker 3: du modèle de base. Avec des ensembles de données de
15:12
Speaker 3: plusieurs gigaoctets, cela peut faire la différence entre exécuter trois
15:14
Speaker 3: expériences en une journée ou une seule. Une fois le
15:16
Speaker 3: modèle terminé, l'évaluation à cette échelle s'accompagne de son lot
15:19
Speaker 3: de défis. Vous ne pouvez pas toujours obtenir un score
15:22
Speaker 3: par rapport à l'ensemble de tests complets en une seule
15:24
Speaker 3: passe sans ralentir considérablement les choses. L'échantillonnage équilibré est utile
15:28
Speaker 3: ici car il permet de conserver les proportions des classes
15:29
Speaker 3: tout en réduisant l'ensemble de données à une taille qui
15:31
Speaker 3: permet une évaluation plus rapide. Pour une plus grande précision,
15:34
Speaker 3: l'évaluation distribuée vous permet de répartir la tâche de notation
15:36
Speaker 3: sur le cluster avec des résultats agrégés automatiquement. Fabric prend
15:41
Speaker 3: en charge les bibliothèques Python telles que MLib et les
15:43
Speaker 3: workflows SeekItLearn distribués pour rendre cela possible. Au lieu d'attendre
15:48
Speaker 3: qu'une seule machine exécute des métriques sur des centaines de
15:50
Speaker 3: millions d'enregistrements, vous pouvez répartir la tâche et récupérer les
15:53
Speaker 3: scores consolidés d'exactitude, de précision, de rappel ou de F1
15:56
Speaker 3: en une fraction du temps. Les données ne quittent jamais l'acte,
15:59
Speaker 3: vous n'avez donc pas à gérer les exportations d'ensemble de
16:01
Speaker 3: tests ni les fusions manuelles.