Preparación para entrevistas de Plataforma de ML / MLOps
Preguntas de Entrevista para Ingenieros de Plataforma de ML y MLOps
15 preguntas seleccionadas de entrevista de plataforma de ML y MLOps, agrupadas por nivel de experiencia. Úselas para repasar los fundamentos, las compensaciones prácticas y el razonamiento de producción a nivel senior.
1Explique qué es un contrato de datos en una plataforma de aprendizaje automático (ML) en producción y por qué es importante para la fiabilidad del modelo.
En una plataforma de aprendizaje automático (ML) en producción, un contrato de datos es un acuerdo formal y versionado entre productores de datos (como servicios de aplicación ascendentes, registradores de eventos o pipelines de ingeniería de datos) y consumidores de datos (como ingenieros de ML, pipelines de características y modelos). Más allá de los esquemas de bases de datos estándar (nombres de columnas y tipos primitivos), un contrato de datos especifica explícitamente expectativas semánticas, incluyendo rangos de valores permitidos, vocabularios categóricos, restricciones de nulabilidad, acuerdos de nivel de servicio (SLA) de frescura, líneas base de volumen y una clara responsabilidad del equipo. Los contratos de datos son críticos para la fiabilidad de ML porque los modelos de aprendizaje automático fallan silenciosamente. Mientras que los sistemas de software tradicionales a menudo lanzan excepciones explícitas cuando los esquemas se rompen o las cargas útiles cambian inesperadamente, los pipelines de ML y los modelos posteriores aceptarán con gusto entradas desplazadas o malformadas, produciendo predicciones degradadas, alucinaciones de puntuación o anomalías comerciales graves sin alertar a los monitores operativos estándar. Establecer contratos exigibles previene cambios inesperados que rompen la compatibilidad en el límite de ingesta, minimiza el sesgo entre entrenamiento y servicio y exige responsabilidad por parte del productor en cuanto a la calidad de los datos ascendentes.
2Explicar las comprobaciones de calidad de los datos que van más allá de la validación del esquema y cómo decidiría qué comprobaciones deberían bloquear un *pipeline* de entrenamiento o de servicio.
Las comprobaciones de calidad de los datos que van más allá de la validación del esquema verifican las distribuciones estadísticas, la semántica del negocio y la integridad del conjunto de datos. Las categorías clave incluyen:
1. **Tasas de Nulos y Valores Faltantes**: Monitoreo del porcentaje de valores faltantes en comparación con las líneas base históricas.
2. **Restricciones de Rango y Dominio**: Asegurar que las características numéricas se encuentren dentro de límites válidos (por ejemplo, edad entre 0 y 120, probabilidad en [0, 1]) y que los campos categóricos pertenezcan a vocabularios esperados.
3. **Comprobaciones de Volumen y Frescura**: Verificación del conteo de registros, las marcas de tiempo de llegada de las particiones y la completitud de las particiones.
4. **Integridad Referencial y Unicidad**: Comprobación de la unicidad de la clave primaria y las tasas de coincidencia de uniones de claves foráneas.
5. **Deriva Estadística y Distribucional**: Medición del índice de estabilidad de la población (PSI), la divergencia de Jensen-Shannon o los cambios de media/varianza entre particiones.
Decidir si una comprobación debe bloquear un *pipeline* depende de la criticidad del fallo, el radio de impacto y si el sistema puede degradarse de forma elegante:
- **Comprobaciones de Bloqueo (*Hard Gates*)**: Detienen el entrenamiento o la ingesta de características cuando los errores son irrecuperables o invalidan las matemáticas del modelo. Ejemplos: particiones con 0 registros, claves primarias de entidad faltantes, caídas severas de volumen (>30%) o etiquetas objetivo corruptas.
- **Comprobaciones No Bloqueantes (*Soft Warnings* / Alertas)**: Registran la telemetría y activan alertas para el personal de guardia sin interrumpir la ejecución del *pipeline* cuando los datos siguen siendo utilizables. Ejemplos: ligera deriva de características, caídas estacionales esperadas de volumen o aumentos no críticos en la tasa de nulos de características donde los valores predeterminados de reserva o la imputación preservan predicciones del modelo tolerables.
3Explica el propósito de un almacén de características y distingue el servicio de características en línea de la generación de características fuera de línea.
Un almacén de características es una plataforma de datos centralizada diseñada para gestionar, almacenar, descubrir y servir características de aprendizaje automático a lo largo de los flujos de trabajo de entrenamiento e inferencia. Sus objetivos principales son fomentar la reutilización de características entre equipos, eliminar pipelines de ingeniería duplicados y prevenir el sesgo entre entrenamiento y servicio estandarizando las definiciones de características.
Un concepto arquitectónico central de un almacén de características es el patrón de doble almacenamiento:
1. **Almacén fuera de línea (generación de características y entrenamiento)**: Construido sobre motores analíticos y almacenamiento distribuido (por ejemplo, Snowflake, BigQuery, S3/Parquet, Delta Lake). Está optimizado para el procesamiento por lotes de alto rendimiento, la retención histórica y las uniones correctas en el tiempo (as-of). Genera conjuntos de datos de entrenamiento sin fugas recreando el estado de las características exactamente como existía en las marcas de tiempo de predicción históricas.
2. **Almacén en línea (servicio de inferencia en tiempo real)**: Construido sobre bases de datos clave-valor de baja latencia y alta disponibilidad (por ejemplo, Redis, DynamoDB, Cassandra). Está optimizado para búsquedas puntuales de menos de 10 ms de los últimos valores de características indexados por IDs de entidad (por ejemplo, `user_id`) para enriquecer las solicitudes de puntuación de modelos en tiempo real.
El almacén de características unifica estos entornos manteniendo una única definición y registro de características, orquestando la sincronización de datos desde los pipelines de ingesta por lotes/streaming a los almacenes tanto fuera de línea como en línea.
Feature Definition: `user_30d_transaction_count`
|
+---------------+---------------+
| |
v v
[Offline Store] [Online Store]
- Tech: BigQuery, Iceberg, S3 - Tech: Redis, DynamoDB
- Workload: High-throughput batch - Workload: Low-latency point lookups
- Retention: Multi-year history - Retention: Latest entity state
- Usage: Point-in-time training - Usage: Real-time inference scoring
4Explica la diferencia entre una definición de característica, un valor de característica, una vista de característica y una clave de entidad en una plataforma de características de producción.
En un almacén de características o plataforma de características moderno, estos cuatro conceptos representan capas distintas de modelado de datos y diseño de sistemas: 1. Clave de entidad (`Entity Key`): El identificador principal (o conjunto de claves compuestas) que representa un concepto de dominio u objeto de negocio (por ejemplo, `user_id`, `merchant_id`). Sirve como clave de unión (`join key`) en todas las fuentes de datos y como clave de búsqueda principal durante la inferencia. 2. Definición de característica (`Feature Definition`): Los metadatos lógicos, la especificación del esquema y la lógica de cómputo que declaran qué es una característica, incluyendo su nombre, tipo de dato y lógica de transformación (por ejemplo, `user_30d_txn_sum` declarada como `FLOAT32`). 3. Vista de característica (`Feature View`): Una abstracción lógica que agrupa definiciones de características relacionadas asociadas con claves de entidad específicas y respaldadas por fuentes de datos (por lotes, en streaming o bajo demanda). Define la configuración de ingesta, la semántica temporal (marca de tiempo del evento) y el comportamiento de materialización tanto para almacenes offline como online. 4. Valor de característica (`Feature Value`): La instancia de datos concreta y materializada para una clave de entidad específica evaluada en un punto específico en el tiempo (por ejemplo, para `user_id = 1042` en `2023-10-01 12:00:00 UTC`, el valor de la característica es `452.10`).
5¿Qué es el linaje de datos en una plataforma de ML y por qué es importante para depurar regresiones en la calidad del modelo?
El linaje de datos en una plataforma de ML (Machine Learning) es el registro estructurado del ciclo de vida y la procedencia de los datos, documentando cómo los conjuntos de datos en bruto se transforman, filtran, procesan en características, compilan en conjuntos de entrenamiento y son consumidos por versiones específicas del modelo. El linaje es esencial para depurar regresiones en la calidad del modelo porque la degradación del ML frecuentemente es causada por defectos en los datos de origen en lugar de errores de código. Cuando el rendimiento de un modelo disminuye, el linaje permite un análisis retrospectivo de la causa raíz: los ingenieros pueden rastrear hacia atrás desde el modelo degradado para inspeccionar la versión exacta del conjunto de datos, la lógica de transformación de características, el lote de ingesta de origen o el cambio de esquema que introdujo el problema. Por el contrario, el linaje permite un análisis prospectivo del impacto: cuando se descubre una partición de datos en bruto corrupta o un error lógico de origen, los ingenieros pueden rastrear hacia adelante para identificar todos los conjuntos de entrenamiento posteriores, las tablas de características intermedias y los modelos desplegados que fueron corrompidos y que requieren reentrenamiento o reversión.
[Degraded Model v3.1]
└── Trained on: [Dataset: training_set_2025_04_01]
└── Built from: [Feature View: user_features_v2 @ git_sha: abc1234]
└── Source Table: [raw_user_events @ batch_2025_03_31]
└── Issue Found: Logging bug produced 40% zero-filled values
6¿Qué proporciona un registro de modelos más allá de almacenar artefactos de modelos serializados?
Un registro de modelos es un sistema centralizado de gobernanza, versionado y gestión del ciclo de vida para modelos de aprendizaje automático. A diferencia de un almacén de artefactos estándar (como un bucket de S3, un bucket de GCS o un almacén de blobs genérico) que simplemente contiene archivos binarios serializados (por ejemplo, `.onnx`, `.pt` o `.pkl`), un registro de modelos actúa como el plano de control operativo para los modelos en toda la organización. Un registro de modelos proporciona varias capacidades clave más allá del almacenamiento de archivos brutos:
1. **Versionado de Modelos y Agrupación Lógica:** Organiza las iteraciones bajo entidades de modelo con nombre y versionado semántico, desacoplando la definición lógica del modelo de los archivos de ejecución individuales.
2. **Metadatos de Procedencia y Linaje:** Vincula automáticamente el artefacto del modelo con su ejecución de entrenamiento, confirmación de código (Git SHA), instantánea del conjunto de datos de entrenamiento/versión de datos, hiperparámetros, entorno de entrenamiento (imagen de contenedor, versiones de librerías) y autor.
3. **Métricas de Evaluación y Registros de Gobernanza:** Almacena métricas de validación, auditorías de equidad/sesgo, contratos de esquema (firmas de entrada/salida) y tarjetas de modelo junto con el artefacto para verificar la preparación para el lanzamiento.
4. **Transiciones de Etapa del Ciclo de Vida:** Gestiona las etapas de promoción (por ejemplo, Experimental -> Staging -> Producción -> Archivado) con control de acceso, compuertas de validación y aprobaciones obligatorias humanas o automatizadas.
5. **Trazabilidad de Despliegue y Reversión (Rollback):** Sirve como la fuente única de verdad para la CI/CD (Integración Continua/Despliegue Continuo) y la infraestructura de servicio, permitiendo despliegues automatizados y una reversión rápida a la versión de modelo estable anterior durante incidentes en producción.
7¿Cuál es el propósito de un plan de reversión para los despliegues de modelos y qué estado se necesita para revertir de forma segura?
El propósito de un plan de reversión para los despliegues de modelos es asegurar la fiabilidad del servicio, la disponibilidad del sistema y la continuidad del negocio. Cuando un modelo recién desplegado exhibe una calidad predictiva degradada, regresiones de latencia, errores en tiempo de ejecución o cambios inesperados en las predicciones, un plan de reversión proporciona un procedimiento rápido y determinístico para revertir el tráfico a un estado conocido y funcional con una interrupción mínima. Para ejecutar una reversión segura, la plataforma debe preservar y coordinar varios estados clave: 1. Estado de los Artefactos del Modelo: Los pesos del modelo anteriores, archivos binarios y objetos de pipeline serializados almacenados inmutablemente en un registro de modelos o almacén de objetos. 2. Entorno de Ejecución y Código: La imagen del contenedor, el código de servicio de inferencia y las dependencias de tiempo de ejecución de terceros fijadas a la versión anterior. 3. Estado de las Características y Preprocesamiento: Las definiciones exactas de las características, los esquemas de transformación y las versiones del almacén de características compatibles con la versión anterior del modelo. 4. Estado de Enrutamiento de Tráfico y Configuración: Reglas de enrutamiento dinámico (por ejemplo, configuraciones de pasarela API (Application Programming Interface), equilibrador de carga o malla de servicios) que permiten la redirección instantánea del tráfico sin reconstruir la infraestructura. 5. Mecanismo de Respaldo (Fallback): Un respaldo predeterminado determinístico (por ejemplo, heurística basada en reglas o predicciones estáticas en caché) si tanto las instancias del modelo nuevo como las anteriores experimentan fallos.
8Comparar la validación de esquemas en tiempo de escritura versus en tiempo de lectura para pipelines de características de ML (Machine Learning), y argumentar cuándo es preferible cada una.
La validación de esquemas en tiempo de escritura y en tiempo de lectura representa dos límites de validación complementarios con distintas compensaciones operativas: 1. Validación en Tiempo de Escritura: Valida los registros entrantes a medida que se generan o se ingieren en el almacenamiento central (por ejemplo, ingreso de API, temas de transmisión de eventos o zonas de aterrizaje de lakehouse). Impone garantías de fallar rápidamente (fail-fast), bloquea los registros malformados antes de que contaminen las tablas compartidas y asigna responsabilidad directa a los servicios productores ascendentes. Es preferible para plataformas de producción de misión crítica, almacenes de características compartidos con múltiples consumidores descendentes y rutas de inferencia en línea de baja latencia donde los datos corruptos causarían fallos sistémicos amplios. 2. Validación en Tiempo de Lectura: Valida los datos cuando los pipelines de consumo extraen o cargan lotes (por ejemplo, durante la generación de características o la preparación del conjunto de entrenamiento). Otorga a los consumidores descendentes un control granular para aplicar reglas de filtrado específicas del modelo sin bloquear los pipelines de ingesta ascendentes ni requerir cambios de los equipos productores. Es preferible durante el análisis exploratorio, la investigación fuera de línea, la ingesta de datos heterogéneos de terceros incontrolables o al consumir conjuntos de datos heredados donde la validación en tiempo de escritura no se aplicó.
# 1. Write-Time Validation: Reject or quarantine bad records before landing in Feature Store
def write_to_feature_store(raw_records, schema_validator, feature_table, dlq_publisher):
valid_records = []
for record in raw_records:
if schema_validator.is_valid(record):
valid_records.append(record)
else:
dlq_publisher.publish(record, reason="write_time_validation_failed")
feature_table.append_batch(valid_records)
# 2. Read-Time Validation: Consumer pipeline applies defensive model-specific checks
def load_training_features(feature_table, model_schema):
df = feature_table.read_partition("2023-10-01")
# Model-specific consumer gate: drops non-conforming rows without halting upstream ingestion
clean_df = df[model_schema.validate_row_mask(df)]
return clean_df
9Diagnostica un pipeline de datos que se ejecuta correctamente pero elimina registros silenciosamente o convierte valores faltantes en valores predeterminados que corrompen las predicciones del modelo.
Para diagnosticar y solucionar un pipeline que se ejecuta correctamente pero elimina registros silenciosamente o sustituye valores predeterminados corruptos, siga un flujo de trabajo estructurado de triaje de incidentes: 1. Auditoría de volumen entre etapas del pipeline: Mida los recuentos de filas y la cobertura de entidades antes y después de cada paso de transformación (ingreso de datos en bruto -> uniones -> agregaciones -> tabla de características). Un `INNER JOIN` involuntario contra una tabla con claves faltantes o eliminadas es la causa principal de la eliminación silenciosa de registros. 2. Inspección de manejo de nulos e imputación predeterminada: Inspeccione el código de transformación en busca de lógica de reserva agresiva (por ejemplo, `.fillna(0)`, `COALESCE(val, -1)` o cadenas vacías no manejadas). Si los cambios en el esquema de datos aguas arriba convierten una columna a nulos, los reemplazos predeterminados generales desplazarán silenciosamente toda la distribución de características. 3. Coerción de tipos silenciosa y supresión de errores: Busque mecanismos de conversión de tipos que no fallan (por ejemplo, `pd.to_numeric(..., errors='coerce')` o SQL `SAFE_CAST`), que convierten valores no parseables directamente a `NULL` sin lanzar errores, alimentando posteriormente la imputación predeterminada. 4. Evaluación del impacto del modelo y solución: Compare las distribuciones de características actuales con las líneas base históricas utilizando métricas de PSI, media y tasa de nulos. Audite los registros de distribución de predicciones del modelo para cuantificar la deriva de la predicción y evaluar el impacto en el negocio. Despliegue correcciones de código con aserciones explícitas y ejecute un retroceso (backfill) idempotente de las particiones históricas afectadas.
# Anti-Pattern: Succeeds green but corrupts feature data
# 1. Inner join silently drops users with missing profiles
# 2. errors='coerce' turns string typos into NaNs
# 3. fillna(0) injects artificial 0-values into feature distribution
df_corrupt = df_events.merge(df_profiles, on="user_id", how="inner")
df_corrupt["credit_score"] = pd.to_numeric(df_corrupt["raw_score"], errors="coerce").fillna(0)
# Robust Implementation: Explicit checks and observable failure
df_clean = df_events.merge(df_profiles, on="user_id", how="left")
join_match_rate = df_clean["user_id"].notna().mean()
if join_match_rate < 0.98:
raise RuntimeError(f"Severe join drop detected! Match rate: {join_match_rate:.2%}")
raw_nulls = df_clean["raw_score"].isna().mean()
if raw_nulls > 0.05:
raise ValueError(f"Anomalous raw_score missingness: {raw_nulls:.2%}")
10Compare los pipelines de características por lotes y los pipelines de características por streaming para casos de uso de aprendizaje automático (ML) en producción con diferentes requisitos de frescura, costo y fiabilidad.
Los pipelines de características por lotes y por streaming ofrecen distintas compensaciones en cuanto a la frescura de los datos, el costo computacional y la complejidad operativa: 1. **Frescura y Latencia:** Los pipelines por streaming (por ejemplo, Apache Flink, Spark Structured Streaming) procesan eventos casi en tiempo real, logrando una frescura de características de subsegundos a minutos. Esto es esencial para casos de uso de ML sensibles al tiempo, como la detección de fraude en tiempo real, precios dinámicos y recomendaciones inmediatas basadas en sesiones. Los pipelines por lotes (por ejemplo, DAGs de Airflow programados, dbt, Spark Batch) se ejecutan en programaciones periódicas (horarias, diarias), produciendo características con un retraso de horas a días, lo cual es suficiente para señales de evolución lenta como agregados de usuario de 30 días, puntuación de riesgo crediticio o predicción del valor de vida del cliente. 2. **Costo y Eficiencia de Recursos:** Los pipelines por lotes son significativamente más rentables porque procesan grandes volúmenes de datos en masa utilizando computación vectorizada, E/S columnar optimizada e instancias spot/preemptibles. Los pipelines por streaming requieren una infraestructura provisionada 24/7, almacenamiento de estado dedicado (por ejemplo, RocksDB) y dimensionamiento de capacidad para picos de tráfico, lo que resulta en mayores costos operativos y de infraestructura. 3. **Complejidad Operativa y Fiabilidad:** Los pipelines por lotes son más sencillos de monitorear, depurar y rellenar de forma idempotente en caso de fallo. Los pipelines por streaming introducen modos de fallo complejos, incluida la gestión de estados, la marca de agua de tiempo de evento (event-time watermarking), el manejo de eventos fuera de orden, el checkpointing y las garantías de procesamiento exactamente una vez. En plataformas de ML maduras, una arquitectura híbrida es común: los pipelines de streaming en tiempo real calculan señales de comportamiento de baja latencia, mientras que los pipelines por lotes calculan agregados históricos pesados, unificados a través de una tienda de características centralizada.
11Razone sobre los eventos que llegan tarde y desordenados en los *pipelines* de características y cómo afectan a los datos de entrenamiento, las etiquetas y las características en línea.
En el procesamiento de flujos distribuido y la ingeniería de características, los eventos a menudo llegan fuera de secuencia debido a la latencia de red, interrupciones del sistema o reintentos del cliente. El tiempo del evento se refiere a la marca de tiempo real cuando un evento ocurrió en el cliente o dispositivo de origen, mientras que el tiempo de procesamiento es la marca de tiempo cuando el motor de ingesta o *streaming* procesa ese evento. Los *frameworks* de procesamiento de flujos utilizan *watermarks* (marcas de agua) como marcadores de progreso temporal para rastrear la progresión del tiempo del evento y definir una ventana acotada después de la cual los datos que llegan tarde se consideran retrasados. Los eventos que llegan tarde y desordenados tienen impactos operativos y estadísticos significativos en los sistemas de características:
1. **Datos de entrenamiento y fuga temporal**: Al generar conjuntos de datos de entrenamiento históricos, las características deben unirse con los eventos de predicción estrictamente a partir de la marca de tiempo del evento de predicción (utilizando uniones *point-in-time* o *as-of*). Si el tiempo de procesamiento se usa erróneamente o si las características incorporan datos futuros que llegan desordenados, la información futura se filtra en los conjuntos de entrenamiento, inflando artificialmente las métricas *offline* y causando una degradación del rendimiento en producción.
2. **Generación de etiquetas**: Muchas etiquetas de aprendizaje automático llegan con retrasos variables (por ejemplo, atribución de conversiones, contracargos por fraude publicitario). Si las uniones de etiquetas no tienen en cuenta las llegadas tardías utilizando ventanas de observación/atribución apropiadas, las etiquetas negativas incompletas introducirán un sesgo de falsos negativos.
3. **Características en línea**: En los almacenes de características en línea, las escrituras de flujo desordenadas pueden causar corrupción del estado o sobrescrituras si el *backend* de almacenamiento sobrescribe ingenuamente el estado con datos más antiguos. Los *pipelines* en línea deben utilizar actualizaciones (upserts) conscientes del tiempo del evento, verificaciones de versión o funciones de agregación conmutativas para evitar sobrescrituras de estado obsoleto.
import pandas as pd
# Prediction events (e.g., ad impressions at inference time)
observations = pd.DataFrame({
'user_id': [101, 102],
'pred_time': pd.to_datetime(['2023-10-01 10:00:00', '2023-10-01 10:30:00'])
})
# Feature updates with event-time timestamps
user_features = pd.DataFrame({
'user_id': [101, 101, 102],
'feature_time': pd.to_datetime([
'2023-10-01 09:30:00',
'2023-10-01 10:15:00', # Occurs after observation 1 pred_time
'2023-10-01 10:00:00'
]),
'click_count_1h': [3, 5, 1]
})
# Backward as-of join guarantees only feature state known at pred_time is joined
training_set = pd.merge_asof(
observations.sort_values('pred_time'),
user_features.sort_values('feature_time'),
left_on='pred_time',
right_on='feature_time',
by='user_id',
direction='backward'
)
print(training_set[['user_id', 'pred_time', 'feature_time', 'click_count_1h']])
12Explica el papel de las colas de mensajes fallidos, la idempotencia y los puntos de control en los pipelines de procesamiento de características en tiempo real.
Los pipelines de procesamiento de características en tiempo real se basan en las colas de mensajes fallidos (DLQ), la idempotencia y los puntos de control para mantener la integridad de los datos y la tolerancia a fallos bajo condiciones de streaming de alto rendimiento: 1. Puntos de control: Los motores de streaming (como Apache Flink o Spark Structured Streaming) persisten periódicamente el estado del pipeline (incluyendo agregaciones de ventana y offsets del consumidor de origen) en almacenamiento duradero. Cuando un worker falla o se reinicia, el pipeline restaura el estado desde el punto de control válido más reciente y reanuda el consumo desde el offset registrado, garantizando un procesamiento al menos una vez a través de los fallos. 2. Idempotencia: Debido a que la recuperación de puntos de control reproduce mensajes desde offsets anteriores, los almacenes posteriores pueden recibir escrituras duplicadas. Los sumideros idempotentes aseguran que aplicar la misma carga útil del evento múltiples veces resulte en exactamente el mismo estado que aplicarlo una vez. En los almacenes de características, esto se logra mediante IDs únicos de transacción/evento, actualizaciones condicionales que comparan marcas de tiempo ($t_{incoming} > t_{stored}$), o actualizaciones/inserciones (upserts) atómicas. 3. Colas de mensajes fallidos (DLQ): Los flujos de ingesta frecuentemente encuentran mensajes defectuosos —registros mal formados, violaciones de esquema o cargas útiles que activan excepciones en tiempo de ejecución no controladas. En lugar de colapsar al consumidor y detener el procesamiento de la partición en un bucle de reintentos infinito, el pipeline dirige los registros erróneos a una DLQ. Esto mantiene el pipeline principal saludable mientras aísla los registros erróneos para inspección, alerta y reproducción manual o automatizada.
def update_user_feature(redis_client, user_id: str, new_feature_val: float, event_timestamp: int):
lua_script = """
local current_ts = redis.call('HGET', KEYS[1], 'last_updated')
if not current_ts or tonumber(ARGV[1]) > tonumber(current_ts) then
redis.call('HSET', KEYS[1], 'feature_val', ARGV[2], 'last_updated', ARGV[1])
return 1
end
return 0
"""
# Atomic check-and-set: older replayed events are ignored
return bool(redis_client.eval(lua_script, 1, f"user:{user_id}", event_timestamp, new_feature_val))
13Razone sobre la estrategia de rellenado de datos históricos cuando los datos de origen corregidos invalidan las características derivadas utilizadas por los modelos en producción.
Cuando los datos de origen se corrigen o invalidan retroactivamente, las características derivadas en los conjuntos de entrenamiento offline y los almacenes de características online se vuelven inconsistentes. Una estrategia de rellenado de datos históricos de nivel senior requiere un proceso estructurado de múltiples etapas: 1. **Análisis de Linaje y Alcance del Impacto**: Utilizar metadatos del catálogo de datos y grafos de linaje automatizados para identificar todas las vistas de características derivadas, conjuntos de datos de entrenamiento offline (fuera de línea) posteriores, tablas de características online (en línea) y modelos de producción activos afectados por los datos de origen corruptos. 2. **Reprocesamiento Histórico Aislado**: Reejecutar los pipelines de transformación de características sobre el rango de tiempo afectado utilizando computación aislada y dedicada (p. ej., Spark/Ray). Los datos reprocesados deben escribirse en particiones históricas inmutables y versionadas o en tablas de preparación (staging) en sombra, en lugar de modificar las tablas de producción in situ. 3. **Validación y Compuertas de Calidad**: Ejecutar verificaciones estadísticas y de calidad de datos automatizadas antes de promover los datos rellenados. Esto incluye verificación de esquema, límites de tasa de nulos y comparaciones de distribución de características (p. ej., PSI (Population Stability Index) o distancia de Wasserstein) entre los datos rellenados y las líneas base históricas. 4. **Activadores de Reentrenamiento Gobernados**: Determinar si los modelos entrenados con características históricas inválidas requieren reentrenamiento. Si la deriva de características o el impacto posterior exceden los umbrales predefinidos, activar los DAGs (Grafos Dirigidos Acíclicos) de entrenamiento automatizados en el conjunto de datos corregido, validar las métricas del modelo contra los candidatos de línea base y gobernar el despliegue en producción mediante etapas en sombra o canary. 5. **Corte sin Tiempo de Inactividad y Sincronización Online**: Para los almacenes de características online, sincronizar los valores rellenados utilizando escrituras limitadas o intercambios de punteros de alias (p. ej., actualizando los punteros del registro de características a la nueva versión de la característica) para evitar la saturación de la base de datos, seguido de la deprecación y recolección de basura de las particiones obsoletas.
[Upstream Data Correction Event]
|
v
[1. Lineage Traversal] --------> Identifies: FeatureView_A, TrainingDataset_B, Model_C
|
v
[2. Isolated Reprocessing] ----> Writes to isolated staging: `features_v2_backfill`
|
v
[3. Validation Gate] ----------> Validates: Schema match, Null checks, PSI < 0.05
|
v
[4. Cutover & Retrain Trigger]-> Online: Atomic alias swap (`feature_v1` -> `feature_v2`)
Offline: Retrain Model_C on corrected historical split
14Diseña un sistema de recuperación de características en línea de baja latencia y explica las compensaciones de almacenamiento, caché, particionamiento y claves calientes (hot keys).
Un sistema de recuperación de características en línea sirve características precalculadas y en tiempo real a modelos de inferencia bajo estrictos acuerdos de nivel de servicio (SLAs (Service Level Agreements)) de baja latencia (típicamente p99 < 5–20 ms) con alto rendimiento.
**Arquitectura y Almacenamiento Clave-Valor:**
* **Capa de Almacenamiento**: Los almacenes clave-valor distribuidos de baja latencia (por ejemplo, Redis, DynamoDB, Cassandra, Aerospike) son estándar. Redis proporciona búsquedas en memoria de submilisegundos; DynamoDB/Aerospike ofrecen almacenamiento rentable respaldado por SSD con latencia predecible de un solo dígito de milisegundo.
* **Desnormalización de Datos**: Las características para una entidad a menudo se co-localizan y serializan (por ejemplo, en Protocol Buffers, FlatBuffers o MessagePack) bajo una única clave (`entity_id:feature_view_name`), minimizando los viajes de ida y vuelta de red y las lecturas de disco aleatorias.
**Estrategias de Caché y Recuperación:**
* **Caché Multinivel**: Caché local en proceso (por ejemplo, Caffeine/LRU en el proxy de servicio) para entidades solicitadas con ultra-frecuencia, respaldada por el almacén clave-valor distribuido.
* **Recuperación Paralelizada Multi-Get / por Lotes**: Las solicitudes de inferencia que involucran múltiples entidades (por ejemplo, reordenación de candidatos de 500 ítems) utilizan operaciones MGET por lotes o llamadas asíncronas 'scatter-gather' a través de los fragmentos de almacenamiento.
**Particionamiento y Mitigación de Claves Calientes:**
* **Hashing Consistente**: Distribuye las claves de entidad uniformemente entre los nodos de almacenamiento.
* **Claves Calientes (por ejemplo, usuarios famosos, productos virales, entidades de respaldo predeterminadas/globales)**:
1. **Réplicas de Lectura y Caché Local**: Sirven claves calientes de lectura intensiva desde la memoria de la aplicación local o réplicas de solo lectura.
2. **Salado de Claves / Fragmentación Virtual**: Añadir sufijos aleatorios (`hot_item_123#1..N`) a través de múltiples particiones, distribuyendo el tráfico de lectura entre los fragmentos.
3. **Limitación de Velocidad en el Lado del Cliente y Respaldo**: Servir valores predeterminados estáticos o embeddings de respaldo en caché cuando ocurre una degradación.
# Conceptual Online Feature Client with Local LRU + Batched KV Fetch
import functools
from typing import List, Dict, Any
class OnlineFeatureClient:
def __init__(self, remote_kv_store, local_cache):
self.remote_kv = remote_kv_store
self.local_cache = local_cache
def get_online_features(self, entity_keys: List[str], feature_names: List[str]) -> Dict[str, Dict[str, Any]]:
results = {}
missing_keys = []
# 1. Check local in-memory L1 cache (mitigates hot-keys)
for key in entity_keys:
cached = self.local_cache.get(key)
if cached:
results[key] = cached
else:
missing_keys.append(key)
# 2. Batched async retrieval for missing keys from distributed store (e.g., Redis/DynamoDB)
if missing_keys:
fetched_records = self.remote_kv.mget(missing_keys)
for key, serialized_val in zip(missing_keys, fetched_records):
parsed_val = self._deserialize(serialized_val) # Proto/Msgpack
results[key] = parsed_val
self.local_cache.set(key, parsed_val, ttl=30) # Short TTL L1 cache
return results
def _deserialize(self, data): ...
15Compare la propiedad centralizada de características con la propiedad de características por equipos de dominio en una plataforma de ML multi-equipo.
En las organizaciones de ML multi-equipo, la elección entre la propiedad centralizada y la propiedad por equipo de dominio (descentralizada/federada) de las características implica compromisos entre la reutilización de características, la velocidad de desarrollo, la responsabilidad operativa y la gobernanza:
1. **Propiedad Centralizada de Características (Equipo de Datos/Características Dedicado):**
* **Cómo funciona:** Un equipo central construye, posee y mantiene todos los *pipelines* de características, catálogos de *feature store* y controles de calidad de datos para los equipos de ML consumidores.
* **Ventajas:** Alta estandarización, modelos de datos unificados, características duplicadas mínimas en los equipos, estándares de calidad globales claros y optimización de costos consistente.
* **Desventajas:** Se convierte en un cuello de botella organizacional; los ingenieros centrales carecen de un contexto de dominio profundo para la lógica específica del negocio; tiempo de respuesta lento para nuevas solicitudes de características.
2. **Propiedad de Características por Equipo de Dominio (Federada / Característica como Código / Data Mesh):**
* **Cómo funciona:** Los equipos de ML de producto/dominio (por ejemplo, Búsqueda, Fraude, Recomendaciones) definen y poseen su lógica de características, *pipelines* y definiciones de esquemas. El equipo central de la plataforma proporciona la infraestructura de características subyacente, CI/CD (Integración Continua/Entrega Continua), registros y herramientas de monitoreo.
* **Ventajas:** Alta velocidad y autonomía de dominio; los equipos se mueven rápidamente sin dependencias entre equipos; profunda experiencia en el dominio integrada en la ingeniería de características.
* **Desventajas:** Riesgo de duplicación de características (por ejemplo, tres equipos construyendo recuentos de clics de usuario ligeramente diferentes), convenciones de nomenclatura fragmentadas, estándares de calidad/SLA (Acuerdo de Nivel de Servicio) inconsistentes y desafíos de gobernanza.
**Arquitectura Moderna Recomendada (Propiedad Federada con Gobernanza de Plataforma):**
La mayoría de las organizaciones maduras adoptan un modelo de propiedad federada donde el equipo de la plataforma proporciona un Catálogo de Características unificado, *linting* de CI/CD, validación de esquemas automatizada y herramientas de descubrimiento. Los equipos de dominio poseen los *pipelines* y los SLA operativos, mientras que la plataforma impone la gobernanza, el control de acceso y el descubrimiento de duplicación.