Resumen Técnico: Un Benchmark Unificado para la Búsqueda de Vectores con Preservación de la Privacidad

1. Planteamiento del Problema

La búsqueda de vectores es una infraestructura fundamental para la búsqueda semántica, los sistemas de recomendación y la Generación Aumentada por Recuperación (RAG). Sin embargo, las implementaciones estándar carecen de privacidad: el proveedor del servicio observa tanto los embeddings de la consulta como los del corpus. Esta exposición crea riesgos de privacidad significativos, incluyendo el potencial de ataques de "inversión de embeddings", donde un atacante puede reconstruir el texto original o datos sensibles (por ejemplo, registros médicos) a partir de embeddings densos, incluso sin tener acceso a los pesos internos del modelo.

Aunque existen esquemas criptográficos para mitigar esta filtración (por ejemplo, SAP, EMVP, BNTM, Tiptoe), históricamente se han evaluado de forma aislada. Cada estudio utiliza diferentes corpus, modelos de embedding, configuraciones de hardware, modelos de amenazas y definiciones de métricas. En consecuencia, los profesionales carecen de una base defendible para elegir un esquema, ya que las cifras de rendimiento no son directamente comparables. El problema central abordado es la ausencia de un benchmark unificado para evaluar las compensaciones entre las garantías de privacidad, el rendimiento (throughput/latencia) y la precisión de la recuperación entre estos esquemas.

2. Metodología

Los autores construyeron un entorno experimental uniforme para comparar cinco esquemas: una línea base de Texto Plano (Plaintext) y cuatro mecanismos de preservación de la privacidad (SAP, EMVP, BNTM y Tiptoe).

Configuración Experimental

• Corpus y Carga de Trabajo: El benchmark utiliza la colección de pasajes MS MARCO (8.8M de pasajes) y un subconjunto de 100k. Las consultas se generan a partir del conjunto de datos MS MARCO utilizando el modelo de embedding E5-base-v2 (768 dimensiones).
• Indexación: Para asegurar la comparabilidad, todos los esquemas utilizan un índice de Archivo Invertido (IVF) compartido con agrupamiento k-means. Esto evita la incompatibilidad de los índices basados en grafos (como HNSW) con los esquemas de cifrado de extremo a extremo.
• Hardware: Los experimentos se ejecutan en un Intel Xeon Gold 6426Y de doble socket (64 núcleos lógicos) con 128 GB de RAM y una NVIDIA RTX 5000 Ada GPU (32 GB de VRAM).
• Métricas: El rendimiento se mide mediante throughput (consultas/segundo), latencia de extremo a extremo, recall@10, costo de comunicación (configuración, online, offline) y uso del ancho de banda de memoria.
• Parámetros de Seguridad: Todos los esquemas criptográficos están configurados para una seguridad de 128 bits. SAP utiliza un parámetro de perturbación $\beta$ para ajustar la relación privacidad vs. recuperación.

Los Esquemas Comparados

1. Texto Plano (Plaintext): Línea base sin cifrar.
2. SAP (Perturbación Aditiva Simétrica): Utiliza cifrado que preserva la comparación de distancias. El cliente perturba los vectores antes de la carga. El servidor compara las distancias directamente sobre los textos cifrados. Oculta los valores exactos de los vectores pero revela la geometría del corpus (distancias relativas).
3. EMVP: Cifra los vectores en una matriz. El servidor calcula productos matriz-vector (matvec) cifrados para los clusters enrutados. Proporciona indistinguibilidad computacional (oculta la consulta y el corpus) pero revela el cluster accedido.
4. BNTM: Similar a EMVP pero se basa en la suposición de Aprendizaje de Paridad con Ruido (LPN). Añade verificabilidad ante servidores maliciosos, permitiendo al cliente verificar la corrección de la respuesta del servidor utilizando el algoritmo de Freivalds.
5. Tiptoe: Utiliza Recuperación de Información Privada (PIR) sobre todo el corpus. El servidor realiza un matvec sobre toda la base de datos, ocultando el cluster específico accedido por la consulta. Ofrece la privacidad más fuerte (ocultando los patrones de acceso) pero incurre en el mayor costo computacional.

3. Contribuciones Clave

1. Entorno de Evaluación Unificado: Los autores construyeron un único marco de software que aisla la primitiva criptográfica del resto del pipeline, asegurando que las diferencias de rendimiento se deban únicamente a las especificaciones del esquema y no a artefactos de implementación.
2. Benchmarking Exhaustivo: El estudio evalúa los esquemas a través de múltiples dimensiones: compensaciones de recall-throughput, rendimiento CPU vs. GPU, costos de comunicación (configuración, online, offline), requisitos de ancho de banda de memoria y tiempos de construcción del índice.
3. Reproducibilidad: Todos los artefactos experimentales, mediciones brutas y código se publican de forma abierta para garantizar la transparencia.

4. Resultados Clave

Compensaciones entre Rendimiento y Privacidad

• SAP: Logra un rendimiento casi idéntico a la línea base de Texto Plano (sobrecarga insignificante), pero solo proporciona privacidad de "instantánea"; el servidor aún puede inferir la geometría relativa del corpus.
• EMVP: Proporciona una fuerte indistinguibilidad criptográfica (ocultando tanto la consulta como el corpus) pero incurre en una penalización de throughput de 4× en comparación con el Texto Plano en CPU.
• BNTM: Añade verificabilidad ante servidores maliciosos a las garantías de EMVP. Esto introduce un costo de latencia mediana de 21× adicional respecto al Texto Plano (o aproximadamente 22× más lento que EMVP en algunos contextos, aunque el resumen nota un costo de 22× sobre el Texto Plano).
• Tiptoe: Oculta el patrón de acceso al cluster por completo. Sin embargo, es prohibitivamente lento, incurriendo en un costo de 190× por consulta en comparación con el Texto Plano en un subconjunto de 100k. Su recall también es significativamente menor debido a la cuantización y a la restricción de buscar en un solo cluster por consulta.

Aceleración de Hardware (GPU)

• Texto Plano y SAP: Se benefician significamente de la aceleración por GPU (mejora de velocidad de 1.8–1.9×) porque sus operaciones de puntuación están limitadas por cómputo y son paralelizables.
• EMVP y BNTM: No se benefician de las GPUs; de hecho, EMVP funciona peor en GPU. Estos esquemas están limitados por el ancho de banda de memoria. Las matrices cifradas son demasiado grandes para caber en la memoria de la GPU (por ejemplo, 91 GB para EMVP en un corpus de 8.8M), lo que obliga a transmitir los datos a través del bus PCIe, anulando las ventajas de cómputo de la GPU.
• Tiptoe: No fue evaluado en GPU en este benchmark debido a restricciones arquitectónicas.

Comunicación y Memoria

• Red vs. Memoria: Los esquemas clasifican de forma distinta según la métrica. BNTM tiene el tráfico de red más bajo (tamaño de respuesta pequeño) pero requiere leer cantidades masivas de datos de la memoria del servidor (comparable a EMVP).
• Desglose de Latencia:
  • Texto Plano/SAP están limitados por el cómputo del servidor.
  • EMVP y BNTM están limitados por la decodificación del lado del cliente (decodificar respuestas cifradas).
  • Tiptoe está limitado por la descompresión de la respuesta (descomprimir resultados de PIR).

Tiempo de Construcción del Índice

Los tiempos de construcción del índice son relativamente comparables (dentro de una banda de 2.5×), dominados por el paso de agrupamiento k-means (10.5s para 100k). Las sobrecargas de cifrado para EMVP y Tiptoe añaden aproximadamente 10–15 segundos al tiempo de construcción.

5. Significado y Afirmaciones

El artículo desafía la creencia prevalente de que la privacidad criptográfica para la búsqueda de vectores es "inalcanzable". Los autores demuestran que:

• La privacidad no es una penalización plana: Existen esquemas en una frontera de Pareto. Los profesionales pueden elegir un nivel de privacidad (por ejemplo, ocultar solo la consulta frente a ocultar los patrones de acceso) con un costo cuantificable correspondiente.
• La implementación importa: El rendimiento de un esquema depende fuertemente de los detalles de implementación, particularmente de los patrones de acceso a la memoria. Un esquema con bajo tráfico de red (como BNTM) puede seguir siendo lento debido a los altos requisitos de ancho de banda de memoria, lo que también dicta la idoneidad para GPU.
• Guía Accionable: Los resultados proporcionan "puntos de acción" concretos para los profesionales:
  • Use SAP si no es necesario ocultar la geometría del corpus pero se deben proteger los valores de los vectores (costo casi nulo).
  • Use EMVP si se necesita el cifrado total de la consulta y el corpus (costo de 4×).
  • Use BNTM si no se puede asumir la honestidad del servidor (añade costo de verificación).
  • Use Tiptoe solo si es crítico ocultar el patrón de acceso al cluster (qué cluster se consulta), aceptando penalizaciones de latencia masivas.

El trabajo concluye que, si bien la privacidad conlleva un costo, no es una barrera insuperable, y la elección del esquema debe basarse en modelos de amenazas específicos y restricciones de hardware en lugar de una suposición general de inviabilidad.