Qu'est-ce que le « shift left » ? Le nouveau bon sens pour protéger la qualité des données à l'ère de l'IA.
Bonjour,AIJe suis John, un blogueur qui explique la technologie d'une manière facile à comprendre.
Récemment, l'IA est devenue de plus en plus intelligente et indispensable à notre travail et à notre vie. Cependant, pour qu'elle fonctionne correctement,« Données de haute qualité »Cependant, lors du traitement de ces données, des problèmes inattendus surviennent souvent. De petites corrections apportées par les développeurs avec de bonnes intentions peuvent parfois entraîner de gros problèmes par la suite.
Aujourd’hui, je voudrais présenter une nouvelle façon de penser pour prévenir de tels problèmes liés aux données.« Décalage vers la gauche »Je vais l'expliquer d'une manière que tout le monde puisse comprendre !
Quelle est la différence entre la gestion des données d’hier et d’aujourd’hui ?
Dans les temps anciens du développement de systèmes,Base de donnéesLe format des données (schéma) était strictement défini par des experts du domaine. Les développeurs n'avaient d'autre choix que de suivre ces règles et de supporter les petits inconvénients rencontrés. Cette méthode s'avérait très chronophage et rigide.
D’autre part, dans le développement moderne, les développeurs ont plus de liberté pour générer des données, en particulier dans l’IA etl'analyse des donnéesDans le monde de la science des données, l'approche dominante est celle du « schéma à la lecture », qui consiste à collecter d'abord les données, puis à déterminer leur utilisation. Cette approche a accéléré le développement, mais a également engendré de nouveaux problèmes.
C'est« Cela posera des problèmes aux personnes qui utiliseront les données plus tard. »Le problème est que les développeurs peuvent modifier librement les données, ce qui implique un risque de panne soudaine des outils d'analyse et des modèles d'IA qui les utilisent. Par conséquent, les développeurs craignent de casser quelque chose, ce qui les rend réticents à apporter des modifications, créant ainsi un dilemme.
L'histoire d'un ingénieur : la tragédie d'une seule ligne de code
Laissez-moi vous raconter une histoire précise. C'est une histoire qui s'est réellement produite (ou qui a pu se produire) dans une certaine entreprise.
Jez, un ingénieur talentueux de notre équipe support, a examiné les données du système et a remarqué quelque chose : les identifiants de ticket contenaient toujours la chaîne « zendesk: ». Il s'agissait d'un vestige de notre migration d'un ancien système il y a dix ans, et il était désormais totalement inutile.
« Ces huit lettres sont du gaspillage. »
Avec cela à l’esprit, Jez a modifié une seule ligne de code pour supprimer le préfixe.
S'il n'y avait pas de « contrat de données »...
La solution de Jez a passé les tests sans problème et a été directement mise en production. Mais les résultats ont été désastreux.
- Un processus (appelé tâche ETL) consistait à écrire des identifiants dans un fichier de données qui n’avait plus leurs préfixes.
- Un modèle d’IA devient incapable de reconnaître de nouvelles données,40 % de l'analyse manque silencieusementJ'ai commencé à le faire.
- Étant donné que les règles de conformité impliquent que les données ne peuvent pas être effacées une fois écrites, les ingénieurs ont été contraints d’effectuer un travail de révision complexe pour s’adapter aux anciens et aux nouveaux formats de données.
- Une petite amélioration qui n'aurait dû prendre que 30 secondesUne semaine de chaos entre équipesIl s'est développé en.
Et Jez restera dans les mémoires comme le gars qui a tout cassé avec une seule ligne de code.
S'il y avait un « contrat de données »...
Alors, que se serait-il passé s’il y avait eu un système appelé « contrat de données » ?
Qu'est-ce qu'un « Contrat de données » ?Une promesse qui prédétermine les règles selon lesquelles « ces données doivent être dans ce format »で す.
Au moment où Jez a modifié le code et a essayé de le sauvegarder, un message d'erreur est immédiatement apparu sur l'écran de son PC.
« ❌ Échec de la vérification de l'accord : le champ ticket_id ne correspond pas à la règle « ^zendesk:\d+$ » »
Il a même montré quels systèmes seraient affectés par ce changement.
- finance.dashboard.ticket_volume (Tableau de bord financier)
- ml.modèle.ticket_attribution (Apprentissage automatiqueModèle)
Jez a vu cela et a rapidement inversé le changement, perdant seulement 30 secondes et évitant un désastre majeur.
« Les données sont du code » – Pensée à gauche
Cette expérience démontre l’importance de la pensée « à gauche ».
Shift Left en bref« Vérifions les problèmes plus tôt (sur le côté gauche) »L'idée est la suivante : si l'on considère le processus de développement comme une chronologie de gauche à droite, plus un problème est détecté tardivement (à droite), plus le coût de sa résolution est élevé. Il est donc conseillé de détecter les problèmes plus tôt, lors de l'écriture du code (à gauche).
Le raisonnement derrière cela est que « les données proviennent du code, doncTraiter les données comme du code« Tout comme les bugs de code peuvent être détectés tôt grâce aux tests, les incohérences dans les données doivent être détectées dès qu'elles se produisent.
Une boîte à outils pour se déplacer à gauche
Les technologies et outils suivants seront utilisés pour réaliser ce « déplacement vers la gauche des données ».
- Analyse statique :Avant d’exécuter un programme, il analyse le code pour déterminer quelles données seront créées.
- Accord sur les données :Comme dans l'exemple précédent, la forme, la signification et le propriétaire des données sont définis comme des règles, et ceux-ci sont automatiquement vérifiés à l'aide de CI (un système qui teste automatiquement les modifications de code).
- Analyse d'impact du changement :Il alerte les développeurs sur la manière dont une correction de code apparemment anodine peut affecter les modèles d'IA en aval, etc.
- La politique en tant que code :Les règles telles que la manière dont les informations personnelles sont traitées sont automatiquement vérifiées pendant le développement, plutôt que d'être auditées après coup.
Cela signifie que si des changements comme celui apporté par Jez affectent des systèmes critiques, nous pouvons les détecter avant qu'ils ne causent des problèmes.
Commentaires de l'auteur
On voit bien le « décalage à gauche » des données ! C'est bien ce que l'on ressent. Au lieu de se précipiter pour résoudre les problèmes après qu'ils surviennent, on les prévient avant qu'ils ne surviennent dans un système. C'est exactement comme « mieux vaut prévenir que guérir ». Surtout dans le monde de l'IA, où la qualité des données est déterminante, cette façon de penser risque de se généraliser. Nous entrevoyons un avenir prometteur où les développeurs pourront créer de meilleures choses plus rapidement et en toute sérénité.
Cet article est basé sur les articles originaux suivants et est résumé du point de vue de l'auteur :
Il est temps de déplacer les données vers la gauche
