Universidad San Sebastián · Facultad de Ingeniería · Magíster en Data Science

FitoAsistente

Asistente para el diagnóstico fitosanitario de cultivos, con dos capacidades distintas de modelos fundacionales de Hugging Face.

Ver la demostración Ejecutar la aplicación Modelo ViT Modelo ConvNeXt

Jonathan Núñez Moya · Francisco Rietta González
Inteligencia Artificial — Prof. Manuel Alejandro Goyo · Agosto de 2026

La aplicación funcionando

Recorrido real de 20 segundos, grabado sobre la aplicación en ejecución

Se arrastra la fotografía de una hoja al recuadro, el clasificador la identifica como Peach · Bacterial spot con 99,7 % de confianza, el asistente responde una consulta sobre la enfermedad con ese diagnóstico ya en contexto, y una consulta ajena al dominio queda rechazada por el filtro sin llegar al modelo de lenguaje.

Por qué publicamos un video y no un enlace. La dirección pública que genera Gradio existe únicamente mientras el cuaderno está en ejecución, así que cualquier enlace que dejáramos aquí quedaría muerto a los pocos días. El video resuelve eso: dispone el funcionamiento completo de forma permanente y verificable. Y si prefieres ejecutarla tú, el cuaderno está en la entrega y levanta en unos cuatro minutos — las instrucciones están más abajo.

Qué hace

Dos capacidades distintas de modelos fundacionales, en una sola aplicación

Subes la foto de una hoja y el sistema hace dos cosas que no son la misma. La clasifica entre 38 categorías fitopatológicas, y después conversa contigo sobre qué hacer con ese diagnóstico. El sistema tiene dos capacidades y tres modelos: ViT y ConvNeXt resuelven la misma tarea y están los dos porque son el objeto de la comparación experimental.

Capacidad 1 · image-classification

ViT-Base/16 y ConvNeXt-Tiny

Ajustados sobre PlantVillage. Devuelven una etiqueta entre 38 clases con su probabilidad. Se pueden ejecutar por separado o comparar lado a lado.

Capacidad 2 · text-generation

Qwen2.5-1.5B-Instruct

Sin ajustar. Recibe como texto la clase que decidió el clasificador y conversa sobre tratamiento y manejo. No procesa la imagen.

Por qué se necesitan las dos

El clasificador es preciso pero cerrado: ante una especie que nunca vio devuelve igual una de sus 38 etiquetas, con alta confianza y sin manera de decir «no sé». El modelo de lenguaje no decide nada: recibe la clase ya resuelta y se encarga de traducirla a manejo agronómico, que es la pregunta que un usuario tiene de verdad frente a una hoja enferma.

Resultados

Comparación controlada sobre el conjunto de prueba, usado una sola vez

Todas las condiciones idénticas salvo la arquitectura: 20 % estratificado de PlantVillage, partición 80/10/10, semilla 42, 3 épocas, lote 32, learning rate 5e-5, GPU T4.
ModeloPreentr.ParámetrosExactitudMacro F1Weighted F1Latencia CPU
CNN desde cero (referencia)No8,49 M59,60 %0,3540,544
ViT-Base/16IN-21k85,83 M99,08 %0,9880,991395,0 ms
ConvNeXt-TinyIN-1k27,85 M96,41 %0,9190,960119,6 ms
+63,4 pp

de macro F1 sobre la red entrenada desde cero, contra +39,5 pp de exactitud

+6,9 pp

de macro F1 de ViT sobre ConvNeXt, con solo 2,7 pp de diferencia en exactitud

3,3×

más rápido ConvNeXt en CPU, con un tercio de los parámetros

Por qué la brecha es tan distinta según la métrica

ConvNeXt obtuvo un F1 de 0,000 en Potato___healthy, una clase con solo tres ejemplos en prueba, y 0,182 en Corn___Cercospora_leaf_spot. ViT resolvió las dos por encima de 0,900. Abandonar las clases pequeñas es exactamente el mismo patrón que había mostrado la red entrenada desde cero, y por eso elegimos ViT como modelo por defecto aunque sea más lento.

Las dos arquitecturas coinciden en tres de sus cinco peores clases. Cuando los dos modelos fallan en lo mismo, la dificultad viene del problema y no del modelo.

Matriz de confusión de ViT-Base
Matriz de confusión normalizada — ViT-Base/16
Matriz de confusión de ConvNeXt-Tiny
Matriz de confusión normalizada — ConvNeXt-Tiny
Curvas de entrenamiento
Pérdida y macro F1 de validación. ViT llegó a 0,981 de macro F1 en la primera época; ConvNeXt partió en 0,646 y necesitó las tres para llegar a 0,936.

Lo que aprendimos del modelo de lenguaje

Medimos la segunda capacidad y dos cosas que creíamos resultaron falsas

Sometimos el asistente a diez consultas sobre una misma hoja de duraznero clasificada como Peach · Bacterial spot: ocho del dominio agronómico y dos deliberadamente ajenas. Cada respuesta se clasificó en correcta, vaga o incorrecta.

Resultado sobre 10 consultasQwen2.5-0,5BQwen2.5-1,5B
Correctas (de 8 en dominio)01
Vagas (de 8 en dominio)13
Incorrectas (de 8 en dominio)74
Fuera de dominio bloqueadas0 de 22 de 2

El resultado más informativo

Ante la pregunta por la dosis de cobre, el modelo de 0,5 B inventó una cifra —«0,001 gramos por litro»— y un instrumento que no existe. El de 1,5 B respondió que no tenía información específica y derivó a un agrónomo. Se abstuvo. Un modelo mayor no solo acierta más: reconoce mejor los límites de lo que sabe, y en un asistente que sugiere tratamientos eso importa más que la exactitud media.

El guardarraíl por instrucción no funcionaba

Habíamos escrito en la instrucción de sistema que el asistente solo respondiera sobre botánica y agricultura. Al medirlo, dejó pasar las dos consultas ajenas al dominio: a una pregunta de salud humana llegó a sugerir analgésicos. Lo reemplazamos por un filtro léxico determinista que decide antes de invocar al modelo, y que acertó 21 de 21 casos etiquetados. La lección se resume en una línea: lo que debe cumplirse siempre no se le pide al modelo, se le impone al sistema.

Es una mitigación, no una solución: el filtro decide por vocabulario, así que una consulta ajena redactada con palabras agrícolas pasaría.

Limitaciones

Lo que este trabajo no demuestra

En lo metodológico, los dos hallazgos que más cambiaron nuestra lectura de los resultados —el buffer de barajado del experimento de referencia y el agrupamiento por hoja de PlantVillage— no tienen nada que ver con la arquitectura de los modelos.

Ejecutar la aplicación

Cuatro minutos, sin instalar nada en tu equipo

  1. Abre 4_Codigo_Aplicacion_Gradio.ipynb —incluido en la entrega— en Google Colab.
  2. Menú Entorno de ejecución → Cambiar tipo de entorno → GPU T4. Sin GPU también funciona, pero el asistente tarda entre 15 y 30 segundos por respuesta.
  3. Ejecuta todas las celdas (Ctrl+F9). La descarga de los tres modelos desde el Hub toma unos minutos la primera vez.
  4. La última celda imprime una dirección terminada en .gradio.live. Esa es la aplicación, y funciona desde cualquier navegador mientras el cuaderno siga abierto.

Los tres modelos se descargan solos desde el Hub, así que no hay que entrenar nada ni configurar credenciales. El cuaderno de entrenamiento se entrega por separado y con todas sus salidas ejecutadas, por si interesa revisar el proceso completo.

Sobre este despliegue

Por qué la aplicación no corre dentro de este Space.

En julio de 2026 Hugging Face modificó su política: los Spaces de tipo Gradio y Docker pasaron a requerir plan PRO, mientras que los de tipo Static siguen siendo gratuitos. Está documentado en el foro oficial de Hugging Face.

La documentación menciona una excepción: una cuenta gratuita «in good standing» podría alojar hasta dos Spaces Gradio sobre ZeroGPU. La verificamos en la cuenta del proyecto el 11 de agosto de 2026 y no estuvo disponible: el formulario de creación ofrece Gradio y Docker marcados como «Paid», sin opción de hardware ZeroGPU.

La aplicación es exactamente la misma que habíamos preparado. Lo único que cambia es dónde se ejecuta el proceso: en vez del contenedor de Hugging Face, corre en un cuaderno de Google Colab y Gradio publica la dirección con share=True. Los dos modelos ajustados siguen publicados en el Hub, y esta portada está desplegada como Space Static.

Componentes del proyecto