Intermédiaire · Série IA pratique · Documentation consultée le 14 septembre 2026. Les commandes sont des exemples à adapter à ta version et à ton matériel ; aucun benchmark matériel n’est revendiqué.
Choisir entre configuration, documents, changement de modèle et entraînement, puis mesurer les progrès avant de remplacer son assistant.
Ton modèle répond mal : faut-il en télécharger un plus gros, ajouter tes documents ou l’entraîner ? Commence par classer ses erreurs. Un format incorrect, une information absente et une difficulté de raisonnement n’appellent pas forcément la même solution. Ce tuto propose une méthode de progression et un assistant versionné avec Ollama.
Choisir le bon levier
- La sortie est mal présentée : précise le format et ajoute un exemple.
- Il manque une documentation récente : apporte des sources, éventuellement via un RAG.
- La tâche dépasse régulièrement ses capacités : compare un autre modèle sur les mêmes questions.
- Le comportement doit être spécialisé sur de nombreux exemples : étudie un fine-tuning après avoir constitué et évalué les données.
Changer les instructions ne modifie pas les poids. Un entraînement LoRA ajuste des paramètres supplémentaires en gardant l’essentiel du modèle de base figé ; il vise à réduire le coût d’adaptation. Le guide PEFT de Hugging Face présente ce mécanisme. Ce n’est pas un bouton qui transforme automatiquement un dossier de PDF en expert fiable.
Créer une première configuration versionnée
Après avoir installé Ollama et téléchargé llama3.2:3b, enregistre ce texte dans Modelfile :
FROM llama3.2:3b
PARAMETER temperature 0.2
PARAMETER num_ctx 4096
SYSTEM """Tu aides à comprendre des sujets techniques en français.
Distingue les faits fournis et les hypothèses.
Donne les prérequis avant une commande.
Si une version ou une information manque, signale-le.
N’affirme jamais avoir exécuté un test que tu n’as pas exécuté."""ollama create assistant-tech-v1 -f Modelfile
ollama run assistant-tech-v1Le format Modelfile permet de définir une base, des paramètres et un message système. Ici, la température basse cherche à limiter la variation ; elle ne garantit pas la vérité. Le contexte choisi est une base d’essai à adapter aux capacités de la machine.
Mesurer les erreurs qui comptent
Prépare dix questions que tu sais corriger : cinq cas fréquents, trois cas difficiles et deux où une information essentielle manque. Pour chacune, écris les faits attendus et les erreurs éliminatoires. Par exemple, une commande qui efface des données sans le signaler doit compter comme un échec même si le texte est agréable.
cas,version,exactitude_sur_2,format_sur_1,incertitude_sur_1,commentaire
sauvegarde,v1,,,,
version_manquante,v1,,,,
document_contradictoire,v1,,,,Ce tableau est un gabarit vide, pas un résultat de benchmark. Compare v1 et v2 sur les mêmes cas, dans des conversations neuves, en notant le modèle exact et les paramètres. Répète les essais qui varient. Garde un petit lot de questions à l’écart pendant les réglages, sinon tu risques d’optimiser seulement les exemples connus.
Quand envisager LoRA ?
Seulement quand tu disposes d’exemples de qualité, de droits d’utilisation clairs et d’un besoin stable. Sépare entraînement, validation et test ; retire les doublons entre lots. Évalue aussi la confidentialité, les régressions et la compatibilité de l’adaptateur avec la base exacte. L’entraînement lui-même demande un atelier dédié et des ressources adaptées.
Avant de remplacer v1, conserve son modèle, sa configuration et les sources utilisées. Une amélioration sur le style peut masquer une régression factuelle. Mets en service v2 seulement si elle réussit mieux les tâches pour lesquelles tu utilises réellement ton assistant.