Para los nuevos usuarios, esta es la forma más rápida de poner en marcha la búsqueda de vectores de alta calidad. Si ya usas Elasticsearch, la nueva oferta es la búsqueda de vectores en la plataforma donde ya residen tus datos, sin necesidad de adoptar un sistema nuevo. Elasticsearch Vector Database admite una variedad de situaciones, desde fundamentación para un modelo de lenguaje grande (LLM) hasta dotar a un agente de IA de recuperación y memoria, y prestar servicio a cientos de miles de millones de vectores. Crea un nuevo proyecto y comienza en minutos.

Un motor, todos los casos de uso vectoriales

La base de datos vectorial de Elasticsearch está diseñada para cualquier persona que desarrolle aplicaciones con vectores:

• RAG: recupera el contexto adecuado para tu LLM con la recuperación de vectores densos y dispersos, o elige la búsqueda híbrida combinando la recuperación vectorial y léxica. La calidad de tu generación mejora con la calidad de tu recuperación.

• Agentes de IA: brinda a los agentes una recuperación rápida y filtrada de documentos y memoria de conversación, con las bajas latencias que demandan los bucles de agentes de varios pasos.

• Búsqueda semántica: busca coincidencias según el significado, no por palabras clave, con un tipo de campo y cero código de pipeline.

• Recomendaciones y similitud: encuentra los vecinos más cercanos en productos, imágenes o cualquier contenido que tengas, a escala.

Todo lo que tu carga de trabajo vectorial necesita, optimizado y listo para usar

Crear una aplicación basada en vectores implica conectar varias piezas independientes: configurar y alojar modelos de incrustación, indexar tus documentos a través de ellos, almacenar los vectores de forma eficiente, aplicar el modelo de incrustación a cada búsqueda, comparar con el almacenamiento vectorial y, por último, recuperar los documentos detrás de las coincidencias. La base de datos vectorial de Elasticsearch se encarga de todo por ti, sin configuración ni ajustes adicionales.

Indexación de vectores con el modo de índice vectordb_document

El modo de índice vectordb_document, una nueva configuración de índice diseñada especialmente para cargas de trabajo centradas en vectores, está activado de forma predeterminada, por lo que obtienes la configuración que elegirían los expertos. Esto es lo que activa:

• bfloat16 de forma predeterminada: Los vectores se almacenan con la mitad del tamaño de float32 y un impacto insignificante en la recuperación, lo que reduce aproximadamente a la mitad el espacio en disco incluso antes de que entre en juego la cuantización.

• Vectores de origen excluidos: en Elasticsearch, tus incrustaciones ya se encuentran en las estructuras de índice que se usan para la búsqueda; mantener una segunda copia sin procesar in _source solo infla el almacenamiento y ralentiza la recuperación de resultados. Excluimos el duplicado para que las respuestas se devuelvan más rápido y almacenes menos.

• Los archivos adecuados precargados en caché: las estructuras de datos a las que primero acceden las búsquedas vectoriales se cargan en la memoria con anticipación, para que tu primera (y tu milésima) búsqueda sea ultrarrápida.

• Combinación paralela: La combinación consolida los segmentos en estructuras vectoriales mejor organizadas, lo que mejora tanto la recuperación como la latencia, y ejecutar esas combinaciones en varios hilos permite lograrlo más rápido.

Almacenamiento de vectores, compresión y ajuste automático

• Tus vectores se comprimen automáticamente. Better Binary Quantization (BBQ) reduce la huella de memoria de los vectores hasta 32 veces mientras conserva la recuperación, y DiskBBQ reduce aún más los requisitos de memoria para cargas de trabajo a gran escala. 

• Opta por la autocalibración, que ajusta la cuantización de cada segmento a tus datos y la vuelve a calibrar en cada fusión a medida que los datos varían. Al probarse en 18 sets de datos, las búsquedas por segundo (QPS) mejoraron un promedio de 16.7 %, con mejoras en la recuperación en la mayoría de ellos.

Incrustaciones en inferencia por GPU administrada

• Genera incrustaciones con modelos nativos de incrustación y reclasificación de Jina AI, o incorpora modelos de terceros, todo en GPU administradas a través de Elastic Inference Service (EIS) sin tener que operar servidores de modelos. O autohospeda, si prefieres el tuyo propio.

• El tipo de campo semantic_text maneja automáticamente la fragmentación y la generación de incrustaciones, junto con las consultas, el camino más simple hacia la búsqueda semántica en el mercado. 

Búsqueda híbrida y búsqueda vectorial filtrada

• La búsqueda híbrida viene integrada, combinando la recuperación de texto completo y vectorial en una sola búsqueda. Combina los resultados con la fusión de rango recíproco (RRF) o cualquier otro mecanismo de combinación que quieras. La búsqueda vectorial suele ser la parte de la búsqueda híbrida más difícil de configurar bien. Con la base de datos vectorial de Elasticsearch, lo tienes resuelto y toda tu pila híbrida mejora. 

• Con la búsqueda de vectores filtrada, aplica filtros de metadatos como parte de la propia recuperación de vectores y no como una idea de último momento que arruina la exhaustividad.

Empresarial desde el primer día

También obtienes control de acceso basado en roles (RBAC), logs de auditoría y las certificaciones de cumplimiento de las que generalmente carecen las bases de datos vectoriales dedicadas.

Accesible a escala y predecible

La base de datos vectorial de Elasticsearch está diseñada para seguir siendo accesible a medida que creces: la compresión BBQ y DiskBBQ que mantiene el almacenamiento lineal y la memoria baja significa que el escalado a cientos de miles de millones de vectores no disparará tu factura. Y lo que pagas se calcula a partir de números que ya conoces: cuántos datos almacenas y cuántos indexas, junto con cuánta capacidad de búsqueda necesitas. Estima tu cantidad de documentos y dimensiones de vectores, además de tu carga de búsqueda, y podrás calcular lo que pagarás antes de crear el proyecto. También puedes entender todos los conceptos de tu factura al final del mes. No hay unidades de cómputo opacas ni cargos sorpresa por operaciones en segundo plano.

Cómo comenzar con la base de datos vectorial de Elasticsearch

Crea un proyecto serverless de base de datos vectorial

Crea un nuevo proyecto sin servidor de base de datos vectorial en Elastic Cloud. Apunta los datos al endpoint y todo estará listo para indexar.

Crea un índice usando semantic_text

El modo de índice de vectores gestiona la configuración de vectores. Usar semantic_text significa que la configuración de las incrustaciones y la fragmentación se gestiona por ti, al igual que la configuración del índice, en inferencia de GPU gestionada, sin necesidad de crear un pipeline de incrustaciones.

Ingestar documentos

Indexa texto y las incrustaciones se generan para ti.

Ejecuta una consulta de búsqueda semántica

Consulta el mismo campo semántico que acabas de crear:

Y recibes los resultados:

La búsqueda semántica es solo el comienzo. Ejecuta búsquedas totalmente textuales o combina ambas en búsquedas híbridas. Incluso puedes crear tus propias búsquedas de vectores para tener control total. Sigue la guía de inicio rápido de búsqueda semántica en la documentación para obtener todas las instrucciones.

Qué sigue para la búsqueda de vectores en Elasticsearch

Ya estamos trabajando en las próximas mejoras:

• Mejor manejo de varios inquilinos: si tus datos deben mantenerse separados por inquilino, te daremos una forma de hacerlo más rápido y con menos código.

• Optimización automática del índice: de "índice completamente nuevo" a "totalmente optimizado", con los menores ajustes posibles.

• Mejoras continuas de la infraestructura: Ajuste continuo de la configuración y la infraestructura de la base de datos vectorial para obtener siempre el mejor rendimiento y las respuestas más rápidas.

Prueba la base de datos vectorial de Elasticsearch en Elastic Cloud Serverless

Pasa de un proyecto vacío a una búsqueda vectorial híbrida y filtrada en minutos, con valores predeterminados de nivel de producción que se encargan del ajuste por ti. Crea apps de IA rápidas y escalables en lugar de infraestructura.

Comienza con Elastic Cloud Serverless o explora la documentación completa y la referencia de la API.

¿Qué es la recuperación?

La recuperación mide en una escala de 0 a 1 cuántos de los documentos que realmente quieren tus usuarios aparecen en algún lugar de los resultados de búsqueda. Si una consulta debe mostrar tres productos y la búsqueda solo arroja dos de ellos en los 10 principales, recall@10 = 0.67 para esa consulta. Es una métrica basada en conjuntos: no le importa la posición de los documentos relevantes dentro de esos k resultados. Un documento relevante en la posición 10 cuenta igual que uno en la posición 1. Tener una recuperación alta significa que no estás perdiendo resultados relevantes.

El diagrama muestra dos conjuntos: todos los documentos relevantes (izquierda) y lo que BM25 realmente recuperó (10 principales, derecha). Solo la intersección cuenta para la recuperación, se encontraron prod_1 y prod_2, mientras que prod_3, prod_4 y prod_6 se perdieron por completo. Resultado: Recall@10 = 2/5 = 0.40.

Requisitos previos

Pongamos manos a la obra para comprender mejor cómo funciona la recuperación. Esta demostración utiliza Python. Puedes seguirlo en el cuaderno complementario (notebook.ipynb), donde cada bloque de código es una celda lista para ejecutarse.

El código proporcionado utiliza lo siguiente:

• Elasticsearch 9.3+

• Python 3.10+

• Un archivo .env con tus credenciales de Elasticsearch

El set de datos

Emplearemos un catálogo con 1000 productos, que abarcan categorías como calzado, electrónica, herramientas y más.

Cada documento tiene cuatro campos:

Campo

Tipo

`título`

texto

'descripción'

texto

`marca`

palabra clave

'categoría'

palabra clave

El set de datos se carga desde dataset.csv.

El poder y los límites de la búsqueda léxica

BM25 es el algoritmo de clasificación predeterminado en Elasticsearch y en la mayoría de los motores de búsqueda. Califica los documentos según la frecuencia con la que aparecen tus términos de consulta en ellos, ajustado por la longitud del documento y la frecuencia de esos términos en todo el índice. Los analizadores aparecen en la parte superior: normalización de minúsculas, derivación y eliminación de palabras vacías. Una búsqueda de "zapatillas para correr" coincidirá con "Zapatillas para correr" y probablemente también con "correr".

Esto funciona bien para una amplia clase de consultas:

• "zapatillas de correr" muestra de inmediato los productos que contienen exactamente esas palabras en el título.

• "parlante con bluetooth" muestra productos de audio portátiles porque los tokens aparecen textualmente.

Los resultados son deterministas y explicables: un documento se clasifica alto porque los términos de la consulta aparecen en él. Depurar la relevancia es sencillo.

Cuándo falla

Ahora probemos estas búsquedas en el mismo catálogo:

• "rutina de skincare": la palabra "rutina" no aparece en ningún título de producto. BM25 puede hacer una coincidencia parcial con "skincare", pero los sueros faciales, aceites corporales y humectantes se describen utilizando términos como "vitamina C", "retinol" o "aclarante", ninguno de los cuales se superpone con la consulta. Los productos que forman una rutina completa de skincare están dispersos en el índice sin ningún token compartido para anclarlos.

• "accesorios de viaje para mascotas": esta es una agrupación de casos de uso, no una categoría de producto. Un transportín para perros, un asiento para mascotas en el automóvil y una jaula de viaje son todos relevantes, pero sus descripciones hablan sobre portabilidad, seguridad y comodidad en vez de "accesorios de viaje". BM25 coincide con "mascota" de manera amplia, pero no tiene ninguna señal para distinguir los productos específicos de viaje del resto del catálogo de mascotas.

Este es un problema de recuperación. Los documentos relevantes están en tu índice. BM25 simplemente no puede encontrarlos porque las palabras del usuario y las del documento no coinciden lo suficiente.

Agregar sinónimos es útil en casos conocidos. Pero no se puede enumerar todas las formas en que un usuario podría expresar una intención. Ahí es donde entran los vectores.

Por qué deberías medir el recall

Antes de solucionar un problema, necesitas cuantificarlo.

Recall@k mide cuántos de los documentos que realmente buscan tus usuarios aparecen en algún lugar de los resultados de búsqueda. Es decir:

Precision@k mide los mejores k resultados y cuántos son realmente relevantes:

La alta precisión significa que los resultados que se devuelven son buenos. En el comercio electrónico, no mostrar un producto relevante (baja recuperación) suele ser peor que mostrar un resultado ligeramente imperfecto (menor precisión), porque un producto oculto es una venta perdida.

La API rank_eval de Elasticsearch te permite medir ambos de forma sistemática. Proporcionas una lista de consultas, cada una con un conjunto de documentos calificados, y Elasticsearch calcula las métricas por ti en todas las consultas.

Configuración de la evaluación

La API rank_eval necesita un set de datos de calificaciones: un mapeo de consultas a los documentos que son relevantes para cada uno, junto con un grado de relevancia (0 = no relevante, 1 = relevante, 2 = altamente relevante).

En el cuaderno, esta es la lista de evaluaciones:

La combinación es intencionada: q1 es una consulta que BM25 maneja bien (tokens exactos en los títulos de productos), mientras que q2, q3 y q4 son consultas basadas en la intención donde la intención del usuario se expresa como un concepto en lugar de palabras clave específicas de producto.

Medición de la recuperación basal de BM25

Primero, configura el cliente de Elasticsearch e indexa los datos de texto sin procesar:

Ahora crea la solicitud rank_eval para BM25. Cada solicitud en la lista combina una consulta con sus calificaciones:

Resultado:

0.43 significa que en las cuatro consultas, BM25 encuentra solo el 43 % de los documentos que debería encontrar. La deficiencia se concentra en las consultas basadas en la intención: "rutina de skincare" no encuentra sueros faciales ni aceites corporales porque la palabra "rutina" nunca aparece en los títulos de los productos, y "accesorios de viaje para mascotas" recupera productos para mascotas que no tienen relación con el tema, mientras que no encuentra transportines ni jaulas descritos en términos de portabilidad y seguridad en vez de "accesorios de viaje".

Esta es nuestra referencia base. Ahora tenemos un número que superar.

Agregar búsqueda vectorial con embeddings de Jina

Vector search Codifica documentos y consultas como vectores de alta dimensión, un tipo de vector compuesto por cientos o miles de valores numéricos, cada uno de los cuales codifica una característica específica de los datos que representa. Los documentos con significado similar terminan cerca unos de otros en el espacio vectorial, incluso si no comparten palabras. "Equipo de gimnasio" y "conjunto de mancuernas" estarán cerca porque los conceptos están relacionados. Elegí Elasticsearch como mi base de datos vectorial porque admite la búsqueda híbrida, lo que me brinda comprensión semántica y precisión de palabras clave de inmediato.

EIS incluye soporte integrado para la incorporación de modelos a través de su API de inferencia.

Paso 1: usar las incrustaciones de Jina v5 como endpoint de inferencia

Si tu clúster tiene recursos de GPU (disponibles en Elastic Cloud y Elasticsearch 9.3+), las incrustaciones se generan en GPU, lo cual es mucho más rápido que la inferencia de CPU y elimina el compromiso de rendimiento que históricamente hacía que los vectores fueran caros a gran escala.

¿Por qué las incrustaciones de Jina en particular? jina-embeddings-v5-text es un modelo multilingüe (más de 119 idiomas) con una ventana de contexto de 32 000 tokens y soporte para adaptadores de Adaptación de Rango Bajo (LoRA) específicos para tareas. Funciona bien para descripciones cortas de productos que están listas para usar. Lee más sobre el modelo jina-embeddings-v5-text aquí.

Paso 2: Crear el índice con un campo semántico

El tipo de campo semantic_text es la clave aquí. Es una abstracción de mayor nivel sobre dense_vector: la apuntas a un endpoint de inferencia, y Elasticsearch se encarga de generar incrustaciones de forma automática.

La propiedad copy_to en title y description significa que el contenido de ambos campos fluye hacia semantic_field para su incrustación, por lo que un solo vector captura la representación completa del producto.

Paso 3: Indexar los productos

En tiempo de indexación, Elasticsearch llama al endpoint de inferencia para cada documento y almacena la incrustación resultante en semantic_field. No necesitas agregar ningún código adicional.

Búsqueda híbrida: combinación de BM25 y vectores con RRF

Agregar vectores mejora la recuperación, pero usar solo vectores corre el riesgo de perder precisión en las consultas de coincidencia exacta; "zapatillas para correr" aún debe clasificar primero las coincidencias literales. La búsqueda híbrida retiene el componente léxico específicamente para preservar esa precisión.

La búsqueda híbrida con Reciprocal Rank Fusion (RRF) combina lo mejor de ambos:

• BM25 se ocupa de consultas exactas y casi exactas con alta precisión.

• La búsqueda semántica gestiona consultas basadas en la intención y multilingües con alto nivel de recuperación.

• RRF combina las dos listas clasificadas en una sola clasificación.

La fórmula RRF asigna a cada documento una puntuación basada en su clasificación en cada lista de resultados:

Un documento que se clasifica en una posición alta en ambas listas obtiene una puntuación combinada más alta. El rank_constant controla cuánto peso reciben los documentos de menor rango.

Resultado:

La búsqueda híbrida mejora sustancialmente sobre BM25 (0.43) y preserva la precisión para consultas de coincidencia exacta como "zapatillas para correr".

Resultados: Antes y después

Aquí está la comparación completa entre los tres enfoques:

Resultado:

Método

Recall@10

BM25 (Lexical)

0,43

Híbrido (BM25 + Vectores)

0,75

Desglose por consulta:

Conclusión

A lo largo de esta publicación, vimos que la búsqueda léxica BM25 es confiable cuando los usuarios teclean consultas exactas, pero pierde recuperación cuando buscan por intención en lugar de palabras clave. Usando rank_eval, establecimos una línea de base reproducible para medir esa brecha con números reales. A partir de ahí, agregamos un semantic_text campo impulsado por incrustaciones de Jina y volvimos a ejecutar la evaluación. El resultado: la búsqueda híbrida mejoró la recuperación de 0.43 a 0.75 a la vez que conservó la precisión en las consultas de coincidencia exacta, aunque el margen real dependerá de tu combinación de consultas.

El patrón escala más allá de este ejemplo: recopila juicios de las consultas reales de tus usuarios, ejecuta rank_eval como línea de base, agrega semantic_text y vuelve a medir. Sabrás exactamente qué mejoró y en qué medida.

Pasos siguientes

• Aprende más sobre la recuperación y la búsqueda de vectores: Recuperación y cuantización de la búsqueda de vectores por Jeff Vestal

• Añade reclasificación para una precisión aún mejor en los resultados principales

• Explora la documentación de búsqueda híbrida de Elasticsearch

• Lee más sobre la API rank_eval

Como vimos en la entrada anterior, la consistencia que aportan las llamadas a funciones no es solo una optimización interesante; es esencial. Una vez que eliminamos los errores estructurales del ciclo de evaluación, los resultados en escenarios estándar (como los de los sets de datos de nivel 4) mejoraron significativamente.

Sin embargo, queda una pregunta obvia por responder:

¿Funciona de igual manera este enfoque cuando todo se complica realmente?

La resolución de entidades del mundo real rara vez falla debido a casos simples. Falla cuando los nombres atraviesan idiomas, culturas, sistemas de escritura, períodos de tiempo y límites organizacionales. Falla cuando las personas se mencionan por sus cargos en lugar de por sus nombres, cuando las empresas cambian de nombre, cuando las transliteraciones no son consistentes y cuando el contexto (no la ortografía) es lo único que vincula una mención a una entidad del mundo real.

Así que, para la publicación final de esta serie, sometimos el sistema a lo que llamamos el desafío definitivo.

¿Qué hace que esto sea el desafío definitivo?

En evaluaciones anteriores, probamos el sistema con sets de datos cada vez más complejos. Para cuando llegamos al nivel 4, analizado en la publicación anterior, ya estábamos lidiando con una mezcla de apodos, cargos, nombres multilingües y referencias semánticas. Esas pruebas demostraron que la arquitectura en sí era estable, pero que los problemas de confiabilidad, especialmente el JSON mal formado, estaban reduciendo la capacidad de recuperación.

Con la llamada a funciones implementada, finalmente conseguimos una base estable. Eso nos dio la oportunidad de hacer una pregunta más interesante:

¿Puede una única pipeline unificada gestionar muchos tipos diferentes de problemas de resolución de entidades al mismo tiempo?

El set de datos del desafío final se diseñó precisamente para poner a prueba esa dimensión.

En lugar de centrarse en una sola dificultad (como apodos o transliteración), este sets de datos combina más de 50 tipos distintos de desafíos, incluyendo:

• Convenciones de nomenclatura cultural.

• Referencias basadas en cargos.

• Relaciones comerciales y cambios históricos de nombre.

• Menciones multilingües y entre sistemas de escritura.

• Desafíos compuestos que mezclan varios de los anteriores.

Lo importante es que no se trata de optimizar para un solo caso de uso concreto. Se trata de probar si el patrón de diseño se mantiene cuando las reglas cambian de entidad a entidad.

Resumen del set de datos

El set de datos del desafío final consta de:

• 50 entidades, que abarcan personas, organizaciones e instituciones.

• ~60 artículos, con estructuras y complejidad lingüísticas variables.

• 51 categorías distintas de desafíos, agrupadas en términos generales en:

  • Convenciones de nomenclatura cultural.

  • Títulos y contexto profesional.

  • Relaciones empresariales y organizacionales.

  • Desafíos multilingües y de transliteración.

  • Escenarios combinados y de casos límite.

Al principio de la serie, vimos que usar IA generativa (GenAI) para crear sets de datos puede tener pros y contras. Sin eso, sería muy difícil reunir datos de prueba lo suficientemente amplios y variados. Pero si no se controla, el modelo tiende a facilitar demasiado todo.

En una fase inicial de generación, por ejemplo, descubrimos que el modelo había incluido frases como «el presidente ruso» como alias explícitos para Vladimir Putin. Eso podría parecer razonable hoy en día, pero anula el propósito de probar la resolución contextual. ¿Qué pasa si el artículo habla de Rusia en la década de 1990? El sistema debería deducir la entidad correcta a partir del contexto, en lugar de basarse en un alias predefinido.

Por esa razón, este set de datos fue diseñado deliberadamente para que los atajos no funcionen. Los alias no se enumeran explícitamente cuando se espera que el sistema deduzca su significado. Las frases descriptivas no están previnculadas a entidades. Las coincidencias correctas suelen depender del contexto del artículo, no solo del texto local.

Nota importante: Aunque demostramos las capacidades del sistema en diversos escenarios, este sigue siendo un prototipo educativo. Los sistemas de producción que manejan el monitoreo de entidades sancionadas en el mundo real requerirían validación adicional, verificaciones de cumplimiento, pistas de auditoría y manejo especializado para casos de uso confidenciales.

¿Por qué estos escenarios son difíciles?

¡En la primera publicación de esta serie, presentamos un ejemplo simple pero ambiguo: “¡La nueva actualización de Swift está aquí!”! El desafío es que “Swift” puede resolverse en múltiples entidades del mundo real, dependiendo del contexto. Ese ejemplo refleja una verdad más amplia: el lenguaje natural es inherentemente ambiguo.

La resolución de entidades, por lo tanto, no es solo un problema de coincidencia de texto. Los humanos solemos basarnos en el conocimiento compartido, las normas culturales y el contexto de cada situación para interpretar las referencias, y casi nunca nos damos cuenta de que lo estamos haciendo.

Considera algunos casos comunes:

• Un título como “el presidente” no tiene sentido sin contexto geopolítico y temporal.

• El nombre de una empresa puede referirse a la empresa matriz, a una filial o a una marca anterior, dependiendo de cuándo se escribió el artículo.

• El nombre de una persona puede aparecer en diferentes órdenes, sistemas de escritura o transcripciones, dependiendo del idioma y la cultura.

• La misma frase puede referirse legítimamente a diferentes entidades en diferentes contextos, y el sistema debe ser capaz de rechazar coincidencias con la misma confianza con la que las acepta.

No existe un único conjunto de reglas que maneje todo esto de manera clara. Por eso este prototipo separa las responsabilidades de forma tan marcada:

• Elasticsearch reduce el espacio de candidatos de manera eficiente y transparente.

• El LLM se usa solo donde se requiere juicio y está obligado a explicarse a sí mismo.

• La recuperación y el razonamiento siguen siendo pasos distintos.

Esta distinción cobra aún más importancia a medida que aumenta la variedad de tipos de desafíos.

Cómo el sistema gestiona la diversidad sin casos especiales

Uno de los resultados más interesantes de esta evaluación es lo que no cambió:

• No agregamos lógica especial para nombres japoneses.

• No agregamos reglas personalizadas para patronímicos árabes.

• No agregamos mapeos codificados para nombres históricos de compañías.

En cambio, el sistema se basó en los mismos elementos principales presentados anteriormente en la serie:

• Entidades enriquecidas con contexto indexadas para búsqueda semántica.

• Recuperación híbrida (exacta, alias y semántica) en Elasticsearch.

• Un conjunto pequeño y bien definido de posibles coincidencias.

• El juicio del LLM está limitado por las llamadas a funciones y los esquemas mínimos.

Esto sugiere que la flexibilidad del sistema proviene de la representación y arquitectura, no de una colección cada vez mayor de reglas.

Cuando el sistema tiene éxito, es porque se recuperan los candidatos adecuados y el LLM tiene suficiente contexto para explicar por qué una referencia mapea (o no) a una entidad específica.

Resultados: ¿cómo funcionó?

En los sets de datos del desafío final, el sistema obtuvo los siguientes resultados generales:

• Precisión: ~91 %

• Recuperación: ~86 %

• Puntuación F1: ~89 %

• Tasa de aceptación en LLM: ~72 %

Rendimiento en los tipos de desafíos

El desglose de resultados por tipo de desafío revela fortalezas y limitaciones:

El mejor desempeño (100 % de puntuación F1) se observó en áreas como:

• Coincidencia entre diferentes sistemas de escritura (entidades comerciales en cirílico, coreano y chino).

• Escenarios hebreos (patronímicos, títulos profesionales, títulos religiosos, transliteración).

• Jerarquías empresariales (aeroespacial, producción diversificada, corporaciones multidivisionales).

• Títulos profesionales (académicos, militares, políticos, religiosos).

• Escenarios japoneses combinados que involucran múltiples sistemas de escritura.

Fuerte rendimiento (80-99 % de puntuación F1) incluido:

• Figuras políticas internacionales (98%).

• Cambios de nombre históricos (90 %).

• Jerarquías empresariales complejas (89 %).

• Nombres de empresas japonesas (93 %).

• Transliteración entre alfabetos (86 %).

• Patronímicos árabes (86 %).

Las áreas más desafiantes fueron:

• Transliteración avanzada (chino, coreano): 0 % F1.

• Ciertos escenarios japoneses (honoríficos, orden de los nombres, variación del sistema de escritura): ~67 % F1.

• Algunos escenarios árabes (nombres de empresas, referencias institucionales): ~40% F1.

Lo importante aquí es por qué el sistema tuvo dificultades en estos casos. Las fallas no se debieron a la ruptura del enfoque general, sino a limitaciones en componentes específicos, sobre todo el modelo vectorial denso utilizado para la búsqueda semántica en ciertos escenarios multilingües.

Como la recuperación y la evaluación están claramente separadas, para mejorar el rendimiento no hace falta reescribir el sistema. Si se sustituyera por un modelo de incrustación multilingüe más potente, se enriquecería el contexto de las entidades o se perfeccionarían las estrategias de recuperación, se mejorarían los resultados en todas estas categorías sin cambiar la arquitectura central.

Desde el punto de vista arquitectónico, esa es la verdadera medida del éxito.

Qué nos dice esto sobre el diseño

Si vemos nuevamente las series, se observan algunas tendencias:

• La preparación importa más que la coincidencia inteligente. El enriquecimiento de entidades con contexto de antemano reduce drásticamente la ambigüedad posteriormente.

• Los LLM son más valiosos como jueces, no como recuperadores. Pedirles que expliquen por qué una coincidencia tiene sentido es mucho más poderoso que pedirles que realicen una búsqueda.

• La fiabilidad permite la precisión. La llamada a funciones no solo limpió el JSON; desbloqueó la memoria que ya estaba latente en el paso de recuperación.

• La generalización supera a la especialización. Un pequeño número de abstracciones bien seleccionadas manejó decenas de tipos de desafío sin lógica personalizada.

Esta es la razón por la que el prototipo es intencionalmente nativo de Elasticsearch y es intencionalmente conservador en cómo utiliza los LLM. El objetivo no es reemplazar la búsqueda; es hacer que la búsqueda sea explicable en situaciones donde el significado importa.

Reflexiones finales

El desafío final no se trataba de perseguir métricas perfectas; se trataba de responder una pregunta más fundamental:

¿Puede una arquitectura transparente, centrada en la búsqueda y asistida por LLM, manejar la ambigüedad de entidades en el mundo real sin colapsar en reglas o cajas negras?

Para este prototipo educativo, la respuesta es sí, con claras advertencias sobre el fortalecimiento de la producción, el cumplimiento, el monitoreo y la calidad de los datos. Si estás creando sistemas que necesitan justificar por qué se hizo una coincidencia de entidades, este patrón merece ser considerado seriamente. Espero que esta serie haya demostrado que la resolución de entidades no tiene que ser misteriosa. Con una correcta separación de responsabilidades, se convierte en algo sobre lo que puedes razonar, medir y mejorar.

Este trabajo también sugiere un patrón arquitectónico más amplio. Lo que surge es una ligera pero importante evolución de la clásica Retrieval-Augmented Generation (RAG). En lugar de permitir que la recuperación alimente directamente la generación, introducimos un paso de evaluación explícito. El LLM se usa primero para juzgar y verificar el estado de los candidatos recuperados, y solo los resultados aprobados pueden incrementar la generación. Se puede pensar en esto como Generation-Augmented Retrieval-Augmented Generation with Evaluation, o GARAGE, porque a quién no le gusta un buen acrónimo.

¿Qué otros casos de uso podrían beneficiarse de este patrón? Los sistemas que requieren confianza, transparencia y razonamiento justificable son candidatos naturales. Los trabajos futuros en este ámbito deberían ser tan convincentes como los resultados que hemos visto aquí, y tengo muchas ganas de ver hacia dónde lo lleva la comunidad.

Próximos pasos: Pruébalo tú mismo

¿Quieres ver el desafío final en acción? Mira el cuaderno de desafío final para obtener una guía completa con implementaciones reales, explicaciones detalladas y ejemplos prácticos.

El pipeline completo de resolución de entidades demuestra los conceptos del núcleo y la arquitectura necesarios para uso en producción. Se puede usar como base para construir sistemas que monitoreen los artículos de noticias, rastreen las menciones de entidades y respondan preguntas sobre qué entidades aparecen en qué artículos, al tiempo que se mantiene la transparencia y la explicabilidad.

1. ¡La nueva actualización de Swift está aquí! Los desarrolladores están ansiosos por probar las nuevas características.

2. ¡La nueva actualización de Swift está aquí! El nuevo álbum se lanzará el próximo mes.

Con este contexto añadido, deberíamos ser capaces de resolver el nombre "Swift" a la entidad correcta.

En la publicación anterior, configuramos nuestra lista de seguimiento y enriquecimos las entidades con contexto adicional. Al ver nuestros ejemplos anteriores, necesitamos tener, al menos, las siguientes dos entidades en la lista: Taylor Swift y Swift Programming Language. También explicamos cómo extraemos las menciones de entidades del texto. Ambos ejemplos extraerían "Swift". Con estos ingredientes en su lugar, la lista de vigilancia enriquecida y las entidades extraídas, finalmente estamos listos para presentar la estrella del espectáculo: la coincidencia de entidades.

Recuerda: Este es un prototipo didáctico diseñado para enseñar conceptos de emparejar entidades. Los sistemas de producción pueden usar diferentes modelos de lenguaje grandes (LLM), reglas de coincidencia personalizadas, pipelines de evaluación especializados o enfoques conjuntos que combinan varias estrategias de coincidencia.

El problema: Por qué la coincidencia es difícil

El lenguaje humano es algo extraordinario. Una de sus propiedades más interesantes es su creatividad infinita. Podemos generar y entender un número infinito de frases nuevas. ¿Es de extrañar, entonces, que las coincidencias exactas en la resolución de entidades sean raras? Los autores se esfuerzan por ser creativos cuando pueden. Sería bastante tedioso si tuviéramos que escribir y leer nombres completos cada vez que se menciona una entidad. Entonces, si bien las coincidencias exactas son fáciles, la realidad es que necesitamos un enfoque más sofisticado para la resolución de entidades: uno que sea lo suficientemente robusto para manejar al menos parte de la creatividad ilimitada de los autores humanos. Por eso dividimos el problema en dos pasos: usar Elasticsearch para recuperar candidatos plausibles a escala, y luego usar un LLM para evaluar si esos candidatos realmente se refieren a la misma entidad del mundo real.

La solución: Emparejamiento en tres pasos con evaluaciones transparentes de LLM

Estamos en medio de un cambio de paradigma en la forma en que usamos las computadoras. Así como el auge de internet nos llevó de la computación localizada a una red globalmente conectada, la IA generativa (GenAI) está cambiando fundamentalmente la forma en que se crean el contenido, el código y la información. De hecho, el prototipo educativo que acompaña a esta serie fue casi exclusivamente "codificado con onda" usando un LLM con indicaciones cuidadosas del autor. Esto no quiere decir que los LLM tengan o incluso alcancen el tipo de productividad inherente al lenguaje humano, pero sí significa que ahora tenemos un recurso poderoso para ayudar con la resolución de entidades.

Un patrón común que usamos con GenAI es Retrieval-Augmented Generation (RAG). Aquí, recuperación significa recuperar candidatos de entidades (no generar respuestas), y el LLM se utiliza estrictamente para la evaluación y explicación de coincidencias. Si bien podríamos pedirle a un LLM que nos ayude con la resolución de entidades de extremo a extremo, ese es un enfoque costoso, tanto en términos de tiempo como de dinero. La RAG ayuda a los LLM a hacer su trabajo mediante el uso de formas más eficientes de proporcionar contexto al LLM, lo que permite que el LLM ayude de manera eficiente con la resolución de la entidad.

Para la parte de recuperación de RAG, volvemos a Elasticsearch. Primero encontramos posibles coincidencias usando una combinación de coincidencia exacta, coincidencia con alias y búsqueda híbrida, que combina búsqueda por palabras clave y búsqueda semántica. Una vez que encontramos estas posibles coincidencias, las enviamos a un LLM para su evaluación. El LLM actúa como el evaluador final de coincidencias. También hacemos que el LLM explique su razonamiento, un diferenciador importante con otros sistemas de resolución de entidades. Sin estas explicaciones, la resolución de entidades es una caja negra; con ellas, podemos ver por nosotros mismos por qué una coincidencia tiene sentido.

Conceptos clave: Coincidencia de tres pasos, búsqueda híbrida y evaluación transparente del LLM

¿Qué es la coincidencia de tres pasos? Al inicio de este proyecto, planteamos la hipótesis de que la búsqueda semántica sería una parte crucial del sistema, pero no todas las coincidencias requieren una búsqueda tan sofisticada. Para encontrar coincidencias de manera eficiente, adoptamos un enfoque progresivo para solucionar el problema. Primero, buscamos coincidencias exactas mediante la búsqueda por palabra clave. Si encontramos dicha coincidencia, nuestro trabajo está terminado y podemos seguir adelante. Si falla la coincidencia exacta, recurrimos a la coincidencia de alias. En el prototipo, la coincidencia de alias también se efectúa usando la coincidencia exacta con palabras clave, para simplificar. En producción, puedes ampliar este paso con normalización, reglas de transliteración, coincidencia difusa o tablas de alias seleccionadas. Si aún no hemos encontrado una posible coincidencia en los dos primeros pasos, entonces es hora de incorporar la búsqueda semántica a través de la búsqueda híbrida de Elasticsearch con fusión de rango recíproco (RRF, por sus siglas en inglés).

¿Qué es la búsqueda híbrida? En Elasticsearch, puedes utilizar la búsqueda semántica para encontrar coincidencias significativas que tengan en cuenta el contexto. Elasticsearch se emplea ampliamente para la búsqueda vectorial y la recuperación híbrida. La similitud semántica es muy útil para el significado, pero no sustituye al filtrado estructurado (por ejemplo, por rangos de tiempo, ubicaciones o identificadores), y a menudo es innecesaria cuando se dispone de una coincidencia exacta. Elasticsearch hizo su marca con la búsqueda léxica, que es excelente en tareas donde la búsqueda semántica no encaja. Para aprovechar al máximo ambos enfoques, utilizamos la búsqueda léxica junto con la búsqueda semántica en una única consulta híbrida. Luego combinamos los resultados para encontrar las coincidencias más probables usando RRF. En el prototipo, los dos primeros resultados se convierten en posibles coincidencias que pueden enviarse para la evaluación del LLM.

¿Por qué una evaluación del LLM? Las evaluaciones y explicaciones del LLM permiten que nuestro sistema maneje la ambigüedad y el contexto de manera transparente. Esto es vital para casos como "el presidente", que podría referirse a múltiples entidades, dependiendo del contexto, pero también hace que cosas como los apodos y las variaciones culturales funcionen bien en el sistema. Por último, cuando consideramos tareas de misión crítica, como identificar entidades de listas de sanciones, necesitamos saber por qué se aceptó una coincidencia para poder confiar en el sistema. Fundamentalmente, el LLM no busca en todo el corpus; evalúa solo el pequeño conjunto de candidatos devuelto por Elasticsearch.

Resultados del mundo real: Coincidencia con el razonamiento del LLM

Un gran desafío para cualquier tarea de procesamiento de lenguaje natural es la creación de un documento de referencia, una "clave de respuestas" que nos dice cuáles son los resultados previstos. Sin esto, es casi imposible evaluar el rendimiento de un sistema en una tarea, pero crear un documento de este tipo puede ser un proceso laborioso. Para el prototipo de resolución de entidades, volvimos a recurrir a la GenAI para ayudar a configurar datos contra los que pudiéramos probar.

Primero definimos varios tipos de desafíos, como apodos y transliteraciones, y luego pedimos al LLM que creara una colección escalonada de sets de datos que se hiciera progresivamente más grande y desafiante para el sistema. La creación de los sets de datos fue menos sencilla de lo que cabría esperar. El LLM tenía una fuerte tendencia a "hacer trampa" al hacer demasiado fácil obtener la respuesta correcta. Por ejemplo, uno de los tipos de desafíos se centró en el contexto semántico. Este tipo incluyó cosas como resolver "autor ruso" a "León Tolstói". El LLM colocó incorrectamente "autor ruso", como alias de "León Tolstói", lo que eliminó la necesidad de hacer una búsqueda híbrida para encontrar la coincidencia.

Después de varias refactorizaciones para solucionar problemas como este, teníamos cinco niveles de sets de datos con los que trabajar. Los niveles 1 a 4 eran progresivamente más amplios y presentaban más tipos de desafíos. El Nivel 5 fue el "desafío definitivo" de sets de datos, compuesto por los ejemplos más complicados de todos los tipos de desafíos. Todos los datos de las pruebas están disponibles en el directorio de evaluación exhaustiva.

Para evaluar nuestro enfoque de resolución de entidades basado en indicaciones, centramos nuestra atención en los sets de datos de nivel 4. Una nota importante es que la evaluación se hizo como un experimento controlado para que pudiéramos concentrarnos en la calidad de la coincidencia de entidades. Los datos de la lista de vigilancia se enriquecieron previamente con contexto y las entidades se extrajeron del artículo antes de tiempo. Así se garantizó que la evaluación se centrara en la coincidencia y no en la precisión de la extracción. Esto aísla la calidad de la coincidencia; el rendimiento de extremo a extremo dependería adicionalmente de la recuperación de la extracción y la calidad del enriquecimiento.

Sets de datos de evaluación

El set de datos de evaluación de nivel 4 proporciona una prueba integral de las capacidades del sistema:[1]

• Entidades de la lista de vigilancia: 66 entidades de diversos tipos (personas, organizaciones, ubicaciones).

• Artículos de prueba: 69 artículos que abarcan casos de resolución de entidades del mundo real.

• Coincidencias esperadas: 206 coincidencias de entidades esperadas en todos los artículos.

• Tipos de desafíos: 15 tipos diferentes de desafíos que evalúan varios aspectos de la resolución de entidades.

Los tipos de desafíos incluidos en los sets de datos son:

• Apodos: "Bob Smith" → "Robert Smith" (siete artículos).

• Títulos y honoríficos: "Dr. Sarah Williams" → "Sarah Williams" (cinco artículos).

• Contexto semántico: "Autor ruso" → "León Tolstói" (ocho artículos).

• Nombres multilingües: Manejo de nombres en diferentes escrituras (seis artículos).

• Entidades comerciales: Variaciones del nombre corporativo (siete artículos).

• Referencias ejecutivas: "CEO de Microsoft" → "Satya Nadella" (cinco artículos).

• Líderes políticos: Referencias basadas en títulos (cinco artículos).

• Iniciales: "J. Smith " → "John Smith" (tres artículos).

• Variaciones en el orden de los nombres: Diferentes convenciones de ordenamiento de nombres (tres artículos).

• Nombres truncados: Coincidencias parciales de nombres (tres artículos).

• División de nombres: Nombres divididos en el texto (tres artículos).

• Espacios/guiones faltantes: Variaciones de formato (dos artículos).

• Transliteración: Coincidencia de nombres entre sistemas de escritura (dos artículos).

• Desafíos combinados: Varios desafíos en un artículo (seis artículos).

• Negocios complejos: Relaciones comerciales jerárquicas (cinco artículos).

Veamos cómo se desempeñó la resolución de entidades basada en indicaciones.

Rendimiento general

Los resultados muestran que la evaluación de coincidencias basada en LLM es muy prometedora, pero también revelan un importante problema de confiabilidad. Debido a que cada par de candidatos debe ser evaluado por el LLM, las fallas en la salida estructurada pueden suprimir la aceptación y la recuperación incluso cuando la recuperación está funcionando bien.

Métrica

Valor

Precisión

83.8 %

Recuperación

62.6 %

Puntuación F1

71,7%

Total de coincidencias encontradas

344

Tasa de aceptación de LLM

44,8%

Tasa de error

30.2%

El problema de la tasa de error

Recuerda que el primer paso que damos en el prototipo es crear posibles pares de coincidencia usando Elasticsearch. Cada una de estas posibles coincidencias necesita ser evaluada por el LLM. Para procesar eficientemente todas esas coincidencias, agrupamos las llamadas a los LLM en batches. Esto reduce los costos y la latencia de la API, pero también aumenta el riesgo de obtener JSON malformado en la salida. A medida que aumenta el tamaño del batch, el JSON se vuelve más largo y complejo, lo que aumenta la probabilidad de que el LLM genere un JSON no válido. De aquí proviene la tasa de error del 30 %. En la evaluación, usamos un tamaño de batch de cinco coincidencias por solicitud. Incluso con este tamaño de batch conservador, seguimos viendo fallos en el análisis de JSON, lo que distorsiona significativamente los resultados de la evaluación.

Lo que sigue: Optimización de la integración del LLM

Ahora que hemos emparejado entidades usando la búsqueda semántica y la evaluación a cargo del LLM, tenemos un pipeline completo de resolución de entidades. Sin embargo, este enfoque introduce un nuevo modo de fallo cuando la evaluación del modelo es correcta, pero su salida no es utilizable. Podemos optimizar la integración de los LLM para mejorar la fiabilidad y la eficiencia de costos. En la próxima publicación, analizaremos cómo usar la llamada de funciones para una salida estructurada, que proporciona una estructura y seguridad de tipo garantizadas a la vez que reduce errores y costos.

Pruébalo tú mismo

¿Quieres ver la coincidencia de entidades en acción? Mira el cuaderno de Entity Matching para obtener una guía completa con implementaciones reales, explicaciones detalladas y ejemplos prácticos. El cuaderno te muestra exactamente cómo hacer coincidir entidades empleando la búsqueda de tres pasos, la búsqueda híbrida con RRF y la evaluación impulsada por LLM con razonamiento.

Recuerda: Este es un prototipo didáctico diseñado para enseñar los conceptos. Al construir sistemas de producción, considera factores adicionales, como la selección del modelo, la optimización de costos, los requisitos de latencia, la validación de calidad, el manejo de errores y la monitorización, que no están cubiertos en este prototipo orientado al aprendizaje.

Notas

1. Estos sets de datos son sintéticos y están diseñados con fines didácticos; se aproximan a desafíos reales pero no son representativos de ningún dominio de producción específico.

En este artículo, aprenderás cómo puedes utilizar el parámetro de puntuación mínima para aumentar la precisión de tus resultados de búsqueda semántica. Si deseas probar los ejemplos en esta publicación de blog, ve al cuaderno de Jupyter asociado.

Antecedentes: Precisión y recuperación

En la búsqueda, la relevancia, la precisión y la recuperación son conceptos clave. Se recomienda encarecidamente a todo lector que no esté familiarizado que se interiorice sobre estos conceptos. A continuación se presenta un resumen.

• Precisión: La fracción de resultados de búsqueda devueltos que son relevantes para el usuario.

• Recuerda: La fracción de todos los documentos relevantes del corpus que se incluyen en el conjunto de resultados de búsqueda.

O, en otras palabras, la precisión está devolviendo solo resultados relevantes; y la recuperación está devolviendo todos los resultados relevantes. Como puedes imaginar, estos son, a menudo, requisitos contradictorios. La búsqueda semántica tiende a tener una recuperación muy alta, pero puede tener dificultades con la precisión. Continúa leyendo para saber cómo moverte por esta propiedad.

Introducción del parámetro de puntaje mínimo

El parámetro "min_score" nos permite mejorar la precisión al establecer una puntuación mínima, lo que truncará el conjunto de resultados y eliminará cualquier coincidencia con una puntuación inferior al umbral definido. A continuación se muestra un ejemplo sencillo:

Normalizando la puntuación.

Establecer una puntuación mínima está bien; sin embargo, no todos los modelos semánticos devuelven una puntuación adecuada para un umbral estático. ELSER, por ejemplo, devuelve una puntuación que no tiene límite. Algunas puntuaciones de un modelo denso están estrechamente agrupadas y solo tienen sentido en el contexto de la consulta específica.

Para la mayoría de los casos de búsqueda semántica, recomendamos usar un enfoque de normalización antes de aplicar el "min_score". La normalización garantiza que la puntuación del documento esté dentro de un intervalo definido. Elasticsearch ofrece dos normalizadores, "l2_norm" y "minmax". El más comúnmente usado es "minmax", ya que es fácil de entender y funciona bien en muchos escenarios. Las propiedades clave de "minmax" incluyen:

• Las puntuaciones de los documentos se distribuyen entre 0 y 1.

• El documento con la puntuación más alta siempre tiene una puntuación de 1.

• El documento con la puntuación más baja siempre tiene una puntuación de 0.

  • Esto puede hacer que sea menos adecuado para la búsqueda por palabras clave. Consulta la sección “Búsqueda híbrida” para más información.

A continuación se muestra un ejemplo de una consulta semántica normalizada con min_score. El tamaño de la ventana de clasificación se ha aumentado a 500 para permitirnos devolver una lista más larga de resultados de búsqueda, comenzando en 100.

El tamaño se ha establecido en un valor más alto de lo que normalmente se ve en producción. Esto es para que podamos inspeccionar la calidad de los resultados de búsqueda y ajustar los resultados.

Búsqueda híbrida usando el retriever lineal

Para la búsqueda híbrida, el enfoque más sencillo es normalizar todos las puntuaciones, asignar ponderaciones y aplicar una puntuación mínima. Ten en cuenta que al elegir ponderaciones con una suma de 1, mantienes la puntuación total dentro de un rango de 0–1. Esto hace que sea más fácil entender las puntuaciones finales y afinar min_score. A continuación se muestra un ejemplo:

Búsqueda híbrida usando RRF.

Con BM25, a menudo controlamos la precisión por otros medios, usando, por ejemplo, el operador de AND o minimum_should_match. Además, las consultas que consisten en términos únicos, precisos y poco frecuentes naturalmente generarán resultados con pocos resultados de búsqueda, a menudo todos muy relevantes. Esto puede llevar a:

• Los resultados más lejanos en el resultado reciben una puntuación normalizada baja en el recuperador BM25, incluso si la puntuación absoluta de BM25 está cerca de las puntuaciones más altas.

• Al agregar una puntuación BM25 muy baja a la puntuación semántica, el total puede aproximarse a la puntuación semántica.

• La falta de contribución de la puntuación BM25 puede hacer que el documento sea descartado por el min_score threshold.

Como solución, podemos utilizar la fusión de rangos recíprocos (RRF) para combinar BM25 y los resultados semánticos. RRF consigue sortear el desafío de comparar puntuaciones de diferentes algoritmos de búsqueda al colocar el foco en la posición en cada conjunto de resultados. En este escenario, la min_score solo se aplica al recuperador semántico.

Conclusión

Al usar min_score, hemos demostrado cómo podemos reducir el número de falsos positivos en nuestros conjuntos de resultados causados por la alta recuperación de algoritmos de búsqueda semántica. Para saber más sobre los recuperadores, consulta esta publicación de blog y la documentación de Elasticsearch.

Los conectores personalizados te permiten combinar tus conectores de ChatGPT existentes con otras fuentes de datos como Elasticsearch para obtener respuestas integrales.

En este artículo, crearemos un servidor MCP que conecta ChatGPT a un índice de Elasticsearch que contiene información sobre incidencias internas de GitHub y solicitudes de extracción. Esto permite responder a búsquedas en lenguaje natural mediante los datos de Elasticsearch.

Desplegaremos el servidor MCP utilizando FastMCP en Google Colab con ngrok para obtener una URL pública a la que ChatGPT pueda conectarse, lo que eliminará la necesidad de una infraestructura compleja.

Para una visión general del MCP y su ecosistema, consulta El estado actual de MCP.

Prerrequisitos

Antes de comenzar, necesitarás:

• Clúster de Elasticsearch (8.X o superior).

• Clave API de Elasticsearch con acceso de lectura a tu índice.

• Cuenta de Google (para Google Colab)

• Cuenta de Ngrok (el nivel gratuito funciona)

• Cuenta de ChatGPT con plan Pro/Enterprise/Business o Edu.

Comprensión de los requisitos del conector MCP de ChatGPT.

Los conectores MCP de ChatGPT requieren la implementación de dos herramientas: search y fetch. Para más detalles, consulta OpenAI Docs.

Herramienta de búsqueda

Devuelve una lista de resultados relevantes de tu índice de Elasticsearch según la búsqueda del usuario.

Lo que recibe:

• Un solo texto con la búsqueda de lenguaje natural del usuario.

• Ejemplo: “Encuentra incidencias relacionadas con la migración de Elasticsearch”.

Lo que devuelve: 

• Un objeto con una clave result que contiene un arreglo de objetos de resultado. Cada resultado incluye:

  • id - Identificador único de documentos.

  • title - Título de la incidencia o PR.

  • url - Enlace a la incidencia o PR.

En nuestra implementación:

Herramienta de extracción

Recupera el contenido completo de un documento específico.

Lo que recibe:

• Una sola cadena de texto con el ID del documento de Elasticsearch del resultado de la búsqueda.

• Ejemplo: “Consígueme los detalles de PR-578”.

Lo que devuelve:

• Un objeto de documento completo con:

  • id - Identificador único de documentos.

  • title - Título de la incidencia o PR.

  • text - Descripción completa del problema/PR y sus detalles

  • url - Enlace a la incidencia o PR.

  • type - Tipo de documento (incidencia, pull_request).

  • status - Estado actual (abierto, en progreso, resuelto)

  • priority - Nivel de prioridad (bajo, medio, alto, crítico)

  • assignee - Persona asignada al problema/PR

  • created_date - Fecha de creación.

  • resolved_date - Cuando se resolvió (si procede)

  • labels - Etiquetas asociadas al documento

  • related_pr - ID de solicitud de extracción relacionado

Nota: Este ejemplo usa una estructura plana donde todos los campos están en el nivel raíz. Los requisitos de OpenAI son flexibles y también admiten objetos de metadatos anidados.

Sets de datos de incidencias y PR de GitHub

Para este tutorial, vamos a usar un set de datos interno de GitHub que contenga incidencias y solicitudes de extracción. Esto representa un escenario en el que deseas buscar datos internos privados a través de ChatGPT.

Los sets de datos se pueden encontrar aquí. Y actualizaremos el índice de los datos mediante la API de bulk.

Este sets de datos incluye:

• Problemas con descripciones, estado, prioridad y responsables.

• Solicitudes de extracción con cambios de código, revisiones e información de despliegue.

• Relaciones entre incidencias y PR (p. ej., PR-578 soluciona ISSUE-1889).

• Etiquetas, fechas y otros metadatos

Mappings de índices

El índice utiliza los siguientes mappings para brindar soporte a la búsqueda híbrida con ELSER. El campo text_semantic se utiliza para la búsqueda semántica, mientras que los demás campos permiten la búsqueda por palabras clave.

Construye el servidor MCP

Nuestro servidor MCP implementa dos herramientas que siguen las especificaciones de OpenAI, y utilizan búsquedas híbridas para combinar coincidencia semántica y textual para obtener mejores resultados.

Herramienta de búsqueda

Usa la búsqueda híbrida con RRF (Fusión de Rango Recíproco), combinando la búsqueda semántica con la coincidencia de texto:

Puntos clave:

• Búsqueda híbrida con RRF: Combina búsqueda semántica (ELSER) y búsqueda por texto (BM25) para mejores resultados.

• Búsqueda de múltiples coincidencias: Busca en múltiples campos con mejores ponderaciones (título^3, texto^2, responsable^2). El símbolo de intercalación (^) multiplica las puntuaciones de relevancia, y prioriza las coincidencias en los títulos sobre el contenido.

• Correspondencia aproximada: fuzziness: AUTO maneja los errores tipográficos y ortográficos al permitir coincidencias aproximadas.

• Ajuste de parámetros de RRF:

  • rank_window_size: 50 - Especifica cuántos resultados principales de cada recuperador (semántico y textual) se consideran antes de combinarlos.

  • rank_constant: 60 - Este valor determina cuánta influencia tienen los documentos en los conjuntos de resultados individuales sobre el resultado final clasificado.

• Solo devuelve los campos obligatorios: id, title, url según la especificación de OpenAI, y evita exponer otros campos innecesariamente.

Herramienta de extracción

Recupera los detalles del documento por ID de documento, si existe:

Puntos clave:

• Búsqueda por campo de ID de documento: usa la búsqueda de término en el campo personalizado id.

• Devuelve el documento completo: incluye el campo completo text con todo el contenido.

• Estructura plana: todos los campos en el nivel raíz, coincidiendo con la estructura de documentos de Elasticsearch.

Desplegar en Google Colab

Usaremos Google Colab para ejecutar nuestro servidor MCP y ngrok para exponerlo públicamente de forma tal que ChatGPT pueda conectarse.

Paso 1: Abre el cuaderno de Google Colab.

Accede a nuestro cuaderno preconfigurado Elasticsearch MCP para ChatGPT.

Paso 2: Configura tus credenciales

Necesitarás tres datos:

• URL de Elasticsearch: Tu URL del cluster de Elasticsearch.

• Clave API de Elasticsearch: Clave API con acceso de lectura a tu índice.

• Token de autenticación ngrok: Token gratis de ngrok. Usaremos ngrok para exponer la URL de MCP a internet y así ChatGPT pueda conectarse.

Obtener tu token ngrok

1. Regístrate para una cuenta gratis en ngrok

2. Ve a tu dashboard de ngrok

3. Copia tu token de autenticación

Agregar secretos a Google Colab

En el cuaderno de Google Colab:

1. Haz clic en el icono de llave en la barra lateral izquierda para abrir Secretos.

2. Añade estos tres secretos:

3. Habilitar el acceso al cuaderno para cada secreto

Paso 3: Ejecutar el cuaderno

1. Haz clic en Tiempo de ejecución y, a continuación, en Ejecutar todo para ejecutar todas las celdas.

2. Espera que el servidor se inicie (aproximadamente 30 segundos).

3. Busque la salida que muestre su URL pública de ngrok

4. La salida mostrará algo como:

Conéctate a ChatGPT.

Ahora conectaremos el servidor MCP a tu cuenta de ChatGPT.

1. Abre ChatGPT y ve a Configuración.

2. Navega a Conectores.Si estás usando una cuenta Pro, debes activar el modo de desarrollador en los conectores.

Si estás usando la versión Enterprise o Business de ChatGPT, debes publicar el conector en tu lugar de trabajo.

3. Haz clic en Crear.

Nota: En los espacios de trabajo Business, Enterprise y Edu, solo los propietarios, administradores y usuarios que tengan habilitada la correspondiente configuración (para Enterprise/Edu) pueden agregar conectores personalizados. Los usuarios con un rol de miembro común no tienen la capacidad de agregar conectores personalizados por su cuenta.

Una vez que un propietario o usuario administrador agrega un conector y lo habilita, estará disponible para que lo usen todos los miembros del espacio de trabajo.

4. Introduce la información requerida y la URL de tu ngrok que termina en /sse/. Recuerda la “/” después de “sse”. No funcionará si no la agregas:

• Nombre: Elasticsearch MCP

• Descripción: MCP personalizado para buscar y extraer información interna de GitHub.

5. Presione Crear para guardar el MCP personalizado.

La conexión es instantánea si tu servidor está en funcionamiento. No se necesita ninguna otra autenticación, ya que la clave API de Elasticsearch está configurada en tu servidor.

Prueba el servidor MCP

Antes de hacer preguntas, necesitas seleccionar qué conector ChatGPT debe usar.

Indicación 1: Buscar incidencias

Pregunta: “Encuentre incidencias relacionadas con la migración de Elasticsearch” y confirma la llamada a la herramienta de acciones.

ChatGPT llamará a la herramienta search con tu búsqueda. Puedes ver que está buscando herramientas disponibles y preparándose para llamar a la herramienta Elasticsearch y confirma con el usuario antes de tomar cualquier acción en relación con la herramienta.

Solicitud de llamada a la herramienta:

Respuesta de la herramienta:

ChatGPT procesa los resultados y los presenta en un formato natural y conocido.

Entre bastidores

Indicación: “Busca incidencias relacionadas con la migración de Elasticsearch”

1. Llamadas de ChatGPT search(“Elasticsearch migration”)

2. Elasticsearch realiza una búsqueda híbrida

• La búsqueda semántica entiende conceptos como “actualización” y “compatibilidad de versiones”.

• La búsqueda de texto encuentra coincidencias exactas de "Elasticsearch" y "migración".

• RRF combina y clasifica los resultados de ambos enfoques

3. Devuelve los 10 mejores eventos que coinciden con id, title, url

4. ChatGPT identifica “ISSUE-1712: migrar de Elasticsearch 7.x a 8.x” como el resultado más relevante.

Indicación 2: Obtén los detalles completos

Pregunta: “Obtén detalles de ISSUE-1889”

ChatGPT reconoce que deseas información detallada sobre una incidencia específica, llama a la herramienta fetch y confirma con el usuario antes de tomar cualquier acción con la herramienta.

Solicitud de llamada a la herramienta:

Respuesta de la herramienta:

ChatGPT sintetiza la información y la presenta de manera clara.

Entre bastidores

Indicación: «Obtén los detalles de ISSUE-1889»

1. Llamadas de ChatGPT fetch(“ISSUE-1889”)

2. Elasticsearch recupera el documento completo

3. Devuelve un documento completo con todos los campos a nivel raíz.

4. ChatGPT sintetiza la información y responde con citas adecuadas.

Conclusión

En este artículo, creamos un servidor MCP personalizado que conecta ChatGPT a Elasticsearch con herramientas MCP dedicadas de búsqueda y extracción, lo cual permite realizar búsquedas en lenguaje natural sobre datos privados.

Este patrón MCP funciona para cualquier índice, documentación, productos, logs o cualquier otro dato de Elasticsearch que quieras buscar mediante lenguaje natural.

El problema del rango de puntaje

Para contextualizar, repasemos una de las principales razones por las que la búsqueda híbrida puede ser difícil: los rangos de puntaje variables. Nuestro viejo amigo BM25 produce puntajes ilimitados. En otras palabras, BM25 puede generar puntajes que van desde cerca de 0 hasta (teóricamente) infinitas. En cambio, las consultas contra dense_vector campos producirán puntajes acotados entre 0 y 1. Para empeorar este problema, semantic_text ofusca el tipo de campo empleado para indexar incrustaciones, así que a menos que tengas un conocimiento detallado sobre tu configuración de índices y endpoints de inferencia, puede ser difícil saber cuál será el rango de puntaje de tu consulta. Esto presenta un problema al intentar entrecalar resultados de búsqueda léxica y semántica, ya que los resultados léxicos pueden tener prioridad sobre los semánticos incluso si los resultados semánticos son más relevantes. La solución generalmente aceptada para este problema es normalizar los puntajes antes de entrelazar los resultados. Elasticsearch dispone de dos herramientas para esto: los retrievers lineales y RRF .

El recuperador RRF aplica el algoritmo RRF, usando el rango del documento como medida de relevancia y descartando el puntaje. Como el puntaje no se tiene en cuenta, las discrepancias en el rango de puntaje no son un problema.

El retriever lineal emplea una combinación lineal para determinar el puntaje final de un documento. Esto implica tomar el puntaje de cada consulta componente para el documento, normalizarla y sumarla para generar el puntaje total. Matemáticamente, la operación puede expresar como:

Donde N es la función de normalización, y SX es el puntaje para la consulta X. La función de normalización es clave aquí, ya que transforma el puntaje de cada consulta para usar el mismo rango. Puedes aprender más sobre el retriever lineal aquí.

Desglosándolo

Los usuarios pueden implementar una búsqueda híbrida eficaz con estas herramientas, pero requiere cierto conocimiento sobre tu índice. Veamos un ejemplo con el retriever lineal, donde consultaremos un índice con dos campos:

1. semantic_text_field es un campo semantic_text que emplea E5, un modelo de incrustación de texto

2. text_field es un campo estándar de text

1. Usamos una consulta match en nuestro campo semantic_text , para la que agregamos soporte en Elasticsearch 8.18/9.0

Al construir la consulta, debemos tener en cuenta que semantic_text_field emplea un modelo de incrustación de texto, por lo que cualquier consulta generará un puntaje entre 0 y 1. También necesitamos saber que text_field es un campo de text estándar y, por tanto, las consultas sobre él generarán un puntaje no acotada. Para crear un conjunto de resultados con la relevancia adecuada, necesitamos usar un retriever que normalice los puntajes de consulta antes de combinarlas. En este ejemplo, usamos el retriever lineal con minmax normalización, que normaliza el puntaje de cada consulta a un valor entre 0 y 1.

La construcción de la consulta en este ejemplo es bastante sencilla porque solo están involucrados dos campos. Sin embargo, puede complicar muy rápido a medida que se agregan más campos, y de diferentes tipos. Esto demuestra cómo escribir una consulta híbrida eficaz suele requerir un conocimiento más profundo del índice que se consulta, de modo que los puntajes de los componentes se normalicen correctamente antes de la combinación. Esto supone una barrera para la adopción más amplia de la búsqueda híbrida.

Agrupación de consultas

Ampliemos el ejemplo: ¿Y si quisiéramos consultar un campo text y dos campos semantic_text ? Podríamos construir una consulta así:

Eso parece bueno a simple vista, pero hay un posible problema. Ahora los semantic_text partidos de campo representan dos tercios del total del puntaje:

Probablemente esto no es lo que buscas porque crea un puntaje desequilibrado. Los efectos pueden no ser tan evidentes en un ejemplo como este con solo 3 campos, pero se vuelve problemático cuando se consultan más campos. Por ejemplo, la mayoría de los índices contienen muchos más cuerpos léxicos que la semántica (es decir, dense_vector, sparse_vector, o semantic_text). ¿Y si consultáramos un índice con 9 campos léxicos y 1 campo semántico usando el patrón anterior? Las coincidencias léxicas representarían el 90% del puntaje, lo que reduce la efectividad de la búsqueda semántica.

Una forma común de abordar esto es agrupar las consultas en categorías léxicas y semánticas y ponderar ambas de forma uniforme. Esto impide que cualquiera de las dos categorías domine el puntaje total.

Pongámoslo en práctica. ¿Cómo sería este enfoque de consultas agrupadas en este ejemplo al usar el retriever lineal?

¡Vaya, esto se está poniendo muy extenso! ¡Puede que incluso tuviste que desplazarte arriba y abajo varias veces para revisar toda la consulta! Aquí, usamos dos niveles de normalización para crear los grupos de consultas. Matemáticamente, puede expresar como:

Este segundo nivel de normalización garantiza que las consultas contra los campos semantic_text y text campo tengan un peso uniforme. Ten en cuenta que en este ejemplo omitimos la normalización de segundo nivel para text_field ya que solo hay un cuerpo léxico, lo que te ahorra aún más verbosidad.

Esta estructura de consulta ya es engorrosa y solo estamos consultando tres campos. Se vuelve cada vez más inmanejable, incluso para los profesionales experimentados en búsqueda, a medida que consultas más campos.

El formato de consulta multicampo

Agregamos el formato de consulta multicampo para los retrievers lineales y RRF en Elasticsearch 8.19, 9.1 y serverless para simplificar todo esto. Ahora puedes realizar la misma consulta que antes con simplemente:

¡Lo que reduce la consulta de 55 líneas a solo 9! Elasticsearch emplea automáticamente los mapeos de índice para:

• Determinar el tipo de cada campo consultado

• Agrupa cada cuerpo en una categoría léxica o semántica

• Pondera cada categoría de forma equitativa en el puntaje final

Esto permite a cualquiera ejecutar una consulta híbrida eficaz sin necesidad de conocer detalles sobre el índice o los endpoints de inferencia empleados.

Al usar RRF, puedes omitir la normalizer, ya que rango se usa como indicador de relevancia:

Impulso por campo

Al usar el retriever lineal, puedes aplicar un aumento por campo para ajustar la importancia de los combates en ciertos campos. Por ejemplo, supongamos que consultas cuatro campos: dos campos semantic_text y dos campos text :

Por defecto, cada cuerpo tiene un peso igual en su grupo (léxico o semántico). El desglose del puntaje es el siguiente:

En otras palabras, cada campo representa el 25% del puntaje total.

Podemos usar la sintaxis field^boost para agregar un impulso por campo a cualquier campo. Vamos a aplicar un aumento de 2 a semantic_text_field_1 y text_field_1:

Ahora el desglose del puntaje es así:

Cada grupo de consulta sigue teniendo un peso igual, pero ahora el peso del campo dentro de los grupos cambió:

• semantic_text_field_1 es el 66% del puntaje del grupo de consultas semánticas, 33% del puntaje total

• text_field_1 es el 66% del puntaje del grupo de consultas léxicas, 33% del puntaje total

i️ Ten en cuenta que el rango total de puntaje no cambiará cuando se aplica un aumento por campo. Este es un efecto secundario previsto de la normalización de puntajes, que garantiza que los puntajes de consulta léxica y semántica sigan siendo directamente comparables entre sí.

i️ El aumento por campo también puede usar con el recuperador RRF en Elasticsearch 9.2+

Resolución comodín

Puedes usar el comodín * en el parámetro fields para que coincida con varios campos. Continuando con el ejemplo anterior, esta consulta es funcionalmente equivalente a consultar semantic_text_field_1, semantic_text_field_2, y text_field_1 explícitamente:

Es interesante notar que el patrón de *_field_1 coincide tanto con text_field_1 como con semantic_text_field_1. Esto se gestiona automáticamente; La consulta se ejecutará como si cada uno de los campos fuera consultado explícitamente. También está bien que el semantic_text_field_1 coincida con ambos patrones; Todas las coincidencias de nombres de campo se deduplican antes de la ejecución de la consulta.

Puedes usar el comodín de varias maneras:

• Coincidencia de prefijos (ej: *_text_field)

• Emparejamiento en línea (ej: semantic_*_field)

• Coincidencia de sufijos (ej: semantic_text_field_*)

También puedes usar varios comodines para aplicar una combinación de lo anterior, como *_text_field_*.

Campos de consulta predeterminados

El formato de consulta multicampo también te permite consultar un índice del que no sabes nada. Si omites el parámetro fields , consultará todos los campos especificados por la configuración de índice index.query.default_field:

Por defecto, index.query.default_field está configurado como *. Este comodín se resolverá a todos los tipos de campo del índice que admitan consultas de término, que es la mayoría. Las excepciones son:

• dense_vector Campos

• rank_vector Campos

• Campos geométricos: geo_point, shape

Esta funcionalidad es especialmente útil cuando se quiere realizar una consulta de búsqueda híbrida sobre un índice proporcionado por un tercero. El formato de consulta multicampo permite ejecutar una consulta adecuada de forma sencilla. Simplemente excluye el parámetro fields y se consultarán todos los campos aplicables.

Conclusión

El problema del rango de puntaje puede hacer que la búsqueda híbrida efectiva sea un dolor de cabeza de implementar, especialmente cuando hay poca comprensión del índice que se consulta o de los endpoints de inferencia empleados. El formato de consulta multicampo para los retrievers lineales y RRF alivia este problema al empaquetar un enfoque automatizado de búsqueda híbrida basado en agrupación de consultas en una API simple y accesible. Funcionalidades adicionales, como el aumento por campo, la resolución de comodines y los campos de consulta por defecto, amplían la funcionalidad para cubrir muchos casos de uso.

Prueba hoy el formato de consulta multicampo

Puedes consultar los retrievers lineales y RRF con el formato de consulta multicampo en proyectos Serverless totalmente gestionados de Elasticsearch con una prueba gratis. También está disponible en versiones de pila a partir de la 8.19 y 9.1.

Empieza en minutos en tu entorno local con un solo comando:

La búsqueda no está muerta, solo se movió

Así que tuvimos este cambio de buscar principalmente contexto a través de un cuadro de texto y usar la información (el contexto) que devuelven para construir las respuestas nosotros mismos, a ahora usar lenguaje natural para decirle a un agente lo que queremos y dejar que él investigue y compile automáticamente la respuesta por nosotros. Muchos en el mundo tecnológico señalan este cambio y proclaman que "la búsqueda está muerta" (bueno, el mundo del SEO y las palabras publicitarias definitivamente está cambiando: ¿ alguien quiere GEO ?), pero la búsqueda sigue siendo absolutamente crítica para las operaciones agenticas — solo que ahora se realiza en gran medida fuera de la vista a través de las herramientas.

Anteriormente, los humanos eran los principales árbitros de relevancia subjetiva: cada usuario tiene sus propios motivos para realizar la búsqueda, y su experiencia personal influye en la precisión relativa de los resultados. Si queremos confiar en que los agentes pueden llegar a la misma conclusión (o mejor) que nosotros, debemos cerciorarnos de que la información contextual a la que tienen acceso esté lo más cerca posible de nuestra intención subjetiva. ¡Tenemos que diseñar el contexto que proporcionamos a los LLMs para ese objetivo!

Generación de contexto con recuperación de búsqueda híbrida

Solo un recordatorio de la Parte I de que la búsqueda híbrida de Elastic combina las fortalezas de la búsqueda tradicional basada en palabras clave (flexibilidad sintaxis, precisión de palabras clave y puntaje de relevancia) con la comprensión semántica de la búsqueda por similitud vectorial, y ofrece múltiples técnicas de reclasificación. Esta sinergia (¡nunca se encontró un uso más verdadero de esa palabra!) Permite resultados muy relevantes, con consultas que pueden ser mucho más matizadas en cómo dirigen el contenido. No es solo que puedas aplicar la relevancia subjetiva como una de tus etapas de recuperación; En realidad, la recuperación de la primera etapa puede incluir puntaje de relevancia junto con todos esos otros modos a la vez.

Precisión y eficiencia superiores

Emplear una plataforma de datos que pueda ofrecer búsqueda, recuperación y reclasificación distribuidas como tu principal motor de recuperación de contexto tiene mucho sentido. Puedes usar sintaxis avanzada de consulta para agregar el componente que falta de la intención subjetiva y filtrar contenido que pueda distraer o enturbiar el valor de la información contextual devuelta. Puedes seleccionar cualquiera de las opciones sintácticas individuales disponibles, o combinar modalidades en una única búsqueda que se dirija a cada tipo de datos de la manera que mejor entienda, y luego combinarlas o reordenarlas con el reclasificamiento. Puedes filtrar la respuesta para incluir solo los campos/valores que quieres, manteniendo a distancia los datos superfluos. En servicio de los agentes, esa flexibilidad de segmentación te permite construir herramientas extremadamente precisas en cómo recuperan el contexto.

Refinamiento del contexto (agregaciones y señales no de contenido)

Las agregaciones pueden ser especialmente útiles para moldear el contenido que una herramienta entrega a la ventana de contexto. Las agregaciones proporcionan naturalmente datos numéricos sobre la forma de los datos contextuales devueltos, lo que facilita y hace más preciso que los LLMs razonen. Como las agregaciones pueden anidar jerárquicamente, es una forma sencilla de agregar detalles multinivel para que el LLM genere una comprensión más matizada. Las agregaciones también pueden ayudar a gestionar el tamaño de la ventana de contexto — puedes reducir fácilmente un resultado de consulta de 100k documentos a unos pocos cientos de tokens de insights agregados.

Las señales no relacionadas con el contenido son los indicadores inherentes a tus datos que te muestran una visión general de lo que estás viendo; Son las características adicionales de los resultados, como popularidad, frescura, geolocalización, categorías, diversidad de anfitriones o bandas de precios. Estos datos pueden ser útiles para informar al agente sobre cómo valora la importancia del contexto que recibió. Algunos ejemplos sencillos podrían ayudar a ilustrar esto mejor:

• Potenciar contenido publicado recientemente y popular - Imagina que tienes una base de conocimientos de artículos. Quieres encontrar artículos relevantes para la consulta de un usuario, pero también potenciar artículos que sean recientes y que fueron útiles por otros usuarios (por ejemplo, que tengan un alto número de "me gusta"). En este escenario, podemos usar una búsqueda híbrida para encontrar artículos relevantes y luego reclasificarlos en función de una combinación de su fecha de publicación y popularidad.

• Búsqueda de comercio electrónico con ajustes de ventas y stock - En un entorno de comercio electrónico, quieres mostrar a los clientes productos que coincidan con su término de búsqueda, pero también quieres promocionar productos que se venden bien y estén en stock. También podrías bajar el rango de productos con poco stock para evitar frustraciones del cliente.

• Priorizar los problemas de alta gravedad en un rastreador de errores : para un equipo de desarrollo de software, al buscar problemas, es fundamental destacar primero los problemas de alta gravedad, alta prioridad y actualizados recientemente. Puedes usar no señales como 'criticidad' y 'más debatido' para sopesar diferentes factores de forma independiente, cerciorando que los temas más críticos y debatidos salgan a la superficie

Estas consultas de ejemplo y más se pueden encontrar en la página de contenido de Elasticsearch Labs que la acompaña.

Aplicación de la seguridad

Un beneficio crítico de aprovechar una capa de velocidad basada en búsqueda como Elastic para la ingeniería de contexto es su marco de seguridad integrado. La plataforma de Elastic garantiza que el contexto entregado a las operaciones de IA agente y generativa respete y proteja la información privada sensible mediante un control de acceso basado en roles (RBAC) y un control de acceso basado en atributos (ABAC). Esto significa que no solo las consultas se gestionan con eficiencia, sino que los resultados se filtran según las licencias específicas del agente o del usuario que inicia la solicitud.

Los agentes se ejecutan como el usuario autenticado, por lo que la seguridad se aplica implícitamente a través de las características de seguridad integradas en la plataforma:

• Licencias detalladas: Define el acceso a nivel de documento, campo o incluso término, cerciorando que los agentes de IA solo reciban los datos que están autorizados a ver.

• Control de acceso basado en roles (RBAC): Asignar roles a agentes o usuarios, otorgando acceso a conjuntos de datos o funcionalidades específicas según sus responsabilidades definidas.

• Control de acceso basado en atributos (ABAC): Implementar políticas de acceso dinámicas basadas en los atributos de los datos, del usuario o del entorno, permitiendo una seguridad altamente adaptable y consciente del contexto.

• Seguridad a nivel de documento (DLS) y seguridad a nivel de campo (FLS): Estas capacidades cercioran que, incluso dentro de un documento recuperado, solo sean visibles las partes autorizadas, evitando que se exponga información sensible.

• Integración con la seguridad empresarial: Integra sin problemas con los sistemas de gestión de identidades existentes (como LDAP, SAML, OIDC) para hacer cumplir políticas de seguridad coherentes en toda la organización.

Al integrar estas medidas de seguridad directamente en el mecanismo de recuperación de contexto, Elastic actúa como un guardián seguro, cerciorando que los agentes de IA operen dentro de límites de datos definidos, evitando exposiciones no autorizadas y manteniendo el cumplimiento de las normativas de privacidad de datos. Esto es fundamental para generar confianza en sistemas de IA agente que manejan información confidencial o propietaria.

Como beneficio adicional, al usar una capa unificada de velocidad de datos sobre las fuentes de datos de tu compañía, alivias las cargas inesperadas de consultas ad hoc en esos repositorios que crearían las herramientas agentes. Tienes un único lugar para buscar todo casi en tiempo real, y un lugar para aplicar controles de seguridad y gobernanza.

Herramientas híbridas basadas en búsqueda

Hay algunas características fundamentales (y cada vez van más y más) de la plataforma Elastic que impulsan mucho la búsqueda de la ingeniería de contexto. Lo principal aquí es que la plataforma ofrece multitud de formas de lograr cosas, con la flexibilidad de adaptar, cambiar y ampliar métodos a medida que avanza el ecosistema de IA.

Presentando Agent Builder

Elastic Agent Builder es nuestra primera incursión en el ámbito de herramientas de IA agente diseñadas para comunicar con los datos que ya almacenas en Elastic. Agent Builder ofrece una interfaz de chat que permite a los usuarios crear y gestionar sus propios agentes y herramientas dentro de Kibana. Incluye servidores MCP y A2A integrados, APIs programáticas y un conjunto de herramientas de sistema prediseñadas para consultar y explorar índices de Elasticsearch, así como para generar ES|Consultas QL desde lenguaje natural. Agent Builder te permite crear herramientas personalizadas que dirigen y esculpen los datos contextuales devueltos al agente a través de ES| expresivoSintaxis de consultas QL .

¿Cómo funciona ES|¿Quieres que QL realice búsqueda híbrida, preguntas? La capacidad principal se logra mediante la combinación del tipo de campo semantic_text y los comandos FORK/FUSE (FUSE usa RRF por defecto para fusionar los resultados de cada bifurcación). Aquí tienes un ejemplo sencillo de una búsqueda ficticia de producto:

La cláusula EVAL incluida con cada una de las ramas FORK en el ejemplo anterior no es estrictamente necesaria; Solo se incluye para demostrar cómo se puede rastrear de qué modalidad de búsqueda se devuelve un resultado determinado.

Plantillas de búsqueda

Supongamos que quieres apuntar tus propias herramientas de agencia externa a tu despliegue de Elastic. Y en lugar de ES|QL, quieres usar recuperadores multietapa o reutilizar la sintaxis DSL existente que desarrollaste, y también quieres poder controlar las entradas que acepta la consulta, la sintaxis usada para ejecutar la búsqueda y los campos devueltos en la salida. Las plantillas de búsqueda permiten a los usuarios definir estructuras predefinidas para patrones de búsqueda comunes, mejorando la eficiencia y la consistencia en la obtención de datos. Esto es especialmente beneficioso para herramientas agentes que interactúan con APIs de búsqueda, ya que ayudan a estandarizar el código estándar y permiten una iteración más rápida de la lógica de búsqueda. Y si alguna vez necesitas ajustar alguno de esos factores, solo actualizas la plantilla de búsqueda y voilà que los cambios se implementan. Si buscas un ejemplo de plantillas de búsqueda en acción con herramientas agentes, echa un vistazo al blog de Elasticsearch Labs 'MCP for intelligent search', que emplea una plantilla de búsqueda detrás de una llamada a herramienta desde un servidor MCP externo.

Flujos de trabajo integrados (¡por la primera vez!)

Una de las cosas más difíciles de navegar en nuestro nuevo mundo de IA agente es la naturaleza no determinista de agentes "razonamientos" semi-autónomos y autodirigidos. La ingeniería de contexto es una disciplina crítica para la IA agentica: son las técnicas que ayudan a reducir las posibles conclusiones que puede generar nuestro agente a lo que sabemos de la verdad fundamental. Incluso con una ventana de contexto altamente precisa y relevante (cuando salimos del ámbito de los hechos numéricos) seguimos faltando esa pequeña garantía de que la respuesta del agente es totalmente repetible y fiable.

Cuando envías la misma solicitud a un agente varias veces, las respuestas pueden ser esencialmente las mismas con solo una pequeña diferencia en la respuesta. Eso suele estar bien para consultas simples, quizá apenas perceptibles, y podemos intentar moldear el resultado con técnicas de ingeniería de contexto. Pero a medida que las tareas que pedimos a nuestros agentes se vuelven más complejas, existe más probabilidad de que una o más de las subtareas introduzcan una variación que cambie ligeramente el resultado final. Probablemente empeorará a medida que empecemos a depender más de las comunicaciones agente a agente, y esas variaciones se acumularán. Esto vuelve a la idea de que las herramientas con las que interactúan nuestros agentes deben ser muy flexibles y ajustables para dirigir con precisión los datos contextuales, y que deben responder en un formato de salida esperado. También indica que, en muchos casos de uso, necesitamos dirigir las interacciones entre agentes y herramientas — ¡aquí es donde entran en juego los flujos de trabajo!

Elastic pronto tendrá flujos de trabajo completamente personalizables integrados en el núcleo de la plataforma. Estos flujos de trabajo podrán operar con agentes y herramientas de forma bidireccional, por lo que los flujos de trabajo podrán llamar a agentes y herramientas, y agentes y herramientas podrán llamar a flujos de trabajo. Tener estas capacidades totalmente integradas en la misma plataforma de IA de búsqueda, donde todos tus datos viven siendo transformadores, ¡el potencial de los flujos de trabajo es extremadamente emocionante! ¡Pronto, muy pronto!

Elastic como banco de memoria unificado

Al ser una plataforma de datos distribuida diseñada para búsquedas casi en tiempo real, Elastic realiza naturalmente las funciones de memoria a largo plazo para sistemas de IA agente. Con la experiencia de chat integrada en Agent Builder, también tenemos seguimiento y gestión de la memoria a corto plazo y el historial de chat. Y dado que toda la plataforma es API-first, es extremadamente fácil emplear Elastic como plataforma para mantener la salida contextual de una herramienta (y poder consultar ella después) que podría saturar la ventana de contexto del agente; Esta técnica a veces se denomina "toma de notas" en círculos de ingeniería contextual.

Tener memoria a corto y largo plazo en la misma plataforma de búsqueda aporta muchos beneficios intrínsecos: imagina poder usar historiales de chat y respuestas contextuales persistentes como parte de los influencers semánticos para futuras interacciones en chat, o para realizar análisis de amenazas, o para crear productos de datos persistentes que se generan automáticamente a partir de llamadas a herramientas repetidas con frecuencia... ¡Las posibilidades son infinitas!

Conclusión

La aparición de grandes modelos de lenguaje cambió la forma en que podemos comparar contenido y los métodos que empleamos para analizar nuestros datos. Nos estamos alejando rápidamente de nuestro mundo actual, donde los humanos realizan la investigación, la consideración contextual y el razonamiento lógico para responder a sus propias preguntas, a uno donde esos pasos están en gran medida automatizados mediante IA agente. Para confiar en las respuestas generadas que recibimos, necesitamos la seguridad de que el agente consideró toda la información más relevante (incluido el factor de relevancia subjetiva) al generar su respuesta. Nuestro método principal para hacer que la IA agente sea fiable es fundamentar las herramientas que recuperan contexto adicional mediante técnicas de RAG e ingeniería contextual, pero cómo esas herramientas realizan la recuperación inicial puede ser crucial para la precisión de la respuesta.

La plataforma Elastic Search AI ofrece la flexibilidad y beneficio de la búsqueda híbrida, junto con varias funciones integradas que ayudan a la IA agente en términos de precisión, rendimiento y escalabilidad; en otras palabras, Elastic es una plataforma fantástica para varios aspectos de la ingeniería de contexto. Al estandarizar la recuperación de contexto a través de una plataforma de búsqueda, simplificamos las operaciones de las herramientas agenticas en varios frentes — y, similar al oxímoron de "ralentizar para ir más rápido", la simplicidad en la capa de generación de contexto significa una IA agente más rápida y fiable.

Como muchos de nosotros, me siento a la vez eufórico y asombrado por el ritmo al que evolucionan las capacidades de la IA. Primero vimos cómo los grandes modelos de lenguaje (LLMs) y la búsqueda vectorial nos lanzaron a la revolución semántica, donde ya no buscábamos ni explorábamos palabras clave para encontrar cosas. Después, los LLMs nos mostraron nuevas formas de interactuar con nuestros datos, usando interfaces de chat para transformar solicitudes en lenguaje natural en respuestas que destilan vastas bases de conocimiento en resúmenes fáciles de consumir. Ya sabemos (¡ya!) tienen los inicios de la lógica automatizada impulsada por LLM en forma de flujos de trabajo de "IA agente" que pueden entender semánticamente una petición entrante, razonar los pasos a seguir y luego elegir entre las herramientas disponibles para ejecutar iterativamente acciones y alcanzar esos objetivos.

La promesa de la IA agente nos está obligando a evolucionar desde el uso principal de 'ingeniería de prompts' para moldear nuestras interacciones generativas con IA, hasta centrarnos en cómo podemos ayudar a las herramientas agenticas a obtener la información adicional más relevante y eficiente que el LLM debe tener en cuenta al generar sus respuestas — la 'ingeniería de contexto' es la próxima frontera. La búsqueda híbrida es, con diferencia, el medio más poderoso y flexible para sacar a la luz el contexto relevante, y la plataforma de Search AI de Elastic abre una nueva vía para aprovechar los datos en servicio de la ingeniería contextual. En este artículo, vamos a hablar de cómo los LLM cambiaron el mundo de la recuperación de información desde dos ángulos, y luego de cómo pueden trabajar juntos para obtener mejores resultados. Hay bastante terreno que cubrir...

Parte I: Cómo cambiaron los LLM la búsqueda

Empecemos desde el ángulo de cómo los LLM cambiaron la forma en que accedemos y recuperamos información.

Nuestro legado léxico

Todos vivimos en el mundo de la búsqueda léxica algo limitado (bastante bien, en la medida de lo posible) durante mucho tiempo. La búsqueda es la primera herramienta a la que recurrimos cuando investigamos o empezamos un nuevo proyecto, y hasta hace poco, nos correspondía formular nuestras consultas de una manera que un motor de búsqueda léxico comprenda. La búsqueda léxica se basa en asociar algún tipo de término de consulta con palabras clave que se encuentran en un corpus documental — independientemente de si el contenido es no estructurado o no estructurado. Para que una búsqueda léxica devuelva un documento como resultado, debe coincidir con esa palabra clave (o tener un vocabulario controlado como una lista de sinónimos o diccionario para establecer la conexión conceptual para nosotros).

Un ejemplo de consulta léxica multi-match

Al menos los motores de búsqueda tienen la capacidad de devolver resultados con un puntaje de relevancia. Los motores de búsqueda ofrecen una gran variedad de opciones de sintaxis de consulta para dirigir eficazmente los datos indexados y algoritmos de relevancia incorporados que puntuan los resultados en función de la intención de la sintaxis de consulta del usuario. Los motores de búsqueda se benefician de décadas de avances en algoritmos de clasificación de relevancia, y eso los convierte en una plataforma eficiente de recuperación de datos capaz de ofrecer resultados puntuados y ordenados según su relevancia para la consulta. Las bases de datos y otros sistemas que emplean SQL como su método principal para recuperar datos están en desventaja aquí: no existe un concepto de relevancia en una consulta de base de datos; Lo mejor que pueden hacer es ordenar los resultados alfabéticamente o numéricamente. La buena noticia es que obtendrás todos los resultados (recordación) con esas palabras clave, pero no necesariamente están en un orden útil respecto al motivo por el que las pediste (precisión). Es un punto importante, como veremos en breve...

Entra en escena el dragón (semántico)

El potencial de las representaciones vectoriales de la información como alternativa a la búsqueda por palabras clave se investigó durante bastante tiempo. Los vectores tienen mucho potencial porque nos sacan del modo de emparejamiento de contenido basado solo en palabras clave — al ser representaciones numéricas de términos y pesos, los vectores permiten que los conceptos sean matemáticamente cercanos según la comprensión que tiene un modelo de lenguaje sobre cómo se relacionan los términos entre sí en el ámbito de entrenamiento. El largo retraso en la búsqueda vectorial de propósito general se debió a que los modelos estaban mayormente limitados a dominios específicos, simplemente no eran lo suficientemente grandes para comprender suficientemente los muchos conceptos diferentes que un término podría representar en distintos contextos.

No fue hasta que los Grandes Modelos de Lenguaje (LLMs) aparecieron hace unos años, con su capacidad de capacitar con cantidades mucho mayores de datos (usando transformadores y atención), que la búsqueda vectorial se volvió práctica: el tamaño y la profundidad de los LLMs finalmente permitieron que los vectores almacenaran suficiente matiz para captar realmente el significado semántico. Ese aumento repentino en la profundidad de comprensión permitió que los LLMs ahora sirvieran a un gran número de funciones de procesamiento del lenguaje natural (PLN) que antes estaban bloqueadas, siendo quizás la más impactante la capacidad de inferir el siguiente término más probable de una secuencia dado el contexto de lo que hay en la secuencia hasta ese momento. La inferencia es el proceso que otorga a la IA generativa su capacidad casi humana para producir texto. El texto generado por IA se basa en la comprensión que tiene el LLM sobre cómo se relacionan los términos dentro de sus datos de entrenamiento y también emplea la redacción de la petición para desambiguar entre diferentes contextos en los que los términos pueden aparecer.

Por mágica que sea la IA generativa , existen limitaciones en los LLM que causan errores de calidad y precisión, comúnmente llamados alucinaciones. Las alucinaciones ocurren cuando el LLM no tiene acceso a la información (o no es guiado al contexto correcto) para basar su respuesta en la verdad, por lo que, siendo útil, generará en su lugar una respuesta segura y plausible que es inventada. Parte de la causa es que, aunque los LLMs aprenden el uso del lenguaje dentro de grandes dominios de información diversa, tienen que dejar de capacitar en un momento determinado, por lo que su comprensión tiene un factor de puntualidad — es decir, que el modelo solo puede saber qué era preciso hasta el momento en que dejó de capacitar. Otro factor para las alucinaciones es que el modelo normalmente no conoce datos privados (datos no disponibles en Internet público), y eso es especialmente significativo cuando esos datos contienen términos y nomenclatura específicos.

Bases de datos vectoriales

Los LLM vectorizan el contenido a su espacio de modelo empleando una técnica llamada incrustación de texto, que se refiere a incrustar o mapear el significado semántico del contenido dentro de la visión del mundo del modelo en función del entrenamiento recibido. Hay varios pasos para preparar y procesar contenido para incrustar, incluyendo el chunking y la tokenización (y tokenización de subpalabras). El resultado suele ser un conjunto de vectores densos que representan la comprensión del modelo sobre el significado de ese fragmento de contenido dentro de su espacio vectorial. El chunking es un proceso inexacto que pretende encajar el contenido en las limitaciones de las restricciones de procesamiento de un modelo para generar incrustaciones, mientras intenta agrupar texto relacionado en un bloque usando construcciones semánticas como indicadores de oraciones y párrafos.

La necesidad de hacer chunks puede crear cierta flexibilidad semántica en un documento incrustado porque los chunks individuales no están completamente asociados con otros chunks del mismo documento. La opacidad inherente de las redes neuronales puede empeorar esta flexibilidad: un LLM es realmente una "caja negra" donde las conexiones entre términos y conceptos establecidas durante el entrenamiento no son deterministas y no pueden interpretar para los humanos. Esto genera problemas de explicabilidad, repetibilidad, sesgos inconscientes y, potencialmente, pérdida de confianza y precisión. Aun así, la capacidad de conectar ideas semánticamente, sin estar atado a palabras clave específicas al enviar consultas, es extremadamente poderosa:

Un ejemplo de consulta semántica

Hay un aspecto más a considerar para las bases de datos vectoriales: ¡no son motores de búsqueda, son bases de datos! Cuando se realiza una búsqueda de similitud vectorial , los términos de consulta se codifican para encontrar un conjunto de coordenadas (incrustadas) dentro del espacio vectorial del modelo. Esas coordenadas se emplean entonces como el centro para encontrar los documentos que son los "vecinos más cercanos" al centro — es decir, el rango (o la posición en los resultados) de un documento se determina por la distancia de similitud calculada de las coordenadas de ese documento respecto a las coordenadas de la consulta. ¿En qué dirección debe prevalecer el ranking, cuál de los posibles contextos está más cerca de la intención del usuario? La imagen con la que la comparo es una escena de la película Stargate, donde tenemos los seis puntos de coordenada que se cruzan para indicarnos el destino (el centro), pero no podemos llegar sin conocer el "séptimo símbolo" — las coordenadas del punto de partida que representan la intención subjetiva del usuario. Así que, en lugar de que la clasificación relativa de los vectores se base en una esfera de similitud en constante expansión e indiferenciada, al considerar la intención subjetiva de la consulta mediante la sintaxis expresiva y el puntaje de relevancia, podemos obtener algo que se asemeje a un cilindro de relevancia subjetiva graduada.

Las capacidades de inferencia de un LLM podrían ayudar a identificar el contexto más probable que tiene para la consulta, pero el problema es que sin ayuda, las coordenadas de la consulta entrante solo pueden determinar por cómo se capacitó originalmente el modelo.

En cierto modo, se podría decir que la similitud vectorial va al extremo opuesto a una coincidencia estricta de palabras clave — su fortaleza radica en su capacidad para superar los problemas de desajuste de términos, pero casi en exceso: los LLM tienden a unificar conceptos relacionados en lugar de diferenciarlos. La similitud vectorial mejora nuestra capacidad para emparejar contenido semánticamente, pero no garantiza precisión porque puede pasar por alto palabras clave exactas y detalles específicos que el modelo no desambiguó lo suficiente. La búsqueda por similitud vectorial es poderosa en sí misma, pero necesitamos formas de correlacionar los resultados que recuperamos de una base de datos vectorial con los resultados de otros métodos de recuperación.

Técnicas de reclasificación

Ahora es un buen momento para mencionar una técnica general llamada reclasificación, que vuelve a puntuar o normalizar conjuntos de resultados a un orden de rangos unificado. La necesidad de reclasificar podría deber a que los resultados de múltiples fuentes o métodos de recuperación tengan mecanismos de clasificación/puntaje diferentes (¡o ninguno, SQL!), o bien se podría usar la reclasificación para alinear semánticamente los resultados de fuentes no semánticas con la consulta del usuario. La reclasificación es una operación de segunda etapa, es decir, un conjunto de resultados que fueron recogidos mediante algún método inicial de recuperación (es decir, SQL, búsqueda léxica, búsqueda vectorial) se reordenan con un método de puntaje diferente.

Existen varios enfoques disponibles, incluyendo Learning-To-Rank (LTR) y Reciprocal Rank Fusion (RRF) — LTR es útil para capturar características de los resultados de búsqueda (me gusta, valoraciones, clics, etc.) y usarlas para puntuar y potenciar o sesgar resultados. RRF es perfecto para fusionar resultados retornados de diferentes modalidades de consulta (por ejemplo, búsquedas en bases de datos léxicas y vectoriales) juntas en una única lista de resultados. Elastic también ofrece la flexibilidad de ajustar los puntajes mediante métodos de reclasificación lineal .

Sin embargo, una de las técnicas de reclasificación más efectivas es la reclasificación semántica, que emplea la comprensión semántica de un LLM para analizar las incrustaciones vectoriales tanto de la consulta como de los resultados juntos, y luego aplicar el puntaje/repuntuación de relevancia para determinar el orden final. El reranking semántico requiere, por supuesto, una conexión a un modelo de reclasificación, y Elasticsearch proporciona una API de inferencia que permite crear endpoints de reclasificación que aprovechan modelos integrados (Elastic Rerank), modelos importados de terceros o servicios alojados externamente como Cohere o Google Vertex AI. Luego puedes realizar un reordenamiento mediante la sintaxis de abstracción de la consulta del retriever :

Un ejemplo de operación de reclasificación de recuperadores en varias etapas

Suena genial, ¿verdad? Podemos realizar reclasificaciones con resultados de fuentes dispares y acercarnos a una comprensión semántica de todo tipo de contenido... La reclasificación semántica puede ser costosa tanto computacionalmente como en el tiempo de procesamiento requerido, y por ello, la reclasificación semántica solo puede hacer con un número limitado de resultados, lo que significa que la forma en que se recuperan esos resultados iniciales es importante.

El método de recuperación del contexto es importante

La intención subjetiva es un factor importante para determinar la precisión de un resultado y para valorar su relevancia. Sin la capacidad de considerar la intención del usuario para realizar la consulta (expresada mediante sintaxis flexible, o mediante reclasificación en la segunda etapa), solo podemos seleccionar de los contextos existentes ya codificados dentro del espacio del modelo. La forma en que normalmente abordamos esta falta de contexto es mediante técnicas como la Generación de Aumentos por Recuperación (RAG). El funcionamiento de RAG es que desplaza efectivamente las coordenadas de la consulta al incluir términos relacionados adicionales devueltos de una consulta previa para datos contextualmente relevantes. ¡Eso hace que el motor que proporciona ese contexto adicional y su método inicial para realizar la recuperación sean aún más importantes para la precisión del contexto!

Repasemos los diferentes métodos de recuperación de contexto y cómo pueden ayudar o perjudicar a una operación RAG:

• La recuperación de búsqueda híbrida sin motor de búsqueda sigue careciendo de relevancia subjetiva. Si la plataforma que proporciona RAG es principalmente SQL (lo que incluye la mayoría de las plataformas "data lake"), carece de puntaje de relevancia en la fase inicial de recuperación. Muchas plataformas de data lake ofrecen su propia versión de recuperación híbrida (no de búsqueda), normalmente combinando técnicas de reclasificación como la reclasificación semántica y la RRF en sus resultados de recuperación basada en SQL y bases de datos vectoriales. Un ordenamiento simple es obviamente insuficiente para la clasificación subjetiva, pero incluso cuando se usa como base para una operación de reclasificación semántica de segunda etapa, SQL como recuperación de primera etapa se convierte en un problema cuando el reclasificación semántica se realiza solo en los "k primeros resultados" — sin alguna forma de puntuar resultados en la recuperación, ¿qué garantía tenemos de que los mejores resultados estén realmente en los primeros resultados?

• La similitud vectorial por sí sola no es suficiente para RAGs. Realmente se debe a un conjunto de problemas que se acumulan: es la rapidez del embedding, junto con métodos ingenuos de fragmentación, cómo se calcula la similitud y el componente crucial que falta de la intención subjetiva. Uno de los principales objetivos de RAG es fundamentar las interacciones generativas de IA en la verdad objetiva, tanto para prevenir alucinaciones como para informar al LLM sobre la información privada que no conocía durante el entrenamiento. Podemos emplear el contexto adicional proporcionado por RAG para restringir y dirigir a los LLMs a considerar las conexiones y detalles que sabemos que son más importantes para responder a la pregunta que nos planteamos. Para ello, necesitamos usar tanto enfoques semánticos como léxicos.

• RAG grep/regex basado en archivos. Hay algunos sectores del universo de IA agente que apuntan al uso de ventanas de contexto enormemente ampliadas que acceden a archivos locales mediante grep y regex para RAG en lugar de plataformas externas de recuperación. La idea es que, con una ventana de contexto mucho más amplia disponible, los LLMs podrán establecer conexiones conceptuales dentro de su propio espacio de pensamiento en lugar de depender de fragmentos y múltiples métodos/plataformas de recuperación para recopilar información relevante. Aunque en teoría es cierto que tener un documento completo ofrece una imagen más completa que los segmentos del documento, esto solo puede funcionar en pequeños dominios de datos (o, por ejemplo, al suministrar archivos para vibecoding), y aun así, el método inicial de recuperación es un escaneo de todos los documentos con una coincidencia solo por palabra clave.

La búsqueda es más que una recuperación

Los motores de búsqueda están diseñados específicamente para hacer que las consultas sean lo más rápidas y flexibles posible. Internamente, emplean estructuras de datos especializadas para almacenar y recuperar diferentes tipos de datos de manera que se adapten a esos tipos de datos. Elasticsearch proporciona almacenamiento y consulta optimizados de prácticamente todo tipo de datos, incluyendo búsqueda léxica no estructurada/texto completo (coincidencia, frase, proximidad, multi-coincidencia), coincidencia y filtrado rápido de palabras clave (coincidencia exacta), rangos numéricos, fechas, direcciones IP, y es muy flexible en cómo almacena las estructuras de documentos (por ejemplo, Docs anidados o aplanados). Elasticsearch es también una base de datos vectorial nativa que puede almacenar y consultar tanto tipos vectoriales dispersos como densos, y seguimos explorando formas innovadoras (por ejemplo, Better Binary Quantization (BBQ) y DiskBBQ) para mantener la fidelidad de búsqueda mientras mejoramos la velocidad, escalabilidad y costos asociados al contenido vectorizado. La plataforma Elasticsearch también proporciona resiliencia y alta disponibilidad de datos integradas, e incluye capacidades de gestión del ciclo de vida de los datos como Searchable Snapshots que permiten mantener datos de poca frecuencia o de retención a largo plazo en un almacenamiento de objetos rentable, pero aún totalmente buscables.

La búsqueda híbrida es lo mejor de todos los mundos

Búsqueda híbrida (¡no solo recuperación híbrida!) combina las fortalezas de la búsqueda léxica tradicional con la comprensión semántica de los LLMs y la búsqueda por similitud vectorial. Esta sinergia permite dirigir resultados altamente relevantes en la fase de recuperación mediante cualquiera de las opciones flexibles de sintaxis de consulta que ofrece un motor de búsqueda: opciones de sintaxis impulsadas por intención y puntaje de relevancia, recuperación de datos multimodales, filtrado, agregaciones y sesgos. Con sintaxis de búsqueda como ES|QL y recuperadores de varias etapas, podemos combinar de forma flexible la búsqueda tradicional con búsqueda semántica, filtros y múltiples técnicas de reclasificación, todo en una sola petición.

Uno de los mayores beneficios de la búsqueda híbrida es que tus consultas pueden usar sintaxis especializada para múltiples tipos de datos diferentes simultáneamente. Esas diferentes sintaxis de consulta pueden usar no solo para encontrar resultados, sino también como filtros o agregaciones en los resultados. Por ejemplo, uno de los tipos de consulta más comunes que frecuentemente se combina con otra sintaxis es el análisis geoespacial. Puedes hacer cosas como consultar resultados que tengan coordenadas geográficas dentro de una distancia especificada de un punto, o aplicar agregaciones de tus resultados por región, o agregaciones para rastrear y alertar sobre movimientos dentro o fuera de una zona. Con la búsqueda híbrida tienes la flexibilidad de combinar sintaxis para dirigir los resultados de la manera más precisa, para recuperar el contenido más cercano a tu contexto.

Entreacto

Esta primera parte cuenta la historia de cómo la búsqueda vectorial cambió la forma en que podemos recuperar datos y sienta el terreno para los cambios que los LLMs trajeron a los mecanismos de consulta que empleamos para interactuar con los datos. Vamos a fingir que tuvimos que descomponer esto en varias partes para que los LLM pudieran entenderlo sin perder el contexto... ;-) Aprendamos más sobre por qué esto es importante en la Parte II: IA Agente y la necesidad de ingeniería de contexto, y en la Parte III volveremos a nuestra discusión sobre la búsqueda híbrida.

Para lograrlo, empleamos SigLIP-2 de Google para generar incrustaciones vectoriales tanto para imágenes como para texto, y las almacenamos en la base de datos vectorial Elasticsearch. En el momento de la consulta, convertimos la entrada de búsqueda, texto o imagen, en incrustaciones y realizamos búsquedas rápidas con vectores kNN para obtener resultados. Esta configuración permite una búsqueda eficiente de texto a imagen y de imagen a imagen. Una interfaz Streamlit da vida a este proyecto proporcionándonos una interfaz no solo para hacer búsquedas por texto para encontrar y ver las fotos coincidentes del álbum, sino también para identificar la cima de la montaña a partir de la imagen subida y ver otras fotos de esa montaña en el álbum. También cubrimos los pasos que seguimos para mejorar la precisión de las búsquedas, junto con consejos y trucos prácticos. Para una exploración más profunda, proporcionamos un repositorio de GitHub y un cuaderno de Colab.

Cómo empezó todo

Esta entrada del blog fue inspirada por un niño de 10 años que me pidió que les mostrara todas las fotos del Monte Ama Dablam de mi travesía al campamento base del Everest. Mientras revisábamos el álbum de fotos, también me pidieron que identificara varias otras cumbres montañosas, algunas de las cuales no podía nombrar.

Eso me dio la idea de que esto puede ser un proyecto divertido de visión por computadora. Lo que queríamos conseguir:

• Encuentra fotos de un pico montañoso por nombre

• Adivina el nombre de la cima de la montaña a partir de una imagen y también encuentra picos similares en el álbum de fotos

• Haz que las consultas conceptuales funcionen (persona, río, banderas de oración, etc.)

Formando el equipo soñado: SigLIP-2, Elasticsearch y Streamlit

Pronto quedó claro que, para que esto funcionara, tendríamos que convertir tanto el texto ("Ama Dablam") como las imágenes (fotos de mi álbum) en vectores que puedan comparar de forma significativa, es decir, en el mismo espacio vectorial. Una vez que hacemos eso, la búsqueda es simplemente "encontrar a los vecinos más cercanos".

Para generar incrustaciones de imágenes, usamos un codificador multilingüe visión-lenguaje, de modo que una foto de una montaña y una frase como "Ama Dablam" caen en el mismo espacio vectorial.

SigLIP-2, lanzado recientemente por Google, encaja bien aquí. Puede generar incrustaciones sin entrenamiento específico de tarea (un ajuste de cero disparos ) y funciona bien para nuestro caso: fotos sin etiqueta y picos con diferentes nombres e idiomas. Como está capacitado para la coincidencia de imágenes de texto ↔, una foto de montaña de la travesía y un breve prompt de texto acaban siendo similares a incrustaciones, incluso cuando el idioma de consulta o la ortografía varían.

SigLIP-2 ofrece un fuerte equilibrio calidad-velocidad, soporta múltiples resoluciones de entrada y funciona tanto en CPU como en GPU. El SigLIP-2 está diseñado para ser más robusto para fotos exteriores en comparación con modelos anteriores como el CLIP original. Durante nuestras pruebas, SigLIP-2 generó resultados fiables de forma constante. Además, está muy bien apoyado, lo que lo convierte en la opción obvia para este proyecto.

A continuación, necesitamos una base de datos vectorial para almacenar los embebidos y la búsqueda de potencia. Debe soportar no solo búsqueda kNN coseno sobre incrustaciones de imágenes, sino también aplicar filtros de geocerca y texto en una sola consulta. Elasticsearch encaja bien aquí: maneja vectores (HNSW kNN en campos dense_vector), soporta búsqueda híbrida que combina texto, vectores y consultas geográficas, y ofrece filtrado y ordenación desde el principio. Además, escala horizontalmente, lo que facilita crecer de unas pocas fotos a miles. El cliente oficial de Python de Elasticsearch mantiene la fontanería sencilla y se integra perfectamente con el proyecto. Por último, necesitamos un frontend ligero donde podamos introducir consultas de búsqueda y ver resultados. Para una demostración rápida basada en Python, Streamlit es una opción ideal. Proporciona las primitivas que necesitamos: carga de archivos, una cuadrícula de imágenes responsiva y menús desplegables para ordenar y geovaller. Es fácil de clonar y ejecutar localmente, y también funciona en un cuaderno de Colab.

Implementación

Diseño y estrategia de indexación de Elasticsearch

Emplearemos dos índices para este proyecto: peaks_catalog y photos.

Peaks_catalog índice

Este índice sirve como un catálogo compacto de picos montañosos prominentes visibles durante la travesía al Campamento Base del Everest. Cada documento de este índice corresponde a una sola cima montañosa, como el Monte Everest. Para cada documento de pico de montaña, almacenamos nombres/alias, coordenadas opcionales de latitud-longitud y un único vector prototipo construido mediante la mezcla de prompts de texto SigLIP-2 (+ imágenes de referencia opcionales).

Mapeo indexado:

Campo

Tipo

Ejemplo

Propósito/Notas

Vector/Indexación

identificación

palabra clave

ama-dablam

Slug/id estable

—

Nombres

Subcampo texto + palabra clave

["Ama Dablam","Amadablam"]

Alias / nombres multilingües; names.raw para filtros exactos

—

Latlon

geo_point

{"lat":27.8617,"lon":86.8614}

Coordenadas GPS de pico como combinación de latitud/longitud (opcional)

—

elev_m

entero

6812

Elevación (opcional)

—

text_embed

dense_vector

768

Prototipo mezclado (prompts y, opcionalmente, 1–3 imágenes de referencia) para este pico

Index:True, Similitud:"Coseno", index_options:{type:"hnsw", m:16, ef_construction:128}

Este índice se emplea principalmente para búsquedas imagen a imagen, como identificar picos montañosos a partir de imágenes. También empleamos este índice para mejorar los resultados de búsqueda de texto a imagen.

En resumen, el peaks_catalog transforma la pregunta "¿Qué montaña es esta?" en un problema enfocado del vecino más cercano, separando efectivamente la comprensión conceptual de las complejidades de los datos de imagen.

Estrategia de indexación para el índice peaks_catalog: Comenzamos creando una lista de los picos más destacados visibles durante la travesía por el EBC. Para cada pico, almacenamos su ubicación geográfica, nombre, sinónimos y elevación en un archivo yaml. El siguiente paso es generar la incrustación de cada pico y almacenarla en text_embed campo. Para generar incrustaciones robustas, empleamos la siguiente técnica:

• Crea un prototipo de texto usando:

  • Nombres de los picos

  • Conjunto de prompts (usando varios prompts diferentes para intentar responder a la misma pregunta), por ejemplo:

    • "una foto natural de la cima de la montaña {name} en el Himalaya, Nepal"

    • "{name} pico emblemático en la región del Khumbu, paisaje alpino"

    • "{name} cima de montaña, nieve, cresta rocosa"

  • anticoncepto opcional (indicar a SigLIP-2 en qué no debe coincidir): resta un pequeño vector para "pintura, ilustración, afiche, mapa, logo" para inclinarnos hacia fotos reales.

• Opcionalmente , crea un prototipo de imagen si se proporcionan imágenes de referencia del pico.

Luego mezclamos el prototipo de texto e imagen para generar la incrustación final. Finalmente, el documento está indexado con todos los campos requeridos:

Documento de ejemplo de peaks_catalog índice:

Índice de fotos

Este índice principal almacena información detallada sobre todas las fotos del álbum. Cada documento representa una sola foto, que contiene la siguiente información:

• Camino relativo a la foto del álbum. Esto puede usar para ver la imagen correspondiente o cargarla en la interfaz de búsqueda.

• GPS e información horaria de la imagen.

• Vector denso para codificación de imágenes generado por SigLIP-2.

• predicted_peaks Eso nos permite filtrar por nombre de pico. Mapeo de índices

Campo

Tipo

Ejemplo

Propósito/Notas

Vector / Indexación

camino

palabra clave

datos/imágenes/IMG_1234.HEIC

Cómo se abre la interfaz en miniatura/imagen completa

—

clip_image

dense_vector

768

Incrustación de imágenes SigLIP-2

Index:True, Similitud:"Coseno", index_options:{type:"hnsw", m:16, ef_construction:128}

predicted_peaks

palabra clave

["ama-dablam", "pumori"]

Top-K suposiciones en el tiempo del índice (filtro UX barato / facet)

—

GPS

geo_point

{"lat":27.96,"lon":86.83}

Activa los filtros geográficos

—

shot_time

date

2023-10-18T09:41:00Z

Tiempo de captura: ordenar/filtrar

—

Estrategia de indexación para el índice de fotos: Para cada foto del álbum, hacemos lo siguiente: Extrae shot_time de imagen y gps información de los metadatos de las imágenes.

• Embedding de imagen SigLIP-2: pasar la imagen por el modelo y normalizar el vector en modo L2. Almacena el embedding en clip_image campo.

• Predecir los picos y almacenarlos en el campo predicted_peaks . Para ello, primero tomamos el vector de imagen de la foto generado en el paso anterior y luego ejecutamos una búsqueda rápida kNN en el campo text_embed en el índice de peaks_catalog . Mantenemos los 3-4 primeros picos e ignoramos el resto.

• Calculamos el campo _id haciendo un hash en el nombre y el camino de la imagen. Esto cerciora que no acabemos con duplicados tras varias partidas.

Una vez que determinamos todos los campos para la foto, los documentos fotográficos se indexan en lotes usando indexación masiva :

Documento de ejemplo del índice de fotos:

En resumen, el índice de las fotos es el almacén rápido, filtrable y listo para kNN de todas las fotos del álbum. Su mapeo es mínimo a propósito: la estructura justa para recuperar rápidamente, mostrar limpiamente y recortar los resultados por espacio y tiempo. Este índice sirve tanto para casos de búsqueda como para el uso. Aquí se puede encontrar un script en Python para crear ambos índices.

La visualización de mapas de Kibana que aparece a continuación muestra documentos del álbum de fotos como puntos verdes y picos montañosos del índice de peaks_catalog como triángulos rojos, con los puntos verdes alinear bien con el sendero de la ruta del campamento base del Everest.

Casos de uso de búsqueda

Buscar por nombre (texto a imagen): Esta función permite a los usuarios localizar fotos de picos montañosos (e incluso conceptos abstractos como "banderas de oración") mediante consultas de texto. Para lograrlo, la entrada de texto se convierte en un vector de texto usando SigLIP-2. Para una generación robusta de vectores de texto, empleamos la misma estrategia que se usa para crear incrustaciones de texto en el índice peaks_catalog : combinar la entrada de texto con un pequeño conjunto de prompts, restar un pequeño vector anti-concepto y aplicar la normalización L2 para producir el vector de consulta final. A continuación, se ejecuta una consulta kNN en el campo photos.clip_image para recuperar los picos que coinciden con la parte superior, basar en la similitud coseno para encontrar las imágenes más cercanas. Opcionalmente, los resultados de búsqueda pueden ser más relevantes aplicando filtros geográficos y de fecha, y/o un filtro de photos.predicted_peaks términos como parte de la consulta (ver ejemplos de consultas más abajo). Esto ayuda a excluir picos que se parecen y que en realidad no se ven durante la travesía.

Consulta de Elasticsearch con filtro geográfico:

Buscar por imagen (imagen a imagen): Esta función nos permite identificar una montaña en una imagen y encontrar otras imágenes de esa misma montaña dentro del álbum. Cuando se sube una imagen, el codificador de imagen SigLIP-2 la procesa para generar un vector de imagen. A continuación, se realiza una búsqueda kNN en el campo peaks_catalog.text_embed para identificar los nombres de picos que mejor coinciden. Posteriormente, se genera un vector de texto a partir de estos nombres de picos coincidentes, y se realiza otra búsqueda kNN en el índice de fotos para localizar las imágenes correspondientes.

Consulta Elasticsearch:

Paso 1: Encontrar los nombres de picos que coincidan

Paso 2: Realiza una búsqueda en el índice de photos para encontrar las imágenes coincidentes (misma consulta que se muestra en el caso de búsqueda text-to-image):

Interfaz Streamlit

Para unir todo, creamos una interfaz sencilla de Streamlit que nos permite realizar ambos casos de uso de búsqueda. El riel izquierdo muestra una lista desplazable de picos (agregados a partir de photos.predicted_peaks) con casillas de verificación y un minimapa/filtro geográfico. En la parte superior hay una caja de búsqueda por nombre y un botón de identificación por subida de fotos . El panel central presenta una cuadrícula en miniatura sensible que muestra puntajes kNN, insignias de picos predichos y tiempos de captura. Cada imagen incluye un botón para ver imagen para vistas previas en resolución completa.

Busca subiendo una imagen: Predecimos el pico y encontramos picos coincidentes del álbum de fotos.

Buscar por texto: Encuentra los picos coincidentes en el álbum a partir del texto

Conclusión

¿Qué empezó como , ¿podemos simplemente ver las imágenesde Ama Dablam? se convirtió en un pequeño sistema de búsqueda multimodal funcional. Tomamos fotos en bruto de trekking, las convertimos en incrustaciones SigLIP-2 y usamos Elasticsearch para hacer kNN rápido sobre vectores, además de filtros geo/temporales simples para mostrar las imágenes correctas por significado. En el camino, separamos las preocupaciones con dos índices: un pequeño peaks_catalog de prototipos combinados (para identificación) y un índice escalable de photos de vectores de imagen y EXIF (para recuperación). Es práctica, reproducible y fácil de ampliar.

Si quieres afinarla, hay algunos ajustes con los que puedes experimentar:

• Ajustes de tiempo de consulta: k (cuántos vecinos quieres que devuelvan) y num_candidates (qué ancho buscar antes del puntaje final). Estos ajustes se discuten en el blog aquí.

• Ajustes de tiempo de índice: m (conectividad de grafos) y ef_construction (precisión en tiempo de construcción frente a memoria). Para consultas, experimenta también con ef_search : más alto suele significar mejor recordación con cierto compromiso de latencia. Consulta este blog para más detalles sobre estos entornos.

De cara al futuro, los modelos nativos/reclasificadores para búsqueda multimodal y multilingüe pronto llegarán al ecosistema Elastic, lo que debería mejorar aún más la recuperación de imágenes/texto y el ranking híbrido desde el primer momento. ir.elastic.co+1

Si quieres probar esto tú mismo:

• Repositorio de GitHub: https://github.com/navneet83/multimodal-mountain-peak-search

• Inicio rápido de Colab: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Con esto, nuestro viaje llegó a su fin y es hora de volar de regreso. Espero que esto te fue útil y si lo rompes (o lo mejoras), me encantaría saber qué cambiaste.

Lee el blog Construiendo flujos de trabajo agentes con IA con Elasticsearch para más información sobre la "visión global" de ese esfuerzo, o Tu primer agente elástico: de una sola consulta a un chat impulsado por IA para una introducción más práctica.

Sin embargo, en este blog vamos a hacer un poco de zoom para ver una de las primeras cosas que ocurren cuando empiezas a charlar y para guiarte por algunas de las mejoras recientes que hicimos.

¿Qué está pasando aquí?

Cuando chateas con tus datos de Elasticsearch, nuestro agente de IA predeterminado te guía a través de este flujo estándar:

1. Revisa el enunciado.

2. Identifica qué índice es probable que contenga las respuestas a esa pregunta.

3. Genera una consulta para ese índice, basada en el prompt.

4. Busca en ese índice con esa consulta.

5. Sintetiza los resultados.

6. ¿Pueden los resultados responder al prompt? Si es así, responde. Si no, repite, pero prueba algo diferente.

