Créer des agents Strands avec les modèles SageMaker AI et MLflow

Traçabilité de bout en bout avec DVC et Amazon SageMaker AI MLflow

Les équipes de machine learning en production font face à un problème récurrent : retracer précisément l'origine d'un modèle déployé. Quelle version du jeu de données l'a entraîné ? Peut-on reproduire à l'identique un modèle mis en production il y a six mois ? Amazon Web Services propose une réponse concrète en combinant trois outils : DVC (Data Version Control), Amazon SageMaker AI et SageMaker AI MLflow Apps. L'architecture s'articule en quatre étapes : un job SageMaker Processing prétraite les données brutes et les versionne via DVC en les poussant vers Amazon S3 ; un job SageMaker Training clone le dépôt DVC à un tag Git précis, récupère le dataset exact via dvc pull, entraîne le modèle et enregistre tout dans MLflow. Chaque run MLflow stocke un identifiant datagitcommit_id, soit le hash DVC pointant vers le dataset exact dans S3. Le modèle entraîné est ensuite enregistré dans le MLflow Model Registry et peut être déployé sur un endpoint SageMaker. La chaîne de traçabilité complète devient alors : modèle en production → run MLflow → commit DVC → dataset dans Amazon S3. Cet enchaînement répond à un besoin critique dans les secteurs régulés : santé, services financiers, véhicules autonomes. Dans ces domaines, les exigences d'audit imposent de relier chaque modèle déployé à ses données d'entraînement précises, et de pouvoir exclure à la demande des enregistrements individuels des futurs cycles d'entraînement. Sans ce niveau de traçabilité, une question apparemment simple, "quelles données ont servi à entraîner le modèle actuellement en production ?", peut mobiliser plusieurs jours d'enquête dans des logs dispersés, des notebooks et des buckets S3. La solution proposée réduit ce risque opérationnel en rendant la traçabilité structurelle plutôt qu'optionnelle. DVC est un outil open source gratuit qui étend Git pour gérer des datasets volumineux et des artefacts ML que Git seul ne peut pas versionner. MLflow, de son côté, assure le suivi des expériences, le registre des modèles et la lignée. Les deux outils couvrent chacun la moitié du problème de traçabilité, et leur combinaison ferme la boucle. L'implémentation requiert un compte AWS avec des permissions sur SageMaker, S3, CodeCommit et IAM, Python 3.11 ou 3.12, et le SDK SageMaker v3.4.0 minimum. Les notebooks utilisent AWS CodeCommit comme backend Git pour les métadonnées DVC, mais l'architecture est compatible avec GitHub, GitLab ou Bitbucket moyennant un simple remplacement de l'URL remote. AWS publie des notebooks d'accompagnement permettant de déployer les deux patterns décrits, traçabilité au niveau du dataset et traçabilité au niveau de l'enregistrement individuel, directement dans un compte AWS existant.

Amazon SageMaker AI accélère les appels d'outils des agents autonomes avec la personnalisation de modèles sans serveur

Amazon a introduit une fonctionnalité de personnalisation de modèles sans serveur dans SageMaker AI, permettant aux équipes d'améliorer drastiquement les capacités d'appel d'outils des agents IA sans gérer d'infrastructure GPU. Dans un cas concret publié début avril 2026, des ingénieurs ont affiné le modèle Qwen 2.5 7B Instruct en utilisant la technique RLVR (Reinforcement Learning with Verifiable Rewards) et ont obtenu une amélioration de 57% du score de qualité des appels d'outils sur des scénarios inédits, c'est-à-dire des outils que le modèle n'avait jamais vus lors de l'entraînement. La méthode repose sur un principe simple : le modèle génère huit réponses candidates par prompt, une fonction de récompense vérifie lesquelles sont correctes, et l'algorithme GRPO (Group Relative Policy Optimization) renforce les comportements qui surpassent la moyenne du groupe. SageMaker AI prend en charge les familles de modèles Amazon Nova, Llama, Qwen et DeepSeek, avec un suivi des métriques via MLflow intégré. L'enjeu est concret : les agents IA en production échouent fréquemment lors des appels d'outils, qu'il s'agisse d'halluciner des fonctions inexistantes, de passer des paramètres incorrects, ou de déclencher une action là où ils devraient demander une clarification. Ces erreurs bloquent le déploiement en production et détruisent la confiance des utilisateurs. La nouvelle approche serverless d'Amazon supprime l'obstacle opérationnel majeur que représentait jusqu'ici le fine-tuning par renforcement : achat de GPU, orchestration mémoire entre les phases de rollout et d'entraînement, infrastructure de récompenses, gestion des checkpoints. Les équipes peuvent désormais se concentrer sur leurs données, leur modèle et leur fonction de récompense, le reste étant géré par la plateforme. Le fine-tuning supervisé classique (SFT) montre ses limites pour ce type de tâche : il nécessite des exemples étiquetés pour chaque comportement souhaité, mais peine à généraliser la prise de décision entre appeler un outil, demander des informations supplémentaires, ou refuser d'agir. RLVR contourne ce problème en exploitant la nature vérifiable des appels d'outils : soit le modèle a appelé la bonne fonction avec les bons paramètres, soit non. Cette objectivité binaire rend l'appel d'outils particulièrement adapté à l'apprentissage par renforcement. Amazon positionne cette offre dans un marché de l'IA agentique en forte croissance, où des acteurs comme Google (Vertex AI), Microsoft (Azure ML) et des startups spécialisées se disputent les équipes qui cherchent à industrialiser des agents fiables, avec un accès simplifié via SageMaker Studio et un compte AWS standard.

Affiner les LLM avec des données non structurées via SageMaker Unified Studio et S3

