Manuel d'ingénierie des LLM

Vous êtes un spécialiste de la prise de notes. Votre mission est de synthétiserdes informations tirées du livre "LLM Engineer's Handbook" pour créerdes notes structurées et complètes en français. Utilisez exclusivement le format HTML pour la mise en forme.

Cet ensemblede notes fournit une exploration approfondie de l'ingénierie des grands modèles linguistiques (LLM), couvrant le cycle de vie complet du développement, de la conception et de la mise en œuvre à l'optimisation et au déploiement. Il met l'accent sur les applications pratiques des LLM, y compris la création d'un "LLM Jumeau" capabled'imiter le style d'écriture d'une personne, et intègre les meilleures pratiques MLOps et LLMOps. L'objectif est de transformer un corpus de texte fourni en un guide structuré et didactique.

Comprendre le concept et l'architecture du LLM Jumeau

Le LLM Jumeau est un caractère IA qui intègre le style d'écriture, la voix et la personnalité d'une personne dans un grand modèle linguistique (LLM) complexe. Contrairement à un LLM générique entraîné sur l'ensemble d'Internet, un LLM Jumeau est affiné sur des données personnelles, reflétant ainsi les caractéristiques uniques de son créateur.

Qu'est-ce qu'un LLM Jumeau ?

Un LLM Jumeau est une version digitale d'une personne, projetée dans un LLM. Il est spécifiquement réglé (fine-tuned) sur des données personnelles. Le modèle apprend le style d'écriture, la voix et la personnalité reflétés dans ces données. C'est une application de transfert de style, où la personnalité elle-même est la cible du transfert.

Exemples d'application pour l'entraînement d'un LLM Jumeau :

• Publications LinkedIn et fils X (Twitter) : Spécialiser le LLM dans la rédaction de contenu pour les réseaux sociaux.

• Messages avec amis et famille : Adapter le LLM à une version non filtrée de soi-même.

• Articles académiques et articles : Calibrer le LLM pour un contenu formel et éducatif.

• Code : Spécialiser le LLM dans l'implémentation de code tel que l'utilisateur le ferait.

Pour ajuster le LLM à un style et une voix donnés, en plus du réglage fin (fine-tuning), on utilise des techniques avancées de Génération Augmentée par la Récupération (RAG) pour conditionner le processus auto-régressif avec des plongements (embeddings) antérieurs personnels.

Il est crucial de comprendre que le LLM reflèteles données sur lesquelles il est entraîné. La collecte et l'alimentation de données numériques personnelles au LLM, en utilisant divers algorithmes, constituent l'approche centrale.

Pourquoi construire un LLM Jumeau est important

Le LLM Jumeau vise à résoudre le défi de la création de contenu personnalisé sur des plateformes comme LinkedIn, X, Instagram, Substack et Medium, en utilisant le style et la voix de l'utilisateur. Il agit comme un co-pilote d'écriture, aidant à automatiser le processus de rédaction et à stimuler des idées créatives.

Bénéfices d'un LLM Jumeau :

• Créer une marque personnelle forte.

• Automatiser le processus d'écriture en générant des brouillons basés sur des idées clés.

• Stimuler le brainstorming et l'exploration de nouvelles idées créatives.

Le développement d'un LLM Jumeau est considéré comme éthique car il est exclusivement entraîné sur les données numériques personnelles de l'utilisateur, avec un accès restreint. L'objectif clair est de créer un co-pilote d'écriture personnalisé, non d'usurper l'identité d'autrui.

Pourquoi ne pas utiliser ChatGPT (ou un chatbot similaire) ?

ChatGPT, bien que puissant, n'est pas personnalisé. Son contenu est générique, peu articulé et verbeux. Il ne parvient pas à maintenir une voix originale, ce qui est crucial pour le succès à long terme d'une marque personnelle.

Limitations des chatbots génériques pour le contenu personnalisé :

• Désinformation due aux hallucinations : Vérification manuelle fastidieuse des faits.

• Saisie manuelle fastidieuse : Nécessite une ingénierie d'invites (prompt engineering) manuelle et l'injection d'informations externes, difficile à reproduire.

La clé d'un LLM Jumeau réside dans la gestion des données (collecte, prétraitement, stockage, versioning), le réglage fin (fine-tuning), le RAG et l'évaluation du contenu généré. Un système LLM est nécessaire pour encapsuler et automatiser ces étapes, offrant une solution agnostique auxmodèles pour une meilleure expérimentation et adaptabilité.

Planifier le Produit Minimum Viable (MVP) du LLM Jumeau

Un Produit Minimum Viable (MVP) est une version d'un produit qui inclut juste assez de fonctionnalités pour attirer les premiers utilisateurs et tester la viabilité du concept. L'objectif est d'aligner les idées avec des objectifs commerciaux réalistes, en utilisant les ressources disponibles pour maximiser la valeur du produit par rapport à l'effort investi.

Les raisons pour lesquelles un MVP est une stratégie puissante :

• Accélération de la mise sur le marché : Lancer un produit rapidement pour une adoption précoce.

• Validation d'idée : Tester avec de vrais utilisateurs avant un investissement complet.

• Étude de marché : Obtenir des informations sur la réception du produit par le public cible.

• Minimisation des risques : Réduit le temps et les ressources pour un produit incertain.

L'MVP du LLM Jumeau se concentrera sur des fonctionnalités clés :

• Collecte de données depuis LinkedIn, Medium, Substack et GitHub.

• Réglage fin (fine-tuning) d'un LLM open-source avec les données collectées.

• Remplir une base de données vectorielle (DB) avec les données numériques pour le RAG.

• Créer des publications LinkedIn personnalisées en tirant parti des invites de l'utilisateur, du RAG et de nouvelles connaissances.

• Une interface web simple pour interagir avec le LLM Jumeau, configurant les liens sociaux et déclenchant la collecte.

L'MVP sera conçu pour être rentable, évolutif et modulaire, en utilisant les dernières recherches en LLM et les meilleures pratiques d'ingénierie logicielle et MLOps.

Construire des systèmes ML avec des pipelines de fonctionnalités/entraînement/inférence (FTI)

L'architecture FTI (Fonctionnalités/Entraînement/Inférence) est un modèle fondamental pour la conception de systèmes ML évolutifs. Elle décompose un système ML en trois pipelines distincts : le pipeline de fonctionnalités, le pipeline d'entraînement et le pipeline d'inférence.

Le problème de la construction de systèmes ML :

• La construction de systèmes ML prêts pour la production va bien au-delà de l'entraînement d'un modèle.

• Les défis incluent l'ingestion, le nettoyage et la validation de données fraîches, la gestion des configurations d'entraînement et d'inférence, le calcul et la diffusion des fonctionnalités, le service du modèle de manière rentable, la versionisation, le suivi et le partage des ensembles de données et des modèles, la surveillance de l'infrastructure et des modèles, le déploiement surune infrastructure évolutive, et l'automatisation des déploiements et de l'entraînement.

Les solutions précédentes, telles que les architectures de traitement par lots monolithiques, résolvent le problème du biais d'entraînement-service (training-serving skew) mais introduisent d'autres problèmes comme la non-réutilisabilité des fonctionnalités, la difficulté de refactoriser le code pour de plus grandes échelles (PySpark, Ray), la difficulté de réécrire des modules de prédiction dans des langages plus efficaces (C++, Java, Rust), la difficulté de partager le travail entre équipes, et l'impossibilité de passer à des technologies de streaming pour l'entraînement en temps réel. Les architectures en temps réel sans état (stateless) exigent que l'état entier soit transféré via les requêtes du client, ce qui est inefficace et couplé au service du modèle.

L'architecture FTI propose une solution en définissant clairement la portée et l'interface de chaque pipeline, réduisant la complexité à trois composants principaux.

Les trois pipelines FTI :

1. Pipeline de fonctionnalités : Prend des données brutes en entrée, les traite et stocke les fonctionnalités et les étiquettes dans un magasin de fonctionnalités (feature store). Ce magasin est responsable du stockage, du versionnage, du suivi et du partage des fonctionnalités, évitant ainsi le biais d'entraînement-service.

2. Pipeline d'entraînement : Prend les fonctionnalités et les étiquettes du magasin de fonctionnalités, et sort un modèle ou des modèles entraînés. Les modèles sont stockés dans un registre de modèles (model registry), qui gère leur stockage, versionnage, suivi et partage, avec un magasin de métadonnées pour documenter comment le modèle a été entraîné.

3. Pipeline d'inférence : Prend les fonctionnalités du magasin de fonctionnalités et le modèle entraîné du registre de modèles pour effectuer des prédictions, soit en mode batch, soit en temps réel.

Les bénéfices de l'architecture FTI incluent sa simplicité, la flexibilité technologique pour chaque composant, la facilitation du développement par différentes équipes, ainsi que le déploiement, la mise à l'échelle et la surveillance indépendants de chaque composant. Lespipelines FTI agissent comme des couches logiques, permettant une évolution complexe mais structurée du système.

Concevoir l'architecture du système LLM Jumeau

L'architecture du LLM Jumeau est conçue selon le modèle FTI, avec une particularité : l'ajout d'un pipeline de collecte de données. Bien que le modèle FTI traditionnel comprenne trois pipelines (fonctionnalités, entraînement, inférence), la collecte de données est une étape préliminaire essentielle pour alimenter ces pipelines en données brutes, surtout dans un contexte MVP où unepetite équipe gère l'ensemble du cycle de vie du ML.

Détails techniques :

• Côté données : Collecte autonome et planifiée depuis LinkedIn, Medium, Substack, GitHub. Standardisation des données brutes stockées dans un entrepôt de données(ici, une DB NoSQL comme MongoDB). Nettoyage, création de jeux de données d'instructions pour le réglage fin (fine-tuning), et découpage et plongements (embeddings) des données pour le RAG (stockées dans une DB vectorielle comme Qdrant).

• Côté entraînement : Réglage fin (fine-tuning) de LLM de diverses tailles, sur différentes tailles de jeux de données d'instructions. Suivi et comparaison des expériences, test des candidats LLM avant déploiement, et déclenchement automatique de l'entraînement àla disponibilité de nouveaux jeux de données.

• Côté inférence : Interface API REST, accès en temps réel à la DB vectorielle pour le RAG, inférence avec des LLM de diverses tailles, auto-mise à l'échelle selon les requêtes, et déploiement automatique des LLMvalidés.

• Fonctionnalités LLMOps : Versionnage, lignage et réutilisabilité des jeux de données d'instructions et des modèles. Suivi des expériences, CI/CD/CT (intégration, déploiement, entraînement continus) et surveillance des invites (prompts) et du système.

L'architecture du LLM Jumeau sera divisée en quatre composants principaux :

1. Pipeline de collecte de données : Récupère les données personnelles (articles, posts, code) et les stocke dansun entrepôt de données NoSQL (MongoDB). Ce pipeline suit le modèle ETL (Extraction, Transformation, Chargement).

2. Pipeline de fonctionnalités : Prend les articles, posts et codes bruts de l'entrepôt de données, les nettoie, les traite et les charge dans un magasinde fonctionnalités (ici, une DB vectorielle Qdrant). Il gère le découpage, les plongements (embeddings) et la création d'instantanés de données pour le réglage fin et le RAG.

3. Pipeline d'entraînement : Consomme les jeux de donnéesd'instructions du magasin de fonctionnalités, ajuste (fine-tune) un LLM et stocke ses poids dans un registre de modèles. Il gère l'expérimentation, la sélection des meilleurs hyperparamètres et le processus d'entraînement continu (CT).

4. Pipeline d'inférence: Charge un LLM réglé (fine-tuned) depuis le registre de modèles, accède à la DB vectorielle pour le RAG, et répond aux requêtes client via une API REST. Il intègre un système de surveillance des invites (prompts).

Chaque pipeline sera dimensionné différemment : CPU et RAM pour la collecte de données et les fonctionnalités ; GPU pour l'entraînement ; et mise à l'échelle horizontale basée sur les requêtes pour l'inférence. Cette architecture flexible permet de répondre aux exigences techniques complexes tout en adhérant aux principes MLOps.

Outils et Installation

Ce chapitre présente les outils essentiels pour la conception et le déploiement du projet LLM Jumeau, couvrant l'écosystème Python, les outils MLOps/LLMOps, les bases de données pour le stockage non structuré et vectoriel, et la préparation de l'environnement AWS. L'objectif est de fournir une compréhension rapide des technologies choisies et de leur configuration.

Écosystème Python et installation du projet

Pour tout projet Python, trois outils fondamentaux sont nécessaires : l'interpréteur Python, un gestionnaire de dépendances, et un outil d'exécution de tâches. Pour le projet LLM Jumeau, Python 3.11.8 est la version testée. L'utilisation de pyenv est recommandée pour gérer les versions de Python de manière isolée pour chaque projet, évitant ainsi les conflits de version.

