Guide de prompts de Mistral : cinq erreurs à éviter et ce qu'il faut écrire à la place

Mistral AI publie dans sa documentation un guide de rédaction de prompts. Il est court et ne cite aucun modèle en particulier : il parle des modèles Mistral en général. Sa partie la plus directement applicable est une liste d'erreurs à éviter.

Les bases : deux prompts, un rôle, une structure

Le guide distingue deux niveaux d'instructions :

• le prompt système, placé au début de la conversation, qui fixe le cadre général et le comportement attendu. Il est en principe géré par le développeur ;
• le prompt utilisateur, envoyé en cours de conversation, qui apporte le contexte ou la demande du moment.

Quand on n'a pas la main sur le prompt système, la consigne est de placer les instructions générales devant la question de l'utilisateur, dans le même message.

Viennent ensuite quatre recommandations de forme :

• ouvrir par une phrase courte qui donne le rôle et la tâche, sur le modèle « Vous êtes un…, votre tâche est de… » ;
• organiser les instructions de façon hiérarchique, en sections et sous-sections, et les écrire comme pour une personne qui ne connaît rien au contexte ;
• délimiter les parties avec du Markdown ou des balises de type XML, lisibles pour un humain et faciles à traiter par un programme ;
• fournir quelques exemples. Le guide appelle « few-shot » le fait d'insérer dans l'historique de faux échanges entre l'utilisateur et le modèle, par opposition au « zero-shot », sans exemple.

Cinq erreurs à éviter

1. Les mots flous. « Trop long », « quelques », « intéressant », « améliorez ce texte » : ces formules n'ont pas de sens mesurable. Le guide demande de les remplacer par des critères objectifs.

2. Les contradictions. Elles apparaissent quand un prompt système s'allonge au fil des ajouts. La solution proposée est un arbre de décision : si tel cas, faire ceci ; sinon, si tel autre cas, faire cela. L'exemple porte sur la mise à jour d'une fiche dans une base de données.

3. Faire compter le modèle. Le guide déconseille de demander à un modèle de compter des mots ou des caractères. Si une longueur intervient dans la tâche, il faut la calculer soi-même et la fournir comme donnée d'entrée.

4. Faire trop écrire. Le guide rappelle qu'un modèle lit les jetons plus vite qu'il ne les génère. Mieux vaut demander uniquement la partie utile, par exemple la modification à apporter plutôt que l'enregistrement complet réécrit.

5. Les notes chiffrées. Pour une évaluation, le guide préfère une échelle en mots, de « très faible » à « très bon » en cinq niveaux, quitte à la convertir en chiffres ensuite.

Les limites du guide

Le document reste général. Il ne donne aucune mesure de l'effet de ces consignes et ne précise pas si certaines comptent davantage selon le modèle. La page n'est pas datée.

Mistral le reconnaît d'ailleurs : des modèles de laboratoires différents, et même une simple mise à jour, peuvent changer le comportement obtenu. Sa recommandation finale est de traiter un prompt comme du code, c'est-à-dire de mesurer l'effet de chaque modification.

Notre lecture

Un exercice simple consiste à reprendre le prompt système d'un assistant interne et à y chercher trois choses : les adjectifs sans critère, les règles qui se contredisent, les demandes de longueur exprimées en nombre de mots.

Le conseil sur l'échelle en mots intéresse ceux qui font noter des réponses, des candidatures ou des tickets par un modèle. Celui sur le volume généré a un effet direct sur le délai de réponse, et sur la facture quand la génération est facturée au jeton.

Reste à garder un petit jeu d'exemples de référence, à repasser à chaque changement de modèle.