Fine-tuning local ou RAG pour données internes

Le choix entre génération augmentée par récupération, ou RAG (Retrieval-Augmented Generation), et fine-tuning local ne porte pas d’abord sur la carte graphique. Il porte sur l’endroit où résident durablement les connaissances, donc sur la révocation, la confidentialité, l’exploitation et le coût de l’erreur.

→ Lire l’explication complète de la marmotte

RAG et fine-tuning : deux emplacements pour la connaissance

Un RAG conserve le modèle de langage générique. À la réception d’une question, le système recherche des passages dans une base documentaire, puis les ajoute au contexte soumis au modèle. Les données métier restent donc dans un index et dans les documents sources. La page embeddings et RAG local couvre le mécanisme de recherche sémantique et le découpage documentaire.

Le fine-tuning modifie les paramètres du modèle à partir d’exemples d’entraînement. Après adaptation, le modèle a statistiquement absorbé des régularités du corpus : style rédactionnel, structure de réponse, vocabulaire métier, classification, extraction ou comportement conversationnel. Cette propriété est exactement son intérêt, et exactement son problème.

Le compromis central est brutal : le RAG apporte une connaissance révocable, traçable et fraîche, au prix d’une chaîne de recherche à opérer. Le fine-tuning peut stabiliser un comportement ou une compétence, mais transforme les données d’entraînement en dette de modèle. Une information supprimée du corpus ne disparaît pas automatiquement des poids. Il faut réentraîner, valider, remplacer l’adaptateur et invalider les artefacts dérivés.

La recommandation par défaut est donc nette : utiliser le RAG pour les faits internes, les procédures, les contrats, les référentiels, les tickets, les données clients et tout contenu soumis à rétention ou à suppression. Réserver le fine-tuning aux comportements qui restent valables lorsque les documents changent : format de sortie strict, classification sur taxonomie stable, extraction structurée, terminologie spécialisée ou ton rédactionnel.

Fine-tuner une base documentaire pour répondre à des questions sur sa dernière version est un mauvais échange. Cela remplace une recherche contrôlable par une mémoire probabiliste, avec l’enthousiasme habituel des slides qui promettent de « supprimer la complexité ». La complexité revient, mais elle revient dans les paramètres.

Cas où le fine-tuning local est justifié

Le fine-tuning devient défendable lorsque la difficulté n’est pas de retrouver une information, mais de produire systématiquement une transformation que le modèle générique exécute mal. Un corpus d’exemples entrée-sortie homogènes est alors requis. Par exemple : transformer un événement technique en objet JavaScript Object Notation (JSON) conforme à un schéma, classer des demandes selon une nomenclature interne stable, ou rédiger des comptes rendus dans un format imposé.

Un bon signal est l’échec répétable du modèle avec un prompt précis et des exemples fournis dans le contexte. Si le modèle comprend les documents retrouvés mais ne respecte pas le format, l’adaptation peut corriger le comportement. Si le modèle ne connaît simplement pas la réponse, le RAG reste le bon mécanisme.

Le jeu d’entraînement doit séparer trois ensembles étanches : apprentissage, validation et test final. Le test final ne sert ni à ajuster les hyperparamètres ni à choisir le meilleur point de contrôle. Sinon, la mesure devient un miroir flatteur, discipline très populaire parce qu’elle donne des courbes magnifiques jusqu’au premier vrai trafic.

La diversité compte davantage que le volume brut. Quelques milliers d’exemples quasi identiques apprennent une formule, pas une capacité. Pour une extraction structurée, varier les formulations, les cas incomplets, les ambiguïtés, les entrées adverses et les valeurs absentes. Pour une classification, inclure les frontières entre classes, car c’est là que le modèle inventera de la confiance avec l’aplomb d’un tableur devenu consultant.

Un fine-tuning ne garantit pas la vérité factuelle, le respect d’une autorisation, la citation des sources ni l’absence d’hallucination. Ces propriétés doivent venir du pipeline : contrôle d’accès avant recherche, filtrage par métadonnées, validation syntaxique, règles métier et journalisation. Pour une vue plus large des frontières de sécurité, consulter l’architecture cybersécurité.

Mémorisation et fuite des données d’entraînement

Un modèle adapté peut mémoriser des séquences rares ou répétées, particulièrement lorsque le corpus est petit, que les données sont dupliquées, que le nombre d’époques est excessif ou que le taux d’apprentissage est trop élevé. Les risques incluent la restitution verbatim d’un secret, une donnée personnelle, un identifiant, une clause contractuelle ou une instruction interne injectée dans les exemples.

Le risque n’est pas réduit à l’interface applicative. Une personne disposant du fichier de modèle ou de l’adaptateur peut exécuter des requêtes d’extraction hors des garde-fous prévus. Une politique d’accès au portail ne protège pas un fichier copié dans un registre, un partage de fichiers ou une sauvegarde trop large. Le modèle est un actif sensible, pas un binaire neutre.

Avant entraînement, supprimer les secrets actifs : mots de passe, jetons d’accès, clés privées, chaînes de connexion et secrets de sessions. Remplacer les identifiants directs par des valeurs synthétiques lorsque l’objectif porte sur la forme ou le comportement. Dédupliquer les enregistrements et exclure les documents présentant une obligation de suppression incompatible avec le cycle de vie du modèle.

Il faut aussi défendre le pipeline contre l’empoisonnement des données. Un document malveillant ajouté au corpus peut apprendre une sortie biaisée, une consigne cachée ou une association dangereuse. Les sources doivent être authentifiées, versionnées, soumises à revue et séparées selon leur niveau de confiance. Un répertoire partagé n’est pas une chaîne d’approvisionnement. C’est un buffet où tout le monde apporte parfois du poisson oublié.

Évaluer les fuites implique des tests d’extraction : requêtes ciblant les séquences rares, préfixes de documents, identifiants fictifs injectés volontairement et données proches des limites de décision. Ces tests doivent être exécutés sur chaque candidat avant diffusion. L’absence de fuite observée ne prouve pas l’absence de mémorisation, mais une absence de test prouve surtout l’absence de stratégie.

LoRA et QLoRA sur infrastructure locale

LoRA (Low-Rank Adaptation) gèle les poids du modèle de base et entraîne de petites matrices ajoutées à certaines couches. L’adaptateur obtenu est bien plus petit que le modèle complet, ce qui réduit la mémoire requise, le stockage des versions et le coût de restauration. Il ne rend pas le modèle inoffensif : les données peuvent être mémorisées dans les adaptateurs.

QLoRA (Quantized Low-Rank Adaptation) charge le modèle de base quantifié, généralement sur 4 bits, puis entraîne les adaptateurs en précision supérieure. Cette méthode réduit fortement la mémoire de la carte graphique, ou GPU (Graphics Processing Unit), mais complique le diagnostic : compatibilité des bibliothèques, performances variables selon le matériel et risques de dégradation sur certains usages. La quantification n’est pas une mesure de sécurité. Compresser une fuite ne la transforme pas en confidentialité.

Une plateforme locale minimale doit fournir un hôte dédié ou isolé, un stockage chiffré, une GPU compatible avec les bibliothèques d’entraînement, une version figée des pilotes et un registre interne pour les artefacts. Le modèle de base, les jeux de données, les scripts, les adaptateurs, les journaux et les résultats d’évaluation doivent être versionnés et associés à un hachage cryptographique.

Les accès aux données d’entraînement et aux adaptateurs doivent passer par des identités de service à privilège minimal. Les jetons temporaires sont préférables aux secrets statiques. Les sauvegardes doivent chiffrer les artefacts, tester la restauration et appliquer la même rétention que les données sources. Sauvegarder un adaptateur contenant potentiellement des données sensibles dans un coffre moins protégé que les documents originaux est une forme de recyclage créatif, pas une architecture.

La supervision doit mesurer l’usage mémoire, les erreurs d’entraînement, la dérive des métriques de validation, les téléchargements d’artefacts et les échecs de contrôle d’accès. Conserver également le manifeste d’entraînement : modèle de base, version des dépendances, hachage des données, paramètres, métriques et approbation. Sans ce manifeste, reproduire ou révoquer un modèle devient une séance de divination assistée par journal incomplet.

Exemple reproductible : entraîner un adaptateur LoRA

Cet exemple entraîne un adaptateur local sur un fichier JSON Lines, format où chaque ligne est un objet JSON. Le fichier train.jsonl ne doit contenir ni secret actif ni donnée soumise à effacement immédiat. La validation de schéma et la revue des données précèdent l’exécution, elles ne sont pas décoratives.

# Créer un environnement Python isolé et installer les versions testées.
python3 -m venv .venv
. .venv/bin/activate
pip install "transformers==4.46.3" "peft==0.13.2" "datasets==3.1.0" \
  "accelerate==1.0.1" "trl==0.12.1"

# Le fichier contient des paires instruction/réponse validées.
# L'exécution reste locale si le modèle de base est déjà présent dans ./modele-base.
accelerate launch train_lora.py \
  --model_name_or_path ./modele-base \
  --dataset_path ./train.jsonl \
  --output_dir ./adaptateur-lora \
  --lora_r 16 \
  --lora_alpha 32 \
  --learning_rate 2e-4 \
  --num_train_epochs 2 \
  --seed 42