Pour installer pyenv et Python 3.11.8 :

1. Installer pyenv via le lien fourni dans le texte source.

2. Utiliser pyenv install 3.11.8.

3. Vérifier l'installation avec pyenv versions.

4. Définir la version locale pour le dépôt cloné :

• Cloner le dépôt GitHub : git clone https://github.com/PacktPublishing/LLM-Engineers-Handbook.git.

• Naviguer vers : cd LLM-Engineers-Handbook.

• Créer le fichier .python-version : pyenv local 3.11.8.

• Vérifier la version Python locale avec python --version.

Poetry : gestion des dépendances et environnements virtuels

Poetry est un gestionnaire populaire qui permet de spécifier, installer, mettre à jour et gérer les bibliothèques externes.Il assure la reproductibilité des installations en enregistrant les versions exactes des dépendances dans les fichiers pyproject.toml et poetry.lock.

Pour installer Poetry et les dépendances du projet :

1. Installer Poetry via le lien.

2. Naviguer vers le dépôt cloné.

3. Exécuter poetry install --without aws pour installer les dépendances du projet (la branche aws est à gérer séparément si nécessaire).

4. Activer l'environnement Poetry : poetry shell ou préfixer les commandes par poetry run.

Poetry crée également un environnement virtuel isolé pour chaque projet, prévenant les conflits de dépendances.

Poe le Poète : outil d'exécution de tâches

Poele Poète est un plugin Poetry utilisé pour gérer et exécuter les commandes CLI du projet. Il permet de définir des tâches dans le fichier pyproject.toml et de les exécuter via des alias, simplifiant l'automatisation et la documentation des scripts. Pour installer et utiliser Poe :

1. Installer Poe : poetry self add 'poethepoet[poetry_plugin]'.

2. Les commandes définies sont exécutables via poetry poe (par exemple, poetry poe test).

Pour cloner le dépôt et installer tous les outils :

git clone https://github.com/PacktPublishing/LLM-Engineers-Handbook.git
cd LLM-Engineers-Handbook
poetry install --without aws
poetry self add 'poethepoet[poetry_plugin]'

Les identifiants et clés d'API (OpenAI, Hugging Face) doivent être configurés dans un fichier .env selon le README du dépôt.

Outils MLOps et LLMOps

Cette section détaille les outils MLOps et LLMOps essentiels pour le projet LLM Jumeau, mettant en évidence leur rôle dans les meilleures pratiques de développement ML.

Pour exécuter l'infrastructure localement, Docker doit être installé (version 27.1.1 ou supérieure). Après avoir configuré le fichier .env, lancer poetry poe local-infrastructure-up pour démarrer ZenML, MongoDB et Qdrant.

Hugging Face : registre de modèles

Un registre demodèles est un dépôt centralisé qui gère les modèles ML tout au long de leur cycle de vie, stockant les modèles avec leurs métadonnées, historiques de version et métriques de performance. Hugging Face est choisi pour son écosystème, facilitant le partage et l'intégration des modèles ajustés (fine-tuned).

• Les modèles ajustés du projet : TwinLlama 3.1 8B et TwinLlama 3.1 8B DPO.

• Les démos sont disponibles sur Hugging Face Spaces.

ZenML : orchestrateur, artefacts etmétadonnées

ZenML agit comme un pont entre ML et MLOps, offrant des fonctionnalités de traçabilité, reproductibilité et déploiement des pipelines ML. Il utilise des pipelines et des étapes (fonctions Python décorées par @pipelineet @step respectivement) pour orchestrer les flux de travail.

Un artefact est tout fichier produit pendant le cycle de vie du ML (ensembles de données, modèles entraînés, etc.). ZenML transforme toute sortie d'étape en un artefact versionné et partageable, avec des métadonnées pour une meilleure observation. Un exemple est l'artefact instruct_datasets avec des métadonnées détaillées sur les catégories de données, la taille de stockage et le nombre d'échantillons.

Pour exécuter et configurer un pipeline ZenML :

• Les pipelines peuvent être appelés via le script tools/run.py, avec des fichiers de configuration YAML dynamiques.

• Exemple : poetry poe run-digital-data-etl-maxime.

ZenML supporte le concept de stack pour connecter différents services cloud (orchestrateur, stockage distant, registre de conteneurs), offrant une abstraction de l'infrastructure.

Comet ML : suivi d'expériences

Comet ML est un outil de suivi d'expériences qui permet de loguer les informations essentielles (métriques, visualisations) pour comparer les exécutions d'entraînement ML. Il suit les métriques d'entraînement, d'évaluation, les hyperparamètres et les métriques système (utilisation GPU/CPU).

• Les expériencesd'entraînement du projet sont accessibles publiquement : Comet ML LLM Twin Training.

Opik : surveillance des invites (prompts)

Opik, un outil open-source de Comet, est utilisé pour la surveillance des invites. Il permet de regrouper des traces (chaînes d'invites et de sorties générées) dans des tableaux de bord spécialisés, facilitant le débogage et la surveillance.

Bases de données pour le stockage non structuré et vectoriel

Le projet utilise deux types de bases de données :

• MongoDB : Base de données NoSQL populaire et robuste, utilisée pour stocker les données brutes collectées sur Internetavant leur traitement. Sa flexibilité pour les données textuelles non structurées, sa stabilité et la facilité d'utilisation avec son SDK Python en font un choix idéal.

• Qdrant : Base de données vectorielle populaire, rapide et riche en fonctionnalités, utilisée pour stocker les données de MongoDB aprèsleur traitement et transformation pour l'utilisabilité GenAI. Qdrant offre un bon compromis entre RPS (requêtes par seconde), latence et temps d'indexation.

Ces deux bases de données sont intégrées via Docker pour le développement local et peuvent être déployées sous formede services serverless pour la production.

Préparer AWS

AWS est le fournisseur cloud principal pour le projet en raison de sa popularité et de l'expérience des auteurs. Il offre des services robustes comme S3 (stockage d'objets), ECR (registre de conteneurs) et SageMaker (calcul pour l'entraînement et l'inférence).

Configuration d'un compte AWS, d'une clé d'accès et de l'interface de ligne de commande (CLI)

Les étapes incluent la création d'uncompte AWS, l'accès à la console, la génération d'un utilisateur IAM avec un accès administratif et la création de clés d'accès. La CLI AWS doit être installée et configurée avec ces clés (aws configure).

Attention : Les coûts liésà l'utilisation d'AWS sont la responsabilité de l'utilisateur, surtout pour SageMaker (estimés entre 50 et 100 $). Il est recommandé de surveiller les coûts via des alarmes de facturation.

SageMaker : calcul pour l'entraînement et l'inférence

AWS SageMaker est une plateforme ML entièrement gérée pour la construction, l'entraînement et le déploiement de modèles ML à grande échelle. Il simplifie le processus en gérant l'infrastructure sous-jacente. Il est choisi pour son haut niveau de personnalisation et de contrôlepar rapport à des options comme AWS Bedrock, qui offre des modèles pré-entraînés mais avec des options de personnalisation limitées.

SageMaker permet d'affiner (fine-tune) des pipelines d'entraînement sur des clusters GPU et de déployer des modèles LLM Jumeaux personnalisés en tant qu'API REST.

Ingénierie des Données

Ce chapitre explore la conception et l'implémentation du pipeline de collecte de données pour le projet LLM Jumeau, essentiel pour recueillir les données brutes nécessaires au réglage fin (fine-tuning) et à l'inférence.

Conception du pipeline de collecte de données du LLM Jumeau

Le pipeline de collecte de données du LLM Jumeau est une architecture ETL (Extract, Transform, Load).Il prend en entrée un utilisateur et une liste de liens, extrait les données de diverses plateformes (Medium, Substack, GitHub), les standardise et les charge dans un entrepôt de données MongoDB.

Flux de l'ETL :

1. Extraction : Données recueillies depuis Medium, Substack, GitHub.

2. Transformation : Nettoyage et standardisation des données dans un format cohérent.

3. Chargement : Données transformées stockées dans une DB NoSQL (MongoDB).

Lepipeline utilise un distributeur (dispatcher) qui, en fonction du domaine de chaque lien, appelle un analyseur (crawler) spécialisé. Quatre analyseurs sont implémentés pour trois catégories de données (articles, dépôts/code, posts).

Catégories de données et analyseurs:

• Article :

  • Medium crawler : se connecte à Medium, extrait et normalise le texte HTML.

  • Custom article crawler : implémentation générique, extrait le HTML pour les articles disponibles publiquement (Substack, blogs personnels).

• Dépôt (Code) : GitHub crawler : clone le dépôt, analyse l'arborescence des fichiers, nettoie et normalise.

• Post : LinkedIn crawler : se connecte à LinkedIn, navigue sur le flux de l'utilisateur, extrait et normalise les publicationsrécentes.

Chaque analyseur extrait et nettoie des données, puis les stocke dans un format standardisé dans l'entrepôt pour faciliter le traitement ultérieur. L'architecture est conçue pour être facilement extensible à de nouvelles sources de données en ajoutant simplement un nouvelanalyseur. MongoDB est choisi comme entrepôt de données pour sa flexibilité avec les données textuelles non structurées et sa facilité d'utilisation, même si ce n'est pas une approche standard pour de grands volumes de données.

Implémentation du pipeline de collecte de données du LLM Jumeau

L'implémentation du pipeline de collecte de données utilise ZenML pour l'orchestration, avec des fichiers de configuration YAML pour la flexibilité. Le pipeline digital_data_etl prend un nom d'utilisateur et une liste de liens en entrée, puis utilisedes étapes ZenML pour récupérer ou créer l'utilisateur et analyser les liens.

Pipeline ZenML et étapes :

• Le pipeline digital_data_etl orchestre la récupération de l'utilisateur (get_or_create_user) et l'analyse des liens (crawl_links).

• L'étape get_or_create_user récupère ou crée un utilisateur dans MongoDB et ajoute des métadonnées à l'artefact de sortie.

• L'étape crawl_links utilise un CrawlerDispatcher poursélectionner l'analyseur approprié pour chaque lien, gère les erreurs et ajoute des métadonnées sur les liens analysés.

Le distributeur (dispatcher) : comment instancier le bon analyseur ?

La classe CrawlerDispatcher gère l'instanciation des analyseurs en fonction du domaine de l'URL. Elle utilise un modèle de construction (builder pattern) pour enregistrer les analyseurs et la méthode get_crawler() pour récupérer l'analyseur adéquat, par défaut CustomArticleCrawler si aucunn'est trouvé.

Les analyseurs (crawlers) :

Tous les analyseurs héritent de BaseCrawler, qui définit une méthode abstraite extract(). Une classe BaseSeleniumCrawler étend BaseCrawler avec des fonctionnalitésréutilisables pour interagir avec les navigateurs web (comme se connecter à Medium ou LinkedIn). Elle utilise Selenium, chromedriver_autoinstaller pour la gestion des pilotes, et des options Chrome configurées pour le mode sans tête (headless).

• GithubCrawler : Récupère les dépôts GitHub en utilisant la fonctionnalité git clone, filtre les fichiers indésirables (.git, .toml, .lock, .png) et stocke le contenu des fichiers dans un RepositoryDocument.

• CustomArticleCrawler : Utilise AsyncHtmlLoader et Html2TextTransformer de langchain_community pour extraire le texte des articles. C'est le choix par défaut quand un analyseur spécifique n'existe pas.

• MediumCrawler : Hérite de BaseSeleniumCrawler, utilise Selenium pour naviguer, se connecter, faire défiler la page et extraire le contenu des articles avec BeautifulSoup.

Les documents de l'entrepôt de données NoSQL :

Les donnéessont structurées en classes de documents (ArticleDocument, PostDocument, RepositoryDocument) héritant de NoSQLBaseDocument. Cette classe de base implémente un modèle ODM (Object-Document Mapping) léger pour des opérations CRUD avec MongoDB.Pydantic est utilisé pour la validation de type et la structure des documents.

Collecte de données brutes dans l'entrepôt de données

La collecte des données est orchestrée par ZenML et peut être lancée manuellement. Des fichiers de configuration YAML personnalisés (parexemple, digital_data_etl_maxime_labonne.yaml) permettent de spécifier les liens à analyser pour chaque auteur.

Les artefacts de sortie, visibles dans le tableau de bord ZenML, fournissent des métadonnées détaillées sur les liens analysés etleurs statuts. Les requêtes peuvent être effectuées via les classes ODM pour accéder aux données stockées dans MongoDB.

Dépannage : En cas de problèmes avec Selenium, il est possible de commenter les liens Medium dans les fichiers de configuration. Une sauvegarde de données estégalement disponible pour importer des données pré-collectées si la collecte échoue.

