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.

Una nueva forma de interactuar con los datos

La IA generativa (genIA) y la IA agente hacen las cosas de forma diferente a la búsqueda tradicional. Mientras que la forma en que empezábamos a investigar la información era buscando ("déjame buscar en Google..."), la acción inicial tanto para la IA de generación como para los Agentes suele ser mediante lenguaje natural introducido en una interfaz de chat. La interfaz de chat es una discusión con un LLM que emplea su comprensión semántica para convertir nuestra pregunta en una respuesta destilada, una respuesta resumida que aparentemente proviene de un oráculo que tiene un amplio conocimiento de todo tipo de información. Lo que realmente lo vende es la capacidad del LLM para generar frases coherentes y reflexivas que enlazan los fragmentos de conocimiento que saca a la luz — incluso cuando son inexactas o totalmente alucinadas, tienen cierta veracidad .

Esa vieja barra de búsqueda con la que estábamos tan acostumbrados a interactuar puede considerar el motor RAG que usábamos cuando nosotros mismos éramos el agente de razonamiento. Ahora, incluso los motores de búsqueda de Internet están convirtiendo nuestra experiencia léxica de búsqueda "caza y picotea" en una visión general impulsada por IA que responde a la consulta con un resumen de los resultados, ayudando a los usuarios a evitar la necesidad de hacer clic y evaluar los resultados individuales por sí mismos.

IA generativa y RAG

La IA generativa intenta usar su comprensión semántica del mundo para analizar la intención subjetiva expresada a través de una solicitud de chat, y luego emplea sus habilidades de inferencia para crear una respuesta experta sobre la marcha. Hay varias partes en una interacción generativa con IA: comienza con la entrada/consulta del usuario, conversaciones previas en la sesión de chat pueden usar como contexto adicional, y el prompt instructivo que indica al LLM cómo razonar y qué procedimientos seguir para construir la respuesta. Los prompts evolucionaron desde simples "explícame esto como si tuviera cinco años" a desglosar completos sobre cómo procesar solicitudes. Estos desgloses suelen incluir secciones distintas que describen detalles de la persona/rol de la IA, razonamiento pregeneración/proceso de pensamiento interno, criterios objetivos, restricciones, formato de salida, audiencia, así como ejemplos para ayudar a demostrar los resultados esperados.

Además de la consulta del usuario y el prompt del sistema, la generación aumentada por recuperación (RAG) proporciona información contextual adicional en lo que se denomina una "ventana de contexto". RAG fue una adición fundamental a la arquitectura; es lo que usamos para informar al LLM sobre las piezas que faltan en su comprensión semántica del mundo.

Las ventanas de contexto pueden ser un poco quisquillosas en cuanto a qué, dónde y cuánto les das. Qué contexto se selecciona es muy importante, por supuesto, pero también importa la relación señal-ruido del contexto proporcionado, así como la duración de la ventana.

Muy poca información

Proporcionar muy poca información en una consulta, una indicación o una ventana de contexto puede provocar alucinaciones porque el LLM no puede determinar con precisión el contexto semántico correcto desde el que generar una respuesta. También existen problemas con la similitud vectorial de los tamaños de fragmentos de documentos: una pregunta corta y sencilla puede no coincidir semánticamente con los documentos completos y detallados que encontramos en nuestras bases de conocimiento vectorizadas. Se desarrollaron técnicas de expansión de consultas como los Embeddings de Documentos Hipotéticos (HyDE) que emplean LLMs para generar una respuesta hipotética más rica y expresiva que la consulta corta. El peligro aquí, por supuesto, es que el documento hipotético es en sí mismo una alucinación que aleja aún más al LLM del contexto correcto.

Demasiada información

Al igual que nos pasa a los humanos, demasiada información en una ventana de contexto puede abrumar y confundir a un LLM sobre cuáles deberían ser las partes importantes. El desbordamiento de contexto (o "podredumbre del contexto") afecta a la calidad y el rendimiento de las operaciones de IA generativa; afecta enormemente a la "cotización de atención" del LLM (su memoria de trabajo) y diluye la relevancia entre muchos tokens competidores. El concepto de "podredumbre del contexto" también incluye la observación de que los LLMs tienden a tener un sesgo posicional : prefieren el contenido al principio o al final de una ventana de contexto sobre el contenido de la sección central.

