Intelligence artificielle dans l'ingénierie ML : rôle, limites, validation et responsabilité

Gains :

• Être capable de distinguer où dans le flux de travail ML (code, données, document) l'intelligence artificielle permet de gagner du temps avec un faible risque, et où les décisions telles que les métriques/données/mise en production sont laissées à l'humain, en fonction du niveau de risque de la tâche.
• Capacité à appliquer une discipline qui vérifie chaque sortie de l'IA en la connectant à la source, en la réexécutant, en la mesurant et en la faisant passer à travers un filtre d'ingénierie.
• Capacité à prendre l'habitude de ne pas envoyer de données brutes confidentielles et personnelles à des outils externes, d'utiliser des outils approuvés par l'entreprise et de traiter les problèmes de sécurité uniquement à des fins défensives.

L'intelligence artificielle dans l'ingénierie de l'apprentissage automatique : rôle, limites, validation et responsabilité

Un ingénieur en apprentissage automatique (ingénieur ML : un professionnel du logiciel qui conçoit, forme et met en production des modèles qui apprennent des données) travaille aujourd'hui avec un autre outil d'intelligence artificielle à chaque étape de son travail. Un assistant de codage est en vigueur lors de l'écriture du code, un modèle de conversation lors de l'exploration des données et un grand modèle de langage (LLM : un réseau neuronal avec des milliards de paramètres qui comprend et produit du texte) lors de la production de documentation. Ce module considère l'intelligence artificielle à la fois comme le produit développé et comme l'outil de travail quotidien d'un ingénieur ML. Il fonctionne en délimitant clairement les limites des responsabilités sans mélanger les deux rôles.

Dans cette première unité, nous répondons à la question fondamentale : où, dans l'ingénierie ML, l'intelligence artificielle permet-elle de gagner du temps réel, et où devons-nous laisser la décision aux humains ? La réponse est au cœur de la discipline de l’ingénierie : celui qui fait est rapide, celui qui vérifie est responsable.

Où l’intelligence artificielle est-elle utile dans l’ingénierie ML ?

Un projet ML passe à peu près par les lignes suivantes : collecte de données, nettoyage des données, ingénierie des fonctionnalités (traduction des données brutes en signaux numériques que le modèle peut comprendre), formation du modèle, évaluation, déploiement (déploiement : ouverture du modèle à l'utilisateur réel) et surveillance. L’IA est utile à chaque arrêt sur cette ligne, mais son niveau d’autorité varie.

Domaines très enrichissants et à faible risque : produire un squelette de code, rédiger une fonction de transformation de données, interpréter les messages de log, décrire une trace de pile, résumer des notes d'expérience, rédiger de la documentation et des README, proposer un cas de test. Ici, les erreurs de l’intelligence artificielle sont peu coûteuses ; car le résultat sera déjà soumis à des tests et à une révision.

Domaines à haut risque : décider quelles données seront envoyées en formation, confirmer si un modèle doit être mis en production, juger qu'une métrique est "assez bonne", décision de traiter des données personnelles, classer une vulnérabilité de sécurité comme "indésirable". Ceux-ci affectent l’argent, la confidentialité, la responsabilité juridique et la confiance des utilisateurs. L'intelligence artificielle donne ici des suggestions ; La décision est prise par l'ingénieur compétent et l'équipe responsable.

Astuce : avant de confier une tâche à l'IA, demandez-vous : « Quel est le coût si ce résultat est erroné, et avec quelle facilité quelqu'un pourra-t-il détecter l'erreur ? » Si le prix est bas et que la capture est facile, transmettez-le. Si le prix est élevé ou si la capture est difficile, utilisez l'IA uniquement pour le draft et vous décidez.

Discipline de vérification : trois étapes

Dans l’ingénierie ML, les résultats de l’IA ne sont jamais un « travail fini » ; C'est un brouillon. Exécutez chaque sortie en suivant ces trois étapes :

1. Connectez-le à la source. Si le modèle indique un nombre, un seuil ou une « meilleure pratique », basez-le sur la documentation officielle, la valeur réelle dans la base de code ou une métrique mesurée. L'« ajustement du modèle » (hallucination : la production confiante d'informations non réelles par le modèle de langage) est le plus souvent capturé ici.
2. Redémarrez et mesurez. Exécutez le code généré, recalculez la métrique qu'il produit sur votre propre ensemble de tests, validez la requête SQL proposée sur un petit échantillon. Un code qui ne fonctionne pas ne vaut rien, même s'il a l'air sympa.
3. Passez-le à travers un filtre technique. Le résultat tient-il la route à grande échelle ? Les cas extrêmes (données vides, entrées très volumineuses, champs manquants) ont-ils été pris en compte ? Y a-t-il une faille de sécurité et de confidentialité ? Seule une personne connaissant le domaine peut réaliser cette étape.

