Meilleures pratiques de conception pour éviter les messages en double

Note

Cet article décrit les caractéristiques et le comportement du harnais standard. Apprenez comment accéder aux fonctionnalités standard dans Access Standard Agents et Flux d’agents.

Dans le harnais standard, plusieurs composants peuvent gérer la requête d’un utilisateur, et chacun agit de son propre point de vue. Un sujet peut afficher un message ou une carte adaptative, un outil peut renvoyer des données, et un enfant ou un agent connecté peut répondre depuis son propre contexte. La couche d’orchestration poursuit le plan à partir d’un contexte qui peut ne pas correspondre à la réponse reçue par l’utilisateur. Lorsque ces points de vue s’éloignent, l’utilisateur peut voir un message répété ou une réponse manquée. Les fabricants rencontrent ce comportement plus souvent avec les modèles plus récents que les anciens.

Comprenez pourquoi les doublons apparaissent avant de concevoir une solution. En savoir plus sur la distribution du contexte dans le harnais standard.

Note

Les messages répétés et les messages en double sont généralement des problèmes de conception liés à la gestion du contexte, et non des bugs. Ils surviennent lorsque l’utilisateur voit une réponse, mais la composante qui poursuit le plan contient des informations différentes sur ce qui a déjà été répondu.

Pour comprendre ces cas d’usage, considérez deux surfaces séparément : la sortie visible par l’utilisateur (ce que l’utilisateur voit dans le chat) et le contexte actif (l’information qu’un composant dispose lorsqu’il décide de la suite à donner). Les créateurs ne voient pas directement le contexte actif. Il est donc important de comprendre la perspective de chaque composante et d’utiliser les entrées et sorties pour maintenir ces perspectives alignées.

Pour diagnostiquer un problème sur un agent en production, commencez par Résoudre les problèmes de messages en double et de réponses non fournies, puis revenez à cet article pour obtenir des conseils de refonte.

Conception en tenant compte du contexte

Si une requête est traitée par une seule étape suivie d’un Fin de tous les sujets, la gestion du contexte n’entre pas en jeu. Mais lorsqu’une requête doit enchaîner plusieurs composants, ou lorsque l’utilisateur effectue plus d’une requête dans la même session, la gestion du contexte est importante. La plupart des cas d’usage réels couvrent plusieurs composants par session, donc concevoir en conséquence.

  • Un composant, puis Terminer toutes les rubriques. Un seul sujet, outil, agent enfant ou agent connecté gère la requête et la session se termine. Si ce composant écrit la réponse complète et rapporte cette complétion, la couche d’orchestration n’a aucune raison d’écrire une autre réponse.
  • Plusieurs volets de la séance. Une session peut exécuter plusieurs composants avant de fournir à l’utilisateur une réponse complète. Une session peut également couvrir plusieurs requêtes. Un composant peut répondre à une partie de la demande tandis qu’un autre doit répondre au reste. Chaque composant qui fonctionne doit indiquer ce qu’il a fait. Sinon, un composant ultérieur pourrait agir sur un contexte qui semble sans réponse et répondre à nouveau.
Lorsque le contexte compte Example Conception sonore
Aucun contexte utilisé Un sujet affiche la réponse complète dans un message ou une carte adaptative. Le nœud Clore tous les sujets empêche la couche d’orchestration de répondre de nouveau.
La couche d’orchestration utilise le contexte Un sujet montre un tableau pour la partie A, puis la couche d’orchestration répond à la partie B en utilisant des connaissances ou un autre agent. Chaque composant rapporte ce qu’il a répondu et renvoie les valeurs nécessaires aux étapes suivantes, afin que la couche d’orchestration ne réponde pas deux fois.
Le composant utilise le contexte Un sujet répond à la partie A à l’utilisateur, puis un autre agent gère la partie B. Si l’agent reçoit le contexte parent où A semble sans réponse, il répond à nouveau A. Excluez le contexte parent sur l’agent connecté lorsque possible, et les composants retournent des sorties qui confirment ce qui a été répondu et ce qui reste.

Composants de conception pour rapporter ce qui s’est passé

Un composant envoie un message répété ou des messages en double lorsque la couche d’orchestration ne peut pas détecter un travail qu’un composant précédent a terminé. Utilisez la même approche de conception à chaque fois pour éviter les messages en double — demandez à chaque composant de rapporter ses actions à la couche d’orchestration. Pour chaque partie de la requête, assignez exactement un composant pour écrire la réponse reçue par l’utilisateur. Tous les autres composants font leur travail et renvoient le contexte sans écrire à l’utilisateur.

Utilisez ces pratiques ensemble comme une seule approche de conception :

  1. Retournez les résultats qui consignent ce qui s’est passé. Les sorties seules suffisent généralement pour les anciens modèles.
  2. Ajoutez une instruction à la description du sujet ou du sous-agent qui définit ce que signifie une partie réussie. Cette approche rend la conception robuste.
  3. Ajoutez une instruction de premier niveau pour que la couche d’orchestration vérifie ces sorties avant de répondre. Les modèles plus récents bénéficient le plus de cette approche.