Pipeline de Fonctionnalités RAG

Ce chapitre approfondit la Génération Augmentée par la Récupération (RAG), une technique fondamentale pour les applications d'IA générative. Elle permet d'injecter des données personnalisées dans un LLM pour des actions spécifiques (résumer, reformuler, etc.), surmontant ainsi les limitations des modèles entraînés sur des données fixes.

Comprendre le RAG

La RAG améliorela précision et la fiabilité des modèles d'IA générative en utilisant des informations provenant de sources externes, complétant ainsi leurs connaissances internes ou paramétrées.

RAG signifie :

• Retrieval (Récupération): Recherche de données pertinentes.

• Augmented (Augmenté) : Ajout de ces données comme contexte à l'invite.

• Generation (Génération) : Utilisation de l'invite augmentée avec un LLM pour la génération.

Un LLM est limité aux données sur lesquelles il a été entraîné. Le RAG résout les problèmes d'hallucinations (réponses fausses mais confiantes) et de données obsolètes ou privées. En injectant des informations pertinentes dans l'invite, le LLM utilise cecontexte supplémentaire pour des réponses correctes et fiables, agissant comme un moteur de raisonnement sur une source de vérité unique.

Le RAG est essentiel pour un système d'IA générative robuste et flexible, surtout quand il s'agit d'information externe, comme des actualités financièrespour un assistant, ou des attractions touristiques pour un recommandeur.

Le cadre RAG vanilla (naïf)

Un système RAG est composé de trois modules principaux, indépendants :

1. Pipeline d'ingestion : Un pipelinebatch ou streaming pour peupler la DB vectorielle.

2. Pipeline de récupération : Un module qui interroge la DB vectorielle et récupère les entrées pertinentes à l'entrée de l'utilisateur.

3. Pipeline de génération : La couche qui utilise les données récupérées pouraugmenter l'invite et un LLM pour générer des réponses.

Le processus général est le suivant : le pipeline d'ingestion ajoute des données externes à la DB vectorielle. L'utilisateur pose une question, qui est traitée par le module de récupération pour interroger la DB vectorielle. Le pipeline de génération utilise l'invite, l'entrée utilisateur et le contexte récupéré pour créer l'invite finale qui est passée au LLM pour obtenir la réponse.

Pipeline d'ingestion :

Le pipeline d'ingestion RAG extrait, nettoie, découpe et plonge (embeds) les documents bruts, puis charge les morceaux plongés dans une DB vectorielle. Il se compose de :

• Extraction de données : Collecte de données depuis diverses sources.

• Couche de nettoyage : Standardisation et suppression de caractères indésirables.

• Module de découpe (chunking) : Division des documents nettoyés en morceaux plus petits, sémantiquement liés et dont la taille respecte la limite d'entrée du modèle de plongement.

• Composant de plongement (embedding) : Utilise un modèle pour projeter le contenu des morceaux dans un vecteur dense.

• Module de chargement : Prend les morceaux plongés et leurs métadonnées, les fusionne et les charge dans la DB vectorielle. Les plongements servent d'index pour retrouver des morceaux similaires.

Pipeline de récupération :

Le pipeline de récupération prend l'entrée utilisateur, la plonge (embeds) et interroge la DB vectorielle pour trouver des vecteurs similaires. La tâcheprincipale est de projeter l'entrée dans le même espace vectoriel que les plongements de la DB. La distance cosinus est une métrique courante pour comparer les vecteurs, mesurant la similitude via l'angle entre eux.

Il est crucial de prétraiter l'entrée utilisateur de la même manière que les documents bruts (nettoyage, découpe, plongement) pour assurer la cohérence et éviter le biais d'entraînement-service.

Pipeline de génération :

Cette étape finale utilise l'entrée utilisateur etles données récupérées pour générer une réponse de valeur. L'invite finale est le résultat d'un modèle de système et d'invite rempli avec la question de l'utilisateur et le contexte récupéré. Les modèles d'invite doivent être suivis et versionnés selon les meilleures pratiques MLOps.

Que sont les plongements (embeddings) ?

Les plongements (embeddings) sont des représentations numériques denses d'objets (mots, images, etc.) encodés sous forme de vecteurs dans un espace vectoriel continu.Ils capturent la signification sémantique et les relations entre les objets. Par exemple, en PNL, des mots sémantiquement similaires sont positionnés près les uns des autres.

Il est courant de visualiser les plongements en réduisant leur dimensionnalité (souvent entre 64 et2048) à 2D ou 3D. Des algorithmes comme UMAP ou t-SNE sont utilisés pour conserver les propriétés géométriques lors de cette projection. UMAP est préférable pour la conservation des relations topologiques.

Pourquoi les plongementssont si puissants :

• Les modèles ML ne fonctionnent qu'avec des valeurs numériques. Les plongements transforment les données non numériques (mots, images, audio) en un format utilisable.

• Ils réduisent la dimensionnalité de l'entrée tout en condensant sasignification sémantique en un vecteur dense, évitant ainsi la "malédiction de la dimensionnalité" des méthodes comme le one-hot encoding.

• Ils capturent les relations sémantiques perdues avec d'autres méthodes (comme le feature hashing).

Les plongements sont créés par des modèles d'apprentissage profond qui comprennent le contexte et la sémantique de l'entrée. Le choix du modèle de plongement (Word2Vec, GloVe, BERT, ResNet, CLIP) dépend du type de données (texte, image, audio) et de l'usage spécifique. Des outils comme Sentence Transformers simplifient le calcul des plongements en Python.

Applications des plongements :

Les plongements sont largement utilisés pour la récupération d'informations, la recherche sémantique (texte,code, images, audio), la mémoire à long terme des agents. Ils sont également utilisés dans les systèmes de recommandation, le clustering, la détection d'anomalies, la visualisation de données, la classification et la classification zero-shot.

Plus sur les bases de donnéesvectorielles (DB)

Les bases de données vectorielles (DB) sont conçues pour stocker, indexer et récupérer efficacement les plongements vectoriels. Elles utilisent des algorithmes ANN (Approximate Nearest Neighbor) pour trouver les voisins les plus proches des vecteurs de requête, offrant un compromis entre précision et latence. En revanche, les DB traditionnelles, basées sur des données scalaires, ont du mal à gérer la complexité des données vectorielles.

Fonctionnement d'une DB vectorielle :

1. Indexation des vecteurs : Les vecteurs sont indexés à l'aide de structures de données optimisées pour les données de grande dimension (HNSW, projection aléatoire, quantification de produit (PQ), hachage sensible à la localité (LSH)).

2. Recherche de similarité : La DB interroge les vecteurs indexés pour trouver ceux qui sont les plus similaires au vecteur d'entrée, en utilisant des mesures de similarité (cosinus, distance euclidienne, produit scalaire).

3. Post-traitement des résultats : Les correspondances potentielles sont affinées pour garantir la pertinence.

Les DB vectorielles peuvent également filtrer les résultats en fonction des métadonnées, avant ou après la recherche vectorielle. La requête dépend également des métadonnées (ainsi que de l'index vectoriel), de sorte qu'elle contient un index de métadonnées utilisé pour les opérations de filtrage.

Opérations de la DB :

Les DB vectorielles partagent des caractéristiques avec les DB standard pour la performance, la tolérance aux pannes et la gestion : sharding, réplication, surveillance, contrôle d'accès, sauvegardes.

Aperçu du RAG avancé

Le cadre RAG vanilla présente des limitations en termes de pertinence des documents récupérés, de complétude du contexte, de redondance de l'information,de latence et de capacité à générer des réponses valides. Le RAG avancé vise à optimiser le cadre RAG à trois étapes différentes :

• Pré-récupération (Pre-retrieval) : Comment structurer et prétraiter les donnéespour des optimisations d'indexation, ainsi que des optimisations de la requête.

• Récupération (Retrieval) : Amélioration des modèles de plongement (embedding) et du filtrage des métadonnées.

• Post-récupération (Post-retrieval) : Filtrage du bruit des documents récupérés et compression de l'invite.

Ces techniques peuvent varier selon le type de données. L'optimisation du RAG est un processus expérimental nécessitant une itération constante.

Pré-récupération (Pre-retrieval) :

Les étapes de pré-récupération sont effectuées de deux manières :

• Indexation des données : Techniques comme la fenêtre glissante, l'amélioration de la granularité des données, l'ajoutde métadonnées, l'optimisation des structures d'index et l'approche "small-to-big" (utiliser de petits morceaux de texte pour le plongement, avec un contexte plus large stocké dans les métadonnées).

• Optimisation des requêtes : Techniques comme le routage de requête (décider quelle action prendre en fonction de l'entrée de l'utilisateur), la réécriture de requête (reformuler la question pour mieux correspondre aux informations indexées) et l'expansion de requête (enrichir la question pour inclure des termesou des concepts supplémentaires).

Récupération (Retrieval) :

Cette étape est optimisée par :

• Amélioration des modèles de plongement : Réglage fin (fine-tuning) des modèles pré-entraînés ouutilisation de modèles instructeurs pour adapter les plongements au domaine spécifique.

• Utilisation des fonctionnalités de filtrage et de recherche de la DB :

  • Recherche hybride : Mélange de recherche vectorielle et basée sur des mots-clés, pour des résultats précis etsémantiquement pertinents.

  • Recherche vectorielle filtrée : Utilisation de l'index des métadonnées pour filtrer les mots-clés spécifiques avant ou après la recherche vectorielle.

Post-récupération (Post-retrieval) :

Ces optimisations sont effectuées sur les données récupérées pour éviter que des problèmes comme des fenêtres de contexte limitées ou des données bruyantes ne compromettent les performances du LLM. Deux méthodes populaires sont :

• Compression de l'invite (Prompt compression) : Élimine les détails inutiles tout en conservant l'essence des données.

• Re-classement (Re-ranking) : Utilise un modèle ML de type cross-encoder pour attribuer un score de correspondance entre l'entrée del'utilisateur et chaque morceau récupéré, puis ne garde que les N premiers résultats les plus pertinents.

Architecture du pipeline de fonctionnalités RAG du LLM Jumeau

Le pipeline de fonctionnalités RAG du LLM Jumeau est fondamental pour son architecture, car il gère le traitement des données brutes en fonctionnalités utilisables pour le RAG. Il s'agit d'un pipeline d'ingestion, complété par le pipeline d'inférence (abordé au chapitre 9).

Problème à résoudre :

Concevoir un pipeline de fonctionnalités RAG qui prend les données brutes des réseaux sociaux (articles, dépôts de code, posts) de l'entrepôt de données MongoDB, puis nettoie, découpe et plonge (embeds) le texte, et le charge finalement dans un magasin de fonctionnalités. Ce magasin de fonctionnalités sera un magasin de fonctionnalités logique utilisant les artefacts ZenML et une DB vectorielle Qdrant.

L'objectif est d'automatiser le pipeline de fonctionnalités pour synchroniser constamment l'entrepôt de données et le magasin de fonctionnalités,réduisant ainsi la désynchronisation et assurant la fraîcheur des données pour l'algorithme RAG.

Le magasin de fonctionnalités :

Le magasin de fonctionnalités est le point d'accès central aux fonctionnalités. Il agira comme une carte mentale (mind map)pour la complexité des systèmes ML. Dans le cas du LLM Jumeau, il stocke des instantanés de données (après nettoyage pour le réglage fin, et après découpe/plongements pour le RAG) pour assurer la cohérence. Bien que les données textuelles brutes ne soient pas considérées comme des fonctionnalités au sens strict, elles sont prétraitées pour être consommées par le modèle (tokenisation à l'exécution).

D'où proviennent les données brutes :

Les données brutes sont stockées dans l'entrepôt dedonnées MongoDB, peuplé par le pipeline ETL de collecte de données (Chapitre 3).

Concevoir l'architecture du pipeline de fonctionnalités RAG :

Le pipeline de fonctionnalités RAG est un pipeline de traitement par lots (batch), plutôt quede streaming, en raison de sa simplicité et de la tolérance à une légère latence dans la synchronisation des données pour ce cas d'utilisation.

• Pipelines batch : Collecte, traitement et stockage de données à intervalles définis, en grands volumes. Avantages : efficacitépour les gros volumes, traitement complexe, simplicité.

• Batch vs. Streaming : Les pipelines de streaming traitent les données en continu avec une latence minimale, idéaux pour les cas d'utilisation en temps réel (récommendations, détection de fraude). Les pipelines batch sont plus simples et moinscoûteux, suffisants pour le LLM Jumeau où un délai de quelques minutes est acceptable.

Étapes clés :

1. Extraction de données : Récupération des dernières données (articles, code, posts) de MongoDB.

2. Nettoyage : Nettoyage et normalisation du texte pour l’interprétation par le modèle de plongement.

3. Découpage (chunking) : Division des documents nettoyés en morceaux selon des stratégies dépendant de la catégorie de données et du modèle de plongement.

4. Plongement (embedding) : Passage de chaque morceau à un modèle de plongement (par exemple, "all-mpnet-base-v2").

5. Chargement de données : Combinaison du plongement et des métadonnées du morceau, puis chargement dans la DBvectorielle Qdrant.

Le Change Data Capture (CDC) est une stratégie pour synchroniser les stockages de données. Pour le LLM Jumeau, une approche naïve par lots est utilisée, mais des stratégies CDC basées sur le timestamp ou lesjournaux (logs) pourraient être implémentées pour de plus grands volumes de données.

Deux instantanés de données sont stockés : après nettoyage (pour le réglage fin) et après découpe/plongements (pour le RAG), afin de maintenir la cohérence etl'accès depuis le magasin de fonctionnalités.

L'orchestration est gérée par ZenML, permettant une exécution planifiée ou manuelle, et contribuant à l'entraînement continu (CT).

Implémentation du pipeline de fonctionnalités RAG du LLM Jumeau

L'implémentation du pipeline de fonctionnalités RAG suit une approche descendante, en commençant par la classe Settings et le pipeline ZenML.

Paramètres (Settings) :

Pydantic Settings est utilisé pour définir les variables sensibles etnon sensibles, avec validation de type. Cela inclut les IDs de modèles de plongement, de reranking, de périphériques (CPU/GPU) et les configurations de la DB Qdrant.

Pipeline ZenML et étapes :

Le pipeline feature_engineering est le point d'entrée. Il reflète les cinq phases clés de l'ingestion RAG : extraction, nettoyage, découpe, plongement et chargement. Chaque appel dans la fonction feature_engineering() est une étape ZenML.

• query_data_warehouse : Récupère les documents bruts pour chaque auteur en parallèle et génère des métadonnées descriptives.

• clean_documents : Itère sur les documents et délègue la logique de nettoyage à un CleaningDispatcher.

• chunk_and_embed : Délègue la logique de découpe et de plongement à un distributeur, et calcule les métadonnées sur le processus.

• load_to_vector_db : Regroupe les documents par catégorie de données et les charge par lots dans la DB vectorielle Qdrant.

Les paramètres des pipelines peuvent être configurés dynamiquement via des fichiers YAML à l'exécution, pour s'adapter à différents cas d'utilisation.

Entités de domaine Pydantic :

Les objets de domaine sont structurés en une hiérarchie declasses Pydantic, en suivant les principes DDD (Domain-Driven Design). La hiérarchie est basée sur deux dimensions : la catégorie de données (Post, Article, Repository) et l'état des données (Nettoyé, Découpé, Plongé). Des classes abstraites de base (CleanedDocument, Chunk, EmbeddedChunk) héritent de VectorBaseDocument (OVM personnalisé) et sont étendues par des sous-classes spécifiques à chaque catégorie (par exemple, CleanedArticleDocument).

OVM (Object-Vector Mapping) :

Le modèle OVM est inspiré de l'ORM, mais adapté aux plongements et aux DB vectorielles. La classe de base VectorBaseDocument prend en charge les opérations CRUD (pour l'instant, Création et Lecture) sur Qdrant, avecdes méthodes from_record() et to_point() pour convertir entre les formats Qdrant et Pydantic. Elle inclut également des méthodes bulk_insert(), bulk_find() et search() pour interagir avec la DB vectorielle.

Couche de distributeur (dispatcher) :

Un distributeur (par exemple, CleaningDispatcher) prend un document en entrée et applique des gestionnaires (handlers) dédiés en fonction de sa catégorie de données (article, post, dépôt). Unefabrique (factory) (par exemple, CleaningHandlerFactory) instancie le bon gestionnaire pour chaque type de document. Les distributeurs de découpe (chunking) et de plongement (embedding) suivent un modèle similaire. Cette approche, combinant les modèlesde fabrique abstraite (abstract factory) et de stratégie (strategy), assure la modularité, la réutilisabilité et l'extensibilité du code.

Les gestionnaires (handlers) :

Chaque gestionnaire a une structure un-à-un avec son domaine et hérite d'interfaces de base (CleaningDataHandler(), ChunkingDataHandler(), EmbeddingDataHandler()). Par exemple, ArticleCleaningHandler nettoie le contenu de l'article en utilisant la fonction clean_text(). Les gestionnaires de découpe utilisent des stratégies de découpe adaptées à chaque catégorie (par exemple, chunk_article() pour les articles). Les gestionnaires de plongement (embedding) sont conçus pour traiter les échantillons par lots afin d'optimiser l'inférence. La classe EmbeddingModelSingleton enveloppe SentenceTransformer() et assure la réutilisation de l'instance du modèle de plongement (singleton pattern).

Réglage Fin Supervisé (SFT)

Le Réglage Fin Supervisé (SFT) est une étape cruciale pour préparer les LLM aux applications réelles. Après la phase de pré-entraînement (où le LLM apprend à prédire le jeton suivant), le SFT peaufine le modèle à l'aide de paires d'instructions et de réponses soigneusement organisées. Ce processus permet au modèle de comprendre et de suivre un format de conversation spécifique, le transformant en un agent conversationnel, et d'adapter sa large base de connaissances à des tâches ciblées ou des domaines spécialisés.

Création d'un jeu de données d'instructions dehaute qualité

La création de jeux de données d'instructions est la partie la plus difficile du processus de réglage fin, en raison de la rareté de paires naturelles instructions-réponses dans les textes bruts. Les jeux de données d'instructions sont définis comme des paires d'instructions(entrées) et de réponses (sorties attendues).

Le SFT est utilisé pour affiner les modèles. Les données sont ensuite traitées pour créer des jeux de données d'instructions. Ces jeux de données sont structurés et filtrés pour assurer la qualité.

Des formats de jeux de données comme Alpaca, ShareGPT ou OpenAI organisent ces paires. L'efficacité du modèle dépend de la qualité des données (précision, diversité, complexité) et de la quantité.

Qualité des données :

• Précision : Exactitude factuelle et pertinence des échantillons.

• Diversité : Large éventail de cas d'utilisation, couvrant les requêtes et tâches potentielles.

• Complexité : Inclusion de problèmes complexes, de raisonnements multi-étapes et de tâches difficiles.

Quantité de données :

Le nombre idéal d'échantillons est difficile à calculer. Pour les grands modèles (70 milliards de paramètres), 1 000 échantillons de haute qualité peuvent suffire, tandis que les plus petits modèles (7 milliards de paramètres)nécessitent davantage d'échantillons. Les modèles polyvalents (general-purpose) peuvent nécessiter des millions d'échantillons, tandis que les modèles spécifiques à une tâche (task-specific) ou à un domaine (domain-specific) peuvent en nécessiter moins (100 à 100 000 pour les premiers, variable pour les seconds).

Conservation des données :

Les données sont conservées via le filtrage basé sur des règles (longueur, exclusion de mots-clés, vérification de format),la déduplication (exacte, floue via MinHash ou sémantique) et la décontamination (élimination des échantillons similaires aux jeux de test). L'évaluation de la qualité des données est essentielle, utilisant des méthodes traditionnelles (annotation humaine) ou automatisées (LLM en tant que juge, modèles de récompense, classificateurs).

Exploration du SFT et de ses techniques

Le SFT consiste à ré-entraîner des modèles pré-entraînés sur un jeu de données plus petit, composé de paires d'instructions etde réponses. L'objectif est de transformer un modèle de base, uniquement capable de prédire le jeton suivant, en un assistant utile. Le SFT peut aussi améliorer les performances générales, inculquer de nouvelles connaissances ou se concentrer sur des tâches spécifiques.

Quand affiner (fine-tune) ?

