Cómo contribuí como probador a un sistema de aprendizaje automático: oportunidades, desafíos y aprendizajes

InfoQ Página de inicio Artículos Cómo contribuí como probador a un sistema de aprendizaje automático: oportunidades, desafíos y aprendizajes

16 de febrero de 2023 Lectura de 10 minutos

por

Shivani Gaba

revisado por

Ben Linders

Las pruebas se consideran un aspecto vital en el ciclo de vida del desarrollo de software (SDLC), por lo que los evaluadores participan para garantizar la calidad de la aplicación. Esto es válido para los sistemas de software convencionales, incluidas aplicaciones web, aplicaciones móviles, servicios web, etc.

Pero ¿alguna vez te has preguntado acerca de los sistemas basados ​​en aprendizaje automático? En esos casos, las pruebas pasan a un segundo plano. E incluso si se realizan algunas pruebas, las realizan principalmente los propios desarrolladores. El papel del evaluador no está claramente descrito en estas áreas.

Los evaluadores suelen tener dificultades para comprender los sistemas basados ​​en ML y explorar qué contribuciones podrían hacer en dichos proyectos. Entonces, en este artículo, compartiré mi viaje para garantizar la calidad de los sistemas basados ​​en ML como evaluador. Destacaré mis desafíos, aprendizajes y mi historia de éxito.

Como la mayoría de los evaluadores, he participado en las pruebas de sistemas convencionales que involucran aplicaciones web, aplicaciones nativas, backend, microservicios, etc. En dichos sistemas, los humanos (en su mayoría desarrolladores) toman información y escriben la lógica para producir un salida determinista. Como evaluadores, nuestro objetivo es verificar el resultado esperado con los requisitos especificados/implícitos.

Curiosamente, hace algunos años tuve la oportunidad de probar un sistema de recomendaciones basado en ML. Es bastante diferente de los sistemas convencionales, por lo que estaba emocionado y ansioso al mismo tiempo.

En los sistemas ML, se proporciona como entrada una gran cantidad de datos con patrones. Se alimenta a un modelo, que aprende lógica para descubrir estos patrones y predecir eventos futuros.

Para garantizar la calidad, es importante realizar pruebas.lógica aprendida . Entonces me pregunté, ¿cómo pruebo este proceso de aprendizaje y lalógica aprendida por el modelo? ¿Es siquiera posible probar esta lógica? ¿Es un modelo completamente una caja negra?

Teniendo muchas preguntas de este tipo en mente, tenía curiosidad por explorar y aprender. Estaba listo para un viaje en montaña rusa :)

En mi entusiasmo y curiosidad por contribuir rápidamente, hice lo que la mayoría de nosotros haría: buscar en Google las ideas de prueba. La mayoría de los recursos a los que me referí apuntaban a métricas de evaluación del modelo como precisión, recuperación, matriz de confusión, etc. Me parecían jergas. Sinceramente no los entendí. Pero llevé mis aprendizajes a medias a mis desarrolladores y me dijeron que ya estaban tomando en cuenta estas métricas.

Me di cuenta de que los desarrolladores conocían bien su dominio. Para crear un impacto como tester, necesitaba aportar las perspectivas que ellos pasaban por alto.

Nosotros, como evaluadores, tenemos la suerte de contar con un gran conjunto de habilidades para hacer las preguntas correctas, comprender el panorama general, pensar de manera innovadora, aplicar un conocimiento más profundo del producto, desafiar el status quo, etc. Si estas habilidades se aplican a Si probara los sistemas de aprendizaje automático, muchos de los problemas podrían evitarse.

También me di cuenta de que estaba intentando probar algo sin siquiera entender cómo funciona el sistema y cuáles son los componentes básicos. Pero, para probar mejor cualquier sistema, este debería ser el primer paso.

Discutí este enfoque con mis desarrolladores para colaborar para comprender el sistema en profundidad y aplicar mis habilidades de prueba en cada fase.

Los desarrolladores, que inicialmente se mostraron escépticos acerca de tener un probador a bordo, se entusiasmaron después de escuchar este plan y esperaban con ansias el valor que podía ofrecer.

Junto con mi equipo, entendí que en el aprendizaje automático se recopila, filtra y alimenta a un modelo un enorme conjunto de datos con ciertos patrones. El modelo identifica estos patrones y predice la probabilidad de eventos futuros.

Por ejemplo, nuestro proyecto era proporcionar recomendaciones de artículos para nuestros usuarios. Por lo tanto, se recopiló y alimentó al modelo una gran cantidad de datos, como interacciones con artículos, características de los usuarios y comportamiento del usuario en la plataforma. Luego, el modelo aprendió patrones en los datos y formó reglas para predecir las posibilidades futuras de que los usuarios interactúen con el artículo.

El proceso se divide en dos fases:

Fase A - Proceso de aprendizaje de los sistemas de aprendizaje automático

La fase de aprendizaje es donde el modelo aprende a identificar los patrones a partir de los datos y genera lógica para hacer predicciones futuras.

Hay dos tipos de procesos de aprendizaje: aprendizaje supervisado y aprendizaje no supervisado. Nuestro proyecto tenía aprendizaje supervisado, donde las muestras de resultados deseadas están disponibles en los propios datos de entrenamiento.

El proceso de aprendizaje detallado fue el siguiente:

Paso 1- Recopilación de datos : El entrenamiento de los sistemas ML depende en gran medida de los datos de entrada. Como regla general: “Cuantos más datos, mejor será la formación”. Pero en general hay una tendencia a no prestar atención acalidad de los datos.

De hecho, diría: "Cuanto mayor sea la calidad de los datos, mejor será la formación".

Entonces, como evaluadores, podemos ayudar a los desarrolladores a verificar/corregir todas las dimensiones de calidad como:

Tomemos un ejemplo sencillo. En nuestros datos, una columna llamada 'article_age' tenía valores negativos en ciertos casos. Esta columna refleja cuantas horas hace que se creó un artículo, y seguramente esto no debería ser negativo. Descubrimos que estos valores negativos se debían a un error en la conversión de zona horaria, por lo que lo solucionamos para corregir los datos.

Todas estas comprobaciones deben agregarse e integrarse en el proceso para validar la calidad de los datos.

Paso 2: construcción de características del modelo. : Una vez recopilados y refinados los datos, el siguiente paso es diseñar las características del modelo. Se forma una tabla con todos los datos para alimentar el modelo. Cada columna se denomina característica del modelo, excepto una columna, que es el valor objetivo. Todas las columnas tienen valores numéricos.

Por ejemplo, para nuestro sistema de recomendación de artículos, había funciones relacionadas con características específicas del usuario como edad, sexo, duración de la suscripción del usuario; características específicas del artículo, como el tiempo transcurrido desde su publicación, vistas/impresiones totales del artículo, clics totales en el artículo; características sobre la interacción de un usuario con artículos, como cuántas veces un usuario vio o hizo clic en el artículo, etc., y muchas más.

El valor objetivo reflejaba si el usuario interactuó con el artículo o no.

Para entrenar un modelo correctamente, es importante seleccionar las funciones correctas.

Como evaluador, ayudé a revisar todas las funciones, estandarizar las reglas que se les aplican y aplicar el conocimiento del producto para encontrar errores y mejorar las funciones. Algunos ejemplos:

Un papel importante que jugué fue también documentar las características con su descripción, reglas, etc.

Paso 3: entrenamiento y validación del modelo.: Una vez recopilados los datos y decididas las características, es hora de introducir estos datos en el modelo y entrenarlo.

Aquí es donde el modelo genera reglas para predecir valores objetivo futuros cuando se le proporcionarán nuevos datos.

