Reducir en 96% el costo de etiquetado de imágenes: un caso real de ingeniería que, incluso en un entorno con poco presupuesto y tiempo, reemplazó el trabajo repetitivo humano por un pipeline de software para implementar una función clave.
Resumen clave
• Identificación del problema: no existía un modelo adecuado para reconocer y registrar automáticamente muñecos de personajes famosos, y el etiquetado manual tenía límites claros en costo, velocidad y escalabilidad.
• Enfoque: en vez de preguntarse “¿debemos asignar más personas?”, se descompuso el proceso de juicio humano en un sistema y se convirtió en un pipeline.
Diseño de un pipeline de automatización de 4 etapas
1. Filtrado con CLIP – eliminación masiva de imágenes sin sentido para reducir el costo del LLM
2. Detección con YOLO – recorte solo del objeto principal para reducir el alcance del análisis
3. Etiquetado con LVM – uso de un VLM de alto rendimiento solo sobre datos depurados
4. Verificación con LVM – verificación condicional basada en confianza para reducir aún más el número de llamadas
Resultados:
• Costo de etiquetado humano aprox. 2.16 millones de wones → 90 mil wones
• Ahorro de costos de aprox. 95.7%, y el tiempo de trabajo pasó de varios días → unas cuantas horas
• Valor esencial: no fue un ahorro de una sola vez, sino la obtención de un sistema reutilizable
Se demuestra que los límites del capital pueden superarse con tecnología, y que el software es una herramienta capaz de convertir un problema de costos en un problema estructural.
9 comentarios
Gracias por compartir este buen contenido.
Oh, muy buen artículo. Mencionaste que deciden si realizar validación adicional en función de la confiabilidad; también me da curiosidad cómo se medía exactamente ese valor de confiabilidad.
Como referencia, el modelo gpt-4o-mini tiene un costo excesivamente alto en tokens de entrada al usar imágenes, así que les recomendaría considerar también otros modelos ligeros.
Hola, winterjung, gracias por interesarte en mi trabajo. Para la confiabilidad uso el valor de
confidenceque devuelve directamente el VLM (GPT-4o). Como mencionaste, existe la limitación de que no está claro en qué se basa GPT-4o para calcularconfidencey que no es posible reproducirlo. Aun así, desde una perspectiva práctica, lo implementé de modo que en la etapa final de verificación (Verifier) se decida si validar o no en función de un umbral, asumiendo que elconfidenceque devuelve el VLM es razonablemente preciso.No tenía idea de que el modelo got-4o-mini tuviera tokens de entrada de imagen excesivamente caros; gracias por avisarme. Lo reflejé de inmediato en el código jaja
La verdad me pregunto por qué 4o mini tiene ese precio; según entiendo, el 4o normal es más barato jajaja
Parece un texto que resolvió muy bien el problema usando VLM; me pareció interesante.
Hay una duda que me surgió al leerlo:
Me da curiosidad cómo incorporaron este proceso.
Mientras leía, pensé que el VLM probablemente tendría mejor rendimiento que YOLO, así que al recortar quizá podría darse el problema de que el modelo YOLO juzgue mal y se pierda información importante antes siquiera de pasársela al VLM.
Me gustaría saber a partir de qué problema se les ocurrió usar el recorte, y cómo validaron la precisión antes de incorporarlo.
¡Hola! Gracias por leer el artículo, me alegra que te haya parecido interesante.
Coincido con lo que mencionas. Es cierto que el VLM tiene mejor rendimiento que YOLO y que una clasificación errónea de YOLO puede hacer que se pierda información importante. Aun así, decidimos incluir la etapa de recorte por las siguientes razones.
La primera es el costo. Si se usa la imagen completa directamente en el VLM, el costo aumenta de forma drástica por el procesamiento de imágenes de alta resolución. Esa fue la razón principal para introducir el recorte.
La segunda es la velocidad de procesamiento.
Para procesar datasets grandes en un tiempo realista, esta mejora de velocidad era indispensable.
La tercera es la mejora en la precisión.
El recorte, de hecho, puede aumentar la precisión del juicio del VLM. En una imagen completa pueden aparecer juntos fondos complejos, varios personajes, texto, adornos, etc., y eso puede confundir al VLM sobre qué objeto debe evaluar. Por ejemplo, puede darse el caso de que no quede claro si se trata de un personaje en un póster del fondo, del peluche principal o de otro personaje al lado. En cambio, al usar recortes, el objeto objetivo queda claramente aislado, lo que permite que el VLM se concentre solo en ese objeto al evaluarlo.
Por supuesto, esto no resuelve por completo los problemas de falsas negativas o falsas positivas de YOLO. Sin embargo, configuramos el
confidence thresholdde YOLO en 0.5 para aumentar el recall y luego mitigamos ese problema filtrando las falsas detecciones en las etapas posteriores de filtrado con CLIP y verificación con Verifier. Además, como procesamos grandes volúmenes de datos, incluso si se producen algunas omisiones, estadísticamente pudimos asegurar una cantidad suficiente de datos de alta calidad.En conclusión, el objetivo era construir un pipeline práctico encontrando un punto de equilibrio entre costo, velocidad y precisión, y la etapa de recorte tuvo un efecto positivo en los tres aspectos.
Gracias por la respuesta.
Yo también pensé en el tema de los costos, y parece que, efectivamente, el costo cambia bastante según la resolución de la imagen de entrada. Y además, nunca se me había ocurrido la relación entre el tamaño de la imagen de entrada y la velocidad de procesamiento; es interesante. O sea que al hacer crop incluso mejora la velocidad de procesamiento.
¡Y la mejora en precisión es realmente sorprendente!
Aunque el rendimiento de los VLM ha mejorado mucho, ¿aun así todavía no logran superar el rendimiento de un modelo YOLO entrenado para un solo objetivo?
Gracias por dejar por escrito la experiencia y el know-how que adquiriste en situaciones reales.
Si yo también me encuentro con un problema parecido, sin duda tomaré como referencia los métodos que usaste.
Más que resolverlo al convertirlo en un problema estructural, me parece que lo que hicieron fue crear un modelo nuevo.
¡Gracias por la buena observación!
Creo que la expresión “convertirlo en un problema estructural” sonó un poco abstracta.
Lo que quise decir en el texto fue:
Before: "etiquetado = intervención humana = costo proporcional"
After: "etiquetado = pipeline = costos variables mínimos después de la configuración inicial"
Es decir, se transformó un problema de costo puntual en un problema de construcción de sistema.
También es válida la expresión “se creó un nuevo modelo de trabajo”.
Más precisamente, creo que podría decirse como “reemplazamos el trabajo humano por un pipeline de software” jaja