Reproducibilidad y proyecto de principio a fin: combinarlo todo — Inteligencia artificial en ingeniería de inteligencia artificial y aprendizaje automático

Ganancias:

Capacidad para garantizar la reproducibilidad con cuatro pilares (fijación de semillas, control de versiones de datos, congelación de medios, monitoreo de experimentos) y producir el mismo resultado al repetir la misma ejecución.
Capacidad para combinar todas las paradas del módulo (métricas, datos, modelo, componentes LLM, evaluación, equidad, seguridad, distribución, monitoreo) en una cadena de extremo a extremo.
Capacidad para verificar que la decisión crítica permanece en manos del ser humano en cada parada y documentar el proyecto de manera auditable.

El fracaso más insidioso de un proyecto de ML no es un bloqueo; "No volver a obtener el mismo resultado". Si no puedes reproducir hoy la puntuación del modelo que pusiste en producción hace tres meses, realmente no controlas ese modelo. En esta unidad final, profundizamos la reproducibilidad: la capacidad de obtener de manera confiable el mismo resultado con las mismas entradas y combinar todo el módulo en una disciplina de proyecto de principio a fin.

Por qué la reproducibilidad es difícil

En el software normal, el mismo código produce el mismo resultado. En ML hay muchas más variables que determinan el resultado:

Aleatoriedad: la mezcla de datos, la inicialización de pesos y la división de datos dependen de la aleatoriedad.
Datos: el mismo código produce un modelo diferente con una versión de datos diferente.
Entorno: las versiones de la biblioteca, el hardware (CPU/GPU), incluso el sistema operativo pueden cambiar el resultado.
Caso oculto: un hiperparámetro no guardado, un paso de preprocesamiento manual, una selección no anotada.

La reproducibilidad no es algo "bueno de tener", sino un imperativo científico y de ingeniería. Un resultado que no se puede reproducir es una afirmación que no se puede probar.

Cuatro pilares de la reproducibilidad

1. Arreglar la aleatoriedad. Establezca todas las semillas aleatorias en un solo lugar: división de datos, inicialización del modelo, mezcla de datos. La semilla fija es la base de la garantía de "mismo resultado cuando se repite la misma ejecución".

2. Versione los datos. Registre con qué versión de datos se realizó cada experimento (versiones de datos en la unidad 2). Los “datos más recientes” son vagos; "Versión de datos v3, hash abc123" es exacta.

3. Congele el medio. Fije todas las dependencias a sus versiones exactas (por ejemplo, versiones exactas como numpy==1.26.4 en requisitos.txt o una imagen de contenedor). La "última versión" algún día arruinará todo.

4. Seguimiento de todo (seguimiento de experimentos). Guarde automáticamente para cada experimento: versión del código (git commit), versión de datos, todos los hiperparámetros, métricas y estructuras de salida. Las herramientas de seguimiento de experimentos como MLflow, Weights & Biases hacen esto de forma sistemática. Sin registro, la pregunta "qué configuración era mejor" queda sin respuesta.

Precaución: "Lo recordaré más tarde" es la falacia más cara. Dos semanas después, no recordará qué semilla, qué datos, qué hiperparámetro utilizó. El seguimiento automático elimina la dependencia de la memoria.

Enfoque débil / Enfoque fuerte

Débil: "Encontré el mejor modelo, está en el portátil, creo que su puntuación fue del 89%".

Fuerte: "Ejecute #147 en la herramienta de seguimiento de experimentos: git commit a3f9c, versión de datos v3 (hash abc123), semilla 42, todos los hiperparámetros registrados, prueba PR-AUC 0.887. Cuando ejecuto el mismo comando nuevamente, obtengo el mismo resultado poco a poco. El modelo depende de esta ejecución en el registro".

La diferencia: en el enfoque fuerte el resultado no se basa en una memoria, sino en una cadena fija y monitorizada. Todos pueden producir el mismo resultado cada vez.

Proyecto de principio a fin: combinación de módulo

Ahora combinemos todo el módulo en un solo flujo de proyecto. Un sistema de aprendizaje automático real pasa por estas paradas, y cada parada se basa en la anterior:

Definición del problema: Qué estamos resolviendo, cómo medir el éxito (unidad 3: métrica correcta, contexto empresarial). La métrica y el umbral están claros desde el principio.
Canalización de datos: recopilación, validación, limpieza, partición sin fugas, control de versiones (unidad 2).
Desarrollo de modelos: capacitación, comparación de referencia, validación cruzada, semilla dura (unidad 3 + esta unidad).
Componentes del LLM (si corresponde): RAG (unidad 4) y/o agentes (unidad 5); afinando si es necesario (unidad 6).
Evaluación: clúster de evaluación con casos de borde y seguridad, evaluación multicapa en sistemas LLM (unidad 8).
Auditoría de justicia y ética: Análisis de subgrupos, ficha modelo, explicabilidad (unidad 10).
Auditoría de seguridad: Inyección rápida, privacidad, cadena de suministro (unidad 9).
Distribución: Embalaje, distribución gradual, rollback, registro de modelos (unidad 7).
Monitoreo: Monitoreo de tres capas, alarmas de deriva (unidad 8).
Reproducibilidad: Seguimiento de semillas, versión de datos, medios y experimentos a lo largo de toda la cadena (esta unidad).

En este flujo, la IA es un acelerador y un generador de planos en cada parada; pero la selección de métricas, las decisiones de datos, la priorización de equidad, el umbral de implementación y la aprobación de versiones: las decisiones críticas permanecen en manos del ser humano. Esta es la esencia del módulo.

Documentación: el futuro te lo agradecerá

Un buen proyecto de ML se documenta por sí solo. Como mínimo, se debe escribir lo siguiente: criterios de problema y éxito, fuente y versión de datos, selecciones y justificaciones de modelos, resultados de la evaluación (incluidos los subgrupos), límites y riesgos conocidos, procedimiento de implementación y recuperación, plan de monitoreo. Este documento es el mejor amigo de la persona (tal vez seas tú) que regresa al proyecto después de seis meses.

tres mini casos

Caso 1: resultado perdido. Un ingeniero entrenó un gran modelo, pero no arregló la semilla ni guardó la versión de los datos. Cuando dejó el trabajo, nadie pudo reproducir ese resultado; el modelo se convirtió en una "leyenda de la caja negra" y finalmente se construyó desde cero. Se desperdiciaron semanas. Lección: un resultado no reproducible es un resultado inexistente.

Caso 2 - Colapso del medio ambiente. Un equipo no había arreglado las dependencias. Cuando una biblioteca se actualizaba automáticamente, los resultados del modelo cambiaban silenciosamente y la producción se interrumpía. Fueron necesarios días para encontrar el problema. Cuando las dependencias se congelaron y se colocaron en contenedores con las versiones definitivas, el problema no volvió a ocurrir. Lección: congelar el medio ambiente.

Caso 3 - El poder del seguimiento. Un equipo supervisó automáticamente cada experimento. Tres meses después, durante una auditoría regulatoria, respondieron a la pregunta "¿con qué datos, con qué entornos, qué rendimiento obtuvo en qué grupos?" con una grabación completa en cuestión de minutos. La inspección transcurrió sin contratiempos. Lección: el monitoreo es una herramienta de cumplimiento, no solo de ingeniería.

Plantillas copiables

Realice una verificación de reproducibilidad para este proyecto de aprendizaje automático. - ¿Están fijadas todas las semillas aleatorias (divididas, inicializadas, aleatorias)? - ¿Están versionados los datos? - ¿Están las dependencias congeladas en versiones exactas? - ¿Se realiza un seguimiento de cada experimento (confirmación de código, datos, hiperparámetro, métrica)? Escriba pasos concretos sobre cómo solucionarlo para cada columna que falta. Estructura del proyecto: [descripción]

Produzca un esqueleto de plan para este proyecto de aprendizaje automático de un extremo a otro. Problema: [descripción] Cubra las siguientes paradas y marque dónde está la decisión HUMANA en cada parada: problema/métrica, canalización, modelo, (RAG/agente/ajuste fino?), evaluación, equidad, seguridad, distribución, monitoreo, reproducibilidad. Escriba el riesgo principal y el paso de verificación para cada parada.

Produzca una plantilla de documentación técnica para este proyecto. Secciones: problema+criterios de éxito, datos (fuente+versión), selecciones de modelo+justificación, evaluación (incluidos subgrupos), límites conocidos+riesgos, implementación+reversión, plan de seguimiento. Proporcione los campos a completar para cada sección como preguntas.

Verifique la configuración de monitoreo de mi experimento: ¿Se guarda automáticamente en cada ejecución: git commit, versión de datos/hash, todos los hiperparámetros, todas las métricas, entorno (versiones de biblioteca)? ¿Obtengo el mismo resultado cuando vuelvo a ejecutar la misma ejecución? Configuración: [descripción]. Enumere los defectos y las correcciones.

Tabla de columnas de reproducibilidad

columna

que esta arreglado

Ejemplo de vehículo

aleatoriedad

todas las semillas

establecimiento de semillas

Datos

Versión de datos/hash

DVC

medio ambiente

Versiones de la biblioteca

pin de requisitos, Docker

Monitoreo

Código+datos+configuración+métrica

MLflow, W&B

Errores comunes

No arreglar la semilla. El resultado no se puede repetir.
No guardar la versión de datos. "¿Con qué datos?" sigue sin respuesta.
No congelar las adicciones. Una actualización arruinará todo silenciosamente.
Dejando los experimentos a la memoria. Dos semanas después no se recuerda nada.
Dejar las decisiones críticas a la inteligencia artificial. Las decisiones sobre métricas, justicia y distribución deben quedar en manos de las personas.
Aplazamiento de documentación. El futuro equipo (y tú) pagas el precio.

En resumen

La reproducibilidad es la firma de la ingeniería de aprendizaje automático seria: el resultado no reproducible es la afirmación no demostrable. Viene con cuatro columnas: corregir la aleatoriedad, los datos de la versión, congelar el entorno y realizar un seguimiento de cada experimento. Un proyecto de extremo a extremo combina todas las paradas de este módulo (métrica, datos, modelo, componentes LLM, evaluación, equidad, seguridad, distribución, monitoreo) en una cadena interconectada; La inteligencia artificial es un acelerador en cada parada, pero las decisiones críticas quedan en manos del ser humano. Documente todo, para futuros equipos y auditorías. Esta disciplina es el marco que sustenta todo lo que aprendes a lo largo del módulo.

Tarea de aplicación

Verifique un proyecto de aprendizaje automático con respecto a cuatro pilares de reproducibilidad: ¿las semillas son inmutables, los datos están versionados, el entorno está congelado y se realiza un seguimiento de los experimentos? Corrija las columnas que faltan y demuestre que puede ejecutar la misma ejecución dos veces y obtener el mismo resultado. Luego, genere el flujo de un extremo a otro del proyecto (10 paradas) en una página y marque "dónde está la decisión humana" en cada parada. Finalmente, escriba un breve borrador de documentación técnica.

lista de verificación

[] Se corrigieron todas las semillas aleatorias.
[] La versión/hash de los datos se registra con cada experimento.
[] Las dependencias están congeladas en versiones firmes (pin/contenedor).
[] Cada experimento se monitorea automáticamente (código+datos+configuración+métrica).
[] Cuando repito la misma ejecución, obtengo el mismo resultado.
[ ] Verifiqué y documenté que las decisiones críticas en el flujo de un extremo a otro las toman humanos.

Examen del módulo

1. Como ingeniero de ML, ¿cuál es el mejor enfoque a la hora de posicionar la inteligencia artificial en el flujo de trabajo?

A) La IA es un acelerador en negocios de bajo riesgo; Las decisiones críticas como métricas, datos y producción permanecen validadas y dejadas en manos del ser humano ✔
B) Mientras los resultados de la IA se vean bien, no hay necesidad de verificación
C) Dejar la decisión de poner el modelo en producción en manos de la inteligencia artificial ahorra tiempo.
D) La inteligencia artificial solo es útil para escribir texto, no tiene nada que ver con datos y trabajo con modelos.

Descripción: La IA es un potente acelerador para tareas de bajo riesgo y fácilmente verificables, como códigos, resúmenes de datos y documentos; Sin embargo, la responsabilidad de las decisiones que afectan el dinero, la confidencialidad y la responsabilidad legal, como la selección de métricas, qué datos se van a entrenar y poner el modelo en producción, recae en el ingeniero y el equipo calificados. Cada salida no debe usarse sin verificación.

2. ¿Por qué se coloca la validación del esquema al comienzo de una canalización de datos?

A) Porque aumenta directamente la precisión del modelo.
B) Porque hace innecesario el control de versiones de los datos
C) Porque detecta datos corruptos en el momento más temprano y más barato y evita que se filtren en los siguientes pasos ✔
D) Porque elimina la necesidad de etiquetado

Explicación: Cuanto antes se detecten los datos corruptos, más barato será repararlos. La validación de esquemas evita que datos corruptos se filtren silenciosamente en la capacitación o producción al rechazar datos fuera del tipo y rango esperado al comienzo de la línea (por ejemplo, el precio cambia 100 veces con el cambio de unidad); El mismo error detectado en producción cuesta muchas veces más.

3. ¿Cuál es el enfoque correcto al dividir datos en entrenamiento y prueba en un problema que involucra tiempo (series de tiempo)?

A) Usar división aleatoria porque siempre es el método más justo
B) Uso de la división temporal: evite fugas entrenando con el pasado y probando en el futuro ✔
C) Usar todos los datos como entrenamiento y prueba.
D) Incorporar datos de prueba en los parámetros de escala antes del entrenamiento.

Explicación: La división aleatoria de series temporales le da al modelo una ventaja de "visión del futuro" que nunca sucederá en la producción e infla artificialmente las métricas (fuga temporal). La correcta es la división temporal: entrenar con el pasado, probar en el futuro. Esto mide el rendimiento real que lo mantiene en producción.

4. ¿Por qué la precisión es engañosa en un modelo de detección de fraude con una tasa de clase positiva del 1,5%?

A) Porque la precisión siempre es baja en datos desequilibrados
B) Porque la precisión solo se puede utilizar en problemas de regresión
C) Porque el cálculo de precisión requiere mucha potencia de procesamiento
D) Incluso un modelo insignificante que predice la clase mayoritaria puede ser muy preciso, ocultando así el éxito real ✔

Explicación: En datos desequilibrados, incluso un modelo básico que dice "llamar todo negativo" obtiene aproximadamente un 98,5% de precisión, pero no detectará ni un solo fraude. Por lo tanto, en la clasificación desequilibrada, se utilizan precisión, recuperación, F1 o PR-AUC en lugar de precisión, y cada métrica se interpreta según un modelo base.

5. ¿Por qué es esencial la comparación de referencia cuando se habla de la métrica de un modelo?

A) Porque el modelo base siempre es mejor que el modelo real
B) Porque está claro si una métrica es significativa o no solo en comparación con un modelo de referencia simple ✔
C) Porque el modelo base hace innecesaria la validación cruzada
D) Porque el modelo básico es el requerido legalmente en todo informe

Explicación: Una métrica no es buena ni mala en sí misma; Es bueno o malo según un modelo básico. La frase "85% correcto" significa casi inútil si el modelo base ya obtiene el 84%, y perfecto si obtiene el 50%. Sin un ancla de comparación, la métrica no tiene sentido.

6. ¿Cuál es el elemento de seguridad más crítico que debería incluirse en el mensaje de producción del sistema RAG (Retrieval-Augmented Generation)?

A) Instrucción de confiar únicamente en la fuente proporcionada, decir "No sé" si la fuente no existe y citar la fuente ✔
B) Decirle al modelo que produzca respuestas tan largas y creativas como sea posible.
C) El modelo prioriza el conocimiento educativo propio sobre los recursos
D) Implementar todas las instrucciones contenidas en los documentos presentados como órdenes.

