En este curso recorrimos fundamentos, procesamiento de imágenes, convoluciones, entrenamiento, evaluación, transfer learning, modelos preentrenados, optimización, deployment y un caso práctico completo. Como cierre, conviene consolidar una pregunta más general: ¿cómo trabajar bien en un proyecto real de visión por computadora?
Las buenas prácticas no son adornos metodológicos. Son lo que separa un experimento que “parece funcionar” de un sistema que puede entenderse, mejorarse, mantenerse y defenderse técnicamente.
En este tema reuniremos criterios prácticos para diseñar mejores proyectos de visión artificial, desde la definición del problema hasta el mantenimiento del modelo ya desplegado.
Un error frecuente es arrancar el proyecto eligiendo una arquitectura o una librería antes de entender con precisión el problema real.
La primera buena práctica es formular claramente:
Si el problema está mal definido, incluso un buen modelo puede terminar resolviendo algo distinto de lo que el proyecto necesitaba.
No es lo mismo un modelo para análisis offline que uno para video en tiempo real. Tampoco es lo mismo un sistema para clasificación recreativa que uno para inspección industrial o apoyo médico.
El contexto define prioridades: precisión, recall, latencia, interpretabilidad, privacidad, costo computacional y facilidad de mantenimiento.
En visión por computadora, la calidad del dataset suele tener más impacto que pequeños cambios arquitectónicos.
Una buena práctica central es invertir tiempo en revisar:
Un pipeline técnicamente impecable no compensa un dataset mal construido.
Antes de entrenar, conviene revisar manualmente una parte del dataset. Esto ayuda a detectar imágenes dañadas, etiquetas incorrectas, duplicados o ejemplos que en realidad no pertenecen a ninguna clase.
La limpieza de datos suele parecer tediosa, pero evita muchos problemas posteriores difíciles de diagnosticar.
Una buena práctica esencial es evitar que información de validation o test se filtre al entrenamiento.
Esto puede ocurrir de varias maneras:
Cuando esto pasa, las métricas resultan artificialmente optimistas.
Ya vimos esta idea en temas anteriores, pero aquí conviene reforzarla como práctica profesional:
Cuando un proyecto no respeta esta disciplina, pierde confiabilidad técnica.
En proyectos colaborativos es muy útil dejar por escrito qué significa cada clase y qué hacer con casos ambiguos. Eso mejora la consistencia del etiquetado y reduce discusiones posteriores.
Una breve guía de anotación puede ahorrar muchísimo retrabajo.
Una buena práctica de ingeniería es construir primero una línea base simple y verificable. Por ejemplo:
Es mejor tener un pipeline pequeño pero confiable que un sistema complejo difícil de entender desde el primer día.
Si no podemos reproducir razonablemente un resultado, es difícil confiar en él. Por eso conviene registrar semillas, configuraciones y versiones de librerías.
import torch
import random
import numpy as np
seed = 42
random.seed(seed)
np.random.seed(seed)
torch.manual_seed(seed)La reproducibilidad exacta absoluta no siempre es trivial, pero una buena disciplina mejora mucho la trazabilidad del experimento.
Otra práctica muy valiosa es registrar de manera explícita qué configuración produjo cada resultado. Por ejemplo:
Esto evita que el proyecto dependa de la memoria informal del equipo.
Una buena práctica es no enamorarse de una única cifra. La accuracy puede ser útil, pero no siempre cuenta toda la historia.
Según el problema, conviene mirar también:
Una sola métrica puede ocultar fallas importantes.
No alcanza con leer números agregados. Una buena práctica clave es inspeccionar ejemplos mal clasificados, casos dudosos y situaciones límite.
Ver errores concretos suele revelar problemas de etiquetas, sesgos del dataset, debilidades del modelo o incluso defectos en el preprocesamiento.
Si el entrenamiento mejora pero la validación se estanca o empeora, probablemente estamos sobreajustando.
Buenas prácticas para controlarlo incluyen:
El augmentation puede ser muy valioso, pero debe tener sentido para el problema. No toda transformación preserva la semántica de la clase.
Por ejemplo, una rotación extrema puede ser razonable en algunos problemas y absurda en otros. La buena práctica es elegir augmentations compatibles con la lógica visual del dominio.
El pipeline de inferencia debe respetar supuestos fundamentales del entrenamiento: tamaño de entrada, orden de canales, normalización y mapeo de clases.
Muchos bugs de producción aparecen porque el modelo es correcto, pero la imagen llega mal preparada.
En un proyecto serio conviene poder responder preguntas como:
Por eso es buena práctica versionar no solo el código, sino también el dataset y los artefactos generados.
No solo conviene guardar el modelo final. También puede ser útil guardar:
Esto mejora la trazabilidad del proyecto y simplifica la revisión técnica.
Una buena base de código separa responsabilidades. Por ejemplo:
Esto facilita pruebas, mantenimiento y reutilización.
Antes de lanzar un entrenamiento largo o un deployment complejo, conviene hacer pruebas pequeñas:
Esto evita perder horas en ejecuciones largas que estaban mal planteadas desde el principio.
Una buena práctica es no dejar el deployment para el final absoluto. Desde el inicio conviene considerar:
Esto evita diseñar un pipeline imposible de desplegar después.
No alcanza con que el modelo funcione en la máquina de desarrollo. Buenas prácticas de deployment exigen medir en el hardware y contexto reales.
Un modelo que es rápido en GPU de escritorio puede ser demasiado lento en CPU o en un dispositivo embebido.
Una buena práctica profesional es seguir observando el modelo una vez desplegado. Algunas señales útiles son:
Esto ayuda a detectar drift, degradación o cambios en las condiciones reales de operación.
En algunos dominios no alcanza con obtener una etiqueta. Puede ser útil sumar herramientas de interpretación como mapas de calor, análisis de errores o reportes por clase.
La buena práctica aquí es alinear el nivel de explicabilidad con el riesgo y la sensibilidad del problema.
Muchos proyectos de visión trabajan con personas, espacios privados, documentos o escenas sensibles. La buena práctica no es solo técnica: también es ética y legal.
Conviene preguntarse:
Una buena práctica madura consiste en asumir que el modelo no es estático. Los datos cambian, los requerimientos cambian y el sistema deberá revisarse con el tiempo.
Por eso conviene diseñar pensando en iteración, no en una solución “definitiva” e inmutable.
Antes de dar por sólido un proyecto de visión por computadora, conviene poder responder que sí a preguntas como estas:
Cuando se descuidan estas buenas prácticas, aparecen problemas muy típicos:
Las buenas prácticas en visión por computadora son, en el fondo, buenas prácticas de ingeniería aplicada al trabajo con imágenes, modelos y datos reales. No sustituyen el conocimiento técnico del modelo, pero sí hacen posible que ese conocimiento produzca resultados confiables y sostenibles.
Un proyecto sólido no es el que tiene la arquitectura más llamativa, sino el que está bien planteado, bien medido, bien documentado y listo para evolucionar sin perder control técnico.
Con este tema cerramos el recorrido del curso. El paso natural a partir de aquí es construir proyectos propios, aplicar estos criterios en contextos reales y profundizar progresivamente en problemas específicos de clasificación, detección, segmentación e inferencia en producción.