¡Felicitaciones! Implementaste el modelo de unicornio. Tu modelo debería ejecutarse las 24 horas, todos los días, sin problemas. Para asegurarte de que lo haga, debes supervisar tu canalización de aprendizaje automático (AA).
Escribe un esquema de datos para validar los datos sin procesar
Para supervisar tus datos, debes verificarlos continuamente en relación con los valores estadísticos esperados escribiendo reglas que los datos deben satisfacer. Esta colección de reglas se denomina esquema de datos. Para definir un esquema de datos, sigue estos pasos:
Comprende el rango y la distribución de tus atributos. Para los atributos categóricos, comprender el conjunto de valores posibles
Codifica tu comprensión en el esquema de datos. A continuación, se muestran ejemplos de reglas:
- Asegúrate de que las calificaciones enviadas por los usuarios siempre estén en el rango de 1 a 5.
- Verifica que la palabra the aparezca con mayor frecuencia (para una función de texto en inglés).
- Verifica que cada atributo categórico esté establecido en un valor de un conjunto fijo de valores posibles.
Prueba tus datos con el esquema de datos. Tu esquema debe detectar errores de datos, como los siguientes:
- Anomalías
- Valores inesperados de variables categóricas
- Distribuciones de datos inesperadas
Escribe pruebas de unidades para validar la ingeniería de atributos
Si bien tus datos sin procesar pueden pasar el esquema de datos, tu modelo no se entrena con datos sin procesar. En cambio, tu modelo se entrena con datos que se sometieron a ingeniería de atributos. Por ejemplo, tu modelo se entrena con atributos numéricos normalizados en lugar de datos numéricos sin procesar. Dado que los datos creados con ingeniería de atributos pueden ser muy diferentes de los datos de entrada sin procesar, debes verificar los datos creados con ingeniería de atributos por separado de las verificaciones de los datos de entrada sin procesar.
Escribe pruebas de unidades según tu comprensión de los datos diseñados con ingeniería de atributos. Por ejemplo, puedes escribir pruebas de unidades para verificar condiciones como las siguientes:
- Todas las características numéricas se ajustan, por ejemplo, entre 0 y 1.
- Los vectores con codificación one-hot solo contienen un 1 y N-1 ceros.
- Las distribuciones de datos después de la transformación cumplen con las expectativas. Por ejemplo, si normalizaste los datos con puntuaciones Z, la media de las puntuaciones Z debería ser 0.
- Se controlan los valores atípicos, por ejemplo, mediante el escalamiento o el recorte.
Verifica las métricas para encontrar porciones de datos importantes
A veces, un todo exitoso oculta un subconjunto fallido. En otras palabras, un modelo con métricas generales excelentes podría seguir haciendo predicciones terribles para ciertas situaciones. Por ejemplo:
Tu modelo de unicornios tiene un buen rendimiento en general, pero no es bueno cuando hace predicciones para el desierto del Sahara.
Si eres el tipo de ingeniero que se conforma con un AUC general excelente, es posible que no notes los problemas del modelo en el desierto del Sahara. Si es importante hacer buenas predicciones para cada región, debes hacer un seguimiento del rendimiento en cada una de ellas. Los subconjuntos de datos, como el que corresponde al desierto del Sahara, se denominan segmentos de datos.
Identifica las segmentaciones de datos de interés. Luego, compara las métricas del modelo para estas segmentaciones de datos con las métricas de todo tu conjunto de datos. Comprobar que tu modelo funcione bien en todas las segmentaciones de datos ayuda a eliminar la parcialidad. Consulta Equidad: Evaluación del sesgo para obtener más información.
Usa métricas del mundo real
Las métricas del modelo no necesariamente miden el impacto real de tu modelo. Por ejemplo, cambiar un hiperparámetro podría aumentar el AUC de un modelo, pero ¿cómo afectó el cambio a la experiencia del usuario? Para medir el impacto en el mundo real, debes definir métricas independientes. Por ejemplo, podrías encuestar a los usuarios de tu modelo para confirmar que realmente vieron un unicornio cuando el modelo predijo que lo harían.
Verifica si hay sesgo entre el entrenamiento y la entrega
El sesgo entre el entrenamiento y la entrega significa que los datos de entrada durante el entrenamiento difieren de los datos de entrada en la entrega. En la siguiente tabla, se describen los dos tipos importantes de sesgo:
| Tipo | Definición | Ejemplo | Solución |
|---|---|---|---|
| Sesgo del esquema | Los datos de entrada de entrenamiento y de entrega no se ajustan al mismo esquema. | El formato o la distribución de los datos de entrega cambian mientras tu modelo sigue entrenándose con datos antiguos. | Usa el mismo esquema para validar los datos de entrenamiento y de entrega. Asegúrate de verificar por separado las estadísticas que no revisa tu esquema, como la fracción de valores faltantes. |
| Sesgo de atributos | Los datos diseñados difieren entre el entrenamiento y la entrega. | El código de ingeniería de atributos difiere entre el entrenamiento y la entrega, lo que genera datos procesados diferentes. | Al igual que con el sesgo de esquema, aplica las mismas reglas estadísticas a los datos diseñados de entrenamiento y de entrega. Realiza un seguimiento de la cantidad de atributos sesgados detectados y la proporción de ejemplos sesgados por atributo. |
Las causas del sesgo entre el entrenamiento y la entrega pueden ser sutiles. Siempre ten en cuenta qué datos están disponibles para tu modelo en el momento de la predicción. Durante el entrenamiento, usa solo las funciones que estarán disponibles cuando se realice la entrega.
Ejercicio: Comprueba tus conocimientos
Supongamos que tienes una tienda en línea y quieres predecir cuánto dinero ganarás en un día determinado. Tu objetivo de AA es predecir los ingresos diarios usando la cantidad de clientes como atributo.
Respuesta: El problema es que no conoces la cantidad de clientes en el momento de la predicción, antes de que se completen las ventas del día. Por lo tanto, esta función no es útil, incluso si es un buen predictor de tus ingresos diarios. De manera similar, cuando entrenes un modelo y obtengas métricas de evaluación increíbles (como 0.99 de AUC), busca este tipo de características que puedan filtrarse en tu etiqueta.
Verifica si hay filtración de etiquetas
La filtración de etiquetas significa que las etiquetas de verdad fundamental que intentas predecir se ingresaron de forma inadvertida en tus atributos de entrenamiento. A veces, la filtración de etiquetas es muy difícil de detectar.
Ejercicio: Comprueba tus conocimientos
Supongamos que creas un modelo de clasificación binaria para predecir si un paciente nuevo del hospital tiene cáncer o no. Tu modelo usa características como las siguientes:
- Edad del paciente
- Género del paciente
- Afecciones médicas previas
- Nombre del hospital
- Signos vitales
- Resultados de la prueba
- Herencia
La etiqueta es la siguiente:
- Booleano: ¿El paciente tiene cáncer?
Particiona los datos con cuidado y asegúrate de que tu conjunto de entrenamiento esté bien aislado de tu conjunto de validación y de prueba. El modelo funciona muy bien en el conjunto de validación y en el conjunto de prueba; las métricas son fantásticas. Lamentablemente, el modelo tiene un rendimiento pésimo con pacientes nuevos en el mundo real.
Respuesta: Uno de los atributos del modelo es el nombre del hospital. Algunos hospitales se especializan en el tratamiento del cáncer. Durante el entrenamiento, el modelo aprendió rápidamente que los pacientes asignados a ciertos hospitales tenían muchas probabilidades de tener cáncer. Por lo tanto, el nombre del hospital se convirtió en un atributo con una ponderación alta.
En el momento de la inferencia, la mayoría de los pacientes aún no habían sido asignados a un hospital. Después de todo, el propósito del modelo era diagnosticar la presencia o ausencia de cáncer y, luego, usar ese diagnóstico para asignar al paciente a un hospital adecuado. Por lo tanto, durante la inferencia, el atributo del nombre del hospital aún no estaba disponible y el modelo se vio obligado a depender de otros atributos.
Supervisa la antigüedad del modelo a lo largo de la canalización
Si los datos de entrega evolucionan con el tiempo, pero tu modelo no se vuelve a entrenar con regularidad, verás una disminución en la calidad del modelo. Realiza un seguimiento del tiempo transcurrido desde que se volvió a entrenar el modelo con datos nuevos y establece una antigüedad límite para las alertas. Además de supervisar la antigüedad del modelo en la etapa de entrega, debes supervisar la antigüedad del modelo en toda la canalización para detectar interrupciones.
Probar que los pesos y los resultados del modelo sean estables numéricamente
Durante el entrenamiento del modelo, los pesos y las salidas de las capas no deben ser NaN (no es un número) ni Inf (infinito). Escribe pruebas para verificar los valores NaN y los valores Inf de tus pesos y salidas de capas. Además, prueba que más de la mitad de los resultados de una capa no sean cero.
Supervisa el rendimiento del modelo
Tu predictor de aparición de unicornios fue más popular de lo esperado. Recibes muchas solicitudes de predicción y aún más datos de entrenamiento. Crees que eso es genial hasta que te das cuenta de que tu modelo requiere cada vez más memoria y tiempo para entrenarse. Decides supervisar el rendimiento de tu modelo siguiendo estos pasos:
- Realiza un seguimiento del rendimiento del modelo según las versiones de código, modelo y datos. Este seguimiento te permite identificar la causa exacta de cualquier degradación del rendimiento.
- Prueba los pasos de entrenamiento por segundo de una nueva versión del modelo en comparación con la versión anterior y con un umbral fijo.
- Detecta fugas de memoria estableciendo un umbral para el uso de memoria.
- Supervisa los tiempos de respuesta de la API y haz un seguimiento de sus percentiles. Si bien los tiempos de respuesta de la API pueden estar fuera de tu control, las respuestas lentas podrían generar métricas deficientes en el mundo real.
- Supervisa la cantidad de preguntas respondidas por segundo.
Probar la calidad del modelo activo en los datos publicados
Validaste tu modelo. Pero, ¿qué sucede si los escenarios del mundo real, como el comportamiento de los unicornios, cambian después de registrar tus datos de validación? Entonces, la calidad de tu modelo publicado se degradará. Sin embargo, probar la calidad en la publicación es difícil porque los datos del mundo real no siempre están etiquetados. Si tus datos de publicación no están etiquetados, considera estas pruebas:
Investiga los modelos que muestran un sesgo estadístico significativo en las predicciones. Consulta Clasificación: Sesgo de predicción.
Realiza un seguimiento de las métricas del mundo real para tu modelo. Por ejemplo, si clasificas spam, compara tus predicciones con el spam que denunciaron los usuarios.
Mitiga la posible divergencia entre los datos de entrenamiento y los de entrega publicando una nueva versión del modelo en una fracción de tus búsquedas. A medida que valides tu nuevo modelo de entrega, cambia gradualmente todas las búsquedas a la nueva versión.
Cuando uses estas pruebas, recuerda supervisar la degradación repentina y lenta de la calidad de la predicción.
Aleatorización
Haz que tu canalización de generación de datos sea reproducible. Supongamos que deseas agregar un atributo para ver cómo afecta la calidad del modelo. Para que el experimento sea justo, tus conjuntos de datos deben ser idénticos, excepto por esta nueva función. En ese sentido, asegúrate de que cualquier aleatorización en la generación de datos pueda ser determinística:
- Inicializa tus generadores de números aleatorios (RNG). La inicialización garantiza que el RNG genere los mismos valores en el mismo orden cada vez que lo ejecutes, lo que recrea tu conjunto de datos.
- Usa claves hash invariantes. El algoritmo hash es una forma común de dividir o muestrear datos. Puedes generar un hash para cada ejemplo y usar el número entero resultante para decidir en qué división colocar el ejemplo. Las entradas de tu función hash no deberían cambiar cada vez que ejecutes el programa de generación de datos. No uses la hora actual ni un número aleatorio en tu hash, por ejemplo, si deseas volver a crear tus hashes a pedido.
Los enfoques anteriores se aplican tanto al muestreo como a la división de tus datos.
Consideraciones para el hashing
Imagina de nuevo que recopilaste búsquedas y usaste el hash para incluirlas o excluirlas. Si la clave hash solo usara la búsqueda, en varios días de datos, siempre incluirías esa búsqueda o siempre la excluirías. Siempre incluir o siempre excluir una búsqueda es malo por los siguientes motivos:
- Tu conjunto de entrenamiento verá un conjunto menos diverso de búsquedas.
- Tus conjuntos de evaluación serán artificialmente difíciles, ya que no se superpondrán con tus datos de entrenamiento. En realidad, en el momento de la publicación, habrás visto parte del tráfico en vivo en tus datos de entrenamiento, por lo que tu evaluación debería reflejar eso.
En su lugar, puedes generar un hash en función de la búsqueda y la fecha de la búsqueda, lo que generaría un hash diferente para cada día.
