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.
3Explique la finalidad de un almacén de características y distinga el suministro de características en línea de su generación fuera de línea.
Un almacén de características es una plataforma de datos centralizada diseñada para gestionar, almacenar, descubrir y suministrar características de aprendizaje automático en los flujos de entrenamiento e inferencia. Sus objetivos principales son favorecer la reutilización de características entre equipos, eliminar procesos de ingeniería duplicados y reducir las diferencias entre entrenamiento y servicio de predicciones mediante definiciones estandarizadas. Un concepto arquitectónico central es el patrón de almacenamiento dual: 1. Almacén fuera de línea (generación de características y entrenamiento): Se construye sobre motores analíticos y almacenamiento distribuido, por ejemplo, Snowflake, BigQuery, S3/Parquet o Delta Lake. Está optimizado para el procesamiento por lotes de gran capacidad, la conservación del historial y las uniones temporalmente correctas de tipo as-of. La recuperación histórica permite uniones que tienen en cuenta el tiempo, pero reconstruir los datos sin fugas de información también requiere claves de entidad correctas, historial de eventos y disponibilidad, versiones de las transformaciones y límites temporales de las etiquetas. Un almacén fuera de línea no genera características automáticamente; procesos externos pueden calcularlas y cargar sus valores. 2. Almacén en línea (suministro para inferencia en tiempo real): Se construye sobre bases de datos clave-valor de baja latencia y alta disponibilidad, como Redis, DynamoDB o Cassandra. Está optimizado para consultas puntuales de baja latencia de los valores más recientes de las características, indexados por identificadores de entidad, por ejemplo, user_id, para enriquecer solicitudes de predicción en tiempo real. La latencia real depende del despliegue y de la carga de trabajo. Un registro y definiciones compatibles pueden conectar ambos entornos, mientras que la plataforma de características o procesos externos pueden implementar la ingesta y la sincronización. Las capacidades varían según el producto.
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 procesos de generación de características por lotes y en flujo continuo para casos de uso de ML (aprendizaje automático) en producción con distintos requisitos de actualidad de los datos, coste y fiabilidad.
Los procesos por lotes trabajan con conjuntos de datos acotados según una programación o un desencadenante, mientras que los procesos en flujo continuo procesan de forma incremental los eventos que van llegando. Elija según la actualidad de los datos requerida de extremo a extremo, el volumen de datos, el tamaño del estado y el comportamiento de recuperación. Los trabajos por lotes pueden ejecutarse cada pocos minutos o bajo demanda; no implican necesariamente horas de retraso. El procesamiento en flujo continuo puede ofrecer baja latencia, pero la actualidad de los datos sigue dependiendo de los retrasos de ingesta, procesamiento y escritura en el destino. El procesamiento por lotes suele ser más sencillo de operar para grandes recálculos históricos, pero no es siempre más barato: el procesamiento incremental en flujo continuo puede evitar exploraciones completas repetidas, y los sistemas gestionados o sin servidor modifican los costes de capacidad. Compare el coste medido para la carga de trabajo real. Ambos necesitan validación de esquemas, gestión de duplicados y publicación fiable. En el procesamiento en flujo continuo, además, la gestión del tiempo del evento, los datos tardíos, la recuperación del estado y la contrapresión son aspectos centrales. Un diseño híbrido suele combinar el procesamiento en flujo continuo de la actividad reciente con agregados históricos por lotes, utilizando definiciones coherentes y una semántica explícita del momento de disponibilidad de los datos tanto en el entrenamiento como en el servicio de predicciones.
11Analice los eventos que llegan tarde o fuera de orden en los procesos de generación de características y cómo afectan a los datos de entrenamiento, las etiquetas y las características utilizadas en línea.
En el procesamiento distribuido de flujos y la ingeniería de características, los eventos suelen llegar fuera de secuencia debido a la latencia de red, interrupciones del sistema o reintentos del cliente. El tiempo del evento es la marca temporal real en la que ocurrió un evento en el cliente o dispositivo de origen, mientras que el tiempo de procesamiento es la marca temporal en la que el motor de ingesta o de procesamiento de flujos procesa ese evento. Las marcas de agua representan el progreso estimado del tiempo del evento; las políticas de ventanas y de retraso permitido determinan cómo se actualizan, redirigen o descartan los eventos tardíos. No garantizan que nunca vaya a llegar un evento anterior. Los eventos tardíos y fuera de orden tienen efectos operativos y estadísticos importantes en los sistemas de características: 1. Datos de entrenamiento y fuga temporal de información: Al generar conjuntos históricos de entrenamiento, la construcción de características debe respetar tanto los límites del tiempo del evento como lo que realmente estaba disponible para el servicio de predicciones en el momento histórico de la decisión. Un evento tardío puede tener una marca temporal antigua, pero haber llegado después de la predicción; por ello, una unión temporal de tipo as-of basada únicamente en el tiempo del evento puede introducir una fuga de información. Conserve el historial de disponibilidad u observación y las versiones de las transformaciones; las marcas temporales de procesamiento pueden ayudar a establecer la disponibilidad, pero no son intercambiables con el tiempo del evento. 2. Generación de etiquetas: Muchas etiquetas de aprendizaje automático llegan con retrasos variables, por ejemplo, la atribución de conversiones o las devoluciones de cargos por fraude publicitario. Si las uniones de etiquetas no tienen en cuenta las llegadas tardías mediante ventanas de observación o atribución adecuadas, las etiquetas negativas basadas en observaciones 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 del flujo fuera de orden pueden corromper o sobrescribir el estado si el sistema de almacenamiento lo reemplaza sin más por datos más antiguos. Los procesos en línea deben utilizar operaciones de inserción o actualización que tengan en cuenta el tiempo del evento, comprobaciones de versión o funciones de agregación conmutativas para impedir que datos obsoletos sobrescriban el estado.
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']])
12Explique la función de las colas de mensajes fallidos, la idempotencia y los puntos de control en los procesos de generación de características en tiempo real.
Los puntos de control guardan una posición de recuperación coherente y el estado de los operadores para que un trabajo de procesamiento de flujos pueda volver a procesar la entrada después de un fallo. La garantía real depende de que las fuentes permitan reproducir los datos, de la configuración de los puntos de control y de la coordinación con el destino: un estado interno coherente no hace automáticamente que los efectos externos ocurran exactamente una vez. Los destinos idempotentes hacen que aplicar repetidamente el mismo evento lógico conserve el resultado previsto. Un reemplazo determinista con una clave estable puede ser idempotente, pero una operación atómica de inserción o actualización que incremente un contador sigue contando dos veces los reintentos. Utilice identificadores de deduplicación y cambios de estado atómicos, o un destino transaccional compatible. Las comparaciones de marcas temporales necesitan un desempate determinista y no resuelven cualquier agregación con eventos fuera de orden. La gestión de mensajes fallidos aísla los registros no válidos junto con los identificadores de sus cargas útiles y las causas del fallo, para investigarlos y volver a procesarlos de forma controlada. Supervise su volumen y las entidades afectadas, coordine el enrutamiento con el avance de la fuente y restrinja o degrade el servicio de predicciones si las entradas descartadas hacen que las características estén incompletas en un grado inaceptable. Que el proceso principal siga funcionando no basta para demostrar que los datos de las características son correctos.
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ñe un sistema de recuperación de características en línea de baja latencia y explique las contrapartidas del almacenamiento, la caché, el particionamiento y las claves de acceso muy frecuente.
Un sistema de recuperación de características en línea suministra características precalculadas y en tiempo real a los modelos de inferencia con una elevada capacidad de procesamiento y bajo SLA (acuerdos de nivel de servicio) estrictos de baja latencia, normalmente p99 < 5–20 ms. Arquitectura y almacenamiento clave-valor: - Capa de almacenamiento: Lo habitual es utilizar almacenes distribuidos clave-valor de baja latencia, como Redis, DynamoDB, Cassandra o Aerospike. Mida la latencia p99 y el coste para la red, los tamaños de los elementos, el modo de consistencia, la carga y las condiciones de fallo reales; ninguno de los sistemas citados garantiza la misma latencia para todas las cargas de trabajo. - Desnormalización de datos: Las características de una entidad suelen almacenarse juntas y serializarse, por ejemplo, con Protocol Buffers, FlatBuffers o MessagePack, bajo una única clave (`entity_id:feature_view_name`), para minimizar los viajes de ida y vuelta por la red y las lecturas aleatorias de disco. Estrategias de caché y recuperación: - Caché de varios niveles: Caché local dentro del proceso, por ejemplo, Caffeine o una política LRU (menos recientemente utilizado) en el proxy del servicio de predicciones, para entidades consultadas con muchísima frecuencia, respaldada por el almacén KV (clave-valor) distribuido. - Recuperación múltiple paralela o por lotes: Las solicitudes de inferencia que involucran múltiples entidades, como la reordenación de 500 elementos candidatos, utilizan operaciones MGET por lotes o llamadas asíncronas de distribución y recopilación entre los fragmentos del almacenamiento. Particionamiento y mitigación de claves de acceso muy frecuente: - Hash consistente: Distribuye uniformemente las claves de entidad entre los nodos de almacenamiento. - Claves de acceso muy frecuente, como usuarios famosos, productos virales o entidades de respaldo globales o predeterminadas: 1. Réplicas de lectura y caché local: Atienda las lecturas de estas claves desde la memoria local de la aplicación o desde réplicas de solo lectura. 2. Adición de sufijos a las claves o fragmentación virtual: Para vectores completos de características con muchas lecturas, mantenga réplicas versionadas bajo varias claves y distribuya las lecturas entre ellas, teniendo en cuenta la propagación de actualizaciones a todas las réplicas y la posible desactualización. Si los valores se dividen, en cambio, en agregados parciales, las lecturas deben recuperar y combinar correctamente las partes pertinentes. Añadir sin más un sufijo aleatorio no conserva un valor completo ni resuelve de forma segura el problema de una clave de acceso muy frecuente. 3. Limitación de tasa y alternativas de respaldo en el cliente: Suministre valores predeterminados estáticos o representaciones vectoriales de respaldo almacenadas en caché cuando se produzca 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.