Esto no debería parecer demasiado novedoso: es simplemente Generación Aumentada por Recuperación (RAG). Y como era de esperar, la calidad de tus respuestas depende mucho de la relevancia de tus resultados iniciales. Así que, mientras trabajamos en mejorar la calidad de nuestra respuesta, estuvimos prestando mucha atención a las consultas que generábamos en el paso 3 y ejecutábamos en el paso 4. Y notamos un patrón interesante.

A menudo, cuando nuestras primeras respuestas eran "malas", no era porque hicimos una consulta mala. Fue porque elegimos el índice equivocado para hacer la consulta. Los pasos 3 y 4 normalmente no eran nuestro problema, sino el paso 2.

¿Qué estábamos haciendo?

Nuestra implementación inicial fue sencilla. Creamos una herramienta (llamada index_explorer) que efectivamente hacía un _cat/indices para listar todos los índices disponibles y luego pedir al LLM que identificara cuál de estos índices era el mejor para el mensaje/pregunta/prompt del usuario. Puedes ver esta implementación original aquí.

¿Qué tal funcionaba? ¡No estábamos seguros! Teníamos ejemplos claros de que no funcionaba bien, pero nuestro verdadero primer reto fue cuantificar nuestro estado actual.

Establecimiento de una línea base

Todo empieza con los datos

Lo que necesitábamos era un conjunto de datos dorado para medir la eficacia de una herramienta a la hora de seleccionar el índice adecuado dado un prompt del usuario y un conjunto preexistente de índices. Y no disponíamos de un conjunto de datos así. Así que generamos uno.

Agradecimiento: Esto no es "buena práctica", lo sabemos. Pero a veces, es mejor seguir adelante que abandonar la bicicleta. Progreso, perfección SIMPLE.

Generamos índices semilla para varios dominios diferentes usando este prompt. Luego, para cada dominio generado, generamos algunos índices más usando este prompt (el objetivo aquí es sembrar confusión para el LLM con negativos duros y ejemplos difíciles de clasificar). Después, editamos manualmente cada índice generado y sus descripciones. Finalmente, generamos consultas de prueba usando este prompt. Esto nos dejó con datos de muestra como:

y casos de prueba como:

Elaboración de un arnés de prueba

El proceso a partir de aquí fue muy sencillo. Crea un script para una herramienta que pueda:

1. Establece una hoja limpia con un clúster objetivo de Elasticsearch.

2. Crea todos los índices definidos en el conjunto de datos objetivo.

3. Para cada escenario de prueba, ejecuta la herramienta index_explorer (prácticamente tenemos una API de Herramienta de Ejecución).

4. Comparar el índice de resultados con el índice esperado y capturar el resultado.

5. Luego de terminar todos los escenarios de prueba, tabula los resultados.

La encuesta dice...

Los resultados iniciales fueron, como era de esperar, mediocres.

En general, un 77,14% de precisión para identificar el índice adecuado. Y esto fue en un escenario "mejor escenario", donde todos los índices tienen buenos nombres semánticamente significativos. Cualquiera que hizo alguna vez un 'PUT test2/_doc/foo {...}' sabe que tus índices no siempre tienen nombres significativos.

Así que tenemos una línea de base, y muestra mucho margen de mejora. ¡Ahora era hora de hacer algo de ciencia! 🧪

Experimentación

Hipótesis 1: Los mapeos ayudarán

El objetivo aquí es identificar un índice que contenga datos relevantes para la consigna original. Y la parte de un índice que mejor describe los datos que contiene son los mapeos del índice. Incluso sin obtener muestras del contenido del índice, saber que el índice tiene un campo de precios de tipo doble implica que los datos representan algo que se puede vender. Un campo autor de texto tipográfico implica algunos datos de lenguaje no estructurados. Ambos juntos podrían implicar que los datos son libros/relatos/poemas. Hay muchas pistas semánticas que podemos derivar simplemente conociendo las propiedades de un índice. Así que en una sucursal local, ajusté nuestro '.index_explorer' herramienta para enviar los mapeos completos de un índice (junto con su nombre) al LLM para tomar su decisión.

El resultado (de los registros de Kibana):

Los autores iniciales de la herramienta ya lo habían anticipado. Aunque el mapeo de un índice es una mina de oro de información, también es un bloque bastante extenso de JSON. Y en un escenario realista donde comparas numerosos índices (nuestro conjunto de datos de evaluación define 20), estos blobs JSON suman. Así que queremos dar al LLM más contexto para su decisión que solo los nombres de índices de todas las opciones, pero no tanto como los mapeos completos de cada una.

Hipótesis 2: Mapeos "aplanados" (listas de campos) como compromiso

Partimos de la suposición de que los creadores de índices usarán nombres de índices semánticamente significativos. ¿Y si extendemos esa suposición también a los nombres de campos? Nuestro experimento anterior falló porque el mapeo JSON incluye MUCHOS metadatos y datos basurales y un estándar estándar.

El bloque anterior, por ejemplo, tiene 236 caracteres y define solo un campo en un mapeo de Elasticsearch. Mientras que la cadena "description_text" tiene solo 16 caracteres. Eso supone casi un aumento de 15 veces en el recuento de caracteres, sin una mejora semántica significativa en la descripción de lo que ese campo implica sobre los datos disponibles. ¿Y si recogiéramos los mapeos de todos los índices, pero antes de enviarlos al LLM, los "aplanáramos" solo en una lista con sus nombres de campo?

Lo probamos.

¡Esto es genial! Mejoras en todos los ámbitos. ¿Pero podríamos hacerlo mejor?

Hipótesis 3: Descripciones en el _meta de cartografía

Si solo los nombres de campos sin contexto adicional causaran un salto tan grande, ¡supongo que agregar un contexto sustancial sería aún mejor! No es necesariamente convencional que cada índice tenga una descripción adjunta, pero sí es posible agregar metadatos a nivel de índice de cualquier tipo al objeto _meta del mapeo. Volvimos a nuestros índices generados y agregamos descripciones para cada índice de nuestro conjunto de datos. Mientras las descripciones no sean demasiado largas, deberían usar menos tokens que el mapeo completo y proporcionar una visión significativamente mejor sobre qué datos se incluyen en el índice. Nuestro experimento validó esta hipótesis.

Una mejora modesta, y ahora somos >90% precisos en todos los aspectos.

Hipótesis 4: La suma es mayor que sus partes

Los nombres de campos aumentaron nuestros resultados. Las descripciones aumentaron nuestros resultados. Así que, empleando tanto descripciones COMO nombres de campos debería dar resultados aún mejores, ¿no?

Los datos decían "no" (sin cambios respecto al experimento anterior). La teoría principal aquí era que, dado que las descripciones se generaron a partir de los campos índice/mapeos desde el principio, no hay suficiente información diferente entre estos dos contextos para ayudar a agregar algo "nuevo" al combinarlos. Además, la carga útil que enviamos para nuestros 20 índices de prueba está creciendo bastante. El hilo de pensamiento que seguimos hasta ahora no es escalable. De hecho, hay buenas razones para creer que ninguno de nuestros experimentos hasta ahora funcionaría en clústeres de Elasticsearch donde hay cientos o miles de índices para elegir. Cualquier enfoque que aumente linealmente el tamaño del mensaje enviado al LLM a medida que aumenta el número total de índices probablemente no será una estrategia generalizable.

Lo que realmente necesitamos es un enfoque que nos ayude a reducir un gran número de candidatos a las opciones más relevantes...

Lo que tenemos aquí es un problema de búsqueda.

Hipótesis 5: Selección mediante búsqueda semántica

Si el nombre de un índice tiene significado semántico, entonces puede almacenar como un vector y buscar semánticamente.

Si los nombres de campos de un índice tienen significado semántico, entonces pueden almacenar como vectores y buscar semánticamente.

Si un índice tiene una descripción con significado semántico, también puede almacenar como vector y buscar semánticamente.

Hoy en día, los índices de Elasticsearch no hacen que ninguna de esta información sea buscable (¡quizá deberíamos!), pero fue bastante trivial improvisar algo que pudiera superar esa brecha. Usando el framework de conectores de Elastic, construí un conector que generaba un documento para cada índice de un clúster. Los documentos de salida serían algo así:

Envié estos documentos a un nuevo índice donde definí manualmente el mapeo como:

Esto crea un solo campo semantic_content, donde todos los demás campos con significado semántico se fragmentan e indexan. Buscar en este índice se vuelve trivial, simplemente:

La herramienta de index_explorer modificada es ahora mucho más rápida, ya que no necesita hacer una solicitud a un LLM, sino que puede aplicar una única incrustación para la consulta dada y realizar una operación eficiente de búsqueda vectorial. Tomando el resultado más alto como índice seleccionado, obtuvimos resultados de:

Este enfoque es escalable. Este enfoque es eficiente. Pero este enfoque es apenas mejor que nuestra línea base. Sin embargo, esto no es sorprendente; El enfoque de búsqueda aquí es increíblemente ingenuo. No hay matices. No hay reconocimiento de que el nombre y la descripción de un índice deban tener más peso que un nombre arbitrario de campo que contiene el índice. No hay posibilidad de ponderar coincidencias léxicas exactas sobre coincidencias sinónimas. Sin embargo, construir una consulta muy matizada requeriría asumir MUCHO sobre los datos disponibles. Hasta ahora, ya hicimos algunas grandes suposiciones sobre que los nombres de índices y campos tienen significado semántico, pero tendríamos que ir un paso más allá y empezar a suponer cuánto significado tienen y cómo se relacionan entre sí. Sin hacerlo, probablemente no podamos identificar de forma fiable la mejor coincidencia como nuestro resultado principal, pero es más probable que digamos que la mejor coincidencia está en algún lugar de los primeros N resultados. Necesitamos algo que pueda consumir información semántica en el contexto en el que existe, comparando con otra entidad que pueda representar a sí misma de manera semánticamente distinta, y juzgar entre ellas. Como un LLM.

Hipótesis 6: Reducción de conjuntos candidatos

Hubo bastantes experimentos más que voy a pasar por alto, pero el avance clave fue dejar de lado el deseo de elegir la mejor coincidencia únicamente a partir de una búsqueda semántica, y en su lugar emplear la búsqueda semántica como filtro para eliminar índices irrelevantes de la consideración del LLM. Combinamos Retrievers Lineales, Búsqueda Híbrida con RRF y semantic_text para nuestra búsqueda, limitando los resultados a los 5 principales índices de coincidencia.

Luego, para cada coincidencia, agregamos el nombre, la descripción y los nombres de campos del índice a un mensaje para el LLM. Los resultados fueron fantásticos:

¡La mayor precisión de cualquier experimento hasta ahora! Y como este enfoque no aumenta el tamaño del mensaje proporcional al número total de índices, es mucho más escalable.

Resultados

El primer resultado claro fue que nuestra línea base puede mejorar. Esto parece obvio en retrospectiva, pero antes de que comenzara la experimentación, hubo un debate serio sobre si deberíamos abandonar por completo nuestra herramienta de index_explorer y confiar en la configuración explícita del usuario para limitar el espacio de búsqueda. Aunque sigue siendo una opción viable y válida, esta investigación muestra que existen caminos prometedores para automatizar la selección de índices cuando dichas entradas de usuario no están disponibles.

El siguiente resultado claro fue que simplemente agregar más personajes descriptivos al problema tiene rendimientos decrecientes. Antes de esta investigación, debatimos si deberíamos invertir en ampliar la capacidad de Elasticsearch para almacenar metadatos a nivel de campo. Hoy en día, estos valores de meta están limitados a 50 caracteres, y se asumía que tendríamos que aumentar este valor para poder obtener una comprensión semántica de nuestros campos. Claramente no es así, y el LLM parece funcionar bastante bien solo con los nombres de campos. Puede que investiguemos esto más adelante, pero ya no nos parece urgente.

Por el contrario, esto dio evidencia clara de la importancia de tener metadatos de índice "buscables". Para estos experimentos, hackeamos un índice de índices. Pero esto es algo que podríamos explorar integrando directamente en Elasticsearch, creando APIs para gestionar, o al menos estableciendo una convención en torno a ella. Estaremos valorando nuestras opciones y hablando internamente, así que estad atentos.

Por último, este esfuerzo confirmó el valor de que nos tomemos nuestro tiempo para experimentar y tomar decisiones basadas en datos. De hecho, nos ayudó a reafirmar que nuestro producto Agent Builder va a necesitar capacidades robustas de evaluación dentro del producto. Si necesitamos construir un arnés de pruebas completo solo para una herramienta que selecciona índices, nuestros clientes necesitarán absolutamente formas de evaluar cualitativamente sus herramientas personalizadas mientras hacen ajustes iterativos.

Estoy deseando ver qué construiremos, ¡y espero que tú también!

¡Conoce al retriever lineal!

En esta publicación, presentamos el  linear retriever, ¡nuestra última incorporación para apoyar la búsqueda híbrida! A diferencia de rrf, el recuperador de linear calcula una suma ponderada en todas las consultas que coinciden con un documento. Este enfoque conserva la importancia relativa de cada documento dentro de un conjunto de resultados al tiempo que permite un control preciso sobre la influencia de cada consulta en el puntaje final. Como resultado, proporciona una forma más intuitiva y flexible de ajustar la búsqueda híbrida.

Definición de un recuperador lineal donde el puntaje final se calculará como:

Es tan simple como:

¿Notas lo simple e intuitivo que es? (¡y muy similar a rrf!) Esta configuración le permite controlar con precisión cuánto contribuye cada tipo de consulta a la clasificación final, a diferencia de rrf, que se basa únicamente en clasificaciones relativas.

Queda una advertencia: knn puntajes pueden estar estrictamente limitados, dependiendo de la métrica de similitud empleada. Por ejemplo, con la similitud del coseno o el producto punto de los vectores estandarizados por unidades, los puntajes siempre estarán dentro del rango [0, 1] . Por el contrario, bm25 puntajes son menos previsibles y no tienen límites claramente definidos.

Escalando los puntajes: kNN vs BM25

Un desafío de la búsqueda híbrida es que diferentes recuperadores producen puntajes en diferentes escalas. Considere, por ejemplo, el siguiente escenario:

Puntajes de la consulta A:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

Puntajes de la consulta B:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

Puede ver la disparidad arriba: kNN puntajes oscilan entre 0 y 1, mientras que bm25 puntajes pueden variar enormemente. Esta diferencia hace que sea difícil establecer pesos óptimos estáticos para combinar los resultados.

Normalización al rescate: el normalizador MinMax

Para solucionar esto, introdujimos un normalizador de minmax opcional que escala los puntajes, de forma independiente para cada consulta, al rango de [0, 1] mediante la siguiente fórmula:

Esto conserva la importancia relativa de cada documento dentro del conjunto de resultados de una consulta, lo que facilita la combinación de puntajes de diferentes recuperadores. Con la normalización, los puntajes se convierten en:

Puntajes de la consulta A:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

Puntajes de la consulta B:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

Todos los puntajes ahora se encuentran en el rango de [0, 1] y optimizar la suma ponderada es mucho más sencillo, ya que ahora capturamos la importancia (relativa a la consulta) de un resultado en lugar de su puntaje absoluto y mantenemos la coherencia entre las consultas.

Ejemplo de recuperador lineal

Veamos un ejemplo ahora para mostrar cómo se ve lo anterior y cómo el linear retriever aborda algunas de las deficiencias de rrf. RRF se basa únicamente en rangos relativos y no considera las diferencias de puntaje reales. Por ejemplo, dadas estos puntajes:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

puntaje de la fuerza de avance

0.03226

0.03252

0.03200

0.03125

RRF clasificaría los documentos como:

Sin embargo, doc1 tiene un puntaje de bm25 significativamente más alta que los demás, que rrf no logra capturar porque solo analiza los rangos relativos. El recuperador de linear , combinado con la normalización, explica correctamente tanto los puntajes como sus diferencias, produciendo una clasificación más significativa:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

Como podemos ver en lo anterior, la gran clasificación y score de doc1 para bm25 se contabiliza adecuadamente y se refleja en los puntajes finales. Además de eso, todos los puntajes se encuentran ahora en el rango [0, 1] para que podamos compararlas y combinarlas de una manera mucho más intuitiva (e incluso construir procesos de optimización offline).

Poniéndolo todo junto

Para aprovechar al máximo el recuperador de linear con normalización, la solicitud de búsqueda tendría el siguiente aspecto:

Este enfoque combina lo mejor de ambos mundos: conserva la flexibilidad y el puntaje intuitivo del recuperador de linear , al tiempo que garantiza una escala de puntaje consistente con la normalización MinMax.

Al igual que con todos nuestros retrievers, el linear retriever se puede integrar en cualquier nivel de un árbol jerárquico de retriever, con soporte para explicabilidad, resaltado de coincidencias, colapso de campo y más.

Cuándo elegir el retriever lineal y por qué marca la diferencia

El linear retriever:

• Preserva la importancia relativa al aprovechar los puntajes reales, no solo los rangos.

• Permite el ajuste fino con contribuciones ponderadas de diferentes consultas.

• Mejora la coherencia mediante la normalización, lo que hace que la búsqueda híbrida sea más estable y previsible.

Conclusión

El recuperador de linear ya está disponible en Elasticsearch Serverless y en las versiones 8.18 y 9.0. También se pueden encontrar más ejemplos y parámetros de configuración en nuestra documentación. Pruébelo y vea cómo puede mejorar su experiencia de búsqueda híbrida: esperamos sus comentarios. ¡Feliz búsqueda!