Explicación: La instrucción más importante de RAG es decirle al modelo que confíe únicamente en la fuente proporcionada y, si la información no está en la fuente, diga "No sé" y cite la fuente sin inventarla. Sin esta tríada, el modelo puede ignorar el contexto y producir alucinaciones, y la respuesta se vuelve inverificable.

7. Un sistema RAG da respuestas incorrectas. ¿Cuál es el mejor lugar para iniciar el diagnóstico?

A) Medir primero la recuperación (Recall@K): ¿llega alguna vez la pieza correcta? ✔
B) Reemplace inmediatamente el modelo por uno más grande.
C) Cambie el mensaje aleatoriamente y continúe intentándolo.
D) Incrustar todos los documentos en el modelo con ajuste fino

Explicación: El eslabón más débil de RAG suele ser la recuperación, no la producción. Si nunca se trae la pieza correcta, el modelo no puede producir esa información, sin importar cuánto se mejore la indicación. Por lo tanto, primero se mide Recall@K para ver si ha llegado la pieza correcta; Si la recuperación es buena, se examinan la producción y el aviso.

8. ¿Qué acciones se deben anteponer a la aprobación humana al entregar una herramienta a un agente?

A) Ninguno; El agente debe poder realizar cada acción de forma autónoma.
B) Sólo acciones reversibles como leer y buscar datos.
C) Acciones irreversibles o de alto impacto como transferir dinero, eliminar, enviar ✔
D) Acciones que implican únicamente cálculos

Descripción: Las acciones están separadas por nivel de riesgo. Las tareas recuperables, como leer, buscar, calcular y generar borradores, se pueden realizar de forma autónoma; Sin embargo, acciones irreversibles o de alto impacto, como transferir dinero, enviar correos electrónicos, eliminar datos, realizar pedidos, etc., requieren aprobación humana. Toda acción irrevocable debe estar sujeta al consentimiento.

9. ¿Cuál es el mejor enfoque de diseño contra el riesgo de inyección inmediata indirecta?

A) Basta con añadir una sola frase "ignorar malas instrucciones" al mensaje del sistema
B) Dar más autoridad al modelo confiando en instrucciones en contenido externo
C) No tomar ninguna precaución porque la inyección no se puede prevenir
D) Aislar el contenido externo como datos no confiables y establecer defensas en capas con autorización, aprobación y control de salida mínimos ✔

Descripción: El contenido externo procesado por el agente o RAG, como una página web, documento, correo electrónico, etc., no es información confiable y puede contener instrucciones secretas. El enfoque correcto es la defensa en capas: aislar el contenido externo como "datos, no comandos" con delimitadores claros, aplicar una autorización mínima, vincular las acciones irreversibles a la aprobación humana y auditar el resultado. Una sola línea de instrucciones no es suficiente.

10. ¿Cuál es la principal distinción al decidir si un problema debe resolverse con ajuste fino o RAG?

A) Los problemas de información se resuelven mejor con RAG, los problemas de comportamiento/formato se resuelven mejor con ajuste fino ✔
B) Cada problema siempre debe resolverse mediante ajustes
C) RAG se usa solo para la generación de código, el ajuste fino se usa solo para la traducción
D) El ajuste fino siempre se puede actualizar de forma más económica y rápida que RAG

Explicación: El ajuste fino es débil y arriesgado al enseñar nueva información al modelo; pero es poderoso para enseñar comportamiento, formato, tono y estilo. "La empresa modelo no conoce nuestros datos" es un problema de información y pertenece a RAG. "Dejar que el modelo siempre genere en nuestro formato estricto" es un problema de comportamiento y un candidato para un ajuste fino. Además, se deben realizar pocos disparos antes de realizar el ajuste.

11. ¿Qué es obligatorio para una implementación segura al poner en producción un nuevo modelo?

A) Si el modelo es bueno en las pruebas, ábralo directamente al 100% del tráfico.
B) No configurar ningún monitoreo después de la implementación
C) Implementación por fases (sombra/canario) y un plan de reversión probado previamente ✔
D) Publicar el modelo incluso si no se alcanza el umbral de evaluación

