Distinguer assistant personnalisé, RAG, fine-tuning et entraînement depuis zéro

Formation complémentaire — Créer son propre modèle d’IA pour son entreprise
Module 1 — Définir le projet : choisir ce qu’il faut réellement personnaliser
Unité 1 — Distinguer assistant personnalisé, RAG, fine-tuning et entraînement depuis zéro

Lorsqu’une entreprise souhaite « créer son IA », elle peut chercher à obtenir plusieurs résultats différents :

• un assistant qui respecte ses consignes ;
• un outil qui consulte ses documents ;
• un modèle qui exécute mieux une tâche spécialisée ;
• un système dont elle maîtrise l’hébergement ;
• un modèle entraîné à partir de ses propres données.

Ces objectifs ne correspondent pas à la même opération technique.

Pour choisir correctement, il faut répondre à quatre questions :

1. Où se trouvent les informations propres à l’entreprise ?
2. Quels éléments sont modifiés ?
3. Que reçoit le modèle lorsqu’il répond ?
4. Que faut-il mettre à jour lorsque le besoin change ?

Cette unité explique les mécanismes et leurs conséquences, puis les applique à un même cas d’entreprise.

1. Objectifs pédagogiques

À la fin de cette unité, vous devez pouvoir :

• distinguer une application d’IA, un modèle et un moteur d’exécution ;
• différencier contexte, historique, index documentaire, cache et paramètres appris ;
• expliquer ce qu’une personnalisation par consignes modifie réellement ;
• décrire les étapes d’une chaîne RAG ;
• expliquer comment un fine-tuning modifie le comportement d’un modèle ;
• distinguer fine-tuning complet, adaptation par LoRA et poursuite du préentraînement ;
• préciser ce que signifie entraîner depuis zéro ;
• choisir une première approche à partir d’un problème observable ;
• identifier les propriétés qui ne sont garanties par aucune de ces méthodes.

Le livrable est une fiche de décision technique initiale, justifiant la méthode à tester et les résultats attendus.

2. Définir les composants avant de comparer les méthodes

Le terme « IA » désigne souvent un ensemble de composants.

Exemple

Une entreprise utilise un modèle existant dans un moteur local, avec une interface, une consigne et une base de procédures.

Elle possède un assistant métier personnalisé.

Pour savoir si elle possède également un modèle adapté, il faut vérifier si un processus d’apprentissage a modifié des paramètres ou produit un adaptateur.

Le nom affiché dans l’interface ne permet pas de répondre à cette question.

3. Comprendre ce qui se passe pendant une génération

Pour un modèle de langage autorégressif classique, la réponse est produite progressivement.

À chaque étape, le modèle calcule une distribution de probabilités sur les tokens possibles, à partir :

• des paramètres chargés ;
• du contexte disponible ;
• des tokens déjà générés.

Une notation simplifiée est :

\[ P_\theta(y_t \mid x, y_1,\ldots,y_{t-1}) \]

Avec :

• \(\theta\) : les paramètres du modèle ;
• \(x\) : le contexte fourni ;
• \(y_t\) : le prochain token ;
• \(y_1,\ldots,y_{t-1}\) : les tokens déjà produits.

Il n’est pas nécessaire de maîtriser la formule pour retenir la distinction essentielle :

• modifier le contexte change ce que le modèle reçoit ;
• entraîner le modèle change les paramètres qui servent au calcul.

Les réglages de génération interviennent ensuite dans le choix des tokens. Une température plus basse ne constitue ni un entraînement ni une vérification des faits.

4. Distinguer les différentes formes de « mémoire »

Le mot « mémoire » est particulièrement ambigu.

Le cache KV conserve notamment des représentations de clés et de valeurs pour éviter certains recalculs. Il ne constitue pas un apprentissage permanent des conversations. Hugging Face

Exemple

Vous indiquez :

Mon entreprise s’appelle Atelier Démo.

L’assistant réutilise ce nom dix messages plus tard.

Cela peut simplement signifier que :