Invite faible/Invite forte

Invite faible : « Écrivez-moi un code de formation modèle. »

Invite puissante : "Écrivez un script de formation pour la classification binaire avec scikit-learn. Entrée : data/train.parquet, colonne cible is_churn. Il existe un déséquilibre de classe (taux positif ~ 8 %), gérez-le avec class_weight. Utilisez PR-AUC (zone sous la courbe de rappel de précision) comme métrique d'évaluation, car la précision est trompeuse pour les données déséquilibrées. Fixez la graine aléatoire à 42. Testez à la fin de l'ensemble d'impression de code PR-AUC. "

Différence : la deuxième tâche rapide contient la vérité des données, la métrique correcte, les informations sur le déséquilibre et les exigences de répétabilité. C'est à partir de ce contexte que le résultat est vérifiable et utilisable.

Confidentialité et sécurité des données : la première responsabilité de l'ingénieur

L’ingénieur ML touche souvent aux données les plus sensibles de l’entreprise : dossiers clients, historique des transactions, données de santé ou financières, logs des systèmes de production. Trois règles pour transmettre des données aux outils d’intelligence artificielle :

• N'envoyez pas de données personnelles et confidentielles brutes à des outils externes. Par exemple, au lieu de coller les e-mails des clients dans l'invite, envoyez le schéma et des échantillons factices (synthétiques). Utilisez un exemple masqué comme « ex : ahmet@example.com » au lieu de données réelles.
• Utilisez des véhicules approuvés par l'entreprise. Choisissez des outils dont le contrat précise clairement où les données sont traitées, si elles sont stockées, si elles sont utilisées à des fins éducatives ou non. Le traitement des données d'entreprise avec un compte personnel constitue une violation dans la plupart des entreprises.
• Politique de données minimales. Donnez le contexte minimum nécessaire pour résoudre la tâche. Pas le tableau entier, mais les 5 colonnes et le schéma pertinents.

Attention : Supposons que le texte que vous donnez à un modèle de langage ne puisse pas être annulé. N'envoyez pas de données personnelles brutes en pensant « Je les supprimerai plus tard » ; Le risque est survenu dès l'envoi.

Utilisation défensive dans le domaine de la sécurité

Les ingénieurs ML installent souvent des systèmes de sécurité : détection des fraudes, classification du trafic malveillant, authentification. Tout au long de ce module, nous abordons les questions de sécurité à des fins défensives uniquement : détection de l'attaque, renforcement du système, fermeture de la vulnérabilité. Utiliser l’intelligence artificielle pour un accès non autorisé, une fuite de données ou une intervention non autorisée dans le système de quelqu’un d’autre est à la fois illégal et contraire à l’éthique professionnelle. Lorsque vous découvrez une vulnérabilité, la bonne façon est de la signaler de manière responsable et de la corriger ; pas exploiter.

trois mini-cases

Cas 1 - Temps gagné. Un ingénieur ML passerait normalement une demi-journée à effectuer une analyse exploratoire des données (EDA) d'un ensemble de données de 40 colonnes. Il a transmis le schéma et la sortie df.describe() à l'intelligence artificielle et a demandé : "Quelles colonnes ont un taux de valeurs aberrantes et manquantes élevé, quelles transformations recommandez-vous ?" En 20 minutes, il a reçu une liste prioritaire, vérifiant chaque élément avec son propre code. Économie : ~3 heures, faible risque d'erreur car mesuré à chaque réclamation.

Cas 2 – Erreur détectée. "La précision de l'entraînement est de 99 %, c'est génial", a déclaré le modèle à un assistant de chat. L'ingénieur a appliqué la troisième étape (filtre d'ingénierie) et s'est rendu compte : la colonne cible avait accidentellement divulgué des attributs (fuite de données : le modèle voit des informations qu'il ne devrait pas voir lors de l'entraînement). Les performances réelles étaient bien inférieures. C’est le scepticisme de l’ingénieur, et non la « grande » interprétation de l’IA, qui a sauvé la tâche.

Cas 3 – Prévention des atteintes à la vie privée. Une équipe colle les journaux d'erreurs de production dans un modèle externe et dit « corrigez cette erreur ». Il y avait des numéros d'identification des clients dans les journaux. L'équipe a établi pour règle d'écrire un petit script qui masque d'abord les journaux (en faisant leurs numéros d'identification ***) et de les envoyer de cette façon. Le risque de brèche a disparu, la rapidité de l'assistance n'a pas changé.

