Prácticas recomendadas generales para el diseño de agentes

En esta guía, se proporcionan prácticas recomendadas generales para diseñar todo tipo de agentes.

También deberías ver diseño de agente de voz específica para el diseño de agentes de voz, y las prácticas recomendadas para usar el servicio de Dialogflow.

Consejo general

Compila agentes iterativamente

Si tu agente será grande o complejo, comienza por compilar un diálogo que solo aborde las solicitudes de nivel superior. Una vez que se establece la estructura básica, iterar en las rutas de conversación para asegurarse de abarcar todas las rutas posibles que puede tomar un usuario final.

A medida que tu agente evoluciona, Considera usar la función de casos de prueba para el desarrollo basado en pruebas.

Agentes preconstruidos

Dialogflow ofrece plantillas de agente para ayudarte a comenzar. Agentes compilados previamente abarcan casos de uso comunes como servicios financieros, telecomunicaciones y viajes. Estos agentes incluyen intents y entidades que abordan las solicitudes más comunes de los usuarios. Agrega rutas y entregas específicas para tu empresa, y compilarás rápidamente un agente funcional.

Integraciones y conexión de tus servicios

Existen varias formas de integrar los agentes de Dialogflow. En esta sección, se proporcionan prácticas recomendadas para elegir cómo realizar la integración.

Integraciones

Dialogflow integraciones y proporcionan una interfaz de usuario lista para usar para tu agente. Si usas una integración, no necesitas llamar directamente a la API de Dialogflow, ya que las integraciones se encargan de esto por ti. Estas integraciones le proporcionan un agente de texto que puede incorporar conectarte con otras plataformas de mensajería o proporcionar una interfaz de telefonía.

API de Dialogflow

Si ninguna de las integraciones listas para usar es adecuada, o si quieres personalizar la interfaz para tu sistema puedes Usar la API de Dialogflow directamente Con este enfoque, tendrás que implementar la interfaz de usuario para tu agente o usar una interfaz de usuario existente.

Webhooks

A menos que tu agente pueda definirse completamente con datos estáticos, debes usar webhooks para conectar tu servicio y proporcionar un agente que pueda manejar situaciones dinámicas. Esto se aplica si usas integraciones o la API de Dialogflow.

Recursos del agente

Los recursos de agente de Dialogflow se pueden usar de muchas maneras para lograr el resultado deseado. En esta sección, encontrarás consejos para elegir los recursos adecuados para las situaciones correctas.

Flujos y páginas

Flujos y páginas le proporcionan estructura al agente. Puedes pensar en las páginas como nodos en una máquina de estados y flujos como grupos de páginas relacionadas. Las transiciones entre nodos se controlan controladores de estado, a las que se llama cuando se detecta una coincidencia con un intent, se cumple una condición o se invoca un evento.

Un agente simple puede funcionar bien con un solo flujo, pero los agentes complejos casi siempre están mejor diseñados con flujos múltiples. Cada flujo debe representar un tema de alto nivel para tu agente en la que cada página asociada al flujo ayuda a manejar el tema. Además, cada flujo puede tener su propia configuración, y puede ser de propiedad por un subconjunto de miembros del equipo, lo que ayuda a dividir el trabajo cuando se diseñan agentes grandes.

Cuando diseñas un agente grande y complejo, debes considerar "flujos por agente" y "páginas por flujo" límites. Estos límites ayudan a mantener el rendimiento de tu agente.

Si el diseño de tu agente tiene demasiados flujos por agente combinar temas relacionados en un solo flujo. Por ejemplo: puedes combinar los siguientes temas en un solo artículo "Obtener saldo" flujo:

  • Obtener saldo corriente
  • Obtener saldo de ahorro
  • Obtener saldo hipotecario
  • Obtener saldo de crédito

Si el diseño de tu agente tiene demasiadas páginas por flujo combinar páginas relacionadas y utilizar muchas rutas por página.

Si sigues teniendo dificultades con los límites de flujo y páginas, puede deberse a que tienes demasiada lógica empresarial incorporada en el propio agente. Considera trasladar esta lógica a webhooks.

A continuación, se enumera el nivel de detalle del control de conversación de los recursos del agente. en orden de detalle creciente:

  1. Agentes (un agente controla todas las conversaciones)
  2. Flujos (un flujo maneja uno o más temas de conversación relacionados)
  3. Páginas (una página maneja uno o más turnos de conversación relacionados)
  4. Rutas (una ruta maneja el intent de un usuario o la verificación de condición)

Comparación entre los parámetros de intent y los parámetros de formulario

La principal forma en que tu sistema obtiene datos estructurados del usuario final es con parámetros. Puedes usar parámetros para intents (parámetros de intents) o páginas (parámetros de formulario).

El objetivo principal de algunas páginas es recopilar información específica del usuario final. Por ejemplo: una página puede estar diseñada para recopilar la información de contacto del usuario final. En este caso, siempre debe usar parámetros de formulario para recopilar esta información.

En algunos casos, puedes capturar información del usuario final durante la transición de una página a otra. Por ejemplo: Si el usuario final solicita un producto en particular al principio de la conversación, quieres capturar el producto deseado durante la transición a la página de pedidos adecuada. En este caso, usar los parámetros de intents como parte rutas de intents.

También hay situaciones en las que usar tanto los parámetros de intent como los de formulario. Por ejemplo: si el usuario final solicita una camisa pequeña al principio de la conversación, Quieres capturar el parámetro de tamaño deseado (pequeño). durante la transición a la página de pedidos de camisas. Es posible que la página de pedidos de camisas te solicite información adicional como el color deseado. La página de pedidos de camisetas debe tener parámetros de forma para el tamaño y el color. En este ejemplo, ya se proporcionó el parámetro de tamaño y está propagado, por lo que el agente solo solicitará el color. Sin embargo, otras conversaciones pueden seguir un camino diferente, en los que el usuario final no proporcionó el tamaño deseado Cuando se activa la página de pedidos de camisetas. Al definir este parámetro de ambas maneras, tu agente es más flexible con la forma en que extrae la información.

Rutas y grupos de rutas

Si deseas hacer la transición a otra página poner en cola un mensaje de respuesta o llamar a un webhook cuando un intención coincide o una condition [estado] se cumple, usar rutas.

Si notas que usas el mismo conjunto de rutas en varias páginas, usar grupos de rutas. Esto evitará la duplicación innecesaria en el diseño de tu agente.

Reutilización de intents

Si notas que defines varios intents con frases de entrenamiento similares, considera reutilizar intents en varias páginas. Idealmente, debes definir algunos intents de uso general que se usan en muchas páginas y algunos intents específicos que se usan en una sola página. Esto evitará la duplicación innecesaria en el diseño de tu agente.

Por ejemplo: Por lo general, los intents de confirmación se definen mejor como intents reutilizables. Un intent confirmation.yes podría tener frases de entrenamiento como las siguientes:

  • sí
  • sí
  • sip
  • aceptar
  • sí, acepto
  • claro que sí
  • absolutamente
  • sí, por favor

Un intent confirmation.no podría tener frases de entrenamiento como las siguientes:

  • No
  • nah
  • nop
  • de ninguna manera
  • no es para mí
  • en absoluto
  • no, gracias

Estos intents de confirmación reutilizables puede usarse en muchas situaciones para tu agente.

En algunos casos, también debes considerar crear intents de confirmación especializados. Por ejemplo: al confirmar un pedido, es posible que quieras tener un intent especializado order.confirmation.yes con frases de entrenamiento como las siguientes:

  • el pedido me parece bien
  • Acepto este pedido

Un intent especializado order.confirmation.no con frases de entrenamiento como las siguientes:

  • No quiero este pedido
  • No acepto este pedido

Cuando la página de confirmación de tu pedido está activa, las rutas para estos cuatro intents debería estar dentro del alcance. Esto garantiza que cualquier confirmación genérica o específica del usuario final se manejen adecuadamente.

Intent negativo predeterminado

Debes completar el intent negativo predeterminado con frases que dirían tus usuarios finales, pero no deben coincidir con ningún intent del agente.

Fulfillment

Hay muchas opciones para usar entrega para responder al usuario final. Durante un turno de conversación, el agente puede agregar varios mensajes a la cola de respuestas y la cola concatenada se envía al usuario final al final de la conversación. En esta sección, se describe cada opción para crear los mensajes individuales.

  • Entrega de entrada de página: Se llama a esta entrega cuando la página se activa inicialmente. Es útil cuando quieres mostrar un mensaje que describa el propósito de la página, y solo debe decirse una vez mientras la página está activa. Por ejemplo:
    • ¿Qué te gustaría saber sobre tu cuenta corriente?
    • ¿Qué tipo de producto te gustaría comprar?
    • Necesito recopilar información sobre la camisa que quieres pedir.
  • Rutas: Se llama a esta entrega cuando una ruta de intent o una de condición con entrega. Esto es útil cuando deseas que haya un mensaje que responda al usuario final sobre la coincidencia de intents la condición satisfecha (que puede ser una condición de finalización para completar formularios) o la transición. Por ejemplo:
    • Sí, tu plan internacional incluye Japón. (coincidencia de intent)
    • ¿Confirmas que quieres comprar 300 camisas? (condición de comparación) se cumplen)
    • Muy bien, tu cita es para las 7 a.m. de mañana por la mañana. (completar formularios)
    • Bien, ahora hablemos de los cerdos hormigueros. (transición)
  • Controladores de eventos: Se llama a esta entrega cuando se invoca un evento. Resulta útil cuando quieres que un mensaje responda al evento. Por ejemplo:
    • Las acciones que buscas para comprar acaba de aumentar un 10% su valor. (evento personalizado)
    • ¿Puedes reformularlo? (evento sin coincidencias)
  • Mensajes iniciales para los formularios: Se llama a esta entrega cuando el agente completa formularios. Estos mensajes deben hacerle al usuario final una pregunta específica. Cada parámetro del formulario tiene su propia entrega de instrucciones inicial. Por ejemplo:
    • ¿Qué talla de camisa quiere?
    • ¿Qué color de camisa quieres?
  • Volver a solicitar controladores para formularios: Se llama a esta entrega cuando el agente completa formularios y no comprende la selección del usuario final para el parámetro actual. Esta entrega solo es necesaria si deseas recibir un mensaje nuevo. sea diferente del mensaje inicial. Si no existen controladores de reintentos, el agente solo usará el prompt inicial como mensaje nuevo. Por ejemplo:
    • No entiendo. ¿Puedes proporcionar un color válido para la camisa?

Nombre

En esta sección, se proporcionan consejos para asignar nombres a los recursos del agente.

Nombres de intents

Si tu agente tiene muchas intents, deberías considerar un esquema de nomenclatura que te ayude a mantenerlos organizados. Es común segmentar los nombres de los intents con puntuación, en la que la especificidad aumenta de izquierda a derecha. Además, un nombre de intent debe reflejar la intención del usuario final para un turno de conversación.

Existen muchos esquemas de nombres adecuados, pero este es un ejemplo:

  • phone-service.order.cancel
  • phone-service.order.create
  • phone-service.order.change
  • tv-service.order.cancel
  • tv-service.order.create
  • tv-service.order.change
  • account.balance.get
  • account.balance.pay
  • account.address.get
  • account.address.update

Transiciones

Transiciones definidas en controladores de estado proporcionar control sobre la conversación cambiando la página activa. En esta sección, se proporcionan consejos para organizar las transiciones de tu agente.

Transiciones complementarias

Cuando defines una ruta que activa una transición, considera que puede haber una ruta complementaria o inversa.

Por ejemplo:

  • Si tienes una ruta de intents para confirmation.yes, considera definir otra ruta para confirmation.no.
  • Si defines una ruta de condición con un operador booleano =, considera definir otra ruta que use !=.

Cómo manejar las entradas del usuario final

En esta sección, se proporcionan lineamientos para los intents y las frases de entrenamiento, para que tu agente pueda manejar y procesar de forma óptima la entrada del usuario final.

Define al menos 20 frases de entrenamiento

Debes tener al menos 20 frases de entrenamiento para cada intent. De lo contrario, es posible que el modelo de CLN no tenga suficiente información para que coincida con tu intención. Este es un lineamiento mínimo. Idealmente, deberías definir más especialmente para intents de encabezado de grandes agentes, en la que unos 50 son deseables.

Ten en cuenta el sesgo de intención

Cuando uno o más intents tienen muchas más frases de entrenamiento que otros intents, esto provoca que el modelo de CLN se inclina a favor de intents más grandes debido a datos desequilibrados. Este sesgo de intención puede ocurrir cuando la cantidad de frases de entrenamiento difiere en un orden de magnitud o más.

En algunos casos, este es el comportamiento deseado, porque podrías definir algunos intents que debería coincidir más a menudo que otros porque corresponden a las entradas del usuario final se observa con mayor frecuencia en el tráfico en tiempo real.

En otros casos, este comportamiento puede ser no deseado, porque no quieres un sesgo a favor de estos intents más amplios. Si este es el caso, reducir la cantidad de frases de entrenamiento para estos intents más grandes del mismo orden de magnitud que otros intents. Por ejemplo:

Frases de entrenamiento del intent A Frases de entrenamiento del intent B Sesgo del intent B
20 50 No
20 200 Con limitaciones
20 2000 Sí

Uso de la entidad y cantidad de frases de entrenamiento

Para todos los tipos de entidades que se usan en un intent:

  • Anota cada ejemplo de los tipos de entidad.
  • Para cada tipo de entidad, proporcionar al menos cinco frases de entrenamiento con ejemplos anotados.
  • Proporcionar al menos el triple de frases de entrenamiento que los tipos de entidades Por ejemplo: Si usas 10 tipos de entidades diferentes para las anotaciones en un intent, deberías tener al menos 30 frases de entrenamiento.

Las frases de entrenamiento deben ser naturales

Las frases de entrenamiento deben ser conversacionales y naturales. debe coincidir con lo que la gente dice realmente. Siempre que sea posible, usar las entradas del usuario final que ocurrieron en la producción como tus datos de entrenamiento, prestando especial atención a las más comunes.

Variedad de frases de entrenamiento necesarias

Incluyen variaciones de preguntas, comandos, verbos y sinónimos para sustantivos comunes. para asegurarte de que tus frases cubran un amplio espectro de solicitudes posibles.

Es mejor incluir algunas frases más cortas, como "paga mi factura", así como frases y oraciones más largas, como “Acabo de recibir algo por correo que dice que debo pagar el saldo de mi resumen de cuenta”. No hay una proporción recomendada de frases cortas a largas, pero debes basar esto en las entradas reales del usuario final antes de que se envíen al agente en producción.

Definir frases de entrenamiento que varían en longitud, redacción y estructura de la oración es importante para asegurar una buena capacitación para tu agente. No es necesario añadir variedad por el bien de la variedad, pero es necesario ofrecer suficiente variedad para que el modelo CLN pueda detectar con éxito la identidad de una gran variedad de entradas del usuario final. Si no tienes suficiente variedad, existe el riesgo de sobreajuste. En otras palabras, existe el peligro de que el modelo esté demasiado vinculado a los ejemplos particulares que proporcionas y no generalizará lo suficiente a otros ejemplos.

Variedad de las mayúsculas

La sensibilidad de mayúsculas varía según El modelo de CLN que usa tu agente.

CLN estándar

El modelo de CLN estándar no distingue mayúsculas de minúsculas. En casos excepcionales, es posible que debas agregar frases de entrenamiento que varían solo en el uso de mayúsculas. Por lo general, esto se aplica situaciones en las que esperas que los usuarios finales proporcionen entradas de texto en mayúsculas.

Los enfoques alternativos podrían ser:

CLN avanzada

A diferencia del modelo de CLN estándar, el modelo avanzado de CLN distingue entre mayúsculas y minúsculas. Mié recomendar pruebas y agregar los datos de entrenamiento en mayúsculas relevantes para aumentar y los porcentajes de coincidencias de intent.

Variedad de frases de entrenamiento innecesaria

Evita las variaciones triviales en las frases de entrenamiento, ya que proporcionan información duplicada al modelo de CLN. Por ejemplo: No incluya variantes que solo difieran en los siguientes aspectos:

  • Uso de mayúsculas: Si usas el modelo de CLN estándar, evita los duplicados. frases como "Pedir un boleto" y "pedir un boleto" excepto en raras diferentes. Sin embargo, el modelo avanzado de CLN distingue entre mayúsculas y minúsculas y requiere más frases de entrenamiento para aumentar las coincidencias de intents. Consulta la sección de variedad de mayúsculas para obtener más información.
  • Palabras de relleno: Por ejemplo, “De acuerdo, pide un boleto” y "pedir un boleto".
  • Puntuación: Por ejemplo, "¿Puedes ayudarme?". y "¿Puedes ayudarme?".

Coherencia en las anotaciones

La parte de la frase de entrenamiento seleccionada para una anotación debe incluir y no más que el texto necesario para coincidir con una entidad. Además, asegúrate de que las partes similares de las frases de entrenamiento estén anotadas para todo el intent.

Por ejemplo: la siguiente tabla muestra las formas correctas y las incorrectas para anotar con la entidad del sistema @sys.date:

Buena Malo
7 de septiembre: salida Salida del 7 de septiembre
Partirá el 4 de julio Partida el 4 de julio

Usa anotaciones semánticamente significativas para las entidades del sistema

El significado semántico de una parte de una frase de entrenamiento seleccionada para una anotación pueden verse afectados por el resto del texto de una frase de entrenamiento. Por ejemplo:

Frase de entrenamiento anotada Significado semántico del texto anotado
Tengo 7 años La edad de una persona
El contrato es válido por 7 años. Un intervalo de tiempo

Los modelos de aprendizaje automático de Dialogflow consideran el significado semántico cuando se buscan coincidencias con entidades del sistema. El significado semántico de la parte de la frase de entrenamiento debe coincidir con el significado semántico deseado de la entidad del sistema.

Por ejemplo, no uses la entidad de sistema @sys.duration. para la anotación de los primeros “7 años” ejemplo anterior. El significado semántico de "7 años" no coincide con una duración de tiempo simple. En su lugar, debes seleccionar "7" para la anotación y usa la entidad del sistema @sys.number.

Cómo definir intents para manejar las respuestas que no cumplen con los requisitos de llenado de formularios

Considera definir intents para manejar las respuestas que no cumplan con los requisitos de llenado de formularios. Por ejemplo: tu agente puede preguntar "¿Cuáles son las fechas de viaje?", seguida de la respuesta del usuario final “Aún no lo sé”. Esta respuesta no cumple con el mensaje del parámetro de formulario, pero si tu agente tiene una ruta de intents en el alcance que puede coincidir con esta respuesta, tu agente pueda manejar bien la situación.

Evita @sys.any

Evita usar el tipo de entidad del sistema @sys.any. Solo debe usarse si agotaste por completo todos los canales, incluida la creación de entidades personalizadas. Este tipo de entidad es muy amplio y puede causar un comportamiento no deseado.

Si usas este tipo de entidad, Evita anotar varias partes de una sola frase de entrenamiento por este tipo de entidad ya que esto crea una ambigüedad, y el comportamiento del agente será indefinido.

Es menos peligroso usar @sys.any con parámetros de forma, porque el agente espera información específica cuando solicites parámetros del formulario.

Las anotaciones deben incluir una variedad de valores de entidades

Cuando defines frases de entrenamiento anotadas, deberías usar una variedad de ejemplos de valores de entidad en las frases. No debes usar de manera coherente el mismo ejemplo de entidad. para las anotaciones. En el siguiente ejemplo, se muestran anotaciones buenas y malas Para un tipo de entidad de producto:

Buena Malo
quiero comprar una camisa quiero comprar una camisa
Pedir un sombrero nuevo Pedir una camisa nueva
Agregar un reloj a mi carrito Agregar una camisa a mi carrito

Las entidades personalizadas deben incluir variedad

Las entidades personalizadas deberían abarcar una amplia gama de ejemplos. El modelo CLN proporcionará variedad para las formas gramaticales, pero debes incluir todos los elementos posibles.

Evita las entidades que coinciden de forma agresiva

No definas entidades que coincidan con casi cualquier cosa. Esto degrada el rendimiento y la calidad del AA. Casi todo en cada frase de entrenamiento se evaluará como una posible coincidencia.

Las entidades de asignación y lista deben enfocarse en valores distintos

Los tipos de entidades Map y List deben tener un permiso limitado. que captura valores distintos de un tipo de información. Conserva tus entidades precisas, breves y simples.

Si los valores de tu entidad son complicados, podría deberse a que las frases de entrenamiento de intents se adaptan mejor a tu situación. Por ejemplo, considera las entradas del usuario final como:

  • "¿Cómo puedo hacer una llamada internacional con el Plan A?"
  • "Uso de roaming de datos internacional con el Plan B".

No crees tipos de entidades para las acciones y los planes, de la siguiente manera:

Tipo de entidad de acciones Tipo de entidad de planes
"¿Cómo puedo hacer una llamada internacional?". "Plan A"
"Uso del roaming de datos internacional" "Plan B"

En su lugar, debes usar frases de entrenamiento y coincidencia de intents para capturar las acciones y las entidades para capturar los planes.

Usa entidades de expresión regular para capturar identificadores que no sean palabras

Cuando captures entradas del usuario final que impliquen identificadores que no sean palabras, deberías usar entidades de expresión regular. Por ejemplo: para captar IDs de productos, como “AA-256” o "AC-436", usar una entidad de expresión regular, “[A-Z]{2}-\d{3}”.

Evita anidar entidades compuestas

No utilices más de un nivel de anidación en las entidades compuestas. Cada nivel de anidación degrada significativamente la calidad.

Cómo evitar intents similares

Cada intent debe capturar la intención del usuario final. Si defines diferentes intents con frases de entrenamiento similares, la coincidencia puede no ser confiable, debido a que el modelo CLN no puede determinar con confianza suficiente con qué intent establecer la coincidencia.

Si dos frases de entrenamiento representan la misma intención, deberían pertenecer al mismo intent. Por ejemplo: "cambiar la fecha límite de la factura actual" y "más tiempo para pagar" deben pertenecer al mismo intent, porque ambos solicitan un cambio en la fecha límite. Sin embargo, "¿Puedo hacer una llamada internacional con el Plan A?" y "¿Puedo usar roaming de datos internacional con el Plan A?" podrían pertenecer a diferentes intents, porque el usuario final quiere algo diferente en cada caso.

Evita tipos de entidades similares

Evita definir varios tipos de entidades. con entradas de entidad similares ya que esto puede generar ambigüedad en el modelo de CLN.

Usa eventos sin coincidencias en producción para mejorar tus intents

Cuando ejecutas tu agente en producción, es inevitable que algunas entradas del usuario final den como resultado eventos sin coincidencias. Puedes usar estas oportunidades para mejorar tu agente de una de estas tres maneras:

  • Agrega la entrada del usuario final como frase de entrenamiento al intent deseado. Sin embargo, esta no siempre es la mejor opción. Si haces esto muchas veces para la intención, podría generar sesgo de intención.
  • Limpia las frases de entrenamiento para el intent deseado. para que reflejen con exactitud la intención. En algunos casos, intents con frases de entrenamiento divergentes puede evitar la coincidencia para el intent.
  • Si los intents que no deben coincidir con la entrada del usuario final tienes frases de entrenamiento que podrían coincidir con la entrada del usuario final, borrar estas frases de entrenamiento.

Evita los caracteres especiales

Caracteres especiales en las frases de entrenamiento ({, _, #, [, etc.). La excepción son los emoticones, donde funcionan como se espera.

Evita las palabras de relleno

Las palabras de relleno son palabras que puede ignorar y aun así podrán entender el texto. Por ejemplo:

  • por favor
  • ¿Puedes, por favor?
  • Mmmm
  • ¿Qué te parece?

No es necesario, pero es inofensivo usar palabras de relleno en las frases de entrenamiento. porque el modelo de CLN los ignora. Sin embargo, no debes definir frases de entrenamiento que varían solo por palabras de relleno.

Nunca definas entidades que estén compuestas por palabras de relleno.

Experimenta con la configuración del AA

El Configuración del AA se pueden usar para ajustar la forma en que se procesan las entradas del usuario final. En la mayoría de los casos, la configuración predeterminada funciona bien. Sin embargo, te recomendamos ajustar la configuración para mejorar el rendimiento de tu agente.

Responder al usuario final

En esta sección, se proporcionan lineamientos para usar las entregas para responder al usuario final.

Da la bienvenida al usuario final

Un agente recién creado tiene una ruta de intents creada automáticamente para la intención de bienvenida. Debes editar esta ruta para incluir un mensaje de entrega que da la bienvenida al usuario final. Este mensaje debe describir al agente y dar al usuario final una idea de lo que es capaz de hacer.

Confirmar la información del usuario final

A menudo, es mejor repetir la información proporcionada por el usuario final en las respuestas. Esto le permite al usuario final saber que el agente comprende su solicitud.

Cuando se detecta una coincidencia con un intent y se produce una transición, informa al usuario final que la conversación avanza en función de su solicitud. Por ejemplo:

Diálogos Descripción
Usuario final: Tengo preguntas sobre mi cuenta corriente.
Agente: Bien, ¿qué te gustaría saber sobre tu cuenta corriente?		 La entrada del usuario final generó una coincidencia de intent, y se siguió una ruta que incluía un mensaje de entrega y una transición a una página que maneja las preguntas de verificación de la cuenta. Observa que el agente confirma que el usuario final desea saber acerca de su cuenta corriente.

Cuando se completa el formulario, repetir los datos proporcionados por el usuario final. Por ejemplo:

Diálogos Descripción
Usuario final: Mañana
Agente: Bien, se programó tu corte de cabello para mañana a las 7 p.m. ¿Puedo ayudarte con algo más?		 El usuario final proporcionó el parámetro de formulario de fecha, que era el último parámetro de formulario de la página activa. El agente confirmó la hora y fecha de un corte de cabello programado.

Guía la conversación

El agente siempre debe guiar la conversación con el usuario final. Esto se logra fácilmente finalizando cada respuesta. con una pregunta como la siguiente:

  • ¿Puedo ayudarte con algo más?
  • ¿Qué quieres saber sobre los beagles?
  • ¿Quieres cancelar o enviar ese pedido?
  • ¿En qué puedo ayudarte hoy?
  • ¿Viajas solo o con alguien?

Al definir estas preguntas, ten cuidado de no hacer varias preguntas como las siguientes:

  • ¿Sigues aquí? ¿Sobre qué servicio realiza su consulta?
  • ¿Aún quieres este pedido? ¿Quieres agregar algo?

El usuario final puede responder solo una de las preguntas, y es posible que tu agente no maneje la situación correctamente.

Manejo de errores y entradas inesperadas del usuario final

En esta sección, se proporcionan consejos sobre el manejo de errores y entradas inesperadas del usuario final.

Cómo crear controladores de eventos para eventos integrados

Debes crear controladores de eventos para la integrados según corresponda. El control de estos eventos es similar a detectar excepciones en la programación de software. Según la situación, es posible que quieras manejar los eventos con controladores de eventos específicos de parámetros, controladores de eventos específicos de la página, o controladores de eventos específicos del flujo.

Maneja errores de webhook

Cuando falla el servicio de webhook es importante que tu agente controle la falla sin problemas. Esto se logra definiendo controladores de eventos para la clase eventos integrados. Este es un enfoque recomendado para manejar los errores de webhook:

  • No proporciones un objetivo de transición desde controlador de estado que activa llamada de webhook, De lo contrario, no se invocará el controlador de eventos de errores de webhook. En su lugar, establece el objetivo de transición en la respuesta del webhook desde el servicio de webhook.

  • Elige una página en la que el contador de errores se pueda inicializar en cero. Esta página debe estar activa antes que la que activa una llamada de webhook. La entrega de entrada para esta página debe inicializar el contador de errores. a 0 con un ajuste predeterminado del parámetro de entrega. Por ejemplo:

    Parámetro Valor
    webhook-error-count 0

  • Crea una página de errores de webhook que controle los eventos de errores de webhook:

    • La entrega de entrada debe confirmar la falla para el usuario final. y debería aumentar un parámetro de sesión de contador de errores con un ajuste predeterminado del parámetro de entrega. Por ejemplo:

      Parámetro Valor
      webhook-error-count $sys.func.ADD($session.params.webhook-error-count, 1)

    • Define un ruta de condición que tenga una condición de que el recuento de errores es menor que el máximo permitido. (por ejemplo, $session.params.webhook-error-count <= 3). Esta ruta debe tener una entrega que notifique al usuario final que el agente volverá a intentar. Esta ruta debe tener un objetivo de transición configurado como PREVIOUS_PAGE: o a cualquier página que pueda hacer otro intento de llamar al webhook.

    • Define una ruta de condición que tenga una condición que indique que el recuento de errores es superior al máximo permitido (por ejemplo, $session.params.webhook-error-count > 3). Esta ruta debe tener una entrega que notifique al usuario final que el agente ya no volverá a intentarlo. Esta ruta debe tener un objetivo de transición configurado como una página que no activará reintentos de webhook.

  • El controlador de eventos de webhook debe tener un objetivo de transición que transfiera a la página de error del webhook.

Herramientas

En esta sección, se proporcionan consejos sobre el uso de herramientas para mejorar el diseño de los agentes.

Usa la herramienta de validación

Siempre debes usar el herramienta de validación para consultar tu agente. Esta herramienta encuentra algunos de los problemas descritos en esta guía.

Cómo usar la función de casos de prueba

Siempre debes definir casos de prueba para tu agente. Estos casos de prueba pueden ayudar a prevenir regresiones mientras que el agente evoluciona para admitir más situaciones.

Anterior
Prácticas recomendadas para el uso del servicio
Siguiente
Prácticas recomendadas para el diseño de agentes de voz