Diez millones de embeddings de 768 dimensiones almacenados en float32 ocupan unos 30,72 GB antes de sumar metadatos, identificadores y estructuras de búsqueda. TurboVec reduce la parte vectorial a cerca de 4 GB mediante TurboQuant, un sistema de cuantización desarrollado por Google que no necesita entrenar un libro de códigos específico para cada corpus. Para desarrolladores y administradores de sistemas, la propuesta abre una alternativa a desplegar una base vectorial distribuida cuando el caso de uso puede resolverse dentro de un único servidor.
Las claves de TurboVec para RAG en 30 segundos
- TurboQuant convierte embeddings de 32 bits en representaciones de dos o cuatro bits por dimensión.
- Diez millones de vectores de 768 dimensiones pueden bajar de 30,72 GB a unos 3,84 GB.
- El método base no necesita entrenarse con el corpus ni reconstruirse cuando llegan documentos nuevos.
- TurboVec está escrito en Rust, ofrece bindings para Python y aprovecha SIMD en ARM y x86.
- Puede integrarse con LangChain, LlamaIndex, Haystack y Agno, aunque no sustituye todas las funciones de una base vectorial distribuida.
La reducción no parte de una nueva arquitectura de clúster ni de mover los datos a un servicio externo. TurboVec comprime los propios vectores y ejecuta la búsqueda localmente. Esto permite mantener colecciones mayores en memoria, reducir el número de nodos y aprovechar mejor las cachés del procesador.
La diferencia puede ser suficiente para cambiar el diseño de una aplicación RAG. Un índice que requería una máquina con 64 GB de RAM podría entrar en un servidor más pequeño, compartir recursos con otros servicios o ejecutarse en nodos ARM de bajo consumo.
No obstante, la cifra de 4 GB describe únicamente los embeddings cuantizados. Los documentos, metadatos, permisos, índices textuales y estructuras auxiliares continúan ocupando espacio.
Qué hace TurboQuant con cada embedding
Los embeddings suelen almacenarse como matrices de números en coma flotante. Un vector de 768 dimensiones en float32 utiliza:
768 dimensiones × 4 bytes = 3.072 bytesCon diez millones de documentos:
10.000.000 × 3.072 bytes = 30.720.000.000 bytesEso equivale a unos 30,72 GB en unidades decimales. El sistema todavía tendrá que reservar memoria para los identificadores, las normas, las listas de resultados y cualquier índice auxiliar.
TurboQuant reduce cada coordenada a cuatro bits, o incluso dos, después de aplicar varias transformaciones matemáticas.
| Fase | Operación | Objetivo |
|---|---|---|
| Normalización | Separa la magnitud y la dirección del vector | Trabajar con direcciones comparables |
| Rotación | Aplica una transformación ortogonal aleatoria | Distribuir la información entre las dimensiones |
| Cuantización | Asigna cada valor a un intervalo precalculado | Representar cada dimensión con pocos bits |
| Empaquetado | Agrupa códigos dentro de bytes | Reducir memoria y transferencias |
| Corrección | Conserva información auxiliar por vector | Compensar el error introducido |
La rotación ayuda a evitar que unas pocas dimensiones concentren demasiada información. Tras esa transformación, las coordenadas se aproximan a una distribución matemática predecible. Los límites de los intervalos pueden calcularse de antemano sin analizar todo el conjunto de documentos.
Esta diferencia separa TurboQuant de algunas variantes de Product Quantization, o PQ. En un flujo tradicional, el sistema toma una muestra del corpus, entrena centroides y genera libros de códigos adaptados a esos datos. Si la distribución cambia de forma considerable, puede ser necesario repetir el proceso.
TurboQuant parte de tablas precalculadas. Los nuevos vectores pasan por la misma normalización, rotación y cuantización, por lo que el índice puede crecer sin volver a entrenar sus códigos.
Cuánta RAM puede ahorrar en un servidor RAG
El cálculo teórico depende de la dimensión y del número de bits utilizado.
| Número de vectores | Dimensiones | Formato | Memoria vectorial aproximada |
|---|---|---|---|
| 10 millones | 768 | float32 | 30,72 GB |
| 10 millones | 768 | 4 bits | 3,84 GB |
| 10 millones | 768 | 2 bits | 1,92 GB |
| 10 millones | 1.536 | float32 | 61,44 GB |
| 10 millones | 1.536 | 4 bits | 7,68 GB |
| 10 millones | 1.536 | 2 bits | 3,84 GB |
La memoria real será superior. TurboVec necesita guardar identificadores, factores de corrección, alineamiento y estructuras internas. También puede existir una copia temporal durante la ingesta o la carga del índice.
Aun así, la diferencia frente a float32 continúa siendo grande. Además, reducir el tamaño no solo permite instalar menos RAM. También disminuye el tráfico entre memoria y procesador, una de las limitaciones habituales de las búsquedas por fuerza bruta.
Cuando el conjunto cabe en las cachés de último nivel con mayor frecuencia, el procesador dedica menos tiempo a esperar datos. En cargas de búsqueda vectorial, esta mejora puede ser tan importante como el número de operaciones aritméticas.
Rust, Python y aceleración SIMD
TurboVec está desarrollado en Rust y ofrece bindings para Python. Esta combinación busca mantener un núcleo de búsqueda con control directo de memoria sin obligar a los equipos de datos a abandonar sus aplicaciones en Python.
La implementación emplea instrucciones SIMD, que permiten ejecutar la misma operación sobre varios valores en paralelo.
| Plataforma | Ruta acelerada prevista |
|---|---|
| ARM de 64 bits | NEON |
| x86 moderno | AVX-512BW |
| x86 compatible | AVX2 |
| Sistemas sin SIMD compatible | Implementación escalar |
En pruebas publicadas por el proyecto sobre un Apple M3 Max, TurboVec superó a FAISS IndexPQFastScan entre un 10 % y un 19 % en determinadas configuraciones. En un Intel Xeon Platinum 8481C quedó cerca de FAISS y obtuvo ventajas menores en varias pruebas de cuatro bits.
Estos resultados no significan que TurboVec siempre sea más rápido. El rendimiento depende de la dimensión del embedding, la arquitectura, el tamaño de k, el número de consultas simultáneas y la configuración del índice.
Antes de sustituir FAISS o cualquier otra solución conviene construir un benchmark con los datos reales del proyecto.
import time
def benchmark(store, queries, k=10):
start = time.perf_counter()
for query in queries:
store.similarity_search_by_vector(query, k=k)
elapsed = time.perf_counter() - start
return {
"queries": len(queries),
"seconds": elapsed,
"queries_per_second": len(queries) / elapsed,
}Lenguaje del código: JavaScript (javascript)Además del rendimiento, la prueba debería medir recall, consumo máximo de memoria, tiempo de ingesta y comportamiento con filtros.
Filtrado por ID dentro de la búsqueda
El filtrado suele ser uno de los puntos débiles de un RAG con permisos.
Supóngase una base con diez millones de fragmentos repartidos entre cientos de clientes. Una consulta puede recuperar los 20 vectores más cercanos y aplicar después un filtro por organización. Si solo dos pertenecen al usuario, el sistema devolverá pocos resultados o tendrá que solicitar cientos de candidatos para encontrar suficientes documentos autorizados.
TurboVec permite pasar identificadores aceptados o máscaras de filtrado al propio proceso de búsqueda. El motor evalúa únicamente los candidatos permitidos y calcula el top-k dentro de ese subconjunto.
Este patrón resulta útil para:
- separación entre clientes;
- permisos por departamento;
- filtros temporales;
- búsqueda previa mediante SQL;
- combinación con BM25;
- selección por tipo de documento.
El filtro del índice no sustituye el control de acceso de la aplicación. El backend debe validar siempre que el usuario puede acceder a cada documento antes de devolver el contenido.
Una arquitectura prudente separaría ambas responsabilidades:
Usuario
│
▼
API de aplicación
│
├── Valida identidad y permisos
│
├── Obtiene IDs autorizados
│
▼
TurboVec
│
├── Busca solo dentro de esos IDs
│
▼
Almacén documental
│
└── Verifica de nuevo la autorizaciónEsta doble comprobación reduce el riesgo de que un error en el índice o en el filtrado exponga información de otro cliente.
Integración con LangChain y LlamaIndex
TurboVec ofrece adaptadores orientados a utilizarse como almacén vectorial en LangChain, LlamaIndex, Haystack y Agno. La idea es mantener la interfaz habitual de inserción y búsqueda, mientras el motor interno utiliza TurboQuant.
Un flujo simplificado podría mantener esta estructura:
documents = load_documents()
chunks = split_documents(documents)
vectors = embedding_model.embed_documents(chunks)
vector_store.add(
texts=chunks,
embeddings=vectors,
ids=document_ids,
)
results = vector_store.search(
query_embedding,
k=10,
allowed_ids=authorized_ids,
)La compatibilidad no implica que todas las aplicaciones puedan cambiar de backend sin pruebas. Los equipos deben revisar:
- formato de persistencia;
- operaciones de borrado y actualización;
- filtros disponibles;
- comportamiento en procesos concurrentes;
- carga inicial del índice;
- compatibilidad entre versiones;
- recuperación después de un fallo.
También conviene comprobar cómo se despliega el índice cuando existen varios workers. Si cada proceso carga su propia copia, el ahorro de memoria puede reducirse rápidamente. En ese caso puede resultar preferible ejecutar TurboVec como servicio interno o utilizar memoria compartida cuando la implementación lo permita.
Qué cambia para un administrador de sistemas
Desde el punto de vista operativo, TurboVec puede simplificar proyectos que no necesitan una base vectorial distribuida.
Una instalación local podría organizarse así:
| Componente | Función |
|---|---|
| API RAG | Recibe consultas y aplica autenticación |
| Modelo de embeddings | Convierte documentos y preguntas en vectores |
| TurboVec | Mantiene el índice cuantizado y realiza búsquedas |
| PostgreSQL | Guarda documentos, metadatos, usuarios y permisos |
| Almacenamiento de objetos | Conserva archivos originales |
| Sistema de métricas | Registra latencia, recall, errores y memoria |
| Copias de seguridad | Protege índices, documentos y configuración |
El índice debería almacenarse en un volumen persistente y reconstruirse a partir de los datos originales cuando sea necesario. Aunque guardar una copia del índice acelera la recuperación, la fuente de verdad debería continuar siendo el almacén documental y su base de metadatos.
También deben definirse procedimientos para:
- crear copias consistentes;
- verificar la integridad del índice;
- desplegar nuevas versiones;
- reconstruirlo sin detener el servicio;
- medir el tiempo de calentamiento;
- controlar el consumo de memoria;
- revertir una actualización.
Un despliegue con dos versiones del índice permite actualizar sin interrupciones:
index-v1 ──► producción
index-v2 ──► construcción y validación
Tras las pruebas:
index-v2 ──► producción
index-v1 ──► reserva o eliminaciónTurboQuant evita volver a entrenar el cuantizador, pero la aplicación puede necesitar regenerar el índice si cambia el modelo de embeddings. Los vectores creados por modelos distintos no suelen ser comparables dentro del mismo espacio.
Cuándo no sustituye a una base vectorial
TurboVec encaja como biblioteca embebida o motor local, pero una base vectorial completa puede seguir siendo más adecuada cuando se necesitan:
- alta disponibilidad entre varios nodos;
- replicación automática;
- particionado horizontal;
- control multiusuario integrado;
- escalado independiente de lectura y escritura;
- recuperación ante desastres administrada;
- grandes tasas de actualización simultánea;
- operación distribuida entre regiones.
| Opción | Encaje principal | Ventaja | Coste operativo |
|---|---|---|---|
| TurboVec | Índices locales y RAG privado | Memoria reducida y despliegue sencillo | El equipo gestiona persistencia y disponibilidad |
| FAISS | Bibliotecas de búsqueda y experimentación | Madurez y numerosos tipos de índice | Requiere construir la capa operativa |
| pgvector | RAG unido a datos relacionales | Menos componentes y SQL | Escala condicionada por PostgreSQL |
| Qdrant | Servicio vectorial con filtros | Persistencia y API preparada | Otro servicio que mantener |
| Elasticsearch | Búsqueda híbrida | Texto, filtros y vectores en una plataforma | Mayor consumo de recursos |
| Pinecone | Servicio administrado | Reduce la administración | Coste, dependencia externa y residencia de datos |
La decisión no debería basarse únicamente en consultas por segundo. Importan también el coste de operación, la recuperación ante fallos, la experiencia del equipo y los requisitos de cumplimiento.
Privacidad: ejecutar dentro de la VPC no basta
TurboVec puede funcionar completamente dentro de una nube privada, una VPC o un servidor local. No necesita enviar el índice a un proveedor externo, pero eso no garantiza por sí solo que todo el flujo sea privado.
Los documentos pueden salir de la infraestructura al generar los embeddings si se utiliza una API pública. Los registros de aplicación también pueden almacenar consultas sensibles. Además, los ficheros del índice contienen representaciones matemáticas que deben tratarse como datos potencialmente confidenciales.
Una instalación privada debería incluir:
- embeddings generados localmente o mediante un proveedor autorizado;
- cifrado de volúmenes;
- TLS entre servicios;
- credenciales de corta duración;
- control de acceso por documento;
- auditoría de consultas;
- límites de retención;
- eliminación verificable;
- copias de seguridad cifradas.
La cuantización reduce la precisión con la que se almacena cada vector, pero no debe considerarse un mecanismo de anonimización.
Preguntas frecuentes
¿TurboVec necesita una GPU?
No. El motor está orientado a CPU y aprovecha instrucciones SIMD como NEON, AVX2 y AVX-512. La generación de embeddings sí puede beneficiarse de GPU según el modelo utilizado.
¿Cuánta memoria necesita para diez millones de vectores?
Diez millones de embeddings de 768 dimensiones ocupan unos 30,72 GB en float32, 3,84 GB con cuatro bits y 1,92 GB con dos bits, antes de añadir estructuras auxiliares.
¿Hay que reconstruir el índice cuando se incorporan documentos?
No por el crecimiento normal del corpus. TurboQuant no necesita volver a entrenar libros de códigos. Sí será necesario regenerar los vectores si cambia el modelo de embeddings o su dimensión.
¿Puede utilizarse en producción?
Puede resultar adecuado para índices locales y servicios RAG controlados, pero el equipo debe evaluar madurez, persistencia, concurrencia, recuperación ante fallos y compatibilidad antes de sustituir una plataforma existente.