Explicación: Abrir el nuevo modelo directamente a todo el tráfico es arriesgado; Si está mal, todos se ven afectados. Lo correcto es que sea una distribución gradual (sombra, canario) y cada distribución tenga un plan de reversión probado. Una distribución no está completa sin un plan de recuperación; Poder volver a la versión anterior en cuestión de minutos protege al usuario cuando el modelo se comporta inesperadamente en producción.

12. ¿Cómo puede un modelo de ML fallar "silenciosamente" en producción y cuál es la forma de detectarlo?

A) El modelo colapsa; los registros del servidor muestran esto
B) Realizando predicciones erróneas sin cometer errores; ✔ Captura monitoreo por capas operativo, de entrada y de salida
C) El modelo nunca puede fallar silenciosamente, siempre alarma
D) Simplemente monitorear la latencia es suficiente para detectar cualquier degradación.

Explicación: El modelo puede fallar simplemente produciendo predicciones incorrectas sin fallar ni dar errores; La razón principal de esto es la deriva de datos y la deriva de conceptos. No basta con monitorear las métricas operativas (latencia, tasa de error); También se debe monitorear la distribución de entradas y la distribución de salidas/predicciones. La deriva de entrada proporciona una advertencia temprana si el resultado real se retrasa.

13. ¿Qué principio es esencial cuando se utiliza un LLM como juez para evaluar un sistema LLM?

A) El árbitro de LLM siempre tiene razón, la verificación humana es innecesaria
B) El árbitro debe tomar una decisión basándose únicamente en la longitud de la respuesta.
C) Los controles basados en reglas y la evaluación humana deben descartarse por completo cuando se utilizan árbitros.
D) Las puntuaciones de los jueces deben calibrarse con una muestra etiquetada por humanos y medirse su sesgo antes de que se pueda confiar en ellos ✔

Descripción: El árbitro de LLM también es modelo; Puede ser alucinatorio, sesgado (favoreciendo respuestas largas y seguras) e inconsistente. Por lo tanto, las puntuaciones de los árbitros deben calibrarse con una muestra humana etiquetada y su sesgo sistemático debe medirse antes de tomar la decisión de producción. Un árbitro no verificado da falsa confianza.

14. ¿Por qué es inadecuado observar la precisión general al evaluar el sesgo del modelo?

A) La precisión general es suficiente porque siempre refleja el desempeño del peor grupo.
B) La precisión general por sí sola es insuficiente ya que puede oscurecer la diferencia sistemática (discriminación oculta) entre subgrupos ✔
C) Porque la precisión es una métrica que no tiene nada que ver con el sesgo
D) El sesgo proviene únicamente del modelo y no tiene nada que ver con los datos.

Explicación: La precisión general puede ocultar las diferencias sistemáticas entre subgrupos. Por ejemplo, si bien la precisión general es del 88%, el recuerdo puede ser del 91% en un grupo y del 67% en otro grupo; El modelo pasa por alto sistemáticamente a ese grupo. Por lo tanto, el modelo debe evaluarse sobre la base de subgrupos (demográficos/segmentos) y qué definición de justicia debe priorizarse debe decidirse con las partes interesadas.

15. ¿Qué cuatro cosas deben combinarse para que un resultado de ML sea reproducible?

A) Sólo el nombre del modelo, tamaño, precio y fecha de lanzamiento.
B) Solo marca de GPU y velocidad de Internet
C) Sólo la puntuación de precisión final del modelo; el resto se puede guardar en la memoria
D) Semilla de aleatoriedad, versión de datos, entorno (versiones de dependencia) y seguimiento de experimentos ✔

Descripción: La reproducibilidad se logra a través de cuatro pilares: corregir semillas aleatorias, controlar las versiones de los datos (versión/hash), congelar el entorno (versiones exactas de la biblioteca/contenedor) y rastrear cada experimento (confirmación de código, datos, hiperparámetro, métrica). Sin esta cadena no es posible reproducir el mismo resultado; Un resultado no reproducible es una afirmación que no se puede probar.