Comment obtenir des résultats stables avec les modèles d’IA locaux

Les modèles locaux semblent imprévisibles quand le même prompt donne une forme différente à chaque fois : parfois des puces, parfois un essai, parfois des excuses plus l’essai. L’essentiel vient des réglages et de contraintes manquantes, pas d’une installation cassée. Vous pouvez rendre les résumés, l’extraction et les petites tâches de code assez répétables pour un usage quotidien.

Cette page suppose que vous écrivez déjà un prompt clair. Si la formulation est encore lâche, lisez d’abord Comment écrire de meilleurs prompts pour les modèles d’IA locaux. Les méthodes qui survivent aux essais sont résumées dans Ce qui fonctionne vraiment.

Pourquoi la réponse change

L’échantillonnage choisit le Token suivant avec un peu de hasard. Une température (temperature) plus haute signifie plus de hasard. Un long échange signifie que les règles antérieures sont plus loin de la dernière question. Un prompt ouvert (« écrivez quelque chose d’utile ») a beaucoup de suites valides, donc l’échantillonneur a de la place pour dériver. Vous réduisez la variation en réduisant cette place : température plus basse, un Seed quand vous avez besoin d’une vraie relance, un format avec peu de jeu, un contexte court, et un modèle à qui l’on ne demande pas cinq travaux.

1. Baissez la température avant de réécrire le prompt

Pour une tâche que vous voulez répéter, réglez la température entre 0.1 et 0.3. Laissez top-p au défaut de l’application, sauf si vous savez pourquoi vous le changez. Puis lancez le prompt identique trois fois.

Même prompt, trois intentions :

Listez exactement 4 règles de nommage de fichiers pour un dossier partagé. Une phrase chacune. Pas d’introduction.

Température 0.9 : vous pouvez obtenir 3, 5 ou 4 règles, plus une intro aimable sur certains essais. La formulation saute. Ne jugez pas encore le prompt.
Température 0.2 : vous devriez obtenir 4 règles la plupart des essais. La formulation change encore un peu. C’est normal.
Température 0 : le plus répétable, et parfois le plus fade. Utilisez-la pour l’extraction. Pour l’écriture, 0.2 suffit d’habitude.

La liste a l’air aléatoire, alors j’ai réécrit tout le prompt, ajouté un long personnage et laissé la température à 1.0.

Vous avez changé trop de choses, et vous avez laissé le réglage qui cause le mélange. Figez le prompt, baissez la température, et seulement ensuite modifiez une ligne si le format est encore faux.

2. Utilisez un Seed quand vous comparez des prompts

Ollama, LM Studio et certains autres programmes vous laissent fixer un Seed. Le même modèle, le même prompt, le même Seed et les mêmes réglages d’échantillonnage doivent revenir presque identiques. C’est ainsi que vous voyez si un changement de formulation a aidé.

Une comparaison pratique :

Réglez la température à 0.2 et le Seed à 42.
Enregistrez la sortie du prompt A.
Changez une ligne pour faire le prompt B. Gardez le Seed.
Comparez A et B. Si B est meilleur, gardez-le puis essayez une fois le Seed 43 pour voir si le format tient encore.

Si votre application n’a pas de réglage de Seed, vous ne pouvez pas obtenir des répétitions caractère pour caractère. Vous pouvez quand même exiger un format et une température basse, et c’est ce qu’il vous faut au quotidien. Un Seed sert aux essais, pas aux personnes qui lisent un résumé.

3. Rendez le format difficile à quitter

Plus la forme est serrée, moins l’échantillonneur peut faire. Des étiquettes valent mieux que « organisez ceci ».

Pouvez-vous organiser cet e-mail client en quelque chose que notre équipe peut utiliser ?

Réécrivez l’e-mail dans ces étiquettes seulement : Demande : Produit : Échéance : Manquant : Règles : - Une ligne par étiquette - Si inconnu, écrivez « non indiqué » - N’ajoutez pas de réponse recommandée E-mail : [coller]

Si le modèle ajoute encore une réponse recommandée, mettez l’interdiction sur sa propre dernière ligne : « N’écrivez pas de réponse. » Les règles de dernière ligne sont suivies plus souvent que les règles enfouies au milieu.

4. Ajoutez un contrôle d’une ligne pour les formats fragiles

Utilisez ceci pour le JSON, les tableaux et les comptes exacts. Ne l’utilisez pas pour la prose ordinaire.

Renvoyez un JSON avec les clés sku et qty. qty est un entier. Les valeurs manquantes sont null. Si une clé manque, corrigez le JSON avant de répondre. N’expliquez pas la correction. Texte : [coller]

Lisez la sortie. Si vous voyez un paragraphe qui commence par « J’ai vérifié le JSON », le modèle montre le contrôle. Ajoutez « Ne produisez que le JSON » ou retirez le contrôle et fiez-vous à la liste de clés. Certains petits modèles ne peuvent pas faire un contrôle silencieux. Dans ce cas, la liste de clés seule est le meilleur prompt.

Revérifiez soigneusement votre travail, envisagez les cas limites, et faites en sorte qu’un humain réfléchi serait fier de ce message d’anniversaire.

Il n’y a rien à vérifier. Vous obtiendrez un message guindé et parfois un paragraphe sur la qualité. Plafonnez plutôt les mots.

5. Gardez le contexte court

Des règles d’il y a dix messages sont faciles à laisser tomber pour un petit modèle. Pour un travail répétable, ne continuez pas à discuter. Ouvrez une nouvelle session, ou recollez les règles en haut du dernier message.

Un schéma qui reste stable :

Un message système ou premier message avec les règles.
Un message utilisateur avec le texte source.
Si vous avez besoin d’une révision, un nouvel échange qui contient les règles plus la sortie précédente, pas tout l’historique.

[après 15 tours de questions mêlées] Le même format qu’avant, vous voyez ce que je veux dire.

Souvent, il ne voit pas. Recollez le format. « Comme avant » n’est pas un format.

6. Faites correspondre la taille du modèle au travail

Un modèle plus petit avec un prompt étroit est souvent plus constant qu’un modèle général plus grand avec un prompt négligé, mais ce n’est pas de la magie. Utilisez un petit modèle pour réécrire, extraire et faire de courts résumés d’un texte que vous fournissez. Utilisez un modèle local plus grand quand la tâche demande du code plus long ou un raisonnement en plusieurs étapes. Ne demandez pas à un modèle 3B de relire un fichier de 400 lignes en attendant une relecture stable.

Si le format tient sur un modèle 7B et s’effondre sur un modèle 3B, gardez le prompt et changez de modèle. N’ajoutez pas des règles jusqu’à enterrer le petit modèle.

Une liste de contrôle répétable

Écrivez le format comme des étiquettes, un compte ou des clés JSON.
Placez le texte source après les règles, derrière une étiquette claire.
Réglez la température à 0.2 pour tout ce à quoi vous voulez faire confiance.
Fixez une limite maximale de Tokens un peu au-dessus de la réponse demandée.
Lancez deux fois. Si la forme diffère, resserrez la dernière ligne avant d’ajouter de nouvelles règles.
Si vous comparez deux formulations, fixez un Seed.
Si l’échange est long, recommencez et recollez les règles.

Ce que la constance n’est pas

Ce n’est pas des phrases identiques à chaque fois, sauf si la température est proche de 0 et que le prompt est très serré.
Cela ne fait pas citer au modèle de vraies sources qu’il ne peut pas voir. Collez la source.
Cela n’enlève pas le besoin de lire la sortie. Une mauvaise réponse stable reste mauvaise. Pour l’extraction, vérifiez deux champs contre le texte original.
Cela n’est pas amélioré en collant un énorme préambule « vous êtes un expert qui ne fait jamais d’erreurs ». Cette ligne ne change pas l’échantillonnage.

Quand le prompt est stable, enregistrez-le. La Bibliothèque de prompts est un ensemble de points de départ que vous pouvez ranger à côté des vôtres. Si vous n’êtes pas sûr qu’un prompt enregistré soit trop long pour la fenêtre de contexte, estimez-le avec le Compteur de Tokens avant d’attacher un gros fichier.