Machine learning dans le contrôle industriel : quand est-ce rentable ?

IA et machine learning

Un poste de contrôle signale trop de fausses alarmes, ou certains défauts passent régulièrement à travers les mailles. Le mot « machine learning » tombe vite. Mais ce n'est pas l'algorithme qui décide si l'effort en vaut la peine, ce sont les données, le processus et des objectifs clairs.

Là où le machine learning a ses points forts

Les méthodes par apprentissage montrent leurs forces lorsque les défauts se laissent difficilement traduire en règles : rayures sur des surfaces structurées, décolorations, défauts sur des produits naturels ou des textiles, soudures avec de nombreuses variantes admissibles. Elles aident aussi lorsque les pièces bonnes elles-mêmes ont des aspects très différents.

Le machine learning est moins pertinent là où il faut mesurer avec exactitude. Les méthodes classiques déterminent les dimensions, les distances et les positions avec plus de précision et de traçabilité.

Trois conditions pour en tirer profit

• Données : suffisamment d'images couvrant la dispersion réelle – lots, équipes, encrassement, vieillissement de l'éclairage. S'y ajoutent des images de défauts en nombre suffisant, proprement annotées.
• Prise de vue stable : le machine learning ne remplace ni une caméra adaptée ni un bon éclairage. Plus la prise de vue est homogène, moins le modèle a besoin de données.
• Objectif clair : quel taux de défauts non détectés (glissement) et quel taux de pseudo-rebuts (pièces bonnes écartées à tort) sont acceptables ? Sans ces valeurs, aucun modèle ne peut être réceptionné de façon pertinente.

Quand les images de défauts manquent : la détection d'anomalies

Dans de nombreuses productions, les défauts sont rares. Il y a des milliers de pièces bonnes, mais presque pas de pièces mauvaises. Les méthodes de détection d'anomalies aident ici : elles apprennent seulement à quoi ressemble une pièce bonne et signalent tout ce qui s'en écarte. Le jeu de données public MVTec AD a été constitué précisément pour de telles tâches de contrôle industriel. Il contient, par catégorie, des images d'entraînement sans défaut et des images de test présentant différents types de défauts. Pour démarrer, la détection d'anomalies est souvent plus réaliste qu'un classificateur qui doit connaître chaque type de défaut.

Est-ce rentable ? Une évaluation rapide

Évaluer honnêtement plutôt que se laisser impressionner

Un taux de réussite seul dit peu de chose. Ce qui compte, c'est quels défauts le modèle manque et à quelle fréquence il rejette des pièces bonnes. Mesurez les deux valeurs séparément, et ce sur des images de test que le modèle n'a jamais vues pendant l'entraînement :

# Chaque verdict : (vérité, modèle), valeurs "iO" (conforme) ou "niO" (non conforme)

def pruefkennzahlen(urteile):

    schlechte = [modell for wahr, modell in urteile if wahr == "niO"]

    gute = [modell for wahr, modell in urteile if wahr == "iO"]

    schlupf = schlechte.count("iO") / max(len(schlechte), 1)

    pseudoausschuss = gute.count("niO") / max(len(gute), 1)

    return schlupf, pseudoausschuss



urteile = [("iO", "iO"), ("niO", "niO"), ("niO", "iO"), ("iO", "iO")]

schlupf, pseudo = pruefkennzahlen(urteile)

print(f"Schlupf: {schlupf:.1%}, Pseudoausschuss: {pseudo:.1%}")

Un modèle avec peu de pseudo-rebuts qui laisse passer des défauts critiques n'a aucune valeur pour l'assurance qualité. À l'inverse, trop de pseudo-rebuts font grimper les coûts et font perdre au système son acceptation sur la ligne.

Retour d'expérience

Dans un projet pour un fabricant de caméras, nous n'avons pas seulement examiné quels réseaux de neurones résolvent un problème de détection, mais aussi combien de temps dure l'apprentissage en fonction de la qualité souhaitée. Cette vision coûts-bénéfices fait partie de toute décision. Dans le projet de recherche HIRAC, un système d'assistance par IA pour fauteuils roulants, nous utilisons le deep learning là où le traitement d'images, le retour des capteurs et la manipulation d'objets interagissent – donc là où des règles fixes atteignent leurs limites. Et pour l'amélioration d'images chez un fabricant de capteurs, nous testons d'abord les algorithmes dans MATLAB avant qu'ils n'entrent dans le produit en C#. Tester d'abord, construire ensuite : cela vaut tout autant pour le machine learning.

Erreurs typiques

• Commencer par le modèle plutôt que par les données et les critères de réception.
• Des images d'entraînement et de test issues du même lot ou du même jour – le résultat paraît meilleur qu'il ne l'est sur la ligne.
• Ne communiquer que le taux de réussite global sans séparer glissement et pseudo-rebuts.
• N'avoir aucun plan de réentraînement lorsque le matériau, le fournisseur ou l'éclairage changent.
• Ne pas impliquer les contrôleurs : ceux qui connaissent les défauts devraient aider à annoter les images.
• Mettre en service un modèle sans solution de repli, par exemple sans contrôle manuel des cas incertains.

Tiré de nos projets : étude de réseaux de neurones pour un fabricant de caméras, projet de recherche HIRAC (financé dans le cadre du ZIM, avec la Hochschule Offenburg), amélioration d'images pour un fabricant de capteurs. Pour aller plus loin : MVTec AD – jeu de données pour la détection d'anomalies industrielles.