Planteamiento y alcance
Este es un problema de diseño de sistemas de recuperación, no una solicitud para nombrar una base de datos vectorial. El objetivo es la búsqueda semántica sobre incrustaciones con un aislamiento estricto entre inquilinos, filtros de metadatos y permisos, latencia acotada y un contrato medible de frescura y relevancia. Asume que las incrustaciones son producidas por un modelo ascendente, que los documentos pueden reemplazarse o eliminarse, y que el servicio debe admitir tanto cargas masivas retroactivas (backfills) como actualizaciones continuas.
Qué evalúa el entrevistador
- Si separas la ingesta, la generación de incrustaciones, la construcción de índices, la atención de consultas y la evaluación.
- Si explicas por qué la búsqueda exacta es demasiado costosa y eliges deliberadamente una estrategia de vecinos más cercanos aproximados (ANN).
- Si los filtros se aplican sin degradar silenciosamente la exhaustividad o el aislamiento entre inquilinos.
- Si las actualizaciones, eliminaciones, cambios de modelo y reconstrucciones de índices tienen una semántica de visibilidad explícita.
- Si defines métricas de relevancia, exhaustividad, latencia, costo y frescura en lugar de afirmar simplemente que la "similitud" es correcta.
Preguntas para clarificar primero
- ¿Cuál es la dimensión del vector, la función de distancia, la cantidad de documentos por inquilino y la tasa esperada de consultas?
- ¿Son los filtros de inquilino y ACL restricciones duras obligatorias, o se puede eliminar un resultado después de la recuperación?
- ¿Se requiere la frescura de un minuto para cada escritura o solo para un subconjunto de colecciones activas (hot)?
- ¿Necesitamos una búsqueda híbrida de palabras clave más vectores, reclasificación (reranking) o solo recuperación por vecinos más cercanos?
- ¿Puede cambiar el modelo de incrustaciones y deben los vectores antiguos permanecer consultables durante la migración?
Un marco de respuesta en 30 segundos
“Dividiría el sistema en un registro (log) de ingesta, trabajadores de incrustación, un índice vectorial versionado y una capa de consulta sin estado. Cada registro contiene inquilino, ACL, versión del documento, versión del modelo y un estado de lápida (tombstone). El enrutamiento de consultas primero selecciona el shard o espacio de nombres del inquilino, luego realiza una búsqueda ANN filtrada y opcionalmente reclasifica un conjunto pequeño de candidatos. Un índice delta mutable maneja las escrituras recientes mientras los segmentos inmutables se reconstruyen en segundo plano; las lecturas fusionan ambos y ocultan las versiones obsoletas. Mediría la exhaustividad frente a un conjunto de referencia exacto o curado, la latencia p95, la tasa de fallos de filtro, el retraso de frescura y el costo por consulta.”
Análisis detallado paso a paso
1. Definir el contrato de datos y visibilidad
Almacena document_id, tenant_id, atributos de ACL, versión del modelo de incrustación, versión del contenido, vector y marca de tiempo de actualización. Una eliminación es un tombstone con una versión, no una suposición inmediata de que cada réplica ha eliminado el vector. Una consulta se autoriza antes de la recuperación; los predicados de inquilino y ACL son restricciones obligatorias, mientras que la clasificación de relevancia se aplica solo a los candidatos autorizados.
2. Elegir un índice ANN y el particionamiento
La búsqueda por fuerza bruta cuesta aproximadamente O(N × D) operaciones de distancia para N vectores de dimensión D. Con 100 millones de vectores, eso es inviable para un objetivo de 150 ms, por lo que se debe usar un índice ANN como HNSW o un enfoque de archivos invertidos. HNSW favorece una alta exhaustividad y lecturas rápidas con sobrecarga de memoria; los índices agrupados o cuantizados reducen la memoria y el costo, pero agregan riesgo de ajuste y de exhaustividad. Comienza con espacios de nombres o shards conscientes del inquilino, luego divide los inquilinos con alta carga y replica las particiones con muchas lecturas. No afirmes un Big-O o un número de exhaustividad universal; realiza pruebas de rendimiento de la biblioteca y la dimensión elegidas.
3. Hacer que el filtrado sea parte de la corrección de la recuperación
Un posfiltrado puede devolver menos de 20 resultados cuando los vecinos más cercanos pertenecen a otro inquilino o no cumplen con un predicado de ACL. El prefiltrado puede reducir el espacio de candidatos, pero puede hacer que los filtros dispersos sean costosos. Un diseño práctico mantiene los metadatos filtrables indexados junto con la ruta vectorial, estima la selectividad y elige un grupo de candidatos ANN más grande o un segmento filtrado dedicado cuando sea necesario. Pinecone documenta los predicados de metadatos y advierte que el filtrado es parte del contrato de búsqueda; la respuesta de la entrevista debe indicar qué sucede cuando existen menos de 20 coincidencias autorizadas.
4. Separar las escrituras recientes de los segmentos compactados
Agrega las escrituras aceptadas a un log duradero y a un pequeño índice delta mutable. Consulta tanto los segmentos base inmutables como el delta, luego fusiona por versión de documento y elimina los IDs marcados con tombstone. La compactación en segundo plano construye un nuevo segmento, verifica recuentos y exhaustividad muestreada, e intercambia atómicamente un manifiesto. Un SLA de un minuto se mide desde la escritura confirmada hasta la visibilidad en la consulta, no desde el inicio del trabajo de incrustación. Si la incrustación o la indexación se retrasan, expón el retraso y mantén visible la versión anterior en lugar de fingir que la escritura tuvo éxito.
5. Gestionar las migraciones de esquemas y modelos
Un cambio en el modelo de incrustación hace que los vectores antiguos y nuevos sean incomparables a menos que el sistema admita índices duales o un plan de proyección. Escribe la versión del modelo en cada registro, llena retroactivamente un nuevo índice, duplica las consultas (shadow queries) en ambos y compara la exhaustividad y la latencia antes de cambiar. Mantén el índice antiguo hasta que expiren los requisitos de retención y reversión (rollback). Los cambios de esquema de metadatos y ACL necesitan la misma disciplina de despliegue versionado; una coincidencia vectorial nunca debe eludir un campo de permisos recién agregado.
6. Diseñar la ruta de consulta y la política de sobrecarga
La capa de consulta autentica al inquilino, normaliza la consulta, elige la versión del modelo y se distribuye (fan out) solo a los shards relevantes. Aplica un tiempo límite, un recuento acotado de candidatos y cancelación. Si un shard agota el tiempo de espera, devuelve un resultado parcial solo cuando la API marque la completitud; de lo contrario, falla de manera cerrada (fail closed) para búsquedas sensibles a la seguridad. Almacena en caché las incrustaciones y las consultas públicas estables, pero nunca compartas una entrada de caché entre diferentes alcances de autorización. El control de admisión protege la memoria del índice y la capacidad de reclasificación bajo ráfagas de tráfico.
7. Medir relevancia, frescura y costo
Crea un conjunto de consultas etiquetadas con documentos relevantes y prohibidos. Compara los resultados de ANN con una línea base de búsqueda exacta en particiones muestreadas y reporta recall@20, precisión o nDCG, corrección de filtros y pruebas de fuga de autorización. Monitorea la latencia p50/p95/p99, los recuentos de candidatos, el tiempo de construcción del índice, el retraso de escritura a visibilidad, la acumulación de tombstones, la memoria por vector y el costo por cada mil consultas. Las métricas fuera de línea detectan regresiones en el ranking; las métricas de clics en línea necesitan salvaguardas porque el sesgo de posición puede hacer que un mal resultado parezca popular.
Compensaciones y límites
HNSW frente a índices agrupados o cuantizados
HNSW es una opción inicial sólida para cargas de trabajo con muchas lecturas cuando hay memoria disponible. IVF o la cuantización de productos pueden reducir la memoria y mejorar la eficiencia del escaneo a gran escala, pero requieren entrenamiento, ajuste y validación de exhaustividad. Elige según la tasa de actualización, la dimensión, el desbalance entre inquilinos y el presupuesto de hardware; no elijas basándote únicamente en el nombre de un producto.
Almacén vectorial nativo frente a una base de datos existente
Una base de datos de propósito general con un índice vectorial resulta atractiva cuando las colecciones son moderadas y los joins, las transacciones y los datos de ACL deben permanecer juntos. Un servicio dedicado se justifica cuando la búsqueda vectorial domina la capacidad, requiere índices ANN especializados o necesita escalado independiente. Mantén los registros de documentos y permisos de la fuente de la verdad fuera del índice cuando el almacén vectorial no pueda proporcionar las garantías transaccionales requeridas.
Un índice por inquilino frente a particiones compartidas
Los índices por inquilino simplifican el aislamiento y el control de vecinos ruidosos, pero multiplican la sobrecarga. Los índices compartidos aprovechan mejor el hardware, aunque requieren un filtrado estricto de metadatos y una programación equitativa. Usa espacios de nombres o claves de partición para inquilinos comunes y promueve a los inquilinos muy grandes o regulados a una capacidad aislada.
Respuesta de muestra de alta calidad
“Comenzaría con un log de escritura duradero y versionaría cada documento, ACL y modelo de incrustación. La capa de consulta autoriza al inquilino, se distribuye a los shards relevantes, ejecuta una búsqueda ANN filtrada y fusiona un índice delta reciente con segmentos inmutables. HNSW es una línea base para lecturas intensivas, pero lo compararía mediante benchmarks contra índices agrupados o cuantizados usando recall@20 y latencia p95. Las reconstrucciones publican un manifiesto de forma atómica, los cambios de modelo utilizan consultas en la sombra (shadow queries) y las eliminaciones son tombstones versionados. El servicio reporta corrección de filtros, retraso de escritura a visibilidad, pruebas de fuga de autorización, memoria por vector y costo de consultas; la relevancia es un contrato medido.”
Errores comunes
- Tratar la elección de una biblioteca de ANN como la arquitectura completa mientras se ignoran la ingesta, las eliminaciones y las reconstrucciones.
- Aplicar filtros de ACL después de la recuperación y devolver silenciosamente menos documentos o documentos no autorizados.
- Afirmar una exhaustividad o latencia fijas sin especificar la dimensión, las configuraciones del índice, el hardware y la carga de trabajo.
- Reemplazar un modelo de incrustaciones en el lugar de modo que los vectores antiguos y nuevos se vuelvan incomparables.
- Medir únicamente los clics y nunca mantener una línea base de relevancia exacta o etiquetada.
Preguntas de seguimiento y respuestas
¿Qué pasa si un filtro de ACL deja solo tres coincidencias?
Devuelve tres con una señal explícita total_or_completeness, o devuelve una respuesta vacía/insuficiente según el contrato de la API. Nunca llenes los espacios restantes con resultados no autorizados o no filtrados. Aumenta el grupo de candidatos solo dentro de la ruta de búsqueda autorizada.
¿Cómo reconstruyes un índice sin perder escrituras?
Reproduce el log duradero en el nuevo segmento, registra una marca de agua alta (high-water mark), alcanza las escrituras posteriores a esa marca, valida los recuentos y la exhaustividad muestreada, y luego publica atómicamente un manifiesto. Mantén activa la ruta delta hasta que se complete el intercambio; revierte restaurando el manifiesto anterior.
¿Cuándo puedes eliminar los vectores del modelo antiguo?
Solo después de que la evaluación en la sombra sea exitosa, el nuevo modelo esté prestando servicio, las ventanas de retención y reversión se hayan cerrado y cada ruta de consulta rechace la versión del modelo antiguo. Eliminar basándose únicamente en el tiempo es inseguro cuando trabajos retrasados o consumidores de reproducción aún hacen referencia a él.