Entrenamiento del modelo para la comprensión del lenguaje natural

Oracle Digital Assistant admite dos tipos de intenciones: intenciones regulares y intenciones de respuesta. Ambos tipos de intención utilizan el mismo modelo de NLP, que se debe definir en Trainer Tm para las pruebas de preproducción y en producción.

La diferencia entre los dos tipos de intención es que las intenciones de respuesta están asociadas a un mensaje predefinido que se muestra cada vez que la intención se resuelve a partir de un mensaje de usuario, mientras que las intenciones normales, cuando se resuelven, conducen a una conversación de usuario a bot definida en el flujo de diálogo.

Las intenciones de respuesta se utilizan para que el bot responda a preguntas frecuentes que siempre producen una única respuesta. Las intenciones normales se utilizan para iniciar una interacción más larga entre el usuario y el bot, lo que lleva a la finalización de una tarea transaccional, la consulta de un sistema backend o la respuesta a una pregunta frecuente que debe tener en cuenta la dependencia externa, como la hora, la fecha o la ubicación, al proporcionar una respuesta.

Para que el desarrollo y el mantenimiento de la aptitud sean más eficientes, debe crear una convención de nomenclatura para las intenciones que facilite la comprensión inmediata de lo que representa una intención concreta y el uso de la opción de filtro al buscar intenciones.

Por ejemplo, una parte del nombre debe delimitar entre las intenciones de respuesta y las intenciones normales (y quizás también las intenciones normales que necesite para que pueda devolver una respuesta directa pero con un procesamiento más complejo, como con un anexo o basado en una consulta a un servicio remoto). Con esto en mente, puede comenzar con un esquema similar al siguiente:

• Intenciones normales: reg.<name_of_intent>

• Intenciones de respuesta: ans.<name_of_intent>

• Intenciones normales que son respuestas: reg.ans.<name_of_intent>

Si la aptitud maneja tareas relacionadas que se pueden clasificar, esto también se puede utilizar en la nomenclatura de intenciones. Supongamos que tiene la intención de crear órdenes y cancelar órdenes. Con estos dos casos de uso, la convención de nomenclatura podría ser:

• Intenciones normales: create.reg.<name_of_intent>, cancel.reg.<name_of_intent>

• Intenciones de respuesta: create.ans.<name_of_intent>, cancel.ans.<name_of_intent>

• Intenciones normales que son respuestas: create.reg.ans.<name_of_intent>, cancel.reg.ans.<name_of_intent>

No hay una regla estricta en cuanto a si usa notación de puntos, guiones bajos o algo propio. Sin embargo, mantenga los nombres lo suficientemente cortos como para que no se trunquen en el panel del editor de intenciones de Oracle Digital Assistant.

Cada intención también tiene un campo Nombre de conversación. El nombre de la conversación se utiliza en los cuadros de diálogo de desambiguación que crea automáticamente el asistente digital o la aptitud, si un mensaje de usuario se resuelve en más de una intención.

Cada intención tiene un campo Descripción en el que debe describir brevemente para qué sirve una intención para que otras personas que mantienen la aptitud puedan entenderla sin adivinarla.

Un ejemplo de intenciones de ámbito demasiado restringido es definir una intención independiente para cada producto que desea que maneje una aptitud. Tomemos como ejemplo la extensión de una póliza de seguro existente. Si ha definido intenciones por póliza, el mensaje "Quiero agregar a mi esposa a mi seguro de salud" no es muy diferente de "Quiero agregar a mi esposa a mi seguro de automóvil" porque la distinción entre los dos es una sola palabra. Como otro ejemplo negativo, imagine que en Oracle creamos un asistente digital para que nuestros clientes solicitaran soporte de productos y, en cada uno de nuestros productos, creamos una aptitud independiente con las mismas intenciones y expresiones de formación.

Cuando era niño, probablemente no desarrolló habilidades separadas para sostener botellas, pedazos de papel, juguetes, almohadas y bolsas. Más bien, simplemente aprendiste a mantener las cosas. El mismo principio se aplica a la creación de intenciones para un bot.

El ámbito de una intención es demasiado amplio si aún no puede ver lo que el usuario desea después de resolver la intención. Por ejemplo, supongamos que ha creado una intención denominada "handleExpenses" y que la ha entrenado con las siguientes expresiones y un buen número de sus variaciones.

• "Quiero crear un nuevo informe de gastos"

• "Quiero comprobar mi informe de gastos reciente"

• "Cancelar mi informe de gastos reciente"

• "Mi reciente informe requiere correcciones"

Con esto, se requeriría un procesamiento adicional para comprender si se debe crear, actualizar, eliminar o buscar un informe de gastos. Para evitar código complejo en el flujo de diálogo y reducir la superficie de error, no debe diseñar intenciones que sean demasiado amplias.

Recuerda siempre que el aprendizaje automático es tu amigo y que el diseño de tu modelo debería convertirte en un amigo igualmente bueno de la IA conversacional en Oracle Digital Assistant.

Y hay más funcionalidades proporcionadas por entidades que hacen que valga la pena dedicar tiempo a identificar la información que se puede recopilar con ellas.

Por ejemplo, ¿qué ocurre si un usuario introduce el mensaje "Compré este artículo el 12 de junio de 2021 y el 2 de julio de 2021" cuando se le solicita una fecha de compra? En este caso, la entidad, si se utiliza con el componente Respuesta común o Resolver entidades, generará automáticamente un cuadro de diálogo de desambiguación para que el usuario seleccione un único valor como entrada de datos. Al igual que en una conversación humana en la que una persona le pediría a otro que desambiguara una declaración u orden, las entidades harán lo mismo por usted. Y, por supuesto, las entidades también se pueden configurar para aceptar varios valores si el caso de uso lo soporta.

Además, cuando se utiliza el componente Respuesta común o Resolver entidades con entidades personalizadas, las peticiones de datos que se muestran a los usuarios se pueden definir en la entidad de forma que los usuarios obtengan peticiones de datos alternas cuando se vuelva a solicitar la entrada de datos con fallos anteriores. Cuando el mensaje de petición de datos cambia entre llamadas, hace que el bot sea menos robótico y más conversacional. Además, puede utilizar peticiones de datos alternas para revelar progresivamente más información para ayudar a los usuarios a proporcionar una entrada correcta.

Como práctica general, se recomienda utilizar entidades para realizar la validación de entradas de usuario y mostrar mensajes de error de validación, así como para mostrar peticiones de datos y cuadros de diálogo de desambiguación.

Al igual que con las intenciones, recomendamos una convención de nomenclatura que se debe seguir al crear nombres de entidad. Para empezar, si incluye el tipo de entidad en el nombre de la entidad, es más fácil comprenderlo de un vistazo y proporciona una forma sencilla de filtrar una lista de entidades. Por ejemplo, puede utilizar el siguiente esquema:

• Entidad de lista de valores: list.<name_of_entity>

• Entidad de expresión regular: reg.<name_of_entity>

• Entidad derivada: der.<name_of_entity> o der.DATE.<name_of_entity>

• Entidad de bolsa compuesta: cbe.<name_of_entity>

• Entidad de aprendizaje automático: ml.<name_of_entity>

Tanto si utiliza la notación de puntos como en los ejemplos anteriores, los guiones bajos o algo propio depende de usted. Más allá de eso, le sugerimos que trate de mantener los nombres bastante cortos.

Cada entidad tiene un campo Descripción en el que debe describir brevemente para qué sirve una entidad. El campo está limitado en el número de caracteres que puede introducir, así que asegúrese de ser conciso.

Al crear expresiones para las intenciones, utilizará la mayoría de las expresiones como datos de entrenamiento para las intenciones, pero también debe reservar algunas expresiones para probar el modelo que ha creado. Una división de datos 80/20 es común en la IA conversacional para el ratio entre expresiones que se van a crear para el entrenamiento y las expresiones que se van a crear para la prueba.

Otra proporción que puede encontrar al leer sobre aprendizaje automático es una división de 70/15/15. Una división 70/15/15 significa que el 70% de las expresiones se utilizarían para entrenar una intención, el 15% para probar la intención durante el desarrollo y el otro 15% para realizar pruebas antes de ir a producción con ella. Una buena analogía para el entrenamiento de intención es un examen escolar. El 70% es lo que un profesor te enseña sobre un tema. El primer 15% son pruebas que usted toma mientras estudia. Luego, cuando se trata de escribir tu examen, obtienes otro 15% de pruebas que no has visto antes.

Aunque 70/15/15 es convincente, recomendamos seguir utilizando una división 80/20 para entrenar las intenciones de Oracle Digital Assistant. Como verá más adelante en esta guía, obtendrá datos adicionales para las pruebas de expresiones de pruebas cruzadas en el contexto del asistente digital (pruebas complementarias). Por lo tanto, si sigue las recomendaciones de esta guía, recopilará suficientes datos para realizar pruebas para garantizar que sus modelos funcionen (incluso si no termina siendo una división 70/15/15). Y usted será capaz de ejecutar repetidamente esas pruebas para tener una idea de mejoras o regresión con el tiempo.

No hay basura, los diamantes salen cuando se trata de IA conversacional. La calidad de los datos con los que se entrena el modelo tiene un impacto directo en la comprensión del bot y su capacidad para extraer información.

El objetivo de la definición de expresiones es crear un juego imparcial y equilibrado de datos de entrenamiento y prueba que no desordenen el modelo de intención. Con el fin de hacerlo, aquí hay algunas reglas para que usted siga que, en nuestra experiencia, dar buenos resultados

• No utilice herramientas de generación para crear expresiones. Lo más probable es que obtenga muchas expresiones con poca variación.

• Considere diferentes enfoques para disparar una intención, como "Quiero restablecer mi contraseña" frente a "No puedo iniciar sesión en mi correo electrónico".

• No utilice expresiones que consten de palabras individuales, ya que carecen del contexto del que puede aprender el modelo de máquina.

• Evite palabras como "por favor", "gracias", etc. que no contribuyan mucho al significado semántico de las expresiones.

• Utilizar un juego representativo de valores de entidad, pero no todos.

• Variar la colocación de la entidad. Puede colocar la entidad al principio, al medio y al final de la expresión.

• Mantenga el número de expresiones equilibrado entre intenciones (por ejemplo, evite 300 para una intención y 15 para otra).

• Esforzarse por oraciones semánticas y sintácticamente completas.

• Utilice la ortografía correcta. Solo por excepción, agregaría algunas faltas de ortografía y errores tipográficos muy probables en las expresiones. El modelo generalmente es capaz de lidiar con errores ortográficos y errores tipográficos por sí solo.

• Agregue variaciones específicas del país (por ejemplo, papelera contra papelera, pañal contra pañal).

• Varíe la estructura de la frase (por ejemplo, "Quiero pedir una pizza", "Quiero una pizza, puedo pedir").

• Cambiar el pronombre personal (por ejemplo, yo, somos, somos, lo haría, lo haría, nosotros, usted, su, nosotros).

• Utilice diferentes términos para el verbo (por ejemplo, orden, obtener, preguntar, querer, como, querer).

• Utilice diferentes términos para el sustantivo (por ejemplo, pizza, calzone, hawaiano).

• Cree expresiones de diferentes longitudes (instrucciones cortas, medias y largas).

• Considere la pluralización (por ejemplo, "Quiero pedir pizzas", "Puedo pedir algunas pizzas").

• Considere el uso de diferentes formas verbales y gerundios ("Se permite la pesca", "Quiero pescar, puedo hacer esto").

• Utilizar la puntuación en algunos casos y omitirla en otros.

• Utilizar términos representativos (por ejemplo, evitar demasiados términos técnicos si el software es utilizado por los consumidores).

Las expresiones no se deben definir de la misma forma que escribiría argumentos de línea de comandos o palabras clave de lista. Asegúrese de que todas las expresiones que defina tengan la noción de "conversacional" para ellas. La creación de expresiones que solo tengan palabras clave enumeradas carecen de contexto o son demasiado cortas para que el modelo de aprendizaje automático aprenda.

Idealmente, las expresiones correctas se curan a partir de datos reales. Si no tiene registros de conversaciones existentes para empezar, considere las expresiones de crowdsourcing en lugar de simplemente sintetizarlas. Sintetizarlos debe ser su último recurso.

En el caso de las expresiones de origen colaborativo, envíe un correo electrónico a las personas que conoce que representan o saben cómo representar al público objetivo del bot. Además, puede utilizar la función de fabricación de datos de Oracle Digital Assistant para configurar un proceso automatizado para recopilar (crowdsourcing) sugerencias para expresiones, que probablemente desee seleccionar para que cumplan con las reglas que hemos descrito para qué es una buena expresión.

