Aprendizaje Automático en Big Data

Diseñamos plataformas de ML en torno a un pequeño conjunto de principios: las características deben definirse una vez y reutilizarse; los experimentos deben ser reproducibles por defecto; los modelos deben ser versionados y registrados antes de llegar a producción; y las rutas de inferencia deben ser observables de la misma manera que los servicios subyacentes. Los principios no son nuevos; la disciplina de aplicarlos consistentemente es lo que distingue a las plataformas que se multiplican de las que se anquilosan.

Nuestra caja de herramientas preferida varía según el entorno. Hemos construido alrededor de ofertas gestionadas como Databricks, SageMaker, Vertex AI y Azure ML, alrededor de stacks de código abierto (MLflow, Feast, Ray, Kubeflow, Argo) en Kubernetes, y alrededor de híbridos de ambos. La elección está dictada por sus inversiones existentes, la comodidad operativa de su equipo y el perfil de latencia de las cargas de trabajo en cuestión.

En todos ellos insistimos en algunos elementos no negociables: cada artefacto (conjunto de datos, conjunto de características, modelo) se identifica mediante un hash direccionable por contenido; cada promoción entre entornos se registra con el linaje de entradas y los resultados de las pruebas que lo justificaron; y cada modelo en producción se empareja con un monitor que sabe lo que significa un buen rendimiento.

• Pipelines de entrenamiento reproducibles
• Almacenes de características con paridad en línea y fuera de línea
• Almacenes vectoriales para recuperación y similitud
• Registro, preparación y reversión de modelos
• Monitorización de deriva, rendimiento y coste
• Entrenamiento e inferencia conscientes del coste

El entrenamiento distribuido se justifica con menos frecuencia de la que se intenta. Muchos de nuestros clientes llegan convencidos de que necesitan un clúster multinodo, solo para descubrir que un modelo de gradiente-potenciado bien ajustado en una sola máquina grande lo supera por menos dinero y menos problemas operativos. Comenzamos estableciendo una sólida base de una sola máquina, y solo escalamos cuando los datos, la arquitectura del modelo o los objetivos de latencia lo requieren claramente.

Cuando la distribución es realmente necesaria — para el ajuste fino de modelos fundacionales, para recomendadores profundos distribuidos o para espacios de características muy grandes — utilizamos Ray, PyTorch DDP, DeepSpeed, Spark MLlib o Horovod según corresponda, y prestamos mucha atención a la ruta de datos. El entrenamiento distribuido que se atasca en el almacenamiento o la mezcla es un modo de fallo común y deprimente, y cuya cura rara vez implica más GPUs.

La reproducibilidad se trata como una propiedad del pipeline de entrenamiento, no como una aspiración esperanzadora. Semillas aleatorias, versiones de bibliotecas, definiciones de entorno, instantáneas de datos e hiperparámetros se capturan automáticamente y se vinculan al artefacto del modelo resultante. Tres meses después, cuando un regulador o un analista pregunta por qué el modelo se comporta de la manera en que lo hace, el rastro está intacto.

“Más GPUs rara vez son la respuesta; una mejor gestión de datos sí lo suele ser.”

La arquitectura de inferencia está dictada por el consumidor, no por el modelo. Una puntuación de riesgo que informa una decisión por lotes una vez al día requiere una plataforma diferente a una recomendación en tiempo real servida en el percentil noventa y nueve en decenas de milisegundos. Diseñamos rutas de servicio en función de los requisitos de latencia, rendimiento y frescura del consumidor, y no somos sentimentales al reutilizar la infraestructura entre casos de uso cuando tiene sentido.

Para la inferencia en tiempo real, normalmente utilizamos una combinación de un almacén de características con servicio en línea, un servidor de modelos (Triton, BentoML, KServe o un equivalente gestionado) y una caché del lado de la solicitud cuando sea apropiado. Para la inferencia por lotes, nos apoyamos en el mismo clúster de entrenamiento, con ventanas determinísticas y los mismos controles de linaje que los pipelines upstream. Para la inferencia de streaming, integramos el modelo directamente en la topología de procesamiento de streaming, puntuando eventos en tránsito.

Prestamos mucha atención al coste en esta capa porque es donde los proyectos de ML se vuelven más caros de forma fiable. La cuantificación, la destilación, el procesamiento por lotes, la agregación de solicitudes, el escalado automático basado en señales de demanda reales y la voluntad de utilizar modelos más pequeños cuando son suficientes, reducen rutinariamente el coste de inferencia en un orden de magnitud sin una pérdida medible de precisión.

Un modelo en producción es un artefacto vivo. Los datos cambian, los conceptos cambian, los servicios upstream se modifican y los consumidores downstream encuentran nuevas formas de utilizar los resultados. Diseñamos sistemas de ML con la expectativa de que serán reentrenados docenas de veces a lo largo de su vida útil, y cada reentrenamiento seguirá el mismo camino controlado y auditable que la primera implementación.

La detección de deriva se incorpora por defecto — tanto la deriva de características como la de etiquetas, cuando estas están disponibles — y se combina con umbrales explícitos para la acción. Algunos modelos se reentrenan según un cronograma; otros lo hacen según una señal; la elección depende de cómo llegan las etiquetas y de lo costoso que sea un modelo obsoleto. De cualquier manera, el reentrenamiento produce un nuevo candidato que compite con el modelo actual en el mismo sistema de evaluación, y el ganador es promocionado bajo los mismos controles de lanzamiento utilizados originalmente.

Cuando los modelos están expuestos a condiciones adversas — fraude, abuso, “gaming” — añadimos el “red-teaming” y la implementación en sombra como práctica estándar. El tráfico de producción fluye tanto al modelo en vivo como a un candidato, y el comportamiento del candidato se compara en detalle antes de la promoción. La disciplina es mundana y la seguridad que proporciona es sustancial.

En todos nuestros proyectos, el resultado más consistente no es un único modelo, sino una aceleración medible del ciclo de vida del ML. Los clientes que antes tardaban meses en llevar un modelo desde el cuaderno a producción lo hacen de forma fiable en semanas. Los modelos que antes requerían un equipo dedicado para su operación, ahora funcionan de forma autónoma entre revisiones rutinarias. La capacidad que antes se consumía manteniendo lo existente se libera para construir lo siguiente.

El segundo resultado consistente es una curva de costes defendible. Dado que el trabajo sobre características se reutiliza, la inferencia tiene el tamaño adecuado y la computación se monitoriza como una preocupación de primer orden, el coste marginal del siguiente caso de uso de ML disminuye. Esta es la propiedad que distingue una plataforma de un portfolio de proyectos piloto.