Guía para desarrolladores sobre la exploración de las funciones de Milvus 2.6 en Zilliz Cloud
Milvus comenzó como una base de datos vectorial de código abierto de alto rendimiento creada para escalar, con capacidades de búsqueda ANN vectorial de última generación. A medida que creció la comunidad de desarrolladores, las solicitudes de funciones se ampliaron para incluir búsqueda de texto completo, boosting y compatibilidad con tipos de datos semiestructurados (JSON, struct, etc.). Estas solicitudes reflejan una tendencia más amplia hacia la convergencia de las capacidades de las bases de datos, impulsada por la necesidad de funciones más avanzadas (además de la búsqueda por similitud) que ayuden a acelerar el desarrollo de aplicaciones de IA.
La convergencia no aparece solo en las solicitudes de funciones — ahora aparece en la propia base de datos. Con Milvus 2.6, muchas capacidades que los desarrolladores antes tenían que ensamblar fuera de la base de datos, como la clasificación basada en decaimiento, el boosting a nivel de campo y el filtrado híbrido entre datos estructurados y no estructurados, ahora son primitivas de primera clase.
En otras palabras, Milvus 2.6 marca un cambio de "búsqueda vectorial + código de unión" a un motor de recuperación más avanzado, y ahora está Generalmente Disponible (GA) en Zilliz Cloud (un servicio gestionado de Milvus).
En este artículo, repasaré algunas de las funciones interesantes de Milvus v2.6, cuándo usarlas y cómo usarlas. ¡Empecemos!
La función de embeddings (también conocida como Data In, Data Out)
¿Alguna vez te has preguntado si la base de datos puede encargarse de la generación de embeddings por ti? Con Embedding Functions (también conocidas como "Data in, data out"), Milvus puede transformar texto sin procesar en vectores llamando a servicios externos de embeddings de terceros como OpenAI, VoyageAI y Cohere.
Embedding Functions se lanzó por primera vez en Milvus v2.6.0, y la he mostrado en la demo kafka-milvus-no-code-pipelines. Ahora, Embedding Functions están disponibles en Zilliz Cloud, el servicio totalmente gestionado de la base de datos vectorial Milvus.
¿Cómo funciona la función de embeddings?
Digamos que insertas "The quick brown fox jumps over the lazy dog" en Milvus con una función de embeddings configurada. Milvus lo intercepta en la capa de proxy, lo enruta a través de una canalización de embeddings específica del proveedor y almacena el vector producido por tu modelo. La misma transformación ocurre a la inversa durante la búsqueda. El texto de tu consulta se convierte en un vector antes de llegar al índice.
Esta función es especialmente útil para equipos que buscan delegar en la base de datos la responsabilidad de gestionar flujos de trabajo de embeddings. Al permitir que la base de datos genere embeddings de forma transparente en el momento de la ingesta (a través de un proveedor de modelos de terceros), Zilliz Cloud se encarga de la integración de API, el procesamiento por lotes, los reintentos, los límites de tasa y la gestión de fallos.
Para empezar con Embedding Functions en Zilliz Cloud, necesitas:
- Configurar Model Provider Integration para el proveedor de servicios de embeddings que elijas
- Crear una colección con Embedding Function definida
- Insertar tus datos.
Deberías poder ver la función de embeddings en la consola de Zilliz Cloud en la página del esquema de tu colección si la configuraste correctamente.
Ahora solo tienes que insertar el texto sin procesar, y los embeddings se generarán automáticamente y se almacenarán en tu campo de vector denso especificado. Con las funciones de embeddings definidas, ya no tienes que generar embeddings, ni siquiera para tu consulta de búsqueda.
Un posible problema al que podrías enfrentarte será el límite de tamaño de lote que Milvus impone al usar la función de embeddings.
2026-01-21 14:03:12,902 [ERROR][handler]: RPC error: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>
Mejores prácticas y consejos
- Manténgase dentro del límite de tamaño de lote (mostrado en el mensaje de error). Este es un mecanismo de seguridad para evitar alcanzar el límite de tokens del proveedor del modelo por llamada a la API. Por ejemplo, OpenAI tiene una limitación de un máximo de 300,000 tokens por llamada a la API.
- Para textos largos o casos de uso con documentos grandes, debe dividir en fragmentos antes de insertar. Por ejemplo, OpenAI tiene un límite de 8192 tokens por texto de entrada para todos los modelos de embeddings.
- Aunque proveedores como VoyageAI y Cohere truncan automáticamente los textos largos de forma predeterminada, depender de esto puede provocar la pérdida silenciosa de contenido al final de su documento.
Resaltado léxico
El resaltado léxico es útil para mostrar a los usuarios por qué un resultado coincidió con su consulta al marcar visualmente los términos o frases exactos que activaron la coincidencia. Esto mejora la transparencia, la interpretabilidad y la confianza del usuario en los resultados de búsqueda.
Estos son algunos escenarios clave:
Visualización de resultados de búsqueda en interfaces de usuario. Al crear interfaces de búsqueda, el resaltado ayuda a los usuarios a entender rápidamente la relevancia de un resultado sin abrir el documento completo. Reduce la carga cognitiva y mejora la tasa de clics al hacer explícita la coincidencia.
Búsqueda de documentos / contenido. En documentos grandes (por ejemplo, bases de conocimiento, PDF, políticas), el resaltado léxico permite a los usuarios localizar de inmediato las palabras clave coincidentes dentro del contexto circundante, acelerando el descubrimiento de información.
Análisis de registros / eventos. El resaltado en registros operativos o datos de eventos facilita detectar patrones coincidentes, códigos de error o palabras clave dentro de texto denso y no estructurado, especialmente durante la resolución de problemas o la respuesta a incidentes.
Depuración de RAG (Retrieval-Augmented Generation). En las canalizaciones de RAG, el resaltado léxico ayuda a los profesionales a inspeccionar qué partes de los fragmentos recuperados coincidieron con la consulta original. Esto es útil para:
- Verificar la corrección de la recuperación
- Diagnosticar falsos positivos o coincidencias débiles
- Entender por qué se seleccionó cierto contexto para la generación
Para implementar el resaltado léxico del lado del servidor con Zilliz Cloud, primero instancia un LexicalHighlighter (con el texto de consulta a resaltar y las etiquetas circundantes para indicar cómo se ve el texto resaltado) y proporciónelo como parámetro a su solicitud de búsqueda de texto completo.
Luego, Milvus realizará la búsqueda y ejecutará la lógica léxica para encontrar coincidencias exactas y devolver información posicional sobre qué subcadenas resaltar.
Mejores prácticas y consejos
- LexicalHighlighter solo funciona con la búsqueda de texto completo BM25. No funcionará para la búsqueda vectorial densa.
- Puede definir
pre_tagsypost_tagspara envolver los términos coincidentes con etiquetas HTML (por ejemplo, clase CSS personalizada, negrita, cursiva, etc.) que se rendericen directamente en una página web.
Índice N-gram
Los índices N-gram son potentes técnicas de indexación de motores de búsqueda que descomponen cadenas en secuencias de caracteres más pequeñas y solapadas (por ejemplo, "coffee" en 3-gramas -> "cof", "off", "ffe", "fee") para permitir coincidencias parciales, flexibles y de estilo comodín.
Estos son algunos escenarios en los que encontrará útiles los índices n-gram:
- Mejorar el rendimiento de las búsquedas de subcadenas (por ejemplo,
LIKE %deep%) - Búsqueda mientras se escribe / autocompletado
- Búsqueda difusa
- Búsqueda de nombres de dominio e identificadores (por ejemplo,
example.com,facebook.com)
¿Cómo funciona?
Los documentos que contienen un n-grama especificado se pueden localizar de manera eficiente mediante un índice, a menudo denominado índice invertido, que asigna cada n-grama a una lista de identificadores de los documentos que contienen ese n-grama. La lista se mantiene ordenada para permitir tanto una compresión eficiente como una ejecución eficiente de consultas. En el caso de Milvus, el índice ngram se construye sobre Tantivy, que a su vez utiliza técnicas de compresión como codificación delta, bitpacking y skip lists para comprimir y reducir el tamaño de la lista invertida, haciendo que el índice sea ligero.
En lugar de un escaneo completo de tu campo de texto, Milvus primero extrae el predicado, por ejemplo deep, lo descompone en n-gramas según los tamaños de grama configurados, realiza búsquedas en el índice invertido e intersecta resultados para identificar candidatos que contienen todos los gramas, y luego verifica coincidencias exactas contra el patrón LIKE original.
Milvus te permite especificar min_gram y max_gram, que representan respectivamente la longitud mínima y máxima de los n-gramas que se generarán. Para más detalles sobre cómo crear y usar el índice ngram, consulta el documento de NGRAM Index.
Aquí tienes una breve demostración del autocompletado implementado usando la función de índice ngram de Milvus.
Mejores prácticas y consejos
- Haz benchmarks con consultas representativas: Prueba con patrones de consulta realistas antes de desplegar en producción para validar que la configuración de
min_gramymax_gramse alinea con el comportamiento real del usuario. - Combina estratégicamente con la búsqueda vectorial: Usa el filtrado acelerado por NGRAM como prefiltro para reducir el conjunto de candidatos antes del cálculo de similitud vectorial, mejorando la latencia general de la consulta.
- Evita la sobreindexación: No todos los campos VARCHAR se benefician de un índice NGRAM. Prioriza los campos usados frecuentemente en consultas
LIKEcon patrones comodín. - Ten en cuenta que el índice n-grama es sensible a mayúsculas y minúsculas. Esto significa que los tokens se indexan exactamente como aparecen en el texto original, preservando las distinciones entre mayúsculas y minúsculas. Las consultas deben coincidir con el uso exacto de mayúsculas y minúsculas en el contenido indexado.
Decay Ranker
Imagina que estás construyendo un motor de búsqueda semántica para artículos de investigación, donde favoreces los artículos publicados en los últimos 10 años sobre aquellos publicados hace más de 10 años.
Sin el decay ranker de Milvus, probablemente tendrías que reordenar los resultados de búsqueda fuera de la base de datos vectorial en función del campo del año de publicación. Esto requerirá procesamiento en el servidor de la aplicación / del lado del cliente, lo que añadirá tanto complejidad como latencia, y podría afectar negativamente la experiencia del usuario.
En el corazón del decay ranker de Milvus está la Decay Function. Las Decay Functions ajustan las puntuaciones de relevancia en función de campos numéricos (como marcas de tiempo). La puntuación final se calcula como:
final_score = normalized_similarity_score x decay_score
Actualmente, hay tres funciones de decaimiento diferentes, a saber: Linear, Exponential y Gaussian. Cada función de decaimiento es útil para distintos escenarios. Por ejemplo, Linear Function debe usarse cuando necesitas excluir entidades más allá de cierto punto (p. ej., años, distancia, etc.). Exponential Function puede usarse cuando quieres que los elementos más recientes dominen los resultados, pero permitiendo que los resultados más antiguos sigan siendo detectables. Gaussian Function es útil para búsquedas basadas en ubicación, es decir, los elementos más cercanos a la ubicación actual se clasificarán más arriba.
Las funciones de decaimiento son altamente personalizables, y puedes controlar su forma usando varios parámetros al inicializarlas:
- origin: Punto de referencia (p. ej., marca de tiempo actual)
- offset: Crea una "zona sin decaimiento" donde los elementos mantienen puntuaciones completas (decay = 1.0). Útil para garantizar que los elementos muy recientes o muy cercanos no sean penalizados en absoluto.
- scale: Valores más grandes producen una disminución gradual de la relevancia; valores más pequeños producen una disminución más pronunciada.
- decay: Controla la pendiente de la curva. Valores más bajos (p. ej., 0.3) crean una disminución más pronunciada; valores más altos (p. ej., 0.7) crean una disminución más gradual. El valor predeterminado es 0.5.
Aquí hay un ejemplo de cómo determinar cómo configurar los parámetros de la función de decaimiento:
- Para usar el año actual como origen:
origin=2026 - Los artículos de investigación de 2021 a 2026 son igualmente relevantes sin decaimiento aplicado:
offset=6 - El multiplicador de puntuación a la distancia de escala:
decay=0.5 - Los artículos de 2010 deberían tener una puntuación de decaimiento (especificada previamente) de 0.5:
scale=16(ya que 2026 - 2010 = 16)
Mejores prácticas y consejos
- Realiza pruebas A/B de las configuraciones de decaimiento. Pequeños cambios en los parámetros
scaleydecaypueden afectar significativamente la experiencia del usuario. - Asegúrate de que todos los parámetros basados en tiempo (
origin,scale,offset) usen la misma unidad que los datos de tu colección. - FunctionScore acepta solo una única DecayFunction por consulta. Actualmente no se admite encadenar o componer múltiples DecayFunctions.
- Cada ranker de decaimiento admite solo un campo numérico. No puedes combinar múltiples factores de decaimiento en un solo ranker.
- Evita el decaimiento en campos dispersos o sesgados. Si tu campo de decaimiento tiene muchos valores nulos, valores atípicos o distribuciones muy sesgadas, la clasificación por decaimiento puede producir resultados poco intuitivos.
Boosting
Boosting es un mecanismo práctico para incorporar señales de dominio en la clasificación de búsqueda vectorial. Aunque la búsqueda semántica captura de qué trata tu consulta, a menudo ignora qué importa más en un dominio determinado. Boosting te permite reclasificar resultados usando un campo de metadatos arbitrario, codificando efectivamente la intuición de negocio o de dominio en la capa de recuperación.
Por ejemplo, en un flujo de trabajo de búsqueda de artículos de investigación, dos artículos pueden ser relevantes para "deep learning", pero no igualmente importantes. Un artículo muy citado puede merecer aparecer por encima de uno menos citado, incluso si su puntuación de similitud es ligeramente menor. Con boosting, un artículo con una puntuación de similitud de 0.79 pero 1,200 citas puede clasificarse por encima de un artículo con una puntuación de 0.81 y solo 10 citas.
Lo anterior puede implementarse haciendo boosting de los artículos según el recuento de citas. Una implementación simple es la siguiente:
Pero, ¿qué pasa si queremos hacer boosting de artículos de investigación con recuentos de citas entre 100 y 1000 e incluso incluir una función de decaimiento para favorecer artículos más recientes? Resulta que podemos encadenar una función de decaimiento con múltiples boost rankers en una sola solicitud de búsqueda usando la clase FunctionScore.
Mejores prácticas y consejos
- FunctionScore actualmente solo es compatible con la búsqueda de vectores densos. La búsqueda híbrida no admite FunctionScore; usa un único ranker en su lugar.
- Para boosting basado en campos de valores continuos, considera colocar los valores en buckets discretos y asignar pesos de boost distintos a cada bucket.
Conclusión
Milvus 2.6 representa un avance significativo en lo que una base de datos vectorial puede hacer de forma nativa. Las características y capacidades anteriores que he comentado no son solo elementos deseables; eliminan el código de integración que los desarrolladores antes tenían que crear y mantener fuera de la base de datos.
En lugar de unir pipelines externos de embedding, lógica personalizada de reranking y soluciones alternativas para búsqueda de subcadenas, ahora puedes expresar todo esto directamente en tus consultas de Milvus. El resultado es un código de aplicación más limpio, menor latencia y menos componentes móviles que depurar cuando algo sale mal.
Si has estado tratando a Milvus como "solo" un almacén vectorial, quizá sea hora de volver a evaluar lo que es posible. Todas estas funciones ya están en disponibilidad general en Zilliz Cloud, así que puedes empezar a experimentar hoy mismo.
Recursos
- Doc: Integración con proveedores de modelos
- Doc: Funciones de embedding basadas en modelos
- Blog: Presentamos la función de embedding: cómo Milvus 2.6 simplifica la vectorización y la búsqueda semántica
- Doc: Resaltador léxico en Zilliz Cloud
- Blog: Cómo creamos un modelo de resaltado semántico para la poda de contexto en RAG y el ahorro de tokens
- Doc: Índice NGRAM
- Doc: Descripción general de Decay Ranker
- Doc: Boost Ranker
Sigue leyendo
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Data Deduplication at Trillion Scale: How to Solve the Biggest Bottleneck of LLM Training
Explore how MinHash LSH and Milvus handle data deduplication at the trillion-scale level, solving key bottlenecks in LLM training for improved AI model performance.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.