Preprocesamiento de datos para ML: opciones y recomendaciones

Este documento es el primero de una serie de dos partes que explora el tema de la ingeniería de datos y la ingeniería de características para el aprendizaje automático (ML), centrándose en las tareas de aprendizaje supervisado. Esta primera parte analiza las mejores prácticas para el preprocesamiento de datos en una canalización de ML en Google Cloud. El documento se centra en el uso de TensorFlow y la biblioteca de código abierto TensorFlow Transform ( tf.Transform ) para preparar datos, entrenar el modelo y servir el modelo para predicción. Este documento destaca los desafíos del preprocesamiento de datos para ML y describe las opciones y escenarios para realizar la transformación de datos en Google Cloud de manera efectiva.

En este documento se supone que estás familiarizado con BigQuery , Dataflow , Vertex AI y la API de TensorFlow Keras .

El segundo documento, Preprocesamiento de datos para ML con Google Cloud , proporciona un tutorial paso a paso sobre cómo implementar una canalización tf.Transform .

Introducción

ML le ayuda a encontrar automáticamente patrones complejos y potencialmente útiles en los datos. Estos patrones se condensan en un modelo de aprendizaje automático que luego se puede usar en nuevos puntos de datos, un proceso llamado hacer predicciones o realizar inferencias .

La creación de un modelo de ML es un proceso de varios pasos. Cada paso presenta sus propios desafíos técnicos y conceptuales. Esta serie de dos partes se centra en las tareas de aprendizaje supervisado y el proceso de selección, transformación y aumento de los datos de origen para crear poderosas señales predictivas para la variable objetivo. Estas operaciones combinan el conocimiento del dominio con técnicas de ciencia de datos. Las operaciones son la esencia de la ingeniería de características .

El tamaño de los conjuntos de datos de entrenamiento para modelos de aprendizaje automático del mundo real puede ser fácilmente igual o superior a un terabyte (TB). Por lo tanto, se necesitan marcos de procesamiento de datos a gran escala para poder procesar estos conjuntos de datos de manera eficiente y distribuida. Cuando usa un modelo de ML para hacer predicciones, debe aplicar las mismas transformaciones que usó para los datos de entrenamiento en los nuevos puntos de datos. Al aplicar las mismas transformaciones, presenta el conjunto de datos en vivo al modelo de ML de la manera que el modelo espera.

Este documento analiza estos desafíos para diferentes niveles de granularidad de las operaciones de ingeniería de características: agregaciones a nivel de instancia, de paso completo y de ventana de tiempo. Este documento también describe las opciones y escenarios para realizar la transformación de datos para ML en Google Cloud.

Este documento también proporciona una descripción general de TensorFlow Transform ( tf.Transform ), una biblioteca para TensorFlow que le permite definir la transformación de datos tanto a nivel de instancia como de paso completo a través de canalizaciones de preprocesamiento de datos. Estas canalizaciones se ejecutan con Apache Beam y crean artefactos que le permiten aplicar las mismas transformaciones durante la predicción que cuando se entrega el modelo.

Preprocesamiento de datos para ML

Esta sección presenta las operaciones de preprocesamiento de datos y las etapas de preparación de los datos. También analiza los tipos de operaciones de preprocesamiento y su granularidad.

Ingeniería de datos comparada con ingeniería de características

El preprocesamiento de datos para ML implica tanto ingeniería de datos como ingeniería de características. La ingeniería de datos es el proceso de convertir datos sin procesar en datos preparados . Luego, la ingeniería de funciones ajusta los datos preparados para crear las funciones que espera el modelo de ML. Estos términos tienen los siguientes significados:

Datos sin procesar (o solo datos )

Los datos en su forma fuente, sin ninguna preparación previa para ML. En este contexto, los datos pueden estar en su forma original (en un lago de datos) o en forma transformada (en un almacén de datos). Los datos transformados que se encuentran en un almacén de datos pueden haberse convertido de su forma original sin procesar para utilizarlos en análisis. Sin embargo, en este contexto, los datos sin procesar significan que los datos no se han preparado específicamente para su tarea de aprendizaje automático. Los datos también se consideran datos sin procesar si se envían desde sistemas de transmisión que eventualmente llaman a modelos de aprendizaje automático para realizar predicciones.

Datos preparados

El conjunto de datos en el formulario está listo para su tarea de aprendizaje automático: las fuentes de datos se han analizado, unido y puesto en forma tabular. Los datos preparados se agregan y se resumen con la granularidad adecuada; por ejemplo, cada fila del conjunto de datos representa un cliente único y cada columna representa información resumida del cliente, como el total gastado en las últimas seis semanas. En una tabla de datos preparada, se eliminaron las columnas irrelevantes y se filtraron los registros no válidos. Para tareas de aprendizaje supervisadas, la función de destino está presente.

Funciones diseñadas

El conjunto de datos con las características ajustadas que espera el modelo, es decir, características que se crean al realizar ciertas operaciones específicas de ML en las columnas del conjunto de datos preparado y crear nuevas características para su modelo durante el entrenamiento y la predicción, como se describe más adelante. en Operaciones de preprocesamiento . Ejemplos de estas operaciones incluyen escalar columnas numéricas a un valor entre 0 y 1, recortar valores y características categóricas de codificación única .

El siguiente diagrama, figura 1, muestra los pasos que intervienen en la preparación de datos preprocesados:

Figura 1. El flujo de datos desde datos sin procesar hasta datos preparados, funciones de ingeniería y aprendizaje automático.

En la práctica, los datos de la misma fuente suelen encontrarse en diferentes etapas de preparación. Por ejemplo, un campo de una tabla en su almacén de datos podría usarse directamente como una característica de ingeniería. Al mismo tiempo, es posible que otro campo de la misma tabla deba pasar por transformaciones antes de que se convierta en una característica de ingeniería. De manera similar, las operaciones de ingeniería de datos y de ingeniería de características podrían combinarse en el mismo paso de preprocesamiento de datos.

Operaciones de preprocesamiento

El preprocesamiento de datos incluye varias operaciones. Cada operación está diseñada para ayudar a ML a construir mejores modelos predictivos. Los detalles de estas operaciones de preprocesamiento están fuera del alcance de este documento, pero algunas operaciones se describen brevemente en esta sección.

Para datos estructurados, las operaciones de preprocesamiento de datos incluyen lo siguiente:

• Limpieza de datos: eliminar o corregir registros que tienen valores corruptos o no válidos de los datos sin procesar y eliminar registros a los que les falta una gran cantidad de columnas.
• Selección y partición de instancias: selección de puntos de datos del conjunto de datos de entrada para crear conjuntos de entrenamiento, evaluación (validación) y prueba . Este proceso incluye técnicas de muestreo aleatorio repetible, sobremuestreo de clases minoritarias y partición estratificada.
• Ajuste de características: mejorar la calidad de una característica para ML, lo que incluye escalar y normalizar valores numéricos, imputar valores faltantes, recortar valores atípicos y ajustar valores que tienen distribuciones sesgadas.
• Transformación de características: convertir una característica numérica en una característica categórica (mediante cubetaización ) y convertir características categóricas en una representación numérica (mediante codificación one-hot, aprendizaje con recuentos , incrustaciones de características dispersas, etc.). Algunos modelos funcionan sólo con funciones numéricas o categóricas, mientras que otros pueden manejar funciones de tipo mixto. Incluso cuando los modelos manejan ambos tipos, pueden beneficiarse de diferentes representaciones (numéricas y categóricas) de la misma característica.
• Extracción de características: reducir la cantidad de características mediante la creación de representaciones de datos más poderosas y de menor dimensión utilizando técnicas como PCA , extracción de incrustación y hashing .
• Selección de funciones: seleccionar un subconjunto de las funciones de entrada para entrenar el modelo e ignorar las irrelevantes o redundantes, utilizando métodos de filtro o contenedor . La selección de funciones también puede implicar simplemente eliminar funciones si a las funciones les falta una gran cantidad de valores.
• Construcción de características: creación de nuevas características mediante el uso de técnicas típicas, como la expansión polinomial (mediante el uso de funciones matemáticas univariadas) o el cruce de características (para capturar interacciones de características). Las características también se pueden construir utilizando la lógica empresarial del dominio del caso de uso de ML.

Cuando se trabaja con datos no estructurados (por ejemplo, imágenes, audio o documentos de texto), el aprendizaje profundo reemplaza la ingeniería de características basada en el conocimiento del dominio incorporándola a la arquitectura del modelo. Una capa convolucional es un preprocesador de funciones automático. Construir la arquitectura del modelo correcto requiere cierto conocimiento empírico de los datos. Además, se necesita cierta cantidad de preprocesamiento, como el siguiente:

• Para documentos de texto: derivación y lematización , cálculo TF-IDF y extracción de n-gramas , búsqueda de incrustación.
• Para imágenes: recorte, cambio de tamaño, recorte, desenfoque gaussiano y filtros canarios.
• Para todo tipo de datos (incluidos texto e imágenes): transferencia de aprendizaje , que trata todas las capas, excepto las últimas, del modelo completamente entrenado como un paso de ingeniería de características.

Granularidad de preprocesamiento

Esta sección analiza la granularidad de los tipos de transformaciones de datos. Muestra por qué esta perspectiva es fundamental a la hora de preparar nuevos puntos de datos para predicciones mediante transformaciones que se aplican a los datos de entrenamiento.

Las operaciones de preprocesamiento y transformación se pueden clasificar de la siguiente manera, según la granularidad de la operación:

• Transformaciones a nivel de instancia durante el entrenamiento y la predicción . Estas son transformaciones sencillas, donde solo se necesitan valores de la misma instancia para la transformación. Por ejemplo, las transformaciones a nivel de instancia pueden incluir recortar el valor de una característica a algún umbral, expandir polinomialmente otra característica, multiplicar dos características o comparar dos características para crear un indicador booleano.

  Estas transformaciones deben aplicarse de manera idéntica durante el entrenamiento y la predicción, porque el modelo se entrenará en las características transformadas, no en los valores de entrada sin procesar. Si los datos no se transforman de manera idéntica, entonces el modelo se comporta mal porque se le presentan datos que tienen una distribución de valores con la que no fue entrenado. Para obtener más información, consulte la discusión sobre el sesgo de entrega de capacitación en la sección Desafíos de preprocesamiento .

• Transformaciones de paso completo durante el entrenamiento, pero transformaciones a nivel de instancia durante la predicción . En este escenario, las transformaciones tienen estado porque utilizan algunas estadísticas precalculadas para realizar la transformación. Durante el entrenamiento, se analiza todo el conjunto de datos de entrenamiento para calcular cantidades como mínimo, máximo, media y varianza para transformar los datos de entrenamiento, los datos de evaluación y los datos nuevos en el momento de la predicción.

  Por ejemplo, para normalizar una característica numérica para el entrenamiento, se calcula su media (μ) y su desviación estándar (σ) en todos los datos de entrenamiento. Este cálculo se denomina operación de paso completo (o análisis ). Cuando entrega el modelo para predicción, el valor de un nuevo punto de datos se normaliza para evitar un sesgo en el servicio de entrenamiento. Por lo tanto, los valores μ y σ que se calculan durante el entrenamiento se utilizan para ajustar el valor de la característica, que es la siguiente operación simple a nivel de instancia :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Las transformaciones de paso completo incluyen lo siguiente:

  • MinMax escala características numéricas utilizando el mínimo y el máximo calculados a partir del conjunto de datos de entrenamiento.
  • Características numéricas de escala estándar (normalización de puntuación z) utilizando μ y σ calculadas en el conjunto de datos de entrenamiento.
  • Dividir características numéricas mediante cuantiles.
  • Imputar valores faltantes utilizando la mediana (características numéricas) o la moda (características categóricas).
  • Conversión de cadenas (valores nominales) a números enteros (índices) extrayendo todos los valores distintos (vocabulario) de una característica categórica de entrada.
  • Contar la aparición de un término (valor de característica) en todos los documentos (instancias) para calcular TF-IDF.
  • Calcular el PCA de las características de entrada para proyectar los datos en un espacio de menor dimensión (con características linealmente dependientes).

  Debes usar solo los datos de entrenamiento para calcular estadísticas como μ, σ, min y max . Si agrega los datos de prueba y evaluación para estas operaciones, está filtrando información de los datos de evaluación y prueba para entrenar el modelo. Hacerlo afecta la confiabilidad de los resultados de la prueba y la evaluación. Para asegurarse de aplicar una transformación coherente a todos los conjuntos de datos, utilice las mismas estadísticas calculadas a partir de los datos de entrenamiento para transformar los datos de prueba y evaluación.

• Agregaciones históricas durante el entrenamiento y la predicción . Esto implica crear agregaciones, derivaciones e indicadores comerciales como señales de entrada para la tarea de predicción; por ejemplo, crear métricas de actualidad, frecuencia y monetarias (RFM) para que los clientes creen modelos de propensión. Estos tipos de funciones se pueden calcular previamente y almacenar en un almacén de funciones para utilizarlas durante el entrenamiento del modelo, la puntuación por lotes y la publicación de predicciones en línea. También puede realizar ingeniería de funciones adicionales (por ejemplo, transformación y ajuste) en estas agregaciones antes del entrenamiento y la predicción.

• Agregaciones históricas durante el entrenamiento, pero agregaciones en tiempo real durante la predicción . Este enfoque implica crear una característica resumiendo valores en tiempo real a lo largo del tiempo. En este enfoque, las instancias que se agregarán se definen mediante cláusulas de ventana temporal. Por ejemplo, puede utilizar este enfoque si desea entrenar un modelo que estime el tiempo de viaje en taxi en función de las métricas de tráfico de la ruta en los últimos 5 minutos, en los últimos 10 minutos, en los últimos 30 minutos y en otros intervalos. También puede utilizar este enfoque para predecir la falla de una pieza del motor basándose en el promedio móvil de los valores de temperatura y vibración calculados durante los últimos 3 minutos. Aunque estas agregaciones se pueden preparar fuera de línea para el entrenamiento, se calculan en tiempo real a partir de un flujo de datos durante el servicio.

  Más precisamente, cuando prepara datos de entrenamiento, si el valor agregado no está en los datos sin procesar, el valor se crea durante la fase de ingeniería de datos. Los datos sin procesar generalmente se almacenan en una base de datos con un formato de (entity, timestamp, value) . En los ejemplos anteriores, entity es el identificador del segmento de ruta para las rutas de rodaje y el identificador de la parte del motor para la falla del motor. Puede utilizar operaciones de ventanas para calcular (entity, time_index, aggregated_value_over_time_window) y utilizar las funciones de agregación como entrada para el entrenamiento de su modelo.

  Cuando se entrega el modelo para predicción en tiempo real (en línea), el modelo espera características derivadas de los valores agregados como entrada. Por lo tanto, puede utilizar una tecnología de procesamiento de flujo como Apache Beam para calcular las agregaciones a partir de los puntos de datos en tiempo real transmitidos a su sistema. La tecnología de procesamiento de flujo agrega datos en tiempo real basándose en ventanas de tiempo a medida que llegan nuevos puntos de datos. También puede realizar ingeniería de funciones adicionales (por ejemplo, transformación y ajuste) en estas agregaciones antes del entrenamiento y la predicción.

Canalización de aprendizaje automático en Google Cloud

En esta sección se analizan los componentes principales de una canalización típica de un extremo a otro para entrenar y ofrecer modelos de TensorFlow ML en Google Cloud mediante servicios administrados. También analiza dónde puede implementar diferentes categorías de operaciones de preprocesamiento de datos y los desafíos comunes que podría enfrentar al implementar dichas transformaciones. La sección Cómo funciona tf.Transform muestra cómo la biblioteca TensorFlow Transform ayuda a abordar estos desafíos.

Arquitectura de alto nivel

El siguiente diagrama, figura 2, muestra una arquitectura de alto nivel de una canalización de ML típica para entrenar y servir modelos de TensorFlow. Las etiquetas A, B y C en el diagrama se refieren a los diferentes lugares del proceso donde puede tener lugar el preprocesamiento de datos. Los detalles sobre estos pasos se proporcionan en la siguiente sección.

Figura 2. Arquitectura de alto nivel para la capacitación y el servicio de ML en Google Cloud.

El pipeline consta de los siguientes pasos:

1. Después de importar los datos sin procesar, los datos tabulares se almacenan en BigQuery y otros datos, como imágenes, audio y video, se almacenan en Cloud Storage. La segunda parte de esta serie utiliza datos tabulares almacenados en BigQuery como ejemplo.
2. La ingeniería de datos (preparación) y la ingeniería de características se ejecutan a escala utilizando Dataflow. Esta ejecución produce conjuntos de prueba, evaluación y capacitación listos para ML que se almacenan en Cloud Storage. Idealmente, estos conjuntos de datos se almacenan como archivos TFRecord , que es el formato optimizado para los cálculos de TensorFlow.
3. Se envía un paquete de entrenador de modelos TensorFlow a Vertex AI Training, que utiliza los datos preprocesados ​​de los pasos anteriores para entrenar el modelo. El resultado de este paso es un TensorFlow SavedModel entrenado que se exporta a Cloud Storage.
4. El modelo TensorFlow entrenado se implementa en Vertex AI Prediction como un servicio que tiene una API REST para que pueda usarse para predicciones en línea. El mismo modelo también se puede utilizar para trabajos de predicción por lotes.
5. Una vez que el modelo se implementa como API REST, las aplicaciones cliente y los sistemas internos pueden invocar la API enviando solicitudes con algunos puntos de datos y recibiendo respuestas del modelo con predicciones.
6. Para orquestar y automatizar esta canalización, puede utilizar Vertex AI Pipelines como programador para invocar los pasos de preparación de datos, entrenamiento de modelos e implementación de modelos.

También puede utilizar Vertex AI Feature Store para almacenar funciones de entrada para hacer predicciones. Por ejemplo, puede crear periódicamente funciones diseñadas a partir de los datos sin procesar más recientes y almacenarlas en Vertex AI Feature Store. Las aplicaciones cliente obtienen las funciones de entrada requeridas de Vertex AI Feature Store y las envían al modelo para recibir predicciones.

Dónde hacer el preprocesamiento

En la figura 2, las etiquetas A, B y C muestran que las operaciones de preprocesamiento de datos pueden tener lugar en BigQuery, Dataflow o TensorFlow. Las siguientes secciones describen cómo funciona cada una de estas opciones.

Opción A: BigQuery

Normalmente, la lógica se implementa en BigQuery para las siguientes operaciones:

• Muestreo: seleccionar aleatoriamente un subconjunto de los datos.
• Filtrado: eliminar instancias irrelevantes o no válidas.
• Partición: dividir los datos para producir conjuntos de entrenamiento, evaluación y prueba.

Los scripts SQL de BigQuery se pueden usar como consulta de origen para el proceso de preprocesamiento de Dataflow, que es el paso de procesamiento de datos en la figura 2. Por ejemplo, si se usa un sistema en Canadá y el almacén de datos tiene transacciones de todo el mundo, filtrar a La mejor manera de obtener datos de entrenamiento solo para Canadá es BigQuery. La ingeniería de funciones en BigQuery es simple y escalable, y admite la implementación de transformaciones de funciones de agregaciones históricas y a nivel de instancia.

Sin embargo, le recomendamos que use BigQuery para la ingeniería de funciones solo si usa su modelo para la predicción por lotes (puntuación) o si las funciones se calculan previamente en BigQuery, pero se almacenan en Vertex AI Feature Store para usarse durante la predicción en línea. Si planea implementar el modelo para predicciones en línea y no tiene la característica diseñada en una tienda de características en línea, debe replicar las operaciones de preprocesamiento de SQL para transformar los puntos de datos sin procesar que generan otros sistemas. En otras palabras, debes implementar la lógica dos veces: una vez en SQL para preprocesar los datos de entrenamiento en BigQuery y una segunda vez en la lógica de la aplicación que consume el modelo para preprocesar los puntos de datos en línea para la predicción.

Por ejemplo, si su aplicación cliente está escrita en Java, deberá volver a implementar la lógica en Java. Esto puede introducir errores debido a discrepancias en la implementación, como se describe en la sección de sesgo en la prestación de capacitación de Desafíos de preprocesamiento más adelante en este documento. También supone una sobrecarga adicional mantener dos implementaciones diferentes. Siempre que cambie la lógica en SQL para preprocesar los datos de entrenamiento, deberá cambiar la implementación de Java en consecuencia para preprocesar los datos en el momento de la entrega.

Si usa su modelo solo para la predicción por lotes (por ejemplo, usando la predicción por lotes de Vertex AI) y si sus datos para la puntuación provienen de BigQuery, puede implementar estas operaciones de preprocesamiento como parte del script SQL de BigQuery. En ese caso, puede utilizar el mismo script SQL de preprocesamiento para preparar datos de entrenamiento y puntuación.

Las transformaciones con estado de paso completo no son adecuadas para implementarse en BigQuery. Si usa BigQuery para transformaciones de paso completo, necesita tablas auxiliares para almacenar las cantidades necesarias para las transformaciones con estado, como medias y varianzas para escalar características numéricas. Además, la implementación de transformaciones de paso completo usando SQL en BigQuery crea una mayor complejidad en los scripts SQL y crea una dependencia compleja entre el entrenamiento y los scripts SQL de puntuación.

Opción B: flujo de datos

Como se muestra en la figura 2, puede implementar operaciones de preprocesamiento computacionalmente costosas en Apache Beam y ejecutarlas a escala utilizando Dataflow. Dataflow es un servicio de escalado automático totalmente administrado para el procesamiento de datos por lotes y en streaming. Cuando usas Dataflow, también puedes usar bibliotecas especializadas externas para el procesamiento de datos, a diferencia de BigQuery.

Dataflow puede realizar transformaciones a nivel de instancia y transformaciones de funciones de agregación históricas y en tiempo real. En particular, si sus modelos de aprendizaje automático esperan una característica de entrada como total_number_of_clicks_last_90sec , las funciones de ventanas de Apache Beam pueden calcular estas características basándose en la agregación de los valores de las ventanas de tiempo de los datos de eventos (transmisión) en tiempo real (por ejemplo, eventos de clic). En la discusión anterior sobre la granularidad de las transformaciones , esto se denominó "Agregaciones históricas durante el entrenamiento, pero agregaciones en tiempo real durante la predicción".

El siguiente diagrama, figura 3, muestra la función de Dataflow en el procesamiento de datos de flujo para predicciones casi en tiempo real.

Figura 3. Arquitectura de alto nivel que utiliza datos de flujo para predicción en Dataflow.

Como se muestra en la figura 3, durante el procesamiento, los eventos llamados puntos de datos se incorporan a Pub/Sub . Dataflow consume estos puntos de datos, calcula características basadas en agregados a lo largo del tiempo y luego llama a la API del modelo ML implementado para realizar predicciones. Luego, las predicciones se envían a una cola Pub/Sub saliente. Desde Pub/Sub, las predicciones pueden ser consumidas por sistemas posteriores, como monitoreo o control, o pueden enviarse (por ejemplo, como notificaciones) al cliente solicitante original. Las predicciones también se pueden almacenar en un almacén de datos de baja latencia como Cloud Bigtable para recuperarlas en tiempo real. Cloud Bigtable también se puede utilizar para acumular y almacenar estas agregaciones en tiempo real para poder buscarlas cuando sea necesario para realizar predicciones.

La misma implementación de Apache Beam se puede utilizar para procesar por lotes datos de entrenamiento que provienen de un almacén de datos fuera de línea como BigQuery y procesar datos en tiempo real para ofrecer predicciones en línea.

En otras arquitecturas típicas, como la arquitectura que se muestra en la figura 2, la aplicación cliente llama directamente a la API del modelo implementado para realizar predicciones en línea. En ese caso, si se implementan operaciones de preprocesamiento en Dataflow para preparar los datos de entrenamiento, las operaciones no se aplican a los datos de predicción que van directamente al modelo. Por lo tanto, transformaciones como estas deben integrarse en el modelo durante la publicación de predicciones en línea.

El flujo de datos se puede utilizar para realizar una transformación de paso completo, calculando las estadísticas requeridas a escala. Sin embargo, estas estadísticas deben almacenarse en algún lugar para usarse durante la predicción para transformar los puntos de datos de predicción. Al utilizar la biblioteca TensorFlow Transform ( tf.Transform ), puede incrustar directamente estas estadísticas en el modelo en lugar de almacenarlas en otro lugar. Este enfoque se explica más adelante en Cómo funciona tf.Transform .

Opción C: TensorFlow

Como se muestra en la figura 2, puede implementar operaciones de transformación y preprocesamiento de datos en el propio modelo de TensorFlow. Como se muestra en la figura, el preprocesamiento que implementa para entrenar el modelo TensorFlow se convierte en una parte integral del modelo cuando el modelo se exporta e implementa para predicciones. Las transformaciones en el modelo TensorFlow se pueden lograr de una de las siguientes maneras:

• Implementar toda la lógica de transformación a nivel de instancia en la función input_fn y en la función serving_fn . La función input_fn prepara un conjunto de datos utilizando la API tf.data.Dataset para entrenar un modelo. La función serving_fn recibe y prepara los datos para las predicciones.
• Poner el código de transformación directamente en su modelo de TensorFlow utilizando capas de preprocesamiento de Keras o creando capas personalizadas .

El código de lógica de transformación en la función serving_fn define la interfaz de servicio de su SavedModel para la predicción en línea. Si implementa las mismas transformaciones que se usaron para preparar los datos de entrenamiento en el código lógico de transformación de la función serving_fn , se garantiza que se apliquen las mismas transformaciones a los nuevos puntos de datos de predicción cuando se entreguen.

Sin embargo, debido a que el modelo TensorFlow procesa cada punto de datos de forma independiente o en un lote pequeño, no se pueden calcular agregaciones a partir de todos los puntos de datos. Como resultado, las transformaciones de paso completo no se pueden implementar en su modelo de TensorFlow.

Desafíos de preprocesamiento

Los siguientes son los principales desafíos de la implementación del preprocesamiento de datos:

• "Sesgo de servicio de formación" . El sesgo de entrenamiento-servicio se refiere a una diferencia entre efectividad (rendimiento predictivo) durante el entrenamiento y durante el servicio. Este sesgo puede deberse a una discrepancia entre la forma en que se manejan los datos en las canalizaciones de capacitación y de servicio. Por ejemplo, si su modelo está entrenado en una característica transformada logarítmicamente, pero se le presenta la característica sin procesar durante la publicación, es posible que el resultado de la predicción no sea preciso.

  Si las transformaciones pasan a formar parte del modelo en sí, puede resultar sencillo manejar las transformaciones a nivel de instancia, como se describió anteriormente en la Opción C: TensorFlow . En ese caso, la interfaz de servicio del modelo (la función serving_fn ) espera datos sin procesar, mientras que el modelo transforma internamente estos datos antes de calcular la salida. Las transformaciones son las mismas que se aplicaron en los puntos de datos de predicción y entrenamiento sin procesar.

• Transformaciones de paso completo . No puede implementar transformaciones de paso completo, como transformaciones de escalado y normalización, en su modelo de TensorFlow. En las transformaciones de paso completo, algunas estadísticas (por ejemplo, valores max y min para escalar características numéricas) se deben calcular de antemano en los datos de entrenamiento, como se describe en Opción B: Flujo de datos . Luego, los valores deben almacenarse en algún lugar para usarse durante la entrega del modelo para que la predicción transforme los nuevos puntos de datos sin procesar como transformaciones a nivel de instancia, lo que evita el sesgo en la entrega de entrenamiento. Puede utilizar la biblioteca TensorFlow Transform ( tf.Transform ) para incrustar directamente las estadísticas en su modelo de TensorFlow. Este enfoque se explica más adelante en Cómo funciona tf.Transform .

• Preparar los datos por adelantado para una mejor eficiencia del entrenamiento . La implementación de transformaciones a nivel de instancia como parte del modelo puede degradar la eficiencia del proceso de capacitación. Esta degradación se produce porque las mismas transformaciones se aplican repetidamente a los mismos datos de entrenamiento en cada época. Imagine que tiene datos de entrenamiento sin procesar con 1000 funciones y aplica una combinación de transformaciones a nivel de instancia para generar 10 000 funciones. Si implementa estas transformaciones como parte de su modelo y luego alimenta el modelo con los datos de entrenamiento sin procesar, estas 10,000 operaciones se aplican N veces en cada instancia, donde N es el número de épocas. Además, si utiliza aceleradores (GPU o TPU), permanecen inactivos mientras la CPU realiza esas transformaciones, lo que no constituye un uso eficiente de sus costosos aceleradores.

  Idealmente, los datos de entrenamiento se transforman antes del entrenamiento, utilizando la técnica descrita en Opción B: Flujo de datos , donde las 10 000 operaciones de transformación se aplican solo una vez en cada instancia de entrenamiento. Luego, los datos de entrenamiento transformados se presentan al modelo. No se aplican más transformaciones y los aceleradores están ocupados todo el tiempo. Además, usar Dataflow te ayuda a preprocesar grandes cantidades de datos a escala mediante un servicio totalmente administrado.

  Preparar los datos de entrenamiento por adelantado puede mejorar la eficiencia del entrenamiento. Sin embargo, implementar la lógica de transformación fuera del modelo (los enfoques descritos en la Opción A: BigQuery o la Opción B: Flujo de datos ) no resuelve el problema del sesgo en la entrega de entrenamiento. A menos que almacene la característica diseñada en el almacén de características para usarla tanto para el entrenamiento como para la predicción, la lógica de transformación debe implementarse en algún lugar para aplicarse a los nuevos puntos de datos que vienen para la predicción, porque la interfaz del modelo espera datos transformados. La biblioteca TensorFlow Transform ( tf.Transform ) puede ayudarle a solucionar este problema, como se describe en la siguiente sección.

Cómo funciona tf.Transform

La biblioteca tf.Transform es útil para transformaciones que requieren un pase completo. El resultado de la biblioteca tf.Transform se exporta como un gráfico de TensorFlow que representa la lógica de transformación a nivel de instancia y las estadísticas calculadas a partir de transformaciones de paso completo, que se utilizarán para el entrenamiento y el servicio. Usar el mismo gráfico tanto para el entrenamiento como para el servicio puede evitar sesgos, porque se aplican las mismas transformaciones en ambas etapas. Además, la biblioteca tf.Transform se puede ejecutar a escala en una canalización de procesamiento por lotes en Dataflow para preparar los datos de entrenamiento por adelantado y mejorar la eficiencia del entrenamiento.

El siguiente diagrama, figura 4, muestra cómo la biblioteca tf.Transform preprocesa y transforma datos para entrenamiento y predicción. El proceso se describe en las siguientes secciones.

Figura 4. Comportamiento de tf.Transform para preprocesar y transformar datos.

Transforme los datos de capacitación y evaluación

Los datos de entrenamiento sin procesar se preprocesan mediante la transformación implementada en las API tf.Transform Apache Beam y se ejecutan a escala en Dataflow. El preprocesamiento se produce en las siguientes fases:

• Fase de análisis: durante la fase de análisis, las estadísticas requeridas (como medias, varianzas y cuantiles) para las transformaciones con estado se calculan en los datos de entrenamiento con operaciones de paso completo. Esta fase produce un conjunto de artefactos de transformación, incluido el gráfico transform_fn . El gráfico transform_fn es un gráfico de TensorFlow que tiene la lógica de transformación como operaciones a nivel de instancia. Incluye las estadísticas calculadas en la fase de análisis como constantes.
• Fase de transformación: durante la fase de transformación, el gráfico transform_fn se aplica a los datos de entrenamiento sin procesar, donde las estadísticas calculadas se utilizan para procesar los registros de datos (por ejemplo, para escalar columnas numéricas) a nivel de instancia.

Un enfoque de dos fases como este aborda el desafío del preprocesamiento de realizar transformaciones de paso completo.

Cuando los datos de evaluación se preprocesan, solo se aplican operaciones a nivel de instancia, utilizando la lógica en el gráfico transform_fn y las estadísticas calculadas a partir de la fase de análisis en los datos de entrenamiento. En otras palabras, no se analizan los datos de evaluación en forma completa para calcular nuevas estadísticas, como μ y σ, para normalizar las características numéricas en los datos de evaluación. En su lugar, utiliza las estadísticas calculadas a partir de los datos de entrenamiento para transformar los datos de evaluación a nivel de instancia.

Los datos de entrenamiento y evaluación transformados se preparan a escala utilizando Dataflow, antes de usarlos para entrenar el modelo. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( input_fn & serving_fn )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .