Notas de la versión
¡Descubre las novedades de Milvus! En esta página se resumen las nuevas funciones, las mejoras, los problemas conocidos y las correcciones de errores de cada versión. Te recomendamos que visites esta página con regularidad para estar al tanto de las actualizaciones.
v3.0-beta
Fecha de lanzamiento: 9 de mayo de 2026
| Versión de Milvus | Versión del SDK de Python | Versión del SDK de Node.js |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta amplía la base de datos vectorial de Milvus con una nueva integración en el ecosistema Open Lake: External Collection permite a Milvus consultar tablas externas de Lake sin copia, y Spark puede leer colecciones de Milvus directamente a través de Snapshot. Esta versión también ofrece una recuperación más completa, un esquema más expresivo, una personalización más profunda de la búsqueda de texto, controles más precisos del ciclo de vida de los datos y los modelos, y más controles por parte del operador. Milvus 3.0 es el núcleo central de Zilliz Lakebase, impulsando su servicio unificado, descubrimiento y procesamiento por lotes.
Ve el vídeo a continuación para obtener más información sobre Milvus 3.0 y la sesión de preguntas y respuestas con los principales mantenedores:
Características principales
Colección externa
En los flujos de datos típicos de IA, terabytes de incrustaciones y metadatos ya se encuentran en el almacenamiento de objetos como tablas Parquet, Lance o Iceberg. Copiar esos datos a Milvus duplica el coste de almacenamiento, añade un flujo de trabajo ETL que debe mantenerse sincronizado y aleja la gobernanza de los datos del cliente.
La colección externa elimina la copia. Una colección de Milvus puede hacer referencia a los archivos allí donde ya se encuentran, y Milvus gestiona únicamente el esquema, los índices y la ejecución de consultas. Una actualización incremental mantiene la colección alineada con los archivos subyacentes. Los clientes cuyos datos no pueden salir del lago, como los equipos de finanzas y de atención sanitaria, pueden ejecutar la recuperación de vectores sobre esos datos allí donde se encuentran. Un único conjunto de datos residente en el lago también puede servirse desde varias instancias de Milvus a la vez.
Para obtener más información, consulte Crear una colección externa.
Instantánea
La entrega y el descubrimiento por lotes a menudo necesitan la misma colección al mismo tiempo. La evaluación de modelos A/B, la deduplicación a gran escala, la validación de rellenado y la reversión de versiones requieren una vista estable de la colección mientras siguen produciéndose escrituras.
Snapshot crea una vista de solo lectura de una colección en un momento determinado haciendo referencia a segmentos existentes en lugar de copiar datos, por lo que el coste marginal de almacenamiento es casi nulo. Los trabajos por lotes pueden leer desde el Snapshot bajo aislamiento de tipo MVCC mientras la colección activa sigue aceptando escrituras.
Para obtener más información, consulte Instantáneas, Gestionar instantáneas y Casos de uso de instantáneas.
Ordenar por en consultas y búsquedas
La búsqueda y la consulta ahora admiten la ordenación por varios campos, con la ordenación trasladada al núcleo de Milvus y la configuración de « ASC » y « DESC » por campo. Esto resuelve una deficiencia común en producción: el Top-K basado únicamente en la distancia a menudo no se ajusta a las necesidades empresariales cuando el elemento más similar no es el más barato, el más reciente o el más popular.
Las aplicaciones ya no tienen que recuperar resultados en exceso y volver a ordenarlos en el cliente para expresar una clasificación compuesta.
Para obtener más información, consulte Ordenar resultados de búsqueda por campos escalares y Ordenar resultados de consulta.
Agregación de consultas
La generación de estadísticas de distribución de inquilinos, recuentos de integridad de campos o el progreso del lanzamiento de versiones a partir de una colección de Milvus solía requerir la recuperación de las entidades coincidentes en el cliente y su agregación allí. Milvus 3.0 incorpora la agregación escalar de estilo SQL en el núcleo. Una llamada de consulta acepta expresiones de agregación de tipo « group_by_fields » y « output_fields », incluyendo « count(*) », « count(<field>) », « sum(<field>) », « avg(<field>) », « min(<field>) » y « max(<field>) ». La agregación se evalúa en el lado del servidor tras el filtrado.
Para obtener más información, consulte Resultados de consultas agregadas.
Vector nulo
Las incrustaciones suelen generarse de forma asíncrona, por lo que una entidad puede llegar antes que su vector. Los datos multimodales también tienen lagunas naturales, como un vídeo sin subtítulos o un producto sin imagen. Las versiones anteriores no ofrecían una solución adecuada: las aplicaciones retrasaban la escritura hasta que el vector estuviera listo o rellenaban un vector marcador de posición, y ambas opciones perjudicaban la calidad de la recuperación.
Milvus 3.0 admite el valor NULL en los campos vectoriales de los seis tipos de vectores. La búsqueda omite automáticamente los vectores NULL, la calidad de la recuperación no se ve afectada y los vectores NULL prácticamente no ocupan espacio de almacenamiento. La función « AddField » también se extiende a los campos vectoriales con este cambio: con « nullable=True », una colección existente puede añadir nuevos campos vectoriales en línea sin necesidad de reconstruirla.
Para obtener más información, consulte Campos nulos.
Diccionario personalizado y diccionario de sinónimos
Los tokenizadores predeterminados no siempre cumplen los requisitos de calidad de búsqueda en producción. El chino, los dominios verticales como la medicina, el derecho y la química, y los corpus multilingües pueden beneficiarse sustancialmente de los diccionarios personalizados y las tablas de sinónimos. Hasta ahora, estos recursos existían principalmente como reescrituras de consultas del lado de la aplicación.
Milvus 3.0 añade un mecanismo FileResource para registrar diccionarios de tokenizadores personalizados, listas de sinónimos, listas de palabras vacías y reglas de descomposición de compuestos. Una vez registrado, se puede hacer referencia a un recurso desde cualquier tokenizador o filtro y surte efecto en BM25, los analizadores y Text Match. Ahora los diccionarios y los sinónimos se pueden versionar y gestionar de forma centralizada, en lugar de estar dispersos por el código de la aplicación.
Para obtener más información, consulte Gestionar recursos de archivo.
TTL de entidad
El TTL a nivel de colección y de partición es demasiado general para muchos escenarios de ciclo de vida y cumplimiento normativo. Los diferentes inquilinos dentro de la misma colección suelen tener reglas de retención diferentes, y es posible que las entidades individuales deban caducar según un calendario que no coincida con el resto de la colección.
Milvus 3.0 admite el TTL por entidad. Declare un campo « TIMESTAMPTZ » en el esquema, márquelo como campo TTL a través de una propiedad de la colección y Milvus recuperará automáticamente las entidades caducadas. Esto cubre las solicitudes del derecho al olvido, los datos de sesión caducados y el historial de conversaciones delimitado sin necesidad de limpieza por parte de la aplicación.
Para obtener más información, consulte Establecer el TTL a nivel de entidad.
MinHash DIDO (Doc-in, Doc-out)
Milvus 2.6 añadió el índice « MINHASH_LSH » para la detección de casi duplicados basada en conjuntos, pero las aplicaciones aún tenían que calcular las firmas MinHash antes de escribir datos en Milvus.
Milvus 3.0 añade una función MinHash del lado del servidor. Declare un campo de entrada « VARCHAR » y un campo de salida « BINARY_VECTOR » en el esquema, asigne una función « FunctionType.MINHASH », y Milvus calculará las firmas durante la inserción, la inserción masiva y la búsqueda. Junto con « MINHASH_LSH », esto admite flujos de trabajo de deduplicación para grandes conjuntos de datos, huellas digitales y detección de plagio dentro de Milvus.
Para obtener más información, consulte Función MinHash.
EmbList + DISKANN
La suposición de «una entidad = un vector» ya no se ajusta a la recuperación moderna. Los documentos largos se dividen en muchos fragmentos, los modelos de interacción tardía como ColBERT emiten un vector por token, y las entidades multimodales pueden tener varias vistas.
EmbList almacena una lista de vectores de longitud variable por entidad, con DISKANN como índice en disco. La ruta de disco mantiene bajo control el uso de RAM cuando el corpus excede los límites de memoria. EmbList + DISKANN es la primera variante de la familia más amplia de StructList en esta RC. El resto de la familia, incluyendo el filtrado de StructList y la aceleración multivectorial de Muvera / Lemur, está previsto para la versión oficial 3.0.
Para obtener más información, consulte Búsqueda con listas de incrustación.
Fusionar a la fuerza
Las cargas de trabajo de producción acumulan fragmentación de segmentos con el tiempo, lo que provoca fluctuaciones en la latencia de las consultas y un aumento del almacenamiento.
Milvus 3.0 añade la capacidad de activar la compactación de segmentos de forma explícita durante las ventanas de menor actividad, tanto en modo síncrono como asíncrono.
Para obtener más información, consulte Compactación de fusión forzada.
Almacenamiento V3
Milvus 3.0 introduce Almacenamiento V3, un motor de almacenamiento columnar basado en manifiestos en el que los datos y los metadatos residen en un almacenamiento de objetos compatible con S3. Cada versión del conjunto de datos se captura como una instantánea de manifiesto inmutable, un archivo codificado en Avro que registra qué grupos de columnas, registros delta y estadísticas componen el conjunto de datos.
Los manifiestos son archivos Avro compactos, y los registros delta registran las eliminaciones a nivel de entidad sin reescribir los archivos de datos. Esto mantiene baja la sobrecarga de metadatos a medida que crecen los conjuntos de datos. El manifiesto también desacopla el seguimiento de metadatos de la ruta de consulta, lo que permite que una colección gestione más segmentos sin degradar el rendimiento de las consultas.
Dado que los estados se almacenan en el almacenamiento de objetos, el conjunto de datos es autodescriptivo: cualquier lector con acceso a la ruta de almacenamiento puede descubrirlo e interpretarlo sin necesidad de un catálogo central. Esta propiedad sustenta las integraciones de External Collection, Snapshot y futuros lagos de datos.