Campus
Diagrama de temas
-
-
Posibles desafíos en la implementación
Si bien su enfoque en este curso ha sido el desarrollo de modelos de aprendizaje automático para resolver problemas, es importante comprender que las soluciones de aprendizaje automático a menudo son solo una pequeña pieza de un entorno de producción. Por ejemplo, si está desarrollando un modelo de aprendizaje automático para aprobar automáticamente las líneas de crédito para los clientes bancarios, el modelo debe integrarse en el sitio web del banco y debe funcionar sin problemas con otras aplicaciones bancarias.
Los primeros desafíos a los que puede enfrentarse al mover la solución del desarrollo a la producción están en la implementación. La implementación es donde los profesionales de IA/AA entregan el modelo al personal de desarrollo de software para que lo integre con una solución de producción, que suele ser una aplicación o una serie de aplicaciones relacionadas.
Los desarrolladores e ingenieros de software a menudo necesitan reescribir partes del código del modelo para que quepa en la aplicación de destino. Esto puede resultar en algunos desafíos potenciales que son exclusivos de los proyectos de IA y AA, tales como:
- Errores de traducción de código que pueden alterar o invalidar los resultados generados por las soluciones de AA.
- Cambios en la lógica del modelo que pueden ser necesarios para que el modelo funcione y proporcione valor una vez movido a un entorno de producción.
- Modelos no implementados que, si nunca se ponen en producción, equivalen a la pérdida de los costos y el tiempo de recursos dedicados a crear los modelos y los beneficios que puedan producir.
- Período de tiempo de implementación debido a las complejidades para implementar modelos en producción.
Información adicional
Para obtener información adicional sobre las complejidades de las implementaciones del aprendizaje automático, consulte este sitio.
-
Errores en la traducción del código y mitigación
A medida que los desarrolladores reescriben el código para el entorno de producción, es posible que no entiendan las complejidades del modelo de datos, sus características o los resultados que la solución está diseñada para generar. Del mismo modo que escribir cualquier código puede generar errores o errores en el código, la codificación también puede introducir errores en el modelo o en la forma en que procesa los datos.
Los modelos deben probarse utilizando datos de producción, y los resultados de los datos de producción deben compararse y revisarse para detectar sesgos o errores. Si los datos de producción se pueden limpiar y procesar para producir conjuntos de datos que tienen las características requeridas por el procesamiento del modelo, pero el modelo genera resultados que muestran sesgos, son inesperados o son radicalmente diferentes de los que produjo con datos de diseño, podría ser un indicador de errores de traducción de código.
Para mitigar los errores de traducción de código, los profesionales de IA/AA que han desarrollado el modelo deben proporcionar documentación, información y aclaraciones al equipo de desarrollo de software durante todo el proceso de implementación. Una vez que el modelo está en línea en el entorno de producción, se debe probar para comprobar que se ha traducido correctamente a producción y que funciona según lo previsto.
-
Cambios en la lógica del modelo y mitigación
Es posible que algunos marcos de aprendizaje automático y profundo que se usaron en el desarrollo del modelo no se puedan usar en producción debido al software, la seguridad u otras limitaciones. En este caso, es posible que los modelos deban rediseñarse o simplificarse para que funcionen de forma aceptable en el entorno de producción.
Este problema puede presentarse repetidamente si un modelo se crea para un propósito dedicado y se vende a varias organizaciones para su uso. Por ejemplo, un modelo para aprobar solicitudes de tarjetas de crédito basado en factores de crédito podría venderse a muchas instituciones financieras diferentes, y tendrá que integrarse en diferentes entornos de producción para cada una.
Dado que estos tipos de problemas pueden tener ramificaciones legales y éticas graves y costosas, es importante tener un equipo de supervisión que incluya a personas familiarizadas con las leyes y regulaciones, así como la información del dominio del problema. Estas personas deben ser capaces de identificar cualquier área de preocupación con respecto a los datos de entrada, los pasos de preprocesamiento de datos, los pasos del modelo y los resultados.
El equipo de soluciones de AA tendrá que ajustar los datos, las características o la forma en que el modelo genera resultados para abordar estos problemas en el entorno de producción y asegurarse de que la solución cumpla todos los requisitos legales, reglamentarios y éticos.
-
Mitigación de modelos sin implementar
Las organizaciones que invierten en IA y crean modelos de aprendizaje automático pueden encontrar que es mucho más fácil crear modelos que implementarlos en el entorno de producción debido a las complejidades de la implementación. Esto es especialmente cierto si la organización tiene un pequeño equipo de TI e ingeniería de software, que puede no tener los recursos para llevar a cabo un gran número de proyectos de implementación de soluciones de AA y el mantenimiento de esas soluciones una vez que están en producción.
Si los modelos se diseñan, completan y aprueban, pero no se implementan, podría ser un indicador de que la organización necesita más recursos para implementar los modelos que ha creado.
Si este es el caso, las organizaciones deben considerar la contratación de personal de desarrollo de software adicional o temporal para facilitar la implementación de modelos o la implementación externa a una agencia de consultoría. Ambas soluciones agregarán costos a la implementación del modelo.
-
Desafíos y mitigación del plazo de implementación
La implementación de un modelo en producción es compleja y lleva tiempo. El tamaño y la carga de trabajo de los equipos de ingeniería y desarrollo de software, su familiaridad con la implementación de modelos de aprendizaje automático y la complejidad del modelo y sus canalizaciones de datos influyen en el tiempo que tarda la implementación. La implementación de un modelo en la producción puede tardar días, semanas o meses.
Es posible que no se pueda reducir el tiempo que se tarda en implementar una solución de aprendizaje automático, aunque la contratación de consultores externos o ingenieros de software puede ayudar. Además, una buena comunicación es clave para garantizar que todos, desde los miembros del equipo del proyecto hasta los patrocinadores del proyecto, los usuarios y los ejecutivos, se mantengan informados sobre el estado actual de la implementación, las próximas tareas de implementación y las fechas de vencimiento.
-
Diseño de canalización de la producción
Las soluciones de AA requieren datos continuamente. Los datos se pueden proporcionar en tiempo real, como cuando alguien solicita una aprobación de crédito instantánea o cuando un sistema de clasificación de imágenes comprueba los productos que salen de una línea de montaje. Es posible que otras soluciones de AA no necesiten datos en tiempo real, pero normalmente necesitan un flujo constante de nuevos datos para las operaciones. Por ejemplo, una solución diseñada para recomendar la compra y venta de acciones para una institución financiera puede procesar las operaciones del día anterior cada noche para generar nuevas recomendaciones al comienzo del siguiente día de negociación.
En todos estos casos, la solución de AA necesita una canalización, un flujo de trabajo automatizado diseñado para alimentar los datos de entrada en la solución de AA para su procesamiento, de modo que la solución pueda generar las estimaciones necesarias. Recuerde que, en el momento de la implementación, la canalización es un componente de una solución de AA que aún no existe. Los modelos que se hayan creado y entrenado habrán utilizado datos de ejemplo. Mover el modelo a producción requiere el uso de datos reales, y la canalización debe hacer frente a muchos de los mismos desafíos y realizar pasos de procesamiento similares con los nuevos datos, incluidos:
- Conectarse a orígenes de datos para extraer datos para su uso en la solución de AA.
- Limpieza de los datos para que estén listos para su procesamiento.
- Realizar los pasos de preprocesamiento necesarios para transformar y dar forma a los datos para cumplir los requisitos de la solución de AA.
- Conectarse a los datos e introducir los datos para que la solución los procese.
Figura 1. Procesamiento de datos a lo largo de una canalización. 
Uno de los mayores desafíos en la creación de una canalización para una solución de AA que se mueve a producción puede ser encontrar orígenes de datos adecuados, ya que los datos disponibles para la producción pueden ser muy diferentes de los utilizados para crear el modelo. Esto puede ser especialmente complicado si el modelo de AA se está adaptando para un nuevo rol o una organización diferente. En ese caso, después de que se identifiquen los orígenes de datos y se preparen los datos para la solución, se deben revisar los resultados generados para garantizar la exactitud, la precisión y los estándares éticos para confirmar que la solución está produciendo resultados de alta calidad que cumplen los requisitos. Si no es así, es posible que los profesionales de IA deban cambiar la forma en que se preparan los datos de entrada, ajustar las características de datos utilizadas por la solución o realizar otros ajustes en la solución en función de los datos disponibles.
Implementación en aplicaciones confidenciales
En algunos escenarios, las canalizaciones de producción se deben implementar en sistemas que funcionan con datos confidenciales o en sistemas que funcionan con equipos potencialmente peligrosos. Es importante que la infraestructura de canalización en estos escenarios esté diseñada de manera que sea resistente a varios errores. Por ejemplo, supongamos que diseñó una IA que detecta inmediatamente los derrames de materiales peligrosos en un almacén y hace sonar una alarma para que el personal pueda evacuar lo más rápido posible. Una canalización mal diseñada tendría el software de IA real ubicado fuera del sitio, lo que transmitiría su información de detección a través de Internet. Cualquier retraso o inestabilidad en la red (por ejemplo, si se está ejecutando a través de Wi-Fi) podría costar un tiempo precioso y conducir a un daño mayor que si el software de IA se instalara en o cerca del almacén. También desea diseñar la canalización para que el sistema de IA se pueda probar y actualizar de forma regular para que pueda verificar que realmente funciona.
-
Código de pegamento: conexión de modelos a aplicaciones
Una vez diseñada la canalización, debe conectarse a la solución general. Es probable que cualquier solución de AA se conecte a otras aplicaciones para su uso. Estas aplicaciones pueden proporcionar datos para la solución, ser un componente de la canalización de la solución o tomar los resultados como entrada para otras actividades de procesamiento. La solución debe estar conectada a estas otras aplicaciones para ofrecer el valor prometido. Además, estas aplicaciones se pueden implementar en servidores locales o en implementaciones en la nube, y se deben tener en cuenta los tipos de conexiones y protocolos necesarios, así como la seguridad y la accesibilidad, para conectar correctamente las aplicaciones al entorno informático donde se implementa la solución de AA.
La forma en que estas aplicaciones están conectadas es motivo de cierta preocupación. Algunos pueden estar conectados a través de API, mientras que otros pueden usar servicios web o guardar archivos intermedios a los que se debe acceder o importar en componentes integrados. El código que conecta estas aplicaciones a menudo se denomina código de pegamento. Dado que gran parte de este código de pegamento se crea en el momento de la implementación por los desarrolladores que realizan la integración, es posible que no pase por los rigores de la planificación y las pruebas de software. El código de pegamento de un desarrollador para integrar una aplicación puede parecer completamente diferente del código de pegamento de un segundo desarrollador utilizado para integrar una aplicación diferente. A medida que una solución madura y se extiende con el tiempo, esto puede conducir a una gran cantidad de código de pegamento inconexo que consta de scripts, combinaciones y otros procesos intermedios.
Figura 1. Pegar código que conecta un modelo de clúster a una aplicación móvil que usa ese modelo para recomendar productos a los clientes. 
Como puede imaginar, el código de pegamento, especialmente en implementaciones complejas, puede ser muy difícil de mantener y solucionar problemas, un proceso que puede ser frustrante y propenso a errores. Incluso el cambio aparentemente inocuo puede causar problemas. Por ejemplo, si un desarrollador escribe código de pegamento para almacenar un archivo intermediario en una carpeta del servidor y los permisos de acceso de la carpeta cambian o el servidor se retira, la integración se interrumpirá.
También es posible que el código de pegamento pueda infringir los requisitos de control de datos. Por ejemplo, si el código de pegamento exporta PII a un archivo de texto y lo almacena en una carpeta temporal para que la recoja la aplicación integrada, los datos son vulnerables mientras se almacenan en la carpeta temporal, especialmente si esa carpeta no está cifrada.
Todo el código relacionado con la integración debe ser documentado por los desarrolladores y revisado por el jefe de proyecto y el equipo de supervisión para asegurarse de que el código:
- Es sólido.
- Es bien entendido por los ingenieros de software y desarrolladores que necesitan para admitir la solución.
- Cumple con todos los requisitos de seguridad, reglamentarios y éticos de la solución.
-
Prueba de software
Las pruebas de software son una parte crítica para garantizar la calidad de cualquier solución basada en código, aprendizaje automático o de otro tipo. El objetivo de las pruebas es determinar si el código hace lo que está diseñado para hacer. Cada parte del software, comenzando con funciones, subrutinas, métodos y propiedades, debe ser probada. A continuación, cuando esos componentes se juntan en la base de código más grande para proporcionar un conjunto más amplio de funcionalidad para la solución, se debe probar el componente u objeto resultante. Cuando la solución se integra con otras aplicaciones, se debe probar la comunicación y el intercambio de información, y luego se debe probar toda la solución para asegurarse de que funciona correctamente. Algunas pruebas son realizadas por desarrolladores que escriben el código, mientras que otras son realizadas por probadores dedicados de control de calidad (QA), e incluso otras pueden ser realizadas por usuarios del software.
El software generalmente pasa por varias etapas de prueba. Las tres primeras etapas enumeradas aquí se consideran pruebas de verificación de software.
- Pruebas unitarias. Alguien comprueba la funcionalidad del fragmento de código más pequeño que se puede aislar lógicamente en un sistema. En la mayoría de los lenguajes de programación, se trata de una función, subrutina, método o propiedad. Las pruebas unitarias normalmente las controla el desarrollador que escribió el código, como parte de las pruebas de control de calidad iniciales que se realizan antes de que el código se ingrese como completo y listo para la integración con la base de código más grande. Los desarrolladores usan marcos de pruebas unitarias o herramientas para admitir la escritura y ejecución de pruebas unitarias y para notificar los resultados de las pruebas.
- Pruebas de integración. Los componentes independientes se prueban como un grupo para ver si funcionan juntos según lo diseñado. En esta etapa, los desarrolladores buscan problemas con los componentes que interactúan entre sí y se pasan datos entre sí.
- Pruebas del sistema. Los desarrolladores prueban la aplicación completa, con todos los componentes integrados, para verificar que se desempeñe para cumplir con todos los requisitos principales definidos para el software y que su rendimiento esté optimizado.
- Pruebas de aceptación. A veces llamada prueba funcional, esta es la etapa final del ciclo de prueba de control de calidad. Evalúa si el software cumple los requisitos y si está listo para su lanzamiento a usuarios y clientes. Esta prueba se puede llevar a cabo con un grupo selecto de probadores utilizando una versión beta no completa, pero funcional del software. Al lanzar una versión beta, los equipos de desarrollo aumentan drásticamente el uso del software para ayudar a encontrar cualquier error todavía presente en el software.
En las últimas etapas de la verificación de software y las pruebas de aceptación, los equipos de pruebas de software pueden usar software y código de seguimiento de errores para escribir pruebas, errores de registro, correcciones y versiones actualizadas de software.
En algunos casos, se deben crear componentes falsos para proporcionar funcionalidad para las pruebas. Estos componentes suplentes permiten probar el software que está completo, incluso cuando los componentes a los que se conecta el software no lo están.
Terminología de pruebas de software
Las pruebas de control de calidad de software tienen su propio lenguaje y terminología únicos. Algunos términos notables se describen en la tabla siguiente.
Término
Definición
Caso de prueba
Una sola prueba de un fragmento de código discreto.
Conjunto de pruebas
Un grupo de casos de prueba que pertenecen juntos para probar alguna funcionalidad.
Accesorio de prueba
El entorno (configuración de estado inicial y desmontaje de estado final) del estado del sistema o aplicación antes y después de la ejecución de la prueba.
prueba de integración
Cualquier prueba que incluya componentes fuera del componente de origen.
prueba de interacción
Cualquier prueba que compruebe cómo funcionan juntos los objetos.
Prueba de estado
Una prueba de los resultados producidos por una operación de código.
Falso
Objeto suplente que se utiliza en lugar de un objeto real. Por ejemplo, si una aplicación debe comunicarse con una base de datos para obtener datos, es posible que no se escriba el objeto de acceso a la base de datos, por lo que es posible que deba utilizar un objeto falso, como un objeto de acceso de hoja de cálculo.
Talón
Objeto falso que proporciona una dependencia específica requerida por la prueba.
Simulacro
Una falsificación utilizada para comprobar los resultados de una prueba.
-
Importancia de las pruebas
Antes de continuar, vale la pena discutir la importancia de las pruebas en general y las pruebas unitarias en particular. Las pruebas unitarias ayudan a los desarrolladores a buscar y corregir problemas inmediatamente mediante el recurso. El desarrollador que escribió el código y que está más familiarizado con él realiza estas pruebas sin utilizar tiempo y recursos adicionales para registrar el problema. Además, no es necesario que un nuevo desarrollador aprenda el código para resolver el problema. Las pruebas unitarias sólidas como parte de la verificación de software tienen las siguientes ventajas:
- El desarrollo de software se vuelve ágil. Es más fácil agregar código funcional de forma modular.
- Mejora la calidad del código. Este es un efecto secundario simple pero efectivo de comprobar el propio trabajo.
- Se reduce el impacto de los errores. Los errores de software encontrados durante las pruebas unitarias están contenidos en el fragmento de código discreto que se está probando y se solucionan antes de que el código se integre con la base de código más grande, donde el problema puede ser más difícil de aislar.
- La actualización del código se vuelve más fácil. Es mucho más fácil actualizar el código con confianza cuando ese código se somete a pruebas unitarias porque cada unidad de código se ha comprobado antes de que se integre con la base de código más grande.
- Se crea documentación. Los datos de pruebas unitarias se almacenan normalmente con cada módulo, lo que básicamente amplía la documentación de los componentes de software individuales y facilita a otros desarrolladores la información sobre cómo funcionan esos componentes.
- Se simplifica la verificación del software a posteriori. Las pruebas unitarias exhaustivas encuentran y corrigen los errores de forma temprana, lo que reduce la necesidad de abordarlos en etapas posteriores de las pruebas de verificación de software.
- Se mejora el diseño del software. Los desarrolladores que están familiarizados con las pruebas unitarias y las usan a menudo aprenden a pensar en diseñar su código para que se mantenga y a integrarse bien con otro código.
- Se reducen los costos. Cada vez que los errores se solucionan rápidamente y se mejora la calidad del código, los costos de todo el proyecto de desarrollo se reducen.
-
Pruebas de modelos durante la implementación y la producción
Cualquier código implementado debe probarse para asegurarse de que funcione según sea necesario, pero los posibles desafíos relacionados con los modelos de AA y sus canalizaciones a menudo requieren que realice pruebas adicionales durante la implementación y después de que estén en producción. Estas pruebas adicionales incluyen:
- Pruebas de configuración. Como se mencionó anteriormente, los cambios de configuración en los modelos de AA pueden tener un gran impacto en los resultados, por lo que las pruebas de configuración se deben realizar como pruebas unitarias cada vez que se realizan cambios de configuración. Estas pruebas deben garantizar que el modelo funcione y genere resultados según lo previsto, y que cumpla los requisitos establecidos para el modelo, sus datos y su uso.
- Pruebas de datos de entrada. Las canalizaciones de soluciones de AA a menudo incluyen la entrada continua de datos. El modelo no debe generar estimaciones y resultados sin datos válidos. Debe probar para ver qué sucede si los datos de baja calidad entran en la canalización. ¿Qué sucede si faltan valores o si se encuentran datos inesperados? Dependiendo del diseño de la solución, el modelo debe ser capaz de detectar y generar errores y notificar a las partes responsables.
- Pruebas de características. Los modelos de AA se basan en gran medida en las características de los datos, por lo que se debe usar un conjunto de datos aleatorio para probar tanto la selección de características como la ingeniería. Esto ayudará a probar qué tan bien se puede normalizar la solución con un conjunto determinado de datos y qué tan bien se escalará la solución.
- Pruebas diferenciales. Cada vez que se actualiza el modelo de AA, se deben ejecutar pruebas tanto en el nuevo modelo como en el modelo existente para ver la diferencia en los resultados. El equipo del proyecto debe usar estos resultados para comprobar que el nuevo modelo esté funcionando a la altura de los requisitos y logre las optimizaciones esperadas en el nuevo modelo. Las pruebas diferenciales a menudo se pueden realizar con implementaciones de instantáneas, donde el modelo se implementa en un entorno de producción que no se hace público o no está conectado públicamente. Una implementación de instantáneas permite al equipo del proyecto probar modelos nuevos y antiguos antes de cambiar al nuevo modelo para su uso completo en producción.
-
Descripción de las pruebas de modelos para aplicaciones
-
Campus