Modèles copiables

Tâche : [que faire, phrase unique]Contexte : [schéma de données, taille, contraintes ; AUCUNE donnée personnelle RÉELLE]Contraintes : [langue/bibliothèque, performances, reproductibilité]Metriques : [comment mesurer le succès]Résultat souhaité : [code/description/liste] et pourquoi dans ce format

Consultez ce code. Évaluez non seulement son fonctionnement, mais également en termes de : 1) Cas extrêmes (entrée vide, colonne manquante, données très volumineuses) 2) Risque de fuite de données 3) Reproductibilité (graine, version) Suggérez des solutions pour chaque problème que vous rencontrez. Cochez « vérifier » là où vous n'êtes pas sûr. Code : [code]

Interprétez le résultat de cette métrique, mais demandez-vous d'abord : cette métrique est-elle correcte pour ce problème ? Problème : [classification équilibrée/déséquilibrée, régression, classement...] Métrique et valeur signalées : [par ex. précision 0,99]Quelle métrique recommanderiez-vous et pourquoi, et quels signes dois-je rechercher pour me faire douter du résultat actuel ?

Vérifiez s'il y a des informations personnelles/confidentielles dans les données que je fournirai à l'invite suivante. Listez les champs (nom, e-mail, numéro d'identification, téléphone, adresse) qui doivent être masqués dans le texte ci-dessous. Texte : [texte]

Tableau des rôles et des autorités

Quête

Le rôle de l'intelligence artificielle

Propriétaire de la décision

Squelette de code / fonction de transformation

générateur de projet

Ingénieur (avis)

EDA / résumé des données

accélérateur

Ingénieur (vérifie par mesure)

Interprétation métrique

Suggestions

ingénieur

Quelles données seront utilisées dans la formation ?

Suggestions

Équipe + propriétaire des données

Mettre le modèle en production

Rappel de la liste de contrôle

Ingénieur responsable + équipe

Traitement des données personnelles

Aucun (non utilisé)

Juridique + responsable du traitement

Erreurs courantes

• Utiliser la sortie sans la valider. L'erreur la plus courante et la plus coûteuse. Un code ou une métrique qui semble joli ne veut pas dire qu'il est correct.
• Coller des données confidentielles brutes dans l’outil. Une fois envoyé, il ne peut être repris.
• S'appuyer sur la mauvaise métrique. Les mesures incompatibles telles que la précision des données déséquilibrées et le RMSE dans les problèmes de classement sont trompeuses.
• Confondre l’intelligence artificielle avec le décideur. Il donne des suggestions ; La responsabilité incombe au signataire.
• Invite sans contexte. Des requêtes ambiguës telles que « écrire un modèle » produisent un résultat invérifiable.

En résumé

L’intelligence artificielle est à la fois le produit développé par l’ingénieur ML et son réplicateur quotidien. Sa valeur est la plus élevée dans les tâches à faible risque et facilement vérifiables telles que le code-données-document ; Les décisions affectant l’argent, la vie privée et la sécurité appartiennent à la personne. Connectez chaque sortie à la source, mesurez à nouveau, passez à travers le filtre technique. Protégez les données confidentielles, utilisez des véhicules homologués, travaillez en sécurité à des fins défensives uniquement. Cette discipline est la base de toutes les unités suivantes.

Tâche de candidature

Choisissez une tâche dans votre propre projet (par exemple, écrire une fonction de nettoyage de données). Écrivez d’abord une invite faible, puis écrivez une invite forte en utilisant le modèle de cette unité. Prenez les deux sorties, appliquez une vérification en trois étapes (lien vers la source, réexécution, filtre d'ingénierie). Notez quelle invite enregistre combien de minutes et combien de corrections.

liste de contrôle

• [ ] J'ai déterminé le niveau de risque (faible/élevé) de ma tâche.
• [ ] Je n'ai mis aucune donnée personnelle/confidentielle réelle dans l'invite ; Je l'ai masqué ou utilisé un échantillon synthétique.
• [ ] J'ai connecté la sortie à la source, je l'ai réexécutée, je l'ai filtrée d'un point de vue technique.
• [ ] J'ai vérifié que j'avais sélectionné la bonne métrique.
• [ ] J'ai pris la décision critique (mise en production, traitement des données) moi-même/avec l'équipe, je ne l'ai pas laissé à l'intelligence artificielle.
• [ ] J'ai utilisé un véhicule approuvé par l'entreprise.