• le message est encore dans le contexte ;
• un résumé de la conversation le contient ;
• une préférence enregistrée a été réintroduite.

Cela ne démontre pas une modification du modèle.

5. Un cas d’entreprise commun aux quatre approches

L’entreprise fictive Atelier Démo veut aider son service client.

Elle possède la procédure suivante :

Les demandes standard reçoivent une première réponse sous deux jours ouvrés. Les demandes nécessitant une expertise technique reçoivent une première réponse sous cinq jours ouvrés. Ces délais ne sont pas des délais de résolution.

L’assistant doit :

• identifier le type de demande ;
• expliquer la règle applicable ;
• préserver la distinction entre première réponse et résolution ;
• préparer un brouillon ;
• ne rien envoyer automatiquement.

Question de test :

Le dossier nécessite une expertise technique. Quel délai de résolution puis-je annoncer au client ?

Réponse attendue sur le fond :

La procédure prévoit une première réponse sous cinq jours ouvrés. Elle ne fixe pas de délai de résolution ; il ne faut donc pas en annoncer un sur cette seule base.

Nous allons examiner comment chaque méthode peut contribuer à ce résultat.

6. Assistant personnalisé : modifier la configuration et le contexte

Un assistant personnalisé est une application configurée pour un usage.

La personnalisation peut porter sur :

• le nom et l’interface ;
• les instructions ;
• les exemples ;
• les outils accessibles ;
• les documents consultables ;
• les formats ;
• les permissions.

« Assistant personnalisé » n’est donc pas une méthode d’apprentissage. Un assistant personnalisé peut utiliser un modèle inchangé, un RAG, un modèle adapté, ou plusieurs de ces éléments.

Pour isoler le premier mécanisme, considérons une personnalisation par consignes uniquement.

Exemple

Tu aides le service client d’Atelier Démo.

Prépare des réponses factuelles et courtes.

Distingue systématiquement :
- délai de première réponse ;
- délai de résolution.

N’invente aucun engagement.
Si la règle applicable manque, demande-la.

Ce qui change : le contexte préparé par l’application.

Ce qui ne change pas : les poids du modèle.

Limite : cette consigne ne fournit pas encore le délai de cinq jours. Le modèle ne peut pas être supposé connaître une règle interne qui ne lui a pas été communiquée.

7. Fournir une règle directement dans le contexte

L’application peut ajouter la procédure à chaque demande.

Règle validée d’Atelier Démo :

- Demande standard : première réponse sous deux jours ouvrés.
- Expertise technique : première réponse sous cinq jours ouvrés.
- Aucun délai de résolution n’est défini par cette règle.

Le modèle dispose alors de l’information nécessaire.

Il n’a toujours pas été entraîné.

Conséquences pratiques

• la règle doit être présente lorsque la réponse en dépend ;
• sa longueur consomme une partie de la fenêtre de contexte ;
• sa mise à jour porte sur la configuration ou le document inséré ;
• une nouvelle session peut perdre cette règle si l’application ne la réintroduit pas ;
• la réponse doit rester contrôlée.

Pour un petit nombre de règles courtes, cette méthode peut suffire.

Une recherche documentaire n’est pas obligatoire lorsque tout le contenu utile peut être fourni directement et de manière maîtrisée.

8. Fournir des exemples : l’apprentissage en contexte

Ajoutons un exemple :

Question :
« Puis-je promettre une résolution sous cinq jours ? »

Réponse attendue :
« Non sur la seule base de cette procédure.
Les cinq jours concernent la première réponse.
Le délai de résolution n’est pas indiqué. »

Le modèle utilise cet exemple pendant le traitement.

Cette approche peut être appelée few-shot prompting ou apprentissage en contexte. Dans son usage classique, elle ne comporte pas de mise à jour des paramètres : les exemples sont fournis dans l’entrée. arxiv.org

La distinction avec le fine-tuning est précise :

Dans les deux cas, des exemples incorrects peuvent conduire à de mauvaises réponses.

9. RAG : retrouver les informations avant de répondre

Le RAG ajoute une phase de récupération d’informations.

Une représentation simplifiée est :

\[ \text{passages} = \text{recherche}(\text{question}, \text{sources autorisées}) \]

Puis :

\[ \text{réponse} = \text{génération}(\text{consignes}, \text{question}, \text{passages}) \]

Dans un RAG classique sans entraînement supplémentaire, les paramètres du modèle de génération restent inchangés.

Le système adapte le contexte à chaque question.

Pour Atelier Démo

1. L’utilisateur pose sa question.
2. L’application connaît ses droits.
3. Elle recherche dans les procédures accessibles.
4. Elle récupère la règle sur l’expertise technique.
5. Elle transmet ce passage au modèle.
6. Le modèle prépare la réponse.

Le RAG désigne une famille d’architectures associant récupération et génération. Des variantes peuvent entraîner le moteur de recherche ou le générateur ; l’utilisation du terme ne prouve donc pas à elle seule l’absence de tout entraînement. arxiv.org

10. Ce que l’indexation documentaire modifie réellement

Dans une chaîne utilisant des embeddings, la préparation peut comprendre :

1. extraction du texte ;
2. découpage en passages ;
3. ajout de métadonnées ;
4. calcul d’un vecteur par passage ;
5. enregistrement des vecteurs et des références.

Le modèle d’embeddings est alors utilisé pour calculer des représentations.

Il n’est pas nécessairement entraîné pendant cette opération.

La confusion vient de formulations telles que :

L’assistant apprend mes documents.

Dans ce cas, une formulation plus exacte est :

L’application extrait et indexe les documents pour pouvoir en retrouver des passages.

Ce qui persiste après indexation :

• documents ;
• texte extrait ;
• passages ;
• métadonnées ;
• vecteurs et index ;
• configurations.

Les documents ne sont pas transformés automatiquement en paramètres du modèle de génération.

Par ailleurs, toute recherche RAG n’est pas vectorielle : recherche par mots-clés et recherche hybride sont également possibles.

11. Ce que le RAG permet et ce qu’il ne garantit pas

Le RAG permet notamment :

• de sélectionner des informations pertinentes ;
• d’utiliser des documents récents ;
• d’associer des références ;
• d’organiser des corpus selon les droits ;
• de modifier les sources sans réentraîner systématiquement le générateur.

Il ne garantit pas :

• que le bon passage sera retrouvé ;
• que tous les passages nécessaires seront transmis ;
• que le texte extrait sera correct ;
• que le modèle respectera chaque exception ;
• que la citation justifiera réellement la réponse.

Trois échecs différents

Ces erreurs appellent des corrections différentes.

Entraîner le générateur ne corrige pas automatiquement les permissions ni l’absence du bon document.

12. Fine-tuning : modifier les paramètres appris

Le fine-tuning part d’un modèle déjà entraîné et poursuit son apprentissage.

Pour le fine-tuning supervisé, on prépare des entrées et des réponses de référence.

Exemple :

Entrée :
Procédure : première réponse sous cinq jours ouvrés ;
aucun délai de résolution défini.
Question : peut-on promettre une résolution sous cinq jours ?

Sortie attendue :
Non. Les cinq jours concernent la première réponse.
Le délai de résolution n’est pas défini.

Pendant l’apprentissage :

1. le modèle traite l’entrée et la séquence cible selon le protocole ;
2. une fonction de perte mesure son aptitude à prédire les tokens attendus ;
3. des gradients sont calculés ;
4. un optimiseur modifie les paramètres entraînables.

L’objectif du SFT est un objectif de prédiction conditionnelle des sorties de référence. Il ne constitue pas un contrôle automatique de leur vérité. huggingface.co

Ce qui persiste : de nouveaux poids ou des paramètres d’adaptation enregistrés.

Pour retrouver le comportement adapté, il faut charger ces éléments, et pas seulement le modèle initial.

13. Ce qu’il faut apprendre dans notre exemple

Deux stratégies sont possibles.

Stratégie A — Faire apprendre une valeur particulière

Tous les exemples enseignent que l’expertise reçoit une première réponse sous cinq jours.

Le modèle peut renforcer cette association.

Mais si le délai devient sept jours, ce comportement appris risque de devenir obsolète.

Stratégie B — Faire apprendre une manière de traiter une règle

Les exemples présentent différents délais et différentes procédures.

La compétence visée est :

• extraire le délai fourni ;
• distinguer première réponse et résolution ;
• signaler une information absente ;
• préserver une exception.

Cette stratégie cherche une meilleure généralisation du comportement.

Pour un système documentaire évolutif, il est souvent plus pertinent de fournir les règles actuelles à l’inférence et d’adapter, si nécessaire, la manière de les exploiter.

Cela n’interdit pas l’apprentissage de faits. Cela évite de demander aux poids d’assurer seuls une fonction de référentiel actualisé.

14. Fine-tuning complet et LoRA : une différence de paramètres entraînés

Dans un fine-tuning complet, l’ensemble des paramètres du modèle peut être ajusté.

Dans une adaptation LoRA classique, les poids de base sont figés et des paramètres supplémentaires apprennent une correction sur certaines matrices.

Pour une matrice \(W_0\), on peut écrire :

\[ W_{\text{utilisé}} = W_0 + sBA \]

Avec :

• \(W_0\) : matrice de base figée ;
• \(A\) et \(B\) : matrices entraînées ;
• \(s\) : facteur d’échelle.

Si \(W_0\) mesure \(4096 \times 4096\), elle contient 16 777 216 paramètres.

Avec un rang de 8, les matrices de correction contiennent :

\[ 8 \times 4096 + 4096 \times 8 = 65\,536 \]

Cet exemple concerne une matrice, sans compter d’autres paramètres éventuellement entraînés. Le total dépend des modules ciblés.

LoRA réduit ainsi le nombre de paramètres à ajuster, mais les calculs utilisent toujours le modèle de base. La méthode ne supprime pas tous les besoins mémoire d’entraînement. arxiv.org

15. Ce que signifie « posséder l’adaptateur »

Un adaptateur LoRA n’est généralement pas autonome.

Il faut connaître :

• le modèle de base ;
• sa révision ;
• son architecture ;
• les modules ciblés ;
• la configuration d’adaptation ;
• le tokenizer et le format de conversation.

Deux modèles de taille comparable ne sont pas nécessairement interchangeables.

Un fichier d’adaptateur de petite taille ne contient pas, à lui seul, toutes les capacités du système final.

Selon la méthode et les outils, la correction peut être fusionnée dans une copie des poids. Il faut alors conserver les éléments d’origine pour assurer la traçabilité et le retour arrière.

16. Poursuite du préentraînement : un apprentissage sur un corpus supplémentaire

La poursuite du préentraînement commence également avec des poids existants.

Elle poursuit un objectif de préentraînement, par exemple la prédiction de tokens, sur un corpus supplémentaire.

Elle peut viser une meilleure adaptation :

• à une langue ;
• à une terminologie ;
• à un type de texte ;
• à un domaine.

Des travaux ont étudié cette adaptation de domaine et de tâche avant des évaluations spécialisées. Les bénéfices dépendent du corpus et des tâches évaluées. arxiv.org

Différence avec un SFT d’instructions

Les deux peuvent être successifs, mais cette complexité doit être justifiée.

17. Entraîner depuis zéro : partir de paramètres non préentraînés

Dans un entraînement depuis zéro, les paramètres concernés sont initialisés sans reprendre leurs valeurs apprises d’un modèle préentraîné.

L’équipe doit définir ou choisir :

• l’architecture ;
• le tokenizer ;
• les données ;
• l’objectif ;
• l’optimiseur ;
• l’organisation du calcul ;
• les évaluations.

