Feature Store: cuando un cero es una decisión

Imagina que una tienda utiliza un modelo para decidir qué productos mostrar a cada visitante. Entre sus variables figura el número de compras anteriores. Para Marta, el almacén de variables devuelve cero. Para Luis, recién registrado, no encuentra ninguna fila. Para Elena, la consulta falla. El adaptador entrega cero en los tres casos y el modelo responde sin protestar.

Desde fuera parece una integración robusta: siempre hay un número, no se rompe el esquema y la recomendación llega a tiempo. Sin embargo, acabamos de afirmar tres veces algo que solo sabemos una: que esa persona no tiene compras registradas. La simplificación ha ocurrido antes de que el modelo pudiera equivocarse.

La disponibilidad general de Online Feature Store, anunciada por Snowflake el 20 de octubre de 2026, hace oportuna esta conversación. El servicio incorpora recuperación online de variables para aplicaciones de ML y está disponible en regiones comerciales de AWS y Azure, no en Google Cloud. La novedad facilita servir datos; la decisión sobre qué significa su ausencia sigue siendo nuestra.

Un valor por defecto también modifica el modelo

La imputación forma parte del comportamiento del sistema predictivo: debe evaluarse y versionarse junto con el modelo. Si una ausencia y un cero observado terminan representados igual, el modelo no podrá distinguirlos a partir de esa variable. Eso puede ser deliberado y útil. Lo que necesita justificación es que ocurra por comodidad del adaptador.

En nuestra tienda, un cliente conocido sin compras puede haber navegado durante meses. Un visitante nuevo todavía no ha tenido esa oportunidad. La ausencia por una interrupción técnica podría afectar precisamente a los clientes más activos si sus datos se sirven desde una partición concreta. Las tres poblaciones pueden tener comportamientos diferentes aunque el número final coincida.

Añadir un indicador de ausencia permite conservar información, pero tampoco resuelve todo automáticamente. El modelo debe haber aprendido con esa representación y con un proceso de generación de ausencias pertinente. Si se entrenó únicamente con clientes cuyos perfiles estaban completos, introducir un indicador nuevo en producción no le enseña cómo interpretar los casos que nunca vio.

La documentación de Snowflake sobre variables en tiempo real contempla transformar datos en el momento de la consulta, incluida la imputación de nulos. También advierte sobre entradas sin valor almacenado para una entidad. Son mecanismos que el desarrollador debe manejar; un ejemplo de relleno con cero no demuestra que cero sea una representación adecuada para nuestro problema.

El fallo difícil de ver aparece al seleccionar quién llega al entrenamiento

Supongamos que, al preparar el conjunto de entrenamiento, eliminamos los registros sin historial de compras porque dificultan las uniones. Después desplegamos el modelo para todos los visitantes. La evaluación puede ser excelente sobre la población que conservamos y poco informativa sobre quienes acabamos de excluir.

Ahora añadamos el cero del adaptador. Ya no solo hemos evaluado otra población: también hemos escondido esa diferencia dentro de un valor perfectamente válido. Buscar nulos en la salida no descubrirá el problema. Y un cuadro de mando agregado puede tardar en mostrarlo si los clientes conocidos concentran la mayoría de las compras.

Conviene observar por separado entidades conocidas, entidades nuevas y peticiones atendidas durante degradaciones. El objetivo no es multiplicar segmentos hasta encontrar alguno que falle, sino seguir las causas que podrían cambiar la distribución de entrada. Si la ausencia se concentra en un canal de adquisición, una región o una versión del cliente, tratarla como ruido uniforme borra información relevante para decidir.

Esta cuestión enlaza con el sesgo introducido al excluir usuarios de un experimento. Aquí la exclusión puede ocurrir mucho antes de medir el resultado: durante la construcción de las variables que hacen elegible un registro para entrenar.

Una matriz para decidir qué representa la ausencia

Propongo esta matriz de ausencia y representación como herramienta de revisión del diseño. No prescribe un tratamiento universal; obliga a que cada conversión conserve una explicación.

Cero observado.

La consulta encuentra la entidad y la variable mide cero bajo una definición conocida. Se conserva como observación. Conviene distinguirlo de un perfil incompleto que todavía no ha terminado de cargar.

Entidad sin historial.

La búsqueda termina correctamente y no existe la información solicitada. Se puede utilizar una representación entrenada para ese caso o un modelo de arranque sin historial. La elección depende de qué señales están realmente disponibles.

Variable ausente dentro de una entidad conocida.

El perfil existe, pero falta una de sus variables. Imputar exige conocer su semántica y comprobar el efecto de la ausencia conjunta de varias variables; ensayar cada una por separado puede ocultar una combinación problemática.

Lectura fallida.

No sabemos si el valor existe. Debe conservarse como fallo técnico aunque la aplicación ofrezca una alternativa. Convertirlo directamente en «sin historial» impediría distinguir nuevos clientes de un servicio averiado.

En cada caso dejaría asociados la representación, la versión del preprocesamiento y el comportamiento alternativo permitido. La aplicación puede decidir mostrar una selección general de productos durante una caída. Esa es una política de producto defendible; no necesita fingir que el modelo personalizado recibió un perfil válido.

Entrenar y servir con la misma transformación exige más que compartir columnas

Snowflake permite construir conjuntos de entrenamiento a partir de variables y marcas temporales, y utilizar grupos de variables para acercar la composición offline a la lectura online. Esto reduce trabajo duplicado, pero nuestra aceptación debe comprobar también los casos donde no llega una entrada.

Una prueba de diseño útil toma la misma entidad y compara cuatro situaciones: historial completo, historial inexistente, una variable ausente y lectura fallida. Interesa comprobar qué representación alcanza el modelo, qué política se ejecuta y qué rastro permite explicarlo después. No basta con verificar que todas las peticiones devuelven una respuesta.

La comparación debe incluir la transformación completa. Si entrenamiento normaliza después de imputar y producción lo hace antes, compartir nombres y tipos no garantiza equivalencia. Tampoco la garantiza mantener el mismo modelo mientras cambia silenciosamente el valor por defecto. La unidad que aprobamos incluye esas decisiones previas.

Hay situaciones donde un único valor por defecto funciona bien: la variable puede ser poco relevante, el entrenamiento puede incorporar ausencias representativas y la pérdida puede ser asumible. En ese caso conservaría la solución sencilla, acompañada de evidencia por las poblaciones afectadas. Complicar el tratamiento sin demostrar una mejora también tiene coste operativo.

Volvamos a Marta, Luis y Elena. No necesitamos obligatoriamente tres modelos. Necesitamos saber qué diferencia estamos descartando al darles el mismo cero. Cuando esa decisión es consciente, podemos medirla y cambiarla. Cuando queda escondida en una conversión de tipos, acabamos debatiendo la calidad de un modelo al que nunca dimos la oportunidad de conocer el problema.