Prompting

Lorsque vous commencez à utiliser les modèles Mistral, votre première interaction s'articulera autour des prompts. Maîtriser l'art de rédiger des prompts efficaces est essentiel pour générer des réponses de haute qualité à partir des modèles Mistral ou d'autres LLM.

Concepts principaux

Concepts principaux

L'art de rédiger des prompts

Ci-dessous, nous abordons les concepts fondamentaux du prompting et comment rédiger des prompts efficaces pour maximiser les capacités de nos modèles.

Prompt système

Prompt système

Lorsque vous fournissez des instructions, il existe deux niveaux d'entrée que vous pouvez donner au modèle : system et user.

  • Le prompt system est fourni au début de la conversation. Il définit le contexte général et les instructions pour le comportement du modèle et est généralement géré par le développeur.
  • Le prompt user est fourni pendant la conversation pour donner au modèle un contexte ou des instructions spécifiques pour l'interaction en cours.
Note

En tant que développeur, vous pouvez toujours utiliser les prompts user pour fournir un contexte ou des instructions supplémentaires pendant la conversation si nécessaire. Si vous ne pouvez pas contrôler le prompt system, vous pouvez toujours inclure le contexte général et les instructions dans le prompt user en les concaténant avec la requête réelle. Exemple avec séparation des rôles :

{
    "role": "system",
    "content": "system_prompt"
},
{
    "role": "user",
    "content": "user_prompt"
}

Exemple concaténé :

{
    "role": "user",
    "content": "system_prompt\n\nUser: user_prompt"
}

Définir un objectif

Définir un objectif

Également appelé roleplaying, c'est la première étape dans la rédaction d'un prompt et consiste à définir un objectif clair. Une approche courante consiste à commencer par une définition concise du rôle et de la tâche, telle que : "Vous êtes un <rôle>, votre tâche est de <tâche>." Cette technique simple mais puissante aide à orienter le modèle vers un domaine et une tâche spécifiques, en s'assurant qu'il comprend rapidement le contexte et le résultat attendu.

Structure

Structure

Lorsque vous donnez des instructions, organisez-les de manière hiérarchique ou avec une structure claire, par exemple en les divisant en sections et sous-sections claires. Le prompt doit être clair et complet. Une règle empirique utile est d'imaginer que vous écrivez pour quelqu'un sans contexte préalable — cette personne devrait pouvoir comprendre et exécuter la tâche uniquement en lisant le prompt. Exemple de prompt bien structuré :

Vous êtes un modèle de détection de langue, votre tâche est de détecter la langue du texte donné.
# Langues disponibles
Sélectionnez la langue dans la liste suivante :
- Anglais : "en"
- Français : "fr"
- Espagnol : "es"
- Allemand : "de"
Toute langue non répertoriée doit être classée comme "autre" avec le code "on".
# Format de réponse
Votre réponse doit suivre ce format :
{"language_iso": <language_code>}
# Exemples
Voici des exemples d'entrées et de sorties attendues :
## Anglais
Utilisateur : Hello, how are you?
Réponse : {"language_iso": "en"}
## Français
Utilisateur : Bonjour, comment allez-vous?
Réponse : {"language_iso": "fr"}

Formatage

Formatage

Le formatage est essentiel pour rédiger des prompts efficaces. Il vous permet de mettre en évidence explicitement différentes sections, rendant la structure intuitive pour le modèle et les développeurs. Le Markdown et/ou les balises de style XML sont idéaux car ils sont :

  • Lisibles : faciles à parcourir pour les humains.
  • Analysables : simples pour extraire des informations par programmation.
  • Familiers : probablement vus massivement pendant l'entraînement du modèle. Un bon formatage aide non seulement le modèle à comprendre le prompt, mais facilite également l'itération et la maintenance de l'application pour les développeurs.

Prompting par exemples

Prompting par exemples

Le prompting par exemples est une technique où vous fournissez quelques exemples de tâches pour améliorer la compréhension du modèle, la précision et surtout le format de sortie.

Few-shot prompting

Few-shot prompting

Un exemple spécifique de cette technique est le few-shot prompting, où des interactions artificielles entre l'utilisateur et le modèle sont incluses dans l'historique de la conversation. En revanche, le zero-shot prompting n'implique aucun exemple. Exemple direct dans un prompt :

[...]
# Exemples
Entrée : Hello, how are you?
Sortie : {"language_iso": "en"}
[...]

Structure standard du few-shot prompting :

[
    {
        "role": "system",
        "content": "Vous êtes un modèle de détection de langue. Votre tâche est de détecter la langue du texte donné.\n[...]"
    },
    {
        "role": "user",
        "content": "Hello, how are you?"
    },
    {
        "role": "assistant",
        "content": "{\"language_iso\": \"en\"}"
    },
    {
        "role": "user",
        "content": "Bonjour, comment allez-vous?"
    },
    {
        "role": "assistant",
        "content": "{\"language_iso\": \"fr\"}"
    }
]

Sorties structurées

Sorties structurées

Une fois votre prompt prêt, vous pouvez vous concentrer sur la sortie. Pour garantir que le modèle génère des réponses structurées et prévisibles, nous offrons la possibilité d'imposer un format de sortie JSON spécifique. Cela est particulièrement utile pour les tâches nécessitant une structure cohérente qui peut être facilement analysée et traitée par programmation. Si cette technique était utilisée dans l'exemple ci-dessus, elle garantirait que les réponses du modèle sont cohérentes en termes de formatage et permettrait également d'imposer les catégories à utiliser. Si vous êtes intéressé, pour plus de détails sur l'utilisation des sorties structurées, vous pouvez consulter la documentation Sorties structurées.

Conseils

Conseils

Lors de la création d'un prompt, il est important de rester flexible et d'expérimenter. Différents modèles de différents laboratoires, et même une simple mise à jour, peuvent changer le comportement du modèle et un prompt cohérent peut être impacté par ces changements. Par conséquent, n'hésitez pas à revisiter vos prompts et à observer l'impact. Comme vous itéreriez sur votre code et l'entraînement de votre modèle, vous devriez itérer sur vos prompts et évaluer l'impact de vos modifications.

Ce qu'il faut éviter

Ce qu'il faut éviter

Ce qu'il faut éviter

Nous listons ci-dessous des conseils « bons à savoir » sur ce qu'il vaut mieux ne pas faire. La liste n'est pas exhaustive et peut dépendre de votre cas d'usage — mais ces points sont à garder en tête lors de la rédaction de vos prompts.

Évitez les termes subjectifs et flous

Évitez les termes subjectifs et flous

  • Évitez les adjectifs quantitatifs flous : « trop long », « trop court », « beaucoup », « peu », etc.
    • Préférez des mesures objectives.
  • Évitez les termes flous comme « choses », « trucs », « rédigez un rapport intéressant », « rendez-le meilleur », etc.
    • Précisez ce que vous entendez exactement par « intéressant », « meilleur », etc.

Évitez les contradictions

Évitez les contradictions

À mesure que votre prompt système s'allonge, de légères contradictions peuvent apparaître.
Exemple :

  • « Si les nouvelles données sont liées à un enregistrement de base de données existant, mettez à jour cet enregistrement. »
  • « Si les données sont nouvelles, créez un nouvel enregistrement. »
  • Ceci est ambigu car de nouvelles données pourraient soit mettre à jour un enregistrement existant, soit en créer un nouveau.

Préférez un arbre de décision :

## Comment mettre à jour les enregistrements de base de données
Suivez ces étapes :
- Si les données n'incluent pas d'information nouvelle (c'est-à-dire qu'elles existent déjà dans un enregistrement) :
    - Ignorez ces données.
- Sinon, si les données ne sont liées à aucun enregistrement existant dans la même table :
    - Créez un nouvel enregistrement.
- Sinon, si l'enregistrement lié contient plus de 100 caractères :
    - Créez un nouvel enregistrement.
- Sinon, si les données contredisent directement l'enregistrement existant :
    - Supprimez l'enregistrement existant et créez-en un nouveau.
- Sinon :
    - Mettez à jour l'enregistrement existant pour inclure les nouvelles données.
Ne faites pas compter les mots aux LLM

Ne faites pas compter les mots aux LLM

  • À éviter : « Si l'enregistrement est trop long, divisez-le en plusieurs enregistrements. »
  • À éviter : « Si l'enregistrement contient plus de 100 caractères, divisez-le en plusieurs enregistrements. »
  • Préférez fournir le nombre de caractères en entrée :
    Enregistrements existants :
      - { record: "User: Alice, Age: 30", charCount: 15 }
      - { record: "User: Bob, Age: 25", charCount: 13 }
    Nouvelles données :
      - { data: "User: Charlie, Age: 35", charCount: 17 }

Ne générez pas trop de tokens

Ne générez pas trop de tokens

Les modèles ingèrent les tokens plus rapidement qu'ils ne les génèrent. Si vous utilisez des sorties structurées, ne demandez au modèle de générer que le strict nécessaire.
Mauvais exemples :

  • Générer le contenu complet d'un enregistrement pour une opération NO_OP.
  • Générer un livre entier d'un seul coup.

Ne générez que la mise à jour ou les données nécessaires.

