Durante un año y medio, he ocupado el cargo de desarrollador principal de ML en mi empresa. Seis meses administro un pequeño equipo. He adquirido experiencia que quiero compartir. Lo haré en el formato de una parte superior de errores y posibles dificultades.
¡Queremos una red neuronal!
Muchas personas han escuchado al menos algo sobre la inteligencia artificial y los logros de las redes neuronales. Algunas personas quieren usar redes neuronales en los negocios solo porque es popular. Por lo tanto, ha resuelto una pequeña tarea de análisis de texto y puede declarar con seguridad a todos que su empresa utiliza las tecnologías de inteligencia artificial más modernas.
Además, casi nadie comprende las fortalezas y debilidades de las redes neuronales. De hecho, debido al alto consumo de recursos, están lejos de ser siempre el modelo óptimo.
Muy a menudo, los algoritmos como refuerzo, vecinos más cercanos a k o svm pueden mostrar indicadores de mayor calidad para resolver problemas comerciales (si hablamos de las características clásicas de script -> valor) que las redes neuronales. Esto a pesar del hecho de que son mucho más ligeros.
Si el cliente le dice: "Necesitamos una red neuronal para resolver tal o cual problema", entonces lo más probable es que simplemente no sepa qué herramientas es mejor para resolver este problema. Pero le parece que se necesitan algunos algoritmos complicados aquí y lo único que le viene a la mente es una red neuronal.
Para que pueda resolver el problema a través de un modelo más ligero.
Parece obvio, pero de hecho, después de tal solicitud del cliente, puede pasar tiempo clasificando varias arquitecturas de redes neuronales antes de darse cuenta de que la tarea podría resolverse mucho más fácilmente.
Datos de la mañana, tarde estimeyta
Muy a menudo, se le pedirá que dé fechas límite para realizar experimentos / implementar soluciones en el producto. Además, como base para tales estimaciones solo puede proporcionar una descripción abstracta del problema. Por ejemplo: “Queremos una red neuronal que, según las imágenes médicas, diagnostique a una persona con una enfermedad. ¿Cuánto tiempo llevará? Las personas que no trabajaron con ML (y a veces trabajaron) tienen poca comprensión del concepto de experimentos. Muchos abordan el desarrollo de soluciones ML como desarrollo de software estándar. Pero estos son todos errores. El desarrollo de ML está más cerca de la ciencia que del desarrollo (especialmente en las etapas iniciales). La mayoría de las veces se requiere para el análisis de datos y experimentos. Y la gente rara vez entiende esto.
Si tiene suerte y tiene, por ejemplo, un gerente de proyecto experimentado, entonces no tendrá que lidiar con tales problemas. Él mismo explicará todo al cliente. Pero sucede al revés: cuando el gerente mismo comprende poco los detalles de ML, se inclina bajo el cliente y comienza a patearlo junto con él, exigiendo los plazos un par de días o una semana después de recibir una solicitud del cliente. A veces incluso antes de recibir datos. Entonces, lo más probable es que tenga que nombrar algunas fechas (bueno, o cambiar el lugar de trabajo, que también es una buena opción en esta situación). Pero tenga cuidado si decide hacer una estimación de la línea de tiempo sin suficiente información. Tómese el tiempo para experimentar con el margen.
Precisión del modelo en el experimento preliminar 99.99999%
Incluso si recibió altas métricas en los experimentos preliminares o al probar el prototipo, esta no es una razón para comunicarlos de inmediato al cliente. Pero todo lo que dices puede ser usado en tu contra.
Si obtiene valores altos de las estimaciones de calidad del modelo en experimentos preliminares, puede decirle al cliente que el problema tiene una solución única, pero no debe deleitarlo con números por adelantado que pueden no ser tan buenos para los nuevos datos. O puede llamar métricas, pero con la reserva obligatoria que no puede garantizar que en otras condiciones la calidad seguirá siendo la misma. Puede mejorar y empeorar. Siempre existe la opción de que estuvieras muy equivocado al realizar experimentos (por ejemplo, un generador escrito incorrectamente, y algunos de los datos se filtraron del entrenamiento a la prueba).
Alternativamente, puede arreglar diferentes pagos en el contrato para diferentes calidades finales de su modelo.
En términos generales, las personas suelen confiar en ejemplos concretos más que en números abstractos. Una pequeña demostración de su modelo le dará al cliente más confianza que las declaraciones sobre una precisión del 99%.
Si está resolviendo un problema, por ejemplo, de detección / clasificación utilizando técnicas neuronales convolucionales y es hora de escribir un informe sobre el éxito del equipo durante un período condicional, dedique los 30 minutos adicionales y tome un par de bellas imágenes: juegue con la visualización de filtros convolucionales a altos niveles de abstracción o capas ocultas completamente conectadas, haga mapas de calor de clases, etc.
No habrá problemas con los servidores.
En algún momento comencé a notar que el trabajo del modelo a menudo se basa en su tamaño. Por ejemplo, cuando necesita hacer un clasificador para 5 millones de clases, incluso los modelos más simples pueden consumir demasiados recursos. Entonces, naturalmente, surge la pregunta sobre la especificación del servidor, que el cliente puede descartar con algo como: "No habrá problemas con los servidores: elegiremos algo en los servicios en la nube".
El problema es que puede no representar la escala del modelo en absoluto. Por ejemplo, un conjunto de datos pesará 2 terabytes, y la matriz de peso del modelo entrenado es otros 500 gigabytes. Para usar dicho modelo, necesita 68-128 GB de RAM. Alquilar un automóvil de este tipo puede costarle a un cliente de varios miles a varias decenas de miles de dólares por mes (si se necesitan más GPU). Y aquí, no muchos aceptan pagar por tales servidores.