Recommandé
Recommandé
Contenu connexe
Similaire à D’un modèle d'IA dans un notebook à un service temps réel : architecturons !
Similaire à D’un modèle d'IA dans un notebook à un service temps réel : architecturons ! (20)
Plus de Marie-Alice Blete
Dernier
Dernier (8)
D’un modèle d'IA dans un notebook à un service temps réel : architecturons !
- 1. D’un modèle d'IA dans un notebook à un service temps réel : architecturons ! ?
- 2. 2023 Merci à nos sponsors
- 3. HELLO Marie-Alice Blete Software Architect & Data engineer at Labs
- 4. Un peu de contexte data scientist dév
- 5. Un peu de contexte toute ressemblance avec des personnes existantes serait purement fortuite (ou pas)
- 6. Un peu de contexte ? blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code data scientist
- 7. Un peu de contexte blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code data scientist
- 8. Un peu de contexte blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code blabla code ? data scientist
- 9. Un peu de contexte modèle ?
- 10. Un peu de contexte
- 11. Au programme remarques & conclusion solution 2 critiques/contraintes solution 3 définitions objectif solution 1 solution 4
- 12. définitions
- 13. Le cycle de vie d’un modèle d’IA entraînement inférence création du modèle déploiement du modèle prédiction nouvelle donnée modèle données modèle
- 14. prédiction Le cycle de vie d’un modèle d’IA nouvelle donnée modèle déploiement du modèle vous êtes ici inférence « model-serving »
- 16. Point de départ entrainé + sérialisé modèle
- 17. Point d’arrivée : MODEL-as-SERVICE modèle input prediction webservice
- 18. Point d’arrivée : MODEL-as-SERVICE input prediction webservice modèle
- 19. L’accord avec l’équipe data scientist Pas de contraintes pour: le framework les données le modèle : « boite noire » ReadMe + Python sérialisé + entrainé modèle
- 21. Etape 1 : l’API API modèle ? POST predict <data>
- 22. Etape 2 : le « wrapper » Objectif : avoir un contrat d’interface pour le modèle predict(data) modèle
- 23. Etape 2 : le « wrapper » def initialize(self): # Charger le modèle self.model = joblib.load(...) def predict(self, data): # Appeler la fonction de prediction self.model.predict(data)
- 24. Etape 2 : le « wrapper » def initialize(self): # Charger le modèle self.model = keras.models.load_model(mymodel.h5) def predict(self, data): # Appeler la fonction de prediction self.model.predict_proba(data)
- 25. Etape 2 : le « wrapper » Chez GCP Wrapper = Docker container avec server http gcloud ai models upload --region=LOCATION --display-name=MODEL_NAME --container-image-uri=IMAGE_URI --container-command=COMMAND --container-args=ARGS --container-predict-route=PREDICT_ROUTE
- 26. Etape 2 : le « wrapper » API POST predict <data> modèle MODEL SERVING NODE
- 27. Etape 2 : le « wrapper » API POST predict <data> modèle MODEL SERVING NODE
- 28. modèle Etape 2 : le « wrapper » API POST predict <data> MODEL SERVING NODE
- 29. Point d’arrivée : MODEL-as-SERVICE modèle input prediction webservice
- 30. Model-as-service – solution 1 API POST predict <data> modèle MODEL SERVING NODE
- 31. définitions objectif solution 1 solution 2 critiques/contraintes
- 33. Problèmes de cette solution x Risque de DOS x Couplage entre API et modèle x Problème de responsabilité: l’API doit faire load balancer entre les “Model Nodes” ?
- 34. Etape 3 : ? ? POST predict <data> modèle MODEL SERVING NODE API
- 35. Etape 3 : « event queue » + « event processor » Request queue POST predict <data> modèle MODEL SERVING NODE MESSAGE BROKER API
- 36. Etape 3 : « event queue » + « event processor » Request queue POST predict <data> modèle EVENT PROCESSOR MESSAGE BROKER API
- 37. Etape 3 : « event queue » + « event processor » Request queue Prediction queue POST predict <data> API EVENT PROCESSOR MESSAGE BROKER modèle
- 38. Model-as-service – solution 2 Request queue Prediction queue POST predict <data> API EVENT PROCESSOR MESSAGE BROKER modèle
- 39. définitions objectif solution 1 solution 2 critiques/contraintes solution 3
- 40. Point d’arrivée : MODEL-as-SERVICE « near real time » input prediction webservice < X ms modèle
- 41. Scalability ? POST predict <data> EVENT PROCESSOR MESSAGE BROKER modèle API MESSAGE BROKER Request queue Prediction queue
- 42. Scalability ? Request queue Prediction queue API MESSAGE BROKER EVENT PROCESSOR modèle POST predict <data>
- 43. Scalability ? Request queue Prediction queue API MESSAGE BROKER EVENT PROCESSOR modèle POST predict <data>
- 44. Scalability ? Request queue Prediction queue API MESSAGE BROKER LOAD- BALANCER EVENT PROCESSOR modèle
- 45. Near real time : timeout POST predict <data> EVENT PROCESSOR MESSAGE BROKER modèle Request queue Prediction queue API
- 46. Near real time : timeout, FIFO? POST predict <data> EVENT PROCESSOR MESSAGE BROKER modèle Request queue Prediction queue API
- 47. Near real time : dépendant du modèle Se concerter avec l’équipe de data scientists precision/recall training loss inference latency Comparaison de modèles:
- 48. Model-as-service – solution 3 Request queue Prediction queue API MESSAGE BROKER LOAD- BALANCER EVENT PROCESSOR modèle
- 49. définitions objectif solution 1 solution 2 critiques/contraintes solution 3 solution 4
- 50. Mais… Hypothèse utilisée : data fournie par l’api = data attendue dans le modèle
- 51. Mais… modèle
- 52. Mais… modèle
- 53. Feature engineering & Preprocessing Création de features : Features dérivées date montant ip jour de la semaine montant en euros pays transaction transaction améliorée
- 54. Feature engineering & Preprocessing Création de features : Agrégations transaction courante 24 heures moyenne des montants
- 55. Feature engineering & Preprocessing Spécifique au modèle dans le « wrapper » modèle
- 56. Feature engineering & Preprocessing def initialize(self): # Charger le modèle def predict(self, data): # Appeler la fonction de prediction def preprocess(self, data): # Appliquer les transformations necessaires data[‘newfeature’] = do_something_complicated(data[‘somefeature’])
- 57. Preprocessing avec agrégat database transaction courante 24 heures moyenne des montants
- 58. Etape 4 : « base de données» database POST predict <data> Request queue Prediction queue API EVENT PROCESSOR MESSAGE BROKER modèle
- 59. Preprocessing avec agrégat… et latence Agrégation : opération potentiellement coûteuse Solution classique : utilisation d’un cache Compromis avec la performance du modèle ? database
- 60. Preprocessing avec agrégat… et latence Compromis Latence/Débit vs Performance de modèle Cohérence entre: ✓le preprocessing de data en batch lors de l’entrainement ✓le traitement au fil de l’eau lors de l’inférence
- 61. model-as-service – solution 4 database POST predict <data> Request queue Prediction queue API EVENT PROCESSOR MESSAGE BROKER modèle
- 62. remarques & conclusion solution 2 critiques/contraintes solution 3 définitions objectif solution 1 solution 4
- 64. Et ailleurs? Ingestion de données distincte de l’inférence autre exemple chez
- 65. Et ailleurs? database POST predict Request queue Prediction queue API EVENT PROCESSOR MESSAGE BROKER data stream input modèle
- 66. Autres patterns d’archi possibles avec l’application cliente service ou versionning indépendant de l’application cliente exécution du modèle « model-as-dependency » synchrone « precompute » « model-as-service » asynchrone
- 67. Take-aways message broker interfaces & généricité découplage scalabilité principe de responsabilité unique briques indépendantes communication wrapper
- 68. Déployer un modèle d’IA : une architecture comme une autre
- 69. Don’t be a stranger! Follow & get in touch linkedin.com/in/mblete blog.worldline.tech @WorldlineTech Follow our tech team: Follow me: Marie-Alice Blete Feedback