Cómo MATCH y TO_TEXT habilitan la búsqueda de texto completo en cualquier expresión ES|QL

Empecemos con una búsqueda que era imposible en Elasticsearch 9.4, que usa el comando EVAL:

En este ejemplo, no tiene una configuración de mapeo ni de analizador. Tampoco está asociado con ningún índice invertido. Solo existe durante la vida útil de esta búsqueda, pero ahora puedes realizar una búsqueda de todos modos. Dos adiciones hacen que esto funcione.

Primero, MATCH ahora acepta cualquier expresión como su primer argumento, no solo un campo mapeado. Eso incluye las columnas producidas por EVAL y los resultados de funciones utilizados en línea. También incluye campos no mapeados cargados directamente desde el documento original. Además, todos los tipos de datos normalmente aceptados por MATCH son compatibles en este nuevo caso de uso.

La segunda parte de esto es la nueva función TO_TEXT, que es la primera función de conversión ES|QL que produce la salida de tipo texto. Hasta ahora, las columnas de texto solo podían provenir de campos indexados y mapeados, y todos los textos producidos por las expresiones ES|QL eran valores de palabras clave en lugar de texto. La distinción es importante porque MATCH trata ambos de forma diferente: se analizan los valores de texto, mientras que los valores de palabras clave se comparan exactamente, reflejando cómo una búsqueda MATCH en un campo de palabra clave indexado se reescribe en una búsqueda de término. TO_TEXT(x) es la forma de indicarle a ES|QL: trata esta cadena como texto completo.

Esto se envía como una vista previa técnica en Elasticsearch 9.5 y, como tal, tiene algunas limitaciones:

• Actualmente solo está filtrando. Una coincidencia en una expresión aún no contribuye a la puntuación de relevancia; solo las coincidencias en los campos indexados afectan la puntuación.

• Las opciones de búsqueda, como la imprecisión y otras, aún no son compatibles al hacer coincidir una expresión.

• El texto en tiempo de ejecución se analiza con el analizador estándar. Esto aún no es configurable.

Se está trabajando para solucionar estas limitaciones.

¿Por qué usar la búsqueda de texto completo en lugar de LIKE o RLIKE en ES|QL?

ES|QL ya tenía dos formas de búsqueda de textos sin índice: LIKE (patrones comodines) y RLIKE (expresiones regulares). Ambos funcionan en cualquier expresión de texto, así que es justo preguntar qué agrega MATCH. La respuesta es el análisis, una forma más avanzada de búsqueda que emplea técnicas como el stemming y los sinónimos. También usa la eliminación de palabras vacías.

LIKE es una simple coincidencia de subcadenas, sin ninguna comprensión de las palabras que componen un texto. Digamos, por ejemplo, que estás buscando mensajes de log sobre un oso:

Esto no detecta “Oso avistado cerca del gallinero” por la mayúscula, mientras que sí coincide con “Un resultado fabuloso para la competencia”, que no tiene nada que ver con un oso. Falla en ambas direcciones: hay falsos negativos por la mayúscula y falsos positivos por subcadenas escondidas dentro de otras palabras.

Las expresiones regulares pueden solucionar el problema de las mayúsculas y minúsculas, pero el problema de los límites de las palabras se complica rápidamente. Algo como:

Y ni siquiera así queda bien. No detecta un oso al final de una oración seguido de ¡ o ¿, y no dice nada sobre tabulaciones, comillas o paréntesis. Cada arreglo hace que el patrón sea más largo, y la próxima persona que lea la búsqueda tiene que hacer ingeniería inversa para entender qué es lo que realmente hace.

MATCH hace que el problema desaparezca, porque ejecuta tanto la búsqueda como el valor a través de un analizador, que tokeniza el texto en términos en minúsculas y luego compara término con término:

Esta búsqueda coincidirá con valores como “El rápido oso pardo” y “OSO avistado cerca del gallinero”, pero no con “Un resultado hermoso para la competencia” ni “Protocolo OSOBUCO habilitado”, sin importar la puntuación que rodee a las palabras. Por supuesto, todo esto también funciona con búsquedas de varios términos, como MATCH(TO_TEXT(message), “oso pardo”), tal como uno esperaría.

Se está trabajando para habilitar el uso de los 36 analizadores de lenguaje, con soporte para lenguajes naturales en datos que nunca fueron indexados ni mapeados.

Casos de uso de búsqueda de texto completo para datos no indexados y no mapeados

Los ejemplos anteriores buscaron valores calculados a partir de campos mapeados. Los casos de uso más interesantes para ES|QL MATCH en expresiones involucran datos que nunca se pudieron buscar en absoluto. Vamos a repasar algunos.

Cómo buscar campos sin mapeo en ES|QL sin agregar un mapeo

A veces dejas deliberadamente un campo fuera de tus mapeos, como un rastreo de pila verboso o una carga útil de solicitud sin procesar. Incluso podrías omitir un bloque de depurar. Indexar uno de estos campos costaría espacio en disco y memoria heap en cada documento, y no valdría la pena para un campo que quizás consultes una vez al trimestre.

Esa decisión siempre ha sido definitiva, porque los campos no mapeados eran invisibles para las búsquedas por completo. En Elasticsearch 9.5, puedes usar SET unmapped_fields="load" para hacer que ES|QL cargue campos no mapeados directamente desde el documento de origen como palabras clave. Sigue envolviéndolo en TO_TEXT, y ahora puedes ejecutar una búsqueda de texto completo en él:

Aquí, stack_trace nunca se mapeó. Cada valor se obtiene de los documentos originales y se analiza sobre la marcha. Están emparejados fila por fila. Eso es un trabajo real, y nunca será tan rápido como una búsqueda de índice invertido. Pero ahora, ese campo que no indexaste ya no es inbuscable. Puedes mantener el mapeo pequeño para el caso cotidiano y seguir respondiendo a la pregunta de una vez por trimestre cuando importa.

Búsqueda de texto completo en un campo de palabras clave sin reindexar

Los campos de palabras clave pueden hacer mucho. Dan coincidencias exactas, agregaciones rápidas y clasificación, razón por la cual tantos campos terminan mapeados de esa manera. Pero los mapeos se deciden cuando llegan los datos, y es fácil terminar en una situación en la que quieres hacer algo diferente con tus datos de lo que originalmente pretendías. Quizás product_name se mapeó como palabra clave porque los paneles de control agregan datos en función de ella, y luego de recibir datos de productos de un año, alguien quiere poder buscar dentro de los valores de product_name.

La respuesta antigua era cambiar el mapeo a texto (o agregar campos múltiples) y reindexar todo. Esto puede llevar mucho tiempo y ser costoso, y en muchos casos, los usuarios simplemente no querrán molestarse con ello. La nueva respuesta es una llamada a una función:

TO_TEXT convierte los valores de las palabras clave en texto sobre la marcha, así que MATCH los analiza en vez de compararlos exactamente. Esto te permite consultar un campo de palabra clave sin crear un mapeo o reindexar el documento de origen. Si la búsqueda se convierte en una búsqueda cotidiana, indexar el campo como texto sigue siendo el movimiento correcto a largo plazo, pero TO_TEXT te da una respuesta hoy, sin ningún trabajo adicional.

Buscar el mismo campo en los índices con diferentes mapeos

ES|QL puede abarcar muchos índices, y el mismo campo no tiene por qué verse siempre igual en todos. Cuando el mismo campo tiene diferentes tipos en distintos índices, ES|QL lo trata como un tipo de unión, y una función de conversión resuelve el conflicto. Consideremos un ejemplo en el que el campo message tiene tipo texto en la plantilla de índice de este año, pero era tipo palabra clave en la del año pasado:

Cada valor se analiza en el momento de la búsqueda, ya sea que provenga del índice de texto o del de la palabra clave. Los valores de palabra clave de los índices más antiguos se tokenizan y convierten a minúsculas como todo lo demás, así que “connection reset” encuentra “Connection RESET by peer”, sin importar en qué índice se encuentre.

Otro caso interesante es cuando un campo está mapeado en un solo índice pero también presente (y no mapeado) en el otro:

Hay un matiz que vale la pena destacar aquí. Si error_details está mapeado en logs-2026 pero no en logs-2025, Elasticsearch no puede enviar esta búsqueda a Lucene, porque los índices donde el campo no está mapeado no devolverían coincidencias silenciosamente. En cambio, el planificador se da cuenta de que el campo está potencialmente no mapeado y evalúa todo MATCH fila por fila, de donde provengan las filas. No es necesario que sepas en cuál de tus índices está mapeado el campo; la búsqueda simplemente responde a la pregunta.

Cómo ES|QL analiza el texto en tiempo de búsqueda sin un índice invertido

Cuando ES|QL planifica un MATCH contra una expresión, analiza el texto de búsqueda una vez, de antemano, en un conjunto de términos. La forma en que se evalúa cada fila depende del tipo de expresión:

Tipo de expresión

Procesamiento

Comportamiento de coincidencia

texto (mediante TO_TEXT)

El analizador tokeniza el valor en términos en minúsculas

Comparación token-contra-token; una fila coincide si cualquier token es igual a cualquier término de búsqueda (O semántica)

palabra clave, ip, fecha, numérico

Sin análisis; constante de búsqueda convertida una vez al tipo nativo

Comparación exacta por fila

Ambas rutas eluden Lucene por completo y evalúan los valores fila por fila. La ruta no textual refleja exactamente lo que hace una búsqueda de coincidencia cuando se delega a Lucene contra esos tipos de campo, por lo que la semántica sigue siendo consistente independientemente de si la búsqueda llega a un índice.

Una búsqueda de índice invertido hace su trabajo en el momento de la ingesta, y nunca procesa documentos que no coinciden en el momento de la búsqueda. Un MATCH en tiempo de ejecución realiza ese análisis en el momento de la búsqueda, por cada fila que llega a él. Uno es rápido porque el trabajo ya ocurrió; el otro es flexible porque los datos no necesitan haber sido indexados en absoluto.

¿Qué novedades hay para la búsqueda de texto completo en ES|QL?

Todo lo que se menciona en esta publicación es la primera entrega de un esfuerzo mayor para lograr que la búsqueda en ES|QL funcione con cualquier tipo de contenido, no solo con lo que se indexó previamente. Las limitaciones señaladas anteriormente se abordan de forma activa, y la roadmap va más allá:

• Puntuación. Las coincidencias en tiempo de ejecución contribuirán a _score, por lo que puedes ordenar por relevancia incluso cuando los datos nunca se indexaron.

• MATCH_PHRASE en las expresiones. Ya disponible en Elastic Cloud Serverless, y llegará a Elastic Stack en la versión 9.6.

• Analizadores configurables. Compatibilidad del analizador con MATCH y MATCH_PHRASE en expresiones, lo que permite el uso de analizadores de lenguaje, derivación y sinónimos en el momento de la búsqueda.

• Opciones de coincidencia. Opciones como la coincidencia inexacta y el operador para coincidencias en tiempo de ejecución.

• Búsqueda vectorial. Generar incrustaciones por fila y ejecutar kNN (vecinos más cercanos) en expresiones dense_vector en tiempo de ejecución, llevando también la búsqueda semántica a datos no indexados.

Prueba la búsqueda de texto completo ES|QL en expresiones hoy

Puedes probar la búsqueda en tiempo de ejecución hoy mismo. Ya está disponible en Elastic Cloud Serverless, donde las nuevas capacidades de ES|QL llegan primero y se lanza como vista previa técnica en Elasticsearch 9.5. Comienza con la referencia de funciones de búsqueda y consulta la página de limitaciones de ES|QL para conocer los límites actuales. Es una vista previa técnica porque queremos tus comentarios: si realizas una búsqueda de algo que nunca fue indexado y te sorprende, ya sea positiva o negativamente, nos encantaría saberlo.

1. Uso de la API _mapping para recuperar información de campos

2. Uso de la API _search para mostrar los valores de los campos

3. Visualización de subcampos

4. _source sintética

5. Campos de tiempo de ejecución

1. Uso de la API _mapping para recuperar información de campo

La API _mapping permite recuperar la definición de mapeo para un índice o varios índices. Esto incluye información sobre los campos, sus tipos de datos y otras propiedades. Para recuperar el mapeo de un índice específico, emplee la siguiente petición:

Por ejemplo, si tienes un índice llamado my_index, puedes recuperar su mapeo con la siguiente petición:

La respuesta incluirá la definición de mapeo para el índice, que contiene información sobre los campos y sus propiedades.

También es posible recuperar el mapeo de un campo específico. Esto puede ser útil si tu mapeo es bastante grande y solo quieres centrarte en un campo específico. Para recuperar el mapeo de un campo específico, emplee la siguiente petición:

También puedes recuperar las asignaciones de varios campos separando sus nombres con comas, como en la siguiente petición:

2. Uso de la API _search para mostrar los valores de los campos

Para mostrar los valores de los campos en un índice de Elasticsearch, puedes usar la API _search . La API _search te ofrece múltiples formas de controlar qué campos se devuelven; Los dos principales son:

1. _source: El campo _source contiene el cuerpo original del documento JSON exactamente como estaba indexado, incluyendo cualquier cambio realizado por las canalizaciones de ingestión o pasos de preprocesamiento. Para mostrar campos específicos del documento fuente, implementa filtrado de fuentes como veremos a continuación.

2. fields: El parámetro fields te permite recuperar campos específicos de tus documentos al realizar una búsqueda, basándote en el mapeo de índice. A diferencia de _source, fields también puede devolver valores de campos almacenados, valores de documentación o campos de ejecución sin referenciar la _source, aunque para campos estándar sin valores de documento ni configuraciones almacenadas, vuelve a _source. Esto puede aportar muchos beneficios como el rendimiento y más, como veremos a continuación.

Uso del campo _source

Por defecto, la API _search devuelve el campo _source , que contiene el documento JSON original que se indexó. Para mostrar campos específicos, puedes agregar filtros en el parámetro _source de la solicitud de búsqueda; Esto se llama filtrado de fuente.

Aquí tienes un ejemplo de una solicitud de búsqueda que devuelve los valores de los campos title y author para documentos en el índice my_index :

En este ejemplo, el parámetro _source especifica los campos que se deben devolver.

Si necesitas aún más control, puedes usar las propiedades de includes y excludes del objeto _source. Por ejemplo, la consulta siguiente devuelve el campo title de nivel superior y todos los subcampos de author excepto author.description.

En este ejemplo, usamos el patrón author.* para recuperar todos los subcampos directos del objeto author . Luego excluimos explícitamente author.description para que solo se devuelvan los otros campos de autor. Ten en cuenta que esto no tiene mejoras de rendimiento ya que aún tiene que cargar y analizar el JSON de origen, pero puede reducir el tamaño de la respuesta enviada por la red.

Uso del parámetro de campos

Puedes usar el parámetro fields para filtrar los campos que aparecen en la respuesta de búsqueda. Emplear fields _source ofrece varios beneficios, entre ellos:

• Mejora de rendimiento: fields puede devolver valores directamente desde campos almacenados o valores de documentos sin tener que cargar toda la _source, haciendo que el tamaño de la carga útil de respuesta sea menor.

• Salida formateada: Para campos estándar, fields puede recurrir a _source para obtener los valores, pero revisa el mapeo del índice para formatear correctamente la salida, como las fechas formateadas, haciéndolas consistentes con lo que se usa para agregaciones y ordenación.

• Acceso a campos de tiempo de ejecución: fields puede devolver campos de tiempo de ejecución, que no existen en el _sourceoriginal.

• Aquí se pueden encontrar más beneficios.

Por ejemplo, para devolver solo los campos title y author en el índice my_index , puedes usar la siguiente solicitud de búsqueda:

En la consulta anterior, ponemos el campo _source en false para no devolver el documento fuente. Esto puede minimizar significativamente el tamaño de la carga útil para la respuesta, pero recuerda que esto solo funciona porque los campos title y author son del tipo keyword campo, que doc_values habilitaron por defecto. Si el campo no tiene doc_values activado y el _source está configurado como falso, Elasticsearch no tendría forma de recuperarlos y se omitiría en la respuesta.

Es importante señalar que la respuesta fields siempre devuelve un array de valores para cada campo, incluso si solo hay un único valor. Esto se debe a que Elasticsearch no tiene un tipo de array dedicado, y cualquier campo puede tener varios valores. Para más información sobre los arrays en Elasticsearch, haz clic aquí.

Otras formas de recuperar campos

Aunque recuperar campos usando _source o fields son los métodos recomendados, existen diferentes métodos disponibles para casos de uso específicos, como:

Campos de valor de documentos: Si quieres evitar _source por completo, puedes buscar usando el parámetro docvalue_fields. Los valores de documentación almacenan los mismos valores de campo que _source pero en una estructura de datos en disco, optimizada para ordenar y agregar.

Como está separado de los valores almacenados con _source, puedes aplicar campos específicos sin cargar toda la _source. Esto es útil si consultas documentos grandes pero solo necesitas unos pocos campos pequeños que soporten valores de documentos. Otro caso de uso para usar docvalue_fields es cuando quieres usar formato personalizado en campos date y numeric , como veremos en el ejemplo más abajo.

Ten en cuenta que esto solo funciona para campos que activas doc_values o para tipos de campos que lo tienen activado por defecto, como keyword, date, tipos numéricos y boolean, no para text o annotated_text.

En este ejemplo, usamos el parámetro docvalue_fields para recuperar los campos title, author, y published sin cargar el documento completo de _source :

Cuando se ejecuta esta consulta, Elasticsearch toma los valores directamente de su almacenamiento columnar en disco en lugar de referenciar el _source de cada documento. El campo published se devuelve con el formato epoch_millis en lugar del formato por defecto, gracias al parámetro format proporcionado en la consulta.

Campos almacenados: Si marcas explícitamente campos específicos como almacenados en el mapeo, puedes usar el parámetro stored_fields para filtrar esos campos. Esto es útil si quieres respuestas ligeras solo con esos campos específicos o para campos que almacenaste deliberadamente para recuperarlos después. Se almacena por separado de _source, por lo que este método también es útil para evitar la necesidad de cargar _source.

Es importante señalar que esta opción está desactivada por defecto y generalmente no se recomienda. Emplea filtrado de fuentes para devolver ciertos subconjuntos del documento fuente original.

En la consulta de ejemplo a continuación, usamos el parámetro stored_fields para recuperar el campo summary , que tiene la configuración de mapeo de índice "store”: true.

Cuando se ejecuta esta consulta, Elasticsearch busca si este campo está marcado con ”store”: true, si no lo encuentra, se saltará el campo por completo.

3. Visualización de subcampos

Si tu índice contiene subcampos, puedes usar la notación de puntos para especificar el camino de campo en el parámetro fields . Ten en cuenta que los subcampos son diferentes del tipo de campo anidado. Por ejemplo, si tienes un subcampo llamado address.city, puedes incluirlo en la respuesta de búsqueda así:

En este ejemplo, la respuesta de búsqueda incluirá los valores de los campos title, author address.city .

4. _source sintético

Si quieres mantener la funcionalidad de usar _source pero también ahorrar espacio en disco, tienes la opción de usar _source sintético en tu mapeo de índice. La_source sintética es una función que permite a Elasticsearch reconstruir el _source a partir de datos existentes como campos almacenados y valores de documentos, incluso cuando _source está desactivado. Esto te permite ahorrar mucho espacio de almacenamiento a cambio de velocidades ligeramente menores en el momento de la consulta, ya que la reconstrucción se realiza sobre la marcha. Activa esta función usando los valores que aparecen a continuación en la configuración de tu índice:

Algunos beneficios de usar _source sintéticos incluyen: visualización completa del documento al usar la API _search , filtrado de código fuente y compatibilidad con otras funciones y herramientas como Kibana que esperan _source estén disponibles, todo ello evitando la necesidad de almacenar el documento completo _source .

5. Campos de tiempo de ejecución

Los campos de ejecución te permiten definir campos guionizados en el momento de la consulta o en tu mapeo de índice bajo un bloque de ejecución. Estos campos nunca se indexan, por lo que agregar un campo en tiempo de ejecución no aumenta el tamaño del índice pero nunca aparecerá en _source. Los campos de ejecución definidos en el mapeo son persistentes y están disponibles para todas las consultas, mientras que los campos de ejecución definidos en el momento de la consulta son temporales y solo están disponibles en esa solicitud de búsqueda.

El principal beneficio de usar campos de tiempo de ejecución es la posibilidad de agregar campos a documentos luego de haberlos ingerido, simplificando así tus decisiones de mapeo. Los campos de ejecución también son ideales para enriquecer tus documentos con valores que no existen en el documento original pero que se generan mediante un script, como formatear una cadena o calcular un puntaje.

También cabe destacar que los campos de ejecución pueden perjudicar el rendimiento, ya que será necesario ejecutar un script para cada documento del conjunto de resultados. Para recuperar un campo de ejecución, también puedes usar el parámetro fields en la API _search .

Conclusión

Mostrar campos de un índice de Elasticsearch puede ir desde simplemente recuperar valores usando el mapeo de índice o el _source, hasta métodos más avanzados usando campos fields, docvalue_fieldso en tiempo de ejecución para mayor control y eficiencia. Comprender los compromisos entre diferentes métodos es clave para optimizar tus experiencias de búsqueda. Ya sea que estés optimizando cargas útiles, enriqueciendo documentos o empleando _source sintéticos para ahorrar espacio, Elasticsearch te ofrece múltiples herramientas y funciones para encontrar los datos que necesitas, de la manera que necesitas. Estas técnicas pueden ayudarte a entender la estructura de tus datos, identificar campos específicos y solucionar problemas.

En este artículo, discutiremos estos tipos de campos, cuándo usar cada uno y cómo se relacionan con la generación y las estrategias de uso de incrustaciones, tanto durante la indexación como durante la consulta.

Tipo vectorial denso

El tipo de campo dense_vector en Elasticsearch se emplea para almacenar vectores densos, que son representaciones numéricas de datos como texto, imágenes y audio, donde casi todas las dimensiones son relevantes. Estos vectores se generan empleando modelos de incrustación proporcionados por plataformas como OpenAI, Cohere o Hugging Face, y están diseñados para captar el significado semántico general de los datos, incluso cuando no comparten términos exactos con otros documentos.

En Elasticsearch, los vectores densos pueden tener hasta 4096 dimensiones dependiendo del modelo empleado. Por ejemplo, el modelo totalmente MiniLM-L6-v2 genera vectores con 384 dimensiones, mientras que el text-embedding-ada-002 de OpenAI produce vectores con 1536 dimensiones.

El campo dense_vector se adopta comúnmente como el tipo predeterminado para almacenar este tipo de incrustación cuando se necesita mayor control, como usando vectores pregenerados, aplicando funciones de similitud personalizadas o integrando con modelos externos.

¿Cuándo y por qué usar dense_vector tipo?

Los vectores densos son excelentes para capturar similitudes semánticas entre oraciones, párrafos o documentos completos. Funcionan muy bien cuando el objetivo es comparar el significado general de los textos, aunque no compartan los mismos términos.

El campo vectorial denso es ideal cuando ya tienes una pipeline externa de generación de embedding usando modelos proporcionados por plataformas como OpenAI, Cohere o Hugging Face y solo quieres almacenar y consultar estos vectores manualmente. Este tipo de campo ofrece alta compatibilidad con modelos de incrustación y total flexibilidad en la generación y consulta, permitiéndote controlar cómo se producen, indexan y emplean los vectores durante la búsqueda.

Además, soporta diferentes formas de búsqueda semántica, con consultas como k-NN o script_score para casos en los que sea necesario ajustar la lógica de clasificación. Estas posibilidades hacen que el vector denso sea ideal para aplicaciones como RAG (Generación Aumentada por Recuperación), sistemas de recomendación y búsquedas personalizadas basadas en similitudes.

Por último, el campo te permite personalizar la lógica de relevancia, usando funciones como cosineSimilarity, dotProduct o l2norm para adaptar la clasificación según las necesidades de tu caso de uso.

Los vectores densos siguen siendo la mejor opción para quienes necesitan flexibilidad, personalización y compatibilidad con casos de uso avanzados como los mencionados anteriormente.

¿Cómo usar la consulta para el tipo de vector denso?

Las búsquedas en campos definidos como dense_vector emplean la consulta k-vecinos más cercanos. Esta consulta es responsable de encontrar documentos cuyo vector denso está más cercano al vector de consulta. A continuación se muestra un ejemplo de cómo aplicar una consulta k-NN a un campo vectorial denso:

Además de la consulta k-NN, si es necesario personalizar el puntaje del documento, también es posible usar la consulta script_score, combinándola con funciones de comparación vectorial como cosenoSimilitud, Producto PuntoPunto o l2norm para calcular la relevancia de forma más controlada. Mira el ejemplo:

Si quieres profundizar más, te recomiendo explorar el artículo Cómo configurar la búsqueda vectorial en Elasticsearch.

Tipo vectorial disperso

El tipo de campo sparse_vector se emplea para almacenar vectores dispersos, que son representaciones numéricas donde la mayoría de los valores son cero y solo unos pocos términos tienen pesos significativos. Este tipo de vector es común en modelos basados en términos como SPLADE o ELSER (Elastic Learned Sparse EncodeR).

¿Cuándo y por qué usar tipo vectorial disperso?

Los vectores dispersos son ideales cuando se necesita una búsqueda más precisa en términos léxicos, sin sacrificar la inteligencia semántica. Representan el texto como pares token/valor, resaltando solo los términos más relevantes con pesos asociados, lo que proporciona claridad, control y eficiencia.

Este tipo de campo es especialmente útil cuando se generan vectores basados en términos, como en los modelos ELSER o SPLADE, que asignan diferentes pesos a cada token según su importancia relativa en el texto.

Para las ocasiones en las que quieres controlar la influencia de palabras específicas en la consulta, los tipos vectoriales dispersos te permiten ajustar manualmente el peso de los términos para optimizar el orden de los resultados.

Entre los principales beneficios están la transparencia en la búsqueda, ya que es posible entender claramente por qué un documento se consideraba relevante, y la eficiencia de almacenamiento, ya que solo se almacenan los tokens con valor distinto de cero, a diferencia de los vectores densos que almacenan todas las dimensiones.

Además, los vectores dispersos son el complemento ideal en estrategias de búsqueda híbrida, e incluso pueden combinar con vectores densos para combinar precisión léxica con comprensión semántica.

¿Cómo usar la consulta para el tipo de vector disperso?

La consulta sparse_vector te permite buscar documentos basándote en un vector de consulta en formato token/valor. Consulta un ejemplo de la consulta a continuación:

Si prefieres usar un modelo capacitado, es posible emplear un punto final de inferencia que transforme automáticamente el texto de consulta en un vector disperso:

Para profundizar en este tema, sugiero leer Understanding sparse vector embeddings with trained ML models.

Tipo de texto semántico

El tipo de campo semantic_text es la forma más sencilla y directa de usar la búsqueda semántica en Elasticsearch. Gestiona automáticamente la generación de incrustaciones, tanto en tiempo de indexación como en tiempo de consulta, a través de un punto final de inferencia. Esto significa que no tienes que preocuparte por generar o almacenar vectores manualmente.

¿Cuándo y por qué usar texto semántico?

El campo semantic_text es ideal para quienes quieren empezar con el mínimo esfuerzo técnico y sin tener que manejar vectores manualmente. Este campo automatiza pasos como la generación de incrustaciones y el mapeo de búsqueda vectorial, haciendo que la configuración sea más rápida y cómoda.

Deberías considerar usar semantic_text cuando valoras la simplicidad y la abstracción, ya que elimina la complejidad de configurar manualmente mapeos, generación de incrustaciones y pipelines de ingestión. Solo tienes que seleccionar el modelo de inferencia, y Elasticsearch se encarga del resto.

Los principales beneficios incluyen la generación automática de incrustaciones, realizada tanto durante la indexación como durante la consulta, y el mapeo listo para usar, que viene preconfigurado para soportar el modelo de inferencia seleccionado.

Además, el campo ofrece soporte nativo para la división automática de textos largos (fragmentación de texto), permitiendo dividir textos grandes en pasajes más pequeños, cada uno con su propia incrustación, lo que mejora la precisión en la búsqueda. Esto aumenta enormemente la productividad, especialmente para equipos que quieren ofrecer valor rápidamente sin tener que lidiar con la ingeniería subyacente de la búsqueda semántica.

Sin embargo, aunque semantic_text proporciona rapidez y simplicidad, este enfoque tiene algunas limitaciones. Permite el uso de modelos estándar de mercado, siempre que estén disponibles como puntos finales de inferencia en Elasticsearch. Pero no soporta incrustaciones generadas externamente, como es posible con el campo dense_vector .

Si necesitas más control sobre cómo se generan los vectores, quieres usar tus propios embeddings o necesitas combinar varios campos para estrategias avanzadas, los campos dense_vector y sparse_vector ofrecen la flexibilidad necesaria para escenarios más personalizados o específicos de dominio.

Cómo usar la consulta para el tipo de texto semántico

Antes de semantic_text, era necesario usar una consulta diferente según el tipo de incrustación (densa o dispersa). Se empleaba una consulta sparse_vector para campos dispersos, mientras que dense_vector campos requerían consultas KNN.

Con el tipo de texto semántico, la búsqueda se realiza usando la consulta semántica, que genera automáticamente el vector de consulta y lo compara con las incrustaciones de los documentos indexados. El tipo semantic_text permite definir un extremo de inferencia para incrustar la consulta, pero si no se especifica ninguno, se aplicará el mismo punto final que se usa durante la indexación a la consulta.

Para saber más, te sugiero leer el artículo Elasticsearch nueva semantic_text mapeo: Simplificando la búsqueda semántica.

Conclusión

Al elegir cómo mapear incrustaciones en Elasticsearch, es esencial entender cómo quieres generar los vectores y qué nivel de control necesitas sobre ellos. Si buscas simplicidad, el campo de texto semántico permite una búsqueda semántica automática y escalable, lo que lo hace ideal para muchos casos de uso iniciales. Cuando se requiere más control, un rendimiento ajustado o integración con modelos personalizados, los campos vectoriales densos y dispersos proporcionan la flexibilidad necesaria.

El tipo de campo ideal depende de tu caso de uso, la infraestructura disponible y la madurez de tu pila de aprendizaje automático. Lo más importante es que Elastic ofrece las herramientas para construir sistemas de búsqueda modernos y altamente adaptables.

Referencias

• Tipo de campo de texto semántico

• Tipo de campo vectorial disperso

• Tipo de campo vectorial denso

• Consulta semántica

• Consulta vectorial dispersa

• Búsqueda kNN

• Mapeado de nuevas semantic_text de Elasticsearch: Simplificación de la búsqueda semántica

• Comprendiendo las incrustaciones de vectores dispersos con modelos de aprendizaje automático capacitados