Recuperar la prueba detrás de cada resultado.

Distinguir campaña, configuración y ejecución

Una campaña plantea una pregunta, por ejemplo comparar una referencia con una adaptación. Una configuración describe las decisiones técnicas. Un run es un intento de ejecución de esa configuración, con una semilla, un inicio, un fin y un estado. Por lo tanto, dos intentos idénticos conservan dos identificadores, aunque el segundo sustituya a un ensayo interrumpido.

Añade un identificador de evaluación cuando el mismo artefacto se evalúe sobre varios conjuntos o con una métrica nueva. Esto evita confundir un modelo nuevo con una nueva lectura del modelo existente. Relaciona el intento de reanudación con el anterior y con el checkpoint cargado.

MLflow también organiza el seguimiento en torno a runs, parámetros, métricas y artefactos. Esta distinción es útil incluso en un simple conjunto de archivos. Puedes aplicarla con tu herramienta habitual; no hace falta ninguna plataforma de seguimiento concreta para empezar.

Fuentes técnicas: MLflow — runs, parámetros, métricas y artefactos

Escribir el manifiesto realmente ejecutado

Conserva los parámetros resueltos tras aplicar los valores por defecto y los argumentos de lanzamiento. El archivo de configuración original puede omitir un batch por defecto o una opción modificada en tiempo de ejecución. Registra lo que se utilizó efectivamente, con una copia del código o una revisión inmutable y el estado de los cambios no guardados.

El manifiesto también relaciona versiones del modelo y del tokenizer, entorno de software, GPU realmente utilizada, precisión, datos, seeds y definición de las métricas. Describe el ensayo, sin convertirse en un tutorial de instalación. Anota las unidades: segundos, bytes, tokens, puntos o proporción sobre 0 a 1 según la medida.

Al inicio, el estado es en curso; al final, pasa a terminado, fallido o interrumpido según lo que hayas constatado. No completes a posteriori una versión olvidada con la que está instalada actualmente. Marca la información desconocida y limita la conclusión que dependa de ella.

Identificar los datos más allá de un nombre de carpeta

Una ruta como datos/final no designa una versión estable. Conserva el inventario de los archivos o de los ejemplos, los splits y el procedimiento de transformación. Si corriges etiquetas o filtras filas, crea una nueva versión y mantén la relación con la anterior. La puntuación antigua debe seguir apuntando a sus datos antiguos.

Hugging Face Datasets asocia fingerprints al estado de un conjunto y a sus transformaciones para gestionar la caché. Este mecanismo es útil, pero hay que conservar también el origen de los datos y el preprocesamiento. Una transformación no hasheable puede, en particular, dar lugar a un fingerprint aleatorio: el identificador de caché no sustituye por sí solo tu expediente de procedencia.

Para los artefactos fijados, añade tamaño y huella de archivo. Un digest SHA-256 calculado antes y después de una copia permite verificar que los bytes corresponden a la referencia conservada. No prueba ni la calidad de las etiquetas, ni los derechos de uso, ni la ausencia de fuga entre los splits.

Fuentes técnicas: Hugging Face Datasets — fingerprints y transformaciones · Python 3.14 — huellas de archivos con hashlib

Relacionar métricas, predicciones y artefactos

Una línea de métrica debería identificar el run, el artefacto evaluado, el conjunto de evaluación, la versión de la métrica y su alcance. Precisa si el valor corresponde a un checkpoint intermedio, al modelo final o a un subgrupo. Una curva no basta si ya no se sabe qué archivo corresponde al punto elegido.

Conserva las predicciones con su identificador de entrada, su estado y la información necesaria para la evaluación. Las referencias esperadas pueden quedar en un archivo aparte versionado. Para una salida estructurada, distingue resultado bruto, resultado parseado y veredicto: corregir el parseo no debe sobrescribir la salida inicial.

MLflow permite vincular métricas con modelos y con datos. Con archivos, aplica el mismo principio mediante identificadores explícitos. Mantén un inventario legible de los artefactos: pesos o adaptador, parámetros de generación, salidas, informe de evaluación y nota de decisión. No supongas que una captura de pantalla reemplaza estos archivos.

Fuentes técnicas: MLflow — vincular métricas, modelos y conjuntos de datos

Ejemplo: seis runs y un duplicado que oculta una carencia

Consideremos un ejemplo de clasificación con dos configuraciones y tres semillas. Produce seis runs previstos. Cada uno debe predecir los mismos 300 identificadores de evaluación: la carpeta completa espera, por tanto, 6 × 300 = 1 800 pares únicos (run_id, input_id). Este cálculo describe un inventario esperado, no un experimento realmente ejecutado.

Supongamos que un archivo contenga 300 líneas, pero que el identificador doc-042 aparezca dos veces y doc-117 falte. El total de líneas parece correcto; sin embargo, solo hay 299 identificadores únicos. Este run falla el control de cobertura hasta que se explique y corrija la anomalía.

Si después cada run se evalúa sobre el corpus completo y sobre su subgrupo de textos largos, obtienes doce líneas de métrica para una métrica dada. Siguen siendo seis runs, no doce entrenamientos independientes. La clave de evaluación debe incluir el alcance para conservar esta distinción.

Cerrar el expediente con una decisión legible

Antes de declarar un run terminado, controla la presencia y apertura de los archivos, la correspondencia de los identificadores, las métricas recalculables y el estado de cada error. Un intento técnicamente terminado puede seguir rechazado por calidad insuficiente. Mantén estos dos estados separados.

La nota de decisión reúne la pregunta, las variantes comparadas, el criterio anunciado, los resultados retenidos y los motivos de exclusión. Cita los run_id y las rutas de artefactos en lugar de «el último modelo». Añade las limitaciones: pocas repeticiones, subgrupo insuficiente, versión no recuperada o comparación que se volvió imposible.

Una corrección posterior debe dejar rastro: nueva evaluación, nuevo informe y motivo del cambio. Conserva la conclusión anterior como versión histórica identificada, sin dejar que aparezca como decisión actual. Por último, verifica que la copia exportada se abra desde su carpeta de destino.

Evitar la recolección inútil y las promesas de reproducción

Recoge los campos necesarios para la prueba, no todas las variables de entorno ni el historial de la terminal. Una configuración o una URL puede contener un token; prepara una versión compartible sin secretos y guarda los datos que deben permanecer privados en su ubicación autorizada. Los identificadores técnicos de ensayo no necesitan incluir el nombre de una persona.

Un expediente completo mejora la posibilidad de rehacer y comprender un experimento. No garantiza una igualdad numérica entre plataformas o versiones: PyTorch documenta estos límites de reproducibilidad. Distingue recuperar el protocolo, recargar el artefacto y reproducir exactamente las cifras.

El carnet de IteraGPU puede conservar tus objetivos, parámetros y decisiones, con las referencias útiles. No lanza los runs ni recopila automáticamente los archivos o la telemetría. Úsalo como índice de tu razonamiento y conserva el expediente de artefactos en tus propias copias de seguridad.

Fuentes técnicas: PyTorch 2.14 — límites de reproducibilidad entre entornos

Preguntas prácticas