Presentación del índice Milvus Ngram: Coincidencia de palabras clave y consultas LIKE más rápidas para cargas de trabajo de agentes

En los sistemas de agentes, la recuperación del contexto es un elemento fundamental en todo el proceso, ya que proporciona la base para el razonamiento, la planificación y la acción posteriores. La búsqueda vectorial ayuda a los agentes a recuperar el contexto semánticamente relevante que capta la intención y el significado en conjuntos de datos grandes y desestructurados. Sin embargo, la relevancia semántica por sí sola no suele ser suficiente. Las cadenas de agentes también se basan en la búsqueda de texto completo para aplicar restricciones de palabras clave exactas, como nombres de productos, llamadas a funciones, códigos de error o términos legalmente significativos. Esta capa de apoyo garantiza que el contexto recuperado no sólo sea relevante, sino que también satisfaga explícitamente requisitos textuales estrictos.

Las cargas de trabajo reales reflejan sistemáticamente esta necesidad:

• Los asistentes de atención al cliente deben encontrar conversaciones en las que se mencione un producto o ingrediente concreto.

• Los copilotos de codificación buscan fragmentos que contengan el nombre exacto de una función, una llamada a la API o una cadena de error.

• Los agentes jurídicos, médicos y académicos filtran documentos en busca de cláusulas o citas que deben aparecer textualmente.

Tradicionalmente, los sistemas han manejado esto con el operador SQL LIKE. Una consulta como name LIKE '%rod%' es sencilla y está ampliamente soportada, pero en condiciones de alta concurrencia y grandes volúmenes de datos, esta simplicidad conlleva importantes costes de rendimiento.

• Sin un índice, una consulta a LIKE escanea todo el almacén de contexto y aplica la concordancia de patrones fila por fila. Con millones de registros, incluso una sola consulta puede tardar segundos, lo que resulta demasiado lento para las interacciones de los agentes en tiempo real.

• Incluso con un índice invertido convencional, los patrones comodín como %rod% siguen siendo difíciles de optimizar porque el motor debe recorrer todo el diccionario y ejecutar la concordancia de patrones en cada entrada. La operación evita el escaneo de filas, pero sigue siendo fundamentalmente lineal, con lo que las mejoras son marginales.

Esto crea una clara brecha en los sistemas de recuperación híbridos: la búsqueda vectorial maneja la relevancia semántica de forma eficiente, pero el filtrado de palabras clave exactas a menudo se convierte en el paso más lento del proceso.

Milvus soporta de forma nativa la búsqueda híbrida vectorial y de texto completo con filtrado de metadatos. Para abordar las limitaciones de la concordancia de palabras clave, Milvus introduce el índice Ngram, que mejora el rendimiento de LIKE dividiendo el texto en pequeñas subcadenas e indexándolas para una búsqueda eficiente. Esto reduce drásticamente la cantidad de datos examinados durante la ejecución de la consulta, proporcionando consultas LIKE de decenas a cientos de veces más rápidas en cargas de trabajo reales.

El resto de este artículo explica cómo funciona el índice Ngram en Milvus y evalúa su rendimiento en escenarios reales.

¿Qué es el índice Ngram?

En las bases de datos, el filtrado de texto se expresa habitualmente mediante SQL, el lenguaje de consulta estándar utilizado para recuperar y gestionar datos. Uno de sus operadores de texto más utilizados es LIKE, que admite la comparación de cadenas basada en patrones.

Las expresiones LIKE pueden agruparse a grandes rasgos en cuatro tipos de patrones comunes, dependiendo de cómo se utilicen los comodines:

• Coincidencia infija (name LIKE '%rod%'): Coincide con registros en los que la subcadena rod aparece en cualquier parte del texto.

• Coincidencia prefija (name LIKE 'rod%'): Coincide con los registros cuyo texto empiece por rod.

• Coincidencia de sufijo (name LIKE '%rod'): Coincide con los registros cuyo texto termina con rod.

• Coincidencia con comodín (name LIKE '%rod%aab%bc_de'): Combina múltiples condiciones de subcadena (%) con comodines de un solo carácter (_) en un único patrón.

Aunque estos patrones difieren en apariencia y expresividad, el Índice Ngram de Milvus los acelera todos utilizando el mismo enfoque subyacente.

Antes de construir el índice, Milvus divide cada valor de texto en subcadenas cortas y superpuestas de longitudes fijas, conocidas como n-gramas. Por ejemplo, cuando n = 3, la palabra "Milvus" se descompone en los 3gramas siguientes: "Mil", "ilv", "lvu" y "vus". Cada n-grama se almacena en un índice invertido que asigna la subcadena al conjunto de ID de documentos en los que aparece. En el momento de la consulta, las condiciones de LIKE se traducen en combinaciones de búsquedas de n-gramas, lo que permite a Milvus filtrar rápidamente la mayoría de los registros no coincidentes y evaluar el patrón con un conjunto de candidatos mucho más pequeño. Esto es lo que convierte los costosos escaneos de cadenas en eficientes consultas basadas en índices.

Dos parámetros controlan cómo se construye el índice Ngram: min_gram y max_gram. Juntos, definen el rango de longitudes de subcadenas que Milvus genera e indexa.

• min_gram: La longitud de subcadena más corta a indexar. En la práctica, esto también establece la longitud mínima de la subcadena de consulta que puede beneficiarse del Índice Ngram.

• max_gram: La longitud de subcadena más larga a indexar. En el momento de la consulta, determina además el tamaño máximo de ventana utilizado al dividir las cadenas de consulta más largas en n-gramas.

Al indexar todas las subcadenas contiguas cuya longitud esté comprendida entre min_gram y max_gram, Milvus establece una base coherente y eficaz para acelerar todos los tipos de patrones compatibles con LIKE.

¿Cómo funciona el índice Ngram?

Milvus implementa el Índice Ngram en un proceso de dos fases:

• Construir el índice: Generar n-gramas para cada documento y construir un índice invertido durante la ingesta de datos.

• Acelerar las consultas: Utilice el índice para limitar la búsqueda a un pequeño conjunto de candidatos y, a continuación, verifique las coincidencias exactas de LIKE en esos candidatos.

Un ejemplo concreto facilita la comprensión de este proceso.

Fase 1: Creación del índice

Descomponga el texto en n-gramas:

Supongamos que indexamos el texto "Apple" con la siguiente configuración:

• min_gram = 2

• max_gram = 3

Con esta configuración, Milvus genera todas las subcadenas contiguas de longitud 2 y 3:

• 2-gramas: Ap, pp, pl, le

• 3-gramas: App, ppl, ple

Construir un índice invertido:

Consideremos ahora un pequeño conjunto de datos de cinco registros:

• Documento 0: Apple

• Documento 1: Pineapple

• Documento 2: Maple

• Documento3: Apply

• Documento 4: Snapple

Durante la ingesta, Milvus genera n-gramas para cada registro y los inserta en un índice invertido. En este índice

• Las claves son n-gramas (subcadenas)

• Los valores son listas de ID de documentos en los que aparece el n-grama.

"Ap"  -> [0, 3]
"App" -> [0, 3]
"Ma"  -> [2]
"Map" -> [2]
"Pi"  -> [1]
"Pin" -> [1]
"Sn"  -> [4]
"Sna" -> [4]
"ap"  -> [1, 2, 4]
"apl" -> [2]
"app" -> [1, 4]
"ea"  -> [1]
"eap" -> [1]
"in"  -> [1]
"ine" -> [1]
"le"  -> [0, 1, 2, 4]
"ly"  -> [3]
"na"  -> [4]
"nap" -> [4]
"ne"  -> [1]
"nea" -> [1]
"pl"  -> [0, 1, 2, 3, 4]
"ple" -> [0, 1, 2, 4]
"ply" -> [3]
"pp"  -> [0, 1, 3, 4]
"ppl" -> [0, 1, 3, 4]

Ahora el índice está totalmente construido.

Fase 2: Acelerar las consultas

Cuando se ejecuta un filtro LIKE, Milvus utiliza el índice de n-gramas para acelerar la evaluación de las consultas mediante los siguientes pasos:

1. Extraer el término de la consulta: Las subcadenas contiguas sin comodines se extraen de la expresión LIKE (por ejemplo, '%apple%' se convierte en apple).

2. 2. Descomponer el término de la consulta: El término de la consulta se descompone en n-gramas en función de su longitud (L) y de los configurados min_gram y max_gram.

3. 3.Buscar cada gramo e intersecar: Milvus busca los n-gramas de la consulta en el índice invertido e interseca sus listas de ID de documentos para producir un pequeño conjunto de candidatos.

4. 4. Verificar y devolver resultados: La condición original de LIKE se aplica sólo a este conjunto de candidatos para determinar el resultado final.

En la práctica, la forma de dividir una consulta en n-gramas depende de la forma del propio patrón. Para ver cómo funciona, nos centraremos en dos casos comunes: las coincidencias infijos y las coincidencias comodín. Las coincidencias prefijo y sufijo se comportan igual que las infijos, por lo que no las trataremos por separado.

Coincidencia infija

Para una coincidencia infija, la ejecución depende de la longitud de la subcadena literal (L) relativa a min_gram y max_gram.

1. min_gram ≤ L ≤ max_gram (por ejemplo, strField LIKE '%ppl%')

La subcadena literal ppl cae completamente dentro del rango de n-gramas configurado. Milvus busca directamente el n-gram "ppl" en el índice invertido, produciendo los IDs de documentos candidatos [0, 1, 3, 4].

Dado que el propio literal es un n-grama indexado, todos los candidatos satisfacen ya la condición infija. El último paso de verificación no elimina ningún registro, y el resultado sigue siendo [0, 1, 3, 4].

2. L > max_gram (por ejemplo, strField LIKE '%pple%')

La subcadena literal pple es más larga que max_gram, por lo que se descompone en n-gramas superpuestos utilizando un tamaño de ventana de max_gram. Con max_gram = 3, se obtienen los n-gramas "ppl" y "ple".

Milvus busca cada n-grama en el índice invertido:

• "ppl" → [0, 1, 3, 4]

• "ple" → [0, 1, 2, 4]

Al intersecar estas listas se obtiene el conjunto de candidatos [0, 1, 4]. A continuación, se aplica el filtro original LIKE '%pple%' a estos candidatos. Los tres satisfacen la condición, por lo que el resultado final sigue siendo [0, 1, 4].

3. L < min_gram (por ejemplo, strField LIKE '%pp%')

La subcadena literal es más corta que min_gram y, por tanto, no puede descomponerse en n-gramas indexados. En este caso, no se puede utilizar el índice Ngram y Milvus vuelve a la ruta de ejecución predeterminada, evaluando la condición LIKE mediante un escaneo completo con coincidencia de patrones.

Coincidencia de comodines (por ejemplo, strField LIKE '%Ap%pple%')

Este patrón contiene múltiples comodines, por lo que Milvus lo divide primero en literales contiguos: "Ap" y "pple".

A continuación, Milvus procesa cada literal de forma independiente:

• "Ap" tiene una longitud de 2 y entra dentro del rango de n-gramas.

• "pple" es más largo que max_gram y se descompone en "ppl" y "ple".

Esto reduce la consulta a los siguientes n-gramas:

• "Ap" → [0, 3]

• "ppl" → [0, 1, 3, 4]

• "ple" → [0, 1, 2, 4]

La intersección de estas listas produce un único candidato: [0].

Por último, se aplica el filtro original LIKE '%Ap%pple%' al documento 0 ("Apple"). Como no satisface el patrón completo, el conjunto de resultados final está vacío.

Limitaciones y desventajas del índice de ngramas

Aunque el índice de ngramas puede mejorar significativamente el rendimiento de las consultas en LIKE, introduce ventajas y desventajas que deben tenerse en cuenta en las implantaciones en el mundo real.

• Mayor tamaño del índice

El principal coste del índice Ngram es una mayor sobrecarga de almacenamiento. Dado que el índice almacena todas las subcadenas contiguas cuya longitud esté comprendida entre min_gram y max_gram, el número de n-gramas generados crece rápidamente a medida que se amplía este rango. Cada longitud de n-grama adicional añade efectivamente otro conjunto completo de subcadenas contiguas para cada valor de texto, lo que aumenta tanto el número de claves de índice como sus listas de contabilización. En la práctica, ampliar el rango en un solo carácter puede duplicar aproximadamente el tamaño del índice en comparación con un índice invertido estándar.

• No es eficaz para todas las cargas de trabajo

El índice Ngram no acelera todas las cargas de trabajo. Si los patrones de consulta son muy irregulares, contienen literales muy cortos o no consiguen reducir el conjunto de datos a un pequeño conjunto de candidatos en la fase de filtrado, las ventajas de rendimiento pueden ser limitadas. En tales casos, la ejecución de la consulta puede seguir aproximándose al coste de un escaneo completo, aunque el índice esté presente.

Evaluación del rendimiento del índice Ngram en consultas LIKE

El objetivo de esta prueba es evaluar la eficacia del índice Ngram para acelerar las consultas a LIKE en la práctica.

Metodología de la prueba

Para poner su rendimiento en contexto, lo comparamos con dos modos de ejecución de referencia:

• Maestro: Ejecución de fuerza bruta sin ningún índice.

• Maestro-invertido: Ejecución utilizando un índice invertido convencional.

Diseñamos dos escenarios de prueba para cubrir diferentes características de los datos:

• Conjunto de datos de texto Wiki: 100.000 filas, con cada campo de texto truncado a 1 KB.

• Conjunto de datos de una sola palabra: 1.000.000 de filas, en las que cada fila contiene una sola palabra.

En ambos casos, se aplican los siguientes parámetros de forma coherente:

• Las consultas utilizan el patrón de coincidencia infijo (%xxx%)

• El índice Ngram se configura con min_gram = 2 y max_gram = 4

• Para aislar el coste de ejecución de la consulta y evitar la sobrecarga de materialización de resultados, todas las consultas devuelven count(*) en lugar de conjuntos de resultados completos.

Resultados

Prueba para wiki, cada línea es un texto wiki con una longitud de contenido truncada por 1000, 100K filas

	Literal	Tiempo (ms)	Aceleración	Recuento
Maestro	estadio	207.8		335
Maestro-invertido		2095		335
Ngrama		1.09	190 / 1922	335
Maestro	escuela secundaria	204.8		340
Maestro-invertido		2000		340
Ngrama		1.26	162.5 / 1587	340
Maestro	es una escuela secundaria mixta patrocinada por	223.9		1
Master-invertido		2100		1
Ngrama		1.69	132.5 / 1242.6	1

Prueba de palabras sueltas, 1M de filas

	Literal	Tiempo(ms)	Aceleración	Recuento
Maestro	na	128.6		40430
Maestro-invertido		66.5		40430
Ngrama		1.38	93.2 / 48.2	40430
Maestro	nat	122		5200
Master-invertido		65.1		5200
Ngrama		1.27	96 / 51.3	5200
Maestro	nati	118.8		1630
Master-invertido		66.9		1630
Ngrama		1.21	98.2 / 55.3	1630
Maestro	natio	118.4		1100
Master-invertido		65.1		1100
Ngrama		1.33	89 / 48.9	1100
Maestro	nación	118		1100
Maestro-invertido		63.3		1100
Ngrama		1.4	84.3 / 45.2	1100

Nota: Estos resultados se basan en pruebas comparativas realizadas en mayo. Desde entonces, la rama Master ha experimentado optimizaciones adicionales de rendimiento, por lo que se espera que la diferencia de rendimiento observada aquí sea menor en las versiones actuales.

Los resultados de las pruebas ponen de manifiesto un patrón claro: el índice Ngram acelera significativamente las consultas LIKE en todos los casos, y la rapidez con la que se ejecutan las consultas depende en gran medida de la estructura y la longitud de los datos de texto subyacentes.

• En el caso de los campos de texto largos, como los documentos tipo Wiki truncados a 1.000 bytes, el aumento del rendimiento es especialmente pronunciado. En comparación con la ejecución de fuerza bruta sin índice, el índice Ngram consigue aumentos de velocidad de aproximadamente 100-200×. Si se compara con un índice invertido convencional, la mejora es aún más espectacular, llegando a 1.200-1.900×. Esto se debe a que las consultas LIKE en textos largos son especialmente costosas para los métodos de indexación tradicionales, mientras que las búsquedas de n-gramas pueden reducir rápidamente el espacio de búsqueda a un conjunto muy pequeño de candidatos.

• En los conjuntos de datos compuestos por entradas de una sola palabra, las ganancias son menores, pero siguen siendo sustanciales. En este caso, el índice de n-gramas es entre 80 y 100 veces más rápido que la ejecución por fuerza bruta y entre 45 y 55 veces más rápido que un índice invertido convencional. A pesar de que el escaneo de textos más cortos es intrínsecamente más barato, el enfoque basado en n-gramas evita comparaciones innecesarias y reduce sistemáticamente el coste de la consulta.

Conclusión

El índice Ngram acelera las consultas en LIKE dividiendo el texto en n-gramas de longitud fija e indexándolos mediante una estructura invertida. Este diseño convierte las costosas comparaciones de subcadenas en eficientes búsquedas de n-gramas seguidas de una verificación mínima. De este modo, se evitan las búsquedas de texto completo y se conserva la semántica exacta de LIKE.

En la práctica, este planteamiento es eficaz en una amplia gama de cargas de trabajo, con resultados especialmente buenos en las coincidencias difusas de campos de texto largos. El índice Ngram es, por tanto, muy adecuado para escenarios en tiempo real como la búsqueda de códigos, los agentes de atención al cliente, la recuperación de documentos jurídicos y médicos, las bases de conocimiento empresarial y la búsqueda académica, donde sigue siendo esencial la coincidencia precisa de palabras clave.

Al mismo tiempo, el índice Ngram se beneficia de una configuración cuidadosa. La elección de los valores min_gram y max_gram es fundamental para equilibrar el tamaño del índice y el rendimiento de la consulta. Cuando se ajusta para reflejar patrones de consulta reales, el índice de ngramas ofrece una solución práctica y escalable para consultas de alto rendimiento en LIKE en sistemas de producción.

Para obtener más información sobre el índice Ngram, consulte la documentación siguiente:

• Índice Ngram | Documentación de Milvus

¿Tiene preguntas o desea profundizar en alguna característica de la última versión de Milvus? Únase a nuestro canal Discord o presente incidencias en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.

Más información sobre las características de Milvus 2.6

• Presentación de Milvus 2.6: Búsqueda vectorial asequible a escala de miles de millones

• Presentación de la función de incrustación: Cómo Milvus 2.6 agiliza la vectorización y la búsqueda semántica

• JSON Shredding en Milvus: Filtrado JSON 88,9 veces más rápido con flexibilidad

• Desbloqueo de la verdadera recuperación a nivel de entidad: Nuevas funciones Array-of-Structs y MAX_SIM en Milvus

• Unificación del filtrado geoespacial y la búsqueda vectorial con campos geométricos y RTREE en Milvus 2.6

• Introducción de AISAQ en Milvus: la búsqueda vectorial a escala de miles de millones se ha vuelto 3.200 veces más barata en memoria

• Optimización de NVIDIA CAGRA en Milvus: un enfoque híbrido GPU-CPU para una indexación más rápida y consultas más baratas

• MinHash LSH en Milvus: el arma secreta para combatir los duplicados en los datos de entrenamiento LLM

• Llevar la compresión vectorial al extremo: cómo Milvus sirve 3 veces más consultas con RaBitQ

• Los puntos de referencia mienten: las bases de datos vectoriales merecen una prueba real

• Sustituimos Kafka/Pulsar por un Woodpecker para Milvus