Información que distrae o contradice

Cuanto más grande es una ventana de contexto, más posibilidades hay de que incluya información superflua o contradictoria que pueda distraer al LLM de seleccionar y procesar el contexto correcto. En cierto modo, se convierte en un problema de basura entrando y saliendo basura: simplemente volcar un conjunto de documentos resulta en una ventana de contexto le da al LLM mucha información para analizar (potencialmente demasiado), pero dependiendo de cómo se seleccionó el contexto hay una mayor posibilidad de que se filtre información contradictoria o irrelevante.

Agentic AI

Te dije que había mucho por cubrir, pero lo conseguimos — ¡por fin estamos hablando de temas de IA agente! La IA Agente es un uso muy emocionante de las interfaces de chat LLM que amplía la capacidad de la IA generativa (¿podemos llamarla ya "legado"?) para sintetizar respuestas basar en su propio conocimiento y la información contextual que proporcionas. A medida que la IA generativa maduraba, nos dimos cuenta de que había un cierto nivel de tareas y automatización que podíamos hacer con los LLMs, inicialmente relegados a actividades tediosas y de bajo riesgo que un humano podía comprobar o validar fácilmente. En un corto periodo de tiempo, ese alcance inicial creció: una ventana de chat de un LLM puede ahora ser la chispa que envíe a un agente de IA para planear, ejecutar y evaluar iterativamente su plan para lograr su objetivo especificado. Los agentes tienen acceso al razonamiento propio de sus LLMs, al historial de chat y a la memoria de pensamiento (tal como es), y también disponen de herramientas específicas que pueden emplear para ese objetivo. También estamos viendo arquitecturas que permiten a un agente de alto nivel actuar como orquestador de múltiples subagentes, cada uno con sus propias cadenas lógicas, conjuntos de instrucciones, contexto y herramientas.

Los agentes son el punto de entrada a un flujo de trabajo mayormente automatizado: son autodirigidos en el sentido de que pueden chatear con un usuario y luego usar la 'lógica' para determinar qué herramientas tienen disponibles para ayudar a responder a la pregunta del usuario. Las herramientas suelen considerar pasivas en comparación con los agentes y están diseñadas para realizar un solo tipo de tarea. Los tipos de tareas que una herramienta puede realizar son bastante ilimitados (¡lo cual es realmente emocionante!), pero una tarea principal que realizan las herramientas es recopilar información contextual para que un agente la tenga en cuenta al ejecutar su flujo de trabajo.

Como tecnología, la IA agente aún está en pañezas y propensa al equivalente LLM del trastorno por déficit de atención: olvida fácilmente lo que se le pide hacer y a menudo se escapa a hacer otras cosas que no formaban parte del encargo. Bajo la aparente magia, las habilidades de "razonamiento" de los LLM siguen basar en predecir el siguiente token más probable en una secuencia. Para que el razonamiento (o algún día, la inteligencia artificial general (AGI)) sea fiable y digno de confianza, necesitamos poder verificar que, cuando se nos da la información correcta y más actualizada, razonarán como esperamos (y quizás nos darán ese poco más que quizá no pensamos). Para que eso ocurra, las arquitecturas agenticas necesitarán la capacidad de comunicar claramente (protocolos), adherir a los flujos de trabajo y restricciones que les damos (barreras de seguridad), recordar en qué punto de una tarea (estado) se sienten, gestionar su espacio de memoria disponible y validar que sus respuestas son precisas y cumplen los criterios de la tarea.

Háblame en un idioma que pueda entender

