Le fine-tuning n'apprend pas de faits
Corriger une erreur factuelle par le fine-tuning est une erreur d'architecture. Le modèle n'apprendra pas la vérité, il apprendra à halluciner avec votre style.
Le réflexe « on va fine-tuner pour corriger ça »
Un client arrive avec un problème récurrent : les modèles génératifs continuent de recommander une gamme de produits abandonnée il y a deux ans. Face à cette hallucination persistante, la DSI a déjà budgété un sprint de fine-tuning pour « corriger le modèle ». L'intention est logique en apparence, mais l'exécution est techniquement vouée à l'échec.
C'est le malentendu fondateur de l'ingénierie LLM appliquée au métier : croire qu'on injecte ou qu'on efface une vérité factuelle en ajustant les poids d'un réseau de neurones. La modification des poids paramétriques ne fonctionne pas comme une base de données relationnelle où l'on viendrait écraser une ligne obsolète avec une requête SQL. Tenter d'effacer une donnée périmée par fine-tuning revient à essayer de changer le sens d'un mot en modifiant les règles grammaticales d'une langue.
Le modèle va ingérer vos nouveaux exemples d'entraînement et ajuster sa distribution probabiliste superficielle. Pourtant, la connaissance initiale restera enfouie dans ses couches profondes, prête à ressurgir au premier prompt ambigu. C'est l'essence même des deux mémoires, deux stratégies d'entité : on ne corrige pas la mémoire paramétrique avec des exemples isolés.
Le bénéfice : Éviter d'allouer un budget d'ingénierie massif sur un chantier d'entraînement qui ne résoudra jamais l'obsolescence de la donnée.
Ce que le fine-tuning apprend réellement
Le fine-tuning est un exercice d'alignement comportemental, pas d'acquisition encyclopédique. Quand vous exposez un modèle pré-entraîné à des milliers de paires de requêtes-réponses, vous lui enseignez une forme. Vous lui dictez un registre de langue, une structure de sortie stricte (comme un schéma JSON spécifique), ou une concision particulière.
Il apprend à répondre comme votre marque, pas à mémoriser le catalogue de votre marque. Si vous lui fournissez des exemples contenant uniquement les nouveaux produits, il apprendra la syntaxe de vos fiches techniques. Mais face à une question directe de l'utilisateur sur l'ancienne gamme, sa mémoire paramétrique initiale — celle forgée sur des pétaoctets de données web historiques — prendra le relais. Le fine-tuning encode le contenant, jamais le contenu factuel. C'est d'ailleurs la raison pour laquelle un juge LLM préfère sa propre prose : il est biaisé par la forme qu'on lui a apprise, indépendamment de la véracité du fond.
Le bénéfice : Concentrer l'effort de fine-tuning exclusivement sur l'homogénéisation des formats de sortie et le respect strict du ton de marque.
L'hallucination fluide : pire que l'hallucination brute
Que se passe-t-il quand on utilise le mauvais outil sur le bon problème ? L'erreur mute et devient invisible. Avant le fine-tuning, l'hallucination sur le produit abandonné était souvent brute, parfois syntaxiquement maladroite, et donc facilement détectable par une équipe d'assurance qualité lors des tests.
Après le fine-tuning, le modèle a parfaitement assimilé votre ton de voix institutionnel. Il va donc générer une hallucination fluide. Il décrira le produit abandonné avec une syntaxe impeccable, en reprenant vos éléments de langage actuels, et le présentera avec une assurance redoutable. Vous n'avez pas supprimé l'erreur, vous l'avez rendue crédible.
C'est le scénario catastrophe en production : une donnée fausse qui passe sous le radar des validateurs humains car elle « sonne juste ». Un modèle fine-tuné sur des faits est un menteur pathologique doté d'une excellente élocution.
Le bénéfice : Protéger la chaîne de validation (QA) en gardant les erreurs factuelles isolées de la couche stylistique, facilitant ainsi leur détection.
Le fait vit dans le retrieval et le owned
Dès qu'un problème métier se formule par « le modèle dit quelque chose de faux ou de périmé sur notre offre », la solution ne se trouve pas dans les poids du modèle. Elle se trouve dans le corpus de récupération (retrieval) et les actifs owned. C'est la logique fondamentale de l'approche GEO : scinder la mémoire paramétrique (lente, stylistique) et la mémoire de travail (sensible au contexte, fraîche).
Pour corriger un fait, il faut instrumenter le terrain. Cela implique de consolider une URL owned canonique qui porte la vérité à jour, car chaque entité a besoin d'un domicile. Il faut ensuite injecter des signaux de fraîcheur clairs (dates de mise à jour strictes, balisage schema.org rigoureux), et ancrer l'entité dans le graphe de connaissances. Le moteur génératif doit être forcé d'aller lire la réalité présente dans votre corpus plutôt que de deviner à partir de son entraînement passé.
Le bénéfice : Maîtriser le cycle de vie de l'information en temps réel sans devoir réentraîner ou redéployer un modèle à chaque mise à jour catalogue.
Arbre de décision : fine-tune, RAG ou contenu ?
Notre position contractuelle est stricte : nous ne facturons jamais de prestation de fine-tuning tant que la voie du retrieval n'a pas été épuisée. Pour rationaliser les budgets d'ingénierie, nous appliquons une grille de tri binaire dès le préflight GEO à zéro euro.
- Problème de style, de ton ou de formatage strict de la réponse (JSON, XML) → Fine-tuning du modèle.
- Problème de fait, de catalogue obsolète ou de tarif erroné (comme quand l'IA cite votre prix d'il y a trois mois) → Optimisation du retrieval et mise à jour du corpus owned.
- Problème de confusion entre deux marques ou concepts → Ancrage d'entité (grounding) et désambiguïsation sémantique sur la page.
Séparer ces trois couches garantit une architecture résiliente. Le modèle gère la langue, le système de retrieval gère la vérité contextuelle, et votre site web reste la source canonique de cette vérité.
Le bénéfice : Déployer le bon budget sur le bon levier technique, en garantissant un ROI mesurable sur la justesse des réponses générées.