Entrevista de backend: ¿Cómo diseñarías una búsqueda por similitud híbrida y controlable con Redis Vector Sets?

Pregunta

Necesitas Redis vector sets para una búsqueda semántica de productos con filtros de tenant, año e inventario. ¿Cómo diseñarías las escrituras, las consultas VSIM, la capacidad y la validación de calidad?

Contexto y límites

Cada elemento tiene un ID de tipo cadena (string), un vector de dimensión fija y atributos JSON opcionales. Los Redis vector sets utilizan HNSW para la búsqueda por similitud y admiten filtros matemáticos simples a través de FILTER. Cubre actualizaciones, eliminaciones, arranque en frío (cold start), límites de memoria, codificación FP32 multiplataforma y fallback de búsqueda; no describas la funcionalidad como una caja negra que garantiza un recall exacto a nivel de negocio.

Qué está evaluando el entrevistador

El entrevistador busca un contrato de servicio único para la recuperación de vectores, restricciones estructuradas, ciclo de vida de los datos y capacidad. Redis documenta VADD para agregar o actualizar elementos, VSIM para consultas de similitud de vectores y filtros de atributos que deciden qué candidatos permanecen; los blobs FP32 requieren un orden de bytes little-endian, mientras que VALUES evita la codificación de blobs específica de la plataforma.

Aclara estos puntos primero:

• ¿Cuáles son la dimensión del vector, la métrica de distancia, el volumen por tenant y la frecuencia de actualización?
• ¿Son los filtros restricciones estrictas (hard constraints), o la aplicación puede refiltrar un conjunto ampliado de candidatos?
• ¿Los resultados necesitan top-k, puntuaciones de similitud, atributos o una razón de filtrado explicable?
• ¿Cuáles son los requisitos de memoria, persistencia, recuperación y replicación entre zonas?

Respuesta de 30 segundos

Define la clave (key), el ID del elemento, la dimensión del vector y el esquema de atributos. Explica escrituras idempotentes con VADD/VSETATTR, el top-k y filtrado con VSIM. Concluye con estimaciones de capacidad, una línea base de calidad y fallback a palabras clave o al índice anterior cuando Redis no esté disponible.

Análisis detallado paso a paso

1. Contrato de datos: fija la dimensión y la versión del modelo; haz que los IDs sean globales o asígnales claves por tenant; almacena solo los campos de filtrado como atributos.
2. Ruta de escritura: valida la dimensión y la versión del modelo, actualiza el vector de forma idempotente con VADD, actualiza los atributos con VSETATTR y elimina con VREM.
3. Ruta de consulta: valida los límites de tenant y las expresiones de filtrado en el servicio, solicita un poco más que el k final desde VSIM y devuelve puntuaciones y atributos para auditoría.
4. Capacidad: estima la memoria para vectores, enlaces HNSW y atributos; establece límites por tenant, política de desalojo (eviction policy) y particionamiento (sharding); evita atributos JSON arbitrariamente grandes.
5. Consistencia y recuperación: registra la versión del modelo y los eventos de escritura; tras restaurar una instantánea (snapshot), verifica las dimensiones, el recuento de elementos y el recall muestreado; las actualizaciones fallidas no deben dejar atributos parcialmente nuevos.
6. Calidad y fallback: mide Recall@k, la tasa de aciertos con filtro y la latencia p95 sobre datos etiquetados; cambia a recuperación por palabras clave o a una instantánea anterior cuando Redis o el filtrado no estén disponibles.

Respuesta modelo

Asignaría la clave del set por tenant y versión del modelo, mantendría los IDs de elementos estables y fijaría la dimensión del vector. En la escritura, validaría la dimensión y la versión del modelo, actualizaría de forma idempotente el vector con VADD, y luego almacenaría los atributos de año, inventario y tenant con VSETATTR; la eliminación utiliza VREM. El servicio valida las restricciones del tenant antes de solicitar un poco más de k candidatos:

VSIM products:{tenant}:{model} VALUES 3 0.12 0.08 0.44 COUNT 50 WITHSCORES FILTER ".year >= 2024 && .stock > 0"

Haría un seguimiento de las dimensiones, el recuento de elementos, la información de HNSW y la memoria de atributos, con límites por tenant. El benchmark mide Recall@k, la tasa de aciertos con filtro, la latencia p95/p99, el rendimiento (throughput) de lectura/escritura y el tiempo de recuperación, utilizando la búsqueda exacta por fuerza bruta como línea base de calidad. El transporte de FP32 utiliza codificación little-endian, o VALUES para evitar diferencias de endianness en los blobs. Si Redis, el filtrado o la compatibilidad de la versión del modelo fallan, recurriría a la recuperación por palabras clave o a la instantánea anterior y registraría el origen del resultado.

Errores comunes

• Decir que “HNSW es rápido” sin métricas de dimensión, k, filtro o calidad.
• Tratar los filtros de atributos como SQL arbitrario e ignorar los límites de expresión o el aislamiento de tenants.
• Escribir salidas de modelos de dimensiones arbitrarias en un único vector set.
• Ignorar el endianness de FP32, el tamaño de los atributos JSON y el costo de memoria de HNSW.
• No contar con un fallback a un índice antiguo, palabras clave o recuperación por instantáneas.

Una respuesta sólida conecta escrituras, consultas, capacidad, consistencia y validación de calidad; establece los límites de los comandos de Redis; y proporciona un comportamiento de fallback medible. Una respuesta débil solo dice “agregar filtros a una base de datos vectorial” sin un contrato de datos ni métricas operativas.

Preguntas de seguimiento y respuestas

¿Por qué no almacenar cada campo de negocio como un atributo?

Los atributos participan en el filtrado y consumen memoria. Conserva únicamente los campos necesarios para filtrar candidatos y luego recupera los detalles por ID desde el almacenamiento primario para evitar el crecimiento excesivo del índice y la dispersión de datos privados.

¿Qué sucede si una actualización del modelo cambia la dimensión?

Crea una clave o espacio de versiones independiente para el nuevo modelo, aplica doble escritura y evalúalo, y luego realiza la transición una vez que se superen los umbrales de Recall@k, latencia y costo. Nunca mezcles dimensiones dentro de un mismo set.

¿Qué pasa si un filtro estricto no devuelve resultados?

Devuelve una razón explícita de cero resultados y una métrica. Relaja las condiciones en el orden aprobado por el producto o cambia a la recuperación por palabras clave; nunca devuelvas en silencio resultados que violen las restricciones de tenant o inventario.

Lista de verificación para la entrevista

Conclusión en una sola frase

Trata un vector set como un componente de recuperación con contratos explícitos de dimensión, atributos y capacidad, y luego utiliza líneas base de calidad y fallback seguro para una búsqueda controlable.