Il est recommandé de commencer par l'ingénierie rapide (prompt engineering). Si les résultats ne répondent pas aux exigences, le réglage fin (fine-tuning) devient une option, à condition qu'il y ait suffisamment dedonnées disponibles. Le réglage fin offre un contrôle accru et une personnalisation unique, permettant des interactions plus diverses avec les LLM (analyse d'outils, modération, contexte additionnel).

Limites du réglage fin :

• Le SFT exploite les connaissances préexistantes du modèle de base, mais a du mal à apprendre des connaissances trop éloignées du jeu de pré-entraînement.

• Il peut entraîner des hallucinations plus fréquentes et l'oubli catastrophique (effacement de connaissances antérieures).

Formatsdes jeux de données d'instructions :

Les jeux de données d'instructions sont stockés dans des formats spécifiques (Alpaca, ShareGPT, OpenAI, OASST) pour organiser les instructions et les réponses. Chaque échantillon peut être un dictionnaire Python. Le format Alpaca est suffisant pourdes instructions à un seul tour, tandis que ShareGPT ou OpenAI sont mieux adaptés aux conversations multi-tours.

Modèles de conversation (chat templates) :

Des modèles comme ChatML, Llama 3, Mistral, Phi-3, Gemma structurent les instructions etles réponses avec des jetons spéciaux (<|im_start|>, <|im_end|>) pour identifier le début/fin des messages et l'auteur. Ces modèles sont cruciaux pour que le LLM apprenne à suivre les instructions.

Techniques de réglage fin efficaces en termes de paramètres (PEFT)

Trois techniques principales de SFT existent :

1. Réglage fin complet (Full fine-tuning) : Ré-entraîne tous les paramètres du modèle de base. Souvent, les meilleurs résultats, mais nécessite des ressources de calcul importantes (VRAM, jusqu'à 1120 Go pour un modèle de 70B paramètres en FP32). Risque d'oubli catastrophique.

2. LoRA (Low-Rank Adaptation): Introduit des matrices entraînales de rang faible (A et B) pour modifier le modèle sans changer les paramètres originaux. Réduit considérablement la consommation de mémoire et accélère le processus de réglage fin. Non destructif pour les poids pré-entraînés. Hyperparamètres : rang (r) et alpha (α). Peut être appliqué à diverses parties de l'architecture du modèle.

3. QLoRA (Quantization-aware Low-Rank Adaptation) : Combine la quantification (par exemple, 4-bit NormalFloat - NF4) avec LoRA. Réduit davantage l'utilisation de la mémoire GPU (jusqu'à 75% par rapport à LoRA) au prix d'un entraînement plus lent (environ 30%). Idéal pour les contraintes de mémoire GPU.

Paramètres d'entraînement :

• Taux d'apprentissage et schedulers : Le taux d'apprentissage (learning rate) est l'hyperparamètre le plus important (typiquement 1e-6 à 1e-3). Les schedulers (linéaire, cosinus) ajustent le taux d'apprentissage au cours de l'entraînement.

• Taille de lot (Batch size) : Détermine le nombre d'échantillons traités avant la mise à jour des poids du modèle (typiquement 1 à 32). L'accumulation de gradient permet de simuler de grandes tailles de lots avec des ressources mémoire limitées.

• Longueur maximale et empaquetage (Packing) : La longueur maximale de séquence (512 à 4096 jetons) détermine l'entrée la plus longue. L'empaquetage combine plusieurs échantillons plus petits dans un seul lot pour maximiser l'utilisation de chaque lot d'entraînement.

• Nombre d'époques : Nombre de passages complets sur l'ensemble du jeu de données (typiquement 1 à 10). Trop peu d'époques → sous-apprentissage ; trop d'époques → surapprentissage.

• Optimiseurs : AdamW (8-bit pour la mémoire), AdaFactor (pour la mémoire limitée) ou AdamW standard (pour la performance maximale).

• Déclin de poids (Weight decay) : Ajout d'une pénalité pour les poids importants à la fonction de pertepour encourager des caractéristiques plus simples et généralisables (typiquement 0.01 à 0.1).

• Vérification de gradient (Gradient checkpointing) : Réduit la consommation de mémoire pendant l'entraînement en stockant uniquement un sous-ensemble des activations intermédiaires.

Réglage fin en pratique :

Le réglage fin d'un modèle open-source utilise la bibliothèque Unsloth pour l'efficacité. Le modèle choisi est Llama 3.1 8B de Meta, en raison de sa licence permissive,de sa taille gérable et de ses bonnes performances. Processus :

1. Configuration des clés API (Hugging Face, Comet ML) dans le fichier .env.

2. Chargement du modèle et du tokenizer avec FastLanguageModel.from_pretrained().

3. Définition de la configuration LoRA pour les couches linéaires du modèle.

4. Préparation des données en combinant le jeu de données llmtwin (créé dans la section précédente) avec un jeu de données polyvalent de haute qualité comme FineTome-Alpaca-100k.

5. Formatage des données avec un modèle de conversation (par exemple, Alpaca) et ajout du jeton de fin de phrase (EOS).

6. Division du jeu de données en ensembles d'entraînement et de test.

7. entraînement avecSFTTrainer(), configuration des hyperparamètres (taux d'apprentissage, taille de lot, époques, optimiseur, etc.), et signalement des métriques à Comet ML.

Après l'entraînement, le modèle est testé pour vérifierla cohérence et le formatage. Les métriques importantes à surveiller dans Comet ML sont la perte d'entraînement, la perte de validation et la norme de gradient. Le modèle entraîné est ensuite sauvegardé localement et/ou poussé vers Hugging Face Hub.

Réglage Fin avecAlignement de Préférence

Le Réglage Fin Supervisé (SFT) a ses limites pour capturer les nuances des préférences humaines. L'alignement de préférence incorpore un retour d'information direct (humain ou IA) dans le processus d'entraînement.Ce chapitre se concentre sur l'Optimisation de Préférence Directe (DPO) pour sa simplicité et son efficacité.

Comprendre les jeux de données de préférence

Les jeux de données de préférence, comme ceux d'instructions, nécessitent une haute qualité (précision, diversité, complexité). Ils diffèrent par leur structure et leur rôle dans l'entraînement.

Données de préférence :

Contrairement aux jeux de données d'instructions (paires instruction-réponse), les données de préférence contiennent une collection de réponses àune instruction donnée, classées par des humains ou des modèles linguistiques. Pour le DPO, une instruction est associée à une réponse préférée et une réponse rejetée.

Les réponses rejetées sont aussi importantes que les choisies, car elles représentent lescomportements à éliminer du modèle. Les jeux de données de préférence sont bénéfiques pour des cas d'utilisation où le SFT seul est insuffisant (chatbots, modération de contenu, résumé, génération de code, écriture créative, traduction).

Il n'y apas de formats de stockage standardisés comme pour les jeux de données d'instructions. La plupart suivent une structure instruction, réponse préférée, réponse rejetée. Les conversations multi-tours sont rares dans l'alignement de préférence.

Quantité de données :

Les jeux de donnéesDPO nécessitent généralement moins d'échantillons que les jeux de données d'instructions pour un impact significatif. La quantité dépend de la taille du modèle et de la complexité de la tâche. Pour l'alignement général, des millions d'échantillons peuvent être nécessaires. Pour l'alignementspécifique à une tâche, 100 à 10 000 paires peuvent suffire.

Génération et évaluation des données :

La génération et l'évaluation des préférences sont étroitement liées. Les réponses sont d'abord créées, puis évaluées pour constituerle jeu de données final.

Générer des préférences :

Il est conseillé de consulter les jeux de données open-source existants (Anthropic HH-RLHF, OpenAI Summarize from Human Feedback). Les jeux de données DPO peuvent être créés de plusieurs manières :

• Générés par l'homme, évalués par l'homme : Très intensif en ressources, difficile à mettre à l'échelle.

• Générés par l'homme, évalués par LLM : Rarement utilisé en pratique.

• Générés par LLM, évalués par l'homme : Bon équilibre qualité/efficacité ; les humains jugent mieux les réponses qu'ils ne les écrivent.

• Générés par LLM, évalués par LLM : Le plus évolutif et rentable ;nécessite une ingénierie d'invite (prompt engineering) poussée.

Les conseils pour la génération de données incluent la conception d'invites pour encourager la diversité et la complexité des réponses, la manipulation des paramètres de température des LLM et l'utilisation de plusieurs LLM pour générer des échantillons.

Évaluation des préférences :

L'évaluation des données peut être faite par des évaluateurs humains ou automatisée par des LLM. L'évaluation par LLM implique des critères détaillés etdes invites claires pour le LLM. Elle peut se faire par notation absolue (le LLM attribue un score) ou par classement par paires (le LLM compare deux réponses). Le classement par paires est généralement plus précis et se rapproche du jugement humain. Pour améliorer la fiabilité del'évaluation, des stratégies comme l'utilisation de plusieurs LLM comme jury, la randomisation de l'ordre des réponses et la normalisation de la longueur peuvent réduire les biais (biais de position, biais de longueur, biais de famille).

Créer notre propre jeu de données de préférence

Pour adapter le style d'écriture d'un modèle (TwinLlama-3.1-8B) au style des auteurs originaux, un jeu de données de préférence personnalisé est créé. L'objectif est de modifier la "voix" du modèle sans le rendre trop formel ni verbeux, ce qui est une tendance naturelle du DPO. Le processus implique la génération de données synthétiques à partir d'articles existants, où les réponses choisies sont des extraits du texte original et les réponses rejetées sont générées par le modèle.

Processus de génération du jeu de données :

1. Importation des bibliothèques : Utilisation de openai pour l'interaction avec le modèle et datasets pour la gestion des données.

2. Classe PreferenceSet : Gère les triplets(instruction, réponse générée (rejetée), réponse extraite (choisie)).

3. Chargement et nettoyage des articles : Utilisation des fonctions load_articles_from_json et clean_text.

4. Découpage des articles : Lafonction extract_substrings divise les articles nettoyés en morceaux de 1 000 à 2 000 caractères, en respectant les fins de phrase.

5. Génération des triplets de préférence : La fonction generate_preference_triples utilise GPT-4o-mini pour créer cinq triplets instruction-réponse par extrait, en privilégiant l'imitation du style d'écriture de l'auteur.

6. Filtrage de qualité : Les fonctions filter_short_answers et filter_answer_format éliminent les réponses trop courtes ou mal formatées.

7. Création du jeu de données de préférence : La fonction create_preference_dataset orchestre ce processus et pousse le jeu de données final vers Hugging Face Hub.

Le jeu de données finalest disponible sur Hugging Face Hub à mlabonne/llmtwin-dpo. Il montre comment modifier subtilement le style d'écriture sans perdre en qualité factuelle.

L'ingénierie d'invite (prompt engineering) est essentielle pourobtenir des résultats satisfaisants, nécessitant plusieurs itérations d'évaluation manuelle.

Alignement de préférence

L'alignement de préférence regroupe les techniques de réglage fin de modèles sur des données de préférence. Cette section compare le Reinforcement Learning from HumanFeedback (RLHF) et l'Optimisation de Préférence Directe (DPO).

Reinforcement Learning from Human Feedback (RLHF) :

Le RLHF combine l'apprentissage par renforcement (RL) avec l'entrée humaine pour aligner les modèles surles préférences et valeurs humaines. Il découle du Preference-based Reinforcement Learning (PbRL), qui infère les objectifs à partir de retours qualitatifs plutôt que de signaux de récompense quantitatifs. Le RLHF fonctionne en améliorant itérativement un modèle derécompense (appris à partir des préférences humaines) et une politique (optimisée pour maximiser les récompenses prédites).

Optimisation de Préférence Directe (DPO) :

Le DPO est une alternative simplifiée aux méthodes RLHF traditionnelles. Il reformule le problème d'apprentissage de préférence en dérivant une expression de forme fermée pour la politique optimale selon l'objectif RLHF standard. Cela élimine le besoin d'un modèle de récompense séparé ou d'algorithmes complexes d'apprentissage par renforcement.

Le DPO peut être implémenté comme une fonction de perte d'entropie croisée binaire qui opère directement sur les probabilités de sortie du modèle linguistique. Il encourage le modèle à attribuer une probabilité plus élevée aux réponses préférées et plus faible aux réponses non préférées, tout en maintenant la proximitéavec un modèle de référence gelé (frozen reference model).

Avantages du DPO par rapport au RLHF :

• Simplification du pipeline d'apprentissage de préférence, réduisant la complexité d'ingénierie.

• Plus efficace en calcul.

• Correspond souvent aux performances des méthodes RLHF plus complexes.

• Plus stable pendant l'entraînement et moins sensible aux hyperparamètres.

Le DPO est idéal dans la plupart des cas, y compris pour l'exemple du LLM Jumeau, offrant la majorité des bénéfices de performance à un coût de calcul et d'ingénierie inférieur.

Implémentation du DPO

Le réglage fin DPO du modèle TwinLlama-3.1-8B utilise la bibliothèque Unsloth pour l'efficacité. L'objectif est d'imiter un style d'écriture spécifique, ce qui peut entrer en conflit avec la tendance naturelle du DPO à favoriser un langage formel. Cela nécessite un réglage fin léger, avec un faible taux d'apprentissage et un nombre réduit d'époques.

Processus :

1. Configuration des clés API (Hugging Face, Comet ML).

2. Appliquer un patch pour la classe DPOTrainer de TRL.

3. Importation des bibliothèques nécessaires (DPOConfig et DPOTrainer de TRL).

4. Chargement du modèle TwinLlama-3.1-8B et de son tokenizer.

5. Préparation du modèle pour PEFT avec une configuration LoRA.

6. Chargement du jeu de données llmtwin-dpo.

7. Formatage des données en utilisant une invite de conversation (chat template) Alpaca.

8. Lancement du réglage fin avec DPOTrainer(), configuration des paramètres DPO (ref_model, beta, max_prompt_length,max_length) et signalement des métriques à Comet ML.

Les modèles SFT et DPO sont ensuite comparés. Le modèle DPO produit une réponse plus précise et plus proche du style d'écriture souhaité. Les métriques DPO suivies dans Comet ML incluent la perte d'entraînement, la perte de validation, la norme de gradient, les récompenses (choisies et rejetées) et les précisions.

Le DPO est plus facile à surveiller et à déboguer que le SFT, mais pluscomplexe que le réglage fin traditionnel. Le modèle DPO entraîné est sauvegardé localement et poussé vers Hugging Face Hub.

Évaluation des LLM

L'évaluation des LLM est cruciale pour évaluer leurs performances et leurs capacités. Elle peut prendre plusieursformes, allant des questions à choix multiple aux instructions ouvertes et aux retours d'utilisateurs. Il n'existe pas d'approche unifiée, mais des modèles et des recettes peuvent être adaptés à des cas d'utilisation spécifiques.

Évaluation du modèle

L'objectif de l'évaluation des modèles est d'évaluer les capacités d'un modèle unique, sans ingénierie d'invite (prompt engineering) ni pipeline RAG. Cela est essentiel pour sélectionner le LLM le plus pertinent ou pour s'assurer que le processus de réglage fin (fine-tuning) a réellement amélioré le modèle.

Comparaison de l'évaluation ML et LLM :

L'évaluation du ML se concentre sur les performances des modèles de prédiction, de classification et de régression à l'aide de métriques numériques objectives (précision, rappel, F1-score). L'évaluation des LLM est plus subjective et nuancée, car elle concerne l'interprétation et la génération du langage.

• Métriques numériques : L'évaluation ML utilise des métriques objectives. Les LLM nécessitent desapproches plus nuancées et des évaluations qualitatives.

• Ingénierie des fonctionnalités : Le ML traditionnel se concentre sur la sélection et la transformation manuelles des fonctionnalités. Les LLM traitent directement le texte brut.

• Interprétabilité : Le ML permet une interprétationdirecte des prédictions. Avec les LLM, l'interprétation se fait par l'explication du processus de décision.

Évaluations générales des LLM :

Ces évaluations couvrent un large éventail de capacités (connaissance, utilité) sans se concentrersur des tâches ou domaines spécifiques. Elles aident à avoir une vue d'ensemble, à comparer, et à identifier les forces et faiblesses.

Trois phases d'évaluation :

1. Pendant le pré-entraînement : Suivi des métriquesde bas niveau (perte d'entraînement, perte de validation, perplexité, norme de gradient) et de benchmarks (HellaSwag).

2. Après le pré-entraînement : Utilisation d'une suite de benchmarks (MMLU, HellaSwag, ARC-C, Winogrande, PIQA) pour évaluer le modèle de base.

3. Après le réglage fin : Benchmarks spécifiques aux modèles réglés finis (IFEval, Chatbot Arena, AlpacaEval, MT-Bench, GAIA) pour évaluer la capacité à suivre les instructions, les conversations multi-tours et les compétences d'agent (agentic skills).

Les benchmarks ont des limites (fraude aux tests, biais humains) et doivent être considérés comme des signaux, non comme une vérité unique.

Évaluations de LLM spécifiques au domaine:

Ces évaluations ciblent des capacités plus précises avec plus de profondeur. Le choix des benchmarks dépend entièrement du domaine (modèles linguistiques, code, etc.). Des suites de benchmarks reproductibles existent (Open Medical-LLM Leaderboard, BigCodeBench Leaderboard, Hallucinations Leaderboard, Enterprise Scenarios Leaderboard). Les LLM spécifiques à une langue réutilisent souvent des versions traduites de benchmarks généraux.

Évaluations de LLM spécifiques à une tâche :

Ces évaluations sont conçues pour des tâches spécifiques et mesurent les performances en aval.Les métriques ML traditionnelles (précision, rappel, F1-score) sont souvent utilisées pour des tâches structurées (résumé via ROUGE, classification). Pour des tâches plus ouvertes, la technique LLM en tant que juge (LLM-as-a-judge)est utilisée. Pour évaluer les modèles, on peut utiliser la génération de texte ou les probabilités log-likelihood. La version de génération de texte est recommandée pour sa simplicité et sa capacité à imiter l'expérience humaine. Des biais (biais de position, de longueur, de famille) peuvent affecter l'évaluationpar LLM et doivent être atténués.

Évaluation RAG

L'évaluation RAG nécessite une approche complète, tenant compte à la fois des capacités génératives du modèle et de son interaction avec des sources d'information externes. Les systèmes RAG combinent les forces des LLMavec des mécanismes de récupération d'informations pour générer des réponses cohérentes et fondées sur des informations à jour.

L'évaluation RAG dépasse celle d'un LLM autonome. Elle examine la performance de l'ensemble du système, incluant :

• Précision de la récupération : Dans quelle mesure le système récupère-t-il des informations pertinentes ?

• Qualité de l'intégration : Dans quelle mesure les informations récupérées sont-elles efficacement intégrées dans la réponse générée ?

• Facticité et pertinence : La sortie finale répond-elle à la requête de manière appropriée, en mélangeant harmonieusement le contenu récupéré et généré ?

Deux méthodes pour évaluer les modèles RAG :

1. Ragas (Retrieval-Augmented Generation Assessment) : Boîte à outils open-source pour l'évaluation et l'optimisation RAG basée sur les métriques. Génère des jeux de données de test synthétiques, diversifiés et complexes. Fournit une suite de métriques d'évaluation assistées par LLM : fidélité (cohérence factuelle), pertinence de la réponse, précision du contexte, rappel du contexte.

2. ARES (Automated Evaluation Framework for Retrieval-Augmented Generation Systems) : Outil complet pour évaluer les systèmes RAG. Combine la génération de données synthétiques avec des classifieurs ajustés (fine-tuned classifiers) pour évaluer la pertinence contextuelle, la fidélité de la réponse et la pertinence de la réponse.

Ragas et ARES se complètent :Ragas pour la surveillance en production et les métriques assistées par LLM, ARES pour l'évaluation hautement configurable basée sur des classifieurs.

Évaluation de TwinLlama-3.1-8B

L'évaluation des modèles TwinLlama-3.1-8B et TwinLlama-3.1-8B-DPO vise à évaluer leur capacité à générer du texte précis et bien rédigé, en adoptant un style d'écriture plus naturel. Pour ce faire, on utilise un LLM juge (GPT-4o-mini)pour évaluer la qualité du texte généré, en se basant sur deux critères :

• Précision : Degré de correction factuelle et d'exhaustivité de l'information.

• Style : Pertinence du ton et du style d'écriture pour despublications de blog ou du contenu de réseaux sociaux.

Le processus d'évaluation comprend :

1. Génération de réponses : Utilisation de vLLM pour une génération rapide. Mise en forme des instructions avec une invite de conversation (chat template).

2. Évaluation des réponses : Utilisation de GPT-4o-mini comme juge. Le prompt d'évaluation définit les échelles pour chaque métrique (Précision et Style) et fournit des exemples de styles d'écriture.

3. Analyse des résultats : Comparaison qualitative et quantitative (scores moyens) des modèles.

Les résultats montrent que TwinLlama-3.1-8B-DPO réussit à adopter un style plus accessible et moins formel sans sacrifier la qualité du contenu, tandis que Llama-3.1-8B-Instruct (modèle de référence) est plus verbeux. Cette évaluation qualitative, appuyée par les scores du LLM juge (qui confirment la supériorité du modèle DPO en termes de style), aide à affiner le processus de génération de données et à améliorer les modèles futurs.

Optimisation de l'Inférence

Le déploiement des LLM est un défi en raison de leurs exigences de calcul et de mémoire. L'optimisation de l'inférence est cruciale pour de nombreuses applications pratiques, visant à réduire la latence de générationdu premier jeton, augmenter le débit (jetons par seconde) et minimiser l'empreinte mémoire.

Stratégies d'optimisation du modèle

Les LLM modernes sont souvent basés sur une architecture Transformer de type "décodeur seulement", ce qui lesrend efficaces pour la génération de texte séquentielle. Cependant, cette nature séquentielle est un goulot d'étranglement pour l'inférence. Les stratégies d'optimisation visent à améliorer la vitesse et à réduire l'utilisation de la VRAM.

Cache KV (Key-Value) :

Le cache KV stocke les paires clé-valeur produites par les couches d'auto-attention, évitant ainsi de les recalculer pour chaque nouveau jeton. Cela accélère considérablement la génération. Un cache KV statique pré-alloue l'espacedu cache, ce qui permet de le combiner avec torch.compile (pour PyTorch) pour un gain de vitesse jusqu'à 4x pour la passe avant (forward pass).

Traitement par lots continu (Continuous batching) :

Le traitement par lots consisteà traiter simultanément plusieurs requêtes d'inférence. Le traitement par lots continu (in-flight batching) gère la variabilité de la longueur des prompts et des sorties en injectant de nouvelles requêtes dès qu'une autre est terminée, maximisant ainsi l'utilisation dumatériel. Ceci est implémenté nativement dans la plupart des frameworks d'inférence.

Décodage spéculatif (Speculative decoding) :

Cette technique utilise un modèle proxy plus petit pour prédire plusieurs jetons simultanément. Le modèle complet valide ensuite ces prédictions. Si le modèle proxy est de bonne qualité, il est possible de générer plusieurs jetons en une seule étape, ce qui peut entraîner des gains de vitesse de l'ordre de 3 à 4 fois.

Mécanismes d'attention optimisés :

L'attention des Transformers présente une complexité quadratique avec la longueur de la séquence. Des innovations comme PagedAttention (de vLLM) s'inspirent de la mémoire virtuelle pour partitionner le cache KV, améliorant l'utilisation de la mémoire GPU et le débit. FlashAttention-2 (deTri Dao) réduit la complexité quadratique et les contraintes mémoire en divisant les matrices d'entrée/sortie en blocs et en utilisant l'online softmax.

Parallélisme de modèle

Le parallélisme de modèle permet de distribuerla mémoire et la charge de calcul des LLM sur plusieurs GPU, permettant ainsi d'entraîner et d'inférer des modèles trop volumineux pour un seul appareil. Il existe trois approches principales :

1. Parallélisme de données (Data parallelism - DP) :

GPU. Réduit la charge mémoire par GPU, mais introduit des "bulles de pipeline" (périodes d'inactivité des GPU) qui peuvent être mitigées par le micro-batching.

Parallélisme de tenseurs (Tensor parallelism - TP) : Divise les grandes matrices de poids (MLP, têtes d'attention) entre plusieurs GPU. Chaque GPU traite une partie des matrices et des sorties, puis les résultats partiels sont agrégés. Plus efficace que le parallélisme de pipeline, mais nécessite des interconnexions à haute vitesse.

Ces approches sont orthogonales et peuvent être combinées pour optimiser les performances. Le PP pour la réduction de mémoire, et le TP pour la réduction de latence. La combinaison exige un équilibre entre les compromis et une cartographie précise de l'architecture du modèle sur le matériel disponible.

Quantification de modèle

La quantification est le processus de représentation des poids et activations d'un réseau neuronal avec des types de données de précision inférieure. Elle réduit l'empreinte mémoire et accélère l'inférence des LLM.

Introductionà la quantification :

Deux approches principales :

• Quantification post-entraînement (PTQ) : Conversion directe des poids vers une précision inférieure sans ré-entraînement. Simple, mais peut dégrader les performances.
• Quantification consciente de l'entraînement(QAT) : Quantification durant l'entraînement ou le réglage fin, permettant au modèle de s'adapter aux poids de faible précision. Meilleures performances, mais nécessite plus de ressources de calcul et de données d'entraînement représentatives.

Le choix du type de données estcrucial (FP32, FP16, BF16, INT8). Les méthodes de quantification naïves (absmax, zéro-point) peuvent être utilisées, mais les outlier features (valeurs extrêmes des poids) des LLM posent problème. Des techniques avancées comme LLM.int8() (quantification mixte avec FP16 pour les outliers) ou NF4 (4-bit pour QLoRA) sont utilisées pour réduire la mémoire avec une perte minimale de performance.

Quantification avec GGUF et llama.cpp :

Le projet llama.cpp (C++) permet l'inférence LLM sur une large gamme de matériel (CPU, Android) et GPU via son format de quantification GGUF. Il est populaire pour sa large disponibilité de modèles quantifiés sur Hugging Face Hub.

Quantification avec GPTQ et EXL2 :

GPTQ et EXL2 sont des formats de quantification dédiés aux GPU, basés sur l'algorithme GPTQ. EXL2 offre une flexibilité de précision personnalisable (2 à 8 bits parpoids) et la plus haute performance avec sa bibliothèque ExLlamaV2. Ces formats sont plus rapides que llama.cpp pendant l'inférence. L'inférence est gérée par la bibliothèque ExLlamaV2, qui prend en charge les modèles GPTQ et EXL2.

Autres techniques de quantification :

• AWQ (Activate-aware Weight Quantization) : Protège les poids les plus importants en fonction de l'amplitude de l'activation, sans ré-entraînement.
• Techniques de quantification extrême comme QuIP# et HQQ ciblent les quantifications à 1 ou 2 bits, préservant mieux les performances des modèles originaux, surtout pour les grands modèles (>30B paramètres).

Conclusion: Un tableau résume les fonctionnalités des moteurs d'inférence (TGI, vLLM, TensorRT-LLM) comme le traitement par lots continu, le décodage spéculatif, FlashAttention-2, PagedAttention, et les parallélismes de modèle.

Pipeline d'Inférence RAG

Ce chapitre se concentre sur l'implémentation du pipeline d'inférence RAG, complémentaire au pipeline de fonctionnalités RAG (Chapitre 4). Le pipeline de fonctionnalités a peuplé la base de données vectorielle (DB) avec des documentsnettoyés, découpés et plongés (embeddings), désormais prêts pour le RAG.

Comprendre le pipeline d'inférence RAG du LLM Jumeau

Le pipeline d'inférence RAG est une architecture logicielle qui englobe la récupération,l'augmentation d'invite (prompt augmentation) et la génération de réponse. Il utilise un module de récupération pour interroger la DB vectorielle et une fonction pour appeler le LLM avec l'invite augmentée. L'objectif est de mettre en production le modèle LLM Jumeau,optimisé pour l'inférence (Chapitre 8).

Flux d'architecture du pipeline d'inférence RAG :

1. Requête utilisateur : L'utilisateur envoie une requête (par exemple, "Écrire un article sur...").
2. Expansion de requête : La requête initiale est augmentée pour générer de multiples requêtes qui capturent différentes perspectives du problème original.
3. Auto-requête (Self-querying) : Les métadonnées pertinentes (par exemple, le nom de l'auteur) sont extraites de la requête originale pour filtrer la recherche vectorielle.
4. Recherche vectorielle filtrée : Chaque requête est plongée (embedded), et une recherche de similarité est effectuée dans la DB vectorielle, en utilisant les filtres extraits par l'auto-requête.
5. Collecte des résultats : Les résultats des recherches multiples sont agrégés, dédupliqués et renvoyés sous forme de liste de morceaux (chunks).
6. Re-classement (Reranking) : Un algorithme (modèle cross-encoder)classe les morceaux agrégés en fonction de leur pertinence par rapport à la requête initiale, et sélectionne les K meilleurs.
7. Construction de l'invite et appel du LLM : La liste finale des morceaux pertinents est convertie en une chaîne de caractères pour construire l'invite finale,en utilisant un modèle d'invite, le contexte récupéré et la requête de l'utilisateur. L'invite est envoyée au LLM (hébergé sur AWS SageMaker).
8. Réponse : Le LLM génère la réponse basée sur l'invite augmentée, qui est ensuite renvoyée à l'utilisateur.

Exploration des techniques RAG avancées du LLM Jumeau

Les techniques RAG avancées sont appliquées dans le module de récupération : expansion de requête, auto-requête (self-querying), recherchevectorielle filtrée et re-classement (reranking). Ces techniques sont implémentées en utilisant une interface RAGStep et un modèle d'entité de domaine Query et EmbeddedQuery.

Optimisations de pré-récupération RAG avancées : expansion de requête et auto-requête :

1. Expansion de requête : Utilise un LLM (OpenAI's GPT-4o-mini) pour générer plusieurs versions d'une requête, capturant différentes facettes de la question originale et augmentant ainsiles chances de récupérer des documents pertinents.
2. Auto-requête (Self-querying) : Utilise un LLM (OpenAI's GPT-4o-mini) pour extraire des métadonnées cruciales de la requête (par exemple, le nom de l'auteur)qui seront utilisées comme filtres dans la recherche vectorielle.

Optimisation de récupération RAG avancée : recherche vectorielle filtrée :

La recherche vectorielle filtrée combine la similarité sémantique des plongements avec des critères de filtrage contextuels (métadonnées) pour améliorer la précision et réduire la latence. Cela résout le problème des documents sémantiquement similaires mais contextuellement non pertinents.

Optimisation de post-récupération RAG avancée : re-classement :

Le re-classement (reranking) ordonne les morceaux récupérés en fonction de leur pertinence par rapport à la requête initiale. Il utilise des modèles cross-encoder pour évaluer la similarité sémantique de manière plus précise que les méthodes initiales, puis ne sélectionne que les Kmeilleurs morceaux pour le contexte final. Le re-classement est particulièrement efficace lorsqu'il est combiné avec l'expansion de requête.

Implémentation du pipeline d'inférence RAG du LLM Jumeau

L'implémentation se concentre sur le module de récupération, le processus de création d'invite et la génération de réponse via le LLM.

Implémentation du module de récupération :

La classe ContextRetriever orchestre l'étape de récupérationen intégrant l'expansion de requête, l'auto-requête, le re-classement et la recherche vectorielle filtrée. La méthode search() de cette classe convertit l'entrée utilisateur en un objet de requête, extrait les métadonnées de l'auteur, étend la requête, effectue des recherches vectorielles filtrées en parallèle sur plusieurs catégories de données (posts, articles, dépôts) et re-classe les documents récupérés pour ne garder que les K plus pertinents.

Mettre toutes les pièces ensemble dans le pipeline d'inférence RAG :

La fonction call_llm_service() interface avec le service LLM (SageMaker). La fonction rag() encapsule la logique RAG complète. Elle récupère les documents pertinents avec ContextRetriever, construit le contexte, appelle call_llm_service() et renvoie la réponse du LLM.

Des améliorations potentielles incluent l'ajout d'une mémoire de conversation (historique des prompts et réponses) avec des stratégies de réduction de taille (dernier K éléments, résumé de conversation), un routeur (classifieur multi-catégories) pour prévoir les catégories de données à récupérer, l'utilisation d'un algorithme de recherche hybride (vectorielle + mots-clés) et des structures vectorielles multi-index.

Déploiement du Pipeline d'Inférence

Le déploiement du pipeline d'inférence pour l'application LLM Twin est une étape critique dans le cycle de vie du ML, car il rend les modèles accessibles aux utilisateurs finaux. Il exige une planification minutieuse pour répondre auxexigences de latence, de débit et de coûts, en tenant compte des techniques d'optimisation de l'inférence des LLM (Chapitre 8) et des meilleures pratiques MLOps.

Critères de choix des types de déploiement

Quatre exigencesfondamentales orientent les décisions de déploiement :

1. Débit (Throughput) : Nombre de requêtes d'inférence traitées par seconde (RPS). Crucial pour des volumes élevés de requêtes.
2. Latence : Temps nécessaire pourtraiter une seule requête d'inférence. Critique pour les applications en temps réel.
3. Données : Format, volume et complexité des données d'entrée/sortie du modèle. Impacte directement la latence et le débit.
4. Infrastructure : Matériel, logiciel, réseau et architecturesystème sous-jacents qui supportent le déploiement.

Un compromis doit toujours être fait entre ces quatre éléments. Par exemple, une faible latence peut être sacrifiée pour un débit élevé lors du traitement par lots, ce qui réduit l'utilisation du matériel et augmente les coûtsunitaires.

Comprendre les types de déploiement d'inférence

Trois types fondamentaux de déploiement d'inférence coexistent, offrant des compromis différents.

1. Inférence en temps réel (Online real-time inference) : Architecture synchrone où le client envoie une requête HTTP et reçoit une réponse immédiate. Nécessite une infrastructure à faible latence et haute réactivité (serveurs rapides, évolutifs, équilibrage de charge, auto-mise à l'échelle, haute disponibilité). Exemples : chatbots,API LLM, moteurs de recommandation en ligne.
2. Inférence asynchrone (Asynchronous inference) : Le client envoie une requête qui est mise en file d'attente pour traitement différé, puis est notifié lorsque les résultats sont prêts (polling ou push). Permet uneutilisation plus efficace des ressources et gère mieux les pics de requêtes. Introduit une latence plus élevée, mais optimise les coûts. Exemples : extraction de mots-clés, résumé de documents, modèles de deepfake.
3. Transformation par lots hors ligne (Offline batch transform) :Traitement de grands volumes de données simultanément, planifié ou manuel. Optimisé pour un débit élevé avec des exigences de latence permissives. Moins cher et plus simple à implémenter. Le client récupère les résultats directement du stockage de données. Exemples : analyse de données, rapports périodiques, systèmesde recommandation pour des plateformes de vidéo.

Architecture monolithique vs microservices dans le service de modèles

La structure du service ML lui-même peut être monolithique ou divisée en microservices, impactant l'implémentation, la maintenance et lamise à l'échelle.

• Architecture monolithique : Le LLM et la logique métier associée sont regroupés dans un seul service. Simple à démarrer, facile à maintenir pour les petits projets. Difficulté à mettre à l'échelle les composants indépendamment (GPU pour le LLM, CPUpour la logique métier), ce qui mène à une utilisation inefficace des ressources.
• Architecture microservices : Le pipeline d'inférence est décomposé en services indépendants. Chaque microservice peut être mis à l'échelle indépendamment, par exemple, le service LLM (GPU-intensif) séparément de la logique métier (CPU-intensive). Optimise l'utilisation et réduit les coûts, permet des piles technologiques (tech stacks) différentes. Introduit une complexité de déploiement, de surveillance et de communication réseau.

Une stratégie courante est de commencer avec une conception monolithique et de la décomposer en microservices à mesure que le projet grandit, en privilégiant la modularité dès le début.

Stratégie de déploiement du pipeline d'inférence du LLM Jumeau

Pourle LLM Jumeau (chatbot de création de contenu), une architecture d'inférence en temps réel (online real-time) est nécessaire pour une faible latence. Une architecture microservices sera utilisée, séparant un serveur API REST (logique métier) d'un microservice LLM (optimisé pour l'exécution du LLM). Le microservice LLM sera déployé sur AWS SageMaker.

La logique métier (module de récupération RAG) coordonnera la récupération et l'augmentation RAG, intégrant les techniques RAG avancées.Le microservice LLM se concentrera sur la génération RAG. Les traces d'invite (prompt traces) seront envoyées au pipeline de surveillance (Chapitre 11).

Pile technologique (Tech stack) :

• DBvectorielle : Qdrant.
• Registre de modèles : Hugging Face.
• Microservice métier : FastAPI.
• Microservice LLM : AWS SageMaker, utilisant les conteneurs de deep learning (DLC) de Hugging Face et son moteur d'inférence TGI (Text Generation Inference).

Déploiement du service LLM Jumeau

Le déploiement du service LLM Jumeau implique l'implémentation du microservice LLM sur AWS SageMaker et du microservice métier avec FastAPI, intégrant la logique RAGpour un pipeline d'inférence de bout en bout.

Implémenter le microservice LLM avec AWS SageMaker :

Le modèle LLM Jumeau de Hugging Face est déployé sur Amazon SageMaker comme un point d'extrémité d'inférence en temps réel. Onutilise les DLC (Deep Learning Containers) LLM de Hugging Face qui incluent des frameworks ML essentiels et le moteur TGI (Text Generation Inference) pour une inférence haute performance (parallélisme de tenseurs, traitement par lots dynamique, Flash Attention, quantification, chargement accéléré des poids,streaming de jetons).

Processus :

1. Configuration des rôles SageMaker : Création d'un utilisateur IAM restreint (via poetry poe create-sagemaker-role) et d'un rôle d'exécution IAM (via poetry poe create-sagemaker-execution-role) pour SageMaker, qui lui donne les permissions nécessaires pour accéder aux ressources AWS (S3, CloudWatch, ECR).
2. Déployer le modèle LLM Jumeau sur AWS SageMaker : Lancementdu déploiement via une commande CLI (poe deploy-inference-endpoint). Le code python orchestre ce processus en utilisant les classes ResourceManager, DeploymentService et SagemakerHuggingfaceStrategy pour configurer et déployer le modèle Hugging Face sur SageMaker. Cela inclut la spécification de l'image Docker DLC, le rôle IAM, le type d'instance GPU et les paramètres de configuration LLM (quantification, jetons max, etc.).

Appeler le point d'extrémité d'inférence AWS SageMaker :

Une fois le service LLM déployé, on utilise les classes LLMInferenceSagemakerEndpoint (pour interagir avec SageMaker) et InferenceExecutor (pour préparer l'invite et exécuter l'inférence) pour envoyer des requêtes HTTP aupoint d'extrémité SageMaker.

Construire le microservice métier avec FastAPI :

Une application FastAPI est configurée pour exposer les fonctionnalités RAG via un point d'extrémité HTTP (/rag). Cette application utilise la logique RAG du Chapitre 9,appelle le microservice LLM de SageMaker et traite les réponses. La logique RAG est légère en CPU/IO, le calcul lourd étant délégué au microservice LLM GPU).

Capacités d'auto-mise à l'échelle (autoscaling) pour gérer les pics d'utilisation

L'auto-mise à l'échelle est essentielle pour gérer les coûts et la performance. Elle ajuste dynamiquement le nombre de répliques du modèle en fonction de métriques comme le nombre de requêtes. Cela évite le sur-provisionnement (coûts élevés) ou le sous-provisionnement (mauvaise expérience utilisateur).

Processus d'auto-mise à l'échelle :

1. Enregistrer une cible évolutive : Informer AWS du service (par exemple, SageMaker Inference components) à mettre à l'échelle et définir les limites min/max.
2. Créer une politique évolutive : Définir des règles (par exemple, TargetTrackingScaling) qui déclenchent les événements de mise à l'échelle. Par exemple, maintenir une utilisation GPU à 70%.

Un Load Balancer (ALB) est utilisé pour distribuer les requêtes entre les multiples répliques. Une période de cooldown prévient les fluctuations excessives du nombre d'instances.

Attention :L'auto-mise à l'échelle doit être ajustée pour éviter le sur-provisionnement (coûts) ou le sous-provisionnement (mauvaise expérience utilisateur).

MLOps et LLMOps

Les MLOps (Machine Learning Operations) et LLMOps (LargeLanguage Model Operations) sont des domaines clés pour l'automatisation et la gestion du cycle de vie des modèles ML. Ce chapitre explore leurs racines dans le DevOps, leurs composants et principes fondamentaux, tout en soulignant les particularités des LLM.

Le chemin vers les LLMOps : comprendreses racines dans le DevOps et le MLOps

DevOps :

Le DevOps a émergé comme une méthodologie pour automatiser le processus de livraison de logiciels de haute qualité, en écourtant le cycle de développement. Il encourage la collaboration, l'automatisation, l'intégration des flux de travail et les boucles de rétroaction rapides. Les bénéfices incluent une collaboration améliorée, une efficacité accrue, une amélioration continue et une qualité/sécurité supérieure.

Le cycle de vie DevOps comprend la planification, le codage, laconstruction, le test, la publication, le déploiement, l'exploitation et la surveillance. Les concepts clés sont les environnements de déploiement (dev, staging, production), le contrôle de version, l'intégration continue (CI) et le déploiement continu (CD).

MLOps:

Le MLOps applique les principes DevOps au ML. Il prend en compte que les systèmes ML impliquent des données, des modèles et du code, qui peuvent tous évoluer indépendamment. Le MLOps vise la traçabilité, l'opérationnalisation et la surveillance de ces trois dimensionspour une meilleure reproductibilité, robustesse et contrôle. Un changement dans l'un de ces éléments peut déclencher des étapes d'entraînement ou de déploiement.

Les composants clés du MLOps sont le registre de modèles, le magasin de fonctionnalités, le magasinde métadonnées ML et l'orchestrateur de pipelines ML. Les six principes fondamentaux du MLOps sont l'automatisation (ou opérationnalisation via CT/CI/CD), le versionnage (code, modèle, données), le suivi d'expériences, les tests (code, données, modèles), la surveillance et la reproductibilité.

Ingénierie ML vs. MLOps :

L'ingénierie ML (MLE) se concentre sur la construction de modèles modulaires et accessibles (via DB ou API), tandis que l'ingénierie MLOps se concentre sur l'opérationnalisation de ce code sur une infrastructure générique, en pensant à la mise à l'échelle, la latence et la rentabilité. Dans les petites équipes, ces rôles se chevauchent souvent.

LLMOps:

Le LLMOps est une branche spécialisée du MLOps, axée sur les défis uniques des LLM : leur taille massive, les exigences d'entraînement complexes, la gestion des invites (prompts) et la nature non déterministe de la génération de réponses. Il hérite des fondamentaux du MLOps mais y ajoute des préoccupations spécifiques aux LLM.

Les défis majeurs pour l'entraînement des LLM à partir de zéro incluent la collecte et la préparation de données massives (des trillions de jetons),la gestion d'un nombre considérable de paramètres (nécessitant des clusters GPU), le multi-GPU training et les coûts d'infrastructure substantiels (estimés à 100 millions de dollars pour GPT-4).

Pour la plupart des applications LLM, l'accent estmis sur la sélection d'un modèle de base, l'ingénierie d'invite (prompt engineering), le réglage fin (fine-tuning) ou le RAG.

Composants LLMOps populaires :

• Retour d'expériencehumain (Human Feedback) : Intégration de boucles de rétroaction (par exemple, votes "pouce levé/pouce bas") pour recueillir des données de préférence et ajuster le LLM via RLHF ou DPO.
• Garde-fous (Guardrails) : Protection contre les résultats indésirables (hallucinations, fuites d'informations sensibles, contenu toxique). Les garde-fous d'entrée protègent contre les prompts malveillants, tandis que les garde-fous de sortie vérifient les réponses générées.
• Surveillance des invites (Prompt Monitoring) : Enregistrement et analyse des prompts, réponses générées, jetons, latence, etc., sur toute la "trace" de la requête utilisateur (avec des outils comme Opik ou Langfuse) pour le débogage et l'optimisation des coûts.

Déploiement des pipelines du LLM Jumeau sur le cloud

Pour le LLM Jumeau, le déploiement implique :

1. Mettre en place des instances serverless MongoDB et Qdrant.
2. Déployer les pipelines ZenML, les registres de conteneurs et d'artefacts sur AWS.
3. Contenairiser le code et pousser l'image Docker vers un registre de conteneurs.

Les coûts de déploiement sont minimaux (quelques dollars pour AWS) en utilisant les versions gratuites des services mentionnés.

Comprendre l'infrastructure :

L'infrastructure cible repose sur des services serverless (MongoDB, Qdrant) et le cloud ZenML, qui orchestre ledéploiement sur AWS. Le cloud ZenML alloue les ressources AWS nécessaires : ECR (registre Docker), S3 (stockage d'artefacts) et SageMaker (orchestrateur). Le processus de déploiement suit :

1. Construction d'une imageDocker avec toutes les dépendances.
2. Envoi (push) de l'image Docker vers ECR.
3. Déclenchement des pipelines ZenML depuis CLI ou le tableau de bord.
4. Exécution des étapes de pipeline sur des machines virtuelles AWS EC2 via SageMaker.
5. Accès aux stockages S3, MongoDB et Qdrant par les travaux SageMaker.

Mise en place de MongoDB et Qdrant :

Il faut créer des clusters gratuits sur MongoDB Atlas et Qdrant Cloud, puis configurer les clés d'accès et les URL des clusters dans le fichier .env du projet.

Mise en place du cloud ZenML :

1. Créer un compte ZenML Cloud (essai gratuit de sept jours).
2. Créer une organisation et un tenant (appelé twin).
3. Connecter le projet local au tenant ZenML Cloud via zenml connect.
4. Créer une pile AWS (aws-stack) via l'interface ZenML Cloud, qui utilise CloudFormation pour provisionner les ressources AWS(IAM, S3, ECR, SageMaker).

Contenairiser le code avec Docker :

Un Dockerfile est utilisé pour construire une image Docker contenant Python 3.11, Google Chrome (pour les analyseurs basés sur Selenium),les dépendances système, Poetry et les dépendances Python du projet. L'image est construite sur une plateforme Linux. Après la construction, l'image Docker est poussée vers le dépôt ECR AWS créé par ZenML.

Exécuter les pipelines sur AWS :

Changer la pile ZenML par défaut vers aws-stack. Mettre à jour l'URL de l'image parente Docker dans le fichier de configuration configs/end_to_end_data.yaml avec l'URL ECR. Exporter les identifiants du fichier .env vers les secrets ZenML. Configurer l'orchestrateur ZenML pour les pipelines asynchrones. Exécuter le pipeline end-to-end-data-pipeline via Poe.

Ajouter les LLMOps au LLM Jumeau

Cettesection détaille l'automatisation des processus du LLM Jumeau via les principes LLMOps : un pipeline CI/CD (intégration et déploiement continus) avec GitHub Actions, un pipeline CT (entraînement continu) avec ZenML, et un pipeline de surveillance avec Opik de Comet ML, ainsi qu'un système d'alerte avec ZenML.

Flux du pipeline CI/CD du LLM Jumeau :

Deux environnements : staging et production. Le processus commence avec une branche de fonctionnalité fusionnée avec la branche staging (ou mainpour la production). Le pipeline CI est déclenché à l'ouverture d'une Pull Request (PR), effectuant du linting, du formatage (avec Ruff), des vérifications gitleaks et des tests automatisés (avec Pytest). Le pipeline CD est déclenché après la fusion, construisantune nouvelle image Docker et la poussant vers ECR. Ce processus assure la conformité aux standards et la détection précoce des bugs.

Aperçu de GitHub Actions :

GitHub Actions est une plateforme CI/CD intégrée à GitHub. Elle utilise des workflows (fichiers YAML) pour définir des jobs (groupes d'étapes) qui s'exécutent sur des runners (machines virtuelles). Les workflows sont déclenchés par des événements (push, pull_request).

Le pipeline CI :

Le fichier .github/workflows/ci.yaml définit un workflow CI déclenché par une PR. Il comprend deux jobs : qa (linting, formatage, gitleaks) et test (tests automatisés). Chaque job configure un environnement Python, installe Poetry etles dépendances, puis exécute les vérifications et les tests. En cas d'échec, la PR ne peut être fusionnée.

Le pipeline CD :

Le fichier .github/workflows/cd.yaml définit un workflow CD déclenché par un push surla branche main. Il construit une image Docker et la pousse vers AWS ECR. Le processus inclut la configuration des identifiants AWS via les secrets GitHub, la connexion à ECR, la construction de l'image Docker avec docker buildx et son envoi (push) versECR.

Le pipeline CT :

Le pipeline CT utilise ZenML pour automatiser l'entraînement et le déploiement sur l'infrastructure AWS. La conception repose sur l'architecture FTI et l'utilisation précoce d'un orchestrateur (ZenML).Une "master pipeline" agrège les pipelines de collecte de données, de fonctionnalités, de génération de jeux de données d'instructions, d'entraînement et de déploiement. ZenML permet de déclencher les pipelines manuellement, via des API REST ou de manière planifiée (scheduled).

Surveillance des invites (Prompt Monitoring) :

Opik (de Comet ML) est utilisé pour logguer et analyser les traces complètes des requêtes utilisateur, du prompt initial à la réponse finale. Le décorateur @track permet de suivre les entrées/sorties de fonctions. Des métadonnées et tags peuvent être ajoutés aux traces via opik_context.update_current_trace(). Les éléments critiques à surveiller sont la configuration du modèle, le nombre total de jetons et la durée de chaque étape. L'implémentation d'Opik sefait dans le microservice métier FastAPI.

Alertes (Alerting) :

ZenML permet de mettre en œuvre un système d'alerte pour notifier les échecs ou succès de pipelines (par exemple, par e-mail, Discord, Slack) en utilisant des rappels (callbacks) on_failure ou on_success.

Principes MLOps

Les MLOps fournissent un cadre essentiel pour construire des systèmes ML robustes et évolutifs. Ils étendent les pratiques DevOps aux défis spécifiques du MachineLearning, garantissant cohérence, fiabilité et évolutivité tout au long du cycle de vie des modèles.

1. Automatisation ou opérationnalisation

L'automatisation en MLOps se décline en trois niveaux :

1. Processus manuel : Phase expérimentale initiale, où les étapes sont effectuées manuellement (par exemple, dans les notebooks Jupyter).
2. Entraînement continu (CT) : Automatisation de l'entraînement des modèles, déclenché par des événements (nouveautés de données, baisse de performance). Utilisé pour adapter le modèle aux données de production.
3. Intégration et Déploiement Continus (CI/CD) : Automatisation de la construction, du test et du déploiement du code ML et des composants du pipeline d'entraînement.

L'architecture FTI (Fonctionnalités, Entraînement, Inférence) facilite la transition vers CI/CD/CT en créant un système modulaire avec des interfaces claires. Le CT automatise les pipelines FTI, tandis que le CI/CD gère les mises àjour du code dans ces pipelines.

2. Gestion des versions (Versioning)

Le versionnage est essentiel car tout changement dans le code, le modèle ou les données affecte l'ensemble du système ML. Il est crucial de suivre ces trois éléments de manière individuelle:

• Code : Suivi par des outils comme Git (GitHub, GitLab), avec des commits et des versions sémantiques (majeure, mineure, patch).
• Modèle : Versionné via un registre de modèles (Comet ML, W&B, MLflow, ZenML), avec des conventions de versionnage sémantique et des métadonnées détaillées.
• Données : Versionnage complexe, dépendant du type (structuré, non structuré) et de l'échelle. Des solutions comme DVC ou les artefacts (Comet.ml, W&B, ZenML) sont utilisées, souvent avec un stockage cloud (AWS S3) en arrière-plan.

3. Suivi d'expériences (Experiment tracking)

L'entraînement de modèles ML est un processus itératif et expérimental. Un outil de suivi d'expériences (Comet ML, W&B, MLflow, Neptune) est indispensable pour logger les métriques, visualisations et informations nécessaires afin de comparer les expériences et sélectionner le meilleur modèle pour la production.

4. Tests (Testing)

Les tests en MLOps couvrent le code, les données et les modèles, et s'assurent que les pipelines FTI fonctionnent bien ensemble et avec les services externes. Les types de tests incluent :

• Tests unitaires : Composants individuels.
• Tests d'intégration : Interactions entre composants.
• Tests système : L'application complète (performance, sécurité, UX).
• Tests d'acceptation : Vérification de la conformité aux exigences.
• Tests de régression : Détection de la réintroduction de bugs.
• Tests de stress : Performance sous charge extrême.

Les tests de données vérifient la validité (valeurs non nulles, format, etc.). Les tests de modèles sont cruciaux car les systèmesML peuvent fonctionner sans erreur tout en produisant des résultats incorrects. Ils incluent la vérification des formes des tenseurs, la diminution de la perte, l'overfitting sur de petits lots et la vérification des dispositifs supportés (CPU/GPU).

Le test comportemental, comme proposé par "Beyond Accuracy: Behavioral Testing of NLP Models with CheckList", traite le modèle comme une boîte noire et se concentre sur les relations entrée-sortie (invariance, directionnel, fonctionnalité minimale).

5. Surveillance (Monitoring)

La surveillance est vitale car les systèmes ML sont probabilistes et sujets à la dégradation des performances due à l'évolution des données de production (dérive). L'objectif est de détecter et corriger ces erreurs à temps.

• Journaux (Logs) : Capturer tout (configurations, requêtes, résultats, événements intermédiaires).
• Métriques : Mesurer la santé de l'application (infrastructure, données, modèle).
  • Métriques système : Latence, débit, taux d'erreur, utilisation CPU/GPU/mémoire.
  • Métriques de modèle : Précision, rappel, F1-score, ROI, taux de clics. L'analyse par fenêtres temporelles est préférée.
• Dérives (Drifts) : Mesures proxy qui détectent des changementsdans la distribution des données.
  • Dérive de données (Data drift) : La distribution des données de production diffère des données d'entraînement.
  • Dérive de cible (Target drift) : Changements dans la distribution des sorties.
  • Dérive de concept (Concept drift) : La relation entre les entrées et les sorties change.
  Des tests d'hypothèses (Kolmogorov-Smirnov, chi-carré, MMD) sont utilisés pour détecter et mesurer ces dérives.
• Surveillance vs. observabilité : La surveillance collecte des données, l'observabilité fournit des informations sur l'état interne du système.
• Alertes : Notifications déclenchées lorsque les métriques dépassent des seuils prédéfinis ou que des dérives sont détectées.

6. Reproductibilité (Reproducibility)

La reproductibilité signifie que chaque processus au sein des systèmes ML doit produire des résultats identiques avec la même entrée. Cela implique :

• Suivi des entrées : Connaître tous les éléments utilisés pour générer de nouveaux actifs (version de jeude données, configuration, hyperparamètres).
• Gestion de la non-déterminisme : L'entraînement ML est non déterministe. Utiliser des graines (seeds) pour les nombres pseudo-aléatoires assure la cohérence des résultats.