Mi nombre es Alexandra Tsareva. Mis colegas y yo estamos trabajando en proyectos en el campo de la visión por computadora en el Machine Learning Center de Jet Infosystems. Me gustaría compartir nuestra experiencia en el desarrollo e implementación de proyectos en el campo de la visión por computadora.
En este artículo hablaré sobre cómo el proceso de trabajo de un datasetist en un proyecto no se ve desde un punto de vista "espiritual" y, de hecho, datasignist, sino más desde un punto de vista organizacional. Y espero que a este post le sigan algunos más y pueda escribir una pequeña serie.
Señalaré dos puntos importantes de inmediato:
- Estos pasos se aplican a casi cualquier proyecto de conjunto de datos. Pero algunos momentos son causados por el efecto exagerado en torno a CV, algo de gloria de la "bala de plata" en la visión por computadora y el deseo del cliente "de tenerlo con la red neuronal".
- , , — , - . , , ( , ..) , — - .
: ?
Cuando un cliente decide que necesita conjuntos de datos y algún tipo de inteligencia artificial que lo ayude, en primer lugar, debe comprender qué problema va a resolver. En esta etapa, un datasigner actúa como un “psicoanalista” de datos y pregunta en detalle sobre los datos, las limitaciones externas desde un punto de vista empresarial y los problemas que a uno le gustaría resolver en un mundo ideal. El cliente a menudo ya sabe todo sobre la tarea futura; solo necesita ayudarlo a comprender y formalizar este conocimiento (comprender su mundo de datos internos y, a veces, y aceptar sus peculiaridades).
Por supuesto, la visión por computadora es un área muy interesante, siempre hay algo que contar y hacer con las manos. Pero todo esto es bastante costoso, tanto en términos de horas de desarrollo como en el costo de los especialistas y en el equipo requerido para ellos. No podemos evitar preguntarnos si la solución óptima al problema realmente requiere CV. ¿Quizás existen otras herramientas de aprendizaje automático que son más adecuadas y pueden resolver mejor el problema con un tiempo de desarrollo más corto y una mayor precisión?
Te mostraré la idea con un ejemplo sencillo. Un minorista quería implementar el reconocimiento de imágenes de CCTV para realizar un seguimiento de cuántas personas hacen cola en la caja. Parecería una tarea obvia - hay un archivo de video, incluso hay redes neuronales pre-entrenadas - "contadores". Firma el horario, hazlo.
Pero de una conversación con el minorista, el datasinter se entera de que la tarea no está relacionada con la carga del cajero en un momento particular en el tiempo. La tarea global no es llamar a empleados innecesarios para reemplazarlos, sino al mismo tiempo evitar colas. El minorista tiene una gran base de datos que muestra la cantidad de clientes que visitaron la tienda (si vio a los vendedores inclinados sobre los marcos a la salida de la tienda, vio la implementación más simple de dicho contador), datos sobre compras en la caja ... Y, de hecho, la tarea no es cuente a las personas en la cola, prediga la carga de trabajo de los cajeros y optimice su horario de trabajo.
Por supuesto, puede resolverlo contando personas en videos archivados. Pero los datos tabulares generalmente se almacenan más profundamente y son más fáciles de procesar. Es justo ofrecer una alternativa; quizás el cliente solo haya escuchado que CV es genial.
Entonces, en la primera etapa, nos aseguramos de que el problema que el cliente desea resolver sea realmente un problema de visión artificial y que esta tecnología sea la más adecuada para resolverlo.
Paso dos: ¿cómo resolveremos el problema de CV y evaluaremos el éxito de la solución?
La segunda etapa es la formulación de un problema matemático, la elección de métricas.
¿Hay alguna solución conocida, redes neuronales, que pueda resolver este problema? ¿Quizás incluso un producto en caja? Si la tarea es nueva, ¿tal vez hay publicaciones en las que podamos confiar y evaluar preliminarmente la calidad alcanzable?
En esta etapa, discutimos las métricas para resolver el problema desde el punto de vista de nuestro trabajo, como científicos de datos, y desde el punto de vista del cliente, en el contexto de la resolución de un problema empresarial.
El trabajo con datos a veces comienza al mismo tiempo que se acuerda la solución y las métricas, pero por conveniencia lo separaremos en un paso separado.
Paso tres: explore y comprenda nuestros datos
Es muy importante evaluar si tenemos suficientes datos para resolver la tarea en cuestión. Obviamente, los pequeños conjuntos de datos serán rechazados incluso en la etapa de configuración, pero en el proceso de conocer el problema comercial pueden surgir nuevos matices. Las situaciones son diferentes: podemos tener 1000 imágenes, de las cuales solo 10 pertenecen a la clase requerida, y ninguna tecnología secreta de visión artificial nos ayudará.
Tal vez entendamos de inmediato que no es difícil mejorar el conjunto de datos existente: pedir a los empleados que fotografíen más objetos de los que se filman habitualmente, que recopilen algunos datos adicionales mediante la subcontratación o conjuntos de datos abiertos.
En la misma etapa, se observan inconvenientes en términos de aprendizaje del modelo futuro, y muchos de ellos pueden devolvernos al paso en el que volvemos a discutir la resolución fundamental del problema. El ejemplo más común es la baja diversidad de datos o la subrepresentación de una de las clases. Es posible competir para aumentar la diversidad utilizando varias técnicas de aumento, pero esto no siempre nos permite hacer un modelo listo para el mundo real. Sin embargo, si nos parece que podemos hacer frente a las dificultades en los datos, el cuarto paso viene al rescate.
Paso cuatro: desarrollar un modelo prototipo
En esta etapa, no estamos hablando de un modelo listo para implementar, sino de un prototipo que nos responderá a nosotros y al cliente cuando se nos pregunte si vale la pena seguir trabajando en esta dirección, si el posible resultado cumple con las expectativas (las nuestras y, lo más importante, las del cliente). Después de trabajar con los datos, comenzamos a desarrollar un modelo piloto y evaluamos su calidad. Algunas cosas obvias: en esta etapa, el modelo se valida con un conjunto de datos diferido. Las dos opciones principales son las imágenes que dejamos a un lado, o las imágenes que nuestro cliente escribió mientras estábamos trabajando en el proyecto.
El plazo de trabajo del proyecto en la fase piloto para el desarrollo de un prototipo es de al menos un mes. Durante este tiempo, en la mayoría de los casos, el cliente puede acumular datos para realizar pruebas. Esta es una buena prueba para que los registradores de datos vean qué tan serios son para resolver el problema: si tomamos datos que nunca hemos visto, verificamos cómo nuestro modelo puede generalizar y si se ajusta a las respuestas al conjunto de datos de validación (que, por supuesto, también se difiere. pero es demasiado tarde para descubrir que todo ha cambiado en el mundo real desde entonces, sería una lástima).
Por otro lado, en el momento de recibir el conjunto de datos diferidos, podemos averiguar en qué medida los objetos que entran en el ámbito de interés del cliente del proyecto (y esto también se aplica a los clientes internos) son estables y corresponden a la muestra utilizada para la formación y validación del modelo. Después de todo, tal situación es bastante posible: la visión por computadora se está implementando como un gran proyecto para digitalizar todo y a todos, y en la misma etapa ocurren cambios importantes en la fuente de datos (por ejemplo, el transportador principal se ha reconstruido por completo y las imágenes que provienen de él han cambiado fundamentalmente).
El análisis de los resultados del piloto ayuda a decidir el futuro del proyecto. Puede resultar que el cliente tenga requisitos muy altos para el nivel de precisión: por ejemplo, el 99% de las respuestas deben ser correctas, y en los pasos anteriores nos pareció que esto era fundamentalmente alcanzable. Pero en el piloto, logramos una precisión del 93% y, por supuesto, no podemos prometer una ganancia garantizada del 6%. Es lógico discutir opciones para el desarrollo del proyecto con los resultados piloto disponibles con el cliente - acerca de recopilar datos adicionales, reducir la métrica requerida o incluso congelar el proyecto hasta nuevos avances en la esfera de CV.
Los primeros cuatro pasos se pueden mostrar con el siguiente diagrama:
Llevan mucho menos tiempo que el desarrollo real. Sin embargo, se establece el éxito futuro del proyecto: en qué medida cumplirá con las expectativas del cliente y realmente resolverá su problema.
Paso cinco: haz el resto;)
Todo el proyecto, desde la confirmación del concepto hasta la solución implementada, se verá así:
El plan y los términos del desarrollo del proyecto son aproximados. En los proyectos reales siempre surgen distintos matices, ya que los datos son diferentes para todos, se recogen a distintas velocidades, y la etapa de introducción de la visión por computador dentro de la propia empresa puede ser muy diferente según con qué se planifique la integración, quién la esté realizando, etc. .PAGS. Después de todo, una cosa es cuando se trata de instalar un sistema de identificación para los empleados que ingresan a la oficina basado en grabaciones de cámaras de vigilancia durante un largo período de tiempo: podemos comenzar a trabajar con ellos de inmediato. Es otra cuestión si tenemos un número insignificante de imágenes de ejemplo con las que haremos una prueba de concepto; comprobaremos si el problema se puede resolver en principio y cuánto tiempo llevará recopilar un conjunto de datos completo, no lo sabemos.
Por lo tanto, la diapositiva muestra cronogramas muy aproximados para un proyecto abstracto en el vacío, pero creo que es útil saber que el ciclo completo desde la prueba de concepto hasta la implementación y la implementación toma alrededor de un año. Estos términos pueden aumentar para tareas complejas y disminuir en caso de que sea preferible la solución "lista para usar" o si el problema es bien conocido y no requiere trabajo de investigación.