Seuls les composants supportant des sorties personnalisées peuvent renvoyer des sorties et inclure des instructions de description. Pour les composants qui ne supportent pas les sorties personnalisées, il faut éviter les messages en double en limitant le contexte qu’ils reçoivent et en ajoutant une instruction de premier niveau.

Composant Retour avec Corriger
Sujet answered (Vrai/Faux), choiceReceived (Vrai/Faux), et une valeur affichée ou une sortie récapitulative (Texte) Retournez les résultats et ajoutez une instruction à la description de la rubrique. Concevoir les sujets comme des mini-agents qui évitent les messages en double fournit des exemples de descriptions de sujets.
Sous-agent (enfant ou agent connecté) answered (Vrai/Faux), interactionSummary (Texte), openQuestions (Texte) Renvoyez les sorties, ajoutez une entrée de définition du périmètre et ajoutez une instruction à la description du sous-agent. Des sous-agents de conception qui évitent les messages en double fournissent des exemples de descriptions de sous-agents.
Connaissance (un appel à la connaissance) Impossible de personnaliser le contexte, il peut répéter une réponse. Gardez un contexte clair et de haut niveau et influencez les demandes envoyées.
Nœud de réponses génératives Impossible de personnaliser le contexte, il peut répéter une réponse, sa réponse peut être répétée plus tard. Maintenez un contexte de niveau supérieur clair, influez sur la requête transmise à l’entrée du nœud, et faites en sorte que la rubrique hôte renvoie le résultat ou un résultat avec l’état « répondu ».

Concevoir une instruction robuste de haut niveau pour éviter la répétition des messages

Les résultats permettent à la couche d’orchestration de rester informée. Ajoutez une instruction de premier niveau qui indique aux modèles plus récents de vérifier les sorties avant de répondre.

L’instruction d’agent de haut niveau suivante est un exemple conçu pour fonctionner à travers les cas d’usage, qu’un composant communique directement avec l’utilisateur ou non. Modifiez-le et personnalisez-le selon les besoins.

Chaque fois qu’une rubrique ou un agent est invoqué, recherchez toujours le booléen de sortie « answered » avant de décider de la réponse à apporter. Les sujets et les agents ont leur propre canal de communication avec l’utilisateur. Si « répondu » est vrai, supposez toujours que la demande a été répondue correctement en utilisant au moins une des variables de sortie, et vérifiez lesquelles en fonction de la description de sortie. N’utilisez pas de formule d’accusé de réception maladroite pour un contenu ayant déjà reçu une réponse. Ne fournir que les résultats non répondus, et poursuivre la conversation naturellement avec l’étape suivante.

Le terme canal ne désigne pas un canal d’intégration comme Teams ou un site web. C’est un dispositif d’invitation qui indique à la couche d’orchestration que l’utilisateur a peut-être déjà vu la réponse ou fait une sélection via un autre composant, comme un sujet, une carte ou un sous-agent. Cette formulation incite efficacement le modèle à vérifier sa réponse avant de répondre.

Gérer les sujets

Un sujet communique souvent directement avec l’utilisateur en montrant un message, en posant une question ou en présentant une carte adaptative. Le contexte d’orchestration reçoit le texte du sujet en texte clair, mais il n’indique pas si l’utilisateur l’a vu. Le contexte ne reçoit pas non plus d’actions ou de sélections de cartes adaptatives. Si le sujet répond à l’utilisateur mais ne rapporte pas cette action à la couche d’orchestration, la couche d’orchestration considère la requête comme non résolue et y répond à nouveau.

Conçois un sujet comme un mini-agent. Retournez une sortie avec l’état « répondu » afin que la couche d’orchestration sache que la demande a été traitée, ainsi que toute valeur affichée par la rubrique ou toute sélection qu’elle a recueillie et dont une étape ultérieure a besoin. Les résultats rendent les actions et résultats accessibles au reste du plan. Ajoutez une instruction à la description du sujet qui définit ce que signifie une partie réussie.

En savoir plus dans Concevoir des rubriques comme des mini-agents pour éviter les messages en double.

Gérer les agents enfants et les agents connectés

Concevez les agents enfants et connectés comme vous concevez n’importe quel autre composant. Leur échange avec l’utilisateur est invisible pour le parent, qui n’apprend ce qui s’est passé que via les sorties, et seulement après que l’agent ait terminé.

Les agents enfants et liés peuvent également recevoir des demandes auparavant sans réponse qui restent dans le contexte de l’agent parent.

Pour chaque agent, définir sa tâche avec une entrée, spécifier si elle répond à l’utilisateur ou reste silencieuse, et retourner des sorties qui indiquent à l’agent parent ce qui s’est passé.

En savoir plus sur les sous-agents de conception qui évitent les messages en doublon.

Gérer la connaissance

Connaissance est un concept de premier niveau auquel l’agent fait appel. Il reçoit une requête basée sur la conception de l’agent et reçoit également le contexte de l’agent. La plupart des problèmes de messages répétés surviennent lorsque le contexte de l’agent manque d’informations provenant d’autres composants. Concevoir des connaissances pour influencer la manière dont l’agent formule la demande. Assurez-vous que les autres composants utilisent correctement leurs sorties.

Gérer les nœuds de réponse générative

Un nœud de réponses génératives vit dans un sujet et répond à partir de la connaissance. Il reçoit le contexte parent plus ce qui est transmis dans son entrée, il se comporte donc comme une connaissance de haut niveau et complète sa réponse à partir du contexte actuel. Il peut écrire sa réponse directement dans le panneau de discussion ou la stocker dans une variable thématique, mais il ne peut rien renvoyer seul au contexte principal. Comme tout contenu thématique, sa réponse reste dans le sujet à moins que le sujet ne renvoie une sortie.

Un nœud de réponses générées ne nécessite aucune gestion particulière au-delà de la règle qui s’applique à chaque rubrique : transmettre le résultat en sortie de la rubrique. Si le nœud répond à l’utilisateur dans la rubrique, ajoutez une sortie d’état « répondu » et une sortie de valeur affichée. Ces sorties donnent à la couche d’orchestration un enregistrement indiquant que la requête a été répondue et empêchent une étape ultérieure de répondre à nouveau à la requête.

Assurez-vous que les descriptions et instructions correspondent au point de vue

Les descriptions et instructions font également partie du contrat de contexte.

Cette instruction redirige vers la rubrique :

When the user asks about their account balance, call the Account balance topic.

Cette instruction achemine et attribue la responsabilité des réponses à la couche d’orchestration :

When the user asks about their account balance, call the Account balance topic and give the balance.

Si le sujet montre déjà l’équilibre, la seconde instruction crée un second chemin de réponse. Si la rubrique ne renvoie pas balanceValue, la couche d’orchestration peut réinterroger la rubrique ou répondre qu’elle ne connaît pas la valeur.

Utilisez des descriptions et des instructions qui correspondent au point de vue :

  • Une description de sujet aide la couche d’orchestration à décider quand et comment utiliser le sujet. Il suit également les instructions concernant ce qu’il doit faire ou produire ensuite.
  • Une description d’agent connexe provient du point de vue parent.
  • Une instruction agent connexe est lue du point de vue de l’agent connexe.
  • Une description de sortie de sujet ou d’agent connecté indique à la couche d’orchestration comment interpréter la valeur retournée.

Pour un sujet qui donne une réponse à l’utilisateur et définit answered=true, décrivez à la fois quand acheminer vers le sujet et ce que signifie une exécution réussie :

This topic handles account balance requests.
If its answered output is true, the user has already received their response and it should not be answered again.

Pour une rubrique qui produit uniquement des sorties, décrivez à la fois quand acheminer vers cette rubrique et comment répondre :

This topic handles account balance requests and responds with the balance value in italics.

Rétablir le contexte dans de longues conversations

Une valeur qu’un composant possédait peut sortir du contexte actif de deux façons. Dans une longue session, une valeur disponible il y a quelques tours peut ne plus être dans le contexte actif. Ou un composant récupère un résultat complet, utilise la partie pertinente pour produire une réponse, et ne retourne que cette réponse, de sorte que le reste du résultat n’atteint jamais la couche d’orchestration. Dans un cas comme dans l’autre, l’agent peut récupérer de nouveau les données ou demander à l’utilisateur des informations dont il dispose déjà, ce que l’utilisateur perçoit comme une absence de réponse. La couche d’orchestration agit comme si elle n’avait jamais reçu cette valeur.

Concevez cette fonctionnalité pour ce scénario en renvoyant et en enregistrant le contexte important, puis en le restituant lorsque nécessaire :

  • Retournez un résultat complet, pas seulement la partie utilisée pour répondre. Un résultat rapporté comporte souvent plus d’un champ, de nombreuses lignes et un texte long. Retournez toutes les données dont une interaction ultérieure pourrait avoir besoin en sortie, afin que la couche d’orchestration en dispose sans avoir à les récupérer de nouveau.

  • Enregistrez et réutilisez des valeurs d’un tour à l’autre. Aux bons moments, avant ou après un appel d’outil, routez vers un sujet qui peut stocker ou servir la valeur via ses entrées et sorties ainsi qu’une variable globale, afin que le plan ne récupère pas la valeur ni ne la redemande.

Tip

Un comportement agent fluide repose sur une conception d’agent qui prend en compte le contexte à chaque étape et sous chaque point de vue.

  • Last updated on