Vous voulez spécialiser un modèle sur le vocabulaire de votre métier — jargon d’une mutuelle lilloise, procédures d’une mairie d’Amiens, style de tickets d’une ESN de Valenciennes — et vous vous demandez s’il faut entraîner ou simplement brancher un RAG. Ce tutoriel expert parcourt le fine-tuning LoRA d’un petit modèle (ordre 8B, famille Qwen3) avec Unsloth : préparation des données, entraînement, évaluation qualitative, export vers un format servable (souvent GGUF) et mise à disposition via Ollama. On insiste sur les risques — surapprentissage, coût compute, droits sur les données — et sur les cas où un RAG ([[ti04|AnythingLLM]] ou Open WebUI) reste préférable. IAHDF est indépendant ; aucune librairie ne paie ce contenu. Les tags et APIs évoluent : copiez toujours les identifiants exacts depuis la documentation officielle du jour.
RAG ou fine-tuning ? La vraie première question
Le fine-tuning change le comportement du modèle (style, format de réponse, lexique fréquent, tâches répétitives). Le RAG fournit des faits à jour à partir de documents sans réentraîner. Pour un règlement qui change chaque trimestre, un catalogue produit, ou des délibérations : commencez par le RAG (AnythingLLM, Open WebUI, etc.). Pour imposer un format de ticket strict, un ton institutionnel stable, ou une tâche de classification répétée : le LoRA peut aider.
Les deux se combinent parfois (modèle un peu spécialisé + documents). Mais entraîner « parce que c’est fun » sur des données RH ou clients est le plus court chemin vers un incident. Si votre besoin est surtout « répondre à partir de PDF », arrêtez-vous au RAG et gardez ce tutoriel pour plus tard.
- LoRA
- Low-Rank Adaptation : on entraîne de petites matrices branchées sur un modèle de base figé (ou partiellement figé), au lieu de retoucher tous les poids.
- QLoRA
- Variante qui quantifie le modèle de base pour réduire la VRAM pendant l’entraînement. Ordres de grandeur matériel à vérifier chez vous / sur la fiche Unsloth du jour.
- Unsloth
- Bibliothèque et recettes pour accélérer / simplifier le fine-tuning de LLM open source. Suivez le dépôt et la doc officiels : les notebooks changent.
- Adaptateur
- Fichier(s) LoRA produits par l’entraînement, à fusionner ou à charger avec le modèle de base pour l’inférence.
Risques à écrire noir sur blanc
Surapprentissage : le modèle récite vos exemples et généralise mal, ou régurgite des phrases confidentielles du train set. Coût compute : GPU local saturé pendant des heures, ou facture cloud qui grimpe si vous itérez sans discipline. Droits : entraîner sur des mails clients, des dossiers médicaux, du code propriétaire tiers sans base légale ou contractuelle vous expose. Licence du modèle de base : vérifiez ce que la licence Qwen (ou autre) autorise pour usage commercial et redistribution de dérivés.
Il n’y a pas de « score IAHDF » qui garantit la qualité. Une baisse de perplexité sur le train set ne prouve pas que le modèle est utile en production. Préférez une grille métier (exactitude de format, absence de fuite, ton) sur un jeu de test jamais vu à l’entraînement.
Matériel : ordres de grandeur, pas mesures de labo
Pour un fine-tuning LoRA / QLoRA sur un dense ~8B, une carte avec de l’ordre de 16 à 24 Go de VRAM est souvent citée dans la documentation communautaire et les recettes Unsloth comme zone de travail réaliste — à vérifier sur la fiche et sur votre machine. Un GPU cloud de capacité équivalente peut remplacer un poste local. Avec moins de mémoire, regardez les options de quantification d’entraînement documentées le jour J, ou un modèle plus petit. Prévoyez aussi de l’espace disque pour checkpoints intermédiaires.
Ces ordres de grandeur ne sont pas des résultats de banc d’essai IAHDF. Fermez les autres charges GPU. Sur un serveur partagé à Lille, coordonnez les créneaux : un entraînement mal borné bloque les collègues (voir aussi vLLM pour la phase service, distincte de l’entraînement).
Prérequis : Python, GPU, culture data
Vous devez savoir créer un environnement virtuel Python, installer des paquets CUDA-compatible selon votre stack, lire un notebook ou un script d’entraînement, et versionner des fichiers. Installez les drivers GPU et vérifiez que PyTorch (ou la stack indiquée par Unsloth le jour J) voit la carte. Sans Python ni GPU utilisable, ce tutoriel reste utile pour décider de ne pas fine-tuner tout de suite.
Côté culture produit : sachez écrire une spécification de tâche (entrée → sortie attendue), constituer un jeu de test, et refuser un modèle qui « a l’air fluide » mais rate les cas limites. Les bases Ollama sont dans premiers pas Ollama ; la suite export s’appuiera dessus.
Pas à pas : du dataset à Ollama
Trancher RAG vs fine-tuning et cadrer la tâche
Rédigez en une page : la tâche exacte (ex. reformater un signalement citoyen au format interne), ce qui doit rester dans les documents (faits changeants → RAG), le succès mesurable qualitativement (grille de 30 exemples tenus secrets), et ce qui est interdit d’apprendre (données personnelles). Si la page conclut « les faits viennent de PDF mis à jour », arrêtez-vous et déployez un RAG. Sinon, poursuivez avec un objectif de comportement, pas d’« intelligence générale ». Faites valider ce cadrage par un responsable métier à Amiens ou Lille avant de brûler du GPU.
Constituer et nettoyer le jeu de données
Collectez des paires instruction / réponse (ou le format chat exigé par la recette Unsloth / Qwen du jour). Dédupliquez, retirez les secrets, anonymisez noms et numéros, uniformisez le format. Séparez explicitement train / validation / test (le test ne sert jamais à choisir les hyperparamètres à la volée). Pour une collectivité HdF, partez de textes déjà publics ou de cas fictifs validés juridiquement. Qualité avant quantité : cent exemples excellents battent souvent des milliers de lignes bruitées. Documentez la provenance de chaque source dans un manifeste.
Préparer l’environnement Unsloth
Créez un environnement Python dédié. Suivez la documentation officielle Unsloth du jour pour l’installation (commande exacte, version CUDA, contraintes PyTorch). Ne mélangez pas cet env avec votre stack web. Vérifiez la détection GPU par un petit tenseur test. Clonez ou copiez la recette / notebook recommandé pour un modèle 8B type Qwen3 — les noms de paquets et d’API bougent. Épingez les versions dans un requirements gelé pour pouvoir reproduire dans six mois. Sur cloud, choisissez une image dont vous contrôlez la région et la durée de vie des disques.
Charger le modèle de base et configurer le LoRA
Dans le script, chargez le modèle de base en copiant l’identifiant exact depuis la documentation Hugging Face / Unsloth du jour (famille Qwen3 8B ou équivalent retenu). Configurez les rangs LoRA, les modules cibles et, si vous utilisez QLoRA, le mode de quantification d’entraînement selon la recette. Gardez des valeurs proches des defaults documentés pour le premier run : l’hyperparamétrage agressif sans protocole produit surtout du bruit. Fixez une graine si la recette le permet, pour comparer deux runs. Journalisez chaque essai (date, commit data, config).
Lancer l’entraînement et surveiller le surapprentissage
Démarrez l’entraînement sur le split train, avec évaluation périodique sur validation. Surveillez la perte : si la validation se dégrade tandis que le train s’effondre, vous surapprenez — arrêtez, réduisez les epochs, augmentez le dropout LoRA si documenté, ou enrichissez / diversifiez les données. Ne cherchez pas un « score magique » ni un pourcentage inventé à coller dans un slide. Interrompez si la machine thermique s’emballe ou si le job cloud dépasse votre budget prévu. Sauvegardez des checkpoints intermédiaires pour pouvoir revenir en arrière sans tout recommencer. Notez durée approximative et incidents (OOM, redémarrage) dans le journal de run, côté équipe technique à Lille ou ailleurs.
Évaluer sur le jeu de test (grille métier)
Chargez l’adaptateur (ou le modèle fusionné) et passez vos 30 cas de test jamais vus. Pour chaque cas : format OK/KO, fuite de donnée OK/KO, exactitude métier OK/KO, ton OK/KO. Comparez au modèle de base sans LoRA sur les mêmes prompts. Si le LoRA gagne sur le style mais invente des faits absents du prompt, couplez-le à un RAG plutôt que d’ajouter encore des epochs. Invitez une personne métier (pas seulement le data scientist) à lire les sorties à froid. Archivez la grille datée.
Exporter (fusion / GGUF) et préparer Ollama
Suivez la doc Unsloth / outil de conversion du jour pour exporter l’adaptateur et, si besoin, fusionner puis convertir vers un format servable type GGUF. Les commandes et flags changent : ne les inventez pas. Vérifiez la licence avant toute redistribution. Créez un Modelfile Ollama qui pointe vers le fichier produit et déclarer un system prompt aligné avec la tâche. Tirez / créez le modèle localement, puis testez `ollama run` sur trois prompts du jeu de test. Documentez le hash du fichier et la version du script d’export.
Mettre en service avec prudence
Servez d’abord en local ou sur un réseau interne restreint. N’exposez pas l’endpoint sans authentification ni reverse proxy. Surveillez les prompts utilisateurs : le modèle fine-tuné peut rester vulnérable aux injections et aux demandes hors cadrage, malgré le LoRA. Prévoyez un rollback immédiat vers le modèle de base si la grille métier régresse. Si la charge monte (plusieurs utilisateurs simultanés), un runtime type vLLM peut devenir plus adapté qu’Ollama poste par poste. Planifiez la rétention : date à laquelle supprimer datasets, anciens checkpoints et logs d’entraînement contenant éventuellement des extraits sensibles.
Données : le vrai goulot
Un LoRA apprend ce que vous lui montrez. Des tickets mal annotés produisent un assistant qui reproduit les mauvaises habitudes. Des mails internes non anonymisés produisent un modèle qui peut recracher des noms. Travaillez par lots : dix exemples parfaits, revue humaine, puis élargissement. Pour le français administratif des Hauts-de-France, attention aux acronymes locaux et aux références de dispositifs : soit ils sont stables et utiles à graver dans le modèle, soit ils changent et appartiennent au RAG.
Stockez le dataset hors du dépôt git public. Chiffrez les sauvegardes. Limitez les accès. Indiquez dans le manifeste si des données synthétiques ont été générées (et comment), pour ne pas croire à tort qu’elles reflètent le terrain.
Entraînement avec Unsloth : le geste
Unsloth fournit des recettes pour charger un modèle, poser des adaptateurs LoRA, entraîner vite sur GPU grand public ou cloud. Votre job : coller à la recette du jour pour la famille Qwen3 8B (ou le tag exact retenu), brancher vos fichiers, et résister à l’envie de tout modifier d’un coup. Changez un levier à la fois (epochs, learning rate dans les plages documentées, rang LoRA) et gardez la grille de test identique.
# 1. Environnement (exemples de forme — suivez la doc officielle Unsloth du jour) python -m venv .venv-unsloth # Windows: .venv-unsloth\Scripts\activate # Linux/Mac: source .venv-unsloth/bin/activate # pip install ... # commandes EXACTES depuis la doc Unsloth du jour # 2. Données # train.jsonl / valid.jsonl / test.jsonl # Format chat ou instruction : celui exigé par la recette Qwen3 du jour # 3. Script d’entraînement (notebook / train.py de la recette) # - model_id = "IDENTIFIANT_EXACT_DEPUIS_LA_DOC" # - lora_r, lora_alpha, target_modules = valeurs documentées au 1er run # - output_dir = ./outputs/run-YYYYMMDD # 4. Export / conversion (flags exacts = doc du jour) # python export_ou_convert.py --adapter ./outputs/run-... --out ./export/ # 5. Ollama (Modelfile minimal — chemins à adapter) # FROM ./export/modele-ou-gguf # SYSTEM "Tu suis le format métier défini dans le cahier des charges interne." # ollama create mon-metier-lora -f Modelfile # ollama run mon-metier-lora
Si l’installation CUDA échoue, ne « bricolez » pas trois stacks mélangées : reprenez une image cloud ou une machine propre. Beaucoup d’échecs régionaux viennent d’un PyTorch CPU installé par erreur à côté de drivers GPU.
Évaluation : grille métier, pas folklore
Publier un pourcentage inventé ne sert personne. Ce qui sert : une grille stable, un jeu de test figé, une comparaison avant/après LoRA, et un avis métier. Ajoutez des tests de régression négatifs (le modèle ne doit pas inventer un numéro de sécurité sociale, ne doit pas affirmer un article de loi absent du prompt).
Quand le LoRA dégrade les capacités générales (raisonnement large, langues) pour un gain mince sur la tâche, réduisez la spécialisation ou préférez des prompts système + RAG. Le fine-tuning n’est pas un badge de maturité : c’est un outil coûteux.
Export GGUF / adaptateur et Ollama
Selon la recette, vous exporterez un adaptateur seul (à charger avec le base) ou un modèle fusionné, éventuellement converti en GGUF pour llama.cpp / Ollama. Vérifiez la chaîne d’outils documentée le jour J (Unsloth, llama.cpp convert, etc.). Testez l’inférence locale avant de parler de « production ». Pour un service multi-utilisateurs durable, planifiez plutôt un runtime serveur (vLLM) ; Ollama reste excellent pour poste et petite équipe.
Nommez clairement vos tags internes (`metier-v1`, `metier-v2`) et archivez la grille d’évaluation avec chaque version. Sans ça, personne ne saura pourquoi la v2 « semblait mieux » à Arras en septembre.
Quand revenir au RAG
Revenez au RAG si les faits changent souvent, si vous n’avez pas les droits d’entraîner, si vous n’avez pas le budget GPU pour itérer, ou si le LoRA mémorise trop. Un bon AnythingLLM ou équivalent, avec corpus propre et protocole de questions, résout la majorité des besoins « assistant sur nos documents » sans checkpoint sensible. Le fine-tuning reste pour le comportement et le format, pas pour la vérité documentaire du trimestre.
| Signal | Orientation |
|---|---|
| Faits dans des PDF mis à jour | RAG d’abord |
| Format / ton / tâche répétitive stable | LoRA candidate |
| Données personnelles dans le train set | Stop : minimiser ou abandonner |
| Validation qui diverge du train | Stop : surapprentissage |
| Besoin de 50 users simultanés | Runtime serveur (ex. vLLM), pas seulement Ollama laptop |
Limites franches
Unsloth et les recettes 8B ne font pas de vous un labo de fondation model. Vous n’obtiendrez pas un « GPT maison » avec un soir de GPU. Les licences, la qualité des données et la discipline d’évaluation décident plus que le choix de la lib. IAHDF ne fournit pas de dataset métier ni de VRAM garantie.
Questions fréquentes
Comment spécialiser un modèle sur mon métier ?
D’abord par le cadrage tâche + données dont vous avez les droits, souvent via un RAG pour les faits. Ensuite seulement, si le comportement doit changer durablement, par un LoRA évalué sur une grille métier. Sans jeu de test séparé, vous n’avez pas de spécialisation fiable — seulement une démo.
Qwen3 8B est-il obligatoire ?
Non. C’est un ordre de taille pédagogique souvent maniable pour expérimenter. Choisissez la famille et l’identifiant exact documentés le jour J, compatibles Unsloth et votre licence. Un modèle plus petit peut suffire ; un plus grand coûte plus cher à entraîner et à servir.
LoRA ou QLoRA ?
QLoRA vise à réduire la mémoire pendant l’entraînement en quantifiant le base. Le choix dépend de votre VRAM et de la recette Unsloth du jour. Ce n’est pas un label de qualité supérieure : c’est un compromis ingénierie. Vérifiez les options dans la doc, puis comparez deux runs sur la même grille de test.
Puis-je entraîner sur les mails de l’équipe ?
Seulement avec un cadre clair (information des personnes, base légale, minimisation, durée, accès). Sinon, non. Préférez des exemples anonymisés ou synthétiques validés. Un adaptateur peut mémoriser des fragments : traitez-le comme une donnée sensible.
Ollama suffit-il après le fine-tuning ?
Pour un poste ou une petite équipe interne, souvent oui. Pour une API multi-utilisateurs avec charge concurrente, regardez un serveur d’inférence type vLLM et un hébergement adapté (serveur GPU France). L’entraînement et le service sont deux sujets distincts.