Les instructions de l'agent fournissent des conseils détaillés au modèle sur ce qu'il doit faire. Ces instructions sont fournies en langage naturel.
Rédiger des instructions
Les instructions peuvent contenir les éléments suivants :
- Objectif global.
- Comment se comporter.
- Personnalité à utiliser.
- Liste des sous-agents, référencés par leur nom à afficher au format
{@AGENT: Agent Name}. - Instruction d'utiliser un outil spécifique, référencé par son nom à afficher au format
{@TOOL: tool_name}. - Référence à une variable, où le nom de la variable en snake case est placé entre accolades :
{variable_name}.
Exemple pour un agent racine :
CURRENT CUSTOMER: {username}
You are the main Weather Agent coordinating multiple agents.
Your primary responsibility is to provide weather information.
Use {@TOOL: get_weather} ONLY for specific weather requests
(for example, 'weather in London').
If you know the user's name, always greet them by their name.
You have specialized sub-agents:
1. Greeting Agent: Handles simple greetings like 'Hi', 'Hello'.
2. Farewell Agent: Handles simple farewells like 'Bye', 'See you'.
Analyze the user's query.
If it's a greeting, call {@AGENT: Greeting Agent}
If it's a farewell, call {@AGENT: Farewell Agent}
If it's a weather request, handle it yourself using {@TOOL: get_weather}
For anything else, respond appropriately or state you cannot handle it.
Coloration syntaxique
Lorsqu'une variable, un outil ou un agent est référencé dans l'éditeur d'instructions avec la syntaxe appropriée ({variable_name}, {@TOOL: tool_name} ou {@AGENT: Agent Name}), il est mis en surbrillance avec un "chip" coloré, indiquant que la syntaxe est reconnue.
Pour faciliter l'insertion de ces références, l'éditeur d'instructions propose deux raccourcis :
- Saisir
@ouvre un menu contextuel avec trois options : Agent, Outil ou Variable. Vous pouvez parcourir ce menu à l'aide des touches fléchées et de la touche Tabulation, ou en cliquant. Si vous sélectionnez une option, d'autres options s'affichent jusqu'à ce que la référence soit complète. Elle se transforme alors en chip. - Saisir
{ouvre un menu contextuel affichant les variables disponibles pour une insertion rapide.
Langues acceptées
Lorsque vous concevez des requêtes et des instructions pour l'agent, utilisez toujours l'anglais pour que l'agent comprenne au mieux. Lorsque vos agents interagissent avec vos utilisateurs, ils peuvent détecter la langue de la saisie de l'utilisateur final et répondre automatiquement dans la même langue, sauf indication contraire.
Si vous souhaitez que votre agent parle (ou ne parle pas) dans certaines langues, vous devez inclure une instruction décrivant la prise en charge. Par exemple, si votre agent ne doit répondre qu'en italien, vous pouvez inclure "vous ne parlez que l'italien et aucune autre langue" dans vos instructions.
Pour obtenir la liste des langues acceptées, consultez la documentation de référence sur les langages.
Restructurer les instructions
Vous pouvez saisir des instructions en langage naturel, mais votre agent peut être plus performant si vous les mettez en forme à l'aide d'une structure XML, ce qui peut aider le modèle à mieux les suivre. Nous fournissons une structure XML standard avec des balises que vous pouvez utiliser pour structurer vos instructions. Une fois que vous avez saisi des instructions en langage naturel, vous pouvez cliquer sur le bouton Restructurer les instructions au-dessus du panneau d'instructions pour les mettre au format XML recommandé.
Le tableau suivant décrit les balises XML recommandées et leur utilisation :
| Tag | Description |
|---|---|
role |
Définit la fonction ou la responsabilité principale de l'agent. |
persona |
Décrit la personnalité, le ton et les consignes comportementales de l'agent. |
primary_goal |
Dans <persona>, spécifie l'objectif principal de l'agent. |
constraints |
Liste les règles ou les limites que l'agent doit respecter. |
taskflow |
Définit les flux de conversation sous forme de série de sous-tâches. |
subtask |
Dans <taskflow>, une partie spécifique du flux de conversation contenant une ou plusieurs étapes. |
step |
Dans <subtask>, une étape individuelle qui inclut un déclencheur et une action. |
trigger |
Dans <step>, la condition ou l'entrée utilisateur qui lance une étape. |
action |
Dans <step>, l'action que l'agent doit effectuer lorsqu'une étape est déclenchée. |
examples |
Contient des exemples few-shot pour guider le comportement de l'agent dans des scénarios spécifiques. |
Voici un exemple des mêmes instructions utilisant la structure XML que nous recommandons :
CURRENT CUSTOMER: {username}
<role>The main Weather Agent coordinating multiple agents.</role>
<persona>
<primary_goal>To provide weather information.</primary_goal>
How to handle prohibited topics and violations: Respond appropriately or
state inability to handle the request.
General guidelines: Follow the constraints and task flow precisely.
</persona>
<constraints>
1. Use {@TOOL: get_weather} ONLY for specific weather requests
(for example, 'weather in London').
2. If the user's name is known (from the 'CURRENT CUSTOMER' context), always
greet them by their name.
</constraints>
<taskflow>
These define the conversational subtasks that you can take. Each subtask
has a sequence of steps that should be taken in order.
<subtask name="Initial Greeting">
<step name="Check for Username and Greet">
<trigger>Start of conversation or new user interaction.</trigger>
<action>If a username is provided in the 'CURRENT CUSTOMER' context,
greet the user by their name. Otherwise, proceed without a
personalized greeting.
</action>
</step>
</subtask>
<subtask name="Query Analysis and Routing">
<step name="Analyze User Query">
<trigger>User provides a query.</trigger>
<action>Determine the intent of the user's query
(greeting, farewell, weather request, or other).
</action>
</step>
<step name="Handle Greeting">
<trigger>User query is identified as a simple greeting
(e.g., 'Hi', 'Hello').
</trigger>
<action>Call {@AGENT: Greeting Agent}.</action>
</step>
<step name="Handle Farewell">
<trigger>User query is identified as a simple farewell
(e.g., 'Bye', 'See you').
</trigger>
<action>Call {@AGENT: Farewell Agent}.</action>
</step>
<step name="Handle Weather Request">
<trigger>User query is identified as a specific weather request
(e.g., 'weather in London').
</trigger>
<action>Use {@TOOL: get_weather} to retrieve weather information and
provide it to the user.
</action>
</step>
<step name="Handle Other Queries">
<trigger>User query does not fall into greeting, farewell, or
specific weather request categories.
</trigger>
<action>Respond appropriately to the query or state that the request
cannot be handled.
</action>
</step>
</subtask>
</taskflow>
<examples>
</examples>
Exemples few-shot intégrés
Le prompting few-shot est une technique qui consiste à fournir à un grand modèle de langage (LLM) un petit ensemble d'exemples pour guider son comportement, son ton ou sa logique. Dans le contexte des agents, les "exemples inline few-shot" font référence au placement de ces exemples directement dans les instructions de l'agent plutôt que dans un volet d'interface utilisateur distinct. Cette méthode aide le modèle à comprendre des exigences complexes en les lui montrant plutôt qu'en les lui expliquant. Elle comble ainsi le fossé entre les instructions abstraites et l'exécution concrète.
Quand utiliser des exemples few-shot ?
Les exemples few-shot sont un outil puissant pour la calibration, mais ils doivent être utilisés de manière stratégique. Envisagez d'en ajouter dans les cas suivants :
- Résoudre les problèmes de qualité : utilisez principalement des exemples pour corriger des échecs spécifiques lorsque le modèle ne comprend pas les instructions de manière cohérente.
- Mise en forme complexe : lorsque l'agent doit générer des données dans un format très spécifique et non standard.
- Logique nuancée : lorsque les instructions "si-alors" ne suffisent pas à saisir la subtilité d'un processus de prise de décision.
Bonnes pratiques et avertissements
Bien qu'efficaces, les exemples few-shot doivent être sélectionnés avec soin pour éviter de dégrader les performances de l'agent.
- Utilisez-les avec parcimonie : si vous ajoutez trop d'exemples, l'agent peut "surapprendre", c'est-à-dire qu'il peut suivre les exemples de manière rigide et perdre sa capacité à généraliser de nouvelles requêtes utilisateur inédites.
- Descriptif, pas exhaustif : vous n'avez pas besoin d'énumérer toutes les requêtes utilisateur possibles. Les exemples sont destinés à servir de guide pour le modèle de raisonnement, et non de base de données de recherche.
- Commencez par donner des instructions : essayez toujours de résoudre les problèmes de comportement en donnant d'abord des instructions claires et descriptives. N'ajoutez des exemples few-shot que si les instructions seules ne permettent pas d'obtenir le résultat souhaité.
Composants d'un exemple few-shot
Un exemple few-shot standard pour les agents se compose de quatre éléments distincts qui simulent un tour de conversation.
| Composant | Tag / Syntaxe | Description |
|---|---|---|
| Utilisateur | [user] |
Représente l'entrée ou la requête de l'utilisateur final. |
| Modèle | [model] |
Représente la réponse textuelle ou le processus de réflexion de l'agent. |
| Entrée de l'outil | tool_code |
Indique comment l'agent doit structurer l'entrée ou l'appel à un outil ou une fonction externe (par exemple, arguments/syntaxe spécifiques). |
| Sortie de l'outil | tool_outputs |
Simule les données renvoyées par l'outil, en apprenant à l'agent comment interpréter et utiliser ces données dans sa réponse finale. |
Le format suivant doit être utilisé pour les exemples few-shot :
<examples> EXAMPLE 1: Begin example [user] What's the weather in London? [model] ```tool_code get_weather(location="London") ``` ```tool_outputs {"temperature": "15 C", "condition": "Cloudy"} ``` [model] The weather in London is 15 C and Cloudy. End example </examples>
Affiner les instructions
Vous pouvez sélectionner une partie du contenu de vos instructions, puis un bouton Affiner s'affiche. Vous pouvez cliquer sur ce bouton pour utiliser l'IA afin d'améliorer le contenu sélectionné. Dans le champ Exigences, saisissez des informations sur la façon dont vous souhaitez améliorer le contenu sélectionné.
Mettre en forme les réponses des agents
Vous pouvez indiquer à l'agent comment mettre en forme ses réponses textuelles pour une meilleure lisibilité. Voici quelques bonnes pratiques pour les instructions de mise en forme :
Segmentation et espaces blancs
- N'écrivez jamais des paragraphes denses. Les utilisateurs parcourent le texte, ils ne le lisent pas.
- Limitez les blocs de texte à une ou deux phrases maximum.
- Insérez un saut de ligne entre chaque idée distincte pour créer un espace blanc.
Mise en gras stratégique
- Vous devez mettre en gras les points de données les plus importants pour qu'ils se démarquent immédiatement.
- Toujours en gras : noms de produits, prix, dates, numéros de commande et échéances.
- Exemple : "Le T-shirt classique est à 25 €."
Listes sur le texte
- Si vous mentionnez plus de deux éléments ou étapes, convertissez-les automatiquement en liste à puces ou numérotée.
- Utilisez des puces standards (
-) pour les options et des listes numérotées (1.) pour les instructions.
Instructions générales
En plus de définir des instructions spécifiques à l'agent, vous pouvez définir des instructions globales dans les paramètres avancés de l'application d'agent.
Chaque agent de l'application d'agent hérite des instructions globales, qui sont envoyées au modèle à chaque tour de conversation en plus des instructions spécifiques à l'agent.
Les instructions globales sont adaptées aux informations génériques que chaque agent doit connaître. Par exemple : le ton de la marque, les "À FAIRE et À NE PAS FAIRE" généraux, les variables partagées à l'échelle mondiale et les profils clients.