Présentation des stratégies de requête

Bien qu'il n'existe pas de méthode correcte ou incorrecte pour concevoir un prompt, il existe des stratégies courantes que vous pouvez utiliser pour affecter les réponses du modèle. Des tests et une évaluation rigoureux restent essentiels pour optimiser les performances du modèle.

Les grands modèles de langage (LLM) sont entraînés sur de grandes quantités de données textuelles pour apprendre les schémas et les relations entre les unités de langage. Lorsqu'ils reçoivent un texte (la requête), les modèles de langage peuvent prédire ce qui est le plus susceptible de suivre, à la manière d'un outil de saisie semi-automatique très sophistiqué. Par conséquent, lorsque vous concevez des requêtes, prenez en compte les différents facteurs susceptibles d'influencer les prédictions du modèle.

Workflow de prompt engineering

Le prompt engineering est un processus itératif basé sur les tests qui peut améliorer les performances du modèle. Lorsque vous créez des requêtes, il est important de définir clairement les objectifs et les résultats attendus pour chaque requête, puis de les tester systématiquement afin d'identifier les domaines à améliorer.

Le schéma suivant illustre le workflow de prompt engineering :

Schéma du workflow de prompt engineering

Créer une requête efficace

À terme, deux aspects d'une requête affectent son efficacité : le contenu et la structure.

  • Content:

    Pour effectuer une tâche, le modèle a besoin de toutes les informations pertinentes associées à la tâche. Il peut s'agir d'instructions, d'exemples ou d'informations contextuelles, entre autres. Pour en savoir plus, consultez la section Composants d'une requête.

  • Structure :

    Même lorsque toutes les informations requises sont fournies dans la requête, la structure des informations aide le modèle à les analyser. Une structuration telle que le tri, l'étiquetage ou l'utilisation de délimiteurs peut avoir un impact sur la qualité des réponses. Pour obtenir un exemple de structure de requête, consultez la section Exemple de modèle de requête.

Composants d'une requête

Le tableau suivant présente les composants essentiels et facultatifs d'une requête :

Composant Description Exemple
Objectif Ce que vous voulez obtenir du modèle. Soyez précis et incluez tous les objectifs généraux. Également appelé « mission » ou « objectif ». Votre objectif est d'aider les élèves à résoudre des problèmes de mathématiques sans leur donner directement la réponse.
Instructions Instructions qui expliquent en détail comment effectuer la tâche. Également appelés "tâche", "étapes" ou "directives".
  1. Comprendre ce que demande le problème.
  2. Comprendre où l'élève est bloqué.
  3. Donner un indice pour l'étape suivante du problème.
Composants facultatifs
Instructions système

Directives techniques ou environnementales qui peuvent impliquer un contrôle ou une modification du comportement du modèle pour un ensemble de tâches. Pour de nombreuses API de modèles, les instructions système sont spécifiées dans un paramètre dédié.

Les instructions système sont disponibles dans les modèles Gemini 2.0 Flash et versions ultérieures.

 Vous êtes un expert en codage spécialisé dans le rendu de code pour les interfaces frontend. Lorsque je décris un composant d'un site Web que je souhaite créer, veuillez renvoyer le code HTML et CSS nécessaire. Ne fournissez pas d'explications sur ce code. Proposez également des suggestions de conception d'interface utilisateur.
Persona En tant que qui ou quoi le modèle agit. Également appelé "rôle" ou "vision". Vous êtes professeur de mathématiques et vous aidez les élèves à faire leurs devoirs.
Contraintes Restrictions sur ce que le modèle doit respecter quand il génère une réponse, y compris ce que le modèle peut et ne peut pas faire. Également appelées « garde-fous », « limites » ou « contrôles ». Ne donne pas directement la réponse à l'élève. Donne-lui plutôt des indices pour l'étape suivante de la résolution du problème. Si l'élève est complètement perdu, détaille les étapes permettant de résoudre le problème.
Ton Le ton de la réponse. Vous pouvez aussi influencer le style et le ton en précisant un persona. Également appelé "style", "voix" ou "humeur". Réponds sur un ton informel et technique.
Contexte Toute information à laquelle le modèle doit se référer pour effectuer la tâche demandée. Également appelé "arrière-plan", "documents" ou "données d'entrée". Une copie du plan du cours de mathématiques que l'élève suit.
Exemples few-shot Exemples de réponse à une requête donnée. Également appelés "exemplaires" ou "échantillons." input: J'essaie de calculer le nombre de balles de golf qui peuvent tenir dans une boîte qui a un volume d'un mètre cube. J'ai converti un mètre cube en centimètres cubes et je l'ai divisé par le volume d'une balle de golf en centimètres cubes, mais le système indique que ma réponse est fausse.
output: Les balles de golf sont des sphères et ne peuvent pas être emballées dans un espace avec une efficacité parfaite. Vos calculs tiennent compte de l'efficacité d'emballage maximale des sphères.
Étapes du raisonnement Demandez au modèle d'expliquer son raisonnement. Cela peut parfois améliorer la capacité de raisonnement du modèle. Également appelé "étape de réflexion". Explique ton raisonnement étape par étape.
Format de réponse Le format dans lequel vous souhaitez que la réponse soit générée. Par exemple, vous pouvez demander au modèle de générer la réponse au format JSON, tableau, Markdown, paragraphe, liste à puces, mots clés, elevator pitch, etc. Également appelée "structure", "présentation" ou "mise en page". Mets ta réponse au format Markdown.
Récapitulatif Répétez brièvement les points clés de la requête, en particulier les contraintes et le format de réponse, à la fin de la requête. Ne donne pas la réponse, mais fournis plutôt des indices. Présente toujours la réponse au format Markdown.
Sauvegardes Elles ancrent les questions dans le contexte de la mission du bot. Également appelées "règles de sécurité". N/A

Selon les tâches spécifiques à effectuer, vous pouvez choisir d'inclure ou d'exclure certains des composants facultatifs. Vous pouvez également ajuster l'ordre des composants et vérifier comment cela peut affecter la réponse.

Exemple de modèle de requête

Le modèle de requête suivant montre un exemple de requête bien structurée :

      <OBJECTIVE_AND_PERSONA>
      You are a [insert a persona, such as a "math teacher" or "automotive expert"]. Your task is to...
      </OBJECTIVE_AND_PERSONA>

      <INSTRUCTIONS>
      To complete the task, you need to follow these steps:
      1.
      2.
      ...
      </INSTRUCTIONS>

      ------------- Optional Components ------------

      <CONSTRAINTS>
      Dos and don'ts for the following aspects
      1. Dos
      2. Don'ts
      </CONSTRAINTS>

      <CONTEXT>
      The provided context
      </CONTEXT>

      <OUTPUT_FORMAT>
      The output format must be
      1.
      2.
      ...
      </OUTPUT_FORMAT>

      <FEW_SHOT_EXAMPLES>
      Here we provide some examples:
      1. Example #1
          Input:
          Thoughts:
          Output:
      ...
      </FEW_SHOT_EXAMPLES>

      <RECAP>
      Re-emphasize the key aspects of the prompt, especially the constraints, output format, etc.
      </RECAP>

Bonnes pratiques

Les bonnes pratiques de conception de requêtes sont les suivantes :

Check-list de l'état des requêtes

Si une requête ne fonctionne pas comme prévu, utilisez la check-list suivante pour identifier les problèmes potentiels et améliorer les performances de la requête.

Problèmes d'écriture

  • Fautes de frappe : vérifiez les mots clés qui définissent la tâche (par exemple, sumarize au lieu de summarize), les termes techniques ou les noms d'entités, car les fautes d'orthographe peuvent entraîner de mauvaises performances.
  • Grammaire : si une phrase est difficile à analyser, contient des fragments de phrase, présente des sujets et des verbes qui ne correspondent pas ou semble maladroite sur le plan structurel, le modèle peut ne pas comprendre correctement la requête.
  • Ponctuation : vérifiez l'utilisation des virgules, des points, des guillemets et d'autres séparateurs, car une ponctuation incorrecte peut amener le modèle à mal interpréter la requête.
  • Utilisation d'un jargon non défini : évitez d'utiliser des termes, des acronymes ou des initialismes spécifiques à un domaine comme s'ils avaient une signification universelle, sauf s'ils sont explicitement définis dans la requête.
  • Clarté : si vous vous interrogez sur la portée, les étapes spécifiques à suivre ou les hypothèses implicites, la requête n'est probablement pas claire.
  • Ambiguïté : évitez d'utiliser des qualificatifs subjectifs ou relatifs qui ne comportent pas de définition concrète et mesurable. Fournissez plutôt des contraintes objectives (par exemple, "rédige un résumé de trois phrases ou moins" au lieu de "rédige un bref résumé").
  • Informations clés manquantes : si la tâche nécessite la connaissance d'un document, d'une règle d'entreprise, d'un historique utilisateur ou d'un ensemble de données spécifique, assurez-vous que ces informations sont explicitement incluses dans la requête.
  • Choix de mots inapproprié : vérifiez si la requête contient des expressions inutilement complexes, vagues ou verbeuses, car cela pourrait dérouter le modèle.
  • Examen secondaire : si le modèle continue de fonctionner mal, demandez à une autre personne d'examiner votre requête.

Problèmes liés aux instructions et aux exemples

  • Manipulation manifeste : supprimez de la requête tout langage extérieur à la tâche principale qui tente d'influencer les performances à l'aide d'appels émotionnels, de flatteries ou de pressions artificielles. Bien que les modèles de fondation de première génération aient montré une amélioration dans certaines circonstances avec des instructions telles que "de très mauvaises choses se produiront si vous ne faites pas cela correctement", les performances des modèles de fondation ne s'amélioreront plus et, dans de nombreux cas, elles se dégraderont.
  • Instructions et exemples contradictoires : vérifiez cela en auditant la requête pour détecter les contradictions logiques ou les incohérences entre les instructions ou entre une instruction et un exemple.
  • Instructions et exemples redondants : examinez la requête et les exemples pour voir si la même instruction ou le même concept est indiqué plusieurs fois de manière légèrement différente sans ajouter de nouvelles informations ni de nuances.
  • Instructions et exemples non pertinents : vérifiez si toutes les instructions et tous les exemples sont essentiels à la tâche principale. Si des instructions ou des exemples peuvent être supprimés sans réduire la capacité du modèle à effectuer la tâche principale, ils peuvent être non pertinents.
  • Utilisation d'exemples "few-shot" : si la tâche est complexe, nécessite un format spécifique ou présente un ton nuancé, assurez-vous qu'il existe des exemples concrets et illustratifs qui montrent un exemple d'entrée et la sortie correspondante.
  • Spécification du format de sortie manquante : évitez de laisser le modèle deviner la structure de la sortie. Utilisez plutôt une instruction claire et explicite pour spécifier le format et afficher la structure de sortie dans vos exemples few-shot.
  • Définition de rôle manquante : si vous demandez au modèle d'agir dans un rôle spécifique, assurez-vous que ce rôle est défini dans les instructions système.

Problèmes de conception de requêtes et de systèmes

  • Tâche sous-spécifiée : assurez-vous que les instructions de la requête fournissent un chemin clair pour gérer les cas extrêmes et les entrées inattendues, et fournissez des instructions pour gérer les données manquantes plutôt que de supposer que les données insérées seront toujours présentes et bien formées.
  • Tâche en dehors des capacités du modèle : évitez d'utiliser des requêtes qui demandent au modèle d'effectuer une tâche pour laquelle il présente une limite fondamentale connue.
  • Trop de tâches : si la requête demande au modèle d'effectuer plusieurs actions cognitives distinctes en une seule passe (par exemple, 1. résumer, 2. extraire des entités, 3. traduire et 4. rédiger un e-mail), il essaie probablement d'en faire trop. Décomposez les requêtes en requêtes distinctes.
  • Format de données non standard : lorsque les sorties du modèle doivent être lisibles par machine ou suivre un format spécifique, utilisez une norme largement reconnue telle que JSON, XML, Markdown ou YAML qui peut être analysée par des bibliothèques courantes. Si votre cas d'utilisation nécessite un format non standard, envisagez de demander au modèle de générer une sortie dans un format courant, puis d'utiliser du code pour convertir la sortie.
  • Ordre incorrect de la chaîne de pensée : évitez de fournir des exemples qui montrent le modèle générant sa réponse finale structurée avant d'avoir terminé son raisonnement étape par étape.
  • Réflexion ou raisonnement : si vous utilisez la réflexion, essayez de demander sans instructions détaillées sur la façon dont le modèle doit raisonner pour effectuer la tâche. Testez plutôt la réflexion et voyez si le raisonnement étape par étape généré par la réflexion améliore les performances par rapport à vos instructions de raisonnement explicites étape par étape.
  • Références internes contradictoires : évitez d'écrire une requête avec une logique non linéaire ou des conditions qui obligent le modèle à assembler des instructions fragmentées provenant de plusieurs endroits différents de la requête.
  • Risque d'injection de prompt : vérifiez s'il existe des protections explicites concernant les entrées utilisateur non fiables insérées dans le prompt, car cela peut constituer un risque de sécurité majeur.

Étape suivante