Amazon Web Services a annoncé une intégration entre Amazon SageMaker Unified Studio et les buckets Amazon S3 grand public, permettant d'exploiter des données non structurées directement dans les workflows de machine learning. Le cas d'usage présenté illustre l'affinage du modèle Llama 3.2 11B Vision Instruct — développé par Meta — pour des tâches de questions-réponses visuelles (VQA), comme l'extraction automatique d'informations depuis des reçus ou documents scannés. Le modèle de base atteint un score ANLS de 85,3 % sur le benchmark DocVQA, une métrique mesurant la similarité entre réponse prédite et réponse attendue. Pour l'affinage, AWS utilise le dataset DocVQA de Hugging Face, qui contient 39 500 exemples d'entraînement associant image, question et réponse. Trois versions affinées sont produites avec des volumes de données variables : 1 000, 5 000 et 10 000 images, orchestrées entièrement via SageMaker Unified Studio et évaluées avec Amazon SageMaker MLflow en mode serverless. Cet affinement ciblé permet aux équipes data de dépasser les limites d'un modèle généraliste sans reconstruire une infrastructure complexe de bout en bout. Pour les entreprises traitant des documents à haute valeur — contrats, factures, rapports médicaux — gagner quelques points de précision au-delà de 85 % peut représenter une différence opérationnelle significative. L'intégration native entre S3 et le catalogue SageMaker supprime une friction majeure : les données non structurées (images, PDF, textes bruts) deviennent des actifs directement exploitables par les équipes ML sans pipeline d'ingestion personnalisé. Le suivi des expériences via MLflow serverless permet en outre de comparer objectivement les trois variantes affinées et de documenter les gains de performance, une exigence croissante dans les déploiements enterprise. Cette annonce s'inscrit dans la stratégie d'AWS pour faire de SageMaker Unified Studio une plateforme unifiée couvrant l'ensemble du cycle MLOps, depuis l'ingestion des données brutes jusqu'au déploiement en production. La montée en puissance des modèles multimodaux — capables de traiter simultanément texte et image — crée une demande forte pour des outils d'affinage accessibles, sans que chaque équipe doive maîtriser les subtilités de l'entraînement distribué. AWS positionne ici SageMaker JumpStart comme point d'accès aux modèles fondamentaux, tandis que l'infrastructure d'entraînement repose sur des instances p4de.24xlarge, des GPU haute performance nécessitant une demande d'augmentation de quota. La prochaine étape logique pour AWS sera d'élargir cette intégration à d'autres formats de données non structurées et à davantage de modèles fondamentaux, dans un contexte où Google, Microsoft Azure et les plateformes spécialisées comme Modal ou Together AI se disputent le même terrain des équipes ML entreprise.

Créer une couche de mémoire à long terme universelle pour les agents IA avec Mem0 et OpenAI

Des chercheurs et développeurs s'appuient désormais sur Mem0, une bibliothèque open source compatible avec les modèles OpenAI et la base de données vectorielle ChromaDB, pour construire une couche de mémoire persistante destinée aux agents d'intelligence artificielle. Le principe repose sur une architecture en plusieurs modules : extraction automatique de souvenirs structurés à partir de conversations naturelles, stockage sémantique dans ChromaDB via les embeddings text-embedding-3-small, récupération contextuelle par recherche vectorielle, et intégration directe dans les réponses générées par GPT-4.1-nano. Concrètement, le système segmente les échanges conversationnels en faits durables associés à un identifiant utilisateur, comme les préférences techniques, les projets en cours ou les informations personnelles, puis les rend disponibles lors des interactions futures via une API CRUD complète permettant d'ajouter, modifier, supprimer ou interroger ces souvenirs. Cette approche résout un problème fondamental des agents IA actuels : leur amnésie entre les sessions. Sans mémoire persistante, chaque conversation repart de zéro, obligeant l'utilisateur à reformuler son contexte à chaque échange. Avec ce type d'architecture, un agent peut se souvenir qu'un utilisateur est ingénieur logiciel, qu'il travaille sur un pipeline RAG pour une fintech, et qu'il préfère VS Code en mode sombre, sans que ces informations aient été répétées. Pour les entreprises qui déploient des assistants IA internes, des copilotes de code ou des outils de support client, cela représente un gain de personnalisation et d'efficacité considérable. L'isolation multi-utilisateurs intégrée dans Mem0 garantit par ailleurs que les souvenirs d'un profil ne contaminent pas ceux d'un autre. La mémoire à long terme est l'un des chantiers prioritaires de l'IA générative en 2025-2026, aux côtés du raisonnement et de l'utilisation d'outils. Des acteurs comme OpenAI avec la mémoire de ChatGPT, ou des startups spécialisées telles que Mem0 (anciennement EmbedChain), se positionnent sur ce marché en pleine expansion. L'approche présentée ici est dite "production-ready" : elle exploite ChromaDB en local pour réduire les coûts et la latence, mais reste compatible avec des backends cloud. La tendance de fond est de faire évoluer les agents d'un mode sans état vers une continuité contextuelle, condition nécessaire pour des assistants véritablement utiles sur la durée. Les prochaines étapes probables incluent la gestion de la decay mémorielle (oublier les informations obsolètes) et l'intégration dans des frameworks multi-agents comme LangGraph ou AutoGen.

💬 Le problème de l'amnésie entre sessions, c'est le truc qui rend les agents inutilisables en vrai. Mem0 propose une architecture propre pour ça, avec ChromaDB en local et une isolation multi-utilisateurs qui tient la route, ce qui évite les bricolages maison qu'on voit partout. Bon, "production-ready" ça se vérifie, mais l'approche est solide.