/ Proyectos / Agritech / Detección de plagas en algodón
Que tu investigación no quede en papel: detección de plagas en algodón con una app real
Un modelo entrenado en un notebook es un hallazgo. La misma investigación, dentro de una app que un agricultor puede usar desde el celular, es una prueba de concepto.
Muchas investigaciones académicas de machine learning terminan en el mismo lugar, un notebook bien documentado, con buenas métricas, guardado en una carpeta que nadie más vuelve a abrir. El modelo funciona, pero nunca llega a la persona que realmente lo necesitaba usar.
Este proyecto partió de un modelo ya entrenado para clasificar ocho condiciones distintas en hojas de algodón, entre plagas, enfermedades y estados sanos, y se propuso una pregunta distinta a la habitual. No "¿qué tan preciso es el modelo?", sino "¿puede alguien en el campo, sin conocimientos técnicos, tomar una foto y recibir una recomendación útil en segundos?". Esa pregunta es la que convierte una investigación en una prueba de concepto real.
Mapa del casoContenido
- Diagrama de la solución. De la foto tomada en el celular a la recomendación en pantalla
- Construcción de la solución. Del modelo entrenado a una app instalable
- Condiciones del proyecto. El objetivo y las restricciones reales de una prueba de concepto
- Pasos. Del entrenamiento del modelo a la app móvil con BeeWare
- Proceso de iteración. Un ajuste real del modelo, documentado sin maquillaje
- Descargables. Notebook, código de la app y repositorio del proyecto
- Lecciones importantes. Qué tan lejos llega esta arquitectura, y qué le falta para producción
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
Todo el flujo, desde que se toma la foto hasta que aparece la recomendación en pantalla, ocurre en segundos, sin que el usuario necesite entender nada de lo que pasa en la nube mientras tanto.
De la investigación a la app instalableConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Origen del proyecto | Investigación académica ya con un modelo entrenado, sin una interfaz de uso real |
| Categorías a clasificar | Ocho condiciones de la hoja de algodón, entre plagas, enfermedades y estado sano |
| Usuario final | Alguien sin conocimientos técnicos, que solo necesita tomar una foto y recibir una recomendación |
| Alcance esperado | Prueba de concepto o prueba piloto, no una aplicación de producción con miles de usuarios simultáneos |
| Opción | Por qué se descartó |
|---|---|
| Dejar el modelo únicamente documentado en el notebook | Nadie fuera del equipo técnico podría usarlo en un caso real |
| Construir apps nativas por separado para iOS y Android | Duplicaría el esfuerzo de desarrollo para una prueba de concepto que no lo justifica |
| Empaquetar la interfaz con BeeWare, un solo código Python para múltiples plataformas | Permite construir una app instalable real sin salir del mismo lenguaje usado para entrenar el modelo |
Pasos
Extracción de características antes de clasificar
Agente: propuso alimentar el modelo directamente con los píxeles crudos de cada imagen.
Criterio aplicado: convertir cada imagen a escala de grises, redimensionarla, normalizarla, y concatenar su histograma de intensidades como parte del vector de características, reduciendo dimensionalidad sin perder la señal relevante para clasificar.
Elegir un perceptrón multicapa como modelo base
Agente: sugirió empezar directamente con una red convolucional profunda.
Criterio aplicado: entrenar primero un perceptrón multicapa sobre las características ya extraídas, un modelo más simple y rápido de iterar, adecuado para validar la viabilidad de la prueba de concepto antes de invertir en arquitecturas más pesadas.
Empaquetar la interfaz con BeeWare en lugar de una app nativa
Agente: propuso construir la interfaz como una aplicación web accedida desde el navegador del celular.
Criterio aplicado: usar BeeWare y Toga para construir una app instalable real, con acceso directo a la cámara del dispositivo, algo que una app web no siempre puede ofrecer de forma nativa.
Enriquecer el resultado con un diccionario local, no con otra llamada a la nube
Agente: propuso consultar una base de datos externa para obtener la descripción y los consejos de cada plaga.
Criterio aplicado: mantener esa información en un diccionario local dentro de la misma app, porque no cambia con frecuencia y evita una dependencia de red adicional justo en el paso final que el usuario ve.
Proceso de iteración
Ajuste documentado, no forzado
La primera versión del modelo cometía errores consistentes en un subconjunto identificable de imágenes. En lugar de aceptar esos errores como ruido inevitable, se identificaron las imágenes mal clasificadas, se retiraron del conjunto de entrenamiento, y se reentrenó un segundo modelo más simple sobre los datos filtrados. El resultado mejoró, pero vale la pena ser honesto sobre esta decisión, filtrar ejemplos "difíciles" del entrenamiento reduce el error medido, aunque también puede ocultar casos reales que el modelo seguirá enfrentando en producción. Para una prueba de concepto, la mejora fue aceptable, pero es exactamente el tipo de ajuste que habría que revisar con más cuidado antes de escalar el proyecto.
CierreLecciones importantes
Si tienes una investigación académica de machine learning y sientes que se está quedando en papel, la distancia hasta una prueba de concepto real suele ser más corta de lo que parece. No hace falta un equipo de producto ni meses de desarrollo, hace falta empaquetar el modelo detrás de una interfaz simple y conectarlo a un flujo mínimo de datos. Eso ya demuestra el valor de la investigación frente a alguien que no sabe qué es un perceptrón multicapa, pero sí sabe reconocer una recomendación útil cuando la ve.
Los límites honestos de esta arquitectura
Esta arquitectura fue diseñada para demostrar viabilidad, no para soportar producción a gran escala. No incluye balanceo de carga, ni un manejo robusto de picos de tráfico, ni las capas de seguridad que exigiría exponer credenciales y servicios a miles de usuarios reales. Para una prueba de concepto o una prueba piloto académica funciona muy bien. Llevar este mismo proyecto a producción real exigiría rediseñar esas piezas desde cero, no simplemente escalar los recursos existentes.
Termina ya tu proyecto
¿Tienes una investigación que no quiere quedarse en papel? Yo te ayudo a llevarla a una prueba de concepto.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato