Automatisation de la reconnaissance de signature à l’aide de Capgemini MLOps Pipeline sur AWS

Reconnaître la signature d’un utilisateur est une étape essentielle dans les transactions bancaires et juridiques. Le processus implique de s’appuyer sur la vérification humaine d’une signature pour établir l’identité d’une personne.
Cependant, cela peut être source d’erreurs, prendre du temps et limiter l’automatisation de nombreuses applications bancaires qui nécessitent une vérification humaine. Le défi peut être résolu en utilisant le traitement d’image, la vision par ordinateur, l’apprentissage automatique et l’apprentissage en profondeur.
L’automatisation de la reconnaissance des signatures permet d’effectuer la plupart des transactions de bout en bout rapidement et avec un minimum d’erreurs, sauf s’il y a un problème avec les données et qu’elles doivent ensuite être examinées par des humains.
Un vérificateur de signature fiable peut réduire le besoin de vérification humaine à moins de 5 % des efforts humains nécessaires manuellement. Un vérificateur de signature permet d’automatiser les processus de vérification de l’identité des utilisateurs, comme l’ouverture de nouveaux comptes ou la signature de documents de prêt immobilier, ou simplement l’encaissement d’un chèque avec une ou plusieurs signatures.
Dans cet article, je vais vous expliquer comment Capgemini utilise l’apprentissage automatique (ML) d’Amazon Web Services (AWS) pour créer des modèles ML afin de vérifier les signatures de différents canaux d’utilisateurs, y compris les applications Web et mobiles. Cela garantit que les organisations peuvent respecter les normes requises, reconnaître l’identité des utilisateurs et évaluer si des vérifications supplémentaires sont nécessaires.
Capgemini est un Partenaire de conseil AWS Premier Tier et Managed Cloud Service Provider (MSP) avec une équipe multiculturelle de 220 000 personnes dans plus de 40 pays. Capgemini possède plus de 12 000 accréditations AWS et plus de 4 900 certifications AWS actives.
Le modèle ML de reconnaissance de signature
Pour définir le modèle, l’équipe de développement ML de Capgemini crée le modèle avec deux jeux de données parallèles pour les données principales et les données d’entrée :
- La golden data est l’ensemble des signatures stockées dans la base de données de la banque suivant les normes de conformité de clarté et de lisibilité.
- L’ensemble de données d’entrée est généralement un ensemble de signatures capturées manuellement à l’aide d’une caméra mobile ou d’un scanner domestique. Ces données ont tendance à inclure des problèmes d’image tels que le flou, l’éblouissement, la distorsion, l’arrière-plan bruyant et la faible résolution.
L’équipe ML construit un pipeline pour transformer les signatures d’entrée au format standard or, puis trouve une méthode de reconnaissance pour vérifier si la signature correspond à l’une des signatures or de la base de données.
Les étapes répertoriées ci-dessous décrivent la mise en œuvre du processus à l’aide d’un pipeline sur site :
- Validation des entrées : L’image d’entrée est d’abord validée par rapport à un ensemble de métriques pour détecter si elle présente l’un des problèmes connus tels que le flou, l’éblouissement, le bruit ou une faible résolution. Si l’image présente l’un de ces problèmes, elle doit être corrigée à l’aide de méthodes de traitement d’image connues, notamment le fenêtrage, le filtrage, la transformation et l’analyse d’histogramme. Ensuite, l’image est réévaluée en utilisant les mêmes métriques pour décider de transmettre l’image au modèle ou de la rejeter, puis demande à l’utilisateur de télécharger à nouveau l’image ou de demander une vérification humaine.
- Pré-traitement des données : Les images de chèques ont généralement plusieurs contenus tels que des noms imprimés, des logos et des numéros de série. Par conséquent, il nécessite un prétraitement pour en extraire la signature, qui comprend le fenêtrage, la détection des contours, l’érosion, la dilatation, la binarisation, la quantification, etc. Capgemini utilise des bibliothèques de traitement du signal 2D telles que SciPy et OpenCV pour le traitement du signal et le traitement des images.
- Ingénierie des fonctionnalités : Capgemini extrait et trouve les caractéristiques les plus informatives des images, telles que les histogrammes RVB et HSV, les composants DFT, les classes de couleurs et la coordination spatiale. Ces fonctionnalités sont utilisées comme entrées pour les algorithmes d’apprentissage (SciPy).
- Sélection du modèle : Il s’agit du processus d’évaluation de plusieurs algorithmes de ML et d’apprentissage en profondeur pour déterminer si l’image est une signature appropriée par rapport à la vérité absolue. Cela comprend l’essai d’une variété d’algorithmes avec différentes configurations et plusieurs méthodes de prétraitement, et la validation croisée des résultats à l’aide de plusieurs ensembles de données à l’aide de Scikitlearn et Keras.
- Optimisation du modèle : Une fois le pipeline ML construit, il est optimisé pour obtenir les meilleurs résultats possibles en utilisant les paramètres intégrés à chaque étape des pipelines. Cela inclut le seuil de binarisation, la granularité de clustering, le nombre de dimensions réduites, les paramètres d’algorithme et les méthodes de validation.
- Validation non fonctionnelle : Une fois que le pipeline ML s’est avéré efficace, il est important de valider le temps de réponse, les besoins de calcul, la mémoire requise et le potentiel d’évolutivité pour faire face à la surcharge et au stress (Jmeter).
- Déploiement en tant qu’API : Le pipeline ML est déployé en tant qu’API reposante à l’aide de Flask hébergé à l’aide de Gunicorn ou FastAPI avec une interface Web proxy utilisant NGINX.
Le pipeline d’apprentissage automatique traditionnel
Chaque étape du processus de développement de l’apprentissage automatique a été alambiquée avec une autre étape du pipeline DevOps, car le pipeline se compose des étapes ci-dessous :
- Développement et codage, y compris l’extraction de données de construction, la transformation, le chargement (ETL), le prétraitement, l’ingénierie des fonctionnalités, la sélection d’algorithmes et les tests de modèles. Cela peut être mis en œuvre à l’aide de n’importe quel environnement de développement intégré (IDE).
- Contrôle de la source à l’aide d’outils pour gérer les archivages/extractions, la fusion, la création de branches, le forking, le push et la validation.
- Orchestration du flux de code du contrôle de code source au déploiement :
- Virtualisez l’environnement de développement pour avoir toutes les dépendances au même endroit avec les versions exactes.
- Générez du code à l’aide de l’environnement précédemment configuré, manuellement ou automatiquement.
- Expédiez les conteneurs vers l’environnement de déploiement tel que le test, le transfert, la pré-production ou la production.
- Informez l’examinateur du modèle pour qu’il vérifie le modèle déployé. Après leur approbation, le conteneur sera expédié vers l’environnement suivant.
- Avant que le modèle ne soit envoyé au déploiement, il peut nécessiter une vérification humaine des performances, en particulier pour les exigences non fonctionnelles telles que le temps de réponse, la sécurité, l’évolutivité et la convivialité. C’est là que vous avez besoin d’un processus de test standard et d’un outil de suivi des problèmes pour les rapports et le suivi.
- Une fois le modèle déployé sur le serveur, il a besoin d’une passerelle API pour fournir les fonctionnalités de repos telles que la mise en file d’attente des messages, l’équilibrage de charge et l’évolutivité des modèles déployés.
- Après le déploiement, Capgemini surveille les performances du modèle en cours d’exécution pour suivre la dérive des données et la dérive du concept du modèle et agir en conséquence en ajustant le modèle ou en le reconstruisant.
Un tel pipeline fournit des modèles sous forme d’API qui seront hébergés en tant que service Web, puis utilisés ou intégrés à une application Web ou mobile frontale développée par l’équipe de développement logiciel.
Vous trouverez ci-dessous un aperçu de la façon dont l’architecture d’un tel pipeline fournit un modèle unique du développement à la production.
Un tel pipeline nécessite beaucoup d’interférences et de travail de la part des ingénieurs DevOps pour faire passer le modèle du développement à l’étape finale. Le diagramme de séquence présenté ci-dessous illustre le processus de développement de l’apprentissage automatique et sa dépendance à l’interférence humaine, en particulier les ingénieurs DevOps.
Capgemini
Problèmes rencontrés avec les implémentations sur site
Bien que le pipeline ci-dessus fournisse le modèle requis, quelques problèmes entravent la productivité de l’équipe et réduisent la probabilité de déploiement à l’aide de ce pipeline.
Les observations de Capgemini sur une telle implémentation sont les suivantes :
- Plus de 30 % des heures de travail de ML sont gaspillées sur des étapes opérationnelles en cours de route, y compris l’enregistrement, la virtualisation, les tests, la révision, la correction, la mise en scène (environnement de pré-production), la surveillance et le déploiement. Ce temps peut être gagné en automatisant la partie DevOps et en adoptant la philosophie CI/CD.
- Le modèle livré peut ne pas respecter les exigences non fonctionnelles telles que la taille du modèle, la gestion de la mémoire ou le temps de réponse. Ces problèmes sont suffisamment fatals pour tuer l’ensemble du modèle à moins qu’ils ne soient réalisés aux premières étapes du processus de développement, ce qui ne peut être assuré que via l’environnement CI/CD.
En tant que tel, ce processus doit être automatisé pour minimiser les pertes de temps, les retards, les efforts humains et les coûts opérationnels associés à la maintenance du pipeline et à la réduction des erreurs liées à l’intervention humaine.
Pour surmonter ces problèmes, Capgemini met en œuvre sa solution de pipeline MLOps en utilisant Amazon Sage Maker pour accélérer le processus et minimiser les efforts et le temps.
Pipeline Capgemini MLOps sur AWS
Pour créer un tel pipeline à l’aide des offres de services gérés AWS qui réduisent les efforts de maintenance opérationnelle, suivez ces étapes :
- Déployez des blocs-notes dans Amazon SageMaker, analysez les données à l’aide de bibliothèques de vision par ordinateur telles que OpenCV et l’image scikit, et créez un ensemble de fonctionnalités.
- Les fonctionnalités sont stockées dans Amazon DynamoDBcar la même image peut avoir un grand nombre de caractéristiques, y compris les valeurs RVB, les histogrammes, les pixels, le HSV, l’image traitée telle que la binarisation, l’érosion, la dilatation, les distributions de couleurs et la version quantifiée.
- La première étape consiste à différencier si l’image est une signature ou non. Il s’agit d’un problème de classification binaire de base qui peut être résolu à l’aide de AutoML ou Pilote automatique Amazon SageMaker:
- Le pilote automatique analyse les fonctionnalités et trouve les plus informatives en association avec la vérité terrain, à savoir si l’image est une signature ou non.
- Le pilote automatique sélectionne un ensemble de mesures pour évaluer les modèles prédictifs, notamment la précision, le rappel, le score F, l’aire sous la courbe ROC et l’aire sous la courbe PR.
- Le pilote automatique expérimente plusieurs algorithmes pour trouver les meilleures prédictions en fonction de l’ensemble de métriques prédéterminé.
- Le pilote automatique optimise les hyperparamètres de l’algorithme choisi pour obtenir la meilleure prévisibilité et générer le modèle en conséquence.
- Une fois le modèle développé et validé à l’aide des métriques prédéfinies, le modèle et le code seront validés pour AWS CodeCommit.
- Le code sera construit et déployé en utilisant AWS CodeBuild et AWS CodeDeploy.
- Le modèle, le code et les dépendances seront virtualisés, conteneurisés et enregistrés à l’aide de Amazon Elastic Container Registry (Amazon ECR).
- Les conteneurs seront enregistrés sur AWS CloudFormation pour le provisionnement, la mise à l’échelle et la gestion.
- Le modèle sera hébergé sur Passerelle d’API Amazon être accessible en tant qu’API reposante ou API WebSocket. Les API seront accessibles via des applications Web et des applications mobiles.
Capgemini MLOps Pipeline sur AWS simplifie l’ensemble du processus, du développement de l’apprentissage automatique à la production. Les équipes de développement ML peuvent se concentrer sur la manipulation des données et la préparation des fonctionnalités, et elles n’ont pas besoin de se soucier des tâches DevOps telles que le contrôle des sources, la gestion des versions, la virtualisation, la conteneurisation, le déploiement, la mise à l’échelle et la surveillance.
Le diagramme de séquence suivant nécessite une interférence humaine minimale après l’utilisation d’Amazon SageMaker. Le pipeline MLOps tel qu’implémenté avec AWS minimise les boucles, les goulots d’étranglement, les dépendances et les pertes de temps.
Conclusion
Le développement de l’apprentissage automatique et les MLOps sont deux tâches alambiquées l’une avec l’autre. Si l’un d’eux a un problème, l’autre ne peut pas avancer.
Dans cet article, j’ai montré comment Capgemini peut créer des modèles ML pour reconnaître les signatures à l’aide de services AWS tels qu’Amazon SageMaker qui simplifie les tâches DevOps et accélère le processus de développement au déploiement. Cela permet aux scientifiques des données de se concentrer sur les défis scientifiques au lieu de se préoccuper des problèmes de déploiement et d’environnement.
Visitez nous pour en apprendre plus sur AWS et Capgemini, et contactez l’un de nos experts.
Source link