Tenga en cuenta que puede encontrar que las personas que solicita expresiones de muestra se sienten desafiadas a presentar ejemplos excepcionalmente buenos, lo que puede conducir a casos de nicho poco realistas o un uso demasiado artístico del lenguaje que requiere que curar las oraciones.

Además, tenga en cuenta que la curaduría de expresiones de muestra también implica la creación de múltiples variaciones de muestras individuales que ha cosechado a través del crowdsourcing.

La calidad de las expresiones es más importante que la cantidad. Algunas expresiones correctas son mejores que muchas recomendaciones utterances.Our mal diseñadas para empezar con 20-30 expresiones correctas por intención en desarrollo y, finalmente, aumentar ese número a 80-100 para realizar pruebas serias de las intenciones. Con el tiempo y a medida que el bot se prueba con usuarios reales, recopilará expresiones adicionales que luego seleccionará y utilizará para entrenar el modelo de intención.

En función de la importancia y el caso de uso de una intención, puede terminar con diferentes números de expresiones definidas por intención, que van desde cien hasta varios cientos (y, rara vez, entre miles). Sin embargo, como se ha mencionado anteriormente, la diferencia de expresiones por intención no debe ser extrema.

Un modelo de aprendizaje automático evalúa un mensaje de usuario y devuelve una puntuación de confianza para lo que cree que es la etiqueta de nivel superior (intención) y el subcampeón. En la IA conversacional, la etiqueta de nivel superior se resuelve como la intención de iniciar una conversación.

Por lo tanto, según el entrenamiento del modelo y el mensaje del usuario, imagine un caso en el que el modelo tenga un 80% de confianza en que la intención A es una buena coincidencia, un 60% de confianza para la intención B y un 45% para la intención C. En este caso, es probable que se sienta bastante cómodo de que el usuario desee la intención A.

Pero, ¿y si la etiqueta con la puntuación más alta tiene solo el 30% de confianza en que esto es lo que el usuario quiere? ¿Corre el riesgo de que el modelo siga esta intención o prefiere reproducirla de forma segura y asumir que el modelo no puede predecir lo que un usuario desearía y mostrar un mensaje al usuario para volver a redactar una solicitud?

Para ayudar al modelo de intención a tomar una decisión sobre qué intenciones considerar la coincidencia con una expresión de usuario, la IA conversacional utiliza un valor denominado umbral de confianza. El modelo de intención evalúa una expresión de usuario en todas las intenciones y asigna puntuaciones de confianza para cada intención. El umbral de confianza es un valor dentro del rango de posibles puntuaciones de confianza que marca la línea:

• por debajo de la cual se considera que una intención no corresponde en absoluto con la expresión; y,

• por encima de la cual una intención se considera una intención candidata para iniciar una conversación.

En Oracle Digital Assistant, el umbral de confianza se define para una aptitud en la configuración de la aptitud y tiene un valor por defecto de 0.7.

Un valor de 0.7 es un buen valor para empezar y probar el modelo de intención entrenado. Si las pruebas muestran que la intención correcta para los mensajes de usuario se resuelve muy por encima de 0,7, entonces tiene un modelo bien entrenado.

Si obtiene buenos resultados con un ajuste de 0,7, pruebe con 0,8. Cuanto mayor sea la confianza, más probable será que elimine el ruido del modelo de intención, lo que significa que el modelo no responderá a las palabras de un mensaje de usuario que no sean relevantes para la resolución del caso de uso.

Sin embargo, cuanto mayor sea el umbral de confianza, más probable será que disminuya la comprensión general (lo que significa que es posible que muchas expresiones viables no coincidan), lo que no es lo que desea. En otras palabras, el 100 por ciento de "comprensión" (o 1,0 como nivel de confianza) podría no ser un objetivo realista.

Recuerda que la IA conversacional consiste en entender lo que un usuario quiere, a pesar de que puede expresar eso de muchas maneras diferentes. Por ejemplo, en un caso de bot de pizza, los usuarios deberían poder pedir pizza con frases tan diversas como "Quiero pedir una pizza" y "Tengo hambre".