Presentamos Milvus 3.0: búsqueda vectorial nativa de lago y un motor de recuperación más potente

Hoy lanzamos Milvus 3.0, un hito arquitectónico importante para el proyecto. Cambia tanto dónde Milvus puede crear y servir índices como cuánto trabajo de recuperación puede realizarse directamente dentro del motor.

• Milvus 3.0 introduce una ruta nativa de lake para indexar datos vectoriales que residen en almacenamiento de objetos y formatos de tabla abiertos, incluidos Parquet, Lance, Iceberg y Vortex. Los equipos pueden hacer que los datos residentes en el lake sean buscables sin mantener otra copia en una base de datos vectorial.
• Esta versión también amplía Milvus más allá de la recuperación inicial de candidatos. La ordenación del lado del servidor, la agregación, la búsqueda facetada, StructArray para estructuras anidadas de documento/fragmento y vectores ColBERT, y un índice disperso rediseñado trasladan más clasificación, agrupación y procesamiento de resultados fuera del código de la aplicación y dentro del motor de recuperación.

En conjunto, estos avances convierten a Milvus en la base de código abierto para la recuperación de IA en producción y para arquitecturas Vector Lakebase que combinan almacenamiento nativo de lake con recuperación vectorial de alto rendimiento.

Un vistazo rápido al conjunto de funciones de Milvus 3.0

Área	Funciones	Por qué importa
Recuperación nativa de lake	Colecciones externas sobre Parquet, Lance, Iceberg y Vortex	Busca datos residentes en el lake sin mantener una segunda copia de servicio
Almacenamiento basado en S3	Loon (Storage v3)	Reduce la amplificación de lecturas puntuales para el acceso de estilo serving y admite la evolución del esquema
Flujos de trabajo offline/batch y recuperación	Snapshots, Spark DataSource V2 y evolución de esquema en línea	Lleva vistas estables de colecciones a canalizaciones de evaluación, deduplicación, clustering y características
Motor de recuperación	ORDER BY, agregación, facetas, StructArray y recuperación dispersa mejorada	Traslada más procesamiento de resultados y puntuación multivectorial a Milvus
Modelo de datos y operaciones	Vectores anulables, TEXT LOB, TTL, MinHash, Woodpecker y ForceMerge	Admite modelos de datos más ricos y patrones operativos de producción

La infraestructura nativa de lake: indexa y sirve datos donde ya residen

El mayor cambio arquitectónico en Milvus 3.0 es dónde el sistema puede crear y servir índices. Los datos vectoriales pueden permanecer en formatos abiertos sobre almacenamiento de objetos mientras Milvus proporciona indexación, recuperación y API de nivel de producción.

1. Colecciones externas: indexación directamente sobre datos residentes en el lake

Muchos equipos ya almacenan embeddings en un data lake: tablas Lance, tablas Iceberg, archivos Parquet u otros conjuntos de datos de formato abierto en S3, GCS o Azure Blob Storage. Antes de Milvus 3.0, normalmente había dos opciones para buscar esos datos.

• Copiar los embeddings en una base de datos vectorial. Esto proporciona búsqueda de baja latencia, pero crea una segunda copia y una canalización ETL que debe permanecer sincronizada.
• Consultar el lake directamente. Esto evita la duplicación, pero sin índices ANN, la búsqueda vectorial se convierte en un escaneo de fuerza bruta que no puede cumplir con la latencia de producción.

Las colecciones externas introducen una tercera vía. Defines una colección de Milvus sobre datos que permanecen en el almacenamiento de objetos, mapeas campos externos a un esquema de Milvus y utilizas las mismas API de búsqueda y consulta que con una colección nativa. Los archivos de origen no se mueven; Milvus crea y sirve índices vectoriales, invertidos BM25, JSON y escalares sobre los datos externos.

Las colecciones externas son de solo lectura y zero-copy, lo que las hace útiles cuando la gobernanza, los límites de propiedad o el coste operativo exigen que el conjunto de datos de origen permanezca en el lake.

Cuando el conjunto de datos externo cambia, Milvus lee su manifiesto de almacenamiento e indexa los fragmentos recién añadidos en lugar de reconstruir toda la colección.

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

En entornos gobernados, la recuperación puede ejecutarse donde se permite que residan los datos. Para sistemas de IA a gran escala, un conjunto de datos residente en el lake puede admitir múltiples despliegues de recuperación sin un trabajo de migración entre ellos.

Las colecciones externas son una capacidad aditiva. Las colecciones nativas de Milvus siguen siendo la ruta principal para serving de baja latencia y con muchas escrituras, mientras que las colecciones externas están diseñadas para conjuntos de datos cuyo sistema de registro permanece fuera de Milvus.

Para obtener más detalles, consulta Crear una colección externa.

2. Loon (Storage v3): lecturas puntuales eficientes para la recuperación nativa de lake

Las colecciones externas plantean una pregunta obvia: el almacenamiento de objetos está diseñado para escalabilidad y durabilidad, pero ¿puede admitir las lecturas puntuales estrechas que siguen a una búsqueda ANN?

El desafío es la amplificación de lectura. La búsqueda vectorial suele ejecutarse en dos etapas: un índice ANN devuelve IDs candidatos y el sistema obtiene campos seleccionados para esos candidatos. Los formatos optimizados para escaneos analíticos pueden convertir una búsqueda lógica estrecha en una lectura física mucho mayor.

Milvus 3.0 aborda este problema con Loon, también conocido como Storage v3, un motor de almacenamiento columnar basado en manifiestos para almacenamiento de objetos compatible con S3. Loon organiza los campos en ColumnGroups con IDs de fila alineados, lo que permite que los campos escalares favorezcan el filtrado y los escaneos, mientras que los vectores y los campos con muchas lecturas puntuales utilizan diseños pensados para búsquedas más estrechas.

Loon mantiene los índices vectoriales e invertidos separados del formato de archivo en lugar de incrustarlos dentro de él. Cada versión del conjunto de datos se describe mediante un manifiesto inmutable que registra sus ColumnGroups, lo que permite que el mismo motor de indexación funcione en Lance, Parquet, Iceberg y Vortex.

El diseño basado en manifiestos también hace que la evolución del esquema sea menos disruptiva. Añadir o eliminar un campo puede actualizar los metadatos sin reescribir las columnas existentes. Rellenar un nuevo campo escribe un nuevo ColumnGroup mientras deja los ColumnGroups existentes sin cambios.

Vortex es el formato predeterminado para esta ruta. Es un formato columnar abierto y compatible con Arrow, con diseños flexibles y codificaciones anidadas que se ajustan mejor a datos de IA con muchas consultas puntuales. En una prueba comparativa interna con 3 millones de filas, vectores de 128 dimensiones, S3 y 256 lectores concurrentes, la E/S medida por lectura puntual cayó de aproximadamente 9,4 MB para la línea base de Parquet a 0,07 MB para Vortex con Loon, unas 135 veces menos.

Milvus 3.0 no hace que el almacenamiento de objetos se comporte como memoria local. Reduce la amplificación de lectura que, de otro modo, haría impracticable el almacenamiento de objetos para búsquedas puntuales de estilo serving. El predicate pushdown en el formato y una variante local de Vortex son los siguientes pasos en la hoja de ruta.

Para obtener más detalles, consulta nuestro blog: Por qué creamos Loon y el proyecto Vortex.

3. Snapshots: vista en un punto en el tiempo sin copia de datos

Los trabajos offline necesitan una vista coherente de los datos incluso mientras las colecciones de producción siguen recibiendo escrituras. Un snapshot de Milvus es una vista de solo lectura en un punto en el tiempo que registra referencias a archivos de datos, índices y metadatos existentes en lugar de copiar todo el conjunto de datos.

Eso hace que los snapshots sean lo bastante económicos como para crearlos antes de operaciones arriesgadas, como un cambio de modelo, un trabajo de re-embedding o una migración de esquema. Restaurar un snapshot puede reutilizar los archivos de datos e índices existentes mediante copia del lado del servidor en el almacenamiento de objetos, en lugar de reimportar cada fila y reconstruir cada índice. Esta función es especialmente útil para cargas de trabajo que avanzan rápido, como agentes de IA, donde los datos cambian constantemente y quieres puntos de recuperación frecuentes y baratos en lugar de copias de seguridad pesadas ocasionales.

La misma vista congelada puede admitir evaluación, deduplicación, validación de backfill y pruebas aisladas mientras la colección en vivo continúa aceptando escrituras. El snapshot estabiliza la entrada lógica, aunque las cargas de trabajo aún pueden compartir infraestructura como almacenamiento de objetos y ancho de banda de red.

Los snapshots no reemplazan las copias de seguridad. Un snapshot referencia archivos propiedad de la colección en vivo y es más adecuado para recuperación lógica, clonación y vistas estables de corta duración. Una copia de seguridad crea una copia independiente para retención a largo plazo y recuperación ante desastres.

Para obtener más información, consulta Snapshots, Gestionar snapshots y Casos de uso de snapshots.

4. Conector Spark: conecta Milvus con flujos de trabajo batch

Una snapshot estable solo es útil si los motores batch pueden leerla. Milvus 3.0 expone Milvus como una Spark DataSource V2, lo que permite que trabajos de Spark, Databricks y EMR lean de Milvus y escriban en Milvus como parte de canalizaciones batch estándar.

Esta función importa porque los flujos de trabajo de datos de IA son iterativos: la deduplicación alimenta el re-embedding, el clustering alimenta la evaluación y la evaluación produce conjuntos seleccionados para entrenamiento o serving. Un snapshot estable proporciona a esos trabajos una entrada coherente, mientras la colección en vivo sigue sirviendo. Con el conector Spark, el destino de un trabajo se convierte en el origen del siguiente, sin exportar una colección completa fuera de Milvus cada vez.

Milvus 3.0 también introduce operadores batch nativos de vectores para tareas como deduplicación, detección de anomalías y clustering, manteniendo el trabajo intensivo en cómputo fuera de la ruta de consulta online mientras opera directamente sobre datos vectoriales.

5. Cambios de esquema en línea y backfill

Un esquema rara vez permanece estático en producción: los equipos añaden nuevos modelos de embedding, vectores dispersos, etiquetas, campos de metadatos y políticas de retención con el tiempo. Milvus 3.0 les permite añadir, rellenar y eliminar columnas mientras el servicio continúa, en lugar de las reconstrucciones disruptivas que esto solía requerir.

Añadir o eliminar una columna no requiere reescribir los datos existentes. client.add_collection_field(...) incorpora una nueva columna anulable sin desconectar la colección, y client.drop_collection_field(...) elimina un campo obsoleto o experimental en tiempo de ejecución. Ninguna de las dos operaciones reescribe los datos existentes: cada una es un cambio en el manifiesto de la colección, no en los archivos de datos, por eso no hay reconstrucción.

Milvus 3.0 admite dos rutas de backfill:

• Backfill interno (en 3.0) es para valores derivados de campos existentes. Milvus puede generar un vector disperso BM25 a partir de una columna de texto dentro del kernel, eliminando la necesidad de un codificador del lado del cliente al crear recuperación híbrida densa más dispersa.
• Backfill externo(en la hoja de ruta) será para valores calculados fuera de Milvus: tomar un snapshot, ejecutar Spark contra la vista coherente, calcular una nueva columna, escribir los valores de vuelta y permitir que Milvus actualice el índice de forma incremental. Esta es la ruta prevista para grandes trabajos de re-embedding; por ejemplo, añadir una nueva columna de embedding en cientos de millones de filas mientras las escrituras continúan.

En conjunto, los cambios de esquema en línea y el backfill facilitan la evolución de canalizaciones de recuperación sin reconstruir una colección completa cada vez que cambia el modelo de datos.

Un motor más potente para la recuperación de extremo a extremo

Milvus ha admitido durante mucho tiempo más que búsqueda ANN densa, incluida la recuperación dispersa basada en BM25 y la búsqueda híbrida. Milvus 3.0 amplía el motor en un eje diferente: lleva más de la canalización de recuperación multietapa al propio Milvus, reduciendo la sobreobtención, la lógica de aplicación duplicada y la dependencia de servicios de posprocesamiento separados.

1. ORDER BY del lado del servidor: ordena dentro del motor, por segmento

Anteriormente, la ordenación requería que las aplicaciones obtuvieran candidatos de más, los trasladaran al cliente y los ordenaran allí. Eso consumía ancho de banda y hacía que el resultado final dependiera de dónde se produjera el truncamiento del lado del cliente.

Milvus 3.0 añade ORDER BY del lado del servidor, lo que permite que las cargas de trabajo de consulta ordenen filas filtradas por campos escalares como calificación, precio, frescura, inventario o marca temporal.

• En la ruta de consulta, cada segmento ordena su conjunto de resultados filtrados, los nodos de consulta fusionan esos flujos y el proxy devuelve el segmento solicitado.
• En la ruta de búsqueda, ORDER BY ordena el conjunto de candidatos ANN dentro de Milvus, reduciendo la sobreobtención del lado del cliente y el posprocesamiento duplicado. No cambia el límite de recall establecido por los candidatos ANN.

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

Esto es especialmente útil para búsquedas que combinan relevancia con restricciones empresariales o orientadas al usuario, como calificación, precio, frescura, inventario o marca temporal.

Para obtener más información, consulta Ordenar resultados de búsqueda por campos escalares y Ordenar resultados de consulta.

2. Agregación y búsqueda facetada

Milvus 3.0 añade agregación del lado de consulta con operaciones como conteo, suma, promedio, mínimo y máximo, agrupadas por uno o más campos escalares. Esto elimina un patrón común en el que los equipos extraen filas filtradas al código del cliente solo para contar, agrupar o calcular estadísticas simples.

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

Milvus 3.0 también añade agregación de búsqueda para búsqueda facetada. Después de una búsqueda ANN, Milvus agrupa los aciertos recuperados por un campo y devuelve conteos de buckets, estadísticas agregadas y los N principales aciertos de muestra por bucket: el patrón detrás de la agrupación por marca, rango de precio, color, tenant o tipo de documento. Una salvedad: la agregación de búsqueda opera sobre el conjunto de resultados recuperado por ANN, no sobre toda la colección, por lo que los conteos de facetas son aproximados. Cuando necesites conteos exactos, usa la agregación del lado de consulta.

Para obtener más información, consulta Agregar resultados de consulta.

3. StructArray para vectores anidados y modelo de interacción tardía

Muchas entidades se representan naturalmente mediante múltiples vectores. Un documento largo es una serie de fragmentos; un vídeo es una secuencia de fotogramas que preferirías mantener juntos en una fila en lugar de dispersarlos en muchas; un producto tiene varias imágenes o ángulos. Los modelos de interacción tardía llevan esto aún más lejos: ColBERT emite un vector por token, ColPali uno por parche visual. En todos los casos, la unidad que realmente quieres almacenar y buscar es la entidad completa, no cada fragmento por separado.

StructArray permite que una fila de Milvus contenga un array de longitud variable de elementos estructurados, incluidos múltiples vectores, preservando al mismo tiempo un único ID de entidad y un único conjunto de metadatos. Eso evita dividir un documento en múltiples filas y duplicar etiquetas, permisos u otros campos entre fragmentos.

Milvus admite dos granularidades de búsqueda.

• Búsqueda a nivel de elemento compara un vector de consulta con cada elemento de la lista y devuelve el elemento específico coincidente con su desplazamiento. Esto es útil cuando quieres saber qué fragmento, token, parche o imagen coincidió. Una fila puede aparecer más de una vez si coinciden varios elementos.
• Búsqueda a nivel de entidad compara la lista completa de vectores de una consulta con la lista de vectores de la fila mediante MAX_SIM, con la métrica MAX_SIM_COSINE. Cada token de consulta toma su mejor coincidencia en el documento, y esas mejores puntuaciones se suman. Esto proporciona a Milvus compatibilidad nativa con patrones de recuperación de interacción tardía como ColBERT y ColPali, manteniendo una fila por documento.

Indexar cada vector de token puede ser costoso; por eso Milvus 3.0 añade múltiples rutas de aceleración, incluidas TokenANN, Muvera y Lemur, que intercambian tamaño de índice, coste de entrenamiento y recall.

Estrategia	Representación de primera etapa	Perfil de coste	Mejor para
TokenANN	Se indexa cada vector de token.	Más alto, exacto	Modelos de alta discriminación y documentos cortos
Muvera	Un vector por documento usando FDE de proyección aleatoria.	Medio, sin entrenamiento	Documentos largos
Lemur	Un vector por documento usando compresión MLP aprendida	Más bajo, requiere entrenamiento	Modelos de baja discriminación y vectores visuales o de parches

En nuestras pruebas comparativas, Lemur iguala o supera el recall de TokenANN en la mayoría de los conjuntos de datos mientras colapsa cada documento a un único vector; la excepción son los corpus con alta varianza de longitud, donde TokenANN u otra estrategia es más segura.

Para corpus más grandes que la memoria, Milvus también admite un índice DISKANN que mantiene las listas de embeddings en disco para reducir la presión sobre la RAM.

La búsqueda a nivel de elemento ya llegó en Milvus 2.6. El filtrado para Muvera, Lemur y StructList es nuevo en 3.0.

4. Compresión de índices BM25 y SINDI

Milvus ha admitido la búsqueda de vectores dispersos en versiones anteriores. Milvus 3.0 reduce el tamaño del índice disperso mediante postings comprimidos por bloques (algoritmos relacionados con VByte más decodificación SIMD) y cuantización (fp16 para productos internos, u16 para BM25).

En un conjunto de pruebas comparativas internas de BM25, la nueva implementación fue aproximadamente 3 veces más pequeña que el índice disperso de Milvus 2.6 con un recall comparable. Un índice más pequeño reduce la presión sobre memoria y ancho de banda y puede mejorar la velocidad en cargas de trabajo limitadas por el movimiento de datos.

Milvus 3.0 también introduce SINDI, un nuevo algoritmo de recuperación dispersa optimizado para embeddings dispersos aprendidos como SPLADE. Debido a que estos embeddings producen listas de postings más densas que BM25, los algoritmos de búsqueda con mucha poda pueden dedicar un tiempo considerable de CPU a decidir qué omitir. En cambio, SINDI organiza los postings en ventanas compactas y usa acumulación de puntuación compatible con SIMD para procesarlos de forma eficiente, preservando al mismo tiempo la precisión de recuperación mediante poda sin pérdida.

También ampliamos SINDI más allá de su diseño original para incluir compatibilidad nativa con BM25, lo que permite a Milvus usar la misma ruta de recuperación dispersa optimizada tanto para embeddings dispersos aprendidos como para la búsqueda tradicional de texto completo.

En nuestras pruebas comparativas sobre 4 conjuntos de datos de vectores dispersos SPLADE, SINDI alcanza hasta aproximadamente 10 veces el QPS de MaxScore en vectores aprendidos dispersos, con un peor caso de alrededor de 5 veces.

SINDI es el valor predeterminado para la búsqueda dispersa de producto interno en Milvus 3.0.

Otras mejoras

• TEXT LOB: Almacena texto fuente largo junto a los vectores. El texto inferior a 64 KB permanece inline; los valores más grandes usan una referencia Vortex LOB.
• Compatibilidad ampliada con índices densos: Añade más opciones de índice dentro de la familia Faiss, incluidas SVS, Panorama, PQ, IVFPQ y ScaNN, para diferentes requisitos de escala, memoria y recall.
• MinHash y búsqueda de casi duplicados: Genera firmas MinHash en el lado del servidor y recupera candidatos casi duplicados usando MINHASH_LSH.
• Vectores anulables y nuevos tipos: Permite que los campos vectoriales sean NULL y añade TIMESTAMPTZ para filtrado consciente del tiempo y políticas de retención.
• Diccionarios de texto completo personalizados: Registra diccionarios, sinónimos y recursos de palabras vacías en el clúster para tokenización multilingüe y específica del dominio.
• Woodpecker independiente: Ejecuta el registro write-ahead de Milvus como un servicio escalable y observable de forma independiente.
• Entidad TTL****: Expira registros individuales mediante un campo TIMESTAMPTZ, con filtrado MVCC seguido de recolección de basura durante la compactación.
• ForceMerge: Compacta segmentos pequeños a un tamaño objetivo y reconstruye índices para reducir la amplificación de lectura antes de un servicio sostenido con muchas lecturas.
• Y más

Empieza con Milvus 3.0

Milvus 3.0 está disponible hoy bajo la licencia Apache 2.0 y sigue siendo un proyecto de LF AI & Data. Para empezar:

• Lee las notas de la versión y la guía de inicio rápido, y obtén el código fuente en github.com/milvus-io/milvus.
• Únete a la comunidad de Milvus en Discord o reserva una sesión de Milvus Office Hours para hablar sobre tu caso de uso con los mantenedores.

Milvus 3.0 y Zilliz Vector Lakebase

Milvus 3.0 establece la base de código abierto para la recuperación de IA en producción y la arquitectura emergente Vector Lakebase, que combina almacenamiento nativo de lake con recuperación vectorial de alto rendimiento sobre una única fuente de verdad, cada uno al coste adecuado.

Zilliz Cloud es un Vector Lakebase totalmente gestionado creado por el equipo detrás de Milvus. Comparte la misma arquitectura distribuida y nativa de lake que Milvus y es totalmente compatible con la API de Milvus. Impulsado por su motor de indexación propietario Cardinal, Zilliz Cloud ofrece hasta 10× mejor relación precio-rendimiento que los enfoques estándar de indexación de código abierto, al tiempo que elimina la complejidad operativa de gestionar infraestructura. Las capacidades empresariales incluyen cómputo scale-to-zero, recuperación ante desastres entre regiones, despliegue BYOC, seguridad y cumplimiento de nivel empresarial (SOC 2, HIPAA, ISO 27001 y GDPR), y hasta un SLA del 99,99 %.

Los desarrolladores pueden desplegar Milvus como una base de datos vectorial de código abierto o usar Zilliz Cloud para una plataforma gestionada en múltiples cargas de trabajo a lo largo del ciclo de vida de los datos de IA.

Qué viene después

La hoja de ruta de Milvus se basa en la arquitectura 3.0 con predicate pushdown para colecciones externas, backfill externo, operadores Spark adicionales y compatibilidad con más formatos de tabla, incluidos Delta Lake y Apache Paimon.

La dirección general está clara: los sistemas de datos de IA necesitan un bucle más estrecho entre la recuperación online y la mejora de datos offline. Los datos vectoriales no deberían tener que copiarse en sistemas separados cada vez que los equipos quieran buscarlos, analizarlos, mejorarlos o servirlos.