Patrones de arquitectura de sistemas de IA

Un sistema de IA para producción es mucho más que un archivo de modelo. Incluye canalizaciones de datos, feature stores, infraestructura de serving y monitorización. Los patrones de arquitectura son diseños probados para ensamblar estas piezas de forma fiable.

Los sistemas de IA suelen necesitar ambos tipos:

• Procesamiento por lotes para obtener resultados precisos y completos sobre datos históricos
• Procesamiento en tiempo real para obtener resultados recientes y con baja latencia sobre eventos nuevos

Conciliar estas dos necesidades es un desafío de diseño recurrente.

La arquitectura Lambda resuelve esto con dos capas que se ejecutan en paralelo: una capa de procesamiento por lotes que vuelve a calcular vistas precisas sobre todos los datos, y una capa de velocidad que gestiona los datos recientes con baja latencia. Una capa de serving combina ambas para las consultas.

La capa de procesamiento por lotes vuelve a procesar periódicamente el conjunto de datos completo para producir resultados autorizados y correctos, como el recálculo nocturno de features. Es precisa, pero tiene una latencia alta, por lo que no puede reflejar los eventos de los últimos segundos.

La capa de velocidad procesa datos en streaming casi en tiempo real para cubrir el intervalo desde la última ejecución por lotes. Sacrifica algo de precisión a cambio de actualidad, y sus resultados quedan finalmente sustituidos por los de la siguiente ejecución por lotes.

Un feature store es un sistema central para gestionar features de ML. Resuelve un problema fundamental: el entrenamiento y el serving deben usar las mismas definiciones de features; de lo contrario, el modelo recibe entradas diferentes en producción de las que recibió durante el entrenamiento (training-serving skew).

El offline store almacena grandes volúmenes de valores históricos de features, normalmente en archivos parquet dentro de un data lake o almacén de datos. Se utiliza para el entrenamiento y el scoring por lotes, donde el rendimiento importa más que la latencia.

El online store almacena los valores más recientes de las features en una base de datos de baja latencia, como Redis. Durante el serving, el modelo obtiene las features desde aquí en milisegundos, utilizando las mismas definiciones que el offline store.

El feature store garantiza que una feature calculada para el entrenamiento (offline) coincida con lo que consulta el serving (online). Esta coherencia elimina una fuente importante de errores silenciosos en producción y constituye el valor central del feature store.

Antes de confiar en un modelo nuevo en producción, ejecútelo en modo shadow: recibe tráfico real y genera predicciones, pero esas predicciones se registran en lugar de mostrarse a los usuarios. Puede compararlas con las del modelo actual sin ningún riesgo para los usuarios.

Cuando el modo shadow demuestra que el modelo nuevo es preciso y estable con tráfico real, puede promocionarlo, a menudo mediante un despliegue canario. El modo shadow junto con el canary ofrece un camino seguro y gradual desde un modelo entrenado hasta todo el tráfico de producción.

Ponga a prueba sus conocimientos sobre arquitectura.

Ha aprendido patrones de arquitectura para sistemas de IA:

• Arquitectura Lambda: capa de procesamiento por lotes (precisa) más capa de velocidad (actualizada)
• Feature store: parquet offline para el entrenamiento, Redis online para el serving y definiciones coherentes
• El modo shadow valida un modelo nuevo con tráfico real antes de promocionarlo