Prueba y evaluación de cargas de trabajo de IA en Azure
El propósito de las pruebas en las cargas de trabajo de IA es ayudar a garantizar la calidad cuando se introduce un cambio en el sistema. Las pruebas pueden validar si la carga de trabajo cumple los objetivos identificados y cumple las expectativas del usuario. También evita regresiones de calidad. Este proceso incluye la realización de pruebas en varias áreas funcionales y la evaluación de la calidad de la funcionalidad, el control de carga, la previsibilidad y otros criterios en función de los requisitos de la carga de trabajo.
Los resultados de las pruebas proporcionan puntos de datos críticos para las decisiones , como si los componentes de inteligencia artificial están listos para su lanzamiento y qué SKU o características son adecuadas. Además, las pruebas pueden servir como sistema de notificación para errores y ayudar a detectar problemas en producción a través de pruebas sintéticas o rutinarias.
Azure Well-Architected Framework describe una metodología de prueba completa. Debe usar varios tipos de pruebas en diferentes fases del ciclo de vida de desarrollo y en distintos componentes y flujos del sistema. Sin estas pruebas, los cambios implementados pueden degradar la calidad del sistema. Por ejemplo, los errores de código menores pueden convertirse en errores grandes del sistema. El comportamiento del sistema puede ser impredecible o producir resultados sesgados debido a la naturaleza no determinista de los sistemas de inteligencia artificial. Además, la asignación de recursos puede ser ineficaz y los datos reales del usuario o los recursos del sistema se pueden aprovechar porque estos sistemas son vulnerables a abusos.
Debe diseñar y desarrollar recursos de carga de trabajo teniendo en cuenta las pruebas. Por ejemplo, al realizar la manipulación de datos y cambiar la forma de los datos de origen para la ingeniería de características, siga los procedimientos recomendados de codificación y asegúrese de estructurar el código para admitir pruebas. Esta estrategia incluye diseñar el código para facilitar pruebas unitarias eficaces y aislar las pruebas de la funcionalidad del código y sus dependencias. En este ejemplo, debe diseñar un sistema que pueda realizar en un entorno de prueba con datos de prueba suficientemente representativos en términos de volumen y similares.
Debe implementar componentes de carga de trabajo en producción de forma segura. Parte de las prácticas de implementación seguras de cualquier carga de trabajo es una prueba estratégica para ayudar a garantizar un comportamiento correcto antes de que los usuarios o los datos consuman el sistema. Las pruebas estratégicas son esenciales durante la implementación inicial y a medida que el sistema evoluciona y se somete a cambios de código o infraestructura. Pruebe todos los cambios propuestos en el código y la infraestructura relacionados con la inteligencia artificial antes de implementar los cambios en producción.
Este artículo se centra en aplicar esa metodología a los aspectos de la inteligencia artificial de la arquitectura. Cómo llevar a cabo esas pruebas no está en el ámbito.
Recomendaciones
Este es el resumen de las recomendaciones proporcionadas en este artículo.
| Recomendación | Descripción |
|---|---|
| Defina las métricas de éxito para la estrategia de pruebas. | Al igual que cualquier otro tipo de pruebas de carga de trabajo, debe capturar y analizar las métricas adecuadas para una prueba determinada para asegurarse de que la prueba proporciona información útil sobre la carga de trabajo de IA. ▪ Definición de métricas correctas |
| Realice pruebas de un extremo a otro de las canalizaciones de ingesta y procesamiento de datos a lo largo del ciclo de vida de desarrollo. | Las pruebas pueden validar los datos y ayudarle a asegurarse de que el proceso de manipulación de datos funciona según lo previsto. Incorpore las pruebas al principio de la fase de diseño para garantizar la calidad de los datos, la tecnología adecuada y las opciones de ajuste de tamaño. Desarrolle pruebas unitarias para código personalizado durante el desarrollo y realice pruebas de producción en tiempo real para detectar problemas y validar la funcionalidad. ▪ Ingesta de datos de prueba |
| Ejecute pruebas para trabajos de entrenamiento para asegurarse de que los scripts se invocan y funcionan según lo previsto. | Las pruebas de carga y rendimiento pueden proporcionar información sobre la elección y el ajuste de tamaño del proceso adecuado para ejecutar los trabajos. Las pruebas unitarias pueden validar la utilidad del código y detectar regresiones cuando se actualizan las dependencias. ▪ Prueba del flujo de trabajo de entrenamiento |
| Evalúe y pruebe el modelo para evitar la duplicación en los datos de entrenamiento, evaluación y pruebas. | Para asegurarse de que los datos de origen no se usan completamente para el entrenamiento, debe reservar datos únicos para la evaluación del modelo y las pruebas finales. Estos subconjuntos no se incluyen en el proceso de entrenamiento real. ▪ Evaluación y prueba del modelo |
| Pruebe el punto de conexión de inferencia. | Realice pruebas de carga en el punto de conexión que hospeda el servidor de inferencia y elija SKU de GPU en función de esos resultados de prueba. En el caso de los puntos de conexión hospedados en plataforma como servicio (PaaS), pruebe el rendimiento y los posibles errores. Estos puntos de conexión son accesibles, por lo que se realizan pruebas de seguridad adecuadas para evitar situaciones de jailbreak. ▪ Prueba del punto de conexión de inferencia |
| Pruebe la corrección del diseño del índice para que las consultas produzcan resultados relevantes. | Las pruebas funcionales y de integración le ayudan a garantizar que los datos son precisos y las pruebas de esquema de índice comprueban la compatibilidad con versiones anteriores. Debe probar los pasos de preprocesamiento para la calidad. Las pruebas de carga determinan las SKU adecuadas para los recursos y los controles de seguridad protegen la confidencialidad de los datos. ▪ Prueba de los datos de puesta a tierra |
| Pruebe el orquestador para validar su funcionalidad y seguridad. | Realice pruebas unitarias, funcionales, de integración y en tiempo de ejecución, incluidas las pruebas del modo de carga y error, para garantizar el rendimiento y la confiabilidad. Las pruebas de seguridad y seguridad de contenido también son cruciales para proteger el sistema y los datos. ▪ Prueba del orquestador |
| Pruebe la descomposición del modelo. | La descomposición del modelo es un problema inevitable que afecta a la mayoría de las cargas de trabajo de inteligencia artificial. Las pruebas de los datos y el desfase de concepto pueden ayudarle a detectar el deterioro del modelo al principio y mitigar el problema antes de que afecte negativamente a la carga de trabajo. ▪ Impedir la descomposición del modelo |
Definición de métricas correctas
Se recomienda tener una línea base y medir la eficacia predictiva del modelo mediante métricas bien definidas. Estas son algunas métricas comunes.
La precisión representa la proporción de instancias predichas correctamente con las instancias totales del conjunto de datos de prueba. Es una medida común del rendimiento general del modelo.
La precisión es la proporción de predicciones positivas verdaderas a la suma de verdaderos positivos y falsos positivos. Es útil al minimizar los falsos positivos es importante, como en los diagnósticos médicos, por ejemplo.
La sensibilidad mide la proporción de verdaderos positivos a la suma de verdaderos positivos y falsos negativos. Es útil cuando se evitan falsos negativos o faltan casos relevantes, es fundamental.
La especificidad calcula la proporción de verdaderos negativos a la suma de verdaderos negativos y falsos positivos. Es relevante cuando se optimiza para predicciones negativas precisas.
Nota:
Al definir métricas de éxito para los modelos de regresión, considere la posibilidad de agregar las siguientes métricas:
El error absoluto medio (MAE) mide la diferencia absoluta media entre los valores previstos y los valores reales. Calcule la media de las diferencias absolutas entre cada valor real y su valor previsto correspondiente. MAE es menos sensible a los valores atípicos en comparación con MSE y RMSE.
El error cuadrático medio (MSE) mide la diferencia cuadrática media entre los valores reales y los valores previstos. Calcule la media de las diferencias cuadradas entre cada valor real y su valor previsto correspondiente. MSE penaliza errores más grandes que MAE porque los errores están cuadrados.
El error cuadrático medio raíz (RMSE) es la raíz cuadrada del MSE. Proporciona una medida del error absoluto medio entre los valores reales y previstos, pero en las mismas unidades que los datos originales. RMSE es más sensible a los valores atípicos en comparación con MAE porque cuadrado los errores antes de un promedio.
Ingesta de datos de prueba
Canalizaciones de datos, como procesos de extracción, transformación y carga (ETL), traslado y manipulación de datos. Pruebe la parte ETL de la carga de trabajo para asegurarse de que ingiere datos de forma confiable y que los datos son de alta calidad y aceptables para el análisis y la ingeniería de características. Asegúrese de que la limpieza y el procesamiento de datos incluyan pruebas para confirmar que las funciones de manipulación de datos según lo previsto.
Las pruebas deben integrarse durante todo el ciclo de vida, incluidas las fases de diseño, desarrollo y producción.
Prueba para facilitar las opciones de diseño
Cuando se recopilan requisitos para la carga de trabajo, un paso clave para tomar decisiones consiste en elegir una opción de tecnología específica que sea viable para el diseño.
En función de los criterios de aceptación y requisitos de ETL, realice pruebas funcionales exploratorias para seleccionar el producto más adecuado, sus SKU y las características que realizan las tareas previstas. La prueba de concepto, la prueba de tecnología y las pruebas de funcionalidades son esenciales para evaluar si elige la tecnología adecuada y si tiene el tamaño adecuado.
En escenarios en los que se incorpora la inteligencia artificial en una arquitectura existente, pruebe la forma en que la nueva tecnología se puede integrar con el sistema actual.
Los requisitos iniciales de la carga de trabajo pueden cambiar. Supongamos que la empresa prevé el crecimiento y el sistema debe controlar el doble de las consultas de usuario normales. Esta expectativa requiere un planeamiento adecuado de la capacidad. Se recomienda realizar pruebas proactivas para comprender cómo responde el sistema a los datos adicionales y realizar ajustes controlados por datos en el ajuste de tamaño existente o realizar nuevas opciones de producto. Para las pruebas de capacidad, se recomienda combinar pruebas funcionales con pruebas de carga y rendimiento y usar sintéticos para simular condiciones realistas.
Prueba para garantizar la calidad del código
Cuando se incluye código, asegúrese de que pasa por pruebas unitarias y no se libera si se produce un error. Por ejemplo, es habitual tener código personalizado que se ejecuta como parte de la ingesta. También se usa código para la limpieza y el procesamiento de datos. Ejecute pruebas unitarias para asegurarse de que el código se comporta según su diseño y que la manipulación de datos funciona según lo previsto.
Ejecute pruebas como parte de la canalización de integración continua y entrega continua.
Prueba en el sistema activo
Las pruebas funcionales deben extenderse al sistema activo. Si se produce un error en estas pruebas, considere la posibilidad de desencadenar alertas para iniciar investigaciones inmediatas, si es necesario. Estos son algunos ejemplos:
Ejecute pruebas programadas para comprobar que se recopiló el volumen correcto de datos si los datos se ingieren en una programación establecida con una cantidad esperada.
Ejecute pruebas que detecten problemas de datos, como valores que faltan o datos duplicados, y realice comprobaciones básicas de integridad de datos. Si los datos contienen información temporal que indica su actualización, estas pruebas pueden comprobar esa información y evitar que los procesos de bajada usen datos obsoletos.
Compruebe la disponibilidad de las dependencias externas. Por ejemplo, un trabajo de limpieza de datos podría llamar a otro servicio para extraer tablas o preprocesar. Ejecute pruebas para asegurarse de que están disponibles porque su falta de disponibilidad podría afectar al proceso de ETL.
Otra manera de probar la corrección del sistema ETL en producción es mediante pruebas sintéticas. Tener datos de prueba conocidos disponibles en producción es muy eficaz. Puede usarlo para validar el procesamiento de un extremo a otro comparando el estado inicial conocido con el estado final esperado para esos datos. Por ejemplo, se requiere un documento para pasar por la inteligencia de documentos y contener datos personales. La inserción de un documento sintético puede probar que la carga de trabajo realiza el trabajo de manipulación de datos según lo previsto.
Además, experimente liberando experiencias diferentes, también conocidas como pruebas A/B, para aprender de las interacciones del usuario antes de confirmar completamente. Las pruebas A/B ayudan a evitar regresiones de calidad.
Prueba de los datos recopilados durante la ingesta
Como parte del proceso de ingesta de varios orígenes de datos, incluya pruebas para validar que los datos de entrenamiento coinciden con sus expectativas.
El entrenamiento de un modelo de Machine Learning con datos incompletos o dañados puede ser productivo. Podría dar lugar a esfuerzos desperdiciados y dar lugar a un modelo que no puede realizar predicciones significativas. Las canalizaciones de ingesta y preprocesamiento de datos incluyen pruebas de calidad como puntos de control. Estas pruebas pueden ayudarle a comprobar que los datos se alinean con las expectativas establecidas durante el análisis de datos y la ingeniería de características.
En la lista siguiente se incluyen algunos casos de prueba de ejemplo:
Prueba de integridad. Pruebe la cantidad esperada de datos de entrenamiento para comprobar la integridad del conjunto de datos. Esta prueba garantiza que proporcione suficientes datos para entrenar el modelo.
Pruebe para obtener información crítica. Si el entrenamiento se basa en entidades conocidas, como registros o identificadores específicos, pruebe el conjunto de datos para asegurarse de que esas entidades están presentes. Esta validación garantiza que no falta información crítica.
Pruebe si hay datos irrelevantes. Los datos ingeridos no deben contener entradas irrelevantes o erróneas. El proceso de ingesta de datos debe filtrar esos datos.
Pruebe la actualización. La actualización de los datos ingeridos no debe afectar a la potencia predictiva del modelo. Compruebe que los datos reflejan información razonablemente actual y no están obsoletos de las ejecuciones anteriores. Por ejemplo, si espera que los datos incluyan registros de la semana pasada, pero no hay registros de este tipo después de importar los datos, que podrían indicar un problema de importación con errores o de actualización de datos en el sistema de origen.
Realización de pruebas rutinarias
Una preocupación importante con la ingesta de datos es el volumen de datos y rendimiento. La evaluación continua durante las operaciones es necesaria para evitar cuellos de botella de rendimiento. Esta evaluación en curso debe formar parte de los procesos operativos en lugar de solo una prueba única. El objetivo es asegurarse de que el equipo de cargas de trabajo no pierda sus objetivos de nivel de servicio.
Considere una situación en la que la supervisión indica la degradación del rendimiento. Para mitigar estas condiciones, vuelva a evaluar y optimizar los procesos ETL. Después de realizar cambios, las pruebas de rendimiento pueden ayudarle a asegurarse de que las modificaciones cumplen el rendimiento necesario.
Nota:
Las pruebas y la supervisión sirven para diferentes propósitos. Realice pruebas para evaluar los posibles cambios en el sistema, normalmente antes de implementar los cambios. Llevar a cabo la supervisión continuamente para evaluar el estado general del sistema.
Prueba del flujo de trabajo de entrenamiento
Entrene un modelo mediante código personalizado, como scripts de PyTorch, que realizan el trabajo de entrenamiento real. Estos scripts se ejecutan en proceso, como en cuadernos o trabajos de Azure Machine Learning, que también requieren recursos de memoria y redes. Se recomienda realizar pruebas de carga durante la fase de diseño para evaluar las necesidades de proceso y asegurarse de que las SKU propuestas son adecuadas. A menudo, necesita pruebas manuales para determinar la mejor configuración para ejecutar eficazmente la carga de trabajo dentro del límite de tiempo.
Escriba los scripts mediante SDK especializados, que controlan la mayoría de las tareas. Sin embargo, dado que los scripts siguen siendo código, debe integrar pruebas unitarias como parte del desarrollo. Estas pruebas le ayudan a asegurarse de que no se producen regresiones al actualizar las dependencias. Si no es posible realizar pruebas unitarias, es necesario realizar pruebas manuales antes de implementar código nuevo para evitar regresiones de calidad.
Estos scripts se ejecutan como parte de un flujo de trabajo, como Estudio de Azure Machine Learning, que pueden proporcionar información sobre cuándo y si se ejecutó el script. Pero se recomienda ejecutar pruebas de integración para asegurarse de que estos scripts se invocan de forma confiable.
Evaluación y prueba del modelo
Nota:
La evaluación y las pruebas de modelos se suelen usar indistintamente, pero deben considerarse procesos independientes que usan conjuntos de datos distintos. La evaluación es una actividad iterativa que se realiza durante la fase de desarrollo. Se centra en la experimentación para encontrar el mejor modelo con el nivel correcto de ajuste. Incluye ajustar hiperparámetros, configuraciones o características y, a continuación, evaluar el modelo en función de varias métricas. Después de identificar el mejor modelo, realice pruebas durante la implementación.
Las pruebas incluyen la comprobación del sistema completo, incluidos el modelo optimizado y los componentes que no son de IA, para comprobar que funcionan correctamente, integran bien y ofrecen los resultados esperados de acuerdo con los estándares de calidad. Evalúe un modelo in situ junto con otros componentes de la carga de trabajo. El proceso incluye el envío de solicitudes al modelo, la evaluación de sus respuestas y la toma de una decisión de ir o no ir en función de los datos de prueba. Aunque las pruebas no son negociables antes de la producción, se recomienda realizar también pruebas en producción mediante datos reales y datos sintéticos.
Uso de datos para evaluar y probar
Normalmente hay tres conjuntos de datos clave particionados de los datos de origen: entrenamiento, evaluación y pruebas.
Use el conjunto de datos de entrenamiento, que suele ser el subconjunto más grande, para entrenar el modelo. Use otro conjunto de datos para la evaluación para refinar el modelo a través de un proceso iterativo mediante la evaluación de diferentes permutaciones. Después de encontrar una permutación satisfactoria, pruebelo en el conjunto de datos de prueba.
Todos los conjuntos de datos deben contener datos de alta calidad para minimizar el ruido. Los casos de prueba en canalizaciones de ingesta y preprocesamiento de datos pueden servir como puntos de control de calidad. Una falta de ejemplos también puede atribuirse a datos de baja calidad. Use datos sintéticos para equilibrar y lograr la uniformidad en el conjunto de datos. Este enfoque es útil para entrenar modelos como modelos de detección de fraudes, donde las instancias reales de fraude son poco frecuentes, lo que dificulta obtener suficiente poder estadístico para predicciones confiables.
Para evitar sesgos en las predicciones, mantenga todos los conjuntos de datos distintos. No debe usar los datos de entrenamiento para la evaluación y no debe usar los datos de evaluación para las pruebas. Reserve datos únicos para la evaluación del modelo y las pruebas finales.
Uso de métricas de evaluación
Entrenar un modelo y seleccionar el adecuado para producción son procesos interdependientes. Debe elegir inicialmente un modelo, pero puede cambiar después de la experimentación y la evaluación.
La evaluación del modelo sigue como un bucle de experimentación que evalúa numerosas permutaciones de modelos, parámetros y características mediante métricas. Estas métricas proporcionan clasificaciones científicas, que debe comparar de forma iterativa en distintas versiones y configuraciones para determinar el mejor modelo. Para más información, consulte Métricas de evaluación.
Un enfoque similar se aplica a los modelos de IA generativos. Tener procesos que evalúen y cuantifiquen los resultados de la experiencia del usuario en función del rendimiento del modelo. Por ejemplo, la base es una de las métricas clave que cuantifica la alineación del modelo con los datos de origen. La relevancia es otra métrica importante que indica cómo es pertinente la respuesta a la consulta. Para ver métricas de ejemplo, consulte Métricas de evaluación y supervisión para la inteligencia artificial generativa.
Evalúe diferentes tipos de modelos mediante varias métricas. La importancia de cada métrica puede variar en función del escenario. Priorice las métricas en función del caso de uso. Por ejemplo, la equidad es fundamental en la inteligencia artificial responsable. A pesar de las buenas pruebas, los modelos todavía pueden mostrar sesgos injustos debido a los datos de origen sesgados. Los resultados pueden puntuar alto en relevancia, pero bajo en equidad. Integre las evaluaciones de equidad en el proceso para garantizar resultados no sesgados.
La inteligencia artificial generativa se integra con el código de orquestación, la lógica de enrutamiento y un índice para la generación aumentada de recuperación (RAG), lo que complica la evaluación. Aunque debe evaluar los modelos individualmente mediante métricas, también es importante evaluar otros componentes del sistema.
Probar el modelo
El ajuste preciso es básicamente probar porque modifica un modelo entrenado previamente para cambiar su comportamiento. Requiere comenzar con una línea base para comprender el rendimiento inicial del modelo. Después del ajuste, vuelva a evaluar el rendimiento del modelo para asegurarse de que cumple los estándares de calidad. Tenga en cuenta las siguientes métricas de evaluación comunes:
La base hace referencia a la alineación del modelo con los datos de origen. Un modelo con base genera respuestas coherentes con la realidad.
Relevancia indica cómo es pertinente la respuesta a una pregunta determinada. Una respuesta muy fundamentada podría carecer de relevancia si no aborda la pregunta directamente.
La similitud mide la similitud entre un texto de datos de origen y la respuesta generada. ¿El modelo ha usado palabras precisas? Una falta de gobernanza editorial puede reducir la puntuación de similitud.
La recuperación indica la eficacia de las consultas de índice. Evalúe cómo se alinean los datos de índice recuperados con la pregunta. Los datos irrelevantes de la búsqueda de índices reducen esta puntuación. Las puntuaciones de recuperación más altas indican una menor variabilidad porque dependen únicamente de las consultas de índice.
La fluidez se relaciona con el uso del vocabulario. Si el modelo se adhiere a una guía de estilo y presenta contenido en el formato adecuado, puede ser fluido incluso si carece de base o relevancia.
La coherencia evalúa si la voz del modelo fluye de forma natural y coherente. Evalúa si la conversación se siente como un intercambio genuino.
Prueba de hiperparámetros
Los parámetros del modelo dependen de decisiones de diseño específicas de la aplicación. Como parte del diseño de la aplicación, elija el modelo y los parámetros en función de los casos de uso de la carga de trabajo. El proceso de prueba tiene un bucle interno iterativo en el que los datos de entrenamiento se comparan con los datos de prueba para validar que el modelo está entrenando en el conjunto de datos previsto. Además, los parámetros se ajustan para que el modelo pueda realizar predicciones con un nivel de precisión aceptable.
Dilema. El bucle interno incluye los costos computacionales del entrenamiento del modelo y el costo de evaluarlo a través de pruebas. Debe factorizar el tiempo que requiere el entrenamiento y las pruebas del modelo en este bucle. Espere que el proceso de prueba tarde más tiempo que el proceso de entrenamiento. Puede realizar pruebas iniciales en un subconjunto de datos de entrenamiento para evaluar si el modelo genera resultados razonables. Puede escalar verticalmente esa prueba establecida en el conjunto de datos completo.
Prueba del punto de conexión de inferencia
Un punto de conexión de inferencia es la API REST que permite el acceso a los modelos para realizar predicciones. Es la interfaz donde se envían datos como parte de la solicitud y se obtiene una respuesta que contiene los resultados del modelo. El punto de conexión se hospeda en el proceso, que puede ser PaaS como Azure OpenAI Service o un servidor que no sea de inferencia de Microsoft, como NVIDIA Triton Inference Server, TorchServe y BentoML. En escenarios de PaaS, el proveedor de servicios controla las pruebas en cierta medida. Sin embargo, si hospeda el punto de conexión, tratarlo como cualquier otra API y probarlo exhaustivamente.
Aunque se prueba el modelo durante el entrenamiento y la evaluación, probar el punto de conexión de inferencia implica asegurarse de que los mecanismos alrededor de ese modelo, como el procesamiento de solicitudes, la creación de respuestas, el escalado y la coordinación entre instancias, funcionan correctamente. Cree un plan de prueba completo que abarque los casos de uso en función de sus requisitos. En esta sección se describen algunos casos de prueba de ejemplo y tipos de prueba que se deben tener en cuenta.
Consideraciones de prueba para los servidores de hospedaje de inferencia
Es importante comprender las características de carga del proceso y validar el rendimiento a través de las pruebas de carga. Estas acciones le ayudan a elegir tecnologías al diseñar o optimizar la arquitectura. Por ejemplo, los distintos servidores de inferencia tienen distintas características de rendimiento. El código consume ciclos de CPU y memoria a medida que aumenta el número de conexiones simultáneas. Comprenda cómo funcionan el código y los recursos de proceso en condiciones de carga estándar y máxima. Azure Load Testing es una buena opción para las pruebas de carga y puede generar una carga de gran volumen. Otras opciones de código abierto, como Apache JMeter, también son populares. Considere la posibilidad de invocar estas pruebas directamente desde su entorno. Por ejemplo, Machine Learning se integra bien con Load Testing.
Otra decisión clave es la elección de las funcionalidades de GPU. Muchos modelos requieren GPU para la inferencia eficaz debido a su diseño. Las pruebas de carga le ayudan a comprender los límites de rendimiento de una SKU de GPU y evita el sobreaprovisionamiento, que son consideraciones financieras importantes.
En el caso de las plataformas de hospedaje que no son PaaS, la seguridad es fundamental porque la API se expone públicamente. Es importante asegurarse de que el punto de conexión no se aproveche ni se ponga en peligro, lo que puede poner en peligro todo el sistema. Incluya este punto de conexión como parte de las pruebas de seguridad rutinarias junto con otros puntos de conexión públicos. Considere la posibilidad de realizar pruebas, como pruebas de penetración, en el sistema activo. Otro aspecto de la seguridad es la seguridad del contenido. El código puede llamar a las API especializadas que detectan contenido dañino en la carga de solicitud y respuesta. Se puede llamar a La seguridad del contenido de Azure AI desde las pruebas para facilitar las pruebas de seguridad de contenido.
Para obtener estrategias clave, consulte Recomendaciones para pruebas de seguridad.
Consideraciones de prueba para los puntos de conexión de inferencia de PaaS
El cliente debe esperar errores cuando envía solicitudes al punto de conexión de inferencia en el servicio PaaS. Los errores pueden producirse debido a la sobrecarga del sistema, a los back-ends que no responden y a otras condiciones de error. Realice el análisis del modo de error en el servicio y pruebe esos posibles errores. El análisis del modo de error es necesario para diseñar e implementar estrategias de mitigación en el código de cliente. Por ejemplo, las API de Azure OpenAI limitan las solicitudes devolviendo un código de respuesta de error HTTP 429. El cliente debe controlar ese error mediante mecanismos de reintento y disyuntores. Para más información, consulte Recomendaciones para realizar el análisis del modo de error.
Probar los servicios de PaaS puede ayudarle a seleccionar las SKU de servicio porque comprende los costos asociados, como el proceso de pago por uso o el proceso aprovisionado previamente. Use calculadoras de precios de Azure para evaluar las cargas de trabajo, la frecuencia y el uso de tokens para determinar las mejores opciones de facturación y proceso. Simulación de cargas de trabajo con SKU de bajo costo y justifica opciones de gama alta, como unidades de rendimiento aprovisionadas (PTU) para Azure OpenAI.
Las pruebas de carga no son tan relevantes para el proceso de pago por uso porque, con capacidad infinita, no se producen problemas. Las pruebas validan los límites y las cuotas. No se recomienda realizar pruebas de carga para el proceso de pago por uso porque es un gasto financiero significativo. Sin embargo, debe cargar la prueba para comprobar el rendimiento, que se mide en tokens por minuto o solicitudes por minuto. A diferencia de las API estándar que consideran métricas como el tamaño de la solicitud, este enfoque evalúa las cargas de trabajo basadas en tokens para determinar el uso. La clave es comprender el número de usuarios activos y medir el rendimiento en consecuencia. Para más información, consulte Medición del rendimiento.
Uso de controles de seguridad
Independientemente de si usa un servidor de inferencia o una opción PaaS, la seguridad es su responsabilidad. Con los puntos de conexión de API, es fundamental probar el jailbreak y los controles de seguridad de contenido. Asegúrese de que estos controles no se pueden omitir y que funcionan según lo previsto. Por ejemplo, enviar un elemento bloqueado conocido puede ayudarle a comprobar si los controles de seguridad están en su lugar y funcionan correctamente antes de la implementación. Considere la posibilidad de ejecutar estas pruebas según sea necesario o integrarlas en el proceso de versión.
Es importante probar si el sistema puede exponer accidentalmente información que no debería. Por ejemplo, el sistema no debe exponer información personal en la carga de respuesta. Además, pruebe para asegurarse de que un cliente no puede acceder a los puntos de conexión diseñados para otras identidades. Realice pruebas de seguridad para comprobar que la API, con sus mecanismos de autenticación y autorización, no filtra información confidencial y mantiene la segmentación de usuarios adecuada.
Prueba de los datos de puesta a tierra
El diseño de datos influye en la eficacia de un modelo generativo y los datos en tierra son el componente crítico. Los datos en tierra proporcionan más contexto para aumentar la relevancia de la respuesta. Se indexa antes de alcanzar el modelo. Se accede a este índice en tiempo real a medida que el usuario espera una respuesta.
Realice pruebas de un extremo a otro e incorpore ese proceso como parte del diseño de datos. Implemente un proceso de prueba que evalúe y cuantifica los resultados de la experiencia del cliente en función del rendimiento, orquestación, índice, preprocesamiento y datos de origen del modelo. Supervise y mida las métricas de calidad de forma iterativa. A continuación, se indican algunas consideraciones:
Pruebe exhaustivamente el procesamiento de datos mediante pruebas funcionales e de integración. Compruebe que los datos se cargan según lo previsto y que todos los datos están presentes.
Pruebe el esquema de índice para comprobar la compatibilidad con versiones anteriores. Debe probar cualquier cambio en un documento o campo para asegurarse de que la nueva versión puede seguir teniendo en cuenta las versiones anteriores de los datos.
Antes de indexar los datos, se somete a la preparación para reducir el ruido y el sesgo y habilitar la consulta eficaz. Este proceso incluye preprocesamiento, fragmentación y cálculo de incrustaciones, y cada paso guarda los datos en el contexto o los archivos del índice. Una canalización de orquestación, como los conjuntos de aptitudes proporcionados por Azure AI Search, lleva a cabo estos pasos. Debe probar el código de orquestación para asegurarse de que no se pierdan los pasos y que los datos procesados sean de alta calidad.
Las pruebas deben comprobar si hay datos antiguos, valores sintéticos, tablas vacías, actualización de datos y procesamiento en la versión más reciente. Si se producen errores de prueba, es posible que tenga que ajustar la consulta de búsqueda y el índice. Este proceso incluye el ajuste de filtros y otros elementos descritos anteriormente. Debe pensar en las pruebas como una actividad iterativa.
Los índices son complejos y el rendimiento de las consultas puede variar en función de la estructura del índice, lo que requiere una estimación de carga. Las pruebas de carga adecuadas pueden ayudar a determinar las distintas SKU para el almacenamiento, el proceso y otros recursos que están disponibles para satisfacer sus requisitos.
Debe probar todos los controles de seguridad. Por ejemplo, los datos se pueden dividir en documentos independientes. Cada partición tiene controles de acceso. Debe probar correctamente esos controles para proteger la confidencialidad.
Prueba del orquestador
Un componente clave de una aplicación RAG es el orquestador central. Este código coordina varias tareas relacionadas con la pregunta inicial del usuario. Las tareas de Orquestador suelen requerir una comprensión de la intención del usuario, una conexión al índice para buscar datos básicos y llamar al punto de conexión de inferencia. Si los agentes necesitan realizar tareas, como llamar a las API REST, este código controla esas tareas dentro del contexto.
Puede desarrollar código de orquestación en cualquier lenguaje o escribirlo desde cero. Sin embargo, se recomienda usar tecnologías como el flujo de mensajes en Azure AI Studio o los grafos Acíclicos dirigidos (DAG) de Apache Airflow para acelerar y simplificar el proceso de desarrollo. El flujo de mensajes proporciona una experiencia en tiempo de diseño. Úselo para modularizar tareas como unidades y conectar entradas y salidas de cada unidad, formando en última instancia el código de orquestación, que representa todo el proceso.
Aísle el código de orquestación. Desarrollarlo por separado e implementarlo como un microservicio con un punto de conexión en línea y la API REST para el acceso. Este enfoque garantiza la modularidad y la facilidad de implementación.
Desde una perspectiva de pruebas, trate este código como cualquier otro código y realice pruebas unitarias. Sin embargo, el aspecto más importante es su funcionalidad, como su lógica de enrutamiento, que puede validar a través de pruebas funcionales e de integración. Pruebe la ingeniería de avisos para asegurarse de que el código pueda detectar la intención del usuario y enrutar las llamadas correctamente. Hay varios marcos y bibliotecas para pruebas, como Scikit-learn, el módulo torch.testing de PyTorch, FairML para pruebas de sesgo y equidad, y Análisis de modelos de TensorFlow para la evaluación del modelo.
Además, realice pruebas en tiempo de ejecución, como pruebas en modo de error. Por ejemplo, pruebe posibles errores relacionados con las limitaciones del token.
Algunas pruebas en tiempo de ejecución pueden ayudarle a tomar una decisión. Ejecute pruebas de carga para comprender cómo se comporta este código bajo estrés y use los resultados para planear la capacidad. Dado que este código se coloca en un punto crucial de la arquitectura donde necesita llegar a otros servicios, puede ayudar a recopilar datos de telemetría de todas esas llamadas. Estos datos pueden proporcionar información sobre cuánto tiempo se dedica al procesamiento local frente a las llamadas de red y determinar el comportamiento de otros componentes, como la posible latencia. Las tecnologías como el flujo de mensajes tienen funcionalidades de telemetría integradas para facilitar este proceso. De lo contrario, incorpore telemetría en el código personalizado.
Nota:
Probar este código tiene implicaciones de costo. Por ejemplo, si usa Azure OpenAI para hospedar el punto de conexión de inferencia, las pruebas de esfuerzo son una práctica común que puede ayudarle a determinar los límites del sistema. Sin embargo, Azure OpenAI cobra por cada llamada, lo que puede hacer que las pruebas de esfuerzo extensas sean costosas. Una manera de optimizar los cargos es usar PTUs no utilizado de Azure OpenAI en un entorno de prueba. Como alternativa, puede simular el punto de conexión de inferencia.
Los problemas de seguridad se aplican tanto al código de orquestación como al modelo. Incluya pruebas para jailbreaking, donde el objetivo es interrumpir la seguridad del modelo. Los atacantes no interactúan directamente con el modelo. Interactúan primero con el código de orquestación. El código de orquestación recibe solicitudes de usuario y las analiza. Si el código de orquestación recibe una solicitud malintencionada, puede reenviar esa solicitud al modelo y poner en peligro el modelo.
La seguridad del contenido es otro aspecto importante. En una aplicación de bot de chat, el código de orquestación recibe texto de chat. En el código, considere la posibilidad de llamar a un servicio de seguridad de contenido. Envíe el mensaje del usuario y el contexto de puesta en tierra para su análisis y reciba una evaluación del riesgo. Prompt Shields es una API unificada que analiza las entradas del modelo de lenguaje grande y detecta ataques de petición de usuario y ataques de documentos, que son dos tipos comunes de entradas adversarios.
El control de seguridad y la autenticación son cruciales para un punto de conexión RESTful. Debe administrar la autenticación y asegurarse de realizar pruebas exhaustivas.
Impedir la descomposición del modelo
Un problema común para todos los modelos es cierto grado de degradación a lo largo del tiempo. Los cambios que son internos y externos a la carga de trabajo finalmente provocan una degradación en la calidad del modelo y sus salidas. La descomposición del modelo se produce de dos maneras:
El desfase de datos se produce cuando cambian los datos de entrada. La nueva entrada de datos hace que el modelo entrenado no sea actualizado. Por ejemplo, puede tener un modelo que prediga patrones de votación de un área geográfica determinada, como un distrito. Si el distrito se vuelve a dibujar y los datos demográficos de la población de ese distrito cambian, el modelo debe actualizarse para tener en cuenta los cambios.
El desfase de concepto se produce cuando las condiciones externas a la carga de trabajo y el modelo cambian de forma que las salidas del modelo ya no coincidan con la realidad. Por ejemplo, puede tener un modelo de previsión de ventas para un producto tecnológico. Si un competidor introduce inesperadamente un producto competidor más avanzado que llama la atención significativa del público, debe actualizar el modelo en función de cómo cambian las tendencias de los consumidores.
Cuando sea posible, use pruebas automatizadas para detectar y evaluar la descomposición del modelo en el ciclo de vida del modelo. Si el modelo predice valores discretos, puede crear pruebas para evaluar las predicciones con esos valores a lo largo del tiempo y medir la desviación entre los resultados esperados y reales. Complemente esta prueba con la supervisión para detectar el desfase a lo largo del tiempo comparando las estadísticas de resumen y las métricas de distancia.
Otro enfoque común para identificar el deterioro del modelo es los comentarios del usuario. Un ejemplo de comentarios de usuario es un mecanismo de respuesta de pulgar hacia arriba o hacia abajo. El seguimiento de los comentarios positivos frente a los negativos a lo largo del tiempo y la creación de una alerta cuando se cumple un umbral de comentarios negativos puede ayudarle a saber cuándo investigar la calidad del modelo.
Independientemente de las señales que use para identificar la descomposición del modelo, el equipo de operaciones que está alertado sobre posibles descomposición debe involucrar a un científico de datos para investigar la señal y determinar si se está produciendo la decaimiento y la causa principal.
Implementación de herramientas
Use el recopilador de datos de Azure Machine Learning para obtener el registro en tiempo real de datos de entrada y salida de modelos que se implementan en puntos de conexión en línea administrados o puntos de conexión en línea de Kubernetes. Machine Learning almacena los datos de inferencia registrados en Azure Blob Storage. A continuación, puede usar estos datos para la supervisión, depuración o auditoría de modelos, lo que proporciona observabilidad en el rendimiento de los modelos implementados. Si implementa un modelo fuera de Machine Learning o en un punto de conexión por lotes de Machine Learning, no puede aprovechar el recopilador de datos y necesita poner en marcha otro proceso de recopilación de datos.
Use la supervisión del modelo de Machine Learning para implementar la supervisión. Machine Learning adquiere señales de supervisión mediante la realización de cálculos estadísticos en datos de inferencia de producción transmitidos y datos de referencia. Los datos de referencia pueden ser datos históricos de entrenamiento, datos de validación o datos verídicos básicos. Por otro lado, los datos de inferencia de producción hacen referencia a los datos de entrada y salida del modelo recopilados en producción.
- Consulte Supervisión de modelos de Machine Learning para obtener información sobre las funcionalidades de supervisión de Machine Learning y las métricas que captura y analiza.
- Consulte los procedimientos recomendados para obtener más recomendaciones para la supervisión.