Como es habitual en nuevas áreas de desarrollo (especialmente en el mundo de los LLM), inicialmente existían bastantes enfoques para la comunicación agente-herramienta, pero rápidamente convergieron hacia el Protocolo de Contexto del Modelo (MCP) como estándar de facto. La definición de Protocolo de Contexto de Modelo está realmente en el nombre: es el protocolo que emplea un modelo para aplicar y recibir información contextual . MCP actúa como un adaptador universal para que los agentes LLM se conecten a herramientas externas y fuentes de datos; simplifica y estandariza las APIs para que diferentes frameworks y herramientas de LLM puedan interoperar fácilmente. Eso convierte a MCP en una especie de punto de pivote entre la lógica de orquestación y los indicios del sistema dados a un agente para actuar de forma autónoma al servicio de sus objetivos, y las operaciones enviadas a las herramientas para que se ejecuten de forma más aislada (aislada al menos respecto al agente iniciador).

Este ecosistema es tan nuevo que cada dirección de expansión se siente como una nueva frontera. Tenemos protocolos similares para interacciones agente a agente (Agent2Agent (A2A , por supuesto!) así como otros proyectos para mejorar la memoria de razonamiento de agentes (ReasoningBank), para seleccionar el mejor servidor MCP para el trabajo en cuestión (RAG-MCP), y usar análisis semántico como la clasificación zero-shot y la detección de patrones en entrada y salida como Guardrails para controlar sobre qué puede operar un agente.

Quizá notaste que la intención subyacente de cada uno de estos proyectos es mejorar la calidad y el control de la información que se devuelve en una ventana de contexto agente/genAI. Aunque el ecosistema de IA agente continúa desarrollando la capacidad de manejar mejor esa información contextual (para controlarla, gestionar y operar sobre ella), siempre habrá necesidad de recuperar la información contextual más relevante como materia para que el agente siga adelante.

¡Bienvenido a la ingeniería de contexto!

Si conoces los términos de IA generativa, probablemente oíste hablar de la 'ingeniería de prompts'; a estas alturas, es casi una pseudociencia en sí misma. La ingeniería de prompts se emplea para encontrar las mejores y más eficientes formas de describir proactivamente los comportamientos que quieres que el LLM emplee para generar su respuesta. La 'ingeniería de contexto' extiende las técnicas de 'ingeniería de prompts' más allá del lado del agente para cubrir también las fuentes y sistemas de contexto disponibles en el lado de herramientas del protocolo MCP, e incluye los temas generales de gestión, procesamiento y generación de contexto:

• Gestión del contexto - Relacionada con mantener el estado y la eficiencia del contexto en flujos de trabajo agentivos de larga duración y/o más complejos. Planeación iterativa, seguimiento y orquestación de tareas y llamada a herramientas para lograr los objetivos del agente. Debido a la limitada "cotización de atención" que los agentes deben trabajar, la gestión del contexto se centra principalmente en técnicas que ayudan a refinar la ventana de contexto para capturar tanto el alcance más completo como los aspectos más importantes del contexto (¡su precisión frente a la memoria!). Las técnicas incluyen compresión, resumen y persistencia de contexto de pasos previos o llamadas a herramientas para dejar espacio en la memoria de trabajo para contexto adicional en los pasos posteriores.

• Procesamiento de contexto : los pasos lógicos y, con suerte, mayormente programáticos para integrar, normalizar o refinar el contexto adquirido de fuentes dispares, de modo que el agente pueda razonar a través de todo el contexto de manera más o menos uniforme. El trabajo subyacente consiste en hacer que el contexto de todas las fuentes (prompts, RAG, memoria, etc.), todo sea consumible por el agente de la forma más eficiente posible.

• Generación de contexto - Si el procesamiento de contexto consiste en hacer que el contexto recuperado sea utilizable para el agente, entonces la generación de contexto le da al agente el alcance para aplicar y recibir esa información contextual adicional a voluntad, pero también con restricciones.

Los distintos efímeros de las aplicaciones de chat LLM se corresponden directamente (y a veces de formas superpuestas) a esas funciones de alto nivel de la ingeniería del contexto:

• Instrucciones / prompt del sistema - Los prompts son el marco de cómo la actividad generativa (o agente) de IA dirigirá su pensamiento hacia el logro del objetivo del usuario. Los prompts son contexto en sí mismos; No son solo instrucciones tonales: también suelen incluir lógica de ejecución de tareas y reglas para cosas como "pensar paso a paso" o "respirar hondo" antes de responder para validar que la respuesta responde completamente a la petición del usuario. Pruebas recientes demostraron que los lenguajes de marcado son muy eficaces para enmarcar las diferentes partes de un prompt, pero también hay que tener cuidado de calibrar las instrucciones para que quede en un punto óptimo entre demasiado vago y demasiado específico; queremos dar suficiente instrucción para que el LLM encuentre el contexto adecuado, pero sin ser tan prescriptivo que pierda ideas inesperadas.

• Memoria a corto plazo (estado/historial) - La memoria a corto plazo es esencialmente la interacción de la sesión de chat entre el usuario y el LLM. Estos son útiles para refinar el contexto en sesiones en tiempo real y pueden almacenar para su recuperación y continuación futuras.

• Memoria a largo plazo - La memoria a largo plazo debe consistir en información útil a lo largo de varias sesiones. Y no solo se accede a bases de conocimiento específicas de dominio a través de RAG; investigaciones recientes emplean los resultados de solicitudes previas de IA agente/generativa para aprender y referenciar dentro de las interacciones agentices actuales. Algunas de las innovaciones más interesantes en el ámbito de la memoria a largo plazo están relacionadas con ajustar cómo se almacena y enlaza el estado para que los agentes puedan retomar donde lo dejaron.

• Salida estructurada - La cognición requiere esfuerzo, así que probablemente no sea de extrañar que, incluso con capacidades de razonamiento, los LLMs (igual que los humanos) quieran gastar menos esfuerzo al pensar, y en ausencia de una API o protocolo definido, tener un mapa (un esquema) para leer los datos devueltos de una llamada a una herramienta es de gran ayuda. La inclusión de Salidas Estructuradas como parte del marco agential ayuda a hacer que estas interacciones máquina a máquina sean más rápidas y fiables, con menos necesidad de análisis sintáctico impulsado por el pensamiento.

• Herramientas disponibles - Las herramientas pueden hacer todo tipo de cosas, desde recopilar información adicional (por ejemplo, enviar consultas RAG a repositorios de datos empresariales o a través de APIs en línea) hasta realizar acciones automatizadas en nombre del agente (como reservar una habitación de hotel según los criterios de la solicitud del agente). Las herramientas también podrían ser subagentes con sus propias cadenas de procesamiento agenticos.

• Generación Aumentada por Recuperación (RAG) - Me gusta mucho la descripción de RAG como "integración dinámica del conocimiento". Como se describió antes, RAG es la técnica para proporcionar la información adicional a la que el LLM no tenía acceso cuando fue capacitado, o es una reiteración de las ideas que consideramos más importantes para obtener la respuesta correcta — la que es más relevante para nuestra consulta subjetiva.

¡Un poder cósmico fenomenal, un espacio vital diminuto!

¡La IA Agente tiene tantos reinos nuevos fascinantes y emocionantes por explorar! Todavía quedan muchos de los problemas tradicionales de recuperación y procesamiento de datos por resolver, pero también nuevas clases de desafíos que solo ahora se están exponiendo a la luz en la nueva era de los LLM. Muchos de los problemas inmediatos con los que lidiamos hoy están relacionados con la ingeniería de contexto, es decir, conseguir que los LLMs reciban la información contextual adicional que necesitan sin saturar su limitado espacio de memoria de trabajo.

La flexibilidad de los agentes semiautónomos que tienen acceso a una variedad de herramientas (y otros agentes) da lugar a tantas ideas nuevas para implementar IA que es difícil imaginar las diferentes formas en que podríamos unir las piezas. La mayor parte de la investigación actual se centra en el campo de la ingeniería del contexto y se centra en construir estructuras de gestión de memoria capaces de manejar y rastrear mayores cantidades de contexto — esto se debe a que los problemas de pensamiento profundo que realmente queremos que resuelvan los LLMs presentan una mayor complejidad y pasos de pensamiento multifásicos y de larga duración, donde la memoria es extremadamente importante.

Gran parte de la experimentación continua en el campo consiste en intentar encontrar la gestión óptima de tareas y configuraciones de herramientas para alimentar la boca agente. Cada llamada a una herramienta en la cadena de razonamiento de un agente genera un costo acumulado, tanto en términos de cálculo para realizar la función de esa herramienta como del impacto en la ventana de contexto limitada. Algunas de las técnicas más recientes para gestionar el contexto de agentes LLM provocaron efectos de cadena no intencionados como el "colapso del contexto", donde comprimir/resumir el contexto acumulado para tareas de larga duración se vuelve demasiado perdiente. El resultado deseado son herramientas que devuelvan un contexto conciso y preciso, sin que información extraña se filtre en el valioso espacio de memoria de la ventana de contexto.

Demasiadas posibilidades

Queremos separación de tareas con flexibilidad para reutilizar herramientas/componentes, así que tiene todo el sentido crear herramientas agentes dedicadas para conectar a fuentes de datos específicas: cada herramienta puede especializar en consultar un tipo de repositorio, un tipo de flujo de datos o incluso un caso de uso. Pero cuidado: en la lucha por ahorrar tiempo/dinero/demostrar que algo es posible, va a haber una fuerte tentación de usar los LLMs como herramienta de federación... Intenta no hacerlo, ¡ya pasamos por eso antes! La consulta federada actúa como un "traductor universal" que convierte una consulta entrante en la sintaxis que el repositorio remoto entiende, y luego tiene que racionalizar de alguna manera los resultados de múltiples fuentes para obtener una respuesta coherente. La federación como técnica funciona bien a pequeña escala, pero a gran escala y especialmente cuando los datos son multimodales, la federación intenta salvar brechas que son demasiado amplias.

En el mundo agente, el agente sería el federador y las herramientas (a través de MCP) serían las conexiones definidas manualmente con recursos dispares. Emplear herramientas dedicadas para llegar a fuentes de datos no conectadas puede parecer una forma poderosa de unir dinámicamente diferentes flujos de datos por consulta, pero usar herramientas para hacer la misma pregunta a múltiples fuentes probablemente acabará causando más problemas de los que resuelve. Cada una de esas fuentes de datos probablemente sean diferentes tipos de repositorios debajo, cada uno con sus propias capacidades para recuperar, clasificar y cerciorar los datos que contienen. Esas variaciones o "desajustes de impedancia" entre repositorios agregan carga de procesamiento, por supuesto. También pueden introducir información o señales contradictorias, donde algo aparentemente inocuo como un desalineamiento de puntaje podría desajustar radicalmente la importancia dada a un poco de contexto devuelto y afectar la relevancia de la respuesta generada al final.

El cambio de contexto también es difícil para las computadoras

Cuando envías a un agente en una misión, a menudo su primera tarea es encontrar todos los datos relevantes a los que tiene acceso. Al igual que ocurre con los humanos, si cada fuente de datos que el agente conecta a respuestas con respuestas disímiles y desagregadas, habrá carga cognitiva (aunque no exactamente del mismo tipo) asociada a extraer los fragmentos contextuales salientes del contenido recuperado. Eso lleva tiempo/cálculo, y cada pequeño detalle se acumula en la cadena lógica agentica. Esto lleva a la conclusión de que, al igual que se discute sobre MCP, la mayoría de las herramientas agenticas deberían comportar más como APIs — funciones aisladas con entradas y salidas conocidas, ajustadas para soportar las necesidades de diferentes tipos de agentes. Incluso nos estamos dando cuenta de que los LLM necesitan contexto para contexto — son mucho mejores conectando los puntos semánticos, especialmente cuando es una tarea como traducir lenguaje natural a sintaxis estructurada, cuando tienen un esquema al que referir (¡RTFM, sin duda!).

¡Séptima entrada!

Ahora cubrimos el impacto que los LLMs tuvieron en la recuperación y consulta de datos, así como cómo la ventana de chat está madurando hacia la experiencia de IA agente. Pongamos los dos temas juntos y veamos cómo podemos emplear nuestras nuevas capacidades de búsqueda y recuperación para mejorar nuestros resultados en ingeniería de contexto. ¡Pasando a la Parte III: ¡El poder de la búsqueda híbrida en la ingeniería de contexto!

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.