Elle peut utiliser une architecture et des bibliothèques existantes. « Depuis zéro » concerne ici les paramètres appris, pas nécessairement l’invention de tous les composants.

Pour un grand modèle de langage, il faut lui faire acquérir les capacités qu’un modèle préentraîné apporte déjà : régularités linguistiques, représentations et aptitudes utiles aux tâches.

Quelques centaines de réponses clients ne remplacent pas ce préentraînement général.

En revanche, un petit classificateur spécialisé peut être entraîné depuis zéro avec des besoins très différents. Il faut toujours préciser de quel type de modèle on parle.

18. Comparer ce qui doit être mis à jour

Supposons que le délai d’expertise d’Atelier Démo passe de cinq à sept jours.

L’entraînement depuis zéro ne facilite pas automatiquement la modification d’un fait appris.

De même, une information supprimée du corpus d’apprentissage ne disparaît pas automatiquement d’un modèle déjà entraîné.

19. Comparer les garanties de traçabilité et d’accès

Un modèle partagé entraîné sur des informations confidentielles peut poser un problème différent d’un corpus documentaire filtré par utilisateur.

Il ne faut pas supposer qu’une consigne empêchera chaque utilisateur d’obtenir une information potentiellement apprise.

La solution dépend de l’architecture, des données et du niveau de séparation exigé.

20. Ne pas confondre modification des fichiers et apprentissage

Un fichier de poids peut changer sans qu’un nouvel apprentissage métier ait eu lieu.

Exemples :

• conversion de format ;
• changement de précision ;
• quantification ;
• fusion d’un adaptateur déjà entraîné ;
• réorganisation du stockage.

La quantification transforme une représentation numérique pour réduire certains coûts. Elle peut affecter les résultats, mais elle n’est pas, à elle seule, un apprentissage de procédures d’entreprise.

Inversement, un apprentissage peut produire uniquement un adaptateur sans modifier le fichier original du modèle de base.

Pour démontrer un entraînement, il faut documenter le processus, les données, les paramètres entraînables et les artefacts produits. Une différence entre fichiers ne suffit pas.

21. Hébergement, personnalisation et droits : trois dimensions indépendantes

Le lieu d’exécution ne détermine pas la méthode.

Un modèle peut être :

• adapté localement et exécuté localement ;
• adapté à distance et exécuté localement ;
• inchangé et utilisé dans une application locale ;
• personnalisé par consignes dans un service distant.

De même, l’adaptation ne supprime pas les licences du modèle initial.

L’expression « notre modèle » doit être précisée :

• modèle hébergé par l’entreprise ;
• modèle configuré pour son usage ;
• modèle adapté avec ses données ;
• modèle dont elle possède certains droits ;
• modèle entraîné depuis zéro.

Ces situations ne donnent pas les mêmes garanties techniques ou contractuelles.

22. Choisir à partir du défaut constaté

Un fine-tuning devient une piste sérieuse lorsque le problème porte effectivement sur un comportement du modèle, que les exemples sont disponibles et que le bénéfice peut être mesuré.

23. Protocole pratique : distinguer les mécanismes sans entraîner

Cet exercice utilise un modèle existant et des données fictives.

Essai A — Consigne sans procédure

Fournissez le rôle du service client, puis posez la question sur le délai.

Attendu : l’assistant doit signaler que la règle manque plutôt qu’inventer une valeur.

Essai B — Procédure dans le contexte

Ajoutez la règle des cinq jours et reposez la question.

Attendu : distinguer première réponse et résolution.

Essai C — Nouvelle session

Ouvrez une conversation réellement indépendante, sans document ni préférence réinjectée, puis reposez la question.

L’absence de la règle dans le contexte permet d’observer la dépendance à l’information fournie.

Si l’assistant répond encore correctement, cela ne prouve pas un entraînement : il faut vérifier l’historique réintroduit, la configuration, les sources et la possibilité d’une réponse fortuite.

Essai D — Modification de la règle

Fournissez une version fictive indiquant sept jours.

Attendu : utiliser la règle explicitement applicable, sans conserver arbitrairement cinq jours.

Essai E — Recherche documentaire

Retirez la règle de la consigne et placez-la dans la chaîne documentaire.

Vérifiez les passages réellement récupérés.

Le résultat montre alors le rôle de la recherche, pas une modification des poids.

24. Comment démontrer qu’un fine-tuning apporte quelque chose ?

Comparez deux versions :

• modèle initial ;
• même modèle de base avec adaptation.

Conservez autant que possible :

• le même moteur ;
• le même format de conversation ;
• les mêmes informations fournies ;
• les mêmes réglages ;
• les mêmes cas de test.

Utilisez des exemples absents de l’apprentissage.

Vérifiez :

• respect des distinctions métier ;
• prise en compte des exceptions ;
• absence d’invention ;
• format ;
• qualité sur les formulations nouvelles ;
• régressions ;
• temps et ressources.

Si la version adaptée reçoit les sources et que la version initiale ne les reçoit pas, vous ne mesurez pas seulement l’effet de l’apprentissage.

Un entraînement terminé est une réussite d’exécution. Une amélioration démontrée sur des cas indépendants est une réussite d’adaptation.

25. Exercices avec corrigés

Exercice 1 — Nom commercial

Une interface « Expert Atelier Démo » utilise un modèle existant avec une consigne enregistrée.

Question : a-t-on entraîné un nouveau modèle ?

Réponse : non, pas d’après ces éléments. Une configuration d’assistant a été créée.

Exercice 2 — Importation de PDF

L’application découpe cinquante procédures et calcule leurs embeddings.

Question : qu’est-ce qui a été produit ?

Réponse : des représentations et un index documentaire, pas nécessairement de nouveaux poids.

Exercice 3 — Mille exemples

Une équipe fournit mille couples entrée–réponse à un optimiseur qui ajuste un adaptateur.

Question : y a-t-il apprentissage ?

Réponse : oui. Des paramètres d’adaptation sont modifiés, même si les poids de base restent figés.

Exercice 4 — Tarif variable

Le tarif change chaque semaine et doit être donné avec sa date d’application.

Question : quelle première approche étudier ?

Réponse : une source actualisée consultée à la demande, structurée ou documentaire. La mémorisation dans les poids n’offre pas les garanties nécessaires à elle seule.

Exercice 5 — Ancien délai

Le RAG transmet une ancienne procédure et le modèle la restitue fidèlement.

Question : faut-il d’abord entraîner le modèle ?

Réponse : non. Il faut corriger la sélection documentaire et le versionnement.

Exercice 6 — Bonne source, mauvaise interprétation

Le bon passage est transmis, mais le modèle confond régulièrement première réponse et résolution.

Question : quelle démarche suivre ?

Réponse : améliorer et tester la consigne, les exemples et le modèle de référence ; envisager ensuite une adaptation sur des exemples variés si l’erreur persiste.

26. Fiche de décision à remettre

Exemple de conclusion

Le problème principal est l’accès à des procédures actualisées. Nous commencerons par une recherche documentaire avec gestion des versions et des permissions. Le modèle recevra les passages applicables à chaque demande. Une adaptation ne sera étudiée que si des erreurs d’interprétation persistent malgré la transmission des bonnes sources et une consigne évaluée.

27. Critères de validation de l’unité

Vous devez pouvoir expliquer, pour chaque approche :

• où les informations métier résident ;
• ce qui est modifié ;
• ce qui est chargé à l’utilisation ;
• ce qui persiste ;
• comment une règle est actualisée ;
• comment la méthode est évaluée ;
• quels contrôles doivent rester dans l’application.

La distinction centrale à maîtriser est la suivante :

Références techniques

• Brown et al. — Language Models are Few-Shot Learners
• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Hu et al. — LoRA: Low-Rank Adaptation of Large Language Models
• Gururangan et al. — Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks
• Hugging Face TRL — Fine-tuning supervisé
• Hugging Face Transformers — Fonctionnement du cache