12. Guía de defensa del proyecto
Cómo defender cada aspecto del proyecto ante un tribunal, con los argumentos clave y las objeciones frecuentes con su respuesta. La regla de oro: conoce tus limitaciones mejor que quien te pregunta, y ten un plan para cada una.
12.1. Cómo defender la arquitectura del software
Argumento central: separación limpia entre librería reutilizable (src/) y entrypoints (scripts/), con configuración centralizada y sin rutas hardcodeadas.
Puntos fuertes a destacar:
- Patrón registry para modelos → añadir arquitecturas sin tocar el entrenamiento.
- Patrón factory para transforms → pipelines por etapa desacoplados.
- Único punto de entrada a imagen → consistencia train/eval/inferencia garantizada por construcción.
- Versionado de runs por timestamp → reproducibilidad y trazabilidad de experimentos.
Objeción probable: "¿No es sobre-ingeniería para un proyecto académico?"Respuesta: No; cada patrón resuelve un problema concreto que apareció. El registry permitió comparar 8 arquitecturas cambiando un string. La separación src/scripts permitió reusar la carga de datos en 4 lugares (dos pipelines, explicabilidad, inferencia) sin duplicar. Es la cantidad de estructura que el problema demanda, no más.
12.2. Cómo defender el dataset
Argumento central: consolidación cuidadosa de 8 fuentes heterogéneas, con deduplicación, estandarización y auditoría.
Puntos fuertes:
- Deduplicación exacta por SHA-256 con escaneo determinista.
- Distinción lab/real y estratificación por ambos, alineando la evaluación con el despliegue.
split_audit_report.csvdocumenta la distribución exacta por clase/entorno/split.
Objeción probable: "El dataset está muy desbalanceado; ¿no invalida los resultados?"Respuesta: El desbalance es real y lo abordamos explícitamente: sampler balanceado + augmentation asimétrico + selección por macro-F1 (que pesa todas las clases igual). Los resultados por clase (matriz de confusión, reporte de clasificación) muestran que las minoritarias no se ignoran. El desbalance es una característica del problema real, no un defecto que ocultamos.
Objeción probable: "¿Confían en la calidad de fuentes públicas mezcladas?"Respuesta: Por eso validamos integridad PIL, deduplicamos y separamos lab/real. Reconocemos que la dedup es exacta, no perceptual —una mejora identificada—. Y las licencias de cada fuente están documentadas.
12.3. Cómo defender el entrenamiento
Argumento central: transfer learning con AdamW, condiciones controladas y comparables entre arquitecturas.
Puntos fuertes:
- Transfer learning justificado por el tamaño del dataset.
- Reproducibilidad total (semilla global, cudnn determinista, splits fijos).
- Selección de checkpoint por val macro-F1 (early stopping implícito).
Objeción probable: "LR constante sin scheduler; ¿no están dejando rendimiento sobre la mesa?"Respuesta: Correcto, y es intencional en la fase de baselines: LR constante da comparabilidad justa entre arquitecturas. Un scheduler es la primera mejora del pipeline principal, donde optimizamos el modelo elegido, no comparamos candidatos. Separar "comparar" de "optimizar" es una decisión metodológica.
12.4. Cómo defender las métricas
Argumento central: macro-F1 como métrica principal, apropiada para desbalance, complementada con matriz de confusión y reporte por clase.
Objeción probable: "¿Por qué no reportan solo accuracy, que es más intuitiva?"Respuesta: Accuracy engaña con desbalance: predecir siempre la clase mayoritaria daría accuracy alta pero un modelo inútil. Reportamos accuracy además de macro-F1 para contexto, pero la métrica de decisión es macro-F1 porque refleja el valor real (detectar cada condición, incluidas las raras).
12.5. Cómo defender la selección de modelos
Argumento central: comparación empírica de arquitecturas ligeras bajo condiciones idénticas, con EfficientNet-B0 liderando (macro-F1 0.9117) y ShuffleNetV2 como alternativa más ligera.
Datos reales para citar:
| Modelo | Test macro-F1 | Test accuracy |
|---|---|---|
| EfficientNet-B0 | 0.9117 | 0.9514 |
| ShuffleNetV2-x1.0 | 0.9083 | 0.9541 |
| EfficientNet-Lite0 | 0.8905 | 0.9454 |
Objeción probable: "¿Por qué no probaron modelos más potentes?"Respuesta: La restricción de despliegue (≤20 MB, ≤300 ms, teléfono de gama media offline) descarta modelos grandes por definición. Elegimos arquitecturas diseñadas para edge; los resultados muestran que su capacidad es suficiente (todas superan la meta de 0.85). Usar un modelo que no cabe en el dispositivo sería inútil por muy preciso que fuera.
12.6. Cómo defender los resultados
Argumento central: tres arquitecturas superan la meta de macro-F1 ≥ 0.85, con evaluación en test independiente y explicabilidad que valida que el modelo mira la lesión.
Objeción probable: "0.91 suena a sobreajuste; ¿cómo sé que generaliza?"Respuesta: El test es un conjunto nunca visto, estratificado para incluir imágenes de campo real (el dominio de despliegue). El modelo se seleccionó por validación, no por test. La explicabilidad (LIME + Grad-CAM) muestra que las predicciones se basan en las lesiones, no en artefactos. Y las convergencias en época 26-30 con brecha train-val razonable no indican sobreajuste catastrófico.
12.7. Cómo defender las limitaciones (lo más importante)
Estrategia: presenta las limitaciones tú primero, con su plan de mitigación. Un tribunal confía más en quien conoce sus debilidades.
| Limitación | Cómo presentarla |
|---|---|
| Loop principal pendiente | "Los baselines son funcionales y superan la meta; el pipeline principal refinará el modelo elegido con schedulers y más rigor." |
| Dedup solo exacta | "Identificamos que cuasi-duplicados podrían escapar; la mejora es dedup perceptual, ya disponible en imagededup." |
| Sin tests formales | "Tenemos smoke checks y auditorías; una suite pytest en CI es la siguiente capa de robustez." |
| TFLite no validado | "El objetivo de despliegue está definido; validaremos la cuantización Int8 temprano sobre el líder actual." |
| Estocasticidad de LIME | "Por eso auditamos estabilidad con lime_stability.py en vez de confiar en una corrida." |
12.8. Guion de presentación sugerido (10-15 min)
- Problema y contexto (2 min): el maíz en El Salvador, agricultores sin conectividad, diagnóstico tardío. → Resumen ejecutivo.
- Enfoque (2 min): clasificación con deep learning ligero, Edge AI offline, CRISP-DM.
- Datos (2 min): 8 fuentes → clean/, dedup, estratificación lab/real, desbalance. → Flujo.
- Modelado (3 min): transfer learning, registry de arquitecturas, balanceo por sampler, AdamW. → Decisiones.
- Resultados (2 min): tabla de macro-F1, meta superada, matriz de confusión.
- Explicabilidad (2 min): LIME + Grad-CAM, mostrar un panel, validar que mira la lesión. → Explicabilidad.
- Limitaciones y trabajo futuro (2 min): loop principal, TFLite, dedup perceptual. → Riesgos.
12.9. Frases-ancla para momentos difíciles
- Si no sabes algo: "Esa es una buena pregunta; no lo medimos directamente, pero mi hipótesis fundamentada es... y lo verificaría haciendo...".
- Si cuestionan una decisión: "Consideramos [alternativa]; elegimos [lo nuestro] porque [driver]. El trade-off que aceptamos fue...".
- Si señalan un defecto real: "Correcto, es una limitación conocida. Nuestro plan de mitigación es...".
Nunca inventes un número. Es preferible decir "no lo medimos, pero así lo estimaría" que citar una cifra falsa que un jurado puede desmontar.
Siguiente
Para un integrante nuevo, el orden de estudio recomendado: Plan de onboarding.