Noticias
Modelos
Productos
keyboard_arrow_down
Lector
Lea las URL y busque en la web para obtener una base más sólida para su LLM.
Incrustaciones
Integraciones multilingües y multimodales de clase mundial.
reclasificador
Recuperador neuronal de clase mundial para maximizar la relevancia de la búsqueda.
Búsqueda profunda
Busca, lee y razona hasta encontrar la mejor respuesta.
Más
keyboard_arrow_down
Clasificador
Clasificación de cero disparos y pocos disparos para imágenes y texto.
Segmentador
Corta el texto largo en fragmentos y haz tokenización.

Documentación de la API
Generación automática de código para su IDE o LLM de Copilot
open_in_new


Compañía
keyboard_arrow_down
Sobre nosotros
Contactar con ventas
Programa de prácticas
Únete a nosotros
open_in_new
Descargar logotipo
open_in_new
Términos y condiciones


Acceso
login
¿Qué es la Expansión de Consultas?
Expansión de Consultas con LLM
Probándolo
Resultados
Uso de Prompts Específicos por Tarea
Consideraciones Clave en la Expansión de Consultas
Direcciones Futuras
Blog de tecnología
febrero 18, 2025

Expansión de consultas con LLMs: búsquedas mejores diciendo más

La búsqueda ha cambiado mucho desde la introducción de los modelos de embeddings. ¿Existe todavía un papel para las técnicas léxicas como la expansión de consultas en la IA? Creemos que sí.
Michael Günther
Scott Martens
Michael Günther, Scott Martens • 9 minutos de lectura

La expansión de consultas ha sido durante mucho tiempo una técnica preferida para potenciar los sistemas de búsqueda, aunque ha quedado en segundo plano desde que aparecieron los embeddings semánticos. Si bien algunos podrían considerarla obsoleta en nuestro panorama actual de RAG y búsqueda mediante agentes, no la descarten todavía. En esta exploración profunda, veremos cómo combinar la expansión automática de consultas con jina-embeddings-v3 y LLMs puede mejorar tu sistema de búsqueda y entregar resultados realmente precisos.

tag¿Qué es la Expansión de Consultas?

La expansión de consultas se desarrolló para sistemas de búsqueda que juzgan la relevancia comparando palabras de las consultas con documentos que las contienen, como tf-idf u otros esquemas de "vectores dispersos". Esto tiene algunas limitaciones obvias. Las variantes de las palabras interfieren con la coincidencia, como "corrió" y "corriendo", o "optimizar" vs. "optimizar". El preprocesamiento consciente del lenguaje puede mitigar algunos de estos problemas, pero no todos. Los términos técnicos, sinónimos y palabras relacionadas son mucho más difíciles de abordar. Por ejemplo, una consulta de investigación médica sobre "coronavirus" no identificará automáticamente documentos que hablen de "COVID" o "SARS-CoV-2", aunque serían coincidencias muy buenas.

La expansión de consultas se inventó como solución.

La idea es agregar palabras y frases adicionales a las consultas para aumentar la probabilidad de identificar buenas coincidencias. De esta manera, una consulta por "coronavirus" podría tener agregados los términos "COVID" y "SARS-CoV-2". Esto puede mejorar dramáticamente el rendimiento de la búsqueda.

Figura 1: Diagrama de Flujo de Expansión de Consultas con Tesauro

No es fácil decidir qué términos deben agregarse a una consulta, y ha habido mucho trabajo sobre cómo identificar buenos términos y cómo ponderarlos para la recuperación estilo tf-idf. Los enfoques comunes incluyen:

  • Usar un tesauro curado manualmente.
  • Minería de datos en grandes corpus de texto para encontrar palabras relacionadas.
  • Identificar otros términos usados en consultas similares tomadas de un registro de consultas.
  • Aprender qué palabras y frases funcionan bien como expansiones de consultas a partir de la retroalimentación del usuario.

Sin embargo, se supone que los modelos de embedding semántico eliminan la necesidad de expansión de consultas. Los buenos embeddings de texto para "coronavirus", "COVID" y "SARS-CoV-2" deberían estar muy cerca entre sí en el espacio vectorial de embedding. Deberían coincidir naturalmente sin ningún tipo de aumentación.

Pero, aunque esto debería ser cierto en teoría, los embeddings reales hechos por modelos reales a menudo quedan cortos. Las palabras en los embeddings pueden ser ambiguas y agregar palabras a una consulta puede orientarla hacia mejores coincidencias si usas las palabras correctas. Por ejemplo, un embedding para "erupción cutánea" podría identificar documentos sobre "actuar precipitadamente" y "crema para la piel" mientras pasa por alto un artículo de revista médica que habla sobre "dermatitis". Agregar términos relevantes probablemente orientará el embedding lejos de coincidencias no relacionadas hacia mejores resultados.

tagExpansión de Consultas con LLM

En lugar de usar un tesauro o hacer minería de datos léxica, analizamos el uso de un LLM para hacer expansión de consultas. Los LLMs tienen algunas ventajas potenciales importantes:

  • Amplio conocimiento léxico: Debido a que están entrenados en conjuntos de datos grandes y diversos, hay menos preocupación por seleccionar un tesauro apropiado u obtener los datos correctos.
  • Capacidad de juicio: No todos los términos de expansión propuestos son necesariamente apropiados para una consulta específica. Los LLMs pueden no hacer juicios perfectos sobre la pertinencia, pero las alternativas realmente no pueden hacer juicios en absoluto.
  • Flexibilidad: Puedes ajustar tu prompt a las necesidades de la tarea de recuperación, mientras que otros enfoques son rígidos y pueden requerir mucho trabajo para adaptarse a nuevos dominios o fuentes de datos.

Una vez que el LLM ha propuesto una lista de términos, la expansión de consultas para embeddings funciona de la misma manera que los esquemas tradicionales de expansión de consultas: Agregamos términos al texto de la consulta y luego usamos un modelo de embedding para crear un vector de embedding de consulta.

Figura 2: Expansión de Consultas de Embeddings con un LLM

Para que esto funcione, necesitas:

  • Acceso a un LLM.
  • Una plantilla de prompt para solicitar términos de expansión del LLM.
  • Un modelo de embedding de texto.

tagProbándolo

Hemos realizado algunos experimentos para ver si este enfoque agrega valor a la recuperación de información textual. Nuestras pruebas utilizaron:

  • Un LLM: Gemini 2.0 Flash de Google.
  • Dos modelos de embedding para ver si la expansión de consultas LLM se generaliza entre modelos: jina-embeddings-v3 y all-MiniLM-L6-v2.
  • Un subconjunto de los benchmarks BEIR para recuperación de información.

Realizamos nuestros experimentos bajo dos condiciones de prompting:

  • Usando una plantilla de prompt general para solicitar términos de expansión.
  • Usando plantillas de prompt específicas para cada tarea.

Finalmente, escribimos nuestros prompts para solicitar diferentes cantidades de términos para agregar: 100, 150 y 250.

Nuestro código y resultados están disponibles en GitHub para reproducción.

GitHub - jina-ai/llm-query-expansion: Query Expension for Better Query Embedding using LLMs
Query Expension for Better Query Embedding using LLMs - jina-ai/llm-query-expansion
GitHubjina-ai

tagResultados

tagUsando un Prompt General

Después de varios intentos y errores, encontramos que el siguiente prompt funcionaba lo suficientemente bien con Gemini 2.0 Flash:

Please provide additional search keywords and phrases for 
each of the key aspects of the following queries that make 
it easier to find the relevant documents (about {size} words 
per query):
{query}

Please respond in the following JSON schema:
Expansion = {"qid": str, "additional_info": str}
Return: list [Expansion]

Este prompt nos permite procesar nuestras consultas en lotes de 20-50, asignando un ID a cada una y obteniendo una cadena JSON que conecta cada consulta con una lista de términos de expansión. Si usas un LLM diferente, es posible que tengas que experimentar para encontrar un prompt que funcione.

Aplicamos esta configuración con jina-embeddings-v3 usando el adaptador de recuperación asimétrica. Usando este enfoque, las consultas y documentos se codifican de manera diferente — usando el mismo modelo pero diferentes extensiones LoRA — para optimizar los embeddings resultantes para la recuperación de información.

Nuestros resultados en varios benchmarks BEIR están en la tabla siguiente. Las puntuaciones son nDCG@10 (Ganancia Acumulada Descontada normalizada en los diez primeros elementos recuperados).

Benchmark Sin Expansión 100 términos 150 términos 250 términos
SciFact
(Tarea de Verificación de Hechos)
72.74 73.39 74.16 74.33
TRECCOVID
(Tarea de Recuperación Médica)
77.55 76.74 77.12 79.28
FiQA
(Recuperación de Opciones Financieras)
47.34 47.76 46.03 47.34
NFCorpus
(Recuperación de Información Médica)
36.46 40.62 39.63 39.20
Touche2020
(Tarea de Recuperación de Argumentos)
26.24 26.91 27.15 27.54

Vemos aquí que la expansión de consultas ha resultado en una mejora de la recuperación en casi todos los casos.

Para probar la robustez de este enfoque, repetimos las mismas pruebas con all-MiniLM-L6-v2, un modelo mucho más pequeño que produce vectores de embedding más reducidos.

sentence-transformers/all-MiniLM-L6-v2 · Hugging Face
We're on a journey to advance and democratize artificial intelligence through open source and open science.

Los resultados se muestran en la tabla siguiente:

Benchmark No Expansion 100 terms 150 terms 250 terms
SciFact
(Fact Checking Task)
64.51 68.72 66.27 68.50
TRECCOVID
(Medical Retrieval Task)
47.25 67.90 70.18 69.60
FiQA
(Financial Option Retrieval)
36.87 33.96 32.60 31.84
NFCorpus
(Medical Information Retrieval)
31.59 33.76 33.76 33.35
Touche2020
(Argument Retrieval Task)
16.90 25.31 23.52 23.23

Aquí vemos una mejora aún mayor en las puntuaciones de recuperación. En general, el modelo más pequeño se benefició más de la expansión de consultas. La mejora promedio en todas las tareas se resume en la tabla siguiente:

Model 100 terms 150 terms 250 terms
jina-embeddings-v3 +1.02 +0.75 +1.48
all-MiniLM-L6-v2 +6.51 +5.84 +5.88

La gran diferencia en la mejora neta entre los dos modelos probablemente se debe a que all-MiniLM-L6-v2 parte de un nivel de rendimiento más bajo. Los embeddings de consulta producidos por jina-embeddings-v3 en modo de recuperación asimétrica son mejores para capturar relaciones semánticas clave, y por lo tanto hay menos espacio para que la expansión de consultas añada información. Pero este resultado muestra cuánto puede mejorar la expansión de consultas el rendimiento de modelos más compactos que pueden ser preferibles en algunos casos de uso a los modelos grandes.

No obstante, la expansión de consultas trajo una mejora significativa en la recuperación incluso para modelos de alto rendimiento como jina-embeddings-v3, aunque este resultado no es perfectamente consistente en todas las tareas y condiciones.

Para jina-embeddings-v3, agregar más de 100 términos a una consulta fue contraproducente para los benchmarks FiQA y NFCorpus. No podemos decir que más términos sean siempre mejores, pero los resultados en los otros benchmarks indican que más términos son al menos a veces mejores.

Para all-MiniLM-L6-v2, agregar más de 150 términos fue siempre contraproducente, y en tres pruebas, agregar más de 100 no mejoró las puntuaciones. En una prueba (FiQA) agregar incluso 100 términos produjo resultados significativamente más bajos. Creemos que esto se debe a que jina-embeddings-v3 hace un mejor trabajo capturando información semántica en textos de consulta largos.

Ambos modelos mostraron menos respuesta a la expansión de consultas en los benchmarks FiQA y NFCorpus.

tagUso de Prompts Específicos por Tarea

El patrón de resultados reportados arriba sugiere que si bien la expansión de consultas es útil, usar LLMs corre el riesgo de agregar términos de consulta inútiles que reducen el rendimiento. Esto podría deberse a la naturaleza genérica del prompt.

Tomamos dos benchmarks — SciFact y FiQA — y creamos prompts más específicos del dominio, como el siguiente:

Please provide additional search keywords and phrases for 
each of the key aspects of the following queries that make
it easier to find the relevant documents scientific document 
that supports or rejects the scientific fact in the query 
field (about {size} words per query):
{query}
Please respond in the following JSON schema:
Expansion = {"qid": str, "additional_info": str}
Return: list [Expansion]

Este enfoque mejoró el rendimiento de recuperación en casi todos los casos:

Benchmark Model No Expansion 100
terms
150
terms
250
terms
SciFact jina-embeddings-v3 72.74 75.85 (+2.46) 75.07 (+0.91) 75.13 (+0.80)
SciFact all-MiniLM-L6-v2 64.51 69.12 (+0.40) 68.10 (+1.83) 67.83 (-0.67)
FiQA jina-embeddings-v3 47.34 47.77 (+0.01) 48.20 (+1.99) 47.75 (+0.41)
FiQA all-MiniLM-L6-v2 36.87 34.71 (+0.75) 34.68 (+2.08) 34.50 (+2.66)

Las puntuaciones mejoraron en todas las condiciones excepto al agregar 250 términos a las consultas de SciFact con all-MiniLM-L6-v2. Además, esta mejora no fue suficiente para que all-MiniLM-L6-v2 superara su propia línea base en FiQA.

Para jina-embeddings-v3, vemos que los mejores resultados se obtuvieron con 100 o 150 términos añadidos. Agregar 250 términos fue contraproducente. Esto respalda nuestra intuición de que se pueden agregar demasiados términos a la consulta, especialmente si su significado comienza a alejarse del objetivo.

tagConsideraciones Clave en la Expansión de Consultas

La expansión de consultas claramente puede traer ganancias a la búsqueda basada en embeddings, pero viene con algunas advertencias:

tagCosto

Interactuar con un LLM agrega latencia y costos computacionales a la recuperación de información, y puede agregar costos reales si se usa un LLM comercial. La mejora moderada que aporta puede no justificar el gasto.

tagIngeniería de Prompts

Diseñar buenas plantillas de prompts es un arte empírico y experimental. No aseguramos que los que usamos para este trabajo sean óptimos o portables a otros LLMs. Nuestros experimentos con prompts específicos por tarea muestran que cambiar los prompts puede tener efectos muy significativos en la calidad del resultado. Los resultados también varían considerablemente entre dominios.

Estas incertidumbres aumentan el costo de desarrollo y socavan la mantenibilidad. Cualquier cambio en el sistema — cambiar LLMs, modelos de embedding o dominio de información — significa volver a verificar y posiblemente reimplementar todo el proceso.

tagAlternativas

Vemos aquí que la expansión de consultas agregó la mayor mejora al modelo de embedding con el peor rendimiento inicial. La expansión de consultas, al menos en este experimento, no pudo cerrar la brecha de rendimiento entre all-MiniLM-L6-v2 y jina-embeddings-v3, mientras que jina-embeddings-v3 vio mejoras más modestas con la expansión de consultas.

Bajo estas circunstancias, un usuario de all-MiniLM-L6-v2 obtendría mejores resultados a un menor costo adoptando jina-embeddings-v3 en lugar de perseguir la expansión de consultas.

tagDirecciones Futuras

Hemos mostrado aquí que la expansión de consultas puede mejorar los embeddings de consulta, y que los LLMs ofrecen un medio simple y flexible para obtener buenos términos de expansión de consultas. Pero las ganancias relativamente modestas sugieren que hay más trabajo por hacer. Estamos considerando varias direcciones para investigación futura:

  • Probar el valor del enriquecimiento terminológico en la generación de embeddings de documentos.
  • Explorar las posibilidades de mejora de consultas en otras técnicas de búsqueda con IA como el reranking.
  • Comparar la expansión de consultas basada en LLM con fuentes de términos más antiguas y computacionalmente menos costosas, como un tesauro.
  • Entrenar modelos de lenguaje específicamente para ser mejores en expansión de consultas y proporcionarles entrenamiento más específico del dominio.
  • Limitar el número de términos agregados. 100 puede ser demasiado para empezar.
  • Encontrar formas de identificar términos de expansión útiles e inútiles. Cualquier número fijo que impongamos en la expansión de consultas no va a ser un ajuste perfecto y si pudiéramos evaluar dinámicamente los términos sugeridos y mantener solo los buenos, el resultado probablemente sería una mejora en el rendimiento.

Esta es una investigación muy preliminar, y somos optimistas de que técnicas como esta traerán más mejoras a los productos de búsqueda fundamentales de Jina AI.

Categorías:
Blog de tecnología
rss_feed
Oficinas
location_on
Sunnyvale, California
710 Lakeway Dr, Ste 200, Sunnyvale, CA 94085, EE. UU.
location_on
Berlín, Alemania (sede central)
Prinzessinnenstraße 19-20, 10969 Berlín, Alemania
location_on
Beijing, China
Piso 5, Edificio 6, No.48 Haidian West St. Pekín, China
location_on
Shenzhen, China
Piso 402, Edificio de Tecnología Fu'an, Shenzhen, China
Fundación de búsqueda
Lector
Incrustaciones
reclasificador
Búsqueda profunda
Clasificador
Segmentador
Documentación API
Obtener la clave API de Jina
Límite de velocidad
Estado de la API
Compañía
Sobre nosotros
Contactar con ventas
Sala de prensa
Programa de prácticas
Únete a nosotros
open_in_new
Descargar logotipo
open_in_new
Términos
Seguridad
Términos y condiciones
Privacidad
Administrar cookies
email
Jina AI © 2020-2025.