# Sceller l'artefact produit dans le manifeste de livraison.
sha256sum ./adaptateur-lora/adapter_model.safetensors \
  > ./adaptateur-lora/SHA256SUMS

Le nombre d’époques doit rester faible au départ. Une baisse continue de la perte sur l’apprentissage accompagnée d’une hausse sur la validation signale le surapprentissage. Augmenter les époques dans ce cas ne « finit pas l’entraînement » : cela grave davantage les exemples dans le comportement du modèle.

Exploitation, révocation et stratégie hybride

La stratégie la plus robuste est souvent hybride : fine-tuning pour le comportement stable, RAG pour les connaissances variables. Le modèle adapté reçoit les passages récupérés et applique le format ou la nomenclature apprise. La révocation d’un document reste alors une opération sur l’index et les sources, non une opération de chirurgie sur les poids.

Chaque adaptateur doit disposer d’un propriétaire, d’une finalité documentée, d’une durée de rétention, d’un niveau de sensibilité et d’une procédure de retrait. Un retrait signifie désactiver son service, retirer les copies du registre et des sauvegardes selon la politique, puis remplacer l’adaptateur si les données concernées ont influencé les sorties. Effacer le fichier en production sans traiter les répliques et les sauvegardes ne révoque rien.

Le plan de reprise doit pouvoir restaurer un modèle de base approuvé, un adaptateur identifié par son hachage et une configuration d’inférence versionnée. Il ne doit jamais restaurer aveuglément le dernier artefact disponible. Le dernier artefact est souvent celui que personne n’a eu le temps de qualifier, tradition informatique dont la longévité force le respect.

🐝 Ce qui arrive si on s’en passe

Sans cette distinction, la connaissance interne finit gravée dans des poids que personne ne sait inventorier. Une demande d’effacement devient alors impossible à honorer de façon démontrable : il n’existe ni liste des documents ayant influencé un artefact, ni hachage permettant de relier une sortie suspecte à un jeu d’entraînement. En cas d’incident, le périmètre exposé n’est pas calculable, donc la notification et la reprise se font à l’aveugle. Un adaptateur diffusé sans propriétaire ni rétention survit dans les registres et les sauvegardes bien après le retrait de la source. L’interrogation répétée devient un canal d’extraction, mécanisme déjà illustré par la brèche « la question qui rend le module bavard » : chaque réponse renseigne un peu, et le cumul reconstitue ce qui était censé rester dans l’armoire.

🦫 Explication de la marmotte 🍫

Un modèle de langage produit du texte en calculant la suite la plus probable à partir de ce qu’il a appris. Pour répondre avec des documents internes, deux méthodes existent. La première cherche d’abord les passages liés à la question dans une collection de documents. Ces passages sont ajoutés à la question avant la réponse. Si un document est modifié ou supprimé, il suffit de mettre à jour la collection utilisée pour la recherche.

La seconde méthode entraîne à nouveau le modèle avec des exemples internes. Les réglages numériques du modèle sont alors modifiés. Il peut mieux respecter un format, reconnaître une catégorie ou employer un vocabulaire spécialisé. En revanche, une information présente dans les exemples peut rester partiellement mémorisée. La suppression du document d’origine ne suffit donc pas : il faut refaire l’entraînement sans cette information et remplacer la version utilisée.

L’entraînement demande des exemples propres, variés et vérifiés. S’ils sont trop peu nombreux ou trop répétitifs, le modèle apprend par cœur au lieu de généraliser. Des secrets, mots de passe ou données personnelles ne doivent pas entrer dans ces exemples. Des tests doivent chercher si le modèle restitue des phrases rares ou des informations interdites.

La meilleure organisation utilise généralement la recherche documentaire pour les faits changeants et l’entraînement pour les comportements stables. Les fichiers produits, les données utilisées et les résultats de test doivent être protégés, surveillés, sauvegardés et identifiables.

Pages voisines

La citent

AI Act : obligations du fournisseur d'un modèle d'IA à usage général (article 53, annexes XI et XII)

Fine-tuning local ou RAG pour données internes

Elle cite

: les deux pages se citent l’une l’autre.

Fine-tuning local ou RAG pour données internes

Fine-tuning local ou RAG pour données internes

RAG et fine-tuning : deux emplacements pour la connaissance

Cas où le fine-tuning local est justifié

Mémorisation et fuite des données d’entraînement

LoRA et QLoRA sur infrastructure locale

Exemple reproductible : entraîner un adaptateur LoRA

Exploitation, révocation et stratégie hybride

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines