I. Introducción
En términos generales, los robots pueden tener conversaciones con personas. Lo más difícil de decir para un robot es escribir algunas reglas y plantillas manualmente para responder. Pero es realmente muy difícil para los robots entender las intenciones humanas. Por la diversidad de lenguaje, palabras polisémicas, juegos de palabras, oraciones largas y cortas, etc., especialmente la profundidad del chino. Por lo tanto, el robot necesita una gran cantidad de datos, es decir, para simular el método de interrogatorio del ser humano, para que el robot pueda comprender las características de estas intenciones, comprender el método de interrogatorio del humano y cómo responde el humano a las preguntas de otras personas. preguntas Esta parte del contenido se llama datos de entrenamiento en Rasa.
Rasa usa el formato YAML como una forma unificada y extensible de administrar todos los datos de entrenamiento, incluidos los datos de NLU, los datos de las historias y las reglas. Los datos de entrenamiento se pueden dividir en cualquier cantidad de archivos YAML, cada uno de los cuales puede contener cualquier combinación de datos, historias y reglas de NLU. El analizador de datos de entrenamiento utiliza la clave superior para determinar el tipo de datos de entrenamiento.
¿Los desarrolladores siguen buscando el formato de datos Markdown? Se eliminó en Rasa 3.0, pero aún se puede encontrar documentación para los datos NLU de rebajas y las historias de rebajas. Si aún tiene datos de entrenamiento en formato Markdown, entonces el método recomendado es usar Rasa 2.x para convertir sus datos de Markdown a YAML. La guía de migración explica cómo hacerlo.
1.1 Estructura de alto nivel
Cada archivo puede contener una o más claves y los datos de entrenamiento correspondientes . Un archivo puede contener varias claves, pero cada clave solo puede aparecer una vez en un solo archivo . Las claves disponibles incluyen:
reglas de las historias de la versión
nlu
Los desarrolladores deben especificar la clave de versión en todos los archivos de datos de entrenamiento YAML. Si el desarrollador no especifica una clave de versión en el archivo de datos de entrenamiento, Rasa supondrá que el desarrollador está utilizando el último formato de datos de entrenamiento compatible con la versión instalada de Rasa. Se omitirán los archivos de datos de entrenamiento con una versión de Rasa superior a la versión instalada en la máquina del desarrollador. Actualmente, la última especificación de formato de datos de entrenamiento para Rasa 3.x es 3.1.
1.2 ejemplo
Aquí hay un ejemplo para ilustrar, nlu, stroies y los datos de reglas se muestran en un archivo:
versión: "3.1"
nlu:
- intención: saludar
ejemplos: |
- Hola
- Hola
- hola [Sara](nombre)
- intención: preguntas frecuentes/
ejemplos de idioma: |
- ¿Qué idioma hablas?
- ¿Solo manejas inglés?
historias:
- historia: saludo y preguntas frecuentes
pasos:
- intención: saludo
- acción: utter_greet
- intención: preguntas frecuentes
- acción: utter_faq
reglas:
- regla: saludar al usuario
pasos:
- intención: saludar
- acción: pronunciar_saludo
Para probar historias específicas, colóquelas en un archivo separado y prefijelas con test_:
historias:
- historia: saludar y preguntar idioma
- pasos:
- usuario: |
hola
intención: saludar
- acción: utter_greet
- usuario: |
qué idioma hablas
intención: preguntas frecuentes/idioma
- acción: utter_faq
2. Datos de entrenamiento de NLU
Los datos de entrenamiento de NLU consisten en conversaciones de usuario de ejemplo clasificadas por intención. Los datos de entrenamiento de NLU también incluyen entidades, que pueden extraer información estructurada de los mensajes de los usuarios. También puede agregar información adicional a los datos de entrenamiento, como expresiones regulares y tablas de búsqueda, para ayudar al modelo a identificar correctamente las intenciones y las entidades. Los datos de entrenamiento de NLU se definen bajo la clave NLU. Las cosas que se pueden agregar en este artículo incluyen:
Ejemplos de capacitación agrupados por intención del usuario
Por ejemplo, una entidad con una etiqueta, pero la información de la etiqueta es opcional.
nlu:
- intent: check_balance
ejemplos: |
- ¿Cuál es el saldo de mi [crédito] (cuenta)?
- ¿Cuál es el saldo de mi [cuenta de tarjeta de crédito]{"entidad":"cuenta","valor":"crédito"}
sinónimos
nlu:
- sinónimo: crédito
ejemplos: |
- cuenta de tarjeta de crédito
- cuenta de crédito
expresión regular
nlu:
- expresiones regulares: número_cuenta
ejemplos: |
- \d{10,12}
mesa de cheques
nlu:
- búsqueda:
ejemplos de bancos: |
- JPMC
- Comerica
- Banco de América
2.1 Ejemplos de entrenamiento (muestras de datos de entrenamiento)
Los ejemplos de trenes se agrupan por intención y se enumeran en el campo de ejemplos. Por lo general, los desarrolladores enumerarán un ejemplo por línea, así:
nlu:
- intención: saludar
ejemplos: |
- hola
- hola
- que pasa
Sin embargo, si el desarrollador tiene un componente NLU personalizado y necesita metadatos para las muestras, también se puede usar el formato extendido:
nlu:
- intención: saludar
ejemplos:
- texto: |
hola
metadatos:
sentimiento: neutral
- texto: |
¡hola!
El campo de metadatos puede contener datos de valor-clave arbitrarios asociados con una instancia y accesibles por componentes en NLU. En el ejemplo anterior, los metadatos de opiniones se pueden usar para el análisis de opiniones mediante un componente personalizado en la canalización.
Los desarrolladores también pueden especificar estos metadatos en el nivel de intención:
nlu:
- intención: saludar
metadatos:
sentimiento: neutral
ejemplos:
- texto: |
hola
- texto: |
¡hola!
En este caso, el contenido contenido en el campo de metadatos se aplicará a cada instancia de intención.
Si el desarrollador necesita especificar la intención de recuperación, su ejemplo de NLU podría verse así:
nlu:
- intent: chitchat/ask_name
ejemplos: |
- ¿Cómo te llamas?
- ¿Puedo saber tu nombre?
- ¿Cómo te llama la gente?
- ¿Tienes un nombre para ti?
- intención: charlar/preguntar_tiempo
ejemplos: |
- ¿Como esta el tiempo hoy?
- ¿Se ve soleado afuera hoy?
- Oh, ¿te importaría comprobar el tiempo por mí, por favor?
- Me gustan los días soleados en Berlín.
Todos los intentos de recuperación tienen un sufijo agregado para identificar el campo de respuesta específico del bot. En el ejemplo anterior, ask_name y ask_weather son sufijos. El sufijo y el nombre de la intención están separados por un separador /.
2.2 Entidades
Las entidades son información estructurada que se puede extraer de los mensajes de los usuarios y se etiquetan con nombres de entidad en los datos de entrenamiento. Además de los nombres de las entidades, los desarrolladores pueden etiquetar las entidades con sinónimos, funciones o grupos.
En los datos de entrenamiento, los ejemplos de entidades etiquetadas son los siguientes:
nlu:
- intent: check_balance
ejemplos: |
- cuánto tengo en mi cuenta [de ahorro](cuenta)
- cuánto dinero hay en mi cuenta [de cheques]{"entidad": "cuenta"}
- ¿Cuál es el saldo en mi [cuenta de tarjeta de crédito]{"entidad" :"cuenta","valor":"crédito"}
La sintaxis completa para el etiquetado de entidades es la siguiente:
[<texto de entidad>]{"entidad": "<nombre de entidad>", "función": "<nombre de función>", "grupo": "<nombre de grupo>", "valor": "<sinónimo de entidad> "}
Las palabras clave de función, grupo y valor son opcionales al realizar anotaciones. El contenido del campo de valor puede hacer referencia a sinónimos. Si desea comprender el contenido de los campos de roles y grupos, puede consultar los roles y grupos de entidades.
2.3 Sinónimos (sinónimos)
Los sinónimos asignan entidades extraídas a valores fuera del texto extraído. Los desarrolladores pueden definir sinónimos usando los siguientes formatos:
nlu:
- sinónimo: crédito
ejemplos: |
- cuenta de tarjeta de crédito
- cuenta de crédito
Los desarrolladores también pueden definir sinónimos directamente en los datos de entrenamiento y establecer sinónimos especificando el campo de valor:
nlu:
- intent: check_balance
ejemplos: |
- cuánto tengo en mi [cuenta de tarjeta de crédito]{"entidad": "cuenta", "valor": "crédito"}
- cuánto debo en mi [cuenta de crédito]{"entidad": "cuenta" , "valor": "crédito"}
Si necesita saber más sobre sinónimos, puede ir aquí Página de datos de entrenamiento de NLU
2.4 Expresiones regulares (expresiones regulares)
Los desarrolladores pueden usar expresiones regulares para mejorar el efecto de la clasificación de intenciones y la extracción de entidades. Las expresiones regulares usan principalmente los módulos RegexFeaturizer y RegexEntityExtractor.
El formato para definir una expresión regular es el siguiente:
nlu:
- expresiones regulares: número_cuenta
ejemplos: |
- \d{10,12}
- intención: informar
ejemplos: |
- mi número de cuenta es [1234567891](número_cuenta)
- Este es mi número de cuenta [1234567891](número_cuenta)
número_cuenta es el nombre de la expresión regular. Cuando se usa como característica RegexFeaturizer, el nombre de la expresión regular no importa. Al usar RegexEntityExtractor, el nombre de la expresión regular debe corresponder al nombre de la entidad que el Bot extraerá.
Si necesita saber más acerca de las expresiones regulares, puede ir aquí Página de datos de entrenamiento de NLU
2.5 Tablas de búsqueda (tabla de búsqueda)
Se utiliza una tabla de búsqueda para generar una lista de expresiones regulares que no distingue entre mayúsculas y minúsculas. Se pueden usar de la misma manera que las expresiones regulares, en combinación con los componentes regexfeatureizer y RegexEntityExtractor en la canalización. Se puede usar una tabla de búsqueda para ayudar a extraer entidades con un conjunto conocido de valores posibles. Mantenga la tabla de búsqueda de su desarrollador lo más específica posible. Por ejemplo, para extraer nombres de países, puede agregar una tabla de búsqueda de todos los países del mundo. De hecho, este lugar es la función de agregar diccionario de sinónimos.
nlu:
- búsqueda:
ejemplos de bancos: |
- JPMC
- Comerica
- Banco de América
3. Datos de entrenamiento de conversación
Tanto las historias como las reglas representan el flujo de diálogo entre el usuario y el asistente de diálogo y se utilizan principalmente para entrenar el modelo de gestión de diálogo. Las historias se utilizan para entrenar modelos de aprendizaje automático para reconocer patrones en conversaciones y generalizar a rutas de conversación invisibles. rules describe el principio de que el bot debe seguir siempre la misma ruta y la estrategia de regla RulePolicy de entrenamiento.
3.1 Historias
Las historias suelen constar de las siguientes partes:
historia: El nombre de la historia. El nombre es arbitrario y no se usa para capacitación; los desarrolladores pueden usarlo como una referencia legible por humanos a la historia para estadísticas e ilustraciones.
metadatos: arbitrarios y opcionales, no se usan para entrenamiento, puede usar esto para almacenar información relevante sobre la historia, como el autor.
La lista de pasos: Mensajes de usuario y acciones que componen la historia.
Una muestra es la siguiente:
historias:
- historia: saludar al usuario
metadatos:
autor: alguien
clave: valor
pasos:
# lista de pasos
- intención: saludar
- acción: pronunciar_saludo
Cada paso puede ser uno de los siguientes:
Los mensajes de los usuarios se componen principalmente de intenciones y entidades.
declaración bajo la cual se contienen dos o más mensajes de usuario.
acción de robots
forma.
Eventos de tragamonedas.
punto de control, que conecta una historia con otra historia.
Mensajes de usuario
Todos los mensajes de usuario se pueden especificar con el campo de intención y el campo de entidades, este campo es opcional.
Al escribir historias, los desarrolladores no tienen que lidiar con los detalles de los mensajes que envían los usuarios. En su lugar, los desarrolladores pueden aprovechar el resultado de la canalización de NLU, que utiliza una combinación de intenciones y entidades para hacer referencia a todos los mensajes posibles que un usuario podría enviar con el mismo significado.
Los mensajes de usuario siguen el siguiente formato:
historias:
- historia: estructura del mensaje del usuario
pasos:
- intención: nombre_de_la_intención #
Entidades requeridas: # Opcional
- nombre_de_la_entidad: valor_de_la_entidad
- acción: nombre_de_la_acción
En el ejemplo "Quiero consultar mi saldo de crédito", "crédito" es una entidad. Las entidades incluidas en los datos de entrenamiento también son importantes, ya que la política aprende a predecir la siguiente acción en función de la combinación de intenciones y entidades (sin embargo, los desarrolladores también pueden cambiar este comportamiento mediante el atributo use_entities).
Comportamiento
Todas las acciones realizadas por el Bot se especifican mediante el campo de acción, seguido del nombre de la acción. Al escribir una historia, generalmente hay dos tipos de acciones:
1. Respuesta. Comience con "utter_" y devuelva mensajes específicos. Por ejemplo:
historias:
- historia: historia con una respuesta
pasos:
- intención: saludar
- acción: pronunciar_saludo
2. Personaliza acciones. Comenzó con "action_", ejecutó código arbitrario y envió cualquier número de mensajes (o ninguno). Por ejemplo:
historias:
- historia: historia con
pasos de acción personalizados:
- intención: comentarios
- acción: action_store_feedback
Formularios
Los formularios son un tipo específico de acción personalizada que contiene la lógica para recorrer un conjunto de espacios requeridos y solicitar esta información al usuario. El desarrollador define un formulario en el Dominio. Una vez que se definen los formularios, el desarrollador debe especificar la ruta del formulario como regla. Los desarrolladores deben incluir interrupciones en la forma u otros "caminos indeterminados" en las historias para que los modelos puedan predecir secuencias de diálogo invisibles. Un formulario, como paso de una acción, suele tener el siguiente formato:
historias:
- historia: historia con un formulario
pasos:
- intención: find_restaurant
- acción: restaurant_form # Activar el formulario
- active_loop: restaurant_form # Este formulario está actualmente activo
- active_loop: null # Formulario completo, ningún formulario está activo
- acción: utter_restaurant_found
El paso de acción activa el formulario y comienza a recorrer las ranuras requeridas. active_loop: el paso restaurant_form indica que actualmente hay un formulario de acción. Al igual que el paso slot_was_set, el paso de formulario no establece el formulario como activo, sino que indica que ya debería estar activo. Del mismo modo, un paso active_loop: null indica que ningún formulario debe estar activo hasta que se ejecuten los pasos posteriores.
Un formulario puede ser interrumpido y permanecer activo, en este caso, la interrupción debe ocurrir después del paso action: <formulario a activar>, seguido del paso active_loop: <formulario activo>. Un salto de tabla podría verse así:
historias:
- historia: comida interrumpida
pasos:
- intención: solicitud_restaurante
- acción: forma_restaurante
- intención: cháchara
- acción: cháchara_pronunciada
- active_loop: forma_restaurante
- active_loop: nulo
- acción: utter_slots_values
Tragamonedas
Los eventos de ranura se especifican en el campo slot_was_set: con un nombre de ranura y un valor de ranura opcional. Las ranuras actúan como la memoria del robot, establecidas por el campo action_extract_slots predeterminado, o por una acción personalizada, de acuerdo con la asignación de ranuras especificada en el dominio. Son referenciados por historias en el paso slot_was_set. Por ejemplo:
historias:
- historia: historia con una ranura
pasos:
- intención: celebrar_bot
- ranura_was_set:
- feedback_value: positivo
- acción: utter_yay
Esto significa que las historias requieren que el valor actual de feedback_value sea positivo para que la conversación se desarrolle según lo especificado.
La necesidad de incluir un valor para una ranura depende del tipo de ranura y si el valor puede o debe afectar el cuadro de diálogo. Si el valor no importa, como un espacio de texto, puede enumerar el nombre del espacio:
historias:
- historia: historia con una ranura
pasos:
- intención: saludar
- slot_was_set:
- nombre
- acción: utter_greet_user_by_name
puntos de control
Los puntos de control se especifican mediante el campo de punto de control, ya sea al principio o al final de la historia.
Los puntos de control son cómo conectas las historias. Pueden ser el primer o último paso de una historia. Si son los últimos pasos de una historia, al entrenar el modelo, esa historia se asociará con otras historias que comienzan con puntos de control del mismo nombre. Aquí hay un ejemplo de una historia que termina con un punto de control y un ejemplo de una historia que comienza con el mismo punto de control:
historias:
- historia: historia_con_un_punto_de_control_1
pasos:
- intención: saludar
- acción: pronunciar_saludo
- punto de control: saludar_punto de control
- historia: historia_con_un_punto_de_control_2
pasos:
- punto de control: saludo_punto_de_control
- intención: libro_vuelo
- acción: acción_libro_vuelo
También puede establecer condiciones para los espacios si el punto de control se establece al comienzo de la historia, por ejemplo:
historias:
- historia: historia_con_un_punto_de_control_condicional
pasos:
- punto de control: saludo_punto_de_control
# Este punto de control solo debe aplicarse si los espacios se establecen en el valor especificado
slot_was_set:
- context_scenario: vacaciones
- nombre_vacaciones: acción de gracias
- intención: saludar
- acción: utter_greet_thanksgiving
Los puntos de control pueden ayudar a simplificar y reducir la redundancia en sus datos de entrenamiento en desarrollo, pero no los use en exceso. El uso de muchos puntos de control puede hacer que la historia sea difícil de entender. Tiene sentido usarlos si una serie de pasos se repiten con frecuencia en diferentes historias, pero las historias sin puntos de control son más fáciles de leer y escribir.
3.2 Reglas
Las reglas generalmente se definen en el campo de reglas, que se parece a las historias. Las reglas también tienen un campo de pasos que contiene la misma lista de pasos que las historias. Las reglas también pueden contener campos de conversación iniciada y condiciones. Estos se utilizan para especificar las condiciones bajo las cuales se aplica la regla.
Una regla con una condición se ve así:
reglas:
- regla: solo diga `hey` cuando el usuario proporcionó una
condición de nombre:
- slot_was_set: - user_provided_name: pasos
verdaderos : - intención: saludar - acción: pronunciar_saludo
Si necesitas saber más sobre reglas, puedes ir aquí Reglas
4. Test Stories (historias de prueba)
Las historias de prueba verifican si los mensajes de los usuarios están correctamente clasificados y las predicciones de acción. Las historias de prueba usan el mismo formato que las historias, excepto que el paso del mensaje de usuario puede incluir el texto real y las entidades de anotación del mensaje de usuario especificado por el usuario. Aquí hay un ejemplo de una historia de prueba.
historias:
- historia: pasos básicos de prueba de extremo a extremo
:
- usuario: |
hola
intención: saludar
- acción: utter_ask_howcanhelp
- usuario: |
muéstrame [chino]{"entidad": "cocina"} restaurantes
intención: informar
- acción: utter_ask_ubicación
- usuario: |
en [París]{"entidad": "ubicación"}
intención: informar
- acción: utter_ask_price
Los desarrolladores pueden probar ejecutando el siguiente comando:
Prueba de sabor
Si necesita saber más sobre las pruebas, puede ir aquí Probando a su asistente
Cinco, Capacitación de extremo a extremo (capacitación de extremo a extremo)
A través de la capacitación de un extremo a otro, los desarrolladores deben lidiar con la intención específica extraída por la canalización de NLU. En cambio, los desarrolladores pueden usar el campo de usuario para colocar el texto del mensaje del usuario directamente en la historia.
Estos mensajes de usuario de extremo a extremo siguen el siguiente formato:
stories:
- story: estructura del mensaje del usuario
pasos:
- user: el texto real del mensaje del usuario
- action: action_name
Además, los desarrolladores pueden agregar etiquetas de entidad que TED Policy puede extraer. La sintaxis de las etiquetas de entidad es la misma que en los datos de entrenamiento de NLU. Por ejemplo, la siguiente historia contiene el enunciado del usuario Siempre puedo ir a comer sushi. Mediante el uso de la gramática en los datos de entrenamiento de la NLU [sushi](cocina), los desarrolladores pueden etiquetar el sushi como entidades de tipo cocina.
historias:
- historia: historia con entidades
pasos:
- usuario: Siempre puedo ir por [sushi](cocina)
- acción: utter_suggest_cocina
Del mismo modo, los desarrolladores pueden colocar declaraciones de bot directamente en historias usando el campo de bot seguido del texto que el desarrollador quiere que hable el bot.
Una historia con solo el campo bot podría verse así:
historias:
- historia: historia con una respuesta de principio a fin
pasos:
- intención: saludar
entidades:
- nombre: Iván
- bot: ¡Hola, una persona con nombre!
Los desarrolladores también pueden tener una historia híbrida de extremo a extremo:
historias: - historia: pasos
completos de la historia de principio a fin : - intención: saludar entidades: - nombre: Iván - bot: ¡Hola, una persona con un nombre! - intent: search_restaurant - acción: utter_suggest_cuisine - usuario: Siempre puedo elegir [sushi](gastronomía) - bot: Personalmente, prefiero la pizza, pero vamos a buscar restaurantes de sushi - acción: utter_suggest_cuisine - usuario: ¡Que tengas un hermoso día! - acción: utter_goodbye
La capacitación integral de Rasa está totalmente integrada con los métodos estándar de Rasa. Esto significa que los desarrolladores pueden mezclar historias donde algunos pasos están definidos por acciones o intenciones, mientras que otros están definidos directamente por mensajes de usuario o respuestas de bots.
6. Referencias
Formato de datos de entrenamiento
Introducción a Rasa Open Source y Rasa Pro
(13) Datos de entrenamiento RASA