No todos los datos deben usarse para entrenar el modelo. Pero los datos deben dividirse en datos de entrenamiento y datos de prueba. El modelo debe entrenarse con los datos de entrenamiento y la lógica de que el modelo aprendido debe verificarse con los datos de prueba utilizando diferentes métricas de evaluación del modelo como precisión, recuperación, rpAUC, etc.

También se podría realizar alguna evaluación analizando la importancia de cada característica del modelo (por ejemplo, utilizando valores SHAP). Los evaluadores podrían ayudar a evaluar el gráfico de importancia de las características y hacer las preguntas correctas.

Por ejemplo, en nuestro modelo que recomienda artículos, me di cuenta de que la predicción del modelo consideraba que la característica sobre la antigüedad del artículo era la menos importante. Me sorprendió y planteé esta cuestión porque si el modelo aprendiera que la edad es lo menos importante en los datos, entonces podría recomendar artículos antiguos y nuevos con la misma probabilidad. Esto podría resultar problemático para artículos relevantes en el tiempo, donde los artículos recién publicados son mucho más importantes que los artículos publicados anteriormente. Los desarrolladores descubrieron que ocurrió algún error durante el entrenamiento que resultó en este error, por lo que se volvió a entrenar el modelo.

FASE B - Despliegue del (nueva versión del) modelo

Ahora que el modelo está entrenado con los datos pasados, el siguiente paso es proporcionar nuevos datos invisibles para predecir la probabilidad de eventos futuros, lo que básicamente significa implementar el nuevo modelo en producción.

Para probar la implementación de un nuevo modelo, es importante comprender su configuración en producción.

Por ejemplo, en nuestro caso con los recomendadores de artículos, cuando un usuario solicitó recomendaciones, se realizó una solicitud de API para obtener predicciones del modelo. Además del resultado del modelo, también se aplicaron algunos filtros y reclasificadores. Los filtros se referían a reglas comerciales que eliminan algunos elementos predichos por el modelo. Los reclasificadores eran reglas comerciales que mezclaban algunos de los elementos predichos por el modelo.

En la configuración anterior, siempre que planificamos implementar el modelo recién entrenado para reemplazar el existente, se realizaron ciertas pruebas antes de reemplazarlo para confirmar que vale la pena reemplazarlo.

Realizamos un análisis comparativo entre el resultado final que los usuarios verían con la versión antigua y la nueva. Recopilamos los X elementos principales del resultado de ambas versiones y los comparamos con diferentes métricas, como cuántos elementos cambian/son iguales, cuál es el efecto de la antigüedad promedio del artículo, cuál es el efecto en la diversidad de elementos, etc.

Analizar cuidadosamente estos resultados nos ayudó a decidir si implementar el nuevo modelo o no. Por ejemplo, una vez que notamos que en el nuevo modelo, la edad promedio de los 10 artículos principales mostrados a los usuarios disminuyó en gran medida y esto fue un obstáculo para nuestra implementación porque no queríamos mostrar contenido antiguo a los usuarios cuando eran nuevos. Los artículos estaban disponibles.

Realizar estas pruebas siempre nos dio confianza en la calidad del nuevo modelo.

Además, cada vez que había un cambio en la regla del filtro o de los reclasificadores, probaba el cambio relevante y, a veces, incluso encontraba errores cruciales. Por ejemplo, queríamos agregar un filtro que debería mantener solo dos artículos que tengan el mismo autor y eliminar el resto de los artículos de ese autor. Pero noté que el filtro permitía tres artículos del mismo, en lugar de dos artículos. Los desarrolladores se dieron cuenta de que este error se introdujo debido a solicitudes poco claras y lo solucionaron. De hecho, esta pequeña solución cambió en gran medida los resultados para nuestros usuarios.

Por lo tanto, definitivamente es crucial realizar pruebas antes de implementar cada vez que se realicen cambios en la configuración.

Dicho esto, en última instancia, nuestros usuarios son nuestros evaluadores finales. Entonces, en lugar de simplemente lanzar el nuevo modelo, siempre hicimos una prueba A/B en la que el grupo de usuarios se divide en 2 grupos. Los usuarios del grupo A recibieron la versión anterior y los usuarios del grupo B recibieron la nueva versión. Después de dejar que la prueba se ejecutara durante un tiempo determinado (algunas semanas), recopilamos datos de ambos grupos y analizamos si el nuevo modelo/reclasificador/filtro realmente funcionó mejor en función de métricas como la proporción de clics, la distancia de desplazamiento, la interacción con los elementos, etc. Según los resultados, decidimos si vale la pena implementar la nueva versión para todos. Luego, estos datos se recopilan y se utilizan para volver a entrenar el nuevo modelo.

Al principio era muy escéptico acerca de mi papel en un proyecto de sistema ML.

Pero al reflexionar sobre mi viaje, he aprendido el gran impacto que pueden tener los evaluadores. He aprendido los errores que podrían ocurrir si no se realizan las pruebas. Aprendí cómo los evaluadores pueden colaborar estrechamente con los desarrolladores y encontrar problemas incluso con los sistemas ML.

En resumen, he aprendido que ya es hora de cambiar la percepción de que "los evaluadores no pueden contribuir a los sistemas de aprendizaje automático".

Gracias a Rahul Verma, Prabhu y Ben Linders por motivarme a escribir este artículo y revisarlo minuciosamente para ayudar a llevarlo a su forma actual.

Escribir para InfoQ ha abierto muchas puertas y aumentado las oportunidades profesionales. para mí. Pude interactuar profundamente con expertos y líderes de opinión para aprender más sobre los temas que cubrí. Y también puedo difundir mis conocimientos a la comunidad tecnológica en general y comprender cómo se utilizan las tecnologías en el mundo real.

¡Descubrí el programa de colaboradores de InfoQ a principios de este año y lo he disfrutado desde entonces! Además de brindarme una plataforma para compartir aprendizaje con una comunidad global de desarrolladores de software, el sistema de revisión entre pares de InfoQ ha mejorado significativamente mi escritura. . Si está buscando un lugar para compartir su experiencia en software, comience a contribuir a InfoQ.

Comencé a escribir noticias para la cola InfoQ .NET como una forma de mantenerme actualizado con la tecnología, pero saqué mucho más provecho de ello. Conocí gente conocedora, obtuve visibilidad global y mejoré mis habilidades de escritura..

Convertirme en editor de InfoQ fue una de las mejores decisiones de mi carrera . Me ha desafiado y me ha ayudado a crecer de muchas maneras. . Nos encantaría tener más gente.Unete a nuestro equipo.

InfoQ busca un editor en jefe a tiempo completo para unirse al equipo internacional y siempre remoto de C4Media. Únase a nosotros para cubrir las tecnologías más innovadoras de nuestro tiempo, colabore con los profesionales de software más brillantes del mundo y ayude a más de 1,6 millones de equipos de desarrollo a adoptar nuevas tecnologías y prácticas que superan los límites de lo que el software y los equipos pueden ofrecer.

Todos los martes se envía un resumen del contenido de la semana pasada en InfoQ. Únase a una comunidad de más de 250.000 desarrolladores senior. Ver un ejemplo

Protegemos su privacidad.

Debe registrar una cuenta InfoQ o iniciar sesión o iniciar sesión para publicar comentarios. Pero hay mucho más detrás de estar registrado.

Aproveche al máximo la experiencia InfoQ.

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p

por Charles Chan,

por Charles Chan,

Su mensaje está pendiente de moderación. Gracias por participar en la discusión.

Gracias por escribir el artículo y compartirlo con la comunidad. Describe los desafíos que enfrenta un evaluador cuando se enfrenta a una aparentemente "caja negra". Es fantástico ver que podemos razonar con un sistema basado en ML al comprender cada paso del proceso de capacitación.

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p