Compartir vía

Pruebas de DevOps de LUIS

  • Artículo

Importante

LUIS se retirará el 1 de octubre de 2025. Además, a partir del 1 de abril de 2023, ya no se podrán crear recursos de este servicio. Se recomienda migrar las aplicaciones de LUIS al reconocimiento del lenguaje conversacional para aprovechar el soporte continuo del producto y las capacidades multilingües.

Los ingenieros de software que desarrollan una aplicación de Language Understanding (LUIS) pueden aplicar prácticas de DevOps en torno al control de código fuente, las compilaciones automatizadas, las pruebas y la administración de versiones según estas instrucciones.

En las metodologías de Agile Software Development, las pruebas desempeñan un papel integral en la creación de software de calidad. Cada cambio significativo en una aplicación de LUIS debe ir acompañado de pruebas diseñadas para probar la nueva funcionalidad que está creando el desarrollador en la aplicación. Estas pruebas se comprueban en el repositorio de código fuente junto con el archivo de código fuente .lu de la aplicación de LUIS. La implementación del cambio finaliza cuando la aplicación pasa satisfactoriamente las pruebas.

Las pruebas son una parte fundamental de los flujos de trabajo de CI/CD. Cuando se proponen los cambios realizados en una aplicación de LUIS en una solicitud de incorporación de cambios (PR) o después de que los cambios se combinan en la rama principal, los flujos de trabajo de CI deben ejecutar las pruebas para comprobar que las actualizaciones no hayan causado ninguna regresión.

Cómo realizar pruebas unitarias y pruebas por lotes

En los flujos de trabajo de integración continua se deben realizar dos tipos diferentes de pruebas para una aplicación de LUIS:

  • Pruebas unitarias: pruebas relativamente simples que comprueban la funcionalidad clave de la aplicación de LUIS. Una prueba unitaria se supera cuando se devuelven la intención esperada y las entidades esperadas para una expresión de prueba determinada. Se deben superar todas las pruebas unitarias para que la ejecución de prueba se complete correctamente.
    Este tipo de pruebas son similares a las pruebas interactivas que puede realizar en el portal de LUIS.

  • Pruebas por lotes: las pruebas por lotes son una prueba completa sobre el modelo entrenado actual para medir su rendimiento. A diferencia de las pruebas unitarias, las pruebas por lotes no consisten en superar o no superar. La expectativa con las pruebas por lotes no es que todas las pruebas devuelvan la intención esperada y las entidades esperadas. En su lugar, una prueba por lotes ayuda a ver la precisión de cada intención y entidad de la aplicación y ayuda a comparar a lo largo del tiempo a medida que se realizan mejoras.
    Estas pruebas son del mismo tipo que las pruebas por lotes que puede realizar de forma interactiva en el portal de LUIS.

Puede emplear pruebas unitarias desde el principio del proyecto. Las pruebas por lotes solo son realmente de valor una vez que se ha desarrollado el esquema de la aplicación de LUIS y se trabaja para mejorar su precisión.

En el caso de las pruebas unitarias y las pruebas por lotes, asegúrese de que las expresiones de prueba se mantienen separadas de las expresiones de entrenamiento. Si realiza pruebas sobre los mismos datos con los que entrena, obtendrá la falsa impresión de que la aplicación funciona bien cuando esta simplemente realiza un sobreajuste de los datos de prueba. Las pruebas deben ser invisibles para el modelo para probar si la generalización funciona bien.

Escritura de pruebas

Al escribir un conjunto de pruebas, para cada prueba debe definir:

  • Probar expresión
  • Intención esperada
  • Entidades esperadas.

Use la sintaxis de archivo por lotes de LUIS para definir un grupo de pruebas en un archivo con formato JSON. Por ejemplo:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

Algunas herramientas para pruebas, como NLU.DevOps, también admiten archivos de pruebas con formato LUDown.

Diseño de pruebas unitarias

Las pruebas unitarias se deben diseñar para probar la funcionalidad básica de la aplicación de LUIS. En cada iteración (o sprint) del desarrollo de la aplicación, debe escribir un número suficiente de pruebas para comprobar que la funcionalidad clave que va a implementar en esa iteración funciona correctamente.

En cada prueba unitaria, para una expresión de prueba determinada, puede realizar lo siguiente:

  • Probar que se devuelve la intención correcta
  • Probar que se devuelven las entidades "clave": aquellas que son críticas para la solución.
  • Probar que la puntuación de predicción de la intención y las entidades supera un umbral definido por el usuario. Por ejemplo, puede decidir que solo se considerará que se ha superado una prueba si la puntuación de predicción para la intención y las entidades clave supera 0,75.

En las pruebas unitarias, es una buena idea probar que se han devuelto las entidades clave en la respuesta de la predicción, pero para omitir los falsos positivos. Los falsos positivos son entidades que se encuentran en la respuesta de la predicción, pero que no se han definido en los resultados esperados de la prueba. Al omitir los falsos positivos es menos oneroso crear pruebas unitarias, a la vez que le permite centrarse en probar que se devuelven en la respuesta de la predicción los datos que resultan clave para la solución.

Sugerencia

La herramienta NLU.DevOps es compatible con todas las necesidades para pruebas de LUIS. Cuando se usa en modo de prueba unitaria, el comando compare confirmará que se han superado todas las pruebas y omitirá los resultados con falsos positivos de entidades que no se han etiquetado en los resultados esperados.

Diseño de pruebas por lotes

Los conjuntos de pruebas por lotes deben contener un gran número de casos de prueba, diseñados para probar en todas las intenciones y todas las entidades de la aplicación de LUIS. Consulte Pruebas por lotes en el portal de LUIS para obtener información sobre cómo definir un conjunto de pruebas por lotes.

Ejecución de las pruebas

El portal de LUIS ofrece características para ayudar con las pruebas interactivas:

  • Las pruebas interactivas le permiten enviar una expresión de ejemplo y obtener una respuesta de las intenciones y las entidades reconocidas por LUIS. Se comprueba que la prueba se ha realizado correctamente mediante una inspección visual.

  • Las pruebas por lotes utilizan un archivo de pruebas por lotes como entrada para validar la versión entrenada actual con el fin de medir la precisión de su predicción. Una prueba por lotes ayuda a ver la precisión de cada intención y entidad en la versión activa, mostrando los resultados en un gráfico.

Ejecución de pruebas en un flujo de trabajo de compilación automatizada

Las características de pruebas interactivas del portal de LUIS son útiles, pero en el caso de DevOps, las pruebas automatizadas realizadas en un flujo de trabajo de CI/CD tienen ciertos requisitos:

  • Las herramientas para pruebas se deben ejecutar en un paso del flujo de trabajo en un servidor de compilación. Esto significa que las herramientas deben ser capaces de ejecutarse en la línea de comandos.
  • Las herramientas para pruebas deben ser capaces de ejecutar un grupo de pruebas en un punto de conexión y comprobar automáticamente los resultados esperados con respecto a los resultados reales.
  • Si se produce un error en las pruebas, las herramientas para pruebas deben devolver un código de estado para detener el flujo de trabajo y "suspender la compilación".

LUIS no ofrece una herramienta de la línea de comandos ni una API de alto nivel que proporcione estas características. Se recomienda utilizar la herramienta NLU.DevOps para ejecutar las pruebas y comprobar los resultados, tanto en la línea de comandos como durante las pruebas automatizadas dentro de un flujo de trabajo de CI/CD.

Las funcionalidades de prueba que están disponibles en el portal de LUIS no requieren un punto de conexión publicado y forman parte de las funcionalidades de creación de LUIS. Cuando las pruebas se van a implementar en un flujo de trabajo de compilación automatizada, debe publicar la versión de la aplicación de LUIS que se va a probar en un punto de conexión para que las herramientas para pruebas como NLU.DevOps puedan enviar solicitudes de predicción como parte de las pruebas.

Sugerencia

  • Si va a implementar su propia solución de pruebas y escribir código para enviar expresiones de prueba a un punto de conexión, recuerde que si usa la clave de creación de LUIS, la tasa de transacciones permitida se limita a 5 TPS. Limite la velocidad de envío o use una clave de predicción en su lugar.
  • Al enviar consultas de prueba a un punto de conexión, no olvide usar log=false en la cadena de consulta de la solicitud de predicción. Esto garantiza que las expresiones de prueba no se registran en LUIS ni se incluyen en la lista de revisión de expresiones del punto de conexión presentada por la característica de aprendizaje activo de LUIS y, como resultado, se agreguen accidentalmente a las expresiones de entrenamiento de la aplicación.

Ejecución de pruebas unitarias en la línea de comandos y en flujos de trabajo de CI/CD

Puede usar el paquete NLU.DevOps para ejecutar pruebas en la línea de comandos:

  • Use el comando test de NLU.DevOps para enviar pruebas desde un archivo de pruebas a un punto de conexión y capturar los resultados de predicción reales en un archivo.
  • Use el comando compare de NLU.DevOps para comparar los resultados reales con los resultados esperados definidos en el archivo de pruebas de entrada. El comando compare genera la salida de la prueba NUnit y, cuando se usa en modo de prueba unitaria mediante la marca --unit-test, confirmará que se han superado todas las pruebas.

Ejecución de pruebas por lotes en la línea de comandos y en flujos de trabajo de CI/CD

También puede usar el paquete NLU.DevOps para ejecutar pruebas por lotes en la línea de comandos.

  • Use el comando test de NLU.DevOps para enviar pruebas desde un archivo de pruebas a un punto de conexión y capturar los resultados de predicción reales en un archivo, igual que en el caso de las pruebas unitarias.
  • Use el comando compare de NLU.DevOps en modo de prueba de rendimiento para medir el rendimiento de la aplicación. También puede comparar el rendimiento de la aplicación con una prueba comparativa de rendimiento de línea base como, por ejemplo, los resultados de la última confirmación en la versión principal o en la versión actual. En el modo de prueba de rendimiento, el comando compare genera la salida de la prueba NUnit y los resultados de las pruebas por lotes en formato JSON.

Entrenamiento no determinista de LUIS y su efecto en las pruebas

Cuando LUIS entrena un modelo, como una intención, necesita tanto datos positivos, que son las expresiones de entrenamiento etiquetadas que ha proporcionado para entrenar la aplicación para el modelo, como datos negativos, que son aquellos datos que no son ejemplos válidos del uso de ese modelo. Durante el entrenamiento, LUIS crea los datos negativos de un modelo a partir de todos los datos positivos que ha proporcionado para los otros modelos, pero en algunos casos se puede producir un desequilibrio de datos. Para evitar este desequilibrio, LUIS muestrea un subconjunto de los datos negativos de un modo no determinista para su optimización para un conjunto de entrenamiento mejor equilibrado, un mejor rendimiento del modelo y un tiempo de entrenamiento más rápido.

El resultado de este entrenamiento no determinista es que puede obtener una respuesta de predicción ligeramente distinta entre las distintas sesiones de entrenamiento, normalmente para las intenciones y entidades en las que la puntuación de predicción no es alta.

Si desea deshabilitar el entrenamiento no determinista para aquellas versiones de la aplicación de LUIS que se crean con el fin de realizar pruebas, use la API de configuración de versiones con la opción UseAllTrainingData establecida en true.

Pasos siguientes