¡Felicitaciones! Implementaste el modelo 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 compararlos de forma continua con los valores estadísticos esperados escribiendo reglas que los datos deben satisfacer. Esta colección de reglas se denomina esquema de datos. Sigue estos pasos para definir un esquema de datos:
Comprende el rango y la distribución de tus atributos. En el caso de los atributos categóricos, comprende el conjunto de valores posibles.
Codifica tu comprensión en el esquema de datos. Los siguientes son ejemplos de reglas:
- Asegúrate de que las calificaciones que envían los usuarios siempre estén entre 1 y 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é configurado en un valor de un conjunto fijo de valores posibles.
Prueba tus datos en función del esquema de datos. Tu esquema debe detectar errores de datos, como los siguientes:
- Anomalías
- Valores inesperados de las 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 ingeniería de atributos. Por ejemplo, tu modelo se entrena en atributos numéricos normalizados en lugar de datos numéricos sin procesar. Debido a que los datos de atributos diseñados pueden ser muy diferentes de los datos de entrada sin procesar, debes verificarlos por separado.
Escribe pruebas de unidades en función de tu comprensión de los datos de ingeniería de atributos. Por ejemplo, puedes escribir pruebas de unidades para verificar condiciones como las siguientes:
- Todos los atributos numéricos se escalan, por ejemplo, entre 0 y 1.
- Los vectores codificados 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 las puntuaciones Z, el promedio de las puntuaciones Z debería ser 0.
- Los valores atípicos se controlan, por ejemplo, mediante escalamiento o recorte.
Verifica las métricas para encontrar porciones de datos importantes
A veces, un conjunto exitoso oculta un subconjunto que no tuvo éxito. En otras palabras, un modelo con métricas generales excelentes podría hacer predicciones terribles en ciertas situaciones. Por ejemplo:
Tu modelo de unicornio tiene un buen rendimiento en general, pero tiene un rendimiento bajo cuando hace predicciones para el desierto del Sahara.
Si eres el tipo de ingeniero que se siente satisfecho con una AUC general excelente, es posible que no notes los problemas del modelo en el desierto del Sahara. Si es importante realizar buenas predicciones para cada región, debes hacer un seguimiento del rendimiento de cada una. Los subconjuntos de datos, como el que corresponde al desierto del Sahara, se denominan slices de datos.
Identifica los segmentos de datos de interés. Luego, compara las métricas del modelo de estos segmentos de datos con las métricas de todo tu conjunto de datos. Comprobar que tu modelo tenga un buen rendimiento en todas las divisiones de datos ayuda a quitar el sesgo. Consulta Equidad: Cómo evaluar el sesgo para obtener más información.
Usa métricas del mundo real
Las métricas del modelo no miden necesariamente 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 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.
Cómo verificar si hay sesgos 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 |
|---|---|---|---|
| Desequilibrio de esquemas | Los datos de entrada de entrenamiento y entrega no se ajustan al mismo esquema. | El formato o la distribución de los datos de publicación cambian mientras el modelo sigue entrenando con datos antiguos. | Usa el mismo esquema para validar los datos de entrenamiento y entrega. Asegúrate de verificar por separado las estadísticas que no verifica tu esquema, como la fracción de valores faltantes. |
| Sesgo de atributos | Los datos generados por ingeniería difieren entre el entrenamiento y la entrega. | El código de ingeniería de atributos difiere entre el entrenamiento y la entrega, lo que produce datos de ingeniería diferentes. | Al igual que con el sesgo de esquema, aplica las mismas reglas estadísticas en los datos de entrenamiento y de entrega. Realiza un seguimiento de la cantidad de atributos sesgados detectados y de la proporción de ejemplos sesgados por atributo. |
Las causas del sesgo de entrenamiento y entrega pueden ser sutiles. Siempre considera qué datos están disponibles para tu modelo en el momento de la predicción. Durante el entrenamiento, usa solo las funciones que tendrás disponibles durante la publicación.
Ejercicio: Comprueba tu comprensión
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 con la cantidad de clientes como función.
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 una predicción sólida de tus ingresos diarios. En relación con esto, cuando entrenes un modelo y obtengas métricas de evaluación increíbles (como 0.99 en AUC), busca este tipo de características que puedan afectar tu etiqueta.
Cómo verificar si hay filtraciones de etiquetas
La filtración de etiquetas significa que las etiquetas de verdad fundamental que intentas predecir ingresaron, de forma inadvertida, en tus atributos de entrenamiento. A veces, la filtración de etiquetas es muy difícil de detectar.
Ejercicio: Comprueba tu comprensión
Supongamos que creas un modelo de clasificación binaria para predecir si un nuevo paciente del hospital tiene cáncer o no. Tu modelo usa funciones como las siguientes:
- Edad del paciente
- Género del paciente
- Condiciones médicas previas
- Nombre del hospital
- Signos vitales
- Resultados de la prueba
- Herencia
La etiqueta es la siguiente:
- Booleano: ¿El paciente tiene cáncer?
Particionas los datos con cuidado y te aseguras de que el conjunto de entrenamiento esté bien aislado del conjunto de validación y del conjunto 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 muy bajo en pacientes nuevos en el mundo real.
Respuesta: Una de las características 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 era muy probable que los pacientes asignados a ciertos hospitales tuvieran 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 se habían asignado 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. En consecuencia, durante la inferencia, la función de 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 en toda la canalización
Si los datos de publicación evolucionan con el tiempo, pero tu modelo no se vuelve a entrenar con regularidad, verás una disminución en la calidad del modelo. Haz un seguimiento del tiempo desde que se volvió a entrenar el modelo con datos nuevos y establece un umbral de antigüedad para las alertas. Además de supervisar la edad del modelo en la entrega, debes supervisar la edad del modelo a lo largo de la canalización para detectar interrupciones.
Prueba que los pesos y los resultados del modelo sean numéricamente estables
Durante el entrenamiento del modelo, los pesos y las salidas de la capa no deben ser NaN (no es un número) ni Inf (infinito). Escribe pruebas para verificar si hay valores NaN e Inf en tus pesos y resultados 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. Estás recibiendo muchas solicitudes de predicción y aún más datos de entrenamiento. Crees que es genial hasta que te das cuenta de que tu modelo está tomando 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 por 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 versión nueva del modelo en comparación con la versión anterior y con un umbral fijo.
- Para detectar fugas de memoria, establece 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 consultas respondidas por segundo.
Prueba la calidad del modelo activo en los datos publicados
Validaste tu modelo. Pero ¿qué sucede si las situaciones del mundo real, como el comportamiento de unicornio, cambian después de registrar tus datos de validación? Luego, la calidad del modelo publicado se degradará. Sin embargo, probar la calidad de 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, ten en cuenta 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 de tu modelo. Por ejemplo, si clasificas spam, compara tus predicciones con el spam que informaron los usuarios.
Mitiga la posible divergencia entre los datos de entrenamiento y los de entrega a través de la entrega de una versión nueva del modelo en una fracción de tus consultas. A medida que valides tu nuevo modelo de publicación, cambia gradualmente todas las consultas a la versión nueva.
Cuando realices 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 quieres agregar una función 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 se pueda hacer de manera determinista:
- Proporciona un valor inicial para tus generadores de números aleatorios (RNG). La inicialización garantiza que la RNG muestre los mismos valores en el mismo orden cada vez que la ejecutas, lo que recrea tu conjunto de datos.
- Usa claves hash invariables. El 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 deben cambiar cada vez que ejecutas 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 los datos.
Consideraciones para el hash
Imagina de nuevo que recopilabas búsquedas y usabas el hash para incluir o excluir búsquedas. Si la clave hash solo usó la consulta, en varios días de datos, siempre incluirás esa consulta o la siempre excluirás. Siempre incluir o excluir una consulta es malo por los siguientes motivos:
- Tu conjunto de entrenamiento verá un conjunto menos diverso de consultas.
- Tus conjuntos de evaluación serán difíciles de forma artificial, 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 la consulta y la fecha, lo que generaría un hash diferente cada día.