Préférez les échelles verbalisées

Préférez les échelles verbalisées

Si vous avez besoin qu'un modèle note quelque chose, utilisez une échelle verbalisée pour de meilleures performances.
À éviter :

« Notez ces options sur une échelle de 1 à 5, 1 étant très peu pertinent et 5 étant très pertinent. »

Préférez :

Notez ces options avec cette échelle :
- Très faible : si l'option est très peu pertinente
- Faible : si l'option n'est pas assez bonne
- Neutre : si l'option n'est pas particulièrement intéressante
- Bonne : si l'option mérite d'être considérée
- Très bonne : pour les options très pertinentes

Vous pouvez ensuite convertir cette échelle verbalisée en échelle numérique si besoin.

Exemples de prompting

Exemples de prompting

Nous vous présentons ci-dessous des exemples de prompts illustrant quatre capacités de prompting différentes :

  • Classification
  • Résumé
  • Personnalisation
  • Évaluation
Open In Colab

Les modèles Mistral peuvent facilement catégoriser du texte en classes distinctes. Prenons l'exemple d'un chatbot de support client pour une banque : nous pouvons établir une série de catégories prédéfinies dans le prompt, puis demander aux modèles Mistral AI de catégoriser la question du client en conséquence.

Dans l'exemple suivant, face à la demande du client, les modèles Mistral AI la catégorisent correctement comme « country_support » :

Demande de l'utilisateur : « Je me renseigne sur la disponibilité de vos cartes dans l'UE, car je suis résident français et souhaite utiliser vos cartes. » Réponse de l'assistant : « country_support »

Prompt système

Prompt système

Le prompt de classification doit être soigneusement conçu pour garantir que le modèle catégorise correctement la demande du client. Pour la classification, deux stratégies principales existent :

  • Demander le label directement : le modèle répond alors par un seul mot ou une chaîne de caractères.
    • Efficace, rapide et économique, cette stratégie utilise le moins de tokens de sortie mais peut manquer de fiabilité et de flexibilité.
  • Demander une sortie JSON : le modèle répond alors par un objet JSON qui peut être facilement traité en aval.
    • Fiable, flexible et pratique, cette stratégie génère légèrement plus de tokens mais permet des cas d'usage plus complexes et davantage de flexibilité.

Ce prompt est conçu pour que le modèle réponde par un seul terme composé en très peu de tokens.

Vous êtes un agent du service client bancaire. Votre tâche consiste à évaluer l'intention du client et à catégoriser sa demande dans l'une des catégories prédéfinies.

# Catégories
Les principales catégories disponibles sont les suivantes :
- card_arrival : Demandes concernant la réception de la carte ou si elle est perdue.
- change_pin : Demandes concernant la modification du code PIN de la carte.
- exchange_rate : Demandes concernant le taux de change de la carte.
- country_support : Demandes concernant les pays pris en charge par la carte.
- cancel_transfer : Demandes concernant l'annulation d'un virement.
- charge_dispute : Demandes concernant la contestation d'un débit.

Si le texte ne correspond à aucune des catégories ci-dessus, classez-le comme :
- customer_service : Demandes concernant le service client en général qui ne correspondent à aucune des catégories précédentes.

# Format de réponse
Vous répondrez uniquement avec la catégorie parmi celles listées ci-dessus sans aucune explication ni note, sous la forme d'un seul terme composé autonome.

## Exemples
Voici quelques exemples de demandes clients et leurs catégories correspondantes. Vous recevrez une nouvelle demande client et vous répondrez avec la catégorie correspondante.

User: Comment savoir si je vais recevoir ma carte ou si elle est perdue ? Je suis inquiet concernant le processus de livraison et j'aimerais m'assurer que je recevrai ma carte comme prévu. Pourriez-vous s'il vous plaît fournir des informations sur le processus de suivi de ma carte, ou confirmer s'il existe des indicateurs permettant d'identifier si la carte a été perdue pendant la livraison ?
Answer: card_arrival
User: Je prévois un voyage international à Paris et j'aimerais me renseigner sur les taux de change actuels pour l'euro ainsi que sur les éventuels frais associés aux transactions à l'étranger.
Answer: exchange_rate
User: Quels sont les pays pris en charge ? Je vais voyager et vivre à l'étranger pendant une période prolongée, notamment en France et en Allemagne, et j'apprécierais toute information concernant la compatibilité et les fonctionnalités dans ces régions.
Answer: country_support
User: Pouvez-vous m'aider à démarrer mon ordinateur ? J'ai des difficultés à démarrer mon ordinateur et j'apprécierais votre expertise pour m'aider à résoudre ce problème.
Answer: customer_service