Mejores prácticas de diseño para evitar mensajes duplicados

Note

Este artículo describe características y comportamientos del arnés estándar. Descubre cómo acceder a las funciones estándar en Acceder a los agentes estándar y a los flujos de agentes.

En el arnés estándar, varios componentes pueden gestionar la solicitud de un usuario, y cada uno actúa desde su propio punto de vista. Un tema puede mostrar un mensaje o una Tarjeta Adaptativa, una herramienta puede devolver datos, y un hijo o agente conectado puede responder desde su propio contexto. La capa de orquestación continúa el plan desde un contexto que puede no coincidir con la respuesta que recibe el usuario. Cuando esos puntos de vista se alejan, el usuario puede ver un mensaje repetido o una respuesta perdida. Los fabricantes se encuentran con este comportamiento con más frecuencia en modelos más nuevos que en modelos antiguos.

Entiende por qué ocurren duplicados antes de diseñar una solución. Aprende más sobre la distribución de contexto en el arnés estándar.

Note

Los mensajes repetidos y los duplicados suelen ser problemas de diseño relacionados con la gestión del contexto, no errores. Se producen cuando el usuario ve una respuesta, pero el componente que continúa el plan tiene información diferente sobre lo que ya se ha respondido.

Para entender estos casos de uso, considera dos superficies por separado: la salida visible para el usuario (lo que el usuario ve en el chat) y el contexto activo (la información que un componente tiene disponible cuando decide qué hacer a continuación). Los creadores no ven directamente el contexto activo. Por lo tanto, es importante entender la perspectiva de cada componente y utilizar entradas y salidas para mantener esas perspectivas alineadas.

Para depurar un síntoma en un agente en vivo, empieza con Solucionar mensajes duplicados y respuestas perdidas y luego vuelve a este artículo para recibir orientación sobre el rediseño.

Diseño teniendo en cuenta el contexto

Si una petición se gestiona con un solo paso seguido de un Fin de temas, la gestión del contexto no entra en juego. Pero cuando una petición necesita encadenar varios componentes, o cuando el usuario realiza más de una petición en la misma sesión, la gestión del contexto importa. La mayoría de los casos de uso reales abarcan varios componentes por sesión, así que diseña en consecuencia.

  • Un componente y luego terminar todos los temas. Un único tema, herramienta, agente hijo o agente conectado gestiona la solicitud y la sesión termina. Si ese componente escribe la respuesta completa y reporta esa finalización, la capa de orquestación no tiene razón para escribir otra respuesta.
  • Varios componentes de la sesión. Una sesión puede ejecutar varios componentes antes de dar al usuario una respuesta completa. Una sesión también puede abarcar varias solicitudes. Un componente puede responder a parte de la solicitud mientras que otro debe responder al resto. Cada componente que sí funciona debe informar de lo que ha hecho. De lo contrario, un componente posterior podría basarse en un contexto que parece no haber recibido respuesta y volver a responder.
Donde el contexto importa Example Diseño de sonido
No se ha utilizado contexto Un tema muestra la respuesta completa en un mensaje o Tarjeta Adaptativa. El nodo Terminar todos los temas impide que la capa de orquestación responda de nuevo.
La capa de orquestación utiliza el contexto Un tema muestra una tabla para la parte A, luego la capa de orquestación responde a la parte B usando conocimiento u otro agente. Cada componente informa de lo que respondió y devuelve los valores que necesiten los pasos posteriores, así que la capa de orquestación no responde dos veces.
El componente utiliza contexto Un tema da respuesta a la parte A al usuario y después otro agente se encarga de la parte B. Si el agente recibe un contexto superior en el que A parece no haber sido respondida, vuelve a responder a A. Excluye el contexto padre en el agente conectado cuando sea posible, y los componentes devuelven salidas que confirman lo que se respondió y lo que permanece.

Componentes de diseño para informar de lo ocurrido

Un componente envía un mensaje repetido o mensajes duplicados cuando la capa de orquestación no puede detectar trabajo que un componente anterior completó. Utiliza el mismo enfoque de diseño cada vez para evitar mensajes duplicados: instruye a cada componente para que informe sus acciones a la capa de orquestación. Para cada parte de la petición, asigna exactamente un componente para escribir la respuesta que recibe el usuario. Todos los demás componentes hacen su trabajo y devuelven el contexto sin escribir al usuario.

Utiliza estas prácticas juntas como un único enfoque de diseño:

  1. Devolver resultados que registran lo sucedido. Las salidas por sí solas suelen ser suficientes para modelos antiguos.
  2. Añade una instrucción al tema o descripción del subagente que defina qué significa una partida exitosa. Este enfoque hace que el diseño sea robusto.
  3. Añade una instrucción de nivel superior para que la capa de orquestación compruebe esas salidas antes de responder. Los modelos más recientes se benefician más de este enfoque.

Solo los componentes que soportan salidas personalizadas pueden devolver salidas e incluir instrucciones de descripción. Para los componentes que no soportan salidas personalizadas, evita mensajes duplicados limitando el contexto que reciben y añadiendo una instrucción de nivel superior.

Componente Informa con Corregir
Tema answered (Verdadero/Falso), choiceReceived (Verdadero/Falso) y una salida de valor mostrado o resumen (Texto) Devuelve los resultados y añade una instrucción a la descripción del tema. Diseñar temas como mini-agentes que evitan mensajes duplicados proporciona ejemplos de descripciones de temas.
Subagente (hijo o agente conectado) answered (Verdadero/Falso), interactionSummary (Texto), openQuestions (Texto) Devuelve los resultados, añade un parámetro de delimitación y añade una instrucción en la descripción del subagente. Subagentes de diseño que evitan mensajes duplicados proporciona ejemplos de descripciones de subagentes.
Conocimiento (un llamado al conocimiento) No se puede personalizar el contexto, puede que repita una respuesta. Mantén un contexto limpio y de alto nivel e influye en las solicitudes que se envíen.
Nodo de respuestas generativas No se puede personalizar el contexto, puede repetir una respuesta, y su respuesta puede repetirse más adelante. Mantener un contexto limpio de nivel superior, influir en la solicitud escrita en la entrada del nodo y hacer que el tema anfitrión devuelva la salida o una salida en estado respondido.

Diseña una instrucción robusta de nivel superior para evitar mensajes repetidos

Las salidas mantienen informada a la capa de orquestación. Añade una instrucción de nivel superior que indique a los modelos más nuevos que comprueben las salidas antes de responder.

La siguiente instrucción de agente de primer nivel es un ejemplo diseñado para funcionar entre casos de uso, tanto si un componente se comunica directamente con el usuario como si no. Edítalo y personalízalo según sea necesario.

Siempre que se llame a cualquier tema o agente, comprueba siempre el valor booleano de salida 'answered' antes de decidir qué responder. Los temas y agentes tienen su propio canal de comunicación con el usuario. Si 'respondido' es cierto, siempre asume que la petición ha sido respondida adecuadamente usando al menos una de las variables de salida y comprueba cuáles basándose en la descripción de salida. No des un reconocimiento torpe al contenido respondido. Proporciona solo los resultados pendientes y continúa la conversación de forma natural con el siguiente paso.

El término canal no se refiere a un canal de integración como Teams o una página web. Es un dispositivo de indicación que indica a la capa de orquestación que el usuario puede haber visto ya la respuesta o hecho una selección a través de otro componente, como un tema, una carta o un subagente. Esta redacción hace que el modelo compruebe su respuesta antes de responder.

Gestionar temas

Un tema suele comunicarse directamente con el usuario mostrando un mensaje, haciendo una pregunta o presentando una Tarjeta Adaptativa. El contexto de orquestación recibe el texto del tema como texto plano, pero no registra si el usuario lo ha visto. El contexto tampoco recibe acciones o selecciones de Adaptive Card. Si el tema responde al usuario pero no informa de esa acción a la capa de orquestación, la capa de orquestación trata la solicitud como no resuelta y la vuelve a responder.

Diseña un tema a modo de miniagente. Devuelve una salida en estado respondido para que la capa de orquestación sepa que la petición fue gestionada, y devuelve cualquier valor que el tema muestre o la selección que haya recogido y que necesite un paso posterior. Los resultados ponen las acciones y resultados a disposición del resto del plan. Añade una instrucción a la descripción del tema que defina qué significa una partida exitosa.

Aprende más sobre temas de diseño como mini-agentes que evitan mensajes duplicados.

Gestionar agentes secundarios y conectados

Diseña agentes secundarios y conectados igual que cualquier otro componente. Su intercambio con el usuario es invisible para el padre, que solo aprende lo que ocurrió a través de las salidas, y solo después de que el agente termine.

Los agentes hijos y conectados también pueden recibir solicitudes que no se respondieron anteriormente y que siguen en el contexto del agente padre.

Para cada agente, delimita su tarea con una entrada, especifica si responde al usuario o permanece en silencio, y devuelve salidas que indiquen al agente principal qué ha ocurrido.

Aprende más en Subagentes de Diseño que evitan mensajes duplicados.

Conocimiento del manejo

El conocimiento es una construcción de alto nivel a la que recurre el agente. Recibe una solicitud basada en el diseño del agente y recibe el contexto del agente. La mayoría de los problemas de mensajes repetidos ocurren cuando el contexto del agente carece de información procedente de otros componentes. Conocimientos de diseño para influir en cómo el agente formula la solicitud. Asegúrate de que otros componentes usen correctamente sus salidas.

Manejar nodos de respuestas generativas

Un nodo de respuestas generativas vive dentro de un tema y responde desde el conocimiento. Recibe el contexto principal junto con cualquier dato que se le pase como entrada, por lo que se comporta como un conocimiento de nivel superior y enriquece su respuesta con el contexto actual. Puede escribir su respuesta directamente en el panel de chat o almacenarla en una variable de tema, pero no puede devolver nada al contexto principal por sí solo. Como cualquier contenido temático, su respuesta permanece en el tema a menos que el tema devuelva una salida.

Un nodo de respuestas generativas no necesita un manejo especial más allá de la regla que se aplica a cada tema: pasar el resultado como salida de tema. Si el nodo responde al usuario dentro del tema, añade una salida de estado «respondido» y una salida de valor mostrado. Estas salidas proporcionan a la capa de orquestación un registro de que la petición fue respondida y evitan que un paso posterior vuelva a responder a la petición.

Asegúrate de que las descripciones e instrucciones coincidan con el punto de vista

Las descripciones e instrucciones también forman parte del contrato de contexto.

Esta instrucción lleva al tema:

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

Esta instrucción enruta y asigna la propiedad de la respuesta a la capa de orquestación:

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

Si el tema ya muestra el equilibrio, la segunda instrucción crea un segundo camino de respuesta. Si el tema no regresa balanceValue, la capa de orquestación podría llamar al tema de nuevo o responder que no conoce su valor.

Utiliza descripciones e instrucciones que coincidan con el punto de vista:

  • Una descripción del tema ayuda a la capa de orquestación a decidir cuándo y cómo usar el tema. También sigue instrucciones sobre qué hacer o qué generar a continuación.
  • Una descripción de agente conectado proviene del punto de vista del padre.
  • Una instrucción de agente conectado se lee desde el punto de vista del agente conectado.
  • Una descripción de salida de tema o agente conectado indica a la capa de orquestación cómo interpretar el valor devuelto.

Para un tema que muestre una respuesta al usuario y establezca answered=true, describe tanto cuándo enrutarse al tema como lo que significa una ejecución exitosa:

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.

Para un tema que solo genera salidas, describe tanto cuándo redirigir al tema como cómo responder:

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

Restaurar el contexto en conversaciones largas

Un valor que tenía un componente puede salir del contexto activo de dos maneras. En una sesión larga, un valor que estaba disponible hace unos turnos puede que ya no esté en el contexto activo. O un componente obtiene un resultado completo, usa la parte relevante para producir una respuesta y devuelve solo esa respuesta, de modo que el resto del resultado nunca llega a la capa de orquestación. En cualquier caso, el agente puede recuperar los datos o pedir al usuario información que ya posee, lo que el usuario experimenta como una respuesta perdida. La capa de orquestación actúa como si nunca hubiera recibido ese valor.

Diseña para este escenario recuperando y guardando información contextual importante, y volviéndola a mostrar cuando sea necesario:

  • Devuelve un resultado completo, no solo la parte utilizada para responder. Un resultado buscado suele tener más de un campo, muchas filas y texto largo. Devuelve todos los datos que un turno posterior podría necesitar como salidas, para que la capa de orquestación los tenga sin necesidad de rehacer retoques.

  • Guarde y use valores de un turno a otro. En los puntos adecuados, antes o después de una llamada a una herramienta, redirige a un tema que pueda almacenar o proporcionar el valor mediante sus entradas y salidas y una variable global, para que el plan no vuelva a obtener el valor ni lo pida de nuevo.

Tip

El comportamiento agente fluido se basa en un diseño de agente que tiene en cuenta el contexto en cada paso y desde todos los puntos de vista.

  • Last updated on