Présentation des stratégies de requête

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

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 accomplir 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. Des éléments tels que l'ordre, l'étiquetage et l'utilisation de délimiteurs peuvent 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 détaillées sur la façon d'effectuer la tâche Également appelés "tâche", "étapes" ou "directives".
  1. Détermine ce qui est demandé dans 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 Gemini 2.0 Flash et les modèles ultérieurs.

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. Propose également des suggestions de conception d'UI.
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 qu'il peut et ne peut pas faire. Également appelées "garde-fous", "limites" ou "contrôles". Ne donnez pas directement la réponse à l'élève. Donne-lui plutôt des indices lors de l'étape suivante pour l'aider à résoudre le 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ées "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 "exemples" ou "échantillons". input: J'essaie de calculer le nombre de balles de golf pouvant tenir dans une boîte 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 rangé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 les capacités de raisonnement du modèle. Également appelé "étape de réflexion". Explique ton raisonnement étape par étape.
Format de réponse Le format de réponse que vous voulez obtenir. 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". Mettez en forme votre 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 directement, mais fournis plutôt des indices. Mets toujours ta 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 :

Checklist sur l'état des requêtes

Si une requête ne fonctionne pas comme prévu, utilisez la checklist 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 incomplets, présente des sujets et des verbes qui ne s'accordent pas ou semble maladroite sur le plan structurel, il est possible que le modèle ne comprenne pas correctement la requête.
  • Ponctuation : vérifiez l'utilisation des virgules, des points, des guillemets et d'autres séparateurs. Une ponctuation incorrecte peut entraîner une mauvaise interprétation de la requête par le modèle.
  • Utilisation de jargon non défini : évitez d'utiliser des termes, des acronymes ou des sigles propres à un domaine comme s'ils avaient une signification universelle, sauf s'ils sont explicitement définis dans la requête.
  • Clarté : si vous vous demandez quelle est la portée, quelles sont les étapes spécifiques à suivre ou quelles sont les hypothèses implicites qui sont faites, il est probable que la requête ne soit pas claire.
  • Ambiguïté : évitez d'utiliser des qualificatifs subjectifs ou relatifs qui ne sont pas définis de manière 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écifiques, assurez-vous que ces informations sont explicitement incluses dans la requête.
  • Choix de mots inapproprié : vérifiez si la formulation de la requête est inutilement complexe, vague ou verbeuse, car cela pourrait dérouter le modèle.
  • Examen secondaire : si le modèle continue d'être peu performant, demandez à une autre personne d'examiner votre requête.

Problèmes liés aux instructions et aux exemples

  • Manipulation manifeste : supprimez du prompt le langage extérieur à la tâche principale qui tente d'influencer les performances en utilisant des appels émotionnels, de la flatterie ou une pression artificielle. Alors que les modèles de fondation de première génération ont montré des améliorations dans certaines circonstances avec des instructions telles que "de très mauvaises choses se produiront si vous ne faites pas attention", les performances des modèles de fondation ne s'amélioreront plus et, dans de nombreux cas, se détérioreront.
  • Instructions et exemples contradictoires : vérifiez si la requête contient des contradictions logiques ou des 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 sont énoncés 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 d'inclure des exemples concrets et illustratifs montrant 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 montrer la structure de la 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 des requêtes et du système

  • Tâche insuffisamment spécifiée : assurez-vous que les instructions de la requête fournissent une méthode claire pour gérer les cas limites et les entrées inattendues, et fournissent des instructions pour gérer les données manquantes au lieu de supposer que les données insérées seront toujours présentes et bien formées.
  • Tâche hors 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 fois (par exemple, 1. Résumer, 2. Extraire des entités, 3. Traduire et 4. Rédige un e-mail), il essaie probablement d'en faire trop. Décomposez les demandes 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 comme 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 (CoT) : évitez de fournir des exemples montrant le modèle générant sa réponse finale structurée avant d'avoir terminé son raisonnement étape par étape.
  • Références internes conflictuelles : évitez d'écrire une requête avec une logique non linéaire ou des conditions qui obligent le modèle à rassembler des instructions fragmentées provenant de plusieurs endroits différents de la requête.
  • Risque d'injection d'invite : vérifiez s'il existe des mesures de protection explicites concernant les entrées utilisateur non fiables insérées dans l'invite, car cela peut constituer un risque de sécurité majeur.

Étapes suivantes