Cada año, los desastres naturales obligan a los gestores de emergencias, comandantes militares y oficiales de seguridad pública a tomar decisiones críticas en plazos ajustados. Estas decisiones suelen depender de cadenas de llamadas, hojas de cálculo y conocimiento institucional distribuido entre decenas de personas. La coordinación por sí sola consume un tiempo valioso.

Esta publicación demuestra cómo Elastic puede potenciar un sistema de coordinación agéntico con capacidad de respuesta ante desastres, que detecta amenazas, analiza la logística y actúa automáticamente. Para hacerlo concreto, creamos una simulación: un huracán ficticio de categoría 4 que amenaza la costa de Hampton Roads desencadena la reubicación automatizada de más de 137 000 personas en siete instalaciones militares.

Descargo de responsabilidad: Este es un escenario totalmente ficticio creado con fines de demostración. El huracán ELARA-26 no existe. Las ubicaciones de las instalaciones se basan en datos geográficos reales y disponibles públicamente (el set de datos Military Installations, Ranges, and Training Areas [MIRTA] del Departamento de Defensa de los EE. UU. [DoD]), pero todos los datos operativos, como el recuento de personal, la capacidad de alojamiento, los activos, los correos electrónicos de contacto y los perfiles de misión, son completamente ficticios. Nada en esta demostración refleja la preparación, la capacidad o los procedimientos operativos militares reales.

Por qué la respuesta automatizada ante desastres requiere coordinación geoespacial y agéntica

Cuando un desastre natural amenaza la infraestructura crítica, el desafío de coordinación es inmediato:

• ¿Qué instalaciones están en la zona de impacto?

• ¿Cuánto personal necesita trasladarse?

• ¿A dónde pueden ir? ¿Esas instalaciones tienen capacidad?

• ¿A quién se necesita notificar en este momento?

Estas preguntas no esperan. Tampoco deberían hacerlo las respuestas.

Despliega el pipeline: requisitos previos y configuración

Sigue las instrucciones aquí en el repositorio de ejemplo para desplegar un cluster local de Elastic con Elastic Inference Service (EIS) mediante Cloud Connect.

Cómo funciona el pipeline de respuesta ante desastres con agentes de Elasticsearch

El pipeline tiene siete capas que trabajan juntas de extremo a extremo:

1. Ingesta de datos: eventos de desastres del Sistema Mundial de Alerta y Coordinación de Desastres (GDACS) enviados a Elasticsearch

2. Pipeline de ingesta: GeoJSON se ingesta y normaliza a Elastic Common Schema (ECS).

3. Enriquecimiento geoespacial: el polígono del área afectada del evento se compara con los límites indexados de las instalaciones militares.

4. Alerting: una regla de detección de Kibana se activa cuando un desastre interseca cualquier instalación.

5. Automatización de flujos de trabajo: la alerta activa un flujo de trabajo de Kibana que inicia una conversación con un agente de AI.

6. Razonamiento de AI: el agente analiza las instalaciones afectadas, sus activos y las instalaciones de apoyo más cercanas para determinar cómo reubicar todos los activos y al personal.

7. Notificaciones por correo electrónico: el agente envía correos electrónicos a todos los destinatarios sobre la llegada y salida de personal o activos.

Revisemos cada capa.

Paso 1: indexar instalaciones militares con límites geográficos

La base es el set de datos MIRTA del DoD de source.coop/seerai/hifld. Este set de datos proporciona un geo_shape de tipo Point para cada instalación; coordenadas de centroide en lugar de polígonos de límites completos.

Cada documento de instalación en el índice mitra-facilities se enriquece con datos de perfil operativo (todos ficticios), más allá de lo que proporciona MIRTA:

Este índice enriquecido es lo que le permite al agente de AI tomar decisiones inteligentes de asignación; no solo “aquí hay bases cercanas”, sino “aquí hay bases con capacidad de alojamiento disponible, tipos de misión compatibles y la logística para recibir activos entrantes”.

Paso 2: ingestar y normalizar eventos de GDACS

GDACS publica GeoJSON en tiempo real para terremotos, ciclones tropicales, inundaciones, incendios forestales, volcanes y sequías. Ingestamos este feed en un flujo de datos (logs-gdacs.events-*) mediante un pipeline de ingesta personalizado que normaliza el GeoJSON sin procesar a campos de ECS.

El pipeline de ingesta de GDACS hace varias cosas que vale la pena destacar:

Extracción de geometría: el centroide se almacena como geo_point para la visualización en mapas, y el polígono de impacto se almacena como geo_shape en gdacs.affected_area, que es el campo que se utiliza para búsquedas de intersección más adelante.

Normalización de la gravedad: cada tipo de desastre tiene una escala de gravedad diferente. Un ciclón tropical se mide en velocidad del viento en km/h; un terremoto, en magnitud de Richter. El pipeline los mapea a todos a una puntuación normalizada de 0–100:

Luego, la puntuación de gravedad normalizada se mapea a una etiqueta severity_level (low, medium, high, critical) utilizada para el mapeo de gravedad de las alertas en la regla de detección.

Alineación con ECS: event.kind: alert, event.category: threat, marcas de tiempo asignadas a event.start/event.end, y un _id estable basado en una huella digital para la deduplicación.

Paso 3: enriquecimiento geoespacial: búsqueda de instalaciones afectadas al momento de la indexación

La política de enriquecimiento geo_match de Elasticsearch compara el polígono del desastre con el límite de cada instalación al momento de la indexación, sin necesidad de una unión en tiempo de búsqueda. En lugar de consultar durante la búsqueda, usamos un procesador de enriquecimiento en el pipeline de ingesta para comparar el polígono de impacto del desastre con el límite de cada instalación a medida que se indexa el documento.

La política de enriquecimiento es una política geo_match:

El procesador se ejecuta al final del pipeline de ingesta:

INTERSECTS detecta cualquier instalación cuyo límite toque o se superponga con el polígono de desastre, incluidas las intersecciones parciales. El resultado es que cada documento de evento de GDACS se almacena con un arreglo anidado affected_facilities que nos indica exactamente qué instalaciones se encuentran en la zona de impacto. No se necesita una búsqueda de unión.

Paso 4: regla de detección: alertas sobre el impacto en las instalaciones

Una regla de detección de Kibana monitorea el flujo de datos logs-gdacs.events-* y se activa cuando un evento de GDACS se ha enriquecido con información sobre al menos una instalación afectada:

La regla se ejecuta cada hora (cubre un intervalo de now-1h a now) y usa un mapeo dinámico de gravedad; el campo gdacs.severity_level calculado por el pipeline de ingesta determina automáticamente la gravedad de la alerta.

La gravedad de la alerta también determina la puntuación de riesgo mediante el mapeo de campos:

Cuando la regla se activa, envía todo el contexto de la alerta, incluido el arreglo enriquecido affected_facilities con los nombres, tipos y ubicaciones de las instalaciones, a un flujo de trabajo de Kibana para su procesamiento posterior.

Paso 5: automatización del flujo de trabajo: conectar la alerta con el agente

Los flujos de trabajo de Kibana gestionan la transferencia de la detección a la respuesta. El flujo de trabajo de respuesta ante desastres naturales se activa mediante la alerta:

Toda la carga útil de la alerta (tipo de desastre, gravedad, área afectada y la lista de instalaciones afectadas) se reenvía al agente de AI como contexto inicial. El agente se encarga del resto.

Paso 6: el agente de AI: de los datos a la acción coordinada

El agente mitra.response toma la carga útil completa de la alerta y, en un único ciclo agéntico, evalúa el alcance, encuentra instalaciones receptoras, asigna personal y envía notificaciones de evacuación y recepción, todo sin intervención humana.

El agente tiene dos herramientas disponibles:

• mitra.nearest_facilityrealiza una búsqueda en el índice mitra-facilities mediante una búsqueda geo_shape, ordenada por distancia desde una coordenada dada, y devuelve hasta 50 instalaciones activas cercanas con capacidad disponible.

• mitra.send_email itera sobre una arreglo JSON de objetos de instalaciones y envía notificaciones de evacuación o recepción con formato.

El conjunto de instrucciones del agente define un flujo de trabajo claro:

1. Evalúa la situación. Parsea la alerta, identifica las instalaciones afectadas y determina el alcance del desastre.

2. Haz un inventario de lo que se debe mover. Recuentos de personal, activos críticos, requisitos de alojamiento por instalación.

3. Encuentra instalaciones de destino. Invoca a mitra.nearest_facility para cada instalación afectada, sin incluir las que aún están en la zona de peligro.

4. Toma decisiones de asignación. Analiza soluciones que involucren una o varias instalaciones, la compatibilidad entre ramas de las fuerzas armadas, la capacidad de alojamiento y el apoyo para los activos.

5. Envía correos electrónicos de coordinación. Envía órdenes de evacuación a las instalaciones de origen y notificaciones de recepción a las instalaciones receptoras.

6. Genera un reporte resumido. Genera un breve resumen de todas las instalaciones afectadas, el total de personal, los activos trasladados, las instalaciones de destino y cualquier inquietud en el chat para su revisión.

La lógica de asignación del agente sigue restricciones del mundo real: no exceder la capacidad de alojamiento, dar preferencia a las reubicaciones dentro de la misma rama de las fuerzas armadas cuando sea posible, usar bases conjuntas para alojar al personal de distintas ramas que exceda la capacidad de otras instalaciones y priorizar la distancia para minimizar el tiempo de traslado.

La herramienta de instalación más cercana

La búsqueda subyacente del flujo de trabajo usa geo_shape con un filtro de círculo y ordenamiento por _geo_distance:

La capacidad disponible se calcula en el momento de la búsqueda mediante un campo de script que calcula la capacidad de alojamiento menos el recuento de personal actual. El agente usa esto para asignar personal entre destinos sin exceder los límites.

Huracán ELARA-26: coordinación agéntica de 137 000 efectivos, de extremo a extremo

El huracán ELARA-26 es una tormenta de categoría 4 (vientos máximos de 213 km/h) que se prevé que toque tierra en el área de Hampton Roads de Virginia. Cuando se ingiere el evento de GDACS, el polígono del área afectada interseca siete instalaciones militares principales de la región. La regla de detección se activa. El flujo de trabajo inicia una conversación del agente.

Dentro de un solo ciclo agéntico, el agente:

• Identificó siete instalaciones en la zona de impacto, con un total combinado de 137 372 miembros del personal.

• Llamó a mitra.nearest_facility para encontrar instalaciones receptoras fuera de la trayectoria de la tormenta.

• Distribuyó al personal entre nueve instalaciones receptoras en función de la capacidad de alojamiento disponible y la distancia.

• Generó y despachó órdenes de evacuación a las siete instalaciones afectadas.

• Generó y despachó notificaciones de recepción a las nueve instalaciones receptoras.

• Generó un resumen completo de coordinación, similar al siguiente:

Instalaciones evacuadas:

Instalación

Personal

Naval Station Norfolk

50 000

Joint Expeditionary Base Little Creek-Fort Story

18 000

Naval Air Station Oceana

15 355

Naval Air Station Oceana Dam Neck Annex

17 509

NG State Military Reservation Camp Pendleton

9707

Joint Base Langley-Eustis

15 000

Naval Weapons Station Yorktown

11 801

Instalaciones receptoras:

Instalación

Distancia

Personal entrante

Fort Gregg-Adams

97 km

~40 000

Marine Corps Base Quantico

148 km

~30 000

Naval Support Facility Indian Head

151 km

~30 000

Joint Base Andrews

180 km

~30 000

Naval Air Station Patuxent River

141 km

~10 000

NG MTA Camp Butner

174 km

~5000

NG Bethany Beach Training Site

209 km

~4707

Rivanna Station

140 km

~7500

Def Gen Supply Center

22 km

~6000

Los activos reubicados incluyen vehículos de transporte, helicópteros, lanchas patrulleras, unidades médicas, vehículos de ingeniería, generadores, remolques de agua, kits de refugio y sistemas de comunicación.

Notificaciones por correo electrónico automatizadas

Una vez que el agente finalizó su plan de asignación, invocó a mitra.send_email y envió 16 correos electrónicos en una sola pasada; es decir, órdenes de evacuación a las siete instalaciones afectadas y notificaciones de recepción a las nueve instalaciones receptoras. Cada mensaje incluía la instalación de destino, el recuento de personal entrante, los activos por trasladar y un contacto de coordinación. Lo que habría requerido horas de cadenas de llamadas se completó automáticamente en cuanto el agente terminó de razonar.

Ampliación de la respuesta agéntica ante desastres con RAG y fundamentación en políticas

Esta demostración se basa exclusivamente en datos estructurados, como cifras de capacidad, distancias y estado operativo. Las funcionalidades de búsqueda semántica y Retrieval Augmented Generation (RAG) de Elastic pueden hacer que el agente sea significativamente más inteligente, con dos adiciones:

Recuperación de respuestas históricas: indexa reportes posteriores a la acción, resúmenes de incidentes de la Agencia Federal para el Manejo de Emergencias (FEMA) y registros de respuesta ante desastres anteriores como incrustaciones vectoriales. Cuando se activa un evento nuevo, el agente puede recuperar semánticamente cómo se gestionaron eventos similares, lo que fundamenta las decisiones de asignación con conocimiento institucional en lugar de basarse únicamente en cálculos de capacidad.

Fundamentación en políticas y doctrina: indexa las directivas de gestión de emergencias del DoD, los planes de continuidad de las operaciones de la instalación y las directrices del comandante. El agente puede recuperar y citar las políticas reales que rigen una respuesta, lo que garantiza que cada decisión esté fundamentada en la doctrina en lugar de en inferencias.

Ambos siguen el mismo enfoque nativo de Elastic: un pipeline de inferencia genera incrustaciones al momento de la indexación, y se expone una herramienta de búsqueda semántica al agente. El pipeline de coordinación permanece igual. El agente simplemente se vuelve más inteligente.

Por qué Elasticsearch es la plataforma adecuada para la respuesta agéntica del sector público

Esto no es un chatbot. No es un dashboard. Es un sistema de flujo de trabajo agéntico con capacidad de respuesta, uno que detectó una amenaza, razonó sobre un problema logístico complejo y coordinó la reubicación de 137 000 personas sin intervención humana. Ese tipo de resultado solo es posible porque cada funcionalidad de la que depende reside en una sola plataforma unificada.

El soporte geoespacial de Elasticsearch (geo_point, geo_shape, políticas de enriquecimiento y ordenación basada en la distancia) gestiona el razonamiento espacial que hace posible la detección de intersecciones y la búsqueda de instalaciones a escala. La búsqueda semántica y las incrustaciones vectoriales proporcionan a los agentes una base factual, lo que garantiza que el razonamiento de la AI se apoye en el contenido real de tus datos y no en suposiciones producto de alucinaciones. El motor de detección de Kibana, Workflows, Agent Builder y las herramientas de Agent Builder lo integran todo en un pipeline que va desde el evento sin procesar hasta la acción coordinada, sin necesidad de código de integración externo.

Ninguna otra plataforma reúne esto como lo hace Elastic. La combinación de indexación en tiempo real, precisión geoespacial, recuperación semántica y orquestación agéntica, todo en un solo stack, con seguridad y observabilidad de nivel empresarial integradas, es lo que diferencia a Elastic de las herramientas que hacen bien una de estas cosas pero requieren que unas el resto por tu cuenta.

Respuesta geoespacial agéntica para la gestión de emergencias, bomberos, fuerzas del orden y salud pública

La misma arquitectura se aplica dondequiera que se crucen personas, instalaciones y eventos en tiempo real. Los datos específicos cambian. El pipeline no.

Gestión de emergencias: FEMA y las oficinas estatales de gestión de emergencias pueden mapear las ubicaciones de los refugios, las áreas de preparación y las poblaciones vulnerables con respecto a los polígonos de fenómenos meteorológicos adversos entrantes del Servicio Meteorológico Nacional (NWS), lo que activa el posicionamiento previo automatizado de recursos antes de que una tormenta toque tierra.

Servicios de bomberos y emergencias médicas: los departamentos de bomberos pueden superponer las ubicaciones de las unidades y las zonas de respuesta sobre los perímetros de incendios forestales o las agrupaciones de incendios estructurales, y dirigir automáticamente las solicitudes de ayuda mutua a las unidades disponibles más cercanas que cuenten con el equipo adecuado.

Fuerzas del orden: las agencias pueden correlacionar las ubicaciones de incidentes activos con zonas escolares, infraestructura crítica y posiciones de los oficiales, lo cual activa notificaciones de confinamiento con reconocimiento geográfico o el despacho de recursos sin esperar la clasificación manual.

Seguridad en las escuelas públicas: los distritos escolares pueden monitorear datos de amenazas en tiempo real y compararlos con los límites de los recintos escolares. Cuando una amenaza cruza el perímetro de una escuela, un agente puede notificar de inmediato a la administración, iniciar las comunicaciones de cierre de emergencia y coordinar la respuesta de las fuerzas del orden, todo antes de que un despachador atienda el teléfono.

Salud pública: los departamentos de salud pueden cotejar datos de vigilancia de enfermedades o zonas de riesgo ambiental con ubicaciones de clínicas, capas de densidad poblacional e inventarios de depósitos de suministros para dirigir los recursos donde más se necesitan.

Sector

Caso de uso

Capacidad de Elastic

Gestión de emergencias

Hacer coincidir las ubicaciones de los refugios con los polígonos de fenómenos meteorológicos adversos del NWS

Enriquecimiento de geo_shape + flujos de trabajo de Kibana

Bomberos y EMS

Superponer las ubicaciones de las unidades sobre los perímetros de incendios forestales

enrutamiento geoespacial + búsqueda de la instalación más cercana

Fuerzas del orden

Correlacionar incidentes con zonas escolares y posiciones de oficiales

reglas de alerta con reconocimiento geográfico + envío de recursos mediante el agente

Seguridad en las escuelas públicas

Monitorear las fuentes de amenazas contra los perímetros del campus

reglas de detección + notificación automatizada

Salud pública

Comparar las zonas de peligro con las ubicaciones de las clínicas y los depósitos de suministros

búsqueda semántica + enriquecimiento geoespacial

Los datos son diferentes en cada escenario. El patrón subyacente de ingestar, enriquecer en tiempo de indexación, detectar intersecciones, activar una respuesta agéntica y actuar es exactamente el mismo. Elastic brinda a las organizaciones del sector público la plataforma para crearlo una vez y adaptarlo en todas partes.

El lanzamiento de cualquiera de las características o funcionalidades descritas en esta publicación, así como su fecha, quedan a exclusivo criterio de Elastic. Es posible que algunas características o funcionalidades que no estén disponibles en este momento no se lancen a tiempo o no se lancen en absoluto.

Recientemente, contribuimos al proyecto de mastra-ai/mastra open source agregando soporte para Elasticsearch como base de datos vectorial. Con esta nueva característica, puedes usar Elasticsearch de forma nativa en Mastra para almacenar incrustaciones. Además de los vectores, Elasticsearch ofrece un conjunto de funciones avanzadas para satisfacer todas tus necesidades de ingeniería de contexto (por ejemplo, búsqueda híbrida y reordenamiento).

En este artículo, se detalla la creación de un agente para implementar una arquitectura de Retrieval-Augmented Generation (RAG) con Elasticsearch. Te mostraremos un proyecto de demostración en el que se utiliza un enfoque agéntico para interactuar con un corpus de datos de películas de ciencia ficción almacenados en Elasticsearch. El proyecto está disponible en elastic/mastra-elasticsearch-example.

Mastra

Mastra es un marco de trabajo de TypeScript para crear aplicaciones de IA agéntica.

Una estructura de proyecto en Mastra se ve así:

En Mastra, puedes crear agentes, herramientas, flujos de trabajo y puntajes.

Un agente es una clase que acepta un mensaje como entrada y produce una respuesta como salida. Un agente puede usar herramientas, modelos de lenguaje a gran escala (LLM) y una memoria (figura 1).

Las herramientas de un agente le permiten interactuar con el "mundo externo", como comunicarse con una API web o hacer una operación interna, como consultar Elasticsearch. El componente de memoria es crucial para almacenar el historial de conversaciones, incluidas las entradas y salidas pasadas. Este contexto almacenado permite que el agente proporcione respuestas más informadas y relevantes a preguntas futuras mediante el uso de sus interacciones pasadas.

Los flujos de trabajo te permiten definir secuencias complejas de tareas mediante pasos claros y estructurados, en lugar de depender del razonamiento de un solo agente (figura 2). Te brindan control total sobre cómo se desglosan las tareas, cómo se mueven los datos entre ellas y qué se ejecuta y cuándo. Los flujos de trabajo se ejecutan con el motor de ejecución integrado de forma predeterminada o se pueden desplegar en ejecutores de flujos de trabajo.

En Mastra, también puedes definir puntuaciones, que son pruebas automatizadas que evalúan las salidas de los agentes mediante métodos calificados por modelos, basados en reglas y estadísticos. Los evaluadores devuelven puntuaciones: valores numéricos (normalmente entre 0 y 1) que cuantifican qué tan bien una salida cumple con tus criterios de evaluación. Estas puntuaciones te permiten hacer un seguimiento objetivo del rendimiento, comparar diferentes enfoques e identificar áreas de mejora en tus sistemas de IA. Los evaluadores pueden personalizarse con tus propias solicitudes y funciones de puntuación.

Elasticsearch

Para ejecutar el proyecto de demostración, necesitamos tener una instancia de Elasticsearch en ejecución. Puedes activar una prueba gratis en Elastic Cloud o instalarlo localmente usando el script start-local:

Se instalarán Elasticsearch y Kibana en tu computadora y se generará una clave API que se utilizará para configurar la integración de Mastra.

La clave de API se mostrará como salida del comando anterior y se almacenará en un archivo .env en la carpeta elastic-start-local.

Instalar y configurar la demo

Creamos un repositorio elastic/mastra-elasticsearch-example que contiene el código fuente del proyecto de demostración. El ejemplo reportado en el repositorio ilustra cómo crear un agente en Mastra que implemente una arquitectura RAG para recuperar documentos de Elasticsearch.

Proporcionamos un set de datos para la demostración sobre películas de ciencia ficción. Extrajimos 500 películas de los sets de datos de IMDb en Kaggle.

El primer paso es instalar las dependencias del proyecto con npm, usando el siguiente comando:

Luego tenemos que configurar el archivo .env que contendrá la configuración. Podemos generar este archivo copiando la estructura del archivo .env.example , usando el siguiente comando:

Ahora podemos editar el archivo .env, agregando la información faltante:

El nombre del índice de Elasticsearch es scifi-movies. Si quieres, puedes cambiarlo usando la variable de entorno ELASTICSEARCH_INDEX_NAME.

Usamos OpenAI como servicio de incrustación, lo que significa que necesitas proporcionar una clave API para OpenAI en la variable OPENAI_API_KEY .env.

El modelo de incrustación empleado en el ejemplo es openai/text-embedding-3-small, con una dimensión de incrustación de 1536.

Para generar la respuesta final, empleamos el modelo openai/gpt-5-nano para reducir costos.

La arquitectura RAG te permite usar un modelo LLM final menos potente (y generalmente menos costoso) porque el trabajo pesado de fundamentar la respuesta está a cargo del componente de recuperación (Elasticsearch en este caso).

El LLM más pequeño solo se encarga de dos tareas principales:

• Reformulación/incrustación de la consulta: Convertir la pregunta en lenguaje natural del usuario en una incrustación de vectores para la búsqueda semántica.

• Sintetizar la respuesta: Se toman los fragmentos de contexto muy relevantes y recuperados (documentos/películas) y se los sintetiza en una respuesta coherente, final y legible por seres humanos, siguiendo las instrucciones del prompt proporcionado.

Dado que el proceso RAG proporciona el contexto fáctico exacto necesario para la respuesta, el LLM final no necesita ser masivo o muy complejo y no necesita poseer todo el conocimiento requerido dentro de sus propios parámetros (que es donde sobresalen los modelos grandes y caros). Esencialmente actúa como un sofisticado resumidor y formateador de texto para el contexto proporcionado por Elasticsearch, en lugar de ser una base de conocimientos completa en sí mismo. Esto permite el uso de modelos como gpt-5-nano para optimizar costos y latencia.

Después de la configuración del archivo .env, puedes ingestar las películas a Elasticsearch usando el siguiente comando:

Deberías ver una salida como la siguiente:

El mapping del índice de películas de ciencia ficción contiene los siguientes campos:

• incrustación, dense_vector con 1536 dimensiones, similitud del coseno.

• descripción, texto que contiene la descripción de la película.

• director, texto que contiene el nombre del director.

• título, texto que contiene el título de la película.

Generamos las incrustaciones usando el título + la descripción. Como el título y la descripción son dos campos separados, la concatenación de ambos asegura que el vector de incrustación resultante capture tanto la identidad única y específica (título) como el contexto rico y descriptivo (descripción) de la película, lo que lleva a resultados de búsqueda semántica más precisos y completos. Esta entrada combinada le brinda al modelo de incrustación una mejor representación del contenido del documento para la búsqueda por similitud.

Ejecuta la demostración

Puedes ejecutar la demo con el siguiente comando:

Este comando iniciará una aplicación web en localhost:4111 para acceder a Mastra Studio (figura 3).

Mastra Studio ofrece una UI interactiva para crear y probar tus agentes, junto con una API REST que expone tu aplicación Mastra como un servicio local. Esto te permite comenzar a construir de inmediato sin preocuparte por la integración.

Proporcionamos un Agente Elasticsearch que emplea createVectorQueryTool de Mastra como herramienta para ejecutar búsqueda semántica usando Elasticsearch. Este agente emplea el enfoque RAG para buscar documentos relevantes (es decir, películas) que respondan a la pregunta del usuario.

Este agente usa el siguiente prompt:

Si haces clic en el menú Mastra Studio > Agents y seleccionas Agente de Elasticsearch, puedes probar el agente usando un sistema de chat. Por ejemplo, puedes pedir información sobre películas de ciencia ficción con una pregunta como esta:

Encuentra 5 películas o series de TV sobre ovnis.

Notarás que el agente ejecutará el vectorQueryTool. Puedes hacer clic en la herramienta invocada para ver la entrada y la salida. Al final de la ejecución, el LLM responderá tu pregunta, dado el contexto que proviene del índice de películas de ciencia ficción de Elasticsearch (figura 4).

Mastra ejecuta los siguientes pasos internamente:

1. Conversión en vectores: La pregunta del usuario, Encuentra 5 películas o series de televisión sobre ovnis, se convierte en una incrustación de vectores mediante el modelo openai/text-embedding-3-small de OpenAI.

2. Búsqueda de vectores: Esta incrustación se usa luego para hacer una búsqueda en Elasticsearch mediante una búsqueda de vectores.

3. Recuperación de resultados: Elasticsearch devuelve una serie de 10 películas muy relevantes para la consulta (es decir, aquellas con vectores más cercanos al vector de consulta del usuario).

4. Generación de respuestas: Las películas recuperadas y la pregunta original del usuario se envían al LLM, específicamente openai/gpt-5-nano. El LLM procesa esta información y genera una respuesta final, asegurando que se cumpla la solicitud del usuario para cinco resultados.

El agente de Elasticsearch

Aquí presentamos el código fuente del agente de Elasticsearch.

El vectorQueryTool es la herramienta que se invoca para implementar la parte de recuperación del ejemplo de RAG. Emplea la implementación de ElasticSearchVector que Elastic aportó a Mastra.

El agente es un objeto de la clase agente que utiliza la herramienta vectorQueryTool, el prompt y una memoria. Como puedes ver, el código que necesitamos implementar para conectar Elasticsearch a un agente es muy sencillo.

Conclusión

En este artículo, se demostró la simplicidad y el poder de integrar Elasticsearch con el marco de trabajo Mastra para construir sofisticadas aplicaciones de IA agéntica. En concreto, te mostramos cómo crear un agente RAG capaz de efectuar búsquedas semánticas sobre un corpus de datos de películas de ciencia ficción indexados en Elasticsearch.

Una de las principales conclusiones es la contribución directa de Elastic al proyecto de código abierto Mastra, que ofrece compatibilidad nativa con Elasticsearch como almacén de vectores. Esta integración reduce considerablemente las barreras de acceso, como se puede ver en el código fuente del agente de Elasticsearch. Usando el ElasticSearchVector y createVectorQueryTool, la configuración completa para conectar Elasticsearch a tu agente requiere solo un número mínimo de líneas de código de configuración.

Elasticsearch ofrece varias características avanzadas para mejorar la relevancia de los resultados. Por ejemplo, la búsqueda híbrida aumenta significativamente la precisión combinando la búsqueda léxica con la búsqueda de vectores. Otra característica interesante es la reclasificación con los últimos modelos de Jina, que puede aplicarse al final de la búsqueda híbrida. Para obtener más información sobre estas técnicas, consulta los siguientes artículos de Elasticsearch Labs:

• Búsqueda híbrida Elasticsearch de Valentin Crettaz

• Introducción a los modelos de Jina, su funcionalidad y usos en Elasticsearch de Scott Martens

También te animamos a consultar el ejemplo proporcionado y comenzar a crear tus propios agentes basados en datos con Mastra y Elasticsearch. Para más información sobre Mastra, puedes consultar la documentación oficial aquí.

En este artículo, exploraremos las ventajas de construir un servidor MCP personalizado de Elasticsearch y mostraremos cómo crear uno en TypeScript que conecte Elasticsearch con aplicaciones impulsadas por LLM.

¿Por qué construir un servidor MCP personalizado de Elasticsearch?

Elastic ofrece algunas alternativas para los servidores MCP:

• Servidor MCP de Elastic Agent Builder para Elasticsearch 9.2+

• Servidor MCP de Elasticsearch para versiones anteriores (Python)

Si necesitas más control sobre cómo tu servidor MCP interactúa con Elasticsearch, construir tu propio servidor personalizado te da la flexibilidad de adaptarlo exactamente a tus necesidades. Por ejemplo, el endpoint MCP de Agent Builder está limitado a las consultas de lenguaje de búsqueda (ES|QL) de Elasticsearch, mientras que un servidor personalizado te permite usar el DSL de consulta completo. También obtienes control sobre cómo se formatean los resultados antes de pasarlos al LLM y puedes integrar pasos de procesamiento adicionales, como el resumen impulsado por OpenAI que implementaremos en este tutorial.

Al final de este artículo, tendrás un servidor MCP en TypeScript que busca información almacenada en un índice de Elasticsearch, la resume y proporciona citas. Usaremos Elasticsearch para la recuperación, el modelo gpt-4o-mini de OpenAI para resumir y generar citas, y Claude Desktop como cliente MCP y UI para recibir las búsquedas de los usuarios y dar respuestas. El resultado final es un asistente de conocimiento interno que ayuda a los ingenieros a descubrir y sintetizar las mejores prácticas en los documentos técnicos de su organización.

Requisitos previos:

• Node.js 20 +

• Elasticsearch

• Clave de API de OpenAI

• Claude Desktop

¿Qué es MCP?

MCP es un estándar abierto, creado por Anthropic, que ofrece conexiones seguras y bidireccionales entre los modelos de lenguaje grande (LLM) y sistemas externos, como Elasticsearch. Puedes leer más sobre el estado actual del MCP en este artículo.

El panorama de MCP evoluciona cada día, con servidores disponibles para una amplia gama de casos de uso. Además de eso, desarrollar tu propio servidor MCP personalizado es fácil, como te mostraremos en este artículo.

Clientes del MCP

Hay una larga lista de clientes del MCP disponibles, cada uno con sus propias características y limitaciones. Por su sencillez y popularidad, usaremos Claude Desktop como nuestro cliente MCP. Servirá como interfaz de chat en la que los usuarios podrán hacer preguntas en lenguaje natural e invocar automáticamente las herramientas expuestas por nuestro servidor MCP para buscar documentos y generar resúmenes.

Cómo crear un servidor MCP de Elasticsearch

Con el SDK de TypeScript, podemos crear fácilmente un servidor que entiende cómo hacer búsquedas en nuestros datos de Elasticsearch con base en la entrada de búsqueda del usuario.

Estos son los pasos en este artículo para integrar el servidor MCP de Elasticsearch con el cliente Claude Desktop:

1. Configurar el servidor MCP para Elasticsearch.

2. Carga el servidor MCP en Claude Desktop.

3. Pruébalo.

Configurar el servidor MCP para Elasticsearch

Para comenzar, inicialicemos una aplicación de nodo:

Esto creará un archivo package.json y, con él, podremos empezar a instalar las dependencias necesarias para esta aplicación.

• @elastic/elasticsearch nos dará acceso a la biblioteca de Elasticsearch para Node.js.

• @modelcontextprotocol/sdk proporciona las herramientas básicas para crear y administrar un servidor MCP, registrar herramientas y manejar la comunicación con los clientes de MCP.

• openAI permite la interacción con modelos OpenAI para generar resúmenes o respuestas en lenguaje natural.

• zodayuda a definir y validar esquemas estructurados para los datos de entrada y salida en cada herramienta.

ts-node, @types/node y typescript se usarán durante el desarrollo para escribir el código y compilar los scripts.

Configura los sets de datos

Para proporcionar los datos que Claude Desktop puede consultar con nuestro servidor de MCP, utilizaremos un conjunto de datos de base de conocimiento interna simulado. Así es como se verá un documento de este sets de datos:

Para cargar los datos, preparamos un script que cree un índice en Elasticsearch y cargue el set de datos en él. Puedes encontrarlo aquí.

Servidor MCP

Crea un archivo llamado index.ts y agrega el siguiente código para importar las dependencias y gestionar las variables de entorno:

Además, preparemos a los clientes para que gestionen las llamadas a Elasticsearch y OpenAI:

Para hacer nuestra implementación más robusta y asegurar entradas y salidas estructuradas, definiremos esquemas usando zod. Esto nos permite validar los datos en tiempo de ejecución, detectar errores a tiempo y facilitar el procesamiento de las respuestas de la herramienta mediante código:

Descubre más sobre las salidas estructuradas aquí.

Ahora vamos a inicializar el servidor MCP:

Definición de las herramientas MCP

Ahora que ya tenemos todo configurado, podemos empezar a desarrollar las herramientas que ofrecerá nuestro servidor MCP. Este servidor ofrece dos herramientas:

• search_docs: Búsquedas de documentos en Elasticsearch mediante la búsqueda de texto.

• summarize_and_cite: Resume y sintetiza información de documentos previamente recuperados para responder a una pregunta del usuario. Esta herramienta también agrega citas que hacen referencia a los documentos originales.

Juntas, estas herramientas forman un flujo de trabajo simple de “recuperación y resumen”, donde una herramienta busca documentos relevantes y la otra usa esos documentos para generar una respuesta resumida y citada.

Formato de respuesta de herramienta

Cada herramienta puede aceptar parámetros de entrada arbitrarios, pero debe responder con la siguiente estructura:

• Contenido: esta es la respuesta de la herramienta en un formato no estructurado. Este campo se suele usar para mostrar texto, imágenes, audio, enlaces o contenido incrustado. Para esta aplicación, se utilizará para devolver texto formateado con la información generada por las herramientas.

• structuredContent: este es un retorno opcional que se usa para proporcionar los resultados de cada herramienta en un formato estructurado. Esto es útil para fines programáticos. Aunque no se usa en este servidor de MCP, puede ser útil si quieres desarrollar otras herramientas o procesar los resultados mediante programación.

Con esa estructura en mente, comencemos con cada herramienta en detalle.

Herramienta Search_docs

Esta herramienta realiza una búsqueda de texto completo en el índice de Elasticsearch para recuperar los documentos más relevantes según la consulta del usuario. Destaca los resultados clave y ofrece una visión general rápida con puntuaciones de relevancia.

Configuramos fuzziness: “AUTO” para que tenga una tolerancia tipográfica variable basada en la longitud del token que se está analizando. También establecemos title^2 para aumentar la puntuación de los documentos donde se produce la coincidencia en el campo de título.

herramienta de resumen y cita: summarize_and_cite

Esta herramienta genera un resumen basado en los documentos recuperados en la búsqueda anterior. Usa el modelo gpt-4o-mini de OpenAI para sintetizar la información más relevante y responder a la pregunta del usuario para obtener respuestas derivadas directamente de los resultados de búsqueda. Además del resumen, también devuelve metadatos de citas para los documentos fuente utilizados.

Finalmente, necesitamos iniciar el servidor a través de stdio. Esto significa que el cliente MCP se comunicará con nuestro servidor leyendo y escribiendo en sus flujos estándar de entrada y salida. stdio es la opción de transporte más sencilla y funciona bien para servidores MCP locales lanzados como subprocesos por el cliente. Agrega el siguiente código al final del archivo:

Ahora compila el proyecto usando el siguiente comando:

Esto creará una carpeta dist y, dentro de ella, un archivo index.js.

Carga el servidor MCP en Claude Desktop

Sigue esta guía para configurar el servidor MCP con Claude Desktop. En el archivo de configuración de Claude, tienes que establecer los siguientes valores:

El valor args debe apuntar al archivo compilado en la carpeta dist. También es necesario configurar las variables de entorno en el archivo de configuración con los mismos nombres exactos definidos en el código.

Pruébalo

Antes de ejecutar cada herramienta, haz clic en Búsqueda y herramientas para asegurarte de que las herramientas estén habilitadas. Aquí también puedes habilitar o deshabilitar cada una de ellas:

Finalmente, probemos el servidor MCP desde el chat de Claude Desktop y comencemos a hacer preguntas:

Para la consulta"Buscar documentos sobre métodos de autenticación y control de acceso basado en roles", se ejecuta la herramienta search_docs y arroja los siguientes resultados:

La respuesta es: “¡Genial! Encontré 5 documentos relevantes sobre métodos de autenticación y control de acceso basado en roles. Esto es lo que se encontró:”

La llamada a la herramienta devuelve los documentos de origen como parte de su carga útil de respuesta, que luego se utilizan para generar citas.

También es posible encadenar varias herramientas en una sola interacción. En este caso, Claude Desktop analiza la pregunta del usuario y determina que primero debe llamar a search_docs para recuperar documentos relevantes y luego pasar esos resultados a summarize_and_cite para generar la respuesta final, todo eso sin requerir indicaciones separadas del usuario:

En este caso, para la búsqueda: "¿Cuáles son las principales recomendaciones para mejorar la autenticación y el control de acceso en todos nuestros sistemas? Incluye referencias.", obtuvimos los siguientes resultados:

Al igual que en el paso anterior, podemos ver la respuesta de cada herramienta a esta pregunta:

Nota: si aparece un submenú que pregunta si apruebas el uso de cada herramienta, selecciona Permitir siempre o Permitir una vez.

Conclusión

Los servidores MCP representan un paso significativo hacia la estandarización de las herramientas LLM para aplicaciones tanto locales como remotas. Aunque la compatibilidad total todavía está en proceso, nos estamos moviendo rápido en esa dirección.

En este artículo, aprendimos cómo construir un servidor MCP personalizado en TypeScript que conecta Elasticsearch con aplicaciones impulsadas por modelos LLM. Nuestro servidor expone dos herramientas: search_docs para recuperar documentos relevantes con Query DSL y summarize_and_cite para generar resúmenes con citas a través de modelos de OpenAI y Claude Desktop como client UI.

El futuro de la compatibilidad entre los distintos proveedores de clientes y servidores parece prometedor. Los próximos pasos consisten en agregar más funcionalidades y flexibilidad a tu agente. Hay un artículo práctico sobre cómo puedes agregar parámetros a tus consultas a través de plantillas de búsqueda para ganar precisión y flexibilidad.

Esta publicación vuelve a centrarse en la pregunta:¿Cuáles son las interfaces de búsqueda adecuadas que necesita un agente para construir su propio contexto? Primero, cubre las disyuntivas entre las herramientas de shell y las herramientas de base de datos especiales. A partir de ahí, te ofrece un marco de trabajo práctico para encontrar las interfaces adecuadas a las necesidades de tu agente.

¿Qué significa realmente "construir contexto" para un agente?

En las primeras pipelines de retrieval augmented generation (RAG), el desarrollador diseñó un pipeline de recuperación fija y el modelo de lenguaje grande (LLM) era un receptor pasivo del contexto. Esta era una limitación fundamental: el contexto se recuperaba en cada consulta, fuera o no necesario, sin verificar que realmente ayudara.

Con el cambio a la RAG agéntica, los agentes ahora tienen acceso a un conjunto de herramientas de búsqueda para crear su propio contexto. Por ejemplo, tanto Claude Code [1] como Cursor [2] permiten que el agente elija entre diferentes herramientas de búsqueda e incluso las combine para consultas encadenadas, dependiendo de lo que la tarea realmente requiera.

¿Qué interfaces de búsqueda existen para la ingeniería del contexto?

El contexto puede estar en diferentes lugares, como en la web, en un sistema de archivos local o en una base de datos. Un agente puede interactuar con cada una de estas fuentes de datos fuera de contexto mediante diferentes herramientas:

• Las herramientas de shell pueden ejecutar comandos de shell y tener acceso al sistema de archivos local. Algunos ejemplos de herramientas de shell integradas son la herramienta bash de Claude API, la herramienta ejecutiva de OpenClaw y la herramienta de shell de LangChain.

• Las herramientas de base de datos especiales, como las herramientas de un servidor Model Context Protocol (MCP) (p. ej., el servidor MCP de Elastic Agent Builder) o las herramientas personalizadas (p. ej., run_esql(query) o db_list_index()), pueden consultar bases de datos.

• Las herramientas especiales de búsqueda de archivos pueden buscar y leer archivos locales (o subidos) (sin acceso completo al shell). Algunos ejemplos de herramientas de búsqueda de archivos integradas son Herramienta de búsqueda de archivos de Gemini API o Herramienta de búsqueda de archivos de OpenAI.

• Las herramientas de búsqueda web pueden recuperar información de la web.

• Las herramientas de memoria almacenan y recuperan de la memoria a largo plazo (independientemente de cómo se almacene).

Como puedes ver, la herramienta shell es versátil y se puede usar para recuperar contexto de diferentes fuentes de datos, incluyendo:

• Sistema de archivos: el agente explora la estructura de directorios (ls, find), busca contenido relevante (grep, cat) y repite hasta que ha construido suficiente contexto.

• Base de datos: el agente puede usar herramientas de interfaz de línea de comandos (CLI) para bases de datos (por ejemplo, elasticsearch-sql-cli), llamar al HTTP de la API mediante curl o ejecutar scripts, lo cual resulta especialmente útil en combinación con las habilidades del agente, que son ejemplos reutilizables y documentados que se incorporan al contexto del agente para guiar el uso correcto de las herramientas (por ejemplo, Elastic Agent Skills para Elasticsearch).

• Web: el agente puede ejecutar búsquedas web mediante un comando curl a través de la API de un proveedor de búsqueda.

Sin embargo, la herramienta de shell proporciona acceso directo al sistema y, por lo tanto, requiere medidas de seguridad, como ejecutarse en un entorno sandbox aislado y el logging de todos los comandos ejecutados.

Cuándo deberías usar ciertas interfaces de búsqueda

La interfaz de búsqueda adecuada depende de tus datos, tus patrones de consulta y tu caso de uso. Esta sección sirve como un punto de partida práctico.

Los sistemas de archivos no hacen que las bases de datos sean obsoletas.

La discusión entre sistemas de archivos y bases de datos no es sobre la capa de almacenamiento. Por ejemplo, LangChain explica que su sistema de memoria en realidad no almacena la memoria en un verdadero sistema de archivos. En su lugar, almacena la memoria en una base de datos y la representa como un conjunto de archivos para el agente [3].

Los sistemas de archivos son una opción natural para casos de uso nativos de archivos, como los agentes de codificación. También funcionan bien como bloc de notas temporal o memoria de trabajo, y en situaciones con un solo usuario o un solo agente en las que la concurrencia no es un problema. En estos casos, un sistema de archivos físico o representar los datos como un sistema de archivos te da flexibilidad antes de comprometerte con una interfaz diseñada específicamente para ello.

Pero el almacenamiento en sistemas de archivos tiene desventajas reales, como una concurrencia limitada, la aplicación manual de esquemas y las transacciones atómicas. Estos se vuelven más evidentes cuando tu aplicación necesita escalar o pasar a un escenario de múltiples agentes. Cualquiera que ignore estas desventajas está condenado a reinventar dolorosamente bases de datos peores sin las décadas de ingeniería detrás de la seguridad de transacciones o el control de acceso que las bases de datos de producción ya proporcionan. Además, en la mayoría de contextos empresariales, no eliges si usar una base de datos porque ya está ahí, almacenando datos críticos para el negocio.

Herramienta de shell + sistema de archivos

Una herramienta shell es el punto de partida natural para la búsqueda en sistemas de archivos. En la actualidad, los agentes de codificación están impulsando muchos avances en este campo. Como trabajan con código en archivos locales, son, por naturaleza, casos de uso que implican un gran volumen de archivos. Por lo tanto, los LLM se ajustan en la etapa posterior al entrenamiento para tareas de codificación. Es por eso que muchos LLMs no solo son buenos para escribir código, sino también para usar comandos de shell y navegar por sistemas de archivos.

Usar una herramienta de shell con CLI integradas, como ls y grep, para encontrar archivos es efectivo. Con grep, una consulta como "Encontrar todos los archivos que importan matplotlib" es rápida, precisa y económica. Pero cuando el agente necesita manejar consultas conceptuales, como "¿Cómo maneja nuestra app la falla de autenticación?", la coincidencia de patrones con grep puede alcanzar un límite rápidamente. Han surgido varias alternativas que incorporan capacidades de búsqueda semántica a la línea de comandos para cubrir esta carencia, incluidas jina-grep.

Sin embargo, grep y muchas de sus alternativas de búsqueda semántica se ejecutan en O(n) sobre el corpus. Para casos de uso sobre bases de código, esto podría estar bien. Sin embargo, si tus datos crecen, la latencia se notará. En este caso, un almacén de datos indexado se vuelve necesario para mantener el rendimiento.

Herramienta de shell + base de datos

Otra forma de agregar más capacidades de búsqueda, como la búsqueda semántica o híbrida, a tus datos es almacenarlos en una base de datos, como hace Cursor, por ejemplo. Además, cuando los datos requieren uniones relacionales o agregaciones complejas, una interfaz de base de datos es imprescindible.

Cuando los datos se almacenan en una base de datos en lugar de en el sistema de archivos, una herramienta de shell puede servir como una interfaz ligera de base de datos para ciertos casos de uso. Si tus consultas son lo suficientemente simples para una CLI o una llamada curl, una herramienta de base de datos especial podría añadir una complejidad innecesaria.

Este enfoque también es adecuado en las etapas iniciales de exploración, cuando aún no sabes qué patrones de consulta desarrollará tu agente. En este caso, Agent Skills puede darle al agente suficiente estructura para consultar correctamente sin comprometerse con una herramienta específica. Sin embargo, cuando el agente requiere muchas iteraciones para encontrar la forma correcta de consultar en la base de datos para tareas repetidas, la sobrecarga de tokens de usar una herramienta de línea de comandos como interfaz ya no justifica el beneficio de la simplicidad de evitar una herramienta adicional.

Herramienta especial de base de datos

Especialmente cuando los patrones de consulta repetidos son estructurados o analíticos, se hacen necesarias herramientas de base de datos especiales. Una publicación de blog de Vercel y Braintrust comparó a los agentes con diferentes conjuntos de herramientas de búsqueda para tareas de recuperación del mundo real en lugar de datos estructurados, como tickets de atención al cliente y transcripciones de llamadas de ventas (por ejemplo, “¿Cuántos problemas abiertos mencionan 'seguridad'?" o "¿Encontraste problemas en los que alguien reportó un error y luego alguien envió un PR diciendo que lo había arreglado?") [4].

Los agentes con herramientas de base de datos especiales utilizaron menos tokens, fueron más rápidos y cometieron menos errores que los agentes con solo una herramienta de shell y un sistema de archivos. La conclusión es que las herramientas de bases de datos directas son la opción correcta cuando la consulta requiere razonamiento analítico sobre datos semiestructurados.

Combinar interfaces de búsqueda

Ninguna interfaz de búsqueda gestiona bien todas las consultas. Por ejemplo, Cursor combina herramientas de shell (para búsquedas con grep) y herramientas de búsqueda semántica, y permite que el agente seleccione la herramienta correcta según el mensaje del usuario. Informa que el agente elige grep para hacer coincidir símbolos o textos específicos, búsqueda semántica para preguntas conceptuales o de comportamiento, y ambos para tareas exploratorias.

El experimento de Vercel presenta el mismo reporte: su agente híbrido con acceso tanto a una herramienta de shell como a una herramienta dedicada para bases de datos logró el mejor rendimiento de todos los agentes probados al usar primero las herramientas dedicadas para bases de datos y luego verificar los resultados mediante búsquedas con grep en el sistema de archivos. Sin embargo, este enfoque utiliza más tokens y tiempo para razonar sobre la elección de herramientas y la verificación.

El patrón en ambos ejemplos es el mismo: La combinación es superior a cualquier interfaz individual, pero conlleva un costo y una latencia adicionales.

Recomendaciones prácticas para encontrar el conjunto adecuado de herramientas

El conjunto adecuado de interfaces de búsqueda es pequeño, intencionado y específico para los patrones de consulta reales de tu agente. Las mejores prácticas actuales son tener un agente con la menor cantidad de herramientas posible en lugar de tener un agente con cientos de herramientas MCP. Esto se debe a que la desventaja de exponer todas las herramientas posibles de antemano es que infla la ventana de contexto y confunde al agente sobre qué herramienta usar realmente. Por ejemplo, se dice que Claude Code solo tiene unas 20 herramientas.

En cambio, la idea de la divulgación progresiva es comenzar con un conjunto mínimo de herramientas y dejar que el agente descubra capacidades adicionales solo cuando sea necesario. Investigaciones de Anthropic [5] y Cursor [6] demostraron que este enfoque genera un ahorro de tokens entre el 47%–85%. Claude Code, por ejemplo, implementa esto directamente, lo que permite al agente descubrir de forma incremental cómo consultar una API o una base de datos, sin que ese conocimiento consuma contexto en cada llamada al LLM.

Una vez que te familiarices con los patrones de búsqueda del agente, puedes volver a revisar el conjunto de herramientas de búsqueda a las que el agente tiene acceso de forma predeterminada. Una forma útil de pensar en este compromiso es el "principio de piso bajo, techo alto" para decidir qué herramientas son las adecuadas. Las herramientas de alto nivel no limitan el potencial del agente. Por ejemplo, una herramienta de shell versátil permite al agente escribir consultas de base de datos completas, incluidas las ambiguas, pero a costa de una mayor sobrecarga de razonamiento, latencia más alta y menor confiabilidad.

Las herramientas de bajo umbral son todo lo contrario. Son herramientas especializadas que encapsulan búsquedas específicas y son inmediatamente accesibles para el agente con una mínima sobrecarga de razonamiento, ofreciendo menor costo y mayor confiabilidad. No obstante, requieren ingeniería previa, no pueden cubrir cada posible consulta y pueden dificultar que el agente elija la herramienta correcta.

Piensa en cada herramienta en un espectro: las herramientas de bajo nivel son fáciles de usar correctamente para el agente, pero tienen un alcance limitado. Las herramientas de alto potencial son versátiles pero requieren más razonamiento para usarlas bien.

La mayoría de los agentes necesitan una combinación de diferentes herramientas de búsqueda. Pero cada herramienta necesita aportar algo. Recomendamos comenzar con una herramienta de búsqueda multiuso (por ejemplo, una herramienta search_database() o una herramienta de shell). Luego, reutiliza los registros de comandos que ya conservas por motivos de seguridad para rastrear lo que realmente hace tu agente, incluidas las llamadas a herramientas, los reintentos y el número de llamadas por consulta de usuario. Y, cuando ves que un patrón de consulta se repite o falla, esa es la señal para construir una herramienta especialmente diseñada para ello.

Resumen

El debate entre sistema de archivos y base de datos distrae de la pregunta real que los ingenieros deben hacerse: ¿Cuáles son las interfaces de búsqueda adecuadas que un agente necesita para construir su propio contexto? La respuesta es muy probable, no una sola.

Una herramienta de shell es una herramienta versátil para interactuar con diferentes fuentes fuera de contexto y, por lo tanto, un buen punto de partida. Sin embargo, resulta menos eficiente y precisa para casos de uso con consultas analíticas estructuradas que las herramientas de bases de datos especializadas.

El objetivo es encontrar el conjunto mínimo de herramientas de búsqueda que manejen bien los patrones reales de consulta de tu agente. Empieza con una herramienta de shell y registra lo que realmente hace tu agente. Cuando veas un patrón de consulta que se repite y falla, es momento de diseñar herramientas especializadas.

Referencias

1. Thariq (Anthropic). Lessons from Building Claude Code: Seeing like an Agent (2026).

2. Cursor: Documentation. Semantic & agentic search (2026).

3. Harrison Chase (LangChain). Cómo construimos el sistema de memoria de Agent Builder (2026).

4. Ankur Goyal (Braintrust) y Andrew Qu (Vercel). Testing if "bash is all you need" (2026).

5. Anthropic. Introducing advanced tool use on the Claude Developer Platform (2025).

6. Cursor. Dynamic context discovery (2026).

Requisitos previos

• Elasticsearch 9.3 o Elastic Cloud Serverless: puedes crear un despliegue en la cloud siguiendo estas instrucciones, o bien puedes utilizar la guía de inicio rápido de start-local.

• Python 3.12: Descarga Python aquí.

• Token de acceso Hugging Face.

Finalización de chat usando un endpoint de inferencia de Hugging Face

Primero, vamos a crear un ejemplo práctico que conecte Elasticsearch con un endpoint de inferencia de Hugging Face para generar recomendaciones basadas en IA a partir de una colección de publicaciones de blog. Para la base de conocimientos de la app, usaremos un set de datos de artículos del blog de la compañía, que contiene información valiosa pero a menudo difícil de navegar.

Con este endpoint, la búsqueda semántica recupera los artículos más relevantes para una consulta dada, y un LLM de Hugging Face genera recomendaciones breves y contextuales basadas en esos resultados.

Echemos un vistazo a una visión general de alto nivel del flujo de información que vamos a construir:

En este artículo, probaremos la capacidad de SmolLM3-3B paracombinar su tamaño compacto con fuertes capacidades multilingües de razonamiento y llamadas a herramientas. A partir de una búsqueda, enviaremos todo el contenido correspondiente (en inglés y español) al LLM para generar una lista de artículos recomendados con una descripción personalizada basada en la búsqueda y los resultados.

Así podría ser la UI de un sitio web de artículos con un sistema de generación de recomendaciones basado en inteligencia artificial.

Puedes encontrar la implementación completa de esta aplicación en el cuaderno adjunto.

Configurar endpoints de inferencia de Elasticsearch

Para usar el endpoint de inferencia Elasticsearch Hugging Face, necesitamos dos elementos importantes: una clave API de Hugging Face y una URL del endpoint de Hugging Face en funcionamiento. Debería verse así:

El endpoint de inferencia Hugging Face en Elasticsearch admite diferentes tipos de tareas: text_embedding, completion, chat_completion y rerank. En esta publicación de blog, usamos chat_completion porque necesitamos que el modelo genere recomendaciones conversacionales basadas en los resultados de búsqueda y una solicitud del sistema. Este endpoint nos permite realizar finalizaciones de chat directamente desde Elasticsearch de una manera sencilla empleando la API de Elasticsearch:

Esto servirá como núcleo de la aplicación, recibirá la indicación y los resultados de búsqueda que pasarán por el modelo. Ya abordamos la teoría, ahora comencemos a implementar la aplicación.

Configuración de un endpoint de inferencia en Hugging Face

Para desplegar el modelo de Hugging Face, vamos a usar despliegues con un clic de Hugging Face, un servicio fácil y rápido para desplegar endpoints de modelos. Ten en cuenta que este es un servicio de pago y que su uso puede generar costos adicionales. En este paso se creará la instancia del modelo que se usará para generar las recomendaciones de artículos.

Puedes elegir un modelo del catálogo de un clic:

Vamos a elegir el modelo SmolLM3-3B:

Desde aquí, copia la URL del endpoint de Hugging Face:

Como se menciona en la documentación de endpoints de inferencia Hugging Face de Elasticsearch, la generación de texto requiere un modelo compatible con la API de OpenAI. Por esa razón, necesitamos anexar la ruta secundaria /v1/chat/completions a la URL del endpoint de Hugging Face. El resultado final se verá así:

Ahora que está todo listo, podemos empezar a programar en un cuaderno de Python.

Generando clave API de Hugging Face

Crea una cuenta en Hugging Face y obtén un token de API siguiendo estas instrucciones. Puedes elegir entre tres tipos de token: detallado (recomendado para producción, ya que proporciona acceso solo a recursos específicos); lectura (para acceso de solo lectura); o escritura (para acceso de lectura y escritura). Para este tutorial, un token de lectura es suficiente, ya que solo necesitamos llamar al endpoint de inferencia. Guarda esta clave para el siguiente paso.

Configuración del endpoint de inferencia de Elasticsearch

Primero, declaremos un cliente de Python para Elasticsearch:

A continuación, vamos a crear un endpoint de inferencia de Elasticsearch que use el modelo Hugging Face. Este endpoint nos permitirá generar respuestas basadas en las entradas del blog y en el prompt que se pasó al modelo.

Set de datos

El conjunto de datos contiene las publicaciones de blog que se consultarán, representando un conjunto de contenido multilingüe utilizado a lo largo del flujo de trabajo:

Mappings de Elasticsearch

Una vez definido el set de datos, necesitamos crear un esquema de datos que se ajuste correctamente a la estructura de la publicación de blog. Se emplearán las siguientes mappings de índices para almacenar los datos en Elasticsearch:

Aquí, podemos ver mejor cómo se estructuran los datos. Usaremos la búsqueda semántica para recuperar resultados basados en lenguaje natural, junto con la propiedad copy_to para copiar el contenido del campo en el campo semantic_text. Además, el campo title contiene dos subcampos: el subcampo original almacena el título en inglés o español, dependiendo del idioma original del artículo; y el subcampo translated_title está presente solo para artículos en español y contiene la traducción al inglés del título original.

Ingesta de datos

El siguiente fragmento de código ingesta el conjunto de datos de las publicaciones de blog en Elasticsearch mediante la API de bulk:

Ahora que tenemos los artículos ingeridos en Elasticsearch, necesitamos crear una función capaz de buscar en el campo semantic_text :

También necesitamos una función que llame al endpoint de inferencia. En este caso, llamaremos al endpoint usando el tipo de tarea chat_completionpara obtener respuestas de transmisión:

Ahora podemos escribir una función que llame a la función de búsqueda semántica, junto con el endpoint de inferencia chat_completions y el endpoint de recomendaciones, para generar los datos que se asignarán en las tarjetas:

Por último, extrae la información y dale formato para imprimirla:

Pongámoslo a prueba haciendo una pregunta sobre las publicaciones de blog de seguridad:

Aquí podemos ver las tarjetas de la consola generadas por el flujo de trabajo:

Puedes ver los resultados completos, incluso todas las coincidencias y la respuesta del LLM, en este archivo.

Estamos solicitando artículos relacionados con: “Seguridad y vulnerabilidades”. Esta pregunta se emplea como consulta de búsqueda en los documentos almacenados en Elasticsearch. Los resultados obtenidos se pasan al modelo, el cual genera recomendaciones basadas en su contenido. Como podemos ver, el modelo hizo un excelente trabajo generando textos cortos y atractivos que pueden motivar al lector a hacer clic en ellos.

Conclusión

Este ejemplo muestra cómo se pueden combinar Elasticsearch y Hugging Face para crear un sistema centralizado rápido y eficiente para aplicaciones de IA. Este enfoque reduce el esfuerzo manual y proporciona flexibilidad, gracias al extenso catálogo de modelos de Hugging Face. El uso de SmolLM3-3B, en particular, muestra cómo los modelos compactos y multilingües aún pueden ofrecer razonamiento significativo y generación de contenido cuando se combinan con la búsqueda semántica. En conjunto, estas herramientas ofrecen una base escalable y eficaz para construir análisis de contenidos inteligentes y aplicaciones multilingües.

La extensión está disponible como proyecto de open source aquí.

¿Qué es Gemini CLI y cómo lo instalas?

Gemini CLI es un agente open source de IA que lleva los modelos Gemini de Google directamente a la línea de comando. Permite a los desarrolladores interactuar con la IA desde la terminal para hacer tareas como generar código, editar archivos, ejecutar comandos de shell y obtener información de la web.

A diferencia de las interfaces de chat típicas, Gemini CLI se integra con tu entorno local de desarrollo, lo que significa que puede entender el contexto del proyecto, modificar archivos, ejecutar compilaciones o pruebas, y automatizar flujos de trabajo directamente dentro de la terminal. Esto lo hace útil para desarrolladores, ingenieros de confiabilidad del sitio (SRE) e ingenieros que buscan codificación y automatización asistidas por IA sin salir de su flujo de trabajo de línea de comandos.

Gemini CLI puede instalarse usando diversos gestores de paquetes. El método más común es a través de npm:

Si quieres conocer opciones de instalación alternativas, consulta la página de instalación oficial.

Luego de la instalación, inicia la CLI ejecutando:

Verás una pantalla, como se muestra en la Figura 1:

Configurar Elasticsearch

Es necesario tener una instancia de Elasticsearch en funcionamiento. Si quieres usar el servidor Model Context Protocol (MCP), también necesitas instalar Kibana 9.3+. Para emplear la habilidad del lenguaje de búsqueda Elasticsearch (ES|QL) (esql) descrito más abajo, Kibana no es obligatorio.

Puedes activar una prueba gratis en Elastic Cloud o instalarlo localmente usando el script start-local:

Se instalarán Elasticsearch y Kibana en tu computadora y se generará una clave API que se utilizará para configurar Gemini CLI.

La clave de API se mostrará como salida del comando anterior y se almacenará en un archivo .env en la carpeta elastic-start-local.

Si usas Elasticsearch local (por ejemplo, usar start-local), y quieres usar Elastic Agent Builder con MCP, también necesitas conectar un modelo de lenguaje grande (LLM). Puedes leer esta página de documentación para entender las diferentes opciones.

Si usas Elastic Cloud (o sin servidor), ya tienes una conexión con el LLM preconstruida.

Instala la extensión de Elasticsearch

Puedes instalar la extensión de Elasticsearch para Gemini CLI con el siguiente comando:

Puedes verificar que las extensiones se hayan instalado correctamente abriendo Gemini y ejecutando el siguiente comando:

Deberías ver la extensión de Elasticsearch disponible.

Si quieres usar la integración de MCP, necesitas tener instalada una versión de Elasticsearch 9.3 o superior. Necesitas la URL de tu servidor MCP de Kibana:

• Obtén la URL del servidor MCP desde Agentes > Ver todas las herramientas > Administrar MCP > Copiar URL del servidor MCP.

• La URL tendrá este formato: https://your-kibana-instance/api/agent_builder/mcp

Necesitas la URL del endpoint de Elasticsearch. Esta generalmente se informa en la parte superior de la página de Kibana Elasticsearch. Si estás ejecutando Elasticsearch con start-local, ya tienes el endpoint en la clave ES_LOCAL_URLen el archivo start-local.env .

También necesitas una clave API. Si estás ejecutando Elasticsearch con start-local, ya tienes ES_LOCAL_API_KEY en el archivo start-local .env . De lo contrario, puedes crear una clave API desde la interfaz de Kibana, como se indica aquí:

• En Kibana: Stack Management > Seguridad > Claves de API > Crear clave de API.

• Sugerimos establecer solo los privilegios de lectura para la clave API, habilitando el privilegio feature_agentBuilder.read como se informa aquí.

• Copia el valor de la clave API codificada.

Configura las variables de entorno requeridas en tu shell:

Instala el set de datos de ejemplo

Puedes instalar el set de datos de pedidos de comercio electrónico disponible desde Kibana. Incluye un único índice llamado kibana_sample_data_ecommerce, que contiene información sobre 4,675 pedidos de un sitio web de comercio electrónico. Para cada pedido, tenemos la siguiente información:

• Información del cliente (nombre, identificación, fecha de nacimiento, correo electrónico y más).

• Fecha del pedido.

• ID de pedido.

• Productos (lista de todos los productos con precio, cantidad, identificación, categoría, descuento y otros detalles).

• SKU.

• Precio total (sin impuestos, con impuestos).

• Cantidad total.

• Información geográfica (ciudad, país, continente, ubicación, región).

Para instalar los datos de muestra, abre la página Integraciones en Kibana (busca "Integración" en la barra superior de búsqueda) e instala los Datos de muestra. Para más detalles, consulta la documentación aquí.

El objetivo de este artículo es mostrar lo fácil que es configurar la CLI Gemini para conectarse a Elasticsearch e interactuar con el índice kibana_sample_data_ecommerce .

Cómo usar el MCP de Elasticsearch

Puedes comprobar la conexión usando el siguiente comando en Gemini:

Deberías ver el elastic-agent-builder activado, como se muestra en la Figura 2:

Elasticsearch proporciona un conjunto predeterminado de herramientas. Ve la descripción aquí.

Con estas herramientas, puedes interactuar con Elasticsearch y hacer preguntas como:

• Give me the list of all the indexes available in Elasticsearch.

• How many customers are based in the USA in the kibana_sample_data_ecommerce index of Elasticsearch?

Dependiendo de la pregunta, Gemini usará una o varias de las herramientas disponibles para intentar responderla.

Los comandos /elastic

En la extensión Elasticsearch para Gemini CLI, también agregamos comandos/elastic.

Si ejecutas el comando /help, verás todas las opciones /elastic disponibles (Figura 3):

Estos comandos pueden ser útiles si quieres ejecutar directamente una herramienta específica del servidor MCP elastic-agent-builder. Por ejemplo, usando el siguiente comando, puedes obtener el mapping del kibana_sample_data_ecommerce:

Estos comandos son esencialmente atajos para ejecutar herramientas específicas, en lugar de depender del modelo Gemini para determinar qué herramienta debe invocarse.

Cómo usar las habilidades de Elasticsearch

Esta extensión también incluye una habilidad de agente para ES|QL, el lenguaje de búsqueda Elasticsearch disponible en Elasticsearch. Habilidades del Agente es un formato abierto que proporciona a los agentes de codificación de IA, como Gemini CLI, instrucciones personalizadas para tareas específicas. Utilizan un concepto llamado revelación progresiva, lo que significa que solo se agrega una breve descripción de la habilidad a la indicación inicial del sistema. Cuando le pides al agente que haga una tarea, como consultar Elasticsearch, hace coincidir la solicitud con la habilidad relevante y carga dinámicamente las instrucciones detalladas. Esta es una forma eficaz de gestionar los presupuestos de tokens y, al mismo tiempo, proporcionar a la IA exactamente el contexto que necesita.

La habilidadesql está diseñada para permitir que la CLI de Gemini escriba y ejecute consultas en ES|QL directamente en tu cluster. ES|QL es un poderoso lenguaje de búsqueda con barras verticales que hace que la exploración de datos, el análisis de logs y las agregaciones sean sumamente intuitivas. Con esta habilidad activada, no necesitas buscar la sintaxis de ES|QL; simplemente puedes hacer preguntas en lenguaje natural a la CLI de Gemini sobre tus datos, y el agente se encargará del resto.

Las ejecuciones se efectúan mediante comandos curl sencillos ejecutados en una terminal. Esto es posible porque Elasticsearch ofrece un amplio conjunto de API REST que se pueden utilizar fácilmente para integrar el sistema en cualquier arquitectura.

Lo que la habilidadesql ofrece:

• Detección de índices y esquemas: El agente puede usar las herramientas integradas de la habilidad para mostrar los índices disponibles y obtener el mapping de campos. Por ejemplo, antes de escribir una consulta para el set de datos de comercio electrónico, el agente puede ejecutar una verificación de esquema en kibana_sample_data_ecommerce para comprender los campos disponibles, como taxful_total_price o category.

• Traducción perfecta al lenguaje natural: la habilidad le da al agente algo más que un simple manual de referencia; proporciona una guía específica para interpretar la intención del usuario. Cuando escribes solicitudes en lenguaje natural, como "Mostrar el tiempo de respuesta promedio agrupado por servicio", el agente utiliza la función de coincidencia de patrones integrada en la habilidad para traducir al instante tus palabras en las agregaciones, filtros y comandos en ES|QL correctos.

• Autocorrección: Si una consulta falla (por ejemplo, debido a una incompatibilidad de tipos o un error de sintaxis), la habilidad devuelve la consulta generada junto con el mensaje de error exacto de Elasticsearch, lo que permite al agente corregirla al instante y volver a intentarlo sin que tengas que intervenir.

Dado que la habilidad esql también está disponible como una herramienta en el servidor MCP elastic-agent-builder, necesitamos deshabilitar este servidor momentáneamente. Puedes usar el siguiente comando para desactivarlo:

Entonces puedes simplemente escribir un mensaje como este en tu CLI de Gemini:

El agente deberá:

• Reconoce la necesidad de la habilidad esql .

• Verifica el esquema de kibana_sample_data_ecommerce.

• Construye una consulta en ES|QL, como: FROM kibana_sample_data_ecommerce | STATS total_revenue = SUM(taxful_total_price) BY category.keyword | SORT total_revenue DESC | LIMIT 5.

• Ejecutar la consulta en la API de Elasticsearch.

• Presentar la respuesta final directamente en la terminal.

Aquí, presentamos un ejemplo de respuesta de Gemini al mensaje anterior:

Es interesante ver cómo el modelo Gemini genera la respuesta final mostrando todos los pasos que sigue. Aquí, puedes ver claramente la influencia de la habilidad en el proceso de razonamiento del modelo. La primera vez que el modelo reconoce que necesita usar una habilidad o ejecutar un comando de shell, pide permiso empleando el enfoque de intervención humana.

Al manejar el trabajo pesado de descubrimiento de esquemas, generación de consultas y ejecución, la habilidad esql te permite concentrarte completamente en las respuestas en lugar de en la mecánica para obtenerlas. Obtendrás los datos que necesitas, correctamente formateados y directamente en tu terminal, todo sin escribir una sola línea de sintaxis o cambiar de contexto a otra aplicación.

Conclusión

En este artículo, presentamos la extensión Elasticsearch para Gemini CLI que lanzamos recientemente. Esta extensión te permite interactuar con tu instancia de Elasticsearch mediante Gemini y el servidor MCP de Elasticsearch que ofrece Elastic Agent Builder, disponible a partir de la versión 9.3.0, así como el comando /elastic .

Además, la extensión también incluye una habilidad esql que convierte la solicitud del usuario de lenguaje natural en una consulta en ES|QL. Esta habilidad puede resultar especialmente útil cuando no se puede usar el servidor MCP, ya que la comunicación subyacente se gestiona mediante simples comandos curl ejecutados en una terminal. Elasticsearch ofrece un amplio conjunto de API REST que se pueden integrar fácilmente en cualquier proyecto. Esto es especialmente útil cuando se desarrollan aplicaciones de AI agéntica.

Para más información sobre nuestra extensión Gemini CLI, visita el repositorio del proyecto aquí.

Por eso estamos liberando el código de Elastic Agent Skills como open-source: experiencia nativa en plataformas para Elasticsearch, Kibana, Elastic Observability y Elastic Security. Insértalo en el tiempo de ejecución del agente que ya usas y cambia a tu agente de “generalista” que adivina mucha de la sintaxis a darle experiencia, como, por ejemplo, poder usar muchos de los estándares arquitectónicos como los propios equipos de ingeniería de Elastic. Esta versión inicial de vista previa técnica se centra en las habilidades con máxima compatibilidad para Elastic Cloud Serverless, pero evolucionará rápidamente para incluir un mejor soporte para versiones anteriores del stack.

Además, Elastic está abordando este problema desde ambos frentes. Para los agentes en la plataforma de Elastic, Elastic Agent Builder (ahora disponible en general) te permite crear y chatear con agentes de IA que heredan los controles de acceso de tus datos, usan herramientas integradas de búsqueda y análisis, y trabajan en contexto junto a tus dashboards, alertas e investigaciones. Estamos trabajando intensamente para asegurar experiencias agénticas increíbles en la plataforma de Elastic. Pero no todos los agentes están dentro de Elastic. Tu equipo ya usa Cursor, Claude Code u otros entornos de ejecución, y esos agentes también necesitan que Elastic funcione bien. Ahí es donde entra en juego Agent Skills.

Por qué los agentes tienen dificultades con plataformas especializadas

Los modelos de lenguaje grandes (LLM) son generalistas con capacidades extraordinarias. Pueden escribir Python, explicar los manifiestos de Kubernetes y refactorizar los componentes de React porque sus datos de entrenamiento están llenos de ejemplos. Pero cuando se trata de trabajo específico de la plataforma, del tipo que implica lenguajes de búsqueda patentados, superficies de API profundas y mejores prácticas específicas del dominio, muestran limitaciones previsibles.

En el caso de Elasticsearch, la diferencia se nota claramente:

• El lenguaje de búsqueda de Elasticsearch (ES|QL) es un nuevo territorio. Los LLM están muy entrenados en SQL, pero ES|QL es un lenguaje de búsquedas con barras verticales, con sintaxis, funciones y semántica diferentes. Los agentes suelen escribir búsquedas que parecen razonables, pero no se pueden parsear. Confunden WHERE con | WHERE, inventan funciones que no existen y pierden por completo el modelo de composición basado en barras verticales.

• Las superficies de API son anchas y profundas. Elasticsearch, Kibana y Elastic Security ofrecen cientos de API para búsqueda, ingesta, alertas, reglas de detección, gestión de casos, dashboards y mucho más. Un agente que solo cuenta con datos de entrenamiento generales tiene que adivinar a qué endpoint debe enviar la solicitud, cómo es el cuerpo de la solicitud y cómo gestionar la respuesta. Sus suposiciones son incorrectas con demasiada frecuencia como para erosionar la confianza.

• Las mejores prácticas no están en los datos de entrenamiento. ¿Cuándo deberías usar semantic_text frente a una pipeline de incrustación personalizada? ¿Cómo deberías estructurar una pipeline de ingesta para un CSV de 10GB? ¿Cuál es la sintaxis correcta de reglas de detección para una técnica MITRE ATT&CK®? Los agentes de uso general no tienen, por defecto, conocimientos específicos de Elastic seleccionados y estructurados de forma confiable. Tendrían que buscarlo, y aunque lo hicieran, la documentación sin procesar no siempre codifica los juicios y mejores prácticas que ofrecen los profesionales calificados.

El resultado: los desarrolladores pasan más tiempo corrigiendo el resultado del agente que el que habrían dedicado a escribir el código ellos mismos. Esa es la experiencia para la que nadie se registró.

Agent Skills: conocimiento de la plataforma, empaquetado para los agentes

Agent Skills son directorios independientes que contienen instrucciones, scripts y material de referencia que los entornos de ejecución de agentes pueden cargar dinámicamente. Cuando una habilidad está activa, el agente tiene acceso al contexto adecuado en el momento oportuno: sintaxis de búsqueda, patrones de API, lógica de validación y ejemplos prácticos, lo que le permite completar las tareas correctamente desde el primer intento.

Cada habilidad sigue la especificación abierta agentskills.io: una carpeta con un archivo SKILL.md que contiene metadatos e instrucciones estructuradas. Sin formato propietario, sin dependencia del proveedor. Las habilidades funcionan en diferentes entornos de ejecución de agentes; esto incluye Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Cline, Codex y muchos más.

¿Qué hay en la versión inicial v0.1.0?

El primer conjunto de habilidades abarca cinco áreas del Elastic Stack:

• Interactuar con las API de Elasticsearch (búsqueda, indexación, gestión de clústeres)

• Crear y gestionar contenido de Kibana como dashboards, alertas, conectores y más

• Especialización en el dominio para Elastic Observability

• Pericia en la materia para Elastic Security

• Cómo crear agentes eficaces en Agent Builder

Las habilidades son componibles

Las habilidades no son homogéneas. Son modulares por diseño. Tu agente carga solo las habilidades relevantes para la tarea en cuestión. ¿Estás trabajando en una búsqueda ES|QL? Se activa la habilidad ES|QL. ¿Necesitas crear un dashboard a partir de esos resultados? Aparece la habilidad de dashboard. ¿Estás evaluando el estado de tu aplicación? La habilidad de estado del servicio entra en juego. ¿Estás investigando una alerta de seguridad? La habilidad de triaje se asocia con habilidades de gestión de casos y respuesta a medida que avanza la investigación.

Esta capacidad de composición significa que no necesitas un único aviso masivo que intente cubrir todo. Cada habilidad lleva exactamente el contexto que tu dominio requiere, nada más, nada menos.

Para desarrolladores que crean aplicaciones de búsqueda e IA

Si estás cargando datos en Elasticsearch, escribiendo búsquedas o migrando índices, las habilidades reducen el ciclo de generación de código, errores y búsqueda de documentos a partir de los errores.

Pídele a tu agente que cargue un archivo CSV, y este utilizará una herramienta de ingesta en tiempo real que gestiona la contrapresión y deduce el mapping a partir de los datos. No es un bucle _bulk a medida que se queda sin memoria con el primer archivo grande. Pídele que realice búsquedas con ES|QL, y detectará los nombres reales de tus índices y los esquemas de los campos; luego generará búsquedas con barras verticales válidas, con la sintaxis correcta, las agregaciones adecuadas y una selección de características que tiene en cuenta la versión, en lugar de una conjetura al estilo SQL que requiere tres rondas de depuración. Si le pides que vuelva a indexar los clusters, sigue todo el flujo de trabajo operativo: crea el destino con mapping explícitos, configura los ajustes para el rendimiento, ejecuta el trabajo de forma asincrónica y restaura la configuración de producción cuando termina, no una llamada de _reindex que omite la mitad de los pasos que seguiría un operador experimentado.

En lugar de un agente que te da un punto de partida razonable que tienes que arreglar, obtienes uno que codifica la disciplina operativa que hace que el resultado realmente funcione.

Ejemplos de impactos del uso de Elastic Agent Skills

Eval

Qué cambió la habilidad

es-audit-query-failed-logins

Usó los patrones de búsqueda del log de auditoría de la habilidad en lugar de una búsqueda genérica

es-authz-role-mapping-ldap

Generó la estructura correcta de la llamada de API para el mapping de roles

esql-basic-query

Escribió la sintaxis de barras verticales ES|QL en lugar de Query DSL

esql-error-handling

Primero el esquema, en lugar de adivinar los nombres de los campos

esql-schema-discovery

Nunca adivinó el nombre de un índice

es-ingest-csv-with-infer

Usó únicamente --infer-mappings, evitó combinarlo con --source-format csv, que genera un índice vacío.

es-ingest-json-file

Usó un método de ingesta sólido capaz de gestionar archivos de gran tamaño

es-reindex-local-async

Creó primero el índice de destino con réplicas: 0 y refresh_interval: "-1", luego la reindexación asíncrona. La línea base omitió cualquier preparación

es-seguridad-403-privilegios

Siguió el flujo de trabajo de diagnóstico de la herramienta para los errores de privilegios, en lugar de seguir consejos genéricos

Para equipos de seguridad

Los equipos de seguridad repiten los mismos flujos de trabajo operativos a diario: clasificación de alertas, ajuste de reglas de detección, gestión de casos. Las habilidades del agente codifican ese conocimiento de procesos para que tu agente de IA pueda ejecutar estos flujos de trabajo correctamente al llamar a las API adecuadas en el orden correcto con los nombres de campo correctos. Para una guía práctica que te lleva de cero a un entorno de Elastic Security completamente configurado sin salir de tu IDE, consulta Empieza con Elastic Security desde tu agente de IA.

Para equipos de observabilidad y operaciones

Las nuevas funciones de los agentes de Elastic Observability reducen la carga operativa que supone instrumentar sistemas complejos, gestionar los SLO, analizar datos complejos y evaluar el estado de los servicios. Incorporar la experiencia nativa de Elastic directamente en los agentes de IA permite a los equipos ejecutar flujos de trabajo complejos de observabilidad utilizando un lenguaje natural sencillo. Esto permite a los SRE y equipos de operaciones resolver incidentes más rápido y mantener sistemas fiables con mayor facilidad. Obtén más información en este blog.

Open source, especificación abierta, impulsado por la comunidad

Estamos lanzando Agent Skills bajo la licencia Apache 2.0 porque creemos que el conocimiento de los agentes debe ser abierto. La especificación agentskills.io que siguen las habilidades es un estándar abierto, no un formato propietario de Elastic. Queremos que las habilidades sean un esfuerzo comunitario, no un entorno cerrado.

Parte de un panorama más amplio

Agent Skills es una parte de una iniciativa más amplia para hacer de Elasticsearch la plataforma de datos disponible más preparada para los agentes. Para los agentes que están en la plataforma Elasticsearch, Agent Builder va más allá al heredar los controles de acceso y permisos de tus datos, ofrecer herramientas integradas y personalizadas para búsqueda y análisis, y permitir que los usuarios interactúen con los agentes en contexto junto con sus dashboards, alertas e investigaciones. Finalmente, el soporte para habilidades llegará pronto a Agent Builder, lo que permitirá a los desarrolladores la flexibilidad de aprovechar las habilidades de Elastic Agent, así como habilidades de cualquier otra fuente para habilitar chats y automatizaciones seguras y mejoradas por contexto en la plataforma Elasticsearch.

Para los agentes que viven en cualquier otro lugar, estamos invirtiendo en el ecosistema abierto:

• Expansión del servidor del Model Context Protocol (MCP): Ampliando el endpoint MCP en Agent Builder con más herramientas, más allá de la búsqueda actual, ES|QL y operaciones de índice.

• Mejoras en la autenticación: Facilitar a los agentes la conexión segura, con el objetivo de eliminar la necesidad de copiar y pegar manualmente las claves de API.

• Documentación legible en LLM: publicar archivos llms.txt y AGENTS.md para que los agentes puedan descubrir y entender las API de Elastic por sí mismos.

• Una interfaz de línea de comandos (CLI) para los flujos de trabajo de los agentes: Herramientas de línea de comandos que facilitan la gestión de conexiones y las operaciones comunes para los agentes.

Las habilidades son la capa que puedes usar hoy. El resto llegará más adelante.

Comenzar

Antes de que empieces: los agentes de programación con IA operan con credenciales reales, acceso real a la shell y, a menudo, con todos los permisos del usuario que los ejecuta. Cuando esos agentes se orientan a flujos de trabajo de seguridad, hay más en juego: le estás dando a un sistema automatizado acceso a la lógica de detección, las acciones de respuesta y la telemetría sensible. El perfil de riesgo de cada organización es diferente. Antes de habilitar los flujos de trabajo de seguridad impulsados por IA, evalúa a qué datos puede acceder el agente, qué acciones puede realizar y qué pasa si se comporta de forma inesperada.

Instala Elastic Agent Skills en el tiempo de ejecución de tu agente:

npx skills add elastic/agent-skills

Esto detecta automáticamente tus tiempos de ejecución del agente instalado y coloca las habilidades en el directorio de configuración correcto. Desde allí, tu agente los recoge automáticamente.

También puedes navegar directamente en el catálogo de habilidades e instalar habilidades individuales manualmente si copias la carpeta de la habilidad en el directorio de configuración de tu agente.

¿Aún no tienes un clúster de Elasticsearch? Comienza una prueba gratis de Elastic Cloud. Lleva aproximadamente un minuto obtener un entorno completamente configurado.

Explora el proyecto:

• Repositorio de habilidades de agentes

• especificación de agentskills.io

• Documentación de Elasticsearch

• Prueba gratuita de Elastic Cloud

Las integraciones configuran las entradas de Filebeat para realizar la recopilación de datos. Para recopilar datos de APIs HTTP, a menudo utilizamos la entrada HTTP JSON. Sin embargo, incluso las APIs básicas de listado pueden diferir mucho en los detalles, y el modelo de transformaciones configuradas en YAML de la entrada HTTP JSON puede hacer que sea engorroso y a veces imposible expresar la lógica de recopilación requerida.

Se introdujo la entrada del lenguaje de expresión común (CEL) para permitir una interacción más flexible con las APIs HTTP. CEL es un lenguaje diseñado para integrarse en aplicaciones que requieren una forma rápida, segura y extensible de expresar condiciones y transformaciones de datos. La entrada CEL permite a un creador de integraciones escribir una expresión que puede leer configuraciones, realizar un seguimiento de su propio estado, realizar solicitudes, procesar respuestas y, en última instancia, devolver eventos listos para su ingesta.

En este artículo, veremos cómo se diferencia el lenguaje de expresión común de otros lenguajes de programación, cómo lo ampliamos para la entrada del CEL, y la flexibilidad y el poder que te da para expresar tu lógica de recopilación de datos.

CEL y cómo funciona en la entrada

CEL es un lenguaje de expresión. No tiene declaraciones. Cuando escribes CEL, no le dices qué hacer al escribir declaraciones, sino que le dices qué valor producir al escribir una expresión. Cada expresión CEL produce un valor, y las expresiones más pequeñas pueden combinarse en una expresión mayor para producir un resultado según reglas más complejas. Más adelante veremos cómo usar expresiones que se pueden escribir con declaraciones en otros idiomas.

CEL es intencionadamente un lenguaje completo no Turing. No permite bucles ilimitados. Más adelante, veremos cómo puedes procesar listas y mapas mediante macros, pero al evitar bucles sin límites, el lenguaje garantiza un tiempo de ejecución predecible y limitado para expresiones individuales.

La entrada CEL está configurada con un programa CEL (una expresión) y un estado inicial. El estado se proporcionará como entrada al programa. El programa se evalúa para producir un estado de salida. Si el estado de salida incluye una lista de eventos, estos se eliminarán y se publicarán. El resto del estado de salida se usará como entrada para la próxima evaluación. Si el estado de salida incluye uno o más eventos y la advertencia want_more: true, la siguiente evaluación se realizará inmediatamente. De lo contrario, permanecerá en suspensión durante el resto del intervalo configurado antes de continuar. Aquí tienes un diagrama simplificado del flujo de control de la entrada:

La salida de cada evaluación se pasará como entrada a la siguiente evaluación, mientras se ejecute la entrada. Los datos de salida bajo la clave "cursor" se mantendrán en el disco y se volverán a cargar después de que la entrada se reinicie, pero el resto del estado no se conservará entre los reinicios.

El lenguaje CEL en sí tiene funcionalidades limitadas y evita efectos secundarios, pero es extensible. La implementación cel-go agrega algunas funcionalidades, como sintaxis y tipos opcionales. La biblioteca Mito se basa en cel-go y agrega más funcionalidades, como la capacidad de hacer solicitudes HTTP. La entrada CEL usa la versión de CEL de Mito.

Trabajando con Mito

Para construir o depurar una integración mediante una entrada CEL, lo más importante que debes entender es qué estado de salida producirá tu programa CEL para un estado de entrada dado. Durante el desarrollo, puede ser engorroso que tu programa CEL la ejecute la entrada, rodeada por toda la pila de Elastic Stack. Una forma de lograr un ciclo de retroalimentación más rápido es usar la herramienta de línea de comando de Mito, que te permitirá ejecutar un programa CEL directamente y ver la salida que produce para una entrada dada.

Mito está escrito en Go y se puede instalar de la siguiente manera:

Cuando ejecutas un programa CEL con Mito, normalmente le asignas dos archivos: un archivo JSON con el estado inicial de entrada y otro archivo con el código fuente de tu programa CEL:

Para facilitar la copia y el pegado, los ejemplos en este artículo están escritos como comandos únicos que hacen que el shell cree archivos temporales al instante al envolver el contenido de cada archivo en <(echo '...content...'). En tu propio desarrollo, trabajar con archivos reales será más fácil.

Obtención de datos de incidencias desde GitHub

El siguiente ejemplo incluye un programa CEL completo que obtendrá datos sobre los problemas de la API de GitHub. Su estado de entrada inicial tiene una URL para el endpoint de la API y cierta información sobre cómo debe manejar la paginación. El programa CEL utiliza los datos del estado de entrada para generar una solicitud. Decodificará la respuesta, generará eventos a partir de ella y los devolverá como parte de su estado de salida.

Su primera evaluación produce la siguiente salida:

Los eventos se eliminarán y, cuando se ejecuten en la entrada CEL, se publicarán para su ingesta. El resto de la salida se proporcionará a la siguiente evaluación del programa CEL como estado de entrada.

Para entender cómo funciona ese programa CEL, veremos algunos ejemplos más pequeños de CEL y hablaremos con más detalle sobre cómo funciona la entrada de CEL.

Conceptos básicos de CEL

En el lenguaje CEL, no hay declaraciones, solo hay expresiones. Cada expresión CEL exitosa se evalúa hasta un valor final. Esta es una de las expresiones CEL más pequeñas que puedes escribir, junto con su salida:

Muchas expresiones simples son intuitivas. Las operaciones matemáticas solo se admiten en valores del mismo tipo (por ejemplo, int con int), así que convierte los tipos según necesites (aquí de int a double):

No existen variables en el lenguaje CEL, pero una expresión puede recibir un nombre y usarse en una expresión más amplia con la ayuda de la macro as de Mito. En este ejemplo, la expresión (1 + 1) evalúa al valor 2 y .as(n, ...) da a ese valor el nombre n para su uso en la expresión "one plus one is "+string(n):

También es posible acumular información en un mapa y usarla más tarde en la expresión, como se demuestra aquí al usar with:

Mira ese ejemplo otra vez. Observa que la parte anidada, ({ "data": data, "size": size(data), }), nos da la forma del valor final. Es un mapa con las claves "data" y "size". Los valores de esas claves dependen de data, que la define la parte exterior de la expresión. Leer las expresiones de CEL desde adentro hacia afuera puede ayudar a ver rápidamente qué devolverán.

CEL no tiene declaraciones de flujo de control, como if, pero la ramificación condicional se puede hacer con el operador ternario:

Los bucles ilimitados y la recursión no son compatibles, ya que CEL no es un lenguaje de Turing completo. Esto hace que el tiempo de ejecución sea predecible y proporcional al tamaño de los datos de entrada y a la complejidad de la expresión.

Aunque los bucles sin límites no son posibles en expresiones CEL individuales, puedes procesar listas y mapas con macros como map:

En esta sección, abordamos los siguientes temas:

• Textos, números, listas y mapas.

• Concatenación de texto.

• Operaciones matemáticas.

• Conversión de tipos.

• Condicionales.

• Nombrando subexpresiones.

• Procesando colecciones.

A continuación, veremos cómo hacer solicitudes HTTP.

Solicitudes

Mito extiende el CEL con la capacidad de realizar solicitudes HTTP:

Las solicitudes se pueden construir explícitamente antes de que se ejecuten. Esto permite utilizar diferentes métodos HTTP y agregar encabezados y un cuerpo.

En este ejemplo, construimos una URL con la ayuda de format_query, agregamos un encabezado a la solicitud y parseamos el cuerpo de la respuesta con decode_json. Cuando se te da la opción -log_requests, Mito registra información detallada en formato JSON sobre cada solicitud y respuesta.

Gestión del estado y evaluaciones

Ahora que ya vimos cómo realizar solicitudes y los conceptos básicos de CEL necesarios para producir el estado de salida deseado, veamos más de cerca qué debemos incluir en el estado de salida y cómo eso nos permite dirigir el procesamiento posterior.

El programa CEL de una integración debe asegurarse de que su estado de salida sea adecuado para su uso como entrada de la siguiente evaluación. La configuración establece el estado inicial, y eso debe repetirse en la salida con los cambios apropiados. Una forma sencilla de hacerlo es usar state.with({ ... }), para repetir el mapa de estado con algunas sobrescrituras. Un patrón común para programas pequeños es envolver todo el programa en state.with(), para que la propagación de estados no tenga que repetirse en cada rama que genere datos de salida (por ejemplo: éxito, errores).

Cuando hay valores de estado que se inicializan mediante una evaluación en lugar de estar codificados de forma fija en el estado de entrada inicial, el programa tendrá que comprobar si existe un valor antes de establecer el inicial. Eso es algo en lo que el soporte para sintaxis y tipos opcionales puede ayudar. Al usar un signo de interrogación antes del nombre del campo en una clave de mapa, el acceso se vuelve opcional: puede o no resolver a un valor, pero son posibles accesos opcionales adicionales y es fácil proporcionar un valor por defecto si no hay un valor presente:

En ese ejemplo, el valor del contador leído desde el estado se convierte en int porque todos los números se serializan en el estado como números de coma flotante, de acuerdo con las convenciones establecidas por el tipo Number de JSON y JavaScript. También debe tenerse en cuenta que Mito honra "want_more": true, pero cuando se ejecuta en la entrada CEL, la evaluación solo se repetiría si la salida también contiene eventos.

Es un requisito de los programas CEL ejecutados por la entrada CEL que devuelvan una clave "events" en su mapa de salida. Su valor puede ser una lista de mapas de eventos, una lista vacía o un solo mapa de eventos. El caso de evento único generalmente se utiliza para errores. El evento se publicará mediante la entrada, pero su valor también se registrará y, si estableces un valor de error.message, se usará para actualizar el estado de salud de la Fleet de la integración. Si tu programa produce un solo evento sin error, es mejor envolverlo en una lista.

Echa otro vistazo a la salida de nuestro programa de problemas de GitHub de antes:

El programa gestionó eficazmente su estado, mediante:

• Valores de estado iniciales repetidos en url, per_pagey max_pages.

• Agregar un estado que debería persistir durante los reinicios en cursor.page.

• Devolver eventos listos para publicar en la lista events.

• Solicito una reevaluación inmediata con want_more: true.

Ahora que entiendes el acceso opcional y la gestión de estados, así como los conceptos básicos de CEL y las solicitudes HTTP, deberías poder leer el programa completo de incidencias de GitHub. Intenta ejecutarlo con Mito y experimentar con algunos cambios.

Revisión y recursos

En este artículo, analizamos qué es el lenguaje CEL y cómo se ha extendido en la biblioteca Mito para su uso en la entrada CEL. Vimos la flexibilidad de CEL en un programa de ejemplo que obtiene información de incidencias de la API de GitHub, y repasamos todos los detalles necesarios para comprender ese programa, incluidos el acceso a la configuración en el estado inicial, la interacción con las API HTTP, el retorno de eventos para su ingesta y la gestión del estado para ejecuciones posteriores del programa.

Para aprender más y construir integraciones mediante la entrada CEL, hay varios recursos que valen la pena explorar:

• Entrada CEL - documentación de Filebeat

• Documentación de Mito

• Lenguaje de expresión común - sitio web cel.dev

• Crear una integración - Documentación de Elastic

Y quizás el recurso más valioso para crear integraciones con la entrada CEL sea el código CEL de las integraciones existentes de Elastic, que se puede encontrar en GitHub:

cel.yml.hbs archivos en el repositorio de integraciones de Elastic - GitHub

Todos somos testigos del auge de los agentes de IA. Son fantásticos para resumir texto, escribir fragmentos de código y responder preguntas basadas en la documentación. Pero para quienes trabajamos en DevOps y en ingeniería de confiabilidad de sitios (SRE), existe una limitación frustrante. La mayoría de los agentes están atrapados en el paradigma del centro de llamadas, lo que significa que pueden leer, pensar y chatear, pero no pueden interactuar con la infraestructura que se supone que deben administrar.

Para nuestro último proyecto de hackathon, decidimos superar esa limitación.

Desarrollamos infraestructura aumentada: un copiloto de infraestructura que no solo te da consejos, sino que también crea, despliega, monitorea y corrige el entorno en vivo.

El problema: copiar, reformatear, pegar

Los agentes estándar operan en el vacío. Si una app se cae y le cuesta a la compañía $5 millones, un agente estándar puede leerte el libro de apuntes sobre cómo arreglarlo. Pero sigue siendo tu responsabilidad hacer el trabajo. Ahora solo tienes que copiar el código, adaptarlo al entorno y pegarlo en tu terminal.

Queríamos crear un agente que entendiera la diferencia entre hablar de Kubernetes y configurar Kubernetes.

El motor: ¿Qué es Elastic Agent Builder?

Para desarrollarlo no empezamos desde cero. Partimos de Elastic Agent Builder. Para quienes no lo conozcan, Elastic Agent Builder es un marco de trabajo diseñado para desarrollar agentes de forma rápida, y actúa como puente entre un gran modelo de lenguaje (LLM) (en nuestra demo usamos Google Gemini) y los datos privados almacenados en Elasticsearch.

Agent Builder se puede usar para la IA conversacional si se lo basa en datos internos, como documentos o registros. Pero su característica más poderosa es la capacidad de asignar herramientas. Estas herramientas permiten al LLM salir de la interfaz de chat para realizar tareas específicas. Nos dimos cuenta de que si llevábamos esta característica al límite, podíamos transformar Agent Builder en una potencia de automatización.

Cómo hacerlo funcionar: desarrollo de la primera versión

Cuando empezamos el proyecto, sabíamos que queríamos que los agentes pudieran cambiar el mundo exterior. Pensamos lo siguiente: ¿y si construimos algún software “runner” (para ejecutar cualquier comando que el agente pueda pensar en el host)? Y luego: ¿qué pasaría si los runners, Elastic Agent Builder y el usuario estuvieran en una llamada los tres?

Empezamos desarrollando un proyecto en Python, Augmented Infrastructure Runners, que era esencialmente un bucle while(true) que consultaba la API de conversaciones de Elastic Agent Builder cada segundo y verificaba una sintaxis especial que habíamos creado:

Luego actualizamos la indicación para enseñarle sobre nuestra nueva sintaxis de llamada de herramienta. Bill es uno de los mantenedores de FastMCP, el marco de trabajo más popular para crear servidores del Protocolo de Contexto de Modelo (MCP) en Python. Se propuso trabajar usando el cliente FastMCP con este nuevo software runner para montar servidores MCP y poner sus herramientas a disposición del runner. Cuando el agente veía esto, ejecutaba la llamada a la herramienta y publicaba los resultados de vuelta a la conversación como si el usuario hubiera enviado los resultados. Esto hizo que el LLM respondiera al resultado, ¡y seguimos adelante!

Fue genial, pero tuvo dos problemas principales:

1. El agente soltaba todo este JSON directamente a la conversación con el usuario.

2. El primer momento en el que los mensajes se podían ver a través de la API de conversaciones era cuando se completaba una ronda de conversación (es decir, cuando el LLM respondía).

Así que nos propusimos descubrir cómo llevarlo a segundo plano.

Luego cambiamos a darle al agente una herramienta llamada call_external_tool con dos argumentos: el tool_name y los argumentos de la herramienta en JSON como cadena de texto. Esta llamada a la herramienta externa no devolvía nada, pero lo importante es que era visible en la solicitud GET a la API de conversaciones. Luego dimos permiso a los runners para escribir documentos directamente en Elasticsearch, los cuales el agente de Elastic Agent Builder podía recuperar según fuera necesario. El agente siempre está operando en respuesta a un mensaje del usuario, por lo que necesitamos iniciar el agente con un mensaje del usuario para que busque resultados y continúe con el procesamiento. Así que hicimos que los agentes insertaran un pequeño mensaje en el chat para reanudar la conversación:

Así que ya teníamos llamadas a herramientas externas. Sin embargo, debido al segundo problema mencionado anteriormente, tuvimos que deshacernos de esa parte final de arranque. De lo contrario, ¡cada llamada a una herramienta externa requería una ronda completa de conversación para recuperar los resultados!

Llevarlo a otro nivel: introducción a los flujos de trabajo

Además de las llamadas al lenguaje de búsqueda de Elasticsearch (ES|QL) y a las herramientas de búsqueda de índices, los agentes de Agent Builder pueden llamar a herramientas basadas en flujo de trabajo de Elastic. Los flujos de trabajo de Elastic ofrecen una forma flexible y fácil de gestionar para ejecutar una secuencia y una lógica de acciones arbitrarias. Para nuestros objetivos, todo lo que necesitamos que haga el flujo de trabajo es almacenar una solicitud externa de herramienta en Elasticsearch y devolver un ID para consultar los resultados. Esto da lugar a la siguiente definición sencilla de flujo de trabajo:

Con eso, en vez de depender de que la solicitud de llamada a la herramienta se escriba en la conversación, los runners pueden simplemente consultar el índice distributed-tool-requests de Elasticsearch para nuevas solicitudes externas de herramienta y reportar los resultados en otro índice de Elasticsearch con el execution.id proporcionado.

Esto elimina los dos problemas principales mencionados anteriormente:

1. El historial de conversaciones ya no está lleno de datos de las llamadas a herramientas externas.

2. Como los runners consultan el índice de Elasticsearch en lugar del historial de conversaciones, no están bloqueados por la ronda de conversación que debe completarse para que las solicitudes de herramientas externas se hagan visibles.

El segundo punto tiene la gran ventaja de que el procesamiento de las llamadas a herramientas externas comienza dentro de la fase de pensamiento del agente (y no cuando se ha completado la ronda de conversación). Esto nos permite indicarle al modelo de lenguaje grande (LLM) en la indicación del sistema que consulte los resultados de la herramienta externa hasta que estén disponibles, lo que elimina la necesidad del mensaje de inicio. En general, esto tiene el efecto positivo de que la conversación se siente más natural: el LLM puede procesar varias solicitudes de herramienta externa dentro de una sola ronda de conversación (en vez de requerir una ronda de conversación por cada solicitud de herramienta) y, por tanto, puede realizar solicitudes de usuario más complejas de una sola vez.

Todo integrado

Para cerrar la brecha entre el LLM y el rack de servidores, desarrollamos una arquitectura específica empleando las capacidades de la herramienta de Agent Builder:

1. Runners de infraestructura aumentada: desplegamos runners ligeros dentro de los entornos de destino (servidores, clústeres de Kubernetes, cuentas en la cloud). Estos runners se conectan directamente a Elastic, utilizando endpoints seguros y secretos solo disponibles para cada uno de los runners.

2. Recuperación de ES|QL: el copiloto utiliza ES|QL de Elastic para realizar búsquedas híbridas. No solo busca conocimientos, sino que busca capacidades. Consulta a los runners conectados para ver qué herramientas están disponibles (por ejemplo, list_ec2_instances, install_helm_chart).

3. Ejecución del flujo de trabajo: una vez que el agente decide un curso de acción, crea un flujo de trabajo estructurado.

4. Ciclo de retroalimentación: los runners ejecutan el comando de forma local y envían los resultados de vuelta a Elasticsearch. El copiloto lee el resultado del índice y decide el siguiente paso.

La demo: de interrupción a observabilidad

En el video, mostramos dos casos distintos que demuestran la potencia de esta arquitectura.

Escenario 1: Rescate de DevOps

Empezamos con un usuario que estaba preocupado por una interrupción de 5 millones de dólares causada por un punto ciego en su clúster de Kubernetes.

• La solicitud: "¿Cómo me aseguro de que esto no vuelva a suceder?"

• La acción: el agente no solo proporcionó un tutorial. Identificó el clúster, creó los espacios de nombres necesarios, generó secretos de Kubernetes, instaló el operador OpenTelemetry e instantáneamente proporcionó un enlace a un dashboard APM en vivo.

• El resultado: observabilidad completa de Kubernetes e información de aplicación sin que el usuario escriba ni una sola línea de YAML.

Caso 2: entrega de Security

Una regla fundamental de la seguridad de infraestructuras es que no puedes proteger lo que no puedes ver. Mientras llevamos a cabo nuestra intervención de DevOps, el agente ve una oportunidad para mejorar la seguridad del entorno.

Con una alerta iniciada tras una investigación previa relacionada con Elastic Observability, demostramos cómo un profesional de seguridad puede comunicarse directamente con su infraestructura: primero, para enumerar los activos y recursos en su entorno cloud; y segundo, para desplegar las herramientas necesarias para asegurarse de que el entorno esté protegido.

• Descubrimiento: el copiloto enumeró los recursos de AWS para el profesional de la seguridad e identificó una brecha crítica: una instancia de Amazon Elastic Compute Cloud (EC2) y un clúster de Amazon Elastic Kubernetes Service (EKS) con terminales públicos que no tienen protección para endpoints.

• Remediación: con una simple aprobación, el copiloto desplegó Elastic Security detección y respuesta extendida (XDR) y detección y respuesta en el cloud (CDR) a los activos vulnerables, asegurando el entorno en tiempo real.

• El resultado: protección de los activos y recursos de AWS desplegados con seguridad en tiempo de ejecución completa.

El futuro: todo aumentado

Este proyecto demuestra que Elastic Agent Builder puede ser el cerebro central de las operaciones distribuidas. No nos limitamos solo a infraestructura. Nuestra tecnología runner puede impulsar:

• Synthetics aumentados: diagnosticar errores de TLS en runners globales.

• Desarrollo aumentado: crear pull requests e implementar CAPTCHAs en servicios frontend.

• Operaciones aumentadas: reconfiguración automática de los servidores DNS durante una interrupción.

Pruébalo tú mismo

Creemos que el futuro de la IA no se trata solo de soporte por chat; se trata de infraestructura aumentada. Se trata de tener un socio que pueda desplegar, arreglar, observar y proteger a la par tuya.

¡Consulta el código y pruébalo tú mismo con runners distribuidos (GitHub) además de Elastic Agent Builder en Elastic Cloud Serverless hoy mismo!

• Crea un proyecto serverless en Elastic Cloud.

• Despliega el código en un ejecutor.

• Configura el runner.

• Configura tu archivo mcp.json.

• Inicia el runner, el cual creará de forma automática tu agente y sus herramientas.

• ¡Chatea con un agente que puede razonar, planificar y ejecutar acciones en tus runners distribuidos!

El equipo: Alex, Bill, Gil, Graham, & Norrie

Los agentes están ganando terreno impulsados por su potencial para ofrecer aumentos en la eficiencia y mejores experiencias del cliente. Pero en la práctica, ofrecer a los agentes el contexto adecuado es difícil, especialmente cuando se opera sobre datos empresariales desordenados y no estructurados. Los desarrolladores deben gestionar herramientas, indicaciones, estados, lógica de razonamiento, modelos y, lo que es más importante, recuperar el contexto relevante de las fuentes empresariales para ofrecer resultados y acciones precisos. Elastic Agent Builder ofrece estos componentes centrales para desarrollar agentes seguros, confiables y basados en el contexto.

Capacidades centrales de Agent Builder

Agent Builder aprovecha las inversiones a largo plazo de Elastic en relevancia de búsqueda y retrieval-augmented generation, y trabaja para convertir a Elasticsearch en la mejor base de datos vectorial que simplifique el desarrollo de agentes de IA contextuales y centrados en datos.

Agent Builder te permite:

• Comienza inmediatamente con un agente conversacional integrado que pueda responder preguntas, realizar análisis e impulsar investigaciones sobre cualquier dato en Elasticsearch.

• Pasa rápidamente de datos complejos y datos no estructurados a un agente personalizado con una experiencia de desarrollo basada en la configuración.

• Aprovecha la mejor relevancia de búsqueda híbrida de su clase mediante ES|QL integrado o herramientas personalizadas para mejorar la calidad del contexto y la confiabilidad del agente.

• Ejecuta flujos de trabajo complejos (vista previa) como herramientas reutilizables para enriquecer datos, actualizar registros, enviar mensajes y mucho más para la automatización basada en reglas.

• Conéctate a fuentes de datos fuera de Elasticsearch usando flujos de trabajo y MCP para correlacionar y combinar el contexto para los agentes.

• Integra con cualquier marco de trabajo de aplicación o agente utilizando herramientas integradas y personalizadas expuestas a través de MCP, y la capacidad de conectarte a MCP externo (vista previa), soporte para A2A y soporte completo de API.

• Amplía las capacidades de Agent Builder con la integración de soluciones de terceros, como LlamaIndex para el procesamiento de documentos complejos, o Arcade.dev para un acceso seguro y estructurado a las herramientas.

Para ampliar aún más la funcionalidad de Agent Builder, presentamos Elastic Workflows, nuestras nuevas capacidades de automatización basadas en reglas, ahora en versión preliminar técnica. Para las tareas organizacionales, los agentes a veces necesitan certeza y confiabilidad en las acciones basadas en reglas, que a menudo son necesarias para implementar una lógica de negocio específica. Elastic Workflows ofrece a los agentes una forma sencilla y declarativa de orquestar sistemas internos y externos para realizar acciones, recopilar y transformar datos y contexto. Los flujos de trabajo son totalmente componibles, orientados a eventos y flexibles, y pueden exponerse como herramientas a un agente mediante MCP.

De los datos al agente en minutos

El desarrollo de agentes puede llevar semanas de trabajo previo para consolidar almacenes de datos separados, construir pipelines manuales, ajustar búsquedas y gestionar una orquestación compleja. Agent Builder reduce el tiempo de desarrollo de agentes al eliminar la necesidad de almacenes de datos separados, bases de datos vectoriales, pipelines RAG, capas de búsqueda, traductores de búsquedas y orquestadores de herramientas, lo que te permite centrarte en la lógica de agentes y la entrega de aplicaciones.

Agent Builder integra de forma nativa las primitivas de la plataforma Elasticsearch para que el desarrollo de agentes sea rápido.

• Comienza con un agente conversacional integrado que pueda chatear inmediatamente y razonar con tus datos indexados.

• Integra agentes en aplicaciones, dashboards o sistemas CI/CD con acceso interactivo a través de Kibana, API o MCP y A2A.

• Construye con herramientas predeterminadas para entender tu estructura de datos, selecciona el índice adecuado, genera búsquedas híbridas, semánticas y estructuradas optimizadas, y crea visualizaciones configurables usando ES|QL basado en prompts de lenguaje natural.

Para profundizar más, prueba un recorrido práctico completo.

Desarrolla sobre Elasticsearch, una plataforma de datos completa para la ingeniería de contexto

Para los agentes de IA, la calidad del contexto es esencial para brindar un razonamiento eficaz y reducir los riesgos de alucinación. Para muchos agentes de IA empresarial, los datos comerciales necesarios para realizar una tarea son el contexto más decisivo. Como almacén de datos masivamente escalable, base de datos vectorial y líder en relevancia, Elasticsearch ya ofrece muchas primitivas sólidas de ingeniería de contexto. La ingeniería de contexto va más allá de la simple retrieval-augmented generation, ya que te permite adaptar y escalar la forma en que los datos se recuperan, se clasifican, se filtran y se presentan a los agentes, lo que ayuda a reducir el ruido y la ambigüedad.

Elasticsearch ofrece un motor de contexto que combina búsqueda léxica, búsqueda vectorial y filtrado estructurado para la recuperación, lo cual mejora sustancialmente el rendimiento de los LLM al garantizar que el modelo opere en un contexto relevante y preciso. Esta capacidad está respaldada por recuperación agente, junto con herramientas integradas y lógica de búsqueda que seleccionan automáticamente los índices correctos y transforman el lenguaje natural en búsquedas optimizadas para el contexto.

Con Agent Builder, puedes asegurarte de que los agentes reciban primero el contexto más útil con controles de relevancia y clasificación, lo que te permite ajustar la lógica de calificación, clasificación y filtrado. Elasticsearch te permite controlar qué importa, por qué importa y cómo se prioriza, en lugar de depender de un comportamiento de recuperación opaco. Todo esto está respaldado por Elasticsearch como una plataforma de datos escalable para almacenar y escalar todos tus datos, desde texto, vectores, metadatos, logs y más en una plataforma, lo que facilita la gestión del contexto para los agentes.

Ejecutar flujos de trabajo complejos como herramientas reutilizables

Aunque los agentes de IA permiten razonar tareas complejas, gran parte de la automatización depende de ejecutar de forma confiable acciones basadas en reglas que impongan una lógica de negocio específica. Elastic Workflows ofrece una forma sencilla y declarativa de orquestar sistemas internos y externos para realizar acciones, recopilar contexto o datos e integrarlos como parte de los agentes. Definidos en YAML, los flujos de trabajo son totalmente componibles, lo que permite que sean tan simples o complejos como requiera el trabajo. Esto ofrece a los agentes una forma eficiente de actuar en toda la plataforma y soluciones de Elasticsearch, así como con aplicaciones de terceros.

La integración de un flujo de trabajo con Agent Builder se puede realizar en tres pasos (requisito previo: habilitar los flujos de trabajo con los detalles que aparecen aquí).

1. Crea y guarda un nuevo flujo de trabajo usando el sencillo editor basado en YAML con función de autocompletado y pruebas integradas.

2. Crea una nueva herramienta en Agent Builder con el tipo “flujo de trabajo” e ingresa una descripción para ayudar al agente a determinar cuándo usar la herramienta de flujo de trabajo.

3. Agrega la herramienta de flujo de trabajo a tu agente personalizado.

4. ¡Eso es todo! Ahora el agente puede llamar al flujo de trabajo desde una conversación.

Tu agente, tus reglas

Agent Builder no te limita a un solo paradigma de desarrollo. En cambio, está diseñado para permitir enfoques de desarrollo abiertos y flexibles para los agentes, con control total sobre los datos, la relevancia, los modelos, la interoperabilidad, la seguridad y el diseño de los agentes.

Las definiciones personalizadas de agentes te permiten elegir exactamente a qué herramientas puede acceder un agente, incorporar avisos personalizados del sistema, adaptar las instrucciones del agente y definir los límites de seguridad. Los agentes siguen siendo independientes del modelo, lo que te permite configurar de manera flexible un LLM de preferencia, tanto nativo como en todo el ecosistema más amplio, sin estar limitado a un solo proveedor.

Desarrolla herramientas extensibles que encapsulen lógica específica de dominio (por ejemplo, filtros de índice específicos, ES|QL joins, pipelines analíticas), y aplica limitaciones para un uso seguro en producción. El soporte completo de API permite la interoperabilidad con otros marcos de trabajo agentes, con soporte nativo para Model Context Protocol (MCP). La integración A2A significa que puedes exponer tus Elastic Agent a otros marcos de trabajo, servicios y apps de clientes, reutilizando los mismos datos y la lógica de ingeniería de contexto a través de las integraciones.

Agent Builder permite un desarrollo flexible y abierto y está diseñado para integrarse fácilmente con marcos de trabajo y plataformas populares de agentes. Estas integraciones pueden ser esenciales para ofrecer agentes efectivos. Como describe Sam Partee, cofundador de Arcade.dev,

“Los sistemas agénticos fallan hoy porque conectar la IA a herramientas y datos es complejo. Elastic Agent Builder con Arcade.dev ofrece a los desarrolladores una forma estructurada y segura de manejar cómo los agentes recuperan el contexto, la razón y la acción, lo que lleva a los agentes de la demostración al grado de producción".

Agent Builder también aprovecha la extensibilidad de Elasticsearch para manejar datos complejos. Como describe Jerry Liu, CEO de LlamaIndex,

“Desbloquear el contexto empresarial de las fuentes de datos no estructurados es clave para construir agentes efectivos. El procesamiento de documentos complejos de Elastic Agent Builder combinado de LlamaIndex fortalece la capa de contexto crítico, lo que ayuda a los equipos a recuperar, procesar y preparar datos para que los agentes puedan razonar con mayor precisión y ofrecer mejores resultados”.

¿Qué puedes construir?

Agent Builder ya se está utilizando para una variedad de casos de uso. A continuación, se muestran algunos ejemplos y arquitecturas de referencia para empezar a utilizar los agentes:

• Automatizar la infraestructura: En escenarios de soporte, los agentes se han utilizado para leer, pensar y chatear, pero hasta la fecha, no pueden comunicarse y contactarse con la infraestructura que puede que sea necesario administrar. El equipo de ingeniería de Elastic creó un agente para la gestión automatizada de la infraestructura como parte de un hackatón. El agente investiga activamente los problemas relacionados con la infraestructura de la aplicación y toma medidas automatizadas. Utiliza flujos de trabajo para optimizar configuraciones, responder a problemas y escalar recursos, todo ello basado en una comprensión inteligente de los logs de infraestructura.

• Análisis de amenazas a la seguridad: Se desarrolló un agente de vulnerabilidad de seguridad con Elastic Agent Builder, MCP y Elasticsearch. Automatiza el análisis de amenazas correlacionando datos de seguridad interna con inteligencia de amenazas externas. El agente realiza búsquedas semánticas sobre incidentes y configuraciones históricas, incrementa los resultados con datos en tiempo real de Internet y aplica razonamientos LLM para evaluar la relevancia ambiental, priorizar riesgos y producir remediaciones accionables. Consulta la arquitectura de referencia.

• Soporte técnico al cliente: Los agentes pueden realizar múltiples tareas de soporte, incluyendo resumen de casos, desduplicación y creación de problemas, e investigación técnica profunda. Agent Builder permite esto mediante una búsqueda híbrida de varios pasos para encontrar solo los problemas, soluciones y procedimientos relacionados más relevantes, y formular hipótesis de causa raíz y planes de remediación. Agent Builder puede simplificar la arquitectura de sistemas de soporte complejos y acelerar el tiempo de entrega.

• Descubrimiento de productos y contenido: Agent Builder simplifica el proceso de exponer catálogos de productos complejos para experiencias conversacionales, al tiempo que permite a las organizaciones mantener la flexibilidad para incluir sus propios requisitos y lógica de negocio.

• Haz tu propio desarrollo: Únete al Agent Builder Hackathon, que se celebrará del 22 de enero al 27 de febrero de 2026. Trabaja con la comunidad para crear agentes de IA basados en el contexto y en varios pasos que combinen búsqueda, flujos de trabajo, herramientas y razonamiento para automatizar tareas del mundo real*

Comienza a construir agentes personalizados ahora

Comienza con una prueba de Elastic Cloud y revisa la documentación aquí. Para los clientes existentes, Agent Builder está disponible en Cloud Serverless y en el nivel Empresarial en Elastic Cloud Hosted y es autoadministrado.

* Haz clic aquí para conocer los términos, condiciones y requisitos de elegibilidad completos para la hackatón

Una de las formas en que se romperá el “cristal” es mediante la adopción de agentes de voz, que son agentes de AI que reconocen el habla humana y sintetizan audio generado por computadora. Esto se ha vuelto posible gracias al auge de las transcripciones de baja latencia, los modelos de lenguaje grandes (LLM) rápidos y los modelos de texto a voz que suenan humanos.

Los agentes de voz también necesitan acceso a los datos empresariales para ser realmente valiosos. En este blog, aprenderemos cómo funcionan los agentes de voz y diseñaremos uno para ElasticSport, una tienda ficticia de equipamiento deportivo al aire libre, con LiveKit y Elastic Agent Builder. Nuestro agente de voz será consciente del contexto y trabajará con nuestros datos.

Cómo funciona

Existen dos paradigmas en el mundo de los agentes de voz: el primero usa modelos de voz a voz, y el segundo usa un pipeline de voz compuesto por voz a texto, LLM y texto a voz. Los modelos de voz a voz tienen sus propios beneficios, pero los pipelines de voz ofrecen mucha más personalización sobre las tecnologías utilizadas y cómo se gestiona el contexto, además de un mayor control sobre el comportamiento del agente. Nos enfocaremos en el modelo de pipeline de voz.

Componentes clave

Transcripción (voz a texto)

La transcripción es el punto de entrada del pipeline de voz. El componente de transcripción toma como entrada fragmentos de audio sin procesar, transcribe el habla en texto y entrega ese texto como salida. El texto transcrito se almacena en un búfer hasta que el sistema detecta que el habla del usuario ha terminado; en ese momento, se inicia la generación del LLM. Varios proveedores externos ofrecen transcripciones de baja latencia. Al seleccionar uno, considera la latencia y la precisión de la transcripción, y asegúrate de que soporten transcripciones en streaming.

Ejemplos de API de terceros: AssemblyAI, Deepgram, OpenAI, ElevenLabs

Detección de turnos

La detección de turnos es el componente del pipeline que detecta cuándo el hablante ha terminado de hablar y la generación debería comenzar. Una forma común de hacer esto es mediante un modelo de detección de actividad vocal (VAD), como Silero VAD. El VAD utiliza los niveles de energía del audio para detectar cuándo contiene habla y cuándo ha terminado. Sin embargo, el VAD por sí solo no puede identificar la diferencia entre una pausa y el final del discurso. Por eso, a menudo se combina con un modelo de fin de enunciado que predice si el hablante ha terminado de hablar, basándose en la transcripción provisional o el audio sin procesar.

Ejemplos (Hugging Face): livekit/turn-detector, pipecat-ai/smart-turn-v3

Agente

El agente es el núcleo de un pipeline de voz. Es responsable de entender la intención, reunir el contexto adecuado y formular una respuesta en formato de texto. Elastic Agent Builder, con sus capacidades de razonamiento integradas, su biblioteca de herramientas y la integración de flujos de trabajo, permite crear un agente que puede trabajar sobre tus datos e interactuar con servicios externos.

LLM (texto a texto)

Al seleccionar un LLM para Elastic Agent Builder, hay dos características principales a considerar: las evaluaciones de razonamiento del LLM y el tiempo hasta el primer token (TTFT).

Las evaluaciones de razonamiento indican qué tan bien el LLM es capaz de generar respuestas correctas. Las evaluaciones que considerar son aquellas que evalúan la adherencia a las conversaciones de varios turnos y las de inteligencia, como MT-Bench y el set de datos Humanity's Last Exam, respectivamente.

Las evaluaciones de TTFT evalúan qué tan rápido produce el modelo su primer token de salida. Existen otros tipos de evaluaciones de latencia, pero el TTFT es particularmente importante para los agentes de voz, ya que la síntesis de audio puede comenzar tan pronto como se recibe el primer token, lo que resulta en una menor latencia entre turnos y una conversación que se siente natural.

Por lo general, hay que elegir un equilibrio entre estas dos características, ya que los modelos más rápidos suelen tener un peor desempeño en las evaluaciones de razonamiento.

Ejemplos (Hugging Face): openai/gpt-oss-20b, openai/gpt-oss-120b

Síntesis (texto a voz)

La parte final del pipeline es el modelo de texto a voz. Este componente es responsable de convertir la salida de texto del LLM en audio audible. Al igual que con el LLM, la latencia es una característica para tener en cuenta al momento de seleccionar un proveedor de texto a voz. La latencia de texto a voz se mide por el tiempo hasta el primer byte (TTFB). Es el tiempo que tarda en recibirse el primer byte de audio. Un TTFB más bajo también reduce la latencia entre turnos.

Ejemplos: ElevenLabs, Cartesia, Rime

Desarrollar el pipeline de voz

Elastic Agent Builder puede integrarse en un pipeline de voz en varios niveles diferentes:

1. Solo herramientas de Agent Builder: voz a texto → LLM (con herramientas de Agent Builder) → texto a voz

2. Agent Builder como MCP: conversión de voz a texto → LLM (con acceso a Agent Builder a través de MCP) → conversión de texto a voz

3. Agent Builder como núcleo: voz a texto → Agent Builder → texto a voz

Para este proyecto, elegí Agent Builder como el enfoque núcleo. Con este enfoque, se puede usar toda la funcionalidad de Agent Builder y los flujos de trabajo. El proyecto usa LiveKit para orquestar voz a texto, detección de turnos y texto a voz, e implementa un nodo LLM personalizado que se integra directamente con Agent Builder.

Agente de voz de soporte de Elastic

Vamos a construir un agente de voz de soporte personalizado para una tienda de deportes ficticia llamada ElasticSport. Los clientes podrán llamar a la línea de ayuda, pedir recomendaciones de productos, buscar detalles de artículos, consultar el estado de sus pedidos y pedir que se les envíe la información del pedido por mensaje de texto. Para lograr esto, primero necesitamos configurar un agente personalizado y crear herramientas para ejecutar consultas y flujos de trabajo en el lenguaje de búsqueda de Elasticsearch (ES|QL).

Configurar el agente

Indicación

La indicación le señala al agente qué personalidad debe adoptar y cómo responder. Es importante destacar que hay algunas indicaciones específicas para voz que garantizan que las respuestas se sinteticen correctamente en audio y que los malentendidos se resuelvan con elegancia.

Flujos de trabajo

Agregaremos un pequeño flujo de trabajo para enviar un SMS a través de la API de mensajería de Twilio. El flujo de trabajo se expondrá al agente personalizado como una herramienta, lo que dará como resultado una experiencia de usuario donde el agente puede enviar al usuario un SMS mientras está en la llamada. Esto permite que quien llama pueda decir, por ejemplo: “¿Puedes enviarme más detalles sobre X por mensaje de texto?”.

Herramientas ES|QL

Las siguientes herramientas permiten que el agente proporcione respuestas relevantes basadas en datos reales. El repositorio de ejemplo contiene un script de configuración para inicializar Kibana con sets de datos de productos, pedidos y base de conocimientos.

• Product.search

El set de datos de productos contiene 65 productos ficticios. Este es un documento de ejemplo:

Los campos de nombre y descripción se mapean como semantic_text, lo que permite al LLM usar la búsqueda semántica a través de ES|QL para recuperar productos relevantes. La consulta de búsqueda híbrida realiza una coincidencia semántica en ambos campos, aplicando un peso ligeramente mayor a las coincidencias en el campo de nombre mediante un refuerzo.

La búsqueda primero recupera los 20 mejores resultados clasificados por su puntuación de relevancia inicial. Luego, estos resultados se reclasifican basándose en su campo de descripción utilizando el modelo de inferencia .rerank-v1-elasticsearch y, finalmente, se reducen a los cinco productos más relevantes.

• Knowledgebase.search

Los sets de datos de la base de conocimientos contienen documentos con la siguiente estructura, en los que los campos de título y contenido se almacenan como texto semántico:

Y la herramienta usa una búsqueda similar a la herramienta product.search:

• Orders.search

La herramienta final que agregaremos es la que se usa para recuperar pedidos por order_id:

Después de configurar el agente y vincular estos flujos de trabajo y herramientas ES|QL, puedes probar al agente dentro de Kibana.

Además de desarrollar un agente de soporte para ElasticSport, el agente, los flujos de trabajo y las herramientas pueden adaptarse a otros casos de uso, como un agente de ventas que califica clientes potenciales, un agente de servicio para reparaciones del hogar, reservas para un restaurante o un agente para agendar citas.

La parte final es conectar el agente que acabamos de crear con LiveKit, los modelos de texto a voz y de voz a texto. El repositorio enlazado al final de este blog contiene un nodo de LLM personalizado de Elastic Agent Builder que se puede usar con LiveKit. Solo hay que sustituir el AGENT_ID por el tuyo propio y enlazarlo con tu instancia de Kibana.

Primeros pasos

Echa un vistazo al código, y pruébalo tú mismo aquí.

Después de todo, todo en el contexto influye en las respuestas de la IA. Es cierto lo que dicen: "Lo que das es lo que recibes".

En este artículo, presentaremos lo que significan la memoria a corto y a largo plazo para los agentes de IA, específicamente:

• La diferencia entre la memoria a corto y a largo plazo.

• Cómo se relacionan con las técnicas de RAG con bases de datos vectoriales, como Elasticsearch, y por qué es necesaria una gestión cuidadosa de la memoria.

• Los riesgos de descuidar la memoria, como el desbordamiento de contexto y el envenenamiento por contexto.

• Las mejores prácticas, como podar el contexto, resumir y recuperar solo lo relevante, para mantener la memoria de un agente útil y segura.

• Finalmente, hablaremos sobre cómo compartir y propagar la memoria en sistemas multiagente para que los agentes colaboren sin confusión mediante Elasticsearch.

Memoria a corto plazo frente a memoria a largo plazo en los agentes de IA

La memoria a corto plazo en un agente de IA suele referirse al contexto o estado conversacional inmediato, es decir, al historial de chat actual o a los mensajes recientes de la sesión activa. Esto incluye la última consulta del usuario y los intercambios recientes. Es muy similar a la información que una persona tiene en mente durante una conversación.

Los marcos de trabajo de IA suelen mantener esta memoria transitoria como parte del estado del agente (por ejemplo, al utilizar un checkpointer para almacenar el estado de la conversación, como se muestra en este ejemplo de LangGraph). La memoria a corto plazo es de sesión; es decir, existe dentro de una sola conversación o tarea y se restablece o borra cuando esa sesión termina, a menos que se guarde explícitamente en otro lugar. Un ejemplo de memoria a corto plazo limitada a sesiones sería el chat temporaldisponible en ChatGPT.

Memoria a largo plazo, por otro lado, se refiere a la información que persiste a través de conversaciones o sesiones. Este es el conocimiento que un agente conserva a lo largo del tiempo, los datos que aprendió antes, las preferencias del usuario o cualquier dato que le hayamos dicho que recuerde permanentemente.

La memoria a largo plazo generalmente se implementa almacenándola y recuperándola de una fuente externa, como un archivo o una base de datos vectorial que está fuera de la ventana de contexto inmediata. A diferencia de la memoria de chat a corto plazo, la memoria a largo plazo no se incluye automáticamente en cada solicitud. En cambio, basado en un escenario dado, el agente debe recuperarla u obtenerla cuando se invocan las herramientas relevantes. En la práctica, la memoria a largo plazo puede incluir la información del perfil del usuario, respuestas o análisis previos realizados por el agente, o una base de conocimientos que el agente puede consultar.

Por ejemplo, si tienes un agente planificador de viajes, la memoria a corto plazo contendría detalles de la consulta actual del viaje (fechas, destino, presupuesto) y cualquier pregunta de seguimiento en esa conversación; mientras que la memoria a largo plazo podría almacenar las preferencias generales de viaje del usuario, itinerarios pasados y otros datos compartidos en sesiones anteriores. Cuando el usuario regresa más tarde, el agente puede extraer de este almacenamiento a largo plazo (por ejemplo, al usuario le encantan las playas y las montañas, tiene un presupuesto promedio de 100 000 INR, tiene una lista de deseos de lugares para visitar y prefiere experimentar la historia y la cultura en lugar de atracciones para niños) de modo que no trate al usuario como una pizarra en blanco todo el tiempo.

La memoria a corto plazo (historial de chat) proporciona un contexto inmediato y continuidad, mientras que la memoria a largo plazo proporciona un contexto más amplio del que el agente puede extraer cuando sea necesario. La mayoría de los marcos de trabajo de agentes de IA avanzados permiten ambas posibilidades: realizan un seguimiento de los diálogos recientes para mantener el contexto y ofrecen mecanismos para buscar o almacenar información en un repositorio a más largo plazo. La gestión de la memoria a corto plazo garantiza que se mantenga dentro de la ventana de contexto, mientras que la gestión de la memoria a largo plazo ayuda al agente a fundamentar las respuestas basadas en interacciones previas y personalidades.

Memoria y RAG en ingeniería de contexto

¿Cómo le damos a un agente de IA una memoria útil a largo plazo en la práctica?

Un enfoque destacado para la memoria a largo plazo es la memoria semántica, que a menudo se implementa mediante generación aumentada de recuperación (RAG). Esto implica acoplar el LLM con una tienda de conocimiento externa o un almacén de datos habilitado para vectores, como Elasticsearch. Cuando el LLM necesita información más allá de lo que aparece en el prompt o en su entrenamiento integrado, realiza una recuperación semántica contra Elasticsearch e inyecta los resultados más relevantes en el prompt como contexto. De esta manera, el contexto efectivo del modelo incluye no solo la conversación reciente (memoria a corto plazo), sino también datos pertinentes a largo plazo que se obtienen sobre la marcha. A continuación, el LLM basa su respuesta tanto en su propio razonamiento como en la información recuperada, combinando eficazmente la memoria a corto plazo y la memoria a largo plazo para producir una respuesta más precisa y consciente del contexto.

Elasticsearch puede emplearse para implementar memoria a largo plazo para agentes de IA. Aquí hay un ejemplo de alto nivel de cómo se puede recuperar el contexto de Elasticsearch para la memoria a largo plazo.

De esta manera, el agente "recuerda" al buscar datos relevantes en lugar de almacenar todo en su limitado prompt, lo que conduce a diferentes riesgos.

Usar RAG con Elasticsearch o cualquier almacén vectorial ofrece múltiples beneficios:

Primero, amplía el conocimiento del modelo más allá de su límite de entrenamiento. El agente puede recuperar información actualizada o datos específicos del dominio que el LLM podría desconocer. Esto es crucial para preguntas sobre eventos recientes o temas especializados.

Segundo, obtener contexto bajo demanda ayuda a reducir las alucinaciones, especialmente porque los LLM no están capacitados con datos propietarios o altamente especializados en relación con tu caso de uso específico, lo que probablemente los exponga a alucinaciones. En lugar de que el LLM adivine o invente nueva información como se incentivó mediante la evaluación, como se destaca en un reciente artículo de OpenAI (Por qué alucinan los modelos de lenguaje), el modelo puede basarse en referencias factuales de Elasticsearch. Naturalmente, el LLM depende de la fiabilidad de los datos almacenados en el vector para realmente prevenir la desinformación, y los datos relevantes se recuperan según las medidas de relevancia de núcleo.

Tercero, la RAG permite que un agente trabaje con bases de conocimientos mucho más grandes de lo que podrías incluir en un prompt. En lugar de enviar documentos completos, como largos trabajos de investigación o documentos de políticas, a la ventana de contexto y correr el riesgo de que la sobrecarga o el contexto de información irrelevante envenene el razonamiento del modelo, la RAG se basa en la fragmentación. Los documentos grandes se dividen en piezas más pequeñas y semánticamente significativas, y el sistema recupera solo los fragmentos más relevantes para la consulta. De esta manera, el modelo no necesita un contexto de un millón de tokens para parecer conocedor; solo necesita acceso a los fragmentos correctos de un corpus mucho más grande.

Vale la pena señalar que, a medida que las ventanas de contexto de LLM crecieron (algunos modelos ahora admiten cientos de miles o incluso millones de tokens), surgió un debate sobre si la RAG está "muerta". ¿Por qué no enviar todos los datos al prompt? Si te preguntas lo mismo, consulta este maravilloso artículo de mis colegas, Jeffrey Rengifo y Eduard Martin, Contexto más largo ≠ mejor: Por qué la RAG sigue siendo importante. Esto evita el problema de la "Lo que das es lo que recibes": El LLM se mantiene enfocado en los pocos fragmentos que importan, en lugar de ejecutarse a través del ruido.

Dicho esto, integrar Elasticsearch o cualquier almacén vectorial en una arquitectura de agente de IA proporciona memoria a largo plazo. El agente almacena el conocimiento externamente y lo recupera como contexto de memoria cuando es necesario. Esto se podría implementar como una arquitectura, en la que, tras cada consulta de usuario, el agente realiza una búsqueda en Elasticsearch para obtener información relevante y luego agrega los primeros resultados al prompt antes de llamar al LLM. La respuesta también podría guardarse en el almacén a largo plazo si contiene nueva información útil (lo que crea un bucle de retroalimentación de aprendizaje). Al usar una memoria basada en recuperación, el agente se mantiene informado y actualizado, sin tener que abarrotar todo lo que sabe en cada solicitud, a pesar de que la ventana de contexto admite un millón de tokens. Esta técnica es una piedra angular de la ingeniería de contexto, ya que combina las ventajas de la recuperación de información y la IA generativa.

Aquí hay un ejemplo de un estado de conversación gestionado en memoria usando el sistema de puntos de control de LangGraph para la memoria a corto plazo durante la sesión. (Consulta nuestra app de ingeniería de contexto de apoyo).

Así es como almacena los puntos de control:

Para la memoria a largo plazo, así es como realizamos la búsqueda semántica en Elasticsearch para recuperar conversaciones previas relevantes usando embeddings vectoriales tras resumir e indexar los puntos de control en Elasticsearch.

Ahora que hemos explorado cómo se indexan y recuperan la memoria a corto y largo plazo usando los puntos de control de LangGraph en Elasticsearch, tomemos un momento para entender por qué indexar y eliminar las conversaciones completas puede ser riesgoso.

Riesgos de no gestionar la memoria de contexto

Como hablamos mucho sobre ingeniería de contexto, junto con la memoria a corto y largo plazo, entendamos qué sucede si no gestionamos bien la memoria y el contexto de un agente.

Desafortunadamente, muchas cosas pueden salir mal cuando el contexto de una IA se vuelve extremadamente largo o contiene información errónea. A medida que las ventanas de contexto se agrandan, surgen nuevos tipos de falla, como:

• Envenenamiento por contexto

• Distracción del contexto

• Confusión de contexto

• Choque de contexto

• Fuga de contexto y conflictos de conocimiento

• Alucinaciones e información errónea

Hagamos un desglose de estos problemas y otros riesgos que surgen de una mala gestión del contexto:

Envenenamiento por contexto

El envenenamiento por contexto se refiere a cuando la información incorrecta o dañina termina en el contexto y "envenena" las salidas posteriores del modelo. Un ejemplo común es una alucinación del modelo que se trata como un hecho y se inserta en el historial de conversaciones. El modelo podría entonces aprovechar ese error en respuestas posteriores, lo que agravaría el error. En los bucles iterativos de agentes, una vez que una información falsa se introduce en el contexto compartido (por ejemplo, en un resumen de las notas de trabajo del agente), puede reforzarse una y otra vez.

Los investigadores de DeepMind, en la publicación del reporte Gemini 2.5 (TL;DR, consulta aquí), observaron esto en un agente que jugaba a Pokémondesde hacía mucho tiempo: si el agente alucinaba un estado de juego erróneo y eso quedaba registrado en su contexto (su memoria de objetivos), el agente formaba estrategias sin sentido en torno a un objetivo imposible y se quedaba atascado. En otras palabras, un recuerdo contaminado puede llevar al agente por el camino equivocado de forma indefinida.

El envenenamiento del contexto puede ocurrir de forma inocente (por error) o incluso maliciosa, por ejemplo, mediante ataques de inyección de prompt donde un usuario o un tercero introduce una instrucción oculta o un hecho falso que el agente luego recuerda y sigue.

Contramedidas recomendadas:

Basándose en la información de Wiz, Zerlo y Anthropic, las contramedidas para el envenenamiento del contexto se centran en prevenir que la información errónea o engañosa entre en la ventana de contexto, el pipeline de recuperación o la ventana de contexto de un LLM. Los pasos clave incluyen:

• Revisa el contexto constantemente: monitoriza la conversación o el texto recuperado para detectar cualquier cosa sospechosa o dañina, no solo el prompt inicial.

• Utiliza fuentes confiables: Puntúa o etiqueta los documentos según su credibilidad para que el sistema prefiera la información confiable e ignore los datos con baja puntuación.

• Detecta datos inusuales: usa herramientas que detecten contenido extraño, fuera de lugar o manipulado, y elimínalo antes de que el modelo lo use.

• Filtra entradas y salidas: Añade salvaguardas para que el texto dañino o engañoso no pueda entrar fácilmente en el sistema ni ser repetido por el modelo.

• Mantén el modelo actualizado con datos limpios: actualiza regularmente el sistema con información verificada para contrarrestar cualquier dato incorrecto que haya pasado desapercibido.

• Intervención humana: Haz que las personas revisen las salidas importantes o las comparen con fuentes conocidas y confiables.

Los hábitos sencillos de los usuarios también ayudan, como restablecer los chats largos, compartir solo información relevante, dividir las tareas complejas en pasos más pequeños y mantener notas claras fuera del modelo.

En conjunto, estas medidas crean una defensa en capas que protege a los LLMs del envenenamiento del contexto y mantiene las salidas precisas y fiables.

Sin contramedidas como las mencionadas aquí, un agente podría recordar instrucciones, como ignorar directrices previaso datos triviales que un atacante introdujo, lo que podría provocar salidas dañinas.

Distracción del contexto

Distracción por contexto es cuando un contexto crece tanto que el modelo se sobreenfoca en el contexto, y descuida lo que aprendió durante el entrenamiento. En casos extremos, esto se asemeja al olvido catastrófico; es decir, el modelo efectivamente "olvida" su conocimiento subyacente y se apega demasiado a la información colocada frente a él. Estudios previos han demostrado que los LLM a menudo pierden el enfoque cuando la solicitud es extremadamente larga.

El agente Gemini 2.5, por ejemplo, admitía una ventana de un millón de tokens, pero una vez que su contexto creció más allá de cierto punto (del orden de 100 000 tokens en un experimento), comenzó a fijarse en repetir sus acciones pasadas en lugar de encontrar nuevas soluciones. En cierto sentido, el agente se convirtió en prisionero de su extensa historia. Siguió mirando su largo log de movimientos anteriores (el contexto) e imitándolos, en lugar de usar su conocimiento de entrenamiento subyacente para diseñar estrategias nuevas y novedosas.

Esto es contraproducente. Queremos que el modelo emplee el contexto relevante para ayudar al razonamiento, no para anular su capacidad de pensamiento. Cabe destacar que incluso los modelos con ventanas enormes presentan esta podredumbre contextual: su rendimiento se degrada de forma no uniforme a medida que se agregan más tokens. Parece haber un presupuesto de atención. Al igual que los humanos con memoria de trabajo limitada, un LLM tiene una capacidad finita para atender a los tokens, y a medida que ese presupuesto se estira, su precisión y enfoque disminuyen.

Como medida de mitigación, puedes prevenir la distracción del contexto usando fragmentación, ingeniería de la información correcta, resumen regular del contexto y técnicas de evaluación y seguimiento para medir la precisión de la respuesta mediante puntaje.

Estos métodos mantienen el modelo basado tanto en el contexto relevante como en su entrenamiento subyacente, lo que reduce el riesgo de distracción y mejora la calidad general del razonamiento.

Confusión de contexto

La confusión de contexto ocurre cuando el modelo emplea contenido superfluo en el contexto para generar una respuesta de baja calidad. Un ejemplo claro es dar a un agente un gran conjunto de herramientas o definiciones de API que podría emplear. Si muchas de esas herramientas no están relacionadas con la tarea actual, el modelo puede intentar usarlas de forma inapropiada, simplemente porque están presentes en contexto. Los experimentos demostraron que proporcionar más herramientas o documentos puede perjudicar el rendimiento si no se necesitan todos. El agente empieza a cometer errores, como llamar a la función equivocada o referenciar texto irrelevante.

En un caso, un pequeño modelo Llama 3.1 8B falló en una tarea cuando se le dieron 46 herramientas para considerar, pero tuvo éxito cuando se le dieron solo 19 herramientas. Las herramientas adicionales crearon confusión, a pesar de que el contexto se ajustaba a los límites de longitud. El problema subyacente es que cualquier información en el mensaje será atendida por el modelo. Si no sabe ignorar algo, ese algo podría influir en su salida de maneras no deseadas. Los elementos irrelevantes pueden "robar" parte de la atención del modelo y llevarlo por el camino equivocado (por ejemplo, un documento irrelevante podría hacer que el agente responda a una pregunta diferente a la que se le hizo). La confusión contextual a menudo se manifiesta cuando el modelo produce una respuesta de baja calidad que integra contextos no relacionados. Consulta el artículo de investigación: Menos es más: optimización de la llamada de funciones para la ejecución de LLM en dispositivos periféricos.

Nos recuerda que más contexto no siempre es mejor, especialmente si no está curado para que sea relevante.

Choque de contexto

Choque de contexto ocurre cuando partes del contexto se contradicen entre sí, lo que causa inconsistencias internas que desvían el razonamiento del modelo. Puede producir un choque si el agente acumula múltiples piezas de información que están en conflicto.

Por ejemplo, imagina un agente que obtuvo datos de dos fuentes: una dice que el vuelo A sale a las 5 p. m. y la otra dice que el vuelo A sale a las 6 p. m. Si ambos hechos terminan en el contexto, el pobre modelo no tiene forma de saber cuál es el correcto; puede confundirse o producir una respuesta incorrecta o no similar.

El choque de contexto también ocurre frecuentemente en conversaciones de múltiples turnos donde los intentos anteriores del modelo de responder todavía persisten en el contexto junto con información refinada posterior.

Un estudio de investigación realizado por Microsoft y Salesforce muestra que si divides una consulta compleja en múltiples turnos de chatbot (agregando detalles gradualmente), la precisión final disminuye significativamente, en comparación con dar todos los detalles en un solo mensaje. ¿Por qué? Porque las primeras vueltas contienen respuestas intermedias parciales o incorrectas del modelo, y estas permanecen en el contexto. Cuando el modelo luego intenta responder con toda la información, su memoria aún incluye esos intentos incorrectos, que entran en conflicto con la información corregida y lo desvían del camino. Básicamente, el contexto de la conversación entra en conflicto consigo mismo. El modelo puede usar inadvertidamente una pieza de contexto desactualizada (de un turno anterior) que no se aplica después de que se agrega nueva información.

En los sistemas de agentes, el choque de contexto es especialmente peligroso porque un agente puede combinar las salidas de diferentes herramientas o subagentes. Si esas salidas no coinciden, el contexto agregado es inconsistente. El agente podría entonces quedarse atascado o producir resultados absurdos al tratar de conciliar las contradicciones. La prevención del choque de contexto implica asegurarse de que el contexto sea fresco y consistente,por ejemplo, borrar o actualizar cualquier información obsoleta y no mezclar fuentes que no hayan sido objeto de un estudio de consistencia.

Fuga de contexto y conflictos de conocimiento

En los sistemas en los que varios agentes o usuarios comparten un almacén de memoria, existe el riesgo de que la información se filtre entre contextos.

Por ejemplo, si las incrustaciones de datos de dos usuarios distintos residen en la misma base de datos vectorial sin un control de acceso adecuado, un agente que responda a la consulta del usuario A podría recuperar accidentalmente parte de la memoria del usuario B. Esta fuga entre contextos puede exponer información privada o simplemente crear confusión en las respuestas.

Según el Top 10 de OWASP para aplicaciones LLM, las bases de datos vectoriales de usuarios múltiples deben protegerse contra este tipo de fugas:

Según LLM08:2025 Debilidades de Vectores y Embedding, uno de los riesgos comunes es la fuga de contexto:

Otro aspecto es que un LLM podría tener problemas para anular su conocimiento integrado con nueva información de memoria. Si el modelo fue entrenado con algún hecho y el contexto recuperado dice lo contrario, el modelo puede confundirse sobre cuál confiar. Sin un diseño adecuado, el agente podría confundir contextos o no actualizar el conocimiento antiguo con nueva evidencia, lo que llevaría a respuestas obsoletas o incorrectas.

Alucinaciones e información errónea

Mientras que una alucinación (el LLM inventa información plausible pero falsa) es un problema conocido incluso sin contextos largos, una mala gestión de la memoria puede amplificarlo.

Si la memoria del agente carece de un hecho crucial, el modelo puede llenar el vacío con una suposición, y si esa suposición entra en el contexto (envenenándolo), el error persiste.

El informe de seguridad de los LLM OWASP (LLM09:2025 Desinformación) destaca la desinformación como una vulnerabilidad de núcleo: los LLM pueden ofrecer respuestas seguras pero fabricadas, y los usuarios pueden confiar demasiado en ellos. Un agente con una memoria a largo plazo deficiente o desactualizada podría citar con confianza algo que era cierto el año pasado pero que ahora es falso, a menos que su memoria se mantenga actualizada.

La dependencia excesiva en la salida de la IA (ya sea por parte de los usuarios o del propio agente en un bucle) puede empeorar esta situación. Si nadie revisa nunca la información almacenada en la memoria, el agente puede acumular falsedades. Esta es la razón por la que la RAG se usa a menudo para reducir las alucinaciones: al recuperar una fuente autorizada, el modelo no tiene que inventar hechos. Pero si tu recuperación trae el documento incorrecto (digamos, uno que contiene información errónea) o si una alucinación temprana no se poda, el sistema puede propagar esa información errónea a través de sus acciones.

La conclusión: no administrar la memoria puede conducir a salidas incorrectas y engañosas, lo que puede ser perjudicial, especialmente si hay mucho en juego (por ejemplo, malos consejos en un dominio financiero o médico). Un agente necesita mecanismos para verificar o corregir su contenido de memoria, no solo confiar incondicionalmente en lo que esté en el contexto.

En resumen, darle a un agente de IA una memoria infinitamente larga o volcar cada cosa posible en su contexto no es una receta para el éxito.

Mejores prácticas para la gestión de memoria en aplicaciones LLM

Para evitar las trampas anteriores, los desarrolladores e investigadores idearon una serie de mejores prácticas para administrar el contexto y la memoria en sistemas de IA. Estas prácticas tienen como objetivo mantener el contexto de trabajo de la IA ágil, relevante y actualizado. Aquí hay algunas de las estrategias clave, junto con ejemplos de cómo ayudan.

RAG: Utiliza un contexto específico.

Gran parte de la RAG ya se ha cubierto en la sección anterior, así que esto sirve como un conjunto conciso de recordatorios prácticos:

• Usa la recuperación dirigida, no la carga masiva: Recupera solo los fragmentos más relevantes en lugar de insertar documentos enteros o historiales de conversación completos en el prompt.

• Trata la RAG como una recuperación de memoria justo a tiempo: Obtén el contexto solo cuando sea necesario, en lugar de traer todo en cada turno.

• Prefiere estrategias de recuperación conscientes de la relevancia: enfoques como la búsqueda semántica top-k, la fusión de rango recíproco o el filtrado de carga de herramientas ayudan a reducir el ruido y mejorar la conexión a tierra.

• Las ventanas de contexto más grandes no eliminan la necesidad de RAG: dos párrafos muy relevantes son casi siempre más efectivos que 20 páginas poco relacionadas.

Dicho esto, la RAG no se trata de agregar más contexto; se trata de agregar el contexto adecuado.

Carga de herramientas

Configuración de herramientas se trata de darle a un modelo solo las herramientas que realmente necesita para una tarea. El término proviene de los juegos: Eliges un equipo que se ajuste a la situación. Demasiadas herramientas te ralentizan; las incorrectas causan fallas. Los LLM se comportan de la misma manera, según el documento de investigación Menos es más. Una vez que pasas de unas 30 herramientas, las descripciones empiezan a solaparse y el modelo se confunde. Después de ~100 herramientas, el fracaso está casi garantizado. Esto no es un problema de ventana de contexto, es confusión de contexto.

Una solución simple y efectiva es RAG-MCP. En lugar de poner todas las herramientas en el mensaje, las descripciones de las herramientas se almacenan en una base de datos vectorial y solo se recuperan las más relevantes por solicitud. En la práctica, esto permite mantener un equipamiento reducido y específico, acorta considerablemente los tiempos de respuesta y puede mejorar hasta tres veces la precisión en la selección de herramientas.

Los modelos más pequeños alcanzan este límite incluso antes. La investigación muestra que un modelo 8B falla con docenas de herramientas, pero tiene éxito una vez que se reduce la carga. La selección dinámica de herramientas, a veces con un LLM primero, razonando sobre lo que cree que necesita, puede aumentar el rendimiento en un 44%, al tiempo que reduce el uso de poder y la latencia. La clave es que la mayoría de los agentes solo necesitan unas pocas herramientas, pero a medida que tu sistema crece, la carga de herramientas y el RAG-MCP se convierten en decisiones de diseño de primer orden.

Poda de contexto: limita la duración del historial de chat

Si una conversación se prolonga durante muchos turnos, el historial de chat acumulado puede llegar a ser demasiado grande para caber, lo que provoca un desbordamiento del contexto o distrae demasiado al modelo.

Recortar significa eliminar o acortar programáticamente las partes menos importantes del diálogo a medida que crece. Una forma simple es descartar los turnos más antiguos de la conversación cuando alcanzas un cierto límite, manteniendo solo los últimos N mensajes. Una poda más sofisticada podría eliminar digresiones irrelevantes o instrucciones previas que ya no son necesarias. El objetivo es mantener la ventana de contexto despejada de noticias antiguas.

Por ejemplo, si el agente resolvió un subproblema hace 10 turnos y hemos seguido adelante desde entonces, podríamos eliminar esa parte del historial del contexto (asumiendo que ya no será necesaria). Muchas implementaciones basadas en chat hacen esto: mantienen una ventana móvil con los mensajes recientes.

Recortar puede ser tan simple como "olvidar" las primeras partes de una conversación una vez que se han resumido o se consideran irrelevantes. De esta manera, reducimos el riesgo de errores por exceso de contexto y también reducimos la distracción del contexto, por lo que el modelo no verá contenido antiguo o fuera de tema ni se distraerá con él. Este enfoque es muy similar a cómo los humanos podrían no recordar cada palabra de una charla de una hora, pero retendrán los puntos destacados.

Si tienes dudas acerca de la poda de contexto, como lo destaca el autor Drew Breunig aquí, el uso del modelo Provence (`naver/provence-reranker-debertav3-v1`), un podador de contexto ligero (1.75 GB), eficiente y preciso para la respuesta a preguntas, puede marcar la diferencia. Puedes reducir documentos grandes a solo el texto más relevante para una búsqueda determinada. Puedes llamarlo en intervalos específicos.

Así es como invocamos el modelo `provence-reranker` en nuestro código para podar el contexto:

Empleamos el modelo de reranking de Provenza (`naver/provence-reranker-debertav3-v1`) para calificar la relevancia de las oraciones. El filtrado basado en umbrales mantiene las oraciones por encima del umbral de relevancia. Además, introducimos un mecanismo de respaldo, donde volvemos al contexto original si la poda falla. Finalmente, el logging de estadísticas rastrea el porcentaje de reducción en el modo detallado.

Resumen de contexto: Condensa la información antigua en lugar de eliminarla por completo

El resumen es un complemento al recorte. Cuando la historia o la base de conocimientos se vuelve demasiado grande, puedes emplear el LLM para generar un breve resumen de los puntos importantes y usar ese resumen en lugar del contenido completo en el futuro, como realizamos en nuestro código anterior.

Por ejemplo, si un asistente de IA tuvo una conversación de 50 turnos, en lugar de enviar los 50 turnos al modelo en el turno 51 (que probablemente no encaje), el sistema podría tomar los turnos 1 a 40, hacer que el modelo los resuma en un párrafo y luego solo proporcionar ese resumen más los últimos 10 turnos en el siguiente mensaje. De esta manera, el modelo aún sabe lo que se discutió sin necesidad de conocer todos los detalles. Los primeros usuarios del chatbot lo hacían manualmente preguntando: "¿Puedes resumir lo que hablamos hasta ahora?" y luego continuaban en una nueva sesión con el resumen. Ahora se puede automatizar. El resumen no solo ahorra espacio en la ventana de contexto, sino que también puede reducir la confusión y distracción del contexto al eliminar detalles adicionales y conservar solo los hechos más importantes.

Aquí es cómo usamos los modelos de OpenAI (puedes usar cualquier LLM) para condensar el contexto a la vez que preservamos toda la información relevante, lo que elimina la redundancia y la duplicación.

Es importante destacar que cuando se resume el contexto, es menos probable que el modelo se vea abrumado por detalles triviales o errores pasados (suponiendo que el resumen sea exacto).

Sin embargo, el resumen debe hacerse con cuidado. Un mal resumen puede omitir un detalle crucial o incluso provocar un error. Es esencialmente otro mensaje para el modelo ("resume esto"), por lo que puede alucinar o perder matices. La mejor práctica es resumir de forma incremental y quizás mantener algunos hechos canónicos sin resumir.

No obstante, ha demostrado ser muy útil. En el escenario del agente Gemini, resumir el contexto cada ~100k tokens era una forma de contrarrestar la tendencia del modelo a repetir. El resumen actúa como una memoria comprimida de la conversación o los datos. Como desarrolladores, podemos implementar esto haciendo que un agente llame periódicamente a una función de resumen (tal vez un LLM más pequeño o una rutina dedicada) en el historial de la conversación o en un documento largo. El resumen resultante reemplaza el contenido original en el prompt. Esta táctica se utiliza ampliamente para mantener los contextos dentro de unos límites y sintetizar la información.

Cuarentena de contexto: aislar los contextos cuando sea posible

Esto es más relevante en sistemas de agentes complejos o flujos de trabajo de varios pasos. La idea de la segmentación del contexto es dividir una tarea grande en tareas más pequeñas e independientes, cada una con su propio contexto, para que nunca acumules un contexto enorme que lo contenga todo. Cada subagente o subtarea trabaja en una parte del problema con un contexto enfocado, y luego un agente de nivel superior, o supervisor o coordinador integra los resultados.

La estrategia de investigación de Anthropic emplea múltiples subagentes, cada uno investigando un aspecto diferente de una pregunta, con sus propias ventanas de contexto, y un agente principal que lee los resultados destilados de esos subagentes. Este enfoque paralelo y modular significa que ninguna ventana de contexto individual se vuelve demasiado voluminosa. También reduce la posibilidad de que se mezcle información irrelevante, cada hilo se mantiene en el tema (sin confusión de contexto) y no lleva equipaje innecesario al responder su subpregunta específica. En cierto sentido, es como ejecutar hilos separados de pensamiento que solo comparten sus resultados, no todo su proceso de pensamiento.

En sistemas multiagente, este enfoque es esencial. Si el agente A se encarga de la tarea A y el agente B se encarga de la tarea B, no hay razón para que ninguno de los dos consuma todo el contexto del otro, a menos que sea realmente necesario. En cambio, los agentes pueden intercambiar solo la información necesaria. Por ejemplo, el agente A puede pasar un resumen consolidado de sus hallazgos al agente B a través de un agente supervisor, mientras que cada subagente mantiene su propio hilo de contexto dedicado. Esta configuración no requiere intervención humana; se basa en un agente supervisor con herramientas habilitadas y con un intercambio de contexto mínimo y controlado.

No obstante, diseñar tu sistema de manera que los agentes o herramientas operen con la mínima superposición de contexto necesaria puede mejorar considerablemente la claridad y el rendimiento. Piensa en ello como microservicios para IA, cada componente se ocupa de su contexto y pasa mensajes entre ellos de una manera controlada, en lugar de un contexto monolítico. Estas mejores prácticas a menudo se usan en combinación. Además, esto te da la flexibilidad de recortar historiales triviales, resumir mensajes o conversaciones antiguas importantes, transferir los registros detallados a Elasticsearch para contexto a largo plazo y usar la recuperación para recuperar cualquier cosa relevante cuando sea necesario.

Como se mencionó aquí, el principio rector es que el contexto es un recurso limitado y valioso. Quieres que cada token del prompt se gane su conservación, lo que significa que debería contribuir a la calidad de la salida. Si algo en la memoria no está cumpliendo con su función (o peor aún, está causando confusión), entonces debe ser eliminado, resumido o descartado.

Como desarrolladores, ahora podemos programar el contexto igual que programamos el código, decidiendo qué información incluir, cómo formatearla y cuándo omitirla o actualizarla. Siguiendo estas prácticas, podemos proporcionar a los agentes LLM el contexto necesario para realizar tareas sin caer en los modos de fallo descritos anteriormente. El resultado son agentes que recuerdan lo que deben, olvidan lo que no necesitan y recuperan lo que requieren justo a tiempo.

Conclusión

La memoria no es algo que añades a un agente; es algo que diseñas. La memoria a corto plazo es el bloc de notas de trabajo del agente, y la memoria a largo plazo es su almacén duradero de conocimiento. La RAG es el puente entre los dos, ya que convierte un almacén de datos pasivo, como Elasticsearch, en un mecanismo de recuperación activo que puede conectar a tierra las salidas y mantener el agente actualizado.

Pero la memoria es un arma de doble filo. En el momento en que dejas que el contexto crezca sin control, invitas al envenenamiento, la distracción, la confusión y los choques, y en los sistemas compartidos, incluso la fuga de datos. Por eso, el trabajo de memoria más importante no es "almacenar más", sino "seleccionar mejor": recuperar selectivamente, podar agresivamente, resumir cuidadosamente y evitar mezclar contextos no relacionados a menos que la tarea realmente lo demande.

En la práctica, una buena ingeniería de contexto parece un buen diseño de sistemas: contextos más pequeños y suficientes, interfaces controladas entre componentes y una clara separación entre el estado crudo y el estado destilado que realmente quieres que vea el modelo. Si se hace correctamente, no terminas con un agente que lo recuerda todo, sino con un agente que recuerda las cosas adecuadas, en el momento adecuado, por la razón correcta.

Elastic Agent Builder facilita la creación de agentes de IA conectados a datos. Te mostraremos cómo hacerlo en esta publicación de blog. Veamos todos los pasos necesarios para crear un agente con una herramienta MCP que acceda a los datos almacenados en Elastic. Luego usaremos el SDK de Strands Agents y sus capacidades Agent2Agent (A2A) para operar el agente. El SDK de Strands Agents es una plataforma de desarrollo de IA multiagente que puedes usar para crear apps de agentes con el código justo para asegurarte de obtener el resultado que quieres.

Construyamos un agente de IA que juegue el juego de RPS+, que es una versión del clásico juego de "Piedra, papel o tijeras" con un toque adicional; les da a los jugadores del juego un par de opciones adicionales.

Requisitos previos

Aquí está lo que se requiere para seguir los pasos en esta publicación de blog:

• Un editor de texto ejecutándose en tu computadora local

  • Visual Studio Code es lo que usaremos para las instrucciones de ejemplo en esta publicación de blog

• Python 3.10 o superior funcionando en tu computadora local

Crea un proyecto Serverless

Lo primero que necesitamos es un proyecto Elasticsearch Serverless, que incluye Elastic Agent Builder.

Ve a cloud.elastic.co y crea un nuevo proyecto de Elasticsearch Serverless.

Crea un índice y agrega datos

A continuación, vamos a agregar algunos datos a nuestro proyecto de Elasticsearch. Abre Developer Tools, donde podemos ejecutar comandos para crear un nuevo índice e insertar algunos datos en él. Selecciona Herramientas para desarrolladores en el menú de navegación de nivel superior.

Copia y pega el siguiente comando PUT en el área de entrada de solicitud de la consola de Developer Tools. Esta declaración crea un índice de Elasticsearch llamado “game-docs”.

Haz clic en el botón Enviar solicitud que aparece en el lado derecho de la declaración en Herramientas para desarrolladores. Deberías ver una notificación que confirme que el índice game-docs se creó en el área de respuesta de Herramientas para desarrolladores.

Un índice llamado game-docs es el lugar ideal para almacenar los datos del juego que estamos creando. Pongamos un documento llamado rps+-md en este índice que contiene todos los datos que requiere nuestro juego. Copia y pega el siguiente comando PUT en la consola de Herramientas para desarrolladores.

Haz clic en el botón Enviar solicitud junto a la instrucción para ejecutarlo y agregar el documento rps+-md al índice de documentación del juego.

Ahora deberíamos tener algunos datos para consultar, y con Agent Builder, eso es más simple que nunca.

Selecciona Agentes en el menú de navegación superior.

Luego, todo lo que tienes que hacer es preguntarle al agente de Elastic AI predeterminado: "¿Qué datos tengo?".

El agente de Elastic AI evalúa los datos y devuelve una explicación concisa de los datos que tenemos.

Crear una herramienta

Listo, ahora tenemos algunos datos en Elastic; vamos a ponerlos en práctica. Agent Builder incluye soporte integrado para crear herramientas MCP que ayudan a los agentes a acceder a los datos que necesitan para tener el contexto adecuado para su tarea. Vamos a crear una herramienta sencilla que recupere los datos de nuestro juego.

Haz clic en el menú de acciones de Agent Builder.

Selecciona Ver todas las herramientas en las opciones del menú.

Haz clic en + Nueva herramienta.

En el formulario Crear herramienta, selecciona ES|QLcomo Tipo de herramienta e ingresa los siguientes valores.

Para el ID de la herramienta:

Para la Descripción:

Para la configuración, ingresa la siguiente consulta en el área de texto Consulta ES|QL :

Tu formulario completado de Crear herramienta debería verse así. Haz clic en Guardar para crear la herramienta.

Tenemos una nueva herramienta disponible en el estante de herramientas. Las herramientas no deberían estar colgadas perpetuamente en un estante; hay que darles un uso digno. Creemos un agente que pueda emplear nuestra nueva herramienta personalizada.

Crea un agente y asígnale una herramienta

Crear un agente es sorprendentemente sencillo con Agent Builder. Solo tienes que ingresar las instrucciones del agente con algunos detalles y eso es todo lo que necesitas. Vamos a crear un agente ahora.

Haz clic en Gestionar agentes.

Haz clic en + Nuevo agente.

Introduce la siguiente información en el formulario Nuevo agente.

Para ID de agente, ingresa el texto a continuación:

En el área de texto de Instrucciones personalizadas , ingresa las siguientes instrucciones:

Para el Nombre de visualización, ingresa el texto a continuación:

Para la Descripción de la pantalla, ingresa el texto a continuación:

Brinda al agente la herramienta personalizada que creamos previamente al hacer clic en la pestaña Herramientas.

Selecciona solo la herramienta example.get_game_docs que creamos anteriormente.

Haz clic en Guardar para crear el nuevo agente.

Probemos nuestro nuevo agente. Hay un enlace útil para iniciar un chat con cualquier agente de la lista de agentes.

Simplemente ingresa “iniciar juego” y el juego comenzará. ¡Funciona!

Puedes ver que el agente muestra su elección de objeto de juego en la parte superior de su respuesta. Esto es útil porque podemos ver la elección del agente y confirmar que el juego funciona como se espera. Sin embargo, conocer la elección de tu oponente antes de elegir no lo convierte en un juego muy divertido de "Piedra, papel o tijeras". Para pulir y perfeccionar el juego hasta su forma final, podemos usar una plataforma de orquestación de agentes que pueda controlar a los agentes con código.

El SDK de Strands Agents entra al chat.

SDK de agentes de Strands

Si tienes curiosidad por probar nuevos marcos de trabajo de desarrollo de agentes, entonces vale la pena probar el SDK de Strands Agents. El SDK de Strands Agents fue lanzado por AWS (mayo de 2025) como una implementación de open source Python, y ahora también hay una versión en Typescript.

Introducción al SDK de Strands Agents en Python

Enciende tus motores de programación, ahora vamos a pasar rápidamente por el proceso de clonación y ejecución de una app de ejemplo que usa Strands Agents para controlar el agente de RPS+ mediante el protocolo A2A. Vamos a crear una versión ajustada del juego RPS+ para que la elección del agente se revele después de que hagas tu elección, porque, después de todo, es la adivinación y el resultado sorpresa lo que hace que juegos como "Piedra, papel o tijeras" sean divertidos.

En tu computadora local, abre Visual Studio Code y abre una nueva terminal.

En la terminal recién abierta, ejecuta el siguiente comando para clonar el repositorio de Elasticsearch Labs:

Ejecuta el siguiente comando cd para cambiar el directorio al directorio elasticsearch-labs:

A continuación, ejecuta el siguiente comando para abrir el repositorio en Visual Studio Code:

En el Explorador de archivos de Visual Studio, expande las carpetas supporting-blog-content y agent-builder-a2a-strands-agents y luego abre el archivo elastic_agent_builder_a2a_rps+.py. Así es como se ve el archivo abierto en Visual Studio Code:

Aquí tienes el contenido de elastic_agent_builder_a2a_rps+.py que deberías ver en tu editor de texto:

Repasemos qué está pasando en este código. A partir del método main() , el código comienza accediendo a las variables de entorno para la URL del agente y la clave de API. Luego, usamos esos valores para crear un httpx client que podamos usar para obtener la tarjeta de agente para el agente. El cliente luego usa los detalles de la tarjeta del agente para enviar una solicitud de "iniciar juego" al agente. Un aspecto interesante a tener en cuenta aquí es que incluimos un valor random_game_object como parte de la solicitud "start game". Este valor es un número aleatorio generado con el módulo aleatorio de la biblioteca estándar de Python. La razón para hacerlo es que resulta que los poderosos LLM (que hacen posibles a los agentes de IA) no son muy buenos en la aleatoriedad. No hay problema, Python viene al rescate.

Continuando con la programación, una vez que el agente responde a la solicitud de "iniciar juego", el código elimina la selección del objeto de juego del agente y lo guarda en la variable agent_choice. El resto de la respuesta se muestra como texto para el usuario final. Luego, se le solicita al usuario su entrada de elección de objeto de juego, la cual se envía al agente. El código muestra la elección del objeto del juego del agente junto con la determinación final del agente sobre el resultado del juego.

Establecer la URL de tu agente y la clave de API como variables de entorno

Dado que la app de ejemplo se ejecutará en tu computadora local, para comunicarla con nuestro agente Agent Builder, debemos proporcionar al SDK de Strands Agents una URL A2A y una clave API para el agente. La app de ejemplo emplea un archivo llamado .env para almacenar estos valores.

Haz una copia del archivo env.example y nombra el nuevo archivo .env

Vuelve a Elastic Agent Builder, donde podrás obtener los dos valores que necesitas.

Selecciona Ver todas las herramientas en el menú de acciones de Agent Builder en la parte superior derecha de la página.

Haz clic en el menú desplegable servidor MCP en la parte superior de la página Herramientas y selecciona Copiar URL del servidor MCP.

Pega la URL del servidor MCP en el archivo .env como reemplazo para el valor de marcador de posición <YOUR-ELASTIC-AGENT-BUILDER-URL> . Ahora necesitamos hacer una actualización a la URL, es decir, reemplazar el texto final “mcp” con “a2a” porque el protocolo A2A es lo que usará el Agent Strands SDK para comunicarse con el agente que se ejecuta en Elastic Agent Builder.

La URL editada debería verse así:

El otro valor que necesitamos obtener mientras estamos aquí en Elastic Cloud es una clave API. Haz clic en Elasticsearch en el menú de navegación superior.

Haz clic en el botón Copiar clave API para copiar la clave API.

Ahora, de vuelta en Visual Studio Code, pega la clave API en el archivo .env para reemplazar el texto del marcador de posición <YOUR-ELASTIC-API-KEY> . Tu archivo .env debería verse algo así:

Ejecuta la app de ejemplo

Abre una nueva terminal en Visual Studio Code.

Empieza ejecutando el siguiente comando cd en la terminal:

Ejecuta el siguiente comando para crear un entorno virtual en Python.

Dependiendo del sistema operativo de tu computadora local, ejecuta el siguiente comando para activar el entorno virtual.

• MacOS/Linux

• Windows

La app de ejemplo utiliza Strands Agents SDK, y ahora nos encontramos en el punto de este tutorial en el que debes instalarlo. Ejecuta el siguiente comando para instalar el SDK de Strands Agents junto con todas tus dependencias requeridas de la biblioteca de Python.

Es hora de limpiar la plataforma de lanzamiento y comenzar la cuenta regresiva. Estamos listos para lanzar esta app. Retírate. Vamos a ejecutarla usando el siguiente comando:

Deberías desafiarte con un juego de RPS+. ¡Bien hecho y mucha suerte!

Crea tus apps de IA con contexto relevante

Crear un agente con IA es ahora una habilidad en tu caja de herramientas. Y has visto lo fácil que es usar agentes de Elastic Agent Builder a través de A2A en marcos de trabajo de agentes como Strands Agents SDK. Prueba Elastic para crear agentes de IA conectados al contexto relevante en tus datos personalizados.

Recientemente contribuimos al proyecto open source Google MCP Toolbox for Databases agregando soporte para Elasticsearch como base de datos.

Con esta nueva característica, ahora puedes usar Google MCP Toolbox para conectarte a Elasticsearch y “conversar” directamente con tus datos.

Elasticsearch

Es necesario tener una instancia de Elasticsearch en funcionamiento. Puedes activar una prueba gratuita en Elastic Cloud o instalarla localmente utilizando el script start-local:

Esto instalará Elasticsearch y Kibana en tu computadora y generará una clave API que se utilizará para configurar Google MCP Toolbox.

La clave de API se mostrará como salida del comando anterior y se almacenará en un archivo .env. en la carpeta elastic-start-local.

Instala el set de datos de ejemplo

Tras la instalación, puedes iniciar sesión en Kibana con el nombre de usuario elastic y la contraseña generada por el script start-local (almacenada en un archivo .env).

Puedes instalar el conjunto de datos de pedidos de comercio electrónico disponible desde Kibana. Incluye un único índice llamado kibana_sample_data_ecommerce que contiene información sobre 4675 pedidos de un sitio web de comercio electrónico. Para cada pedido, tenemos la siguiente información:

• Información del cliente (nombre, identificación, fecha de nacimiento, correo electrónico, etc.)

• Fecha del pedido

• ID de pedido

• Productos (lista de todos los productos con precio, cantidad, identificación, categoría, descuento, etc.)

• SKU

• Precio total (sin impuestos, con impuestos)

• Cantidad total

• Información geográfica (ciudad, país, continente, ubicación, región)

Para instalar los datos de muestra, abre la página Integraciones en Kibana (busca “Integración” en la barra superior de búsqueda) e instala los “Datos de muestra”. Para obtener más detalles, consulta la documentación aquí: https://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibana.

El objetivo de este artículo es mostrar lo fácil que es configurar Google MCP Toolbox para conectarse a Elasticsearch e interactuar con el índice de kibana_sample_data_ecommerce usando lenguaje natural.

Google MCP Toolbox

Google MCP Toolbox es un servidor MCP open source diseñado para facilitar la interacción segura y eficiente de aplicaciones y agentes de IA con bases de datos. El proyecto, anteriormente conocido como el “GenAI Toolbox for Databases”, cambió su denominación después de adoptar la compatibilidad total con el Protocolo de contexto de modelo (MCP). Su propósito es eliminar el trabajo pesado que tradicionalmente se requiere al conectar agentes con bases de datos, gestionando la agrupación de conexiones, autenticación, observabilidad y otras preocupaciones operativas en segundo plano.

Esencialmente, Toolbox permite a los desarrolladores definir herramientas reutilizables de alto nivel que encapsulan las interacciones con la base de datos. Estas herramientas pueden ser invocadas por cualquier cliente compatible con MCP (como un agente de IA) sin requerir que el cliente implemente consultas SQL de bajo nivel o administre conexiones de base de datos. Este enfoque reduce drásticamente la cantidad de código repetitivo necesario para crear agentes compatibles con bases de datos, lo que permite integrar operaciones de datos avanzadas en solo unas pocas líneas de lógica de aplicación. Una vez definida una herramienta, se puede compartir entre varios agentes, marcos de trabajo o lenguajes (Figura 1).

Una de las ventajas principales de usar la Toolbox es el modelo de seguridad integrado. Los flujos de autenticación como OAuth2 y OIDC son compatibles de forma nativa, lo que permite a los desarrolladores evitar manejar o almacenar credenciales confidenciales de bases de datos en agentes. La plataforma también ofrece características de observabilidad (como métricas y rastreo) a través de OpenTelemetry, que es esencial para la depuración, la supervisión y los despliegues de producción. En conjunto, MCP Toolbox sirve como una interfaz unificada, segura y extensible para interactuar con tus datos desde cualquier sistema compatible con MCP.

Cómo instalar MCP Toolbox

Puedes instalar el servidor MCP Toolbox en Linux usando el siguiente comando:

Si quieres instalarlo en macOS o Windows, puedes seguir las instrucciones detalladas aquí.

Configura la Toolbox para Elasticsearch

Para configurar el MCP Toolbox para Elasticsearch, necesitamos crear un archivo tools.yaml, de la siguiente manera:

Debes reemplazar el valor <insert-here-api-key> por una clave API válida de Elasticsearch. Si estás ejecutando Elasticsearch localmente usando start-local, puedes encontrar la clave de API en el archivo.env generado por start-local, bajo la variable ES_LOCAL_API_KEY . Si usas Elastic Cloud, puedes generar una clave API siguiendo el procedimiento descrito aquí.

Las herramientas anteriores contienen la siguiente consulta ES|QL para Elasticsearch:

Si no estás familiarizado con ES|QL, es un lenguaje de búsqueda desarrollado por Elastic, similar a SQL, que puedes usar para buscar en uno o más índices. Puedes leer más sobre ES|QL en la documentación oficial aquí.

La búsqueda anterior busca todos los pedidos almacenados en el índice kibana_sample_data_ecommerce que contienen el nombre del cliente especificado, usando el parámetro ?name (el signo de interrogación indica un parámetro).

El nombre del cliente se define en la configuración YAML anterior empleando el texto de tipo y la descripción "El nombre del cliente".

Esta herramienta se puede usar para responder preguntas sobre los pedidos de un cliente, por ejemplo: ¿Cuántos pedidos realizó el cliente Foo en octubre de 2025?

Las descripciones de las herramientas y sus parámetros son esenciales para extraer la información relevante de la solicitud en lenguaje natural del usuario. Esta extracción se realiza utilizando la capacidad de llamada de función de un modelo de lenguaje grande (LLM). En la práctica, un LLM puede determinar qué función (herramienta) debe ejecutar para obtener la información necesaria, junto con los parámetros apropiados para esa función.

Para más información sobre las llamadas a funciones, sugerimos leer el artículo de OpenAI sobre llamadas a funciones con Elasticsearch de Ashish Tiwari.

Ejecuta el servidor de Toolbox

Puedes ejecutar la MCP Toolbox usando el archivo tools.yaml anterior con el siguiente comando:

El parámetro –ui ejecuta una aplicación sitio web en http://127.0.0.1:5000/ui (Figura 2).

Puedes seleccionar la Herramientas > pedidos-clientes e insertar un nombre de cliente en el parámetro nombre (por ejemplo, Gwen Sanders) y haz clic en el botón Ejecutar herramienta. Deberías ver una respuesta JSON como se indica en la Figura 3.

La configuración se ha completado y MCP Toolbox puede ejecutar la herramienta de pedidos de clientes para comunicarse con Elasticsearch, ejecutando la consulta ES|QL.

Usar la herramienta MCP Toolbox con Gemini CLI

Podemos usar cualquier cliente del MCP para comunicarnos con MCP Toolbox for Database. Por ejemplo, podemos usar Gemini CLI, una herramienta de línea de comandos, para usar Gemini. Puedes instalar Gemini CLI siguiendo las instrucciones indicadas aquí.

Gemini CLI ofrece una extensión preconfigurada para MCP Toolbox, disponible en gemini-cli-extensions/mcp-toolbox. Puedes instalar esta extensión ejecutando el comando siguiente:

Tras la instalación, debes ir al directorio donde almacenaste el archivo de configuración tools.yaml para MCP Toolbox y ejecutar la CLI Gemini de la siguiente manera (este paso es necesario para que la CLI Gemini se configure automáticamente con MCP Toolbox):

Deberías ver un anuncio de salida como el que se muestra en la Figura 4.

Puedes comprobar si MCP Toolbox está conectada usando el siguiente comando:

Deberías ver el mcp_toolbox con las herramientas de customer-orders listadas (Figura 5).

Si el MCP Toolbox está conectado a la CLI de Gemini, ahora podemos intentar hacer algunas preguntas, como: “Dame los pedidos del cliente Gwen Sanders”. La CLI de Gemini solicitará entonces permiso para ejecutar la herramienta de pedidos de clientes desde el servidor mcp_toolbox (ver Figura 6).

Tras la confirmación, Gemini CLI ejecutará la solicitud a MCP Toolbox, obteniendo una respuesta JSON como resultado y utilizándola para dar formato a la respuesta (Figura 7).

La respuesta de Gemini CLI será un reporte que indica que Gwen Sanders hizo solo un pedido de 2 productos, por un precio total de 132 euros.

SDK de MCP Toolbox

Google MCP Toolbox también ofrece un SDK para acceder a todas las funcionalidades desde un programa escrito en Go, Python y Javascript.

Por ejemplo, el SDK de Python está disponible en Github en la siguiente página: https://github.com/googleapis/mcp-toolbox-sdk-python.

Es necesario crear un agente simple para conectarnos a MCP Toolbox. Debemos instalar los siguientes paquetes:

Además, crear un nuevo proyecto de agente usando los siguientes comandos:

Esto creará un nuevo directorio llamado my_agent con un archivo agent.py.

Actualiza my_agent/agent.py con el siguiente contenido para conectar con Toolbox:

Crea un archivo .env con tu clave de API de Google:

Finalmente, podemos ejecutar el agente y observar los resultados. Para ejecutar el agente, puedes ejecutar el siguiente comando:

O bien, puedes servirlo a través de una interfaz web:

En ambos casos, puedes interactuar con MCP Toolbox usando una interfaz de preguntas frecuentes. Por ejemplo, puedes hacer la pregunta anterior: Dame las órdenes de la cliente Gwen Sanders.

Para más información sobre los diferentes SDK, puedes consultar esta página de documentación.

Conclusión

En este artículo, hemos mostrado la integración de Elasticsearch con Google MCP Toolbox for Databases. Mediante un sencillo archivo de configuración YAML, podemos definir un conjunto de herramientas que traducen preguntas en lenguaje natural a consultas de Elasticsearch utilizando el lenguaje ES|QL.

Mostramos cómo interactuar con el set de datos kibana_sample_data_ecommerce, que contiene pedidos de un sitio web de comercio electrónico. Con este archivo de configuración, podemos simplemente ejecutar el servidor MCP Toolbox y conectarnos a él desde cualquier cliente MCP.

Por último, mostramos cómo utilizar la CLI de Gemini como cliente para conectarse a MCP Toolbox for Databases y consultar los datos de comercio electrónico almacenados en Elasticsearch. Ejecutamos una consulta en lenguaje natural para recuperar información sobre pedidos para un cliente específico identificado por su nombre.

A medida que el ecosistema MCP sigue creciendo, este patrón (definiciones ligeras de herramientas respaldadas por infraestructuras seguras y listas para producción) crea nuevas oportunidades para construir agentes cada vez más capaces y conscientes de los datos con un esfuerzo mínimo. Ya sea que experimentes localmente con los sets de datos de muestra de Elastic o integres capacidades de búsqueda en una aplicación más amplia, MCP Toolbox ofrece una base fiable y extensible para interactuar con tus datos de Elasticsearch usando lenguaje natural.

Para obtener más información sobre el desarrollo de aplicaciones de IA agentic, puedes leer el artículo Creación de flujos de trabajo de IA agentic con Elasticsearch de Anish Mathur y Dana Juratoni.

Para obtener más información sobre Google MCP Toolbox, puedes visitar https://googleapis.github.io/genai-toolbox/getting-started/introduction/.

¿Qué es LangGraph?

LangGraph es un marco de trabajo para construir agentes de IA y orquestarlos en un flujo de trabajo para crear aplicaciones asistidas por IA. LangGraph tiene una arquitectura de nodes donde podemos declarar funciones que representan tareas y asignarlas como nodes del flujo de trabajo. El resultado de la interacción de varios nodes será un grafo. LangGraph es parte del ecosistema más amplio LangChain, que proporciona herramientas para construir sistemas de IA modulares y componibles.

Para explicar mejor por qué LangGraph es útil, vamos a usarlo para resolver una situación problemática.

Visión general de la solución

En una firma de capital de riesgo, los inversores tienen acceso a una gran base de datos con muchas opciones de filtrado, pero cuando uno quiere combinar criterios, se vuelve difícil y lento. Esto puede hacer que algunas iniciativas relevantes no se encuentren para la inversión. Además, implica pasar muchas horas intentando identificar a los mejores candidatos, o incluso perder oportunidades.

Con LangGraph y Elasticsearch, podemos realizar búsquedas filtradas utilizando lenguaje natural, eliminando la necesidad de que los usuarios construyan manualmente solicitudes complejas con docenas de filtros. Para hacerlo más flexible, el flujo de trabajo decide automáticamente (basándose en la entrada del usuario) entre dos tipos de consulta:

• Consultas centradas en la inversión: estas se dirigen a aspectos financieros y de financiación de las startups, como rondas de financiación, valoración o ingresos. Ejemplo: “Encuentra startups con financiamiento Serie A o Serie B entre $8M y $25M e ingresos mensuales superiores a $500K”.

• Consultas centradas en el mercado: estas se concentran en verticales de la industria, mercados geográficos o modelos de negocio, ayudando a identificar oportunidades en sectores o regiones específicos. Ejemplo: “Encuentra startups de fintech y salud en San Francisco, Nueva York o Boston”.

Para mantener la solidez de las consultas, haremos que el LLM cree plantillas de búsqueda en lugar de consultas DSL completas. De esta manera, siempre obtienes la consulta que deseas, y el LLM solo tiene que completar los espacios en blanco y no cargar con la responsabilidad de construir la consulta que necesitas cada vez.

Lo que necesitas para comenzar

• Clave de API de Elasticsearch

• Clave de API de OpenAPI

• Node 18 o más reciente

Instrucciones paso a paso

En esta sección, mostramos cómo se verá la app. Para ello, emplearemos TypeScript, un superconjunto de JavaScript que agrega tipos estáticos para hacer el código más fiable, fácil de mantener y seguro, detectando errores pronto mientras se mantiene totalmente compatible con el JavaScript existente.

El flujo de los nodos será el siguiente:

La imagen de arriba es generada por LangGraph y representa el flujo de trabajo que define el orden de ejecución y la lógica condicional entre nodos:

• decideStrategy: utiliza un LLM para analizar la consulta del usuario y decidir entre dos estrategias de búsqueda especializadas, como centrada en la inversión u orientada al mercado.

• prepareInvestmentSearch: extrae valores de filtro de la consulta y construye una plantilla predefinida que destaca los parámetros financieros y de financiación.

• prepareMarketSearch: extrae también los valores del filtro, pero construye dinámicamente parámetros que enfatizan el mercado, la industria y el contexto geográfico.

• executeSearch: envía la consulta construida a Elasticsearch usando una plantilla de búsqueda y recupera los documentos de startups correspondientes.

• visualizarResultados: formatea los resultados finales en un resumen claro y legible que muestre atributos clave de la startup, como financiación, industria e ingresos.

Este flujo incluye una ramificación condicional, que funciona como una declaración “si” que determina si se debe usar la ruta de búsqueda de inversión o de mercado según la entrada del usuario. Esta lógica de decisión, impulsada por el LLM, hace que el flujo de trabajo sea adaptativo y consciente del contexto, un mecanismo que exploraremos con más detalle en las siguientes secciones.

Estado de LangGraph

Antes de ver cada node individualmente, necesitamos entender cómo se comunican y comparten datos. Para ello, LangGraph nos permite definir el estado del flujo de trabajo. Esto define el estado compartido que se pasará entre los nodes.

El estado actúa como un contenedor compartido que almacena datos intermedios a lo largo del flujo de trabajo: comienza con la consulta en lenguaje natural del usuario, luego guarda la estrategia de búsqueda seleccionada, los parámetros preparados para Elasticsearch, los resultados de búsqueda recuperados y, finalmente, la salida formateada.

Esta estructura permite que cada node lea y actualice el estado, asegurando un flujo coherente de información desde la entrada del usuario hasta la visualización final.

Configure la aplicación

Todo el código de esta sección se puede encontrar en el repositorio elasticsearch-labs.

Abra un terminal en la carpeta donde estará la app e inicialice una aplicación Node.js con el comando:

Ahora podemos instalar las dependencias necesarias para este proyecto:

• @elastic/elasticsearch: nos ayuda a gestionar las solicitudes de Elasticsearch, como la ingesta y la recuperación de datos.

• @langchain/langgraph: Dependencia de JS para proporcionar todas las herramientas de LangGraph.

• @langchain/openai: cliente de OpenAI LLM para LangChain.

• @langchain/core: proporciona los bloques fundamentales del núcleo para las apps de LangChain, incluidas las plantillas de prompts.

• dotenv: dependencia necesaria para usar variables de entorno en JavaScript.

• zod: dependencia para escribir datos.

@types/node tsx typescript nos permite escribir y ejecutar código TypeScript.

Ahora crea los siguientes archivos:

• elasticsearchSetup.ts: creará los mapping de índice, cargará el conjunto de datos desde un archivo JSON e ingerirá los datos en Elasticsearch.

• main.ts: incluirá la aplicación LangGraph.

• .env: archivo para almacenar las variables de entorno

En el archivo .env, agreguemos las siguientes variables de entorno:

La clave API de OpenAPI no se usará directamente en el código; en su lugar, se usará internamente por la biblioteca @langchain/openai.

Toda la lógica relacionada con la creación de mapping, la creación de plantillas de búsqueda y la ingesta de sets de datos se encuentra en el archivo elasticsearchSetup.ts. En los próximos pasos, nos centraremos en el archivo main.ts . Además, puedes consultar los sets de datos para entender mejor cómo se ven los datos en el dataset.json.

Aplicación LangGraph

En el archivo main.ts, vamos a importar algunas dependencias necesarias para consolidar la aplicación LangGraph. En este archivo, también debes incluir las funciones del node y la declaración de estado. La declaración del grafo se realizará en un método main en los siguientes pasos. El archivo elasticsearchSetup.ts contendrá ayudantes de Elasticsearch que vamos a usar dentro de los nodes en los próximos pasos.

Como se mencionó anteriormente, el cliente LLM se utilizará para generar los parámetros de la plantilla de búsqueda de Elasticsearch basados en la pregunta del usuario.

El método anterior genera la imagen del grafo en formato png y utiliza la API de Mermaid.INK en segundo plano. Esto es útil si deseas ver cómo interactúan los nodes de la app con una visualización estilizada.

Nodes LangGraph

Ahora veamos cada node en detalle:

node decideSearchStrategy

El decideSearchStrategy node analiza la entrada del usuario y determina si realizar una búsqueda centrada en la inversión o en el mercado. Utiliza un LLM con un esquema de salida estructurado (definido con Zod) para clasificar el tipo de consulta. Antes de tomar la decisión, recupera los filtros disponibles del índice mediante una agregación, lo que garantiza que el modelo cuente con información actualizada sobre sectores, ubicaciones y datos de financiación.

Para extraer los posibles valores de los filtros y enviarlos al LLM, usemos una consulta de agregación para obtenerlos directamente del índice de Elasticsearch. Esta lógica se encuentra en un método llamado getAvailableFilters:

Con la consulta de agregación anterior, tenemos los siguientes resultados:

Vea todos los resultados aquí.

Para ambas estrategias, utilizaremos la búsqueda híbrida para detectar tanto la parte estructurada de la pregunta (filtros) como las partes más subjetivas (semántica). A continuación se muestra un ejemplo de ambas consultas utilizando plantillas de búsqueda:

Vea las consultas detalladas en el archivo elasticsearchSetup.ts . En el siguiente node, se decidirá cuál de las dos consultas se empleará:

Nodes prepareInvestmentSearch y prepareMarketSearch

Ambos nodos emplean una función auxiliar compartida, extractFilterValues, que aprovecha el LLM para identificar los filtros relevantes mencionados en la entrada del usuario, como la industria, la ubicación, la etapa de financiación, el modelo de negocio, etc. Estamos utilizando este esquema para crear nuestra plantilla de búsqueda.

Según de la intención detectada, el flujo de trabajo selecciona una de dos rutas:

prepareInvestmentSearch: desarrolla parámetros de búsqueda orientados a la financiación, incluyendo la etapa de financiación, el importe de la inversión, el inversionista y la información de renovación. Puedes encontrar la plantilla completa de consulta en el archivo elasticsearchSetup.ts :

prepareMarketSearch: crea parámetros orientados al mercado centrados en industrias, geografías y modelos de negocio. Ver la consulta completa en el archivo elasticsearchSetup.ts:

Node executeSearch

Este node toma los parámetros de búsqueda generados del estado y los envía primero a Elasticsearch, usando la _render API para visualizar la consulta con fines de depuración, y luego envía una petición para recuperar los resultados.

node visualizarResultados

Finalmente, este nodo muestra los resultados de Elasticsearch.

Programáticamente, todo el grafo se ve así:

Como puede ver, tenemos una aplicación condicional donde la aplicación decide qué “ruta” o node ejecutar a continuación. Esta característica es útil cuando los flujos de trabajo necesitan lógica de ramificación, como elegir entre múltiples herramientas o incluir un paso con intervención de una persona.

Con las características básicas del núcleo de LangGraph entendidas, podemos configurar la aplicación donde se ejecutará el código:

Juntando todo en un flujo de trabajo main, aquí declaramos el grafo con todos los elementos bajo la variable flujo de trabajo:

La variable de consulta simula la entrada del usuario introducida en una barra de búsqueda hipotética:

De la frase en lenguaje natural “Encuentra startups con financiamiento de Serie A o Serie B entre $8M y $25M, e ingresos mensuales superiores a $500K” se extraerán todos los filtros.

Finalmente, invoca el método principal:

Resultados

Para la entrada enviada, la aplicación elige la ruta centrada en la inversión y, como resultado, podemos ver la consulta de Elasticsearch generada por el flujo de trabajo de LangGraph, que extrae los valores y los rangos de la entrada del usuario. También podemos ver la consulta enviada a Elasticsearch con los valores extraídos aplicados y, finalmente, los resultados formateados por el node visualizeResults con los resultados.

Ahora vamos a probar el node centrado en el mercado usando la consulta “Encuentre startups de fintech y salud en San Francisco, Nueva York o Boston”:

Aprendizajes

Durante el proceso de escritura aprendí:

• Debemos mostrar al LLM los valores exactos de los filtros; de lo contrario, dependemos de que el usuario escriba los valores exactos de las cosas. Para baja cardinalidad, este enfoque está bien, pero cuando la cardinalidad es alta, necesitamos algún mecanismo para filtrar los resultados.

• El uso de plantillas de búsqueda hace que los resultados sean mucho más consistentes que dejar que el LLM escriba la consulta de Elasticsearch, y también es más rápido.

• Los bordes condicionales son un mecanismo potente para crear aplicaciones con múltiples variantes y rutas de ramificación.

• La salida estructurada es extremadamente útil cuando se genera información con LLM porque impone respuestas predecibles y de tipo seguro. Esto mejora la confiabilidad y reduce las interpretaciones incorrectas de los prompts.

La combinación de búsqueda semántica y estructurada a través de la recuperación híbrida produce resultados mejores y más relevantes, equilibrando la precisión y la comprensión del contexto.

Conclusión

En este ejemplo, combinamos LangGraph.js con Elasticsearch para crear un flujo de trabajo dinámico capaz de interpretar consultas en lenguaje natural y decidir entre estrategias de búsqueda financieras u orientadas al mercado. Este enfoque reduce la complejidad de la creación de consultas manuales, al tiempo que mejora la flexibilidad y la precisión para los analistas de capital de riesgo.

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.

Introducción al RAG agente

La Generación Aumentada por Recuperación (RAG) se convirtió en una piedra angular en aplicaciones basadas en LLM, permitiendo a los modelos proporcionar respuestas óptimas al recuperar el contexto relevante basado en las consultas de los usuarios. Los sistemas RAG mejoran la precisión y el contexto de las respuestas de los LLM al aprovechar información externa de APIs o almacenes de datos, en lugar de limitar al conocimiento preentrenado de los LLM. Por otro lado, los agentes de IA operan de forma autónoma, tomando decisiones y tomando medidas para alcanzar sus objetivos designados.

El RAG agente es un marco que unifica las fortalezas tanto de la generación aumentada por recuperación como del razonamiento agentivo. Integra RAG en el proceso de toma de decisiones del agente, permitiendo al sistema elegir dinámicamente fuentes de datos, refinar consultas para una mejor recuperación de contexto, generar respuestas más precisas y aplicar un bucle de retroalimentación para mejorar continuamente la calidad de la salida.

Características clave del RAG agente

El marco RAG agente supone un avance importante respecto a los sistemas RAG tradicionales. En lugar de seguir un proceso de recuperación fijo, aprovecha agentes dinámicos capaces de planear, ejecutar y optimizar resultados en tiempo real.

Veamos algunas de las características clave que distinguen a las pipelines RAG agenticas:

• Toma de decisiones dinámica: El RAG agente emplea un mecanismo de razonamiento para entender la intención del usuario y enrutar cada consulta a la fuente de datos más relevante, produciendo respuestas precisas y conscientes del contexto.

• Análisis exhaustivo de consultas: Agentic RAG analiza en profundidad las consultas de los usuarios, incluyendo subpreguntas y su intención general. Evalúa la complejidad de las consultas y selecciona dinámicamente las fuentes de datos más relevantes para obtener información, cerciorando respuestas precisas y completas.

• Colaboración en varias etapas: Este marco permite la colaboración en varias etapas a través de una red de agentes especializados. Cada agente gestiona una parte específica de un objetivo mayor, trabajando de forma secuencial o simultánea para lograr un resultado coherente.

• Mecanismos de autoevaluación: La cadena agente RAG emplea la autorreflexión para evaluar documentos recuperados y respuestas generadas. Puede comprobar si la información recuperada responde completamente a la consulta y luego revisar la salida para comprobar su exactitud, completitud y consistencia fáctica.

• Integración con herramientas externas: Este flujo de trabajo puede interactuar con APIs externas, bases de datos y fuentes de información en tiempo real, incorporando información actualizada y adaptar dinámicamente a los datos en evolución.

Patrones de flujo de trabajo del RAG agente

Los patrones de flujo de trabajo definen cómo la IA agente estructura, gestiona y orquesta aplicaciones basadas en LLM de manera fiable y eficiente. Varios frameworks y plataformas, como LangChain, LangGraph, CrewAI y LlamaIndex, pueden emplear para implementar estos flujos de trabajo agentes.

1. Cadena de recuperación secuencial: Los flujos de trabajo secuenciales dividen tareas complejas en pasos simples y ordenados. Cada paso mejora la entrada para el siguiente, lo que conduce a mejores resultados. Por ejemplo, al crear un perfil de cliente, un agente puede extraer datos básicos de un CRM, otro obtener el historial de compras de una base de datos de transacciones y un agente final combinar esta información para generar un perfil completo de recomendaciones o reportes.

2. Cadena de recuperación de enrutamiento: En este patrón de flujo de trabajo, un agente router analiza la entrada y la dirige al proceso o fuente de datos más adecuada. Este enfoque es especialmente eficaz cuando existen múltiples fuentes de datos distintas con una superposición mínima. Por ejemplo, en un sistema de atención al cliente, el agente del router categoriza las solicitudes entrantes, como problemas técnicos, reembolsos o reclamaciones, y las encamina al departamento correspondiente para su gestión eficiente.

3. Cadena de recuperación paralela: En este patrón de flujo de trabajo, se ejecutan simultáneamente múltiples subtareas independientes y sus salidas se agregan posteriormente para generar una respuesta final. Este enfoque reduce significativamente el tiempo de procesamiento y aumenta la eficiencia del flujo de trabajo. Por ejemplo, en un flujo de trabajo paralelo de atención al cliente, un agente recupera solicitudes pasadas similares y otro consulta artículos relevantes de la base de conocimiento. Un agregador combina entonces estas salidas para generar una resolución completa.

4. Cadena de trabajadores Orchestrator: Este flujo de trabajo comparte similitudes con la paralelización debido a su utilización de subtareas independientes. Sin embargo, una distinción clave radica en la integración de un agente orquestador. Este agente es responsable de analizar las consultas de los usuarios, segmentarlas dinámicamente en subtareas durante la ejecución e identificar los procesos o herramientas adecuadas necesarias para formular una respuesta precisa.

Construyendo una pipeline RAG agentica desde cero

Para ilustrar los principios del RAG agente, diseñemos un flujo de trabajo usando LangChain y Elasticsearch. Este flujo de trabajo adopta una arquitectura basada en enrutamiento, donde varios agentes colaboran para analizar consultas, recuperar información relevante, evaluar resultados y generar respuestas coherentes. Podrías consultar este cuaderno Jupyter para seguir este ejemplo.

El flujo de trabajo comienza con el agente router, que analiza la consulta del usuario para seleccionar el método óptimo de recuperación, es decir, un enfoque vectorstore, websearcho composite . La vectorstore se encarga de la recuperación tradicional de documentos basada en RAG, la búsqueda sitio web obtiene la información más reciente que no está almacenada en la vectorstore, y el enfoque compuesto combina ambas cuando se necesita información de múltiples fuentes.

Si los documentos se consideran adecuados, el agente de resumen genera una respuesta clara y contextualmente adecuada. Sin embargo, si los documentos son insuficientes o irrelevantes, el agente de reescritura de la consulta reformula la consulta para mejorar la búsqueda. Esta consulta revisada resetear entonces el proceso de enrutamiento, permitiendo al sistema refinar su búsqueda y mejorar la salida final.

Prerrequisitos

Este flujo de trabajo se basa en los siguientes componentes clave para ejecutar el ejemplo de forma eficaz:

• Python 3.10

• Cuaderno Jupyter

• Azure OpenAI

• Elasticsearch

• LangChain

Antes de continuar, se te pedirá que configures el siguiente conjunto de variables de entorno requeridas para este ejemplo.

Fuentes de datos

Este flujo de trabajo se ilustra empleando un subconjunto del conjunto de datos de AG News. El conjunto de datos comprende artículos de noticias en diversas categorías, como Internacional, Deportes, Negocios y Ciencia/Tecnología.

El módulo ElasticsearchStore se emplea desde el langchain_elasticsearch como nuestro almacén vectorial. Para la recuperación, implementamos SparseVectorStrategy, empleando ELSER, el modelo propietario de incrustación de Elastic. Es esencial confirmar que el modelo ELSER está correctamente instalado y desplegado en tu entorno Elasticsearch antes de iniciar el almacén vectorial.

La funcionalidad de búsqueda sitio web se implementa usando DuckDuckGoSearchRun de las herramientas comunitarias LangChain, lo que permite al sistema recuperar información en tiempo real de la web de forma eficiente. También puedes considerar usar otras APIs de búsqueda que puedan ofrecer resultados más relevantes. Esta herramienta fue elegida porque permite búsquedas sin necesidad de clave API.

El retriever compuesto está diseñado para consultas que requieren una combinación de fuentes. Se emplea para proporcionar una respuesta completa y contextualmente precisa al recuperar datos en tiempo real de la web y consultar noticias históricas del almacén vectorial.

Preparando a los agentes

En el siguiente paso, los agentes LLM se definen para proporcionar capacidades de razonamiento y toma de decisiones dentro de este flujo de trabajo. Las cadenas de LLM que crearemos incluyen: router_chain, grade_docs_chain, rewrite_query_chainy summary_chain.

El agente router emplea un asistente LLM para determinar la fuente de datos más adecuada para una consulta determinada en tiempo de ejecución. El agente evaluador evalúa la relevancia de los documentos recuperados. Si los documentos se consideran relevantes, se entregan al agente de resumen para que genere un resumen. De lo contrario, el agente de consulta de reescritura reformula la consulta y la envía de vuelta al proceso de enrutamiento para otro intento de recuperación. Puedes encontrar las instrucciones de todos los agentes en la sección de cadenas de LLM del cuaderno.

La llm.with_structured_output limita la salida del modelo para seguir un esquema predefinido definido por el BaseModel bajo la clase RouteQuery , cerciorando la consistencia de los resultados. La segunda línea compone una RunnableSequence conectando router_prompt con router_structured, formando una tubería en la que el modelo de lenguaje procesa el prompt de entrada para producir resultados estructurados y compatibles con el esquema.

Definir nodos de grafo

Esta parte implica definir los estados del grafo, que representan los datos que fluyen entre los diferentes componentes del sistema. Una especificación clara de estos estados cerciora que cada nodo del flujo de trabajo sepa qué información puede acceder y actualizar.

Una vez definidos los estados, el siguiente paso es definir los nodos del grafo. Los nodos son como las unidades funcionales del grafo que realizan operaciones específicas sobre los datos. Hay 7 nodos diferentes en nuestra pipeline.

El nodo query_rewriter cumple dos funciones en el flujo de trabajo. Primero, reescribe la consulta del usuario usando el rewrite_query_chain para mejorar la recuperación cuando los documentos evaluados por el agente autorreflexivo se consideran insuficientes o irrelevantes. Segundo, actúa como un contador que registra cuántas veces se reescribió la consulta.

Cada vez que se invoca el nodo, incrementa la retry_count almacenada en el estado del flujo de trabajo. Este mecanismo impide que el flujo de trabajo entre en un bucle infinito. Si el retry_count supera un umbral predefinido, el sistema puede recurrir a un estado de error, una respuesta por defecto o cualquier otra condición predefinida que elijas.

Compilación del grafo

El último paso es definir las aristas del grafo y agregar las condiciones necesarias antes de compilarlo. Cada grafo debe comenzar desde un nodo inicial designado, que sirve como punto de entrada para el flujo de trabajo. Las aristas en el gráfico representan el flujo de datos entre nodos y pueden ser de dos tipos:

• Aristas rectas: Estas definen un flujo directo e incondicional de un nodo a otro. Cada vez que el primer nodo completa su tarea, el flujo de trabajo avanza automáticamente al siguiente nodo a lo largo de la arista recta.

• Aristas condicionales: Estas permiten que el flujo de trabajo se ramifice según el estado actual o los resultados del cálculo de un nodo. El siguiente nodo se selecciona dinámicamente en función de condiciones como resultados de evaluación, decisiones de enrutamiento o recuentos de intentos.

Con eso, tu primera pipeline de RAG agente está lista y puede probar usando el agente compilado.

Prueba de la tubería agente RAG

Ahora probaremos esta canalización usando tres tipos distintos de consultas como se indica a continuación. Ten en cuenta que los resultados pueden variar, y los ejemplos que se muestran a continuación ilustran solo un posible resultado.

Para la primera consulta, el router selecciona websearch como fuente de datos. La consulta no supera la evaluación de autorreflexión y posteriormente se redirige a la etapa de reescritura de la consulta, como se muestra en el resultado.

A continuación, examinamos un ejemplo en el que se emplea vectorstore recuperación, demostrado con la segunda consulta.

La consulta final se dirige a la recuperación compuesta, que emplea tanto la vectorstore como la búsqueda sitio web.

En el flujo de trabajo anterior, el RAG agente determina de forma inteligente qué fuente de datos emplear al recuperar información para una consulta de usuario, mejorando así la precisión y relevancia de la respuesta. Puedes crear ejemplos adicionales para probar al agente y revisar los resultados para ver si dan resultados interesantes.

Mejores prácticas para construir flujos de trabajo agenticos RAG

Ahora que entendemos cómo funciona el RAG agente, veamos algunas buenas prácticas para construir estos flujos de trabajo. Seguir estas directrices ayudará a mantener el sistema eficiente y fácil de mantener.

• Prepárate para los recursos de respaldo: Planea estrategias de respaldo con antelación para escenarios en los que algún paso del flujo de trabajo falle. Estos pueden incluir devolver respuestas por defecto, activar estados de error o emplear herramientas alternativas. Esto garantiza que el sistema gestione los fallos con elegancia sin romper el flujo de trabajo global.

• Implementa registros completos: Prueba a implementar registros en cada etapa del flujo de trabajo, como intentos, salidas generadas, elecciones de enrutamiento y reescrituras de consultas. Estos registros ayudan a mejorar la transparencia, facilitan la depuración y ayudan a refinar los prompts, el comportamiento de los agentes y las estrategias de recuperación con el tiempo.

• Selecciona el patrón de flujo de trabajo adecuado: Examina tu caso de uso y selecciona el patrón que mejor se adapte a tus necesidades. Emplea flujos de trabajo secuenciales para razonamiento paso a paso, flujos de trabajo paralelos para fuentes de datos independientes y patrones orquestador-trabajador para consultas multiherramienta o complejas.

• Incorpora estrategias de evaluación: Integra mecanismos de evaluación en diferentes etapas del flujo de trabajo. Estos pueden incluir agentes de autorreflexión, calificación de documentos recuperados o controles automáticos de calidad. La evaluación ayuda a verificar que los documentos recuperados son relevantes, que las respuestas son precisas y que todas las partes de una consulta compleja están abordadas.

Desafíos

Aunque los sistemas RAG agenticos ofrecen beneficios significativos en términos de adaptabilidad, precisión y razonamiento dinámico, también presentan ciertos desafíos que deben abordar durante sus etapas de diseño e implementación. Algunos de los principales retos incluyen:

• Flujos de trabajo complejos: A medida que se agregan más agentes y puntos de decisión, el flujo de trabajo global se vuelve cada vez más complejo. Esto puede llevar a mayores probabilidades de errores o fallos en tiempo de ejecución. Siempre que sea posible, prioriza flujos de trabajo optimizados eliminando agentes redundantes y puntos de decisión innecesarios.

• Escalabilidad: Puede ser complicado escalar sistemas RAG agentes para manejar grandes conjuntos de datos y grandes volúmenes de consultas. Incorpora estrategias eficientes de indexación, caché y procesamiento distribuido para mantener el rendimiento a gran escala.

• Orquestación y sobrecarga computacional: La ejecución de flujos de trabajo con múltiples agentes requiere orquestación avanzada. Esto incluye una planeación cuidadosa, gestión de dependencias y coordinación de agentes para evitar cuellos de botella y conflictos, todo lo cual contribuye a la complejidad general del sistema.

• Complejidad de la evaluación: La evaluación de estos flujos de trabajo presenta desafíos inherentes, ya que cada etapa requiere una estrategia de evaluación distinta. Por ejemplo, la etapa RAG debe evaluar para verificar la relevancia y completitud de los documentos recuperados, mientras que los resúmenes generados deben verificar para garantizar su calidad y precisión. Del mismo modo, la efectividad de la reformulación de consultas requiere una lógica de evaluación separada para determinar si la consulta reescrita mejora los resultados de recuperación.

Conclusión

En esta entrada de blog, presentamos el concepto de RAG agente y destacamos cómo mejora el marco tradicional de RAG al incorporar capacidades autónomas de la IA agente. Exploramos las características principales de RAG agente y demostramos estas características mediante un ejemplo práctico, construyendo un asistente de noticias usando Elasticsearch como almacén vectorial y LangChain para crear el marco agente.

Además, discutimos las mejores prácticas y los principales retos a considerar al diseñar e implementar una pipeline agentica RAG. Estos conocimientos están destinados a guiar a los desarrolladores en la creación de sistemas agentivos robustos, escalables y eficientes que combinen eficazmente la recuperación, el razonamiento y la toma de decisiones.

¿Qué sigue ahora?

El flujo de trabajo que creamos es sencillo, dejando amplio margen para mejoras y experimentación. Podemos mejorar esto experimentando con varios modelos de incrustación y refinando estrategias de recuperación. Además, integrar a un agente de reclasificación para priorizar los documentos recuperados podría ser beneficioso. Otra área de exploración implica desarrollar estrategias de evaluación para marcos agentivos, identificando específicamente enfoques comunes y reutilizables aplicables a diferentes tipos de marcos. Por último, experimentar con estos marcos en conjuntos de datos grandes y más complejos.

Mientras tanto, si tienes experimentos similares que compartir, ¡nos encantaría saberlos! No dudes en dar tus opiniones o conectar con nosotros a través de nuestro canal comunitario de Slack o foros de discusión.

Recursos

• Auto-RAG: Aprender a recuperar, generar y criticar a través de la autorreflexión

• Generación aumentada por recuperación agentica: una encuesta sobre el RAG agente

Este artículo te mostrará cómo construir un agente de IA para RRHH usando GPT-OSS y Elastic Agent Builder. El agente puede responder a tus preguntas sin enviar datos a OpenAI, Anthropic ni ningún servicio externo.

Usaremos LM Studio para servir GPT-OSS localmente y lo conectaremos a Elastic Agent Builder.

Al final de este artículo, tendrás un agente de IA personalizado que podrá responder preguntas en lenguaje natural sobre los datos de tus empleados manteniendo el control total sobre tu información y modelo.

Prerrequisitos

Para este artículo, necesitas:

• Elastic Cloud alojaba la versión 9.2, despliegue serverless o local

• Máquina con 32GB de RAM recomendada (mínimo 16GB para GPT-OSS 20B)

• LM Studio instalado

• Escritorio Docker Instalado

¿Por qué usar GPT-OSS?

Con un LLM local tienes el control para desplegarlo en tu propia infraestructura y ajustarlo para adaptarlo a tus propias necesidades. Todo esto manteniendo el control sobre los datos que compartes con el modelo y, por supuesto, no tienes que pagar una tasa de licencia a un proveedor externo.

OpenAI lanzó GPT-OSS el 5 de agosto de 2025, como parte de su compromiso con el ecosistema del modelo abierto.

El modelo de parámetros 20B ofrece:

• Capacidades de uso de herramientas

• Inferencia eficiente

• Compatible con SDK OpenAI

• Compatible con flujos de trabajo agentes

Comparación de referencias:

Arquitectura de soluciones

La arquitectura funciona completamente en tu máquina local. Elastic (que funciona en Docker) se comunica directamente con tu LLM local a través de LM Studio, y Elastic Agent Builder emplea esta conexión para crear agentes de IA personalizados que pueden consultar los datos de tus empleados.

Para más detalles, consulte esta documentación.

Construir un agente de IA para RRHH: Pasos

Dividiremos la implementación en 5 pasos:

1. Configurar LM Studio con un modelo local

2. Despliega Elastic Local con Docker

3. Crea el conector OpenAI en Elastic

4. Sube los datos de los empleados a Elasticsearch

5. Construye y prueba tu agente de IA

Paso 1: Configurar LM Studio con GPT-OSS 20B

LM Studio es una aplicación fácil de usar que te permite ejecutar grandes modelos de lenguaje localmente en tu computadora. Proporciona un servidor API compatible con OpenAI, lo que facilita su integración con herramientas como Elastic sin un proceso de configuración complejo. Para más detalles, consulta la documentación de LM Studio.

Primero, descarga e instala LM Studio desde el sitio web oficial. Una vez instalado, abre la aplicación.

En la interfaz de LM Studio:

1. Ve a la pestaña de búsqueda y busca "GPT-OSS"

2. Selecciona el openai/gpt-oss-20b de OpenAI

3. Haz clic en descargar

El tamaño de este modelo debería ser aproximadamente 12,10GB. La descarga puede tardar unos minutos, dependiendo de tu conexión a Internet.

Una vez descargado el modelo:

1. Ve a la pestaña del servidor local

2. Selecciona el openai/gpt-oss-20b

3. Usa el puerto predeterminado 1234

4. En el panel derecho, ve a Cargar y establece la longitud de contexto en 40K o más

5. Haz clic en iniciar servidor

Deberías ver esto si el servidor está funcionando.

Paso 2: Desplegar Elastic Local con Docker

Ahora configuraremos Elasticsearch y Kibana localmente usando Docker. Elastic proporciona un script conveniente que gestiona todo el proceso de configuración. Para más detalles, consulte la documentación oficial.

Ejecuta el script de inicio local

Ejecuta el siguiente comando en tu terminal:

Este guion será:

• Descargar y configurar Elasticsearch y Kibana

• Inicia ambos servicios usando Docker Compose

• Activa automáticamente una licencia de prueba Platinum de 30 días

Producción esperada

Solo espera el siguiente mensaje y almacena la contraseña y la clave API que se muestra; los necesitarás para acceder a Kibana:

Acceso a Kibana

Abre tu navegador y navega a:

Inicia sesión usando las credenciales obtenidas en la salida del terminal.

Habilitar Agent Builder

Una vez iniciado sesión en Kibana, navega a Management > AI > Agent Builder y activa el Agent Builder.

Paso 3: Crea el conector OpenAI en Elastic

Ahora configuraremos Elastic para que use tu LLM local.

Conectores de acceso

1. En Kibana

2. Ve a Configuración > Gestión del Proyecto

3. En Alertas e Información, selecciona Conectores

4. Haz clic en Crear conector

Configurar el conector

Selecciona OpenAI de la lista de conectores. LM Studio emplea el SDK OpenAI, lo que lo hace compatible.

Diligencia el espacio con estos valores:

• Nombre del conector: LM Studio - GPT-OSS 20B

• Selecciona un proveedor de OpenAI: Otros (Servicio compatible con OpenAI)

• URL: http://host.docker.internal:1234/v1/chat/completions

• Modelo por defecto: openai/gpt-oss-20b

• API Key: testkey-123 (cualquier texto funciona, porque LM Studio Server no requiere autenticación.)

Para terminar la configuración, haz clic en Almacenar y probar.

Importante: Activa la opción "Habilitar la llamada a funciones nativas"; esto es necesario para que el Constructor de Agentes funcione correctamente. Si no activas esto, te aparecerá un error de No tool calls found in the response .

Prueba la conexión

El elástico debería probar automáticamente la conexión. Si todo está configurado correctamente, verás un mensaje de éxito como este:

Respuesta:

Paso 4: Subir los datos de los empleados a Elasticsearch

Ahora subiremos el conjunto de datos de empleados de RRHH para demostrar cómo el agente trabaja con datos sensibles. Generé un conjunto de datos ficticio con esta estructura.

Estructura del conjunto de datos

Crea el índice con mapeos

Primero, crea el índice con mapeos adecuados. Ten en cuenta que estamos usando semantic_text campos para algunos campos clave; Esto permite capacidades de búsqueda semántica para nuestro índice.

Índice con API Bulk

Copia y pega el conjunto de datos en tus Dev Tools en Kibana y ejecutalo:

Verifica los datos

Realiza una consulta para verificar:

Paso 5: Construye y prueba tu agente de IA

Con todo configurado, es hora de crear un agente de IA personalizado usando Elastic Agent Builder. Para más detalles, consulte la documentación de Elastic.

Agregar el conector

Antes de poder crear nuestro nuevo agente, tenemos que configurar nuestro constructor de agentes para usar nuestro conector personalizado llamado LM Studio - GPT-OSS 20B porque el predeterminado es el Elastic Managed LLM. Para eso, necesitamos ir a Configuración > Gestión de Proyectos > Configuración de GenAI; ahora seleccionamos la que creamos y hacemos clic en Almacenar.

Constructor de Agentes de Acceso

1. Ir a Agentes

2. Haz clic en Crear un nuevo agente

Configurar el agente

Para crear un nuevo agente, los campos requeridos son el ID del agente, el nombre de visualización y las instrucciones de visualización.

Pero hay más opciones de personalización, como las Instrucciones Personalizadas que guían cómo se comportará tu agente e interactuará con tus herramientas, similar a una indicación del sistema, pero para nuestro agente personalizado. Las etiquetas ayudan a organizar tus agentes, el color del avatar y el símbolo del avatar.

Los que elegí para nuestro agente basándome en el conjunto de datos son: ID del agente: hr_assistant

Instrucciones personalizadas:

Etiquetas: Human Resources y GPT-OSS

Nombre de visualización: HR Analytics Assistant

Descripción de la exposición:

Con todos los datos ahí, podemos hacer clic en Almacenar a nuestro nuevo agente.

Prueba al agente

Ahora puedes hacer preguntas en lenguaje natural sobre los datos de tus empleados, y GPT-OSS 20B entenderá la intención y generará una respuesta adecuada.

Pronto:

Respuesta:

El proceso de Agente fue:

1. Entiende tu pregunta usando el conector GPT-OSS

2. Generar la consulta Elasticsearch adecuada (usando las herramientas integradas o ES| personalizadoQL)

3. Recuperar los registros de empleados coincidentes

4. Presentar resultados en lenguaje natural con un formato adecuado

A diferencia de la búsqueda léxica tradicional, el agente impulsado por GPT-OSS entiende la intención y el contexto, facilitando encontrar información sin conocer los nombres exactos de los campos o la sintaxis de la consulta. Para más detalles sobre el proceso de pensamiento del agente, consulta este artículo.

Conclusión

En este artículo, creamos un agente de IA personalizado usando el Agent Builder de Elastic para conectarse al modelo OpenAI GPT-OSS que se ejecuta localmente. Al desplegar tanto Elastic como el LLM en tu máquina local, esta arquitectura te permite aprovechar las capacidades de IA generativa manteniendo el control total sobre tus datos, todo ello sin enviar información a servicios externos.

Usamos GPT-OSS 20B como experimento, pero aquí se hacen referencia a los modelos oficialmente recomendados para Elastic Agent Builder. Si necesitas capacidades de razonamiento más avanzadas, también está la variante de parámetros 120B que rinde mejor para escenarios complejos, aunque requiere una máquina de especificaciones más altas para ejecutar localmente. Para más detalles, consulte la documentación oficial de OpenAI.

Más allá de los impresionantes proyectos, la experiencia en Cal Hacks 12.0 también nos dio algo igualmente valioso: comentarios rápidos y sin filtros de desarrolladores que se encuentran con nuestra Stack por primera vez. Los hackathons son pruebas de presión únicas con plazos ajustados, cero familiaridad previa y obstáculos impredecibles (como los famosos cortes de WiFi). Exponen exactamente dónde brilla la experiencia del desarrollador y dónde aún necesita mejoras. Esto importa aún más ahora, ya que los desarrolladores interactúan con el Elastic Stack de nuevas maneras, cada vez más a través de flujos de trabajo impulsados por LLM. En esta entrada del blog, profundizaremos en lo que los participantes construyeron con Agent Builder y lo que aprendimos en el proceso.

Los proyectos ganadores

Primer puesto: AgentOverflow

Stack Overflow reconstruido para la era de los LLM y los agentes.

Lee más sobre AgentOverflow aquí.

AgentOverflow aborda un problema que la mayoría de los desarrolladores de IA enfrentan: los LLMs alucinan, los historiales de chat desaparecen y los desarrolladores pierden tiempo resolviendo los mismos problemas.

AgentOverflow captura, valida y reactiva pares reales problema-solución, para que los desarrolladores puedan romper la espiral de alucinaciones y enviar más rápido.

Cómo funciona:

1. Compartir JSON - el "Esquema de Solución".

Un clic desde un recurso compartido de Claude extraerá, extrae y ensamblará un JSON de Solución de Compartir, que es un formato estructurado que contiene:

• Problema

• Contexto

• Código

• Etiquetas

• Pasos verificados de la solución.

Un validador (LAVA) comprueba y aplica la estructura, el usuario agrega una línea de contexto extra y luego se almacena e indexa dentro de Elasticsearch.

2. Encontrar solución

Cuando te quedes atascado, haz clic en Find Solution y AgentOverflow extraerá tu conversación actual, la usará para crear una consulta y ejecutará una búsqueda híbrida en Elasticsearch para que aparezca:

• Arreglos clasificados y validados por la comunidad

• Los exactos prompts que originalmente resolvieron el problema

Esto permite a los desarrolladores copiar, pegar y desbloquear rápidamente su sesión actual.

3. MCP - inyección de contexto para LLMs

Al conectarse a las soluciones estructuradas almacenadas dentro de Elasticsearch a través de MCP (Model Context Protocol), los LLM reciben un contexto de alta señal (código, registros, configuraciones, correcciones previas) en tiempo de ejecución sin ruido adicional.

AgentOverflow emplea Agent Builder con Elasticsearch como una capa de memoria estructurada que inyecta el contexto relevante en los LLMs. Esto los transforma de chatbots pasivos en solucionadores de problemas conscientes del contexto.

Segundo puesto: MarketMind

Una visión interpretable en tiempo real de la energía del mercado, impulsada por seis Agentes Elásticos.

Lee más sobre MarketMind aquí.

MarketMind consiguió su spot al ofrecer a los traders novatos una plataforma que convierte datos de mercado fragmentados en señales claras y en tiempo real. En lugar de compaginar la acción del precio, los fundamentos, el sentimiento y la volatilidad entre diferentes herramientas, MarketMind consolida toda esta información en una sola plataforma, ayudando a los traders a obtener información útil. Este proyecto también empleó algunos complejos ES|QL consulta al construir sus agentes.

Cómo funciona:

1. Recopilar datos de mercado en tiempo real

MarketMind extrae métricas de precio-acción, fundamentos, sentimiento, volatilidad y riesgo de Yahoo Finance. Estos datos se ingieren y organizan en múltiples índices de Elasticsearch.

2. Seis agentes especializados analizan el mercado

Cada agente, construido con Agent Builder, se centra en una capa diferente del mercado. Leen desde un índice de Elasticsearch, calculan sus propias métricas específicas de dominio y generan una salida JSON estandarizada con puntajes y razonamientos.

3. Agregar señales en un modelo unificado de "energía de mercado"

Las salidas combinadas aparecen como pulsos brillantes alrededor de cada acción, ilustrando si el impulso está creciendo, el riesgo está aumentando o el sentimiento está cambiando.

4. Visualizar percepciones

El frontend se construyó con React y Next.js, usando TypeScript, gráficos basados en física SVG y Chart.js para gráficos en tiempo real con candelabros. Esto convierte el análisis en bruto en feedback accionable en tiempo real.

Otros proyectos interesantes:

Aquí tienes otros candidatos fuertes que usaron Elastic en diferentes partes de su stack:

Encuentra aquí la lista completa de proyectos que se presentaron a nuestra especialidad.

Lo que aprendimos de los desarrolladores

• Agent Builder es fácil de usar:

La mayoría de los equipos nunca usaron Elastic antes y aún así podían crear agentes rápidamente con poco apoyo. Organizamos un taller para quienes necesitaban más orientación, pero la mayoría pudo absorber sus datos y crear un agente para realizar acciones sobre esos datos.

• Los LLMs son excelentes en kNN consultas, pero aún necesitan orientación para generar ES|QL:

Pidiendo a ChatGPT-5 que genere ES|Las consultas QL devolvían información incorrecta, a menudo mezclando ES|QL y SQL. Alimentar al LLM la documentación en un archivo de markdown parecía una solución viable.

• ES| solo para instantáneasFunciones QL filtradas en documentos:

Las próximas funciones de agregación FIRST y LAST pasaron sin querer a nuestro ES|Documentos de QL. Como enviamos esa documentación a ChatGPT, el modelo empleó fielmente estas funciones, aunque aún no estén disponibles en Serverless. Gracias a los comentarios del grupo, ingeniería abrió y fusionó rápidamente una corrección para eliminar las funciones de la documentación publicada (PR #137341).

• Falta orientación específica para Serverless:

Un equipo intentó activar LOOKUP JOIN en un índice que no se creó en modo búsqueda. El mensaje de error les hizo perseguir comandos que no existen en Serverless. Transmitimos esto al equipo de producto, que inmediatamente abrió una corrección para un mensaje específico y accionable para Serverless. A largo plazo, la visión es ocultar por completo la complejidad del reindexado (Número #4838).

• Valor de los eventos presenciales:

Los hackathons online son geniales, pero nada iguala el bucle de retroalimentación rápida que tienes cuando depuras codo a codo con los constructores. Vimos cómo los equipos integraban Agent Builder en diferentes casos de uso, y detectamos la experiencia de los desarrolladores con ES|QL podría mejorar y solucionar los problemas mucho más rápido que intentar hacerlo por canales asincrónicos.

Conclusión

Cal Hacks 12.0 nos ofreció más que un fin de semana de demos chulas; también nos dio una visión de cómo los nuevos desarrolladores interactúan con el Elastic Stack. En tan solo 36 horas, vimos a los equipos adquirir Agent Builder, incorporar datos en Elasticsearch, diseñar sistemas multiagente y probar nuestras funcionalidades de diversas maneras. El evento también nos recordó por qué son importantes los eventos presenciales. Los rápidos bucles de retroalimentación, las conversaciones reales y la depuración práctica nos ayudaron a entender las necesidades actuales de los desarrolladores. Estamos entusiasmados por devolver lo aprendido al equipo de ingeniería. Nos vemos en el próximo hackathon.

Este es el artículo complementario al artículo "¡Creando una redacción para agentes LLM con protocolo A2A y MCP en Elasticsearch!", que explicaba los beneficios de implementar tanto las arquitecturas A2A como MCP dentro del mismo agente para aprovechar realmente los beneficios únicos de ambos frameworks. Hay un repositorio disponible si deseas ejecutar la demo por tu cuenta.

Vamos a repasar cómo colaboran nuestros agentes de redacción empleando tanto A2A como MCP para producir un artículo de noticias. El repositorio adjunto para ver a los agentes en acción se puede encontrar aquí.

Paso 1: Asignación de la historia

El Jefe de Noticias (actuando como cliente) asigna una noticia:

Paso 2: El reportero aplicar investigación

El Agente Reportero reconoce que necesita información de fondo y delega al Agente Investigador mediante A2A:

Paso 3: El reportero aplicar contexto histórico al Agente de Archivo

El Reporter Agent reconoce que el contexto histórico fortalecería la historia. Delega al Agente de Archivo (impulsado por el Agente A2A de Elastic) a través de A2A para buscar en el archivo de artículos impulsado por Elasticsearch de la redacción:

Paso 4: El Agente de Archivo emplea el Agente Elastic A2A con MCP

El Archive Agent emplea el A2A Agent de Elastic, que a su vez emplea MCP para acceder a las herramientas de Elasticsearch. Esto demuestra la arquitectura híbrida donde A2A permite la colaboración entre agentes mientras que MCP proporciona acceso a herramientas:

El Agente de Archivo recibe datos históricos completos del Agente A2A de Elastic y los devuelve al Reportero:

Este paso demuestra cómo el Agente A2A de Elastic se integra en el flujo de trabajo de la redacción. El Agente de Archivo (un agente específico de redacción) coordina con el Agente A2A de Elastic (un especialista externo) para aprovechar las poderosas capacidades de búsqueda y análisis de Elasticsearch. El agente de Elastic emplea MCP internamente para acceder a las herramientas de Elasticsearch, mostrando la separación limpia entre la coordinación del agente (A2A) y el acceso a la herramienta (MCP).

Paso 5: El investigador emplea servidores MCP

El Agente Investigador accede a múltiples servidores MCP para recopilar información:

Paso 6: El investigador devuelve los datos al Reportero

El Agente Investigador envía una investigación exhaustiva de vuelta a través de A2A:

Paso 7: Reportero escribe artículo

El Reporter Agent emplea los datos de investigación y sus propias capacidades de LLM para redactar el artículo. Durante la redacción, el Reportero emplea los servidores MCP para el estilo y las plantillas:

Paso 8: la baja confianza desencadena la re-investigación

El Agente Reportero evalúa su borrador y encuentra que una afirmación tiene baja confianza. Envía otra solicitud al Agente Investigador:

El investigador verifica la afirmación empleando servidores MCP de verificación de hechos y devuelve información actualizada:

Paso 9: El reportero revisa y envía al editor

El Reportero incorpora los hechos verificados y envía el borrador completo al Agente Editor a través de A2A:

Paso 10: Revisiones del editor usando herramientas MCP

El Editor Agent emplea múltiples servidores MCP para revisar el artículo:

El editor aprueba el artículo y lo envía hacia adelante:

Paso 11: El editor publica vía CI/CD

Finalmente, el Agente de Impresora publica el artículo aprobado empleando los servidores MCP para la tubería CMS y CI/CD:

El editor confirma la publicación a través de A2A:

Aquí está la secuencia completa del flujo de trabajo A2A en el repositorio adjunto usando los mismos Agentes descritos anteriormente.

#

De

Para

Acción

Protocolo

Descripción

1

Usuario

Jefe de Noticias

Asignar historia

HTTP POST

El usuario presenta la historia, tema y ángulo

2

Jefe de Noticias

Interno

Crear historia

-

Crea un registro de historia con un ID único

3

Jefe de Noticias

Reportero

Asignación de Delegados

A2A

Envía asignación de historia mediante el protocolo A2A

4

Reportero

Interno

Aceptar Asignación

-

Asignación interna de almacenes

5

Reportero

Servidor MCP

Generar esquema

MCP/HTTP

Crea un esquema de artículos y preguntas de investigación

6A

Reportero

Investigador

Solicitud de investigación

A2A

Envía preguntas (paralelo con 6b)

6b

Reportero

Archivero

Archivo de búsqueda

A2A JSONRPC

Busca en artículos históricos (paralelo con 6a)

7

Investigador

Servidor MCP

Preguntas de investigación

MCP/HTTP

Emplea Anthropic vía MCP para responder preguntas

8

Investigador

Reportero

Investigación de Retorno

A2A

Respuestas de investigación de retornos

9

Archivero

Elasticsearch

Índice de búsqueda

ES REST API

Consultas news_archive índice

10

Archivero

Reportero

Archivo de retorno

A2A JSONRPC

Devuelve resultados históricos de búsqueda

11

Reportero

Servidor MCP

Generar artículo

MCP/HTTP

Crea un artículo con contexto de investigación/archivo

12

Reportero

Interno

Tiro de la tienda

-

Salvamentos en el draft interno

13

Reportero

Jefe de Noticias

Enviar Borrador

A2A

Entrega borrador completado

14

Jefe de Noticias

Interno

Actualización de la historia

-

Borrador de la tienda, actualiza el estado a "draft_submitted"

15

Jefe de Noticias

Editor

Borrador de revisión

A2A

Rutas automáticas al Editor para su revisión

16

Editor

Servidor MCP

Artículo de revisión

MCP/HTTP

Analiza contenido usando Anthropic a través de MCP

17

Editor

Jefe de Noticias

Reseña de Retorno

A2A

Envía comentarios y sugerencias editoriales

18

Jefe de Noticias

Interno

Reseña de la tienda

-

Comentarios sobre el editor de tiendas

19

Jefe de Noticias

Reportero

Aplicar ediciones

A2A

Comentarios de la revisión de rutas al Reportero

20

Reportero

Servidor MCP

Aplicar ediciones

MCP/HTTP

Revisa el artículo basar en los comentarios

21

Reportero

Interno

Actualización del borrador

-

Borrador de actualizaciones con revisiones

22

Reportero

Jefe de Noticias

Devolución revisada

A2A

Artículo revisado de declaraciones

23

Jefe de Noticias

Interno

Actualización de la historia

-

Borrador revisado de las tiendas, estado a "revisado"

24

Jefe de Noticias

Editor

Publicar artículo

A2A

Rutas automáticas hacia el editor

25

Editor

Servidor MCP

Generar etiquetas

MCP/HTTP

Crea etiquetas y categorías

26

Editor

Elasticsearch

Artículo índice

ES REST API

Índice de artículos a índice news_archive

27

Editor

Sistema de archivos

Almacenar Markdown

E/S de archivos

Almacena el artículo como .md archivo en /articles

28

Editor

Jefe de Noticias

Confirmar publicación

A2A

Resultados de éxito

29

Jefe de Noticias

Interno

Actualización de la historia

-

Actualiza el estado de la noticia a "publicado"

Conclusión

Tanto A2A como MCP tienen papeles importantes en el paradigma moderno de infraestructura de LLM aumentado. A2A ofrece flexibilidad para sistemas complejos multiagente, pero potencialmente menos portabilidad y mayor complejidad operativa. MCP ofrece un enfoque estandarizado para la integración de herramientas que es más sencillo de implementar y mantener, aunque no está diseñado para manejar orquestación multiagente.

La elección no es binaria. Como demuestra nuestro ejemplo de redacción, los sistemas respaldados por LLM más sofisticados y efectivos suelen combinar ambos enfoques: los agentes coordinan y se especializan mediante protocolos A2A mientras acceden a sus herramientas y recursos a través de servidores MCP. Esta arquitectura híbrida ofrece los beneficios organizacionales de los sistemas multiagente junto con los beneficios de estandarización y ecosistema del MCP. Esto sugiere que puede que no sea necesario elegir en absoluto: simplemente usar ambos como un enfoque estándar

Depende de ti, como desarrollador o arquitecto, probar y determinar la mejor combinación de ambas soluciones para crear el resultado adecuado para tu caso de uso específico. Comprender las fortalezas, limitaciones y aplicaciones adecuadas de cada enfoque te permitirá construir sistemas de IA más eficaces, mantenibles y escalables.

Ya sea que estés construyendo una redacción digital, una plataforma de atención al cliente, un asistente de investigación o cualquier otra aplicación impulsada por LLM, considerar cuidadosamente tus necesidades de coordinación (A2A) y requisitos de acceso a herramientas (MCP) te pondrá en el camino hacia el éxito.

Recursos adicionales

• Constructor de agentes Elasticsearch: https://www.elastic.co/docs/solutions/search/elastic-agent-builder

• Especificación A2A: https://a2a-protocol.org/latest/specification/

• Integración de A2A y MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/

• Protocolo de Contexto del Modelo: https://modelcontextprotocol.io

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!

Los sistemas actuales respaldados por LLM están evolucionando rápidamente más allá de aplicaciones de modelo único hacia redes complejas donde agentes especializados trabajan juntos para realizar tareas que la informática moderna nunca antes consideró posibles. A medida que estos sistemas se vuelven más complejos, la infraestructura que permite la comunicación de agentes y el acceso a herramientas se convierte en el principal foco de desarrollo. Surgieron dos enfoques complementarios para abordar estas necesidades: los protocolos Agent2Agent (A2A) para la coordinación multiagente y el Protocolo de Contexto del Modelo (MCP) para el acceso estandarizado a herramientas y recursos.

Entender cuándo usar cada uno en armonía con y sin el otro puede afectar significativamente la escalabilidad, mantenibilidad y efectividad de tus aplicaciones. Este artículo explora los conceptos e implementaciones de A2A dentro del ejemplo práctico de una redacción digital, donde agentes especializados en LLM colaboran para investigar, escribir, editar y publicar artículos de noticias.

Aquí se puede encontrar un repositorio adjunto, y examinaremos ejemplos concretos de A2A en acción cerca del final del artículo en la Sección 5.

Prerrequisitos

El repositorio consiste en implementaciones basadas en Python de los agentes A2A. Flask proporciona un servidor API, así como un servicio de mensajería personalizado en Python llamado Event Hub, que enruta mensajes para registro y actualizaciones de la interfaz. Por último, se dispone de una interfaz React para el uso independiente de las funciones de la redacción. Todo está contenido dentro de una imagen Docker para facilitar su implementación. Si quieres ejecutar los servicios directamente con tu máquina, querrás cerciorarte de tener estas tecnologías instaladas:

Lenguajes y tiempos de ejecución

• Python 13.12 - Lenguaje central de backend

• Node.js 18+ - Interfaz de React opcional

Frameworks y SDKS básicos:

• A2A SDK 0.3.8 - Coordinación y comunicación de agentes

• SDK Anthropic - Integración de Claude para generación de IA

• Uvicorn - servidor ASGI para ejecutar agentes

• FastMCP 2.12.5+ - Implementación del servidor MCP

• React 18.2 - Marco de interfaz de usuario frontend

Datos y búsqueda

• Elasticsearch 9.1.1+ - Indexación y búsqueda de artículos

Despliegue en Docker (opcional, pero recomendado)

• Docker 28.5.1+

Sección 1: ¿Qué es Agent2Agent (A2A)?

Definición y conceptos fundamentales

Agent2Agent (A2A) es un protocolo estandarizado para la interacción entre agentes independientes de LLM. En lugar de un único sistema monolítico que gestione todas las tareas, A2A permite que múltiples agentes especializados se comuniquen, coordinen y colaboren para lograr flujos de trabajo complejos que serían difíciles, lentos o directamente imposibles de manejar eficientemente para un solo agente.

Especificaciones oficiales: https://a2a-protocol.org/latest/specification/

Orígenes y evolución

El concepto de comunicación Agent2Agent, o sistemas multiagente, tiene raíces en sistemas distribuidos, microservicios e investigación multiagente que se remontan a décadas atrás. Los primeros trabajos en inteligencia artificial distribuida sentaron las bases para agentes capaces de negociar, coordinar y colaborar. Estos primeros sistemas estaban dedicados a simulaciones sociales a gran escala, investigación académica y gestión de redes eléctricas.

Con la llegada de la disponibilidad de LLMs y la reducción del costo operativo, los sistemas multiagente estuvieron disponibles para los mercados "prosumers", con el respaldo de Google y la comunidad de investigación en IA en general. Ahora conocido como sistemas Agent2Agent, la incorporación del protocolo A2A evolucionó hasta convertir en un estándar moderno diseñado específicamente para la era de múltiples grandes modelos de lenguaje coordinando esfuerzos y tareas.

El protocolo A2A garantiza una comunicación y coordinación fluidas entre agentes aplicando estándares y principios consistentes a los puntos de interacción donde los LLMs se conectan y comunican. Esta estandarización permite que agentes de diferentes desarrolladores —empleando distintos modelos subyacentes— trabajen juntos de forma eficaz.

Los protocolos de comunicación no son nuevos y tienen raíces ampliamente arraigadas en casi todas las transacciones digitales realizadas en Internet. Si escribiste https://www.elastic.co/search-labs en un navegador para acceder a este artículo, las probabilidades son altas de que se ejecutaron protocolos TCP/IP, transporte HTTP y consulta DNS, cerciorando una experiencia de navegación coherente para nosotros.

Características clave

Los sistemas A2A se basan en varios principios fundamentales para garantizar una comunicación fluida. Construir sobre estos principios garantiza que diferentes agentes, basados en distintos LLMs, frameworks y lenguajes de programación, interactúen de forma fluida.

Estos son los cuatro principios principales:

• Paso de mensajes: Los agentes se comunican mediante mensajes estructurados con propiedades y formatos bien definidos

• Coordinación: Los agentes orquestan flujos de trabajo complejos delegando tareas entre sí y gestionando dependencias sin bloquear a otros agentes

• Especialización: Cada agente se centra en un dominio o capacidad específica, convertir en un experto en su área y ofreciendo la realización de tareas basar en ese conjunto de habilidades

• Estado distribuido: El estado y el conocimiento se distribuyen entre agentes en lugar de centralizar, con los agentes con la capacidad de actualizar mutuamente sobre el progreso con el estado de la tarea y retornos parciales (artefactos)

La redacción: Un ejemplo recurrente

Imagina una redacción digital impulsada por agentes de IA, cada uno especializado en un aspecto diferente del periodismo:

• Jefe de Noticias (coordinador/cliente): Asigna historias y monitorear el flujo de trabajo

• Agente reportero: Escribe artículos basados en investigaciones y entrevistas

• Agente Investigador: recopila datos, estadísticas e información de fondo

• Archive Agent: Busca en artículos históricos e identifica tendencias usando Elasticsearch

• Editor Agent: Reseña artículos para calidad, estilo y optimización SEO

• Agente editorial: Publica artículos aprobados en la plataforma de blogs vía CI/CD

Estos agentes no actúan de forma aislada; cuando el Jefe de Noticias asigna una noticia sobre la adopción de energías renovables, el Reportero necesita que el Investigador recopile estadísticas, que el Editor revise el borrador y que el Editor publique el texto final. Esta coordinación se realiza a través de protocolos A2A.

Sección 2: comprensión de la arquitectura A2A

Roles de Agente de Cliente y Agente Remoto

En la arquitectura A2A, los agentes asumen dos roles principales. El Agente Cliente es responsable de formular y comunicar tareas a otros agentes del sistema. Identifica a los agentes remotos y sus capacidades, empleando esta información para tomar decisiones informadas sobre la delegación de tareas. El agente cliente coordina el flujo de trabajo general, cerciorando que las tareas se distribuyan correctamente y que el sistema avance hacia sus objetivos.

El Agente Remoto, en cambio, actúa en tareas delegadas por los clientes. Proporciona información o toma acciones específicas en respuesta a solicitudes, pero no inicia acciones de forma independiente. Los agentes remotos también pueden comunicar con otros agentes remotos según sea necesario para cumplir con sus responsabilidades asignadas, creando una red colaborativa de capacidades especializadas.

En nuestra redacción, el Jefe de Noticias actúa como agente cliente, mientras que el Reportero, el Investigador, el Editor y el Editor son agentes remotos que responden a las solicitudes y coordinan entre sí.

Capacidades básicas de A2A

Los protocolos A2A definen varias capacidades que permiten la colaboración multiagente:

1. Descubrimiento

Los servidores A2A deben anunciar sus capacidades para que los clientes sepan cuándo y cómo emplearlas para tareas específicas. Esto se logra mediante Tarjetas de Agente—documentos JSON que describen las habilidades, entradas y salidas de un agente. Las Tarjetas de Agente están disponibles en puntos finales consistentes y conocidos (como el recomendado /.well-known/agent-card.json endpoint), permitiendo a los clientes descubrir y consultar las capacidades de un agente antes de iniciar la colaboración.

A continuación hay un ejemplo de Tarjeta de Agente para el Agente de Archivo personalizado de Elastic, "Archie Archivist". Ten en cuenta que proveedores de software como Elastic alojan sus agentes A2A y proporcionan una URL para el acceso:

Esta Tarjeta de Agente revela varios aspectos importantes del Agente de Archivo de Elastic. El agente se identifica como "Archie Archivist" y deja claro su propósito: ayudar a encontrar documentos históricos de noticias en un índice de Elasticsearch. La tarjeta especifica el proveedor (Elastic) y la versión del protocolo (0.3.0), cerciorando la compatibilidad con otros agentes compatibles con A2A. Lo más importante es que el skills array enumera las capacidades específicas que ofrece este agente, incluyendo una poderosa funcionalidad de búsqueda y una exploración inteligente de índices. Cada habilidad define qué modos de entrada y salida soporta, permitiendo a los clientes entender exactamente cómo comunicar con este agente. Este agente deriva del servicio Agent Builder de Elastic, que ofrece un conjunto de herramientas nativas respaldadas por LLM y endpoints API para mantener una conversación con tu almacén de datos, no solo para recuperarlo de él. El acceso a los agentes A2A en Elasticsearch puede encontrar aquí.

2. Negociación

Clientes y agentes deben acordar los métodos de comunicación —ya sea que las interacciones se realicen mediante texto, formularios, iframes o incluso audio/video— para garantizar una interacción adecuada del usuario y el intercambio de datos. Esta negociación ocurre al inicio de la colaboración entre agentes y establece los protocolos que gobernarán su interacción a lo largo del flujo de trabajo. Por ejemplo, un agente de atención al cliente basado en voz podría negociar para comunicar mediante flujos de audio, mientras que un agente de análisis de datos podría preferir JSON estructurado. El proceso de negociación garantiza que ambas partes puedan intercambiar información de forma eficaz en un formato que se adapte a sus capacidades y a los requisitos de la tarea en cuestión.

Las capacidades listadas en el fragmento JSON anterior tienen todas esquemas de entrada y salida; Estos establecen una expectativa de cómo interactuar con este agente por parte de otros agentes.

3. Gestión de tareas y estado

Los clientes y agentes necesitan mecanismos para comunicar el estado de la tarea, cambios y dependencias a lo largo de la ejecución. Esto incluye gestionar todo el ciclo de vida de una tarea, desde su creación y asignación hasta las actualizaciones de progreso y los cambios de estado. Los estados típicos incluyen estados pendientes, en curso, completados o fallidos. El sistema también debe hacer un seguimiento de las dependencias entre tareas para cerciorar que el trabajo previo se complete antes de que comiencen las tareas dependientes. El manejo de errores y la lógica de reintentos también son componentes esenciales, que permiten al sistema recuperar de forma elegante tras fallos y seguir avanzando hacia el objetivo principal.

Ejemplo de mensaje de tarea:

Este mensaje de tarea de ejemplo demuestra varios aspectos clave de la comunicación A2A.

• La estructura del mensaje incluye metadatos como un identificador único del mensaje, el tipo de mensaje enviado, la identificación del remitente y receptor, y una marca de tiempo para el seguimiento y la depuración.

• La carga útil contiene la información real de la tarea, especificando qué capacidad se está invocando en el agente remoto y proporcionando los parámetros necesarios para ejecutar dicha capacidad.

• La sección de contexto proporciona información adicional que ayuda al agente receptor a comprender el flujo de trabajo más amplio, incluyendo plazos y niveles de prioridad que informan sobre cómo debe asignar sus recursos y programar su trabajo.

4. Colaboración

Clientes y agentes deben apoyar una interacción dinámica pero estructurada, permitiendo a los agentes aplicar aclaraciones, información o subacciones al cliente, otros agentes o usuarios. Esto crea un entorno colaborativo donde los agentes pueden hacer preguntas de seguimiento cuando las instrucciones iniciales son ambiguas, aplicar contexto adicional para tomar mejores decisiones, delegar subtareas a otros agentes con experiencia más adecuada y proporcionar resultados intermedios para recibir retroalimentación antes de proceder con la tarea completa. Esta comunicación multidireccional cerciora que los agentes no actúen de forma aislada, sino que participen en un diálogo continuo que conduce a mejores resultados.

Comunicación distribuida entre pares

A2A permite la comunicación distribuida donde los agentes pueden ser alojados por diferentes organizaciones, con algunos agentes mantenidos internamente mientras que otros son proporcionados por servicios externos. Estos agentes pueden funcionar en diferentes infraestructuras, potencialmente abarcando múltiples proveedores de nube o centros de datos locales. Pueden usar diferentes LLMs subyacentes, con algunos agentes impulsados por modelos GPT, otros por Claude y otros más por alternativas de código abierto. Los agentes incluso podrían operar en diferentes regiones geográficas para cumplir con los requisitos de soberanía de datos o reducir la latencia. A pesar de esta diversidad, todos los agentes acuerdan un protocolo de comunicación común para el intercambio de información, garantizando la interoperabilidad independientemente de los detalles de la implementación. Esta arquitectura distribuida ofrece flexibilidad en la construcción y despliegue de los sistemas, permitiendo a las organizaciones combinar los mejores agentes e infraestructuras según sus necesidades específicas.

Esta es la arquitectura final de la aplicación de redacción:

Sección 3: Protocolo de Contexto de Modelo (MCP)

Definición y propósito

El Protocolo de Contexto del Modelo (MCP) es un protocolo estandarizado desarrollado por Anthropic para mejorar y potenciar un LLM individual con herramientas, recursos y prompts definidos por el usuario, entre otras adiciones suplementarias a la base de código. MCP proporciona una interfaz universal entre los modelos de lenguaje y los recursos externos que necesitan para completar tareas de manera eficaz. Este artículo describe el estado actual de MCP con ejemplos de casos de uso, tendencias emergentes y la propia implementación de Elastic.

Conceptos centrales de MCP

MCP opera sobre una arquitectura cliente-servidor con tres componentes principales:

• Clientes: aplicaciones (como Claude Desktop o aplicaciones de IA personalizadas) que se conectan a servidores MCP para acceder a sus capacidades.

• Servidores: aplicaciones que exponen recursos, herramientas y prompts a modelos de lenguaje. Cada servidor se especializa en proporcionar acceso a capacidades o fuentes de datos específicas.

  • Herramientas: funciones definidas por el usuario que los modelos pueden invocar para realizar acciones, como bases de datos de búsqueda, llamar a APIs externas o transformaciones de ejecución sobre datos

  • Recursos: fuentes de datos de las que los modelos pueden leer, que se sirven con datos dinámicos o estáticos y se acceden mediante patrones URI (similares a rutas REST)

  • Prompts: plantillas reutilizables de prompts con variables que guían el modelo para realizar tareas específicas.

Patrón de petición-respuesta

MCP sigue un patrón de interacción petición-respuesta familiar similar a las APIs REST. El cliente (LLM) aplicar un recurso o invoca una herramienta, luego el servidor MCP procesa la solicitud y devuelve el resultado, que el LLM emplea para continuar su tarea. Este modelo centralizado con servidores periféricos proporciona un patrón de integración más sencillo en comparación con la comunicación entre agentes entre iguales.

MCP en la redacción

En nuestro ejemplo de redacción, los agentes individuales emplean servidores MCP para acceder a las herramientas y datos que necesitan:

• Utilizaciones de Researcher Agent :

  • Servidor MCP de la API de Noticias (acceso a bases de datos de noticias)

  • Verificación de hechos del servidor MCP (verificar afirmaciones frente a fuentes confiables)

  • Servidor MCP de la base de datos académica (artículos académicos e investigaciones)

• Reporter Agent emplea:

  • Guía de estilo MCP Server (estándares de redacción para redacción)

  • Servidor MCP de plantillas (plantillas y formatos de artículos)

  • Servidor MCP de Biblioteca de Imágenes (fotos de archivo y gráficos)

• Editor Agent emplea:

  • Grammar Checker MCP Server (herramientas de calidad del lenguaje)

  • Servidor MCP de detección de plagio (verificación de originalidad)

  • Análisis SEO Servidor MCP (optimización de titulares y palabras clave)

• Utilizaciones del Agente de la Editorial :

  • CMS MCP Server (API del sistema de gestión de contenidos)

  • Servidor CI/CD MCP (Pipeline de despliegue)

  • Servidor MCP de Análisis (seguimiento y monitorización)

Sección 4: comparación de arquitectura

Cuándo usar A2A

La arquitectura A2A destaca en escenarios que requieren colaboración genuina entre múltiples agentes. Los flujos de trabajo de varios pasos que requieren coordinación se benefician enormemente de A2A, especialmente cuando las tareas implican múltiples pasos secuenciales o paralelos, flujos de trabajo que requieren iteración y refinamiento, y procesos con puntos de control y necesidades de validación. En nuestro ejemplo de redacción, el flujo de trabajo de la historia requiere que el Reportero escriba, pero puede que tenga que iterar de nuevo al Investigador si la confianza en ciertos hechos es baja, luego proceder al Editor y finalmente al Editor.

La especialización específica de dominio en múltiples áreas es otro caso de uso estable para A2A. Cuando se necesitan múltiples expertos en distintos campos para realizar una tarea mayor, con cada agente aportando un profundo conocimiento del dominio y capacidades de razonamiento especializadas para distintos aspectos, A2A proporciona el marco de coordinación necesario para establecer esas conexiones. La redacción lo ejemplifica perfectamente: el investigador se especializa en la recopilación de información, el reportero en la escritura y el editor en el control de calidad, cada uno con una experiencia distinta.

La necesidad de un comportamiento autónomo de agentes hace que A2A sea especialmente valioso. Los agentes que pueden tomar decisiones independientes, mostrar un comportamiento proactivo basado en condiciones cambiantes y adaptar dinámicamente a los requisitos del flujo de trabajo prosperan en una arquitectura A2A. La escalada horizontal de funciones especializadas es otro beneficio clave: en lugar de tener un único maestro de todos los oficios, múltiples agentes especializados trabajan coordinados, y múltiples instancias del mismo agente pueden manejar subtareas de forma asíncrona. Durante noticias de última hora en nuestra redacción, por ejemplo, varios agentes de Reporter pueden trabajar simultáneamente en diferentes ángulos de la misma historia.

Por último, las tareas que requieren colaboración genuina entre múltiples agentes son ideales para A2A. Esto incluye mecanismos de evaluación de los LLM como jurado , sistemas de construcción de consenso y votación, y la resolución colaborativa de problemas donde se necesitan múltiples perspectivas para alcanzar el mejor resultado.

Cuándo usar MCP

El Protocolo de Contexto del Modelo es ideal para ampliar las capacidades de un solo modelo de IA. Cuando un único modelo de IA necesita acceso a múltiples herramientas y fuentes de datos, MCP ofrece la solución perfecta con razonamiento centralizado combinado con herramientas distribuidas e integración sencilla de herramientas. En nuestro ejemplo de redacción, el Agente de Investigación (un modelo) necesita acceso a múltiples fuentes de datos, incluyendo News API, servicios de verificación de hechos y bases de datos académicas, todo ello accedido a través de servidores MCP estandarizados.

La integración estandarizada de herramientas se convierte en una prioridad cuando la ampliación de la compartición y la reutilización de las integraciones de herramientas importan. MCP destaca aquí con su ecosistema de servidores MCP preconstruidos que reducen significativamente el tiempo de desarrollo para integraciones comunes. Cuando se requiere simplicidad y mantenibilidad, los patrones de solicitud-respuesta de MCP son familiares para los desarrolladores, más fáciles de entender y depurar que los sistemas distribuidos, y tienen una menor complejidad operativa.

Por último, MCP suele ser ofrecido por proveedores de software para facilitar la comunicación remota con sus sistemas. Estos servidores MCP ofrecidos por el proveedor reducen significativamente el tiempo de incorporación y desarrollo, al tiempo que ofrecen una interfaz estandarizada con sistemas propietarios, haciendo que la integración sea mucho más sencilla que el desarrollo de APIs personalizadas.

Cuándo usar ambos (MCP de A2A ❤️)

Muchos sistemas sofisticados se benefician de combinar A2A y MCP, como se indica en la documentación de A2A sobre integración MCP. Los sistemas que requieren tanto coordinación como estandarización son candidatos ideales para un enfoque híbrido. A2A se encarga de la coordinación de agentes y la orquestación de flujos de trabajo, mientras que MCP proporciona acceso a herramientas individuales a los agentes. En nuestro ejemplo de redacción, los agentes coordinan mediante A2A; con el flujo de trabajo pasando de reportero a investigador, luego editor y luego editor. Sin embargo, cada agente emplea servidores MCP para sus herramientas especializadas, creando una separación arquitectónica limpia.

Múltiples agentes especializados, cada uno usando MCP para acceder a herramientas, representan un patrón común donde hay una capa de coordinación de agentes gestionada por A2A y una capa de acceso a herramientas gestionada por MCP. Esta clara separación de preocupaciones facilita la comprensión y el mantenimiento de los sistemas.

Los beneficios de combinar ambos enfoques son sustanciales. Obtienes los beneficios organizacionales de los sistemas multiagente, incluyendo especialización, autonomía y procesamiento en paralelo, además de disfrutar de los beneficios de estandarización y ecosistema del MCP, como la integración de herramientas y el acceso a recursos. Hay una clara separación entre la coordinación de agentes (A2A) y el acceso a recursos (MCP), y lo importante es que A2A no es necesario solo para tareas pequeñas como el acceso a API—MCP las gestiona de forma eficiente sin la sobrecarga de la orquestación multiagente.

Preguntas frecuentes: A2A vs. MCP - Casos de uso

Característica

Agent2Agent (A2A)

Protocolo de Contexto de Modelo (MCP)

Híbrido (A2A + MCP)

Objetivo principal

Coordinación Multiagente: Permite que un equipo de agentes especializados trabaje juntos en flujos de trabajo complejos y de varios pasos.

Mejora de un solo agente: Extiende la capacidad de un único LLM/Agente con herramientas, recursos y datos externos.

Fuerza combinada: A2A gestiona el flujo de trabajo del equipo, mientras que MCP proporciona herramientas a cada miembro del equipo.

Ejemplo de equipo de redacción

La cadena de flujo de trabajo: Jefe de Noticias → Reportero → Investigador → Editor → Editor. Esta es la capa de coordinación.

Herramientas individuales del agente: El Agente Reportero accede al servidor de la guía de estilo y al servidor de plantillas (a través de MCP). Esta es la capa de acceso a herramientas.

El sistema completo: el reportero coordina con el editor (A2A), y el reportero emplea el servidor MCP de la Biblioteca de Imágenes para encontrar un gráfico para la historia.

Cuándo usar cuál

Cuando necesitas colaboración genuina, iteración y refinamiento, o experiencia especializada repartida entre varios agentes.

Cuando un solo agente necesita acceso a múltiples herramientas y fuentes de datos o requiere integración estandarizada con sistemas propietarios.

Cuando necesitas los beneficios organizacionales de los sistemas multiagente y los beneficios de estandarización y ecosistema del MCP.

Beneficio fundamental

Autonomía y escalado: Los agentes pueden tomar decisiones independientes, y el sistema permite la escalado horizontal de funciones especializadas.

Simplicidad y estandarización: Más fácil de depurar y mantener gracias al razonamiento centralizado, y proporciona una interfaz universal para los recursos.

Separación clara de preocupaciones: Facilita la comprensión del sistema: A2A = trabajo en equipo, MCP = acceso a la herramienta.

Conclusión

Esta es la primera sección de dos partes que cubren la implementación de agentes basados en A2A reforzados con servidores MCP para proporcionar soporte y acceso externo a datos y herramientas. El siguiente artículo explorará el código real para demostrar que trabajan juntos para emular las actividades en una redacción online. Aunque ambos sistemas son extremadamente capaces y flexibles por sí mismos, verás cuánto se complementan cuando trabajan en conjunto.

En este blog, emplearemos Mastra para construir un agente de conocimiento que recuerda lo que dicen los usuarios y puede recuperar información relevante más adelante, empleando Elasticsearch como backend de memoria y recuperación. Puedes extender fácilmente este mismo concepto a casos de uso reales, piensa en agentes de soporte que puedan recordar conversaciones y resoluciones pasadas, permitiéndoles adaptar las respuestas a usuarios específicos o a soluciones superficiales más rápido basar en contextos previos.

Sigue aquí para ver cómo construirlo paso a paso. Si te pierdes o simplemente quieres ejecutar un ejemplo terminado, echa un vistazo al repositorio aquí.

¿Qué es Mastra?

Mastra es un framework TypeScript de código abierto para construir agentes de IA con partes intercambiables para razonamiento, memoria y herramientas. Su función de recuperación semántica permite a los agentes recordar y recuperar interacciones pasadas almacenando mensajes como incrustaciones en una base de datos vectorial. Esto permite a los agentes mantener el contexto y la continuidad de la conversación a largo plazo. Elasticsearch es un excelente almacén vectorial para habilitar esta función, ya que soporta una búsqueda vectorial densa eficiente. Cuando se activa la recuperación semántica, el agente extrae mensajes pasados relevantes en la ventana de contexto del modelo, permitiendo que el modelo emplee ese contexto recuperado como base para su razonamiento y respuestas.

Lo que necesitas para empezar

• Nodo v18+

• Elasticsearch (versión 8.15 o posterior)

• Clave API de Elasticsearch

• Clave API de OpenAI

Nota: Necesitarás esto porque la demo usa el proveedor OpenAI, pero Mastra soporta otros SDKs de IA y proveedores de modelos comunitarios, así que puedes cambiarlo fácilmente según tu configuración.

Construyendo un proyecto de Mastra

Emplearemos la CLI integrada de Mamra para proporcionar el andamiaje de nuestro proyecto. Ejecuta el comando:

Recibirás un conjunto de indicaciones, que empiezan por:

1. Pon un nombre a tu proyecto.

2. Podemos mantener este valor predeterminado; No dudes en dejar esto en blanco.

3. Para este proyecto, emplearemos un modelo proporcionado por OpenAI.

4. Selecciona la opción "Saltar por ahora" porque almacenaremos todas nuestras variables de entorno en un archivo '.env' que configuraremos en un paso posterior.

5. También podemos saltar esta opción.

Una vez que termines de inicializar, podemos pasar al siguiente paso.

Instalación de dependencias

A continuación, necesitamos instalar algunas dependencias:

• ai - Paquete básico de SDK de IA que proporciona herramientas para gestionar modelos de IA, prompts y flujos de trabajo en JavaScript/TypeScript. Mastra está construido sobre el SDK de IA por Vercel, así que necesitamos esta dependencia para permitir la interacción del modelo con tu agente.

• @ai-sdk/openai - Plugin que conecta el SDK de IA con modelos OpenAI (como GPT-4, GPT-4o, etc.), habilitando llamadas API usando tu clave API OpenAI.

• @elastic/elasticsearch - Cliente oficial de Elasticsearch para Node.js, se emplea para conectarse a tu Elastic Cloud o a un clúster local para operaciones de indexación, búsqueda y vectores.

• dotenv - Carga variables de entorno desde un .env archivar en process.env, permitiendo inyectar de forma segura credenciales como claves API y endpoints Elasticsearch.

Configuración de variables de entorno

Crea un archivo .env en el directorio raíz de tu proyecto si aún no ves uno. Alternativamente, puedes copiar y renombrar el ejemplo .env que proporcioné en el repositorio. En este archivo, podemos agregar las siguientes variables:

Eso concluye la configuración básica. Desde aquí, ya puedes empezar a construir y orquestar agentes. Vamos un paso más allá y agregaremos Elasticsearch como la capa de almacenamiento y búsqueda vectorial.

Agregar Elasticsearch como almacenamiento vectorial

Crea una nueva carpeta llamada stores y dentro, agrega este archivo. Antes de que Mastra y Elastic lanzaran una integración oficial de almacenamiento vectorial de Elasticsearch, Abhi Aiyer(CTO de Mestra) compartió esta clase prototipo temprana llamada ElasticVector. Simplemente, conecta la abstracción de memoria de Mamra con las densas capacidades vectoriales de Elasticsearch, para que los desarrolladores puedan incluir Elasticsearch como base de datos vectorial para sus agentes.

Echemos un vistazo más profundo a las partes importantes de la integración:

Ingestión del cliente Elasticsearch

Esta sección define la clase ElasticVector y configura la conexión cliente de Elasticsearch con soporte tanto para despliegues estándar como serverless.

• ElasticVectorConfig extends ClientOptions: Esto crea una nueva interfaz de configuración que hereda todas las opciones del cliente de Elasticsearch (como node, auth, requestTimeout) y agrega nuestras propiedades personalizadas. Esto significa que los usuarios pueden pasar cualquier configuración válida de Elasticsearch junto con nuestras opciones específicas para serverless.

• extends MastraVector: Esto permite ElasticVector heredar de la clase base de MastraVector de Mastra, que es una interfaz común a la que se ajustan todas las integraciones de almacenamiento vectorial. Esto garantiza que Elasticsearch se comporte como cualquier otro backend de vectores Mastra desde la perspectiva del agente.

• private client: Client: Esta es una propiedad privada que contiene una instancia del cliente JavaScript Elasticsearch. Esto permite que la clase hable directamente con tu grupo.

• isServerless y deploymentChecked: Estas propiedades trabajan juntas para detectar y almacenar en caché si estamos conectados a un despliegue serverless o estándar de Elasticsearch. Esta detección ocurre automáticamente en el primer uso, o puede configurar explícitamente.

• constructor(config: ClientOptions): Este constructor toma un objeto de configuración (que contiene tus credenciales de Elasticsearch y configuraciones opcionales de serverless) y lo emplea para inicializar el cliente en la línea this.client = new Client(config).

• super(): Esto llama constructor base de Mastra, por lo que hereda el registro, los asistentes de validación y otros ganchos internos.

En este punto, Mastra sabe que hay un nuevo almacén vectorial llamado ElasticVector

Detección del tipo de despliegue

Antes de crear índices, el adaptador detecta automáticamente si estás usando Elasticsearch estándar o Elasticsearch Serverless. Esto es importante porque los despliegues serverless no permiten la configuración manual de shards.

Qué pasa:

• Primero comprueba si pusiste explícitamente isServerless en la configuración (se salta la auto-detección).

• Llama a la API info() de Elasticsearch para obtener información del clúster

• Comprueba el build_flavor field (los despliegues serverless devuelven serverless)

• Vuelve a revisar el lema si no hay variedad de build disponible

• Almacena en caché el resultado para evitar llamadas repetidas a la API

• Por defecto se aplica al despliegue estándar si falla la detección

Ejemplo de uso:

Creación del almacén de "memoria" en Elasticsearch

La función siguiente establece un índice Elasticsearch para almacenar incrustaciones. Comprueba si el índice ya existe. Si no, crea uno con el mapeo que aparece abajo y contiene un campo dense_vector para almacenar incrustaciones y métricas de similitud personalizadas.

Algunas cosas a tener en cuenta:

• El parámetro dimension es la longitud de cada vector de incrustación, que depende del modelo de incrustación que estés usando. En nuestro caso, generaremos incrustaciones usando el modelo text-embedding-3-small de OpenAI, que genera vectores de tamaño 1536. Usaremos esto como nuestro valor por defecto.

• La variable similarity empleada en el mapeo a continuación se define a partir de la función auxiliar const similarity = this.mapMetricToSimilarity(metric), que toma el valor del parámetro metric y lo convierte en una palabra clave compatible con Elasticsearch para la métrica de distancia elegida.

  • Por ejemplo: Mastra emplea términos generales para similitud vectorial como cosine, euclidean, y dotproduct. Si pasáramos la métrica euclidean directamente al mapeo de Elasticsearch, generaría un error porque Elasticsearch espera que la palabra clave l2_norm represente la distancia euclidiana.

• Compatibilidad sin servidor: El código omite automáticamente los ajustes de shard y réplica para despliegues sin servidor, ya que estos son gestionados automáticamente por Elasticsearch Serverless.

Almacenar una nueva recordación o nota tras una interacción

Esta función toma nuevas incrustaciones generadas tras cada interacción, junto con los metadatos, y luego las inserta o actualiza en el índice usando la API bulk de Elastic. La API bulk agrupa múltiples operaciones de escritura en una sola solicitud; Esta mejora en nuestro rendimiento de indexación garantiza que las actualizaciones se mantengan eficientes a medida que la memoria de nuestro agente sigue creciendo.

Consulta de vectores similares para la recuperación semántica

Esta función es el núcleo de la característica de recuperación semántica. El agente emplea búsqueda vectorial para encontrar incrustaciones almacenadas similares dentro de nuestro índice.

Bajo el capó:

• Ejecuta una consulta kNN (k-vecinos más cercanos) usando la API knn en Elasticsearch.

• Recupera los vectores top-K similares al vector de consulta de entrada.

• Opcionalmente, aplica filtros de metadatos para reducir resultados (por ejemplo, buscar solo dentro de una categoría o rango de tiempo específico)

• Devuelve resultados estructurados que incluyen el ID del documento, el puntaje de similitud y los metadatos almacenados.

Creación del agente del conocimiento

Ahora que vimos la conexión entre Mastra y Elasticsearch a través de la integración ElasticVector , creemos el propio Knowledge Agent.

Dentro de la carpeta agents, crea un archivo llamado knowledge-agent.ts. Podemos empezar conectando nuestras variables de entorno e inicializando el cliente Elasticsearch.

Aquí, nosotros:

• Usa dotenv para cargar nuestras variables desde nuestro archivo .env .

• Comprueba si las credenciales de Elasticsearch se están inyectando correctamente y podemos establecer una conexión exitosa con el cliente.

• Pasa el endpoint de Elasticsearch y la clave API al constructor ElasticVector para crear una instancia de nuestro almacén vectorial que definimos antes.

• Opcionalmente, especifica isServerless: true si usas Elasticsearch Serverless. Esto omite el paso de detección automática y mejora el tiempo de arranque. Si se omite, el adaptador detectará automáticamente el tipo de despliegue en el primer uso.

A continuación, podemos definir el agente usando la clase Agent de Mastra.

Los campos que podemos definir son:

• name y instructions: Darle una identidad y función primaria.

• model: Estamos usando la gpt-4o de OpenAI a través del paquete @ai-sdk/openai .

• memory:

  • vector: Apunta a nuestra tienda Elasticsearch, así que los embeddings se almacenan y recuperan desde allí.

  • embedder: Qué modelo usar para generar incrustaciones

  • semanticRecall Las opciones deciden cómo funciona la retirada:

    • topK: Cuántos mensajes semánticamente similares recuperar.

    • messageRange: Cuánto de la conversación incluir en cada partido.

    • scope: Define el límite de la memoria.

Casi termino. Solo tenemos que agregar este agente recién creado a nuestra configuración de Mestra. En el archivo llamado index.ts, importa el agente de conocimiento e insértalo en el campo agents .

Los otros campos incluyen:

• storage: Este es el almacén interno de datos de Mamra para historial de ejecuciones, métricas de observabilidad, puntajes y cachés. Para más información sobre el almacenamiento de mastras, visita aquí.

• logger: Mastra emplea Pino, que es un registrador JSON estructurado y ligero. Captura eventos como inicios y atajada de agentes, llamadas y resultados de herramientas, errores y tiempos de respuesta de los LLM.

• observability: Controla el rastreo de IA y la visibilidad de ejecución de los agentes. Sigue lo siguiente:

  • Inicio/final de cada paso de razonamiento.

  • Qué modelo o herramienta se empleó.

  • Entradas y salidas.

  • Puntajes y evaluaciones

Probando al agente con Mastra Studio

¡Felicidades! Si llegaste hasta aquí, estás listo para ejecutar este agente y probar sus capacidades semánticas de recuperación. Por suerte, Mastra ofrece una interfaz de chat integrada para que no tengamos que crear la nuestra.

Para iniciar el servidor de desarrollo de Mestra, abre un terminal y ejecuta el siguiente comando:

Tras el empaquetado y el arranque inicial del servidor, debería proporcionarte una dirección del Playground.

Pega esta dirección en tu navegador y te recibirás con Mastra Studio.

Selecciona la opción de knowledgeAgent y charla sin parar.

Para una prueba rápida y ver si todo está correctamente cableado, dale información como: "El equipo anunció que el rendimiento de ventas en octubre subió un 12%, impulsado principalmente por renovaciones empresariales. El siguiente paso es ampliar su alcance a clientes de gama media." Después, inicia un nuevo chat y haz una pregunta como: "¿En qué segmento de clientes dijimos que debemos centrarnos a continuación?" El agente de conocimiento debería ser capaz de recordar la información que le diste en el primer chat. Deberías ver una respuesta como:

Ver una respuesta así significa que el agente almacenó con éxito nuestro mensaje anterior como incrustaciones en Elasticsearch y lo recuperó después usando búsqueda vectorial.

Inspección del almacenamiento de memoria a largo plazo del agente

Ve a la pestaña memory en la configuración de tu agente en Mastra Studio. Esto te permite ver lo que tu agente aprendió con el tiempo. Cada mensaje, respuesta e interacción que se incrusta y almacena en Elasticsearch pasa a formar parte de esta memoria a largo plazo. Puedes buscar semánticamente en interacciones pasadas para encontrar rápidamente información o contexto recordado que el agente aprendió antes. Este es esencialmente el mismo mecanismo que emplea el agente durante la recuperación semántica, pero aquí puedes inspeccionarlo directamente. En nuestro ejemplo a continuación, buscamos el término "ventas" y recibimos cada interacción que incluyera algo relacionado con las ventas.

Conclusión

Al conectar Mastra y Elasticsearch, podemos dar memoria a nuestros agentes, que es una capa clave en la ingeniería de contexto. Con la memoria semántica, los agentes pueden construir contexto con el tiempo, basando sus respuestas en lo que aprendieron. Eso significa interacciones más precisas, fiables y naturales.

Esta integración temprana es solo el punto de partida. El mismo patrón aquí puede permitir que los agentes de soporte recuerden tiquetes anteriores, bots internos que recuperen la documentación relevante o asistentes de IA que puedan recuperar detalles de los clientes en medio de una conversación. También estamos trabajando en una integración oficial de Mestra, haciendo que esta pareja sea aún más fluida en un futuro próximo.

Estamos deseando ver qué construyes a continuación. Pruébalo, explora Mastra y sus funciones de memoria, y siéntete libre de compartir lo que descubras con la comunidad.

Pero la verdadera magia ocurre cuando puedes llevar estas herramientas personalizadas y conscientes de los datos a los entornos donde pasas la mayor parte del tiempo. ¿Y si tu agente editor de código pudiera acceder de forma segura a la base de conocimiento privada de tu organización?

Ahí es donde entra el Protocolo de Contexto del Modelo (MCP). Elastic Agent Builder viene con un servidor MCP integrado que proporciona acceso a las herramientas de la plataforma.

¿Por qué usar el servidor MCP de Elastic Agent Builder?

Los agentes de IA son increíblemente poderosos, pero su conocimiento suele limitar a los datos con los que fueron capacitados y a la información que pueden buscar activamente en Internet público. No conocen los documentos internos de diseño de tu compañía, los libros de despliegue específicos de tu equipo ni la estructura única de tus registros de aplicaciones.

El reto es darle a tu asistente de IA el contexto especializado que necesita. Este es precisamente el problema que MCP está diseñado para resolver. MCP es un estándar abierto que permite a un modelo o agente de IA descubrir y emplear herramientas externas.

Para hacerlo posible, el Constructor de Agentes Elastic expone de forma nativa tus herramientas personalizadas a través de un servidor MCP integrado. Esto significa que puedes conectar fácilmente cualquier cliente compatible con MCP, como Cursor, VS Code o Claude Desktop, con las herramientas especializadas y conscientes de los datos que desarrollaste con Elastic Agent Builder.

Cuándo usar MCP (y cuándo no)

Elastic Agent Builder incluye varios protocolos para soportar diferentes patrones de integración. Elegir el adecuado es clave para construir flujos de trabajo efectivos en IA.

• Usa MCP para complementar tu agente de IA (como en Cursor o VS Code) con herramientas especializadas. Es el enfoque de "trae tus propias herramientas", mejorando el asistente que ya usas con acceso seguro a tus datos privados. Solo las herramientas se exponen a través del servidor MCP — los agentes de Elastic son independientes de ese.

• Emplea el Protocolo A2A para permitir que tu Agente Elastic personalizado completo colabore con otros agentes autónomos (como en Gemini Enterprise de Google). Esto es para la delegación de agente a agente, donde cada agente actúa como un par para resolver un problema.

• Emplea las APIs de Agent Builder para un control programático completo al construir una aplicación personalizada desde cero.

Para un desarrollador que busca obtener respuestas de su documentación interna sin salir de su IDE, MCP es la opción perfecta.

Ejemplo: tus herramientas personalizadas en Cursor con el servidor MCP de Agent Builder

Vamos a repasar un ejemplo práctico que uso a diario. Primero, rastreé e indexé nuestra documentación interna de ingeniería en un índice de Elasticsearch llamado elastic-dev-docs. Aunque podríamos usar las herramientas genéricas integradas disponibles en Agent Builder, crearemos nuestra propia herramienta personalizada para consultar esta base de conocimiento específica.

La razón para construir una herramienta personalizada es sencilla: control y precisión. Este enfoque nos da la capacidad de ejecutar una consulta rápida y semántica directamente contra nuestro índice de elastic-dev-docs . Tenemos control total sobre qué índice se dirige y cómo se recuperan los datos.

Ahora, aquí tienes cómo podemos usar esta base de conocimiento personalizada en un editor de código impulsado por IA, como Cursor.

Paso 1: Crea una herramienta de base de conocimiento personalizada en Agent Builder

Primero, crea una nueva herramienta en Agent Builder. Una descripción clara y específica de la herramienta es importante porque es como cualquier agente de IA, ya sea el Agente Elástico interno o una herramienta externa como Cursor conectar mediante MCP, descubre y selecciona tu herramienta para la tarea adecuada.

Una descripción contundente debe ser explícita. Por ejemplo: "Realiza una búsqueda semántica en el índice elastic-dev-docs para encontrar documentación interna de ingeniería, libros de ejecución y procedimientos de liberación."

Con eso en marcha, la herramienta está configurada para realizar una búsqueda semántica contra nuestro índice específico. Una vez almacenado, está disponible inmediatamente para ser servido.

Antes de conectarlo al exterior, puedes probarlo directamente en la interfaz. Simplemente haz clic en el botón Test para rellenar manualmente los parámetros, emulando lo que hará el LLM, e inspecciona los resultados para confirmar que todo funciona correctamente.

Paso 2: Conecta Cursor al servidor Elastic MCP

Elastic Agent Builder expone automáticamente todas las herramientas disponibles a través de un endpoint MCP seguro. Puedes encontrar la URL única de tu servidor en la interfaz de herramientas dentro de Kibana.

Para conectarnos a Cursor, simplemente agregamos esta URL a su archivo de configuración, junto con una clave API elástica para autenticación (aprende a crear clave API ES). Usamos una clave API para la autorización, ya que garantiza que las herramientas solo se ejecuten con las licencias que concediste, respetando todas tus reglas de control de acceso.

La configuración MCP en el ~/.cursor/mcp.json de Cursor es la siguiente:

Una vez almacenada la configuración, deberías ver la herramienta de servidor MCP de Elastic Agent Builder disponible en Cursor.

Paso 3: ¡pregunta lo que quieras!

Con la conexión establecido, los agentes Cursor pueden ahora invocar tus herramientas personalizadas para responder a tus preguntas o guiar el proceso de generación de código.

Hagamos una pregunta concreta:

"Pasos de búsqueda para liberar el servicio de rastreo desde la documentación interna de ingeniería de la organización elastic search"

Tras bambalinas, ocurre la magia:

1. El agente del cursor decide cómo responder a tu pregunta de la mejor manera y decide llamar a la engineering_documentation_internal_search

2. Invoca la herramienta mediante una consulta en lenguaje natural

3. La herramienta ejecuta una búsqueda semántica contra el índice de elastic-dev-docs y devuelve los procedimientos más relevantes y actualizados.

Obtenemos una respuesta precisa y fiable basada en nuestra documentación interna, todo sin salir nunca del editor de código. La experiencia es fluida y poderosa.

Te toca construir

Ahora viste cómo usar el servidor MCP integrado en Elastic Agent Builder para ampliar tus asistentes de IA con acceso seguro a tus datos privados. Fundamentar los modelos en tu propia información es clave para que sean realmente útiles.

Para recapitular, cubrimos los pasos principales:

• Elegir el protocolo adecuado para tus necesidades (MCP).

• Crear una herramienta de base de conocimiento personalizada.

• Conectar esa herramienta a un asistente IDE como Cursor.

Tus agentes y herramientas ya no necesitan estar desconectados de su contexto más valioso. Esperamos que esta guía te ayude a crear flujos de trabajo más efectivos y conscientes de los datos. ¡Feliz construcción!

En el Elastic Stack hay muchas aplicaciones agenticas impulsadas por LLM, como el próximo Elastic AI Agent en Agent Builder (actualmente en vista previa tecnológica) y Attack Discovery (GA en 8.18 y 9.0+), con más en desarrollo. Durante el desarrollo, e incluso luego del despliegue, es importante responder a estas preguntas:

• ¿Cómo estimamos la calidad de las respuestas de estas aplicaciones de IA?

• Si hacemos un cambio, ¿cómo garantizamos que el cambio sea realmente una mejora y que no cause degradación en la experiencia del usuario?

• ¿Cómo podemos probar estos resultados de forma fácilmente repetible?

A diferencia de las pruebas tradicionales de software, evaluar aplicaciones de IA generativa implica métodos estadísticos, revisión cualitativa matizada y un profundo entendimiento de los objetivos del usuario.

Este artículo detalla el proceso que emplea el equipo de desarrollo de Elastic para realizar evaluaciones, garantizar la calidad de los cambios antes del despliegue y monitorizar el rendimiento del sistema. Nuestro objetivo es garantizar que cada cambio esté respaldado por evidencias, lo que conduzca a resultados fiables y verificables. Parte de este proceso está integrada directamente en Kibana, reflejando nuestro compromiso con la transparencia como parte de nuestra filosofía de código abierto. Al compartir abiertamente partes de nuestros datos y métricas de evaluación, buscamos fomentar la confianza de la comunidad y proporcionar un marco claro para cualquiera que desarrolle agentes de IA o emplee nuestros productos.

Ejemplos de productos

Los métodos empleados en este documento fueron la base para iterar y mejorar soluciones como Attack Discovery y Elastic AI Agent. Una breve introducción de ambos, respectivamente:

Descubrimiento de ataques de Elastic Security

El Descubrimiento de Ataques emplea LLMs para identificar y resumir secuencias de ataques en Elastic. Dado el sistema de alertas de Elastic Security en un plazo determinado (por defecto 24 horas), el flujo de trabajo agente de Attack Discovery detectará automáticamente si se produjeron ataques, así como información importante como qué host o usuarios fueron comprometidos y qué alertas contribuyeron a la conclusión.

El objetivo es que la solución basada en LLM produzca una salida al menos tan buena como la de un humano.

Agente de IA elástica

Elastic Agent Builder es nuestra nueva plataforma para construir agentes de IA conscientes del contexto que aprovechan todas nuestras capacidades de búsqueda. Incluye el Elastic AI Agent, un agente preconstruido y de propósito general diseñado para ayudar a los usuarios a comprender y obtener respuestas de sus datos mediante la interacción conversacional.

El agente lo logra identificando automáticamente la información relevante dentro de Elasticsearch o bases de conocimiento conectadas y aprovechando un conjunto de herramientas prediseñadas para interactuar con ellas. Esto permite al Agente Elastic AI responder a una amplia variedad de consultas de usuario, desde simples preguntas frecuentes en un solo documento hasta solicitudes complejas que requieren agregación y búsquedas de un o varios pasos en múltiples índices.

Medición de mejoras mediante experimentos

En el contexto de los agentes de IA, un experimento es un cambio estructurado y comprobable en el sistema diseñado para mejorar el rendimiento en dimensiones bien definidas (por ejemplo, utilidad, corrección, latencia). El objetivo es responder de forma definitiva: "Si fusionamos este cambio, ¿podemos garantizar que es una verdadera mejora y que no degradará la experiencia del usuario?"

La mayoría de los experimentos que realizamos suelen incluir:

• Una hipótesis: Una afirmación específica y falsable. Ejemplo: "Agregar acceso a una herramienta de detección de ataques mejora la corrección en consultas relacionadas con la seguridad."

• Criterios de éxito: Umbrales claros que definan qué significa "éxito". Ejemplo: "+5% de mejora en el puntaje de corrección en el conjunto de datos de seguridad, sin degradación en otros lugares."

• Plan de evaluación: Cómo medimos el éxito (métricas, conjuntos de datos, método de comparación)

Un experimento exitoso es un proceso sistemático de investigación. Cada cambio, desde un pequeño ajuste de prompt hasta un cambio arquitectónico importante, sigue estos siete pasos para cerciorar que los resultados sean significativos y accionables:

• Paso 1: Identificar el problema

• Paso 2: Definir métricas

• Paso 3: Formular una hipótesis clara

• Paso 4: Preparar el conjunto de datos de evaluación

• Paso 5: Ejecutar el experimento

• Paso 6: Analizar resultados + iterar

• Paso 7: Toma una decisión y documenta

Un ejemplo de estos pasos se ilustra en la Figura 1. Las siguientes subsecciones explicarán cada paso y ampliaremos los detalles técnicos de cada paso en los próximos documentos.

Paso a paso con ejemplos reales de Elastic

Paso 1: Identificar el problema

¿Cuál es exactamente el problema que pretende resolver este cambio?

Ejemplo de descubrimiento de ataque: Los resúmenes a veces son incompletos, o una actividad benigna se marca erróneamente como ataque (falsos positivos).

Ejemplo de Elastic AI Agent: La selección de herramientas del agente, especialmente para consultas analíticas, es subóptima e inconsistente, lo que a menudo lleva a que se elija la herramienta equivocada. Esto, a su vez, incrementa los costos y la latencia de los tokens.

Paso 2: Definir métricas

Haz que el problema sea medible, para que podamos comparar un cambio con el estado actual.

Las métricas comunes incluyen precisión y recordación, similitud semántica, factualidad, etc. Dependiendo del caso de uso, usamos comprobaciones de código para calcular las métricas, como coincidir IDs de alerta o URLs correctamente recuperadas, o usar técnicas como LLM-as-judge para respuestas más libres.

A continuación, algunos ejemplos de métricas (no exhaustivas) empleadas en los experimentos:

Detección de ataques

Métrico

Descripción

Precisión y recordación

Compara los IDs de alerta entre las salidas reales y esperadas para medir la precisión de la detección.

Similitud

Usa BERTScore para comparar la similitud semántica del texto de respuesta.

Hechos

¿Existen indicadores clave de compromiso (IOC)? ¿Se reflejan correctamente las tácticas MITRE (taxonomía industrial de los ataques)?

Consistencia de la cadena de ataque

Compara el número de descubrimientos para comprobar si hay sobrenotificación o infranotificación del ataque.

Agente de IA elástica

Métrico

Descripción

Precisión y recordación

Compara documentos/información recuperada por el agente para responder a una consulta del usuario con la información o documentos reales necesarios para responder a la consulta y así medir la precisión de la recuperación.

Hechos

¿Están presentes los datos clave necesarios para responder a la consulta del usuario? ¿Están los hechos en el orden correcto para las consultas procesales?

Relevancia de la respuesta

¿La respuesta contiene información que es periférica o no relacionada con la consulta del usuario?

Completitud de respuesta

¿La respuesta responde a todas las partes de la consulta del usuario? ¿Contiene la respuesta toda la información presente en la verdad sobre el terreno?

ES|Validación QL

¿Es el ES| generado?¿QL sintácticamente correcto? ¿Es funcionalmente idéntico a la verdad básica ES|¿QL?

Paso 3: Formular una hipótesis clara

Establece un criterio claro de éxito empleando el problema y las métricas definidas anteriormente.

Ejemplo de Elastic AI Agent:

1. Implementa cambios en las descripciones de las herramientas de relevance_search y nl_search para definir claramente sus funciones y casos de uso específicos.

2. Predecimos que mejoraremos la precisión de invocación de nuestra herramienta en un 25%.

3. Verificaremos que esto sea un beneficio neto cerciorándonos de que no haya impacto negativo en otras métricas, por ejemplo, la certeza y la completitud.

4. Creemos que esto funcionará porque descripciones precisas de las herramientas ayudarán al agente a seleccionar y aplicar con mayor precisión la herramienta de búsqueda más adecuada para diferentes tipos de consulta, reduciendo la mala aplicación y mejorando la efectividad general de la búsqueda.

Paso 4: Preparar el conjunto de datos de evaluación

Para medir el rendimiento del sistema, empleamos conjuntos de datos que capturan escenarios del mundo real.

Dependiendo del tipo de evaluación que estemos realizando, puede que necesitemos diferentes tipos de formatos de datos, como datos en bruto que se alimentan a un LLM (por ejemplo, escenarios de ataque para Descubrimiento de Ataques) y resultados esperados. Si la aplicación es un chatbot, entonces las entradas pueden ser consultas del usuario, y las salidas pueden ser respuestas correctas del chatbot, enlaces correctos que debería recuperar, y así sucesivamente.

Ejemplo de Descubrimiento de Ataque:

10 escenarios de ataque novedosos

8 episodios de Oh My Malware (ohmymalware.com)

4 escenarios de múltiples ataques (creados combinando ataques en las dos primeras categorías)

3 escenarios benignos

Ejemplo de conjunto de datos de evaluación de agentes de Elastic AI (Enlace al conjunto de datos Kibana):

14 índices usando conjuntos de datos de código abierto para simular múltiples fuentes en la base de datos.

5 tipos de consulta (analítica, recuperación de texto, híbrida...)

7 Tipos de intención de consulta (procedimental, fáctica - clasificación, investigativa; ...)

Paso 5: Ejecutar el experimento

Ejecuta el experimento generando respuestas tanto del agente existente como de la versión modificada contra el conjunto de datos de evaluación. Calcula métricas como la factualidad (ver el paso 2).

Combinamos diversas evaluaciones basadas en las métricas requeridas en el Paso 2:

• Evaluación basada en reglas (por ejemplo, usar Python/TypeScript para comprobar si .json es válido)

• LLM-as-judge (preguntar a un LLM separado si una respuesta es factualmente coherente con un documento fuente)

• Revisión de Human in the Loop para controles de calidad de matices

Paso 6: Analizar resultados + iterar

Ahora que tenemos las métricas, analizamos los resultados. Incluso si los resultados cumplen los criterios de éxito definidos en el paso 3, seguiremos teniendo una revisión humana antes de fusionar el cambio con la producción; Si los resultados no cumplen los criterios, iterar y corregir los problemas, y luego ejecutar las evaluaciones sobre el nuevo cambio.

Esperamos que haga falta varias iteraciones para encontrar el mejor cambio antes de fusionar. De forma similar a ejecutar pruebas locales de software antes de enviar un commit, las evaluaciones offline pueden ejecutar con cambios locales o múltiples propuestas de cambios. Es útil automatizar el almacenado de resultados de experimentos, puntajes compuestos y visualizaciones para agilizar el análisis.

Paso 7: Toma una decisión y documenta

Basar en un marco de decisión y criterios de aceptación, decide fusionar el cambio y documenta el experimento. La toma de decisiones es multifacética y puede considerar factores más allá del conjunto de datos de evaluación, como comprobar escenarios de regresión en otros conjuntos de datos o valorar el costo-beneficio de un cambio propuesto.

Ejemplo: Tras probar y comparar varias iteraciones, elige el cambio con mejor puntaje para enviar a los responsables de producto y otros interesados relevantes para su aprobación. Anexa los resultados de los pasos anteriores para ayudar a guiar la decisión. Para más ejemplos en el área de Descubrimiento de Ataques, ver Detrás de las cámaras de las funciones de IA generativa de Elastic Security.

Conclusión

En este blog, repasamos el proceso integral de un flujo de trabajo experimental, ilustrando cómo evaluamos y probamos los cambios en un sistema agente antes de lanzarlos a los usuarios de Elastic. También proporcionamos algunos ejemplos de cómo mejorar los flujos de trabajo basados en agentes en Elastic. En próximas entradas del blog, ampliaremos los detalles de diferentes pasos, como cómo crear un buen conjunto de datos, cómo diseñar métricas fiables y cómo tomar decisiones cuando hay múltiples métricas de por medio.

Pero, ¿y si quieres usar tus agentes personalizados con las aplicaciones y herramientas de productividad de las que ya dependes?

Ahí es donde entra el protocolo Agent-a-Agente (A2A ). A2A es un estándar abierto de interoperabilidad, que permite a agentes de diferentes plataformas comunicar y colaborar. Y lo integramos directamente en el Elastic Agent Builder.

Hoy vamos a mostrarte cómo tomar un agente personalizado que creaste y exponerlo a otros servicios, concretamente Gemini Enterprise (antes Agentspace).

El poder de los estándares abiertos: por qué importa A2A

En la entrada del blog Tu primer agente Elastic, mostramos cómo crear agentes personalizados, como un agente de Asistente Financiero con acceso seguro a tus datos de mercado. Pero su valor es limitado si no puedes poner sus conocimientos a disposición en otros entornos, como Gemini Enterprise, sin reconstruir tu trabajo.

Este desafío de interoperabilidad es lo que frena la IA agente. Los agentes necesitan un lenguaje común para comunicar entre plataformas, que es precisamente el papel del protocolo A2A. Proporciona una capa estándar de comunicación que no solo te permite interactuar directamente con tu agente, sino que también abre un futuro donde agentes especializados de toda tu organización pueden colaborar y compartir conocimientos.

Para hacerlo posible, Elastic Agent Builder soporta nativamente el protocolo A2A a través de dos endpoints estándar para todos tus agentes:

1. El punto final de la Tarjeta Agente (GET {your-kibana-url}/api/agent_builder/a2a/{agentId}.json) - Esto actúa como la tarjeta de visita de tu agente personalizado. Proporciona metadatos sobre tu agente (nombre, descripción, capacidades, etc.) a cualquier servicio compatible con A2A.

2. El punto final del Protocolo A2A (POST {your-kibana-url}/api/agent_builder/a2a/{agentId}) - Este es el canal de comunicación. Otros agentes envían sus solicitudes aquí, y tu agente las procesa y responde, todo siguiendo la especificación del protocolo A2A.

Prueba a tu agente con el inspector A2A

Antes de conectar a nuestro agente a un sistema de producción, es bueno comprobar que se comunica correctamente. La forma más sencilla de hacerlo es con el Inspector A2A, una herramienta diseñada específicamente para probar y depurar integraciones A2A.

Poner en marcha al inspector es sencillo. Puedes clonar el repositorio a2a-inspector y seguir las instrucciones README para ejecutar la aplicación. Una vez iniciada, la interfaz está disponible por defecto en http://localhost:5001/.

Para conectar al Inspector A2A con tu agente, tendrás que proporcionar dos datos clave:

• URL de la tarjeta del agente: Este es el punto final que describe a tu agente. Para el agente de Asistente Financiero de nuestra publicación anterior, esta URL sería {your-kibana-url}/api/agent_builder/a2a/financial_assistant.json.

• Cabecera de autenticación: Emplearemos una clave API estándar para la autenticación.

Una vez introduzcas estos datos en la interfaz del inspector, puedes conectarte y empezar a hablar con tu agente inmediatamente.

Esta simple validación nos da la confianza de que nuestro agente está configurado correctamente y listo para el siguiente paso.

¡En directo! Tu agente personalizado en Gemini Enterprise

Ahora, la parte emocionante: dar vida a nuestro agente asesor financiero personalizado dentro de Gemini Enterprise (anteriormente Agentspace). Esta integración está impulsada por el Elastic AI Agent, que está disponible en Google Cloud Marketplace.

Una vez conectado, Gemini Enterprise emplea el protocolo A2A para comunicar directamente con tu agente. Aquí es donde brilla el verdadero poder de la interoperabilidad: los usuarios pueden acceder ahora a los insights profundos y basados en datos de tu agente personalizado de Elasticsearch sin salir nunca de su entorno habitual. Puedes ver tu Agente Elástico personalizado en la lista de agentes:

Imagina a un usuario en Gemini Enterprise preguntar:

"Me preocupa el sentimiento del mercado. ¿Puede mostrarme cuáles de nuestros clientes están más en riesgo por malas noticias?"

Entre bastidores, Gemini Enterprise enruta esta consulta a través del protocolo A2A a tu Agente Elastic personalizado. Tu agente emplea entonces sus herramientas especializadas para consultar tus datos, formular una respuesta y devolverla. Para el usuario final, la experiencia es fluida.

¡Y no se acaba aquí! La respuesta obtenida con el agente elástico ahora puede usar como contexto para tus próximas preguntas que pueden estar activando a otro agente especializado (por ejemplo, tu agente de la plataforma de inversiones para ajustar la exposición a compañías cotizadas). Todo sin salir de tu barra de búsqueda.

Con tus agentes Elastic desplegados en Gemini Enterprise con A2A, puedes unificar acceso, orquestación y flujos de trabajo eliminando fricciones entre IA, búsqueda y sistemas empresariales al ofrecer una única interfaz donde los usuarios se comunican con sus datos y herramientas, todo en contexto. Para los usuarios, eso significa menos cambios de herramienta y asistentes de IA más intuitivos y capaces. Para las organizaciones, significa una gobernanza coherente, escalabilidad e interoperabilidad integradas.

Te toca construir

Ahora tienes las herramientas para poner tus Agentes Elásticos disponibles en cualquier lugar. Aprovechando el protocolo abierto A2A, puedes ampliar el alcance de tus agentes personalizados y conscientes de los datos.

En esta publicación, te guiamos por los pasos clave:

• Exponer a tu agente a través de los endpoints de la tarjeta de agente A2A y el protocolo.

• Probando la conexión con el inspector A2A.

• Integrar a tu agente en directo en un servicio externo como Gemini Enterprise de Google.

Tus agentes ya no necesitan estar aislados. Estamos deseando ver los sistemas poderosos e interconectados que creáis. ¡Feliz construcción!

La forma más sencilla de empezar es con tu prueba gratis de Elastic Cloud en Google Cloud Marketplace

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!

Imagina a un gestor financiero que necesita poner al día antes de una reunión con un cliente. En lugar de buscar manualmente en los feeds de noticias y cruzar paneles de cartera, ahora pueden simplemente hacerle una pregunta directa a su agente personalizado. Esta es el beneficio de un enfoque de "charla primero". El responsable tiene una línea directa y conversacional con sus datos, preguntando cosas como: "¿Cuáles son las últimas noticias sobre ACME Corp y cómo afecta a las participaciones de mi cliente?" y obtener una respuesta experta y sintetizada en segundos.

Aunque hoy estamos formando un experto financiero, las aplicaciones son tan variadas como tus datos. El mismo poder puede crear un analista de ciberseguridad para buscar amenazas, un ingeniero de fiabilidad del sitio para diagnosticar una caída o un responsable de marketing para optimizar una campaña. Sea cual sea el ámbito, la misión principal es la misma: transformar tus datos en un especialista con el que puedas hablar.

Paso 0: Nuestro conjunto de datos

Nuestro set de datos actual es un set de datos sintético basado en finanzas que consta de cuentas financieras, posiciones de activos, noticias y reportes financieros. Aunque es sintético, replica una versión simplificada de un set de datos financieros real.

financial_accounts: Carteras de clientes con perfiles de riesgo

financial_holdings: Posiciones en acciones/ETF/bonos con historial de compras

financial_asset_details: Detalles sobre la acción/ETF/bono

financial_news: Artículos de mercado generados por IA con análisis de sentimiento

financial_reports: Notas de resultados y analistas de la compañía

Puedes cargar este conjunto de datos tú mismo siguiendo el cuaderno adjunto que se encuentra aquí.

Paso 1: La Fundación — Tu lógica empresarial como ES|QL

Cada habilidad de IA empieza con una buena lógica. Para nuestro agente de Gestor Financiero, tenemos que mostrarle cómo responder a una pregunta común: "Me preocupa el sentimiento del mercado. ¿Puede mostrarme cuáles de nuestros clientes están más en riesgo por malas noticias?" Esta pregunta va más allá de una simple búsqueda. Nos obliga a correlacionar el sentimiento del mercado con las carteras de clientes.

Necesitamos encontrar los activos mencionados en artículos negativos, identificar a cada cliente que posee esos activos, calcular el valor de mercado actual de su exposición y luego clasificar los resultados para priorizar el mayor riesgo. Este análisis complejo y multi-join es el trabajo perfecto para nuestro avanzado ES|Herramienta QL.

Aquí está la consulta completa que usaremos. Parece impresionante, pero los conceptos son sencillos.

Desglosándolo: uniones y barreras de seguridad

Hay dos conceptos importantes en juego en esta consulta que hacen que el Constructor de Agentes sea un

1. La unión LOOKUP

Durante años, una de las funciones más aplicar en Elasticsearch fue la capacidad de unir datos de diferentes índices basar en una clave común. Con ES|QL, eso ahora es posible con LOOKUP JOIN.

En nuestra nueva consulta, realizamos una cadena de tres LOOKUP JOIN: primero conectando noticias negativas con detalles de activos, luego vinculando esos activos con las tenencias del cliente y, finalmente, conectando con la información de la cuenta del cliente. Esto genera un resultado increíblemente rico a partir de cuatro índices diferentes en una sola consulta eficiente. Esto significa que podemos combinar conjuntos de datos dispares para crear una única respuesta perspicaz sin tener que desnormalizar todos nuestros datos en un único índice gigante previamente.

2. Parámetros como barreras de seguridad de los LLM

Verás que la consulta usa ?time_duration. Esto no es solo una variable; es una barrera de seguridad para la IA. Aunque los Grandes Modelos de Lenguaje (LLM) son excelentes generando consultas, dejarles tener libertad total sobre tus datos puede llevar a consultas ineficientes o incluso incorrectas.

Al crear una consulta parametrizada, obligamos al LLM a trabajar dentro de la lógica de negocio probada, eficiente y correcta que un experto humano ya definió. Es similar a cómo los desarrolladores usaron plantillas de búsqueda durante años para exponer de forma segura las capacidades de consulta a las aplicaciones. El agente puede interpretar la petición de un usuario como "esta semana" para completar el parámetro time_duration , pero debe usar nuestra estructura de consulta para obtener la respuesta. Esto nos da el equilibrio perfecto entre flexibilidad y control.

En última instancia, esta consulta permite a un experto que entiende los datos encapsular su conocimiento en una herramienta. Otras personas—y agentes de IA—pueden entonces usar esa herramienta para obtener resultados correlacionados simplemente proporcionando un único parámetro, sin necesidad de saber nada sobre la complejidad subyacente.

Paso 2: La habilidad — Convertir una consulta en una herramienta reutilizable

Un ES|La consulta QL es solo texto hasta que la registramos como herramienta. En el Constructor de Agentes, una herramienta es más que una consulta almacenada; es una "habilidad" que un agente de IA puede entender y elegir usar. La magia está en la descripción en lenguaje natural que proporcionamos. Esta descripción es el puente que conecta la pregunta del usuario con la lógica de consulta subyacente. Vamos a registrar la consulta que acabamos de crear.

La ruta de la interfaz

Crear una herramienta en Kibana es un proceso sencillo.

1. Navegar hacia los agentes

• Haz clic en Herramientas o Gestionar herramientas y haz clic en el botón Nueva herramienta .

2. Rellena el formulario con los siguientes detalles:

• ID de herramienta: find_client_exposure_to_negative_news

Yo. Este es el ID único de la herramienta

• Descripción: "Encuentra exposición a la cartera de clientes a noticias negativas. Esta herramienta escanea noticias y reportajes recientes en busca de sentimiento negativo, identifica el activo asociado y localiza a todos los clientes que lo poseen. Devuelve una lista ordenada según el valor de mercado actual de la posición para resaltar el mayor riesgo potencial."

Yo. Esto es lo que lee el LLM para decidir si esta herramienta es la adecuada para el trabajo.

• Etiquetas: retrieval y risk-analysis

Las etiquetas se emplean para ayudar a agrupar varias herramientas

• Configuración: Pega el ES| completoConsulta QL desde el Paso 1

Yo. Esta es la búsqueda que usará el agente

3. Haz clic en Inferir parámetros desde la consulta. La interfaz automáticamente lo encontrará ?time_duration lo listará a continuación. Agrega una descripción sencilla para cada uno para ayudar al agente (y a otros usuarios) a entender su propósito.

• time_duration: El plazo para buscar noticias negativas. El formato es "X horas" POR DEFECTO a 8760 horas

4. ¡Pruébalo!

• Haz clic en Almacenar y probar.

• Verás un nuevo flyout donde puedes probar la consulta para cerciorarte de que funciona como se espera.

Yo. En time_duration entrar en el rango deseado, aquí estamos usando "8760 horas"

• Haz clic en "Enviar" y si todo va bien, verás una respuesta en JSON. Para cerciorarte de que funciona como esperas, desplázate hacia abajo y mira el objeto values . Ahí es donde se devuelven los documentos realmente coincidentes.

5. Haz clic en la "X" en la esquina superior derecha para cerrar el desplegable de prueba. Tu nueva herramienta aparecerá ahora en la lista, lista para ser asignada a un agente.

La ruta API

Para desarrolladores que prefieren la automatización o necesitan gestionar herramientas programáticamente, puedes lograr el mismo resultado con una sola llamada a la API. Solo tienes que enviar una petición POST al endpoint /api/agent_builder/tools con la definición de la herramienta.

Paso 3: Las Mentes — Creando a tu Agente Personalizado

Creamos una habilidad reutilizable (la Herramienta). Ahora, necesitamos crear al Agente, la persona que realmente lo usará. Un Agente es la combinación de un LLM, un conjunto específico de herramientas a las que le concedes acceso y, lo más importante, un conjunto de Instrucciones Personalizadas que actúan como su constitución, definiendo su personalidad, reglas y propósito.

El arte del prompt

La parte más importante para crear un agente fiable y especializado es la rapidez. Un conjunto de instrucciones bien elaborado es la diferencia entre un chatbot genérico y un asistente profesional y enfocado. Aquí es donde pones las barreras de seguridad, defines la salida y le das al agente su misión.

Para nuestro agente de Financial Manager , usaremos el siguiente prompt.

Vamos a desglosar por qué este prompt es tan efectivo:

• Define una personalidad sofisticada: La primera línea establece inmediatamente al agente como un "asistente especializado en inteligencia de datos", estableciendo un tono profesional y capaz.

• Proporciona un marco de razonamiento: Al decirle al agente que "Comprenda, Planee, Ejecute y Sintetice", le estamos dando un procedimiento operativo estándar. Esto mejora su capacidad para manejar preguntas complejas y de varios pasos.

• Promueve el diálogo interactivo: La instrucción de "hacer preguntas aclaratorias" hace que el agente sea más robusto. Minimizará suposiciones incorrectas en solicitudes ambiguas, lo que conducirá a respuestas más precisas.

La ruta de la interfaz

1. Navega hacia los agentes.

• Haz clic en Herramientas o Gestionar herramientas y haz clic en el botón Nueva herramienta .

2. Rellena los datos básicos:

• ID del agente: financial_assistant.

• Instrucciones: Copia el prompt de arriba.

• Etiquetas: Finance.

• Nombre de visualización: Financial Assistant.

• Descripción de la pantalla: An assistant for analyzing and understanding your financial data.

3. Al principio, haz clic en Herramientas.

• Marca la casilla junto a nuestra herramienta de find_client_exposure_to_negative_news .

4. Haz clic en almacenar.

La ruta API

Puedes crear exactamente el mismo agente con una petición POST al endpoint /api/agent_builder/agents . El cuerpo de la solicitud contiene toda la misma información: el ID, el nombre, la descripción, el conjunto completo de instrucciones y una lista de herramientas que el agente puede emplear.

Paso 4: La recompensa — Mantener una conversación

Tenemos nuestra lógica de negocio encapsulada en una herramienta y un "cerebro" listo para usarla en nuestro Agente. Es hora de ver cómo todo encaja. Ahora podemos empezar a chatear con nuestros datos usando un agente especializado.

La ruta de la interfaz

1. Navega hacia Agentes en Kibana.

2. Usando el desplegable en la esquina inferior derecha de la ventana de chat, cambia del agente de IA de Elastic por defecto a nuestro recién creado agente de Asistente Financiero .

3. Haz una pregunta que permita al agente emplear nuestra herramienta especializada:

   1. Me preocupa el sentimiento del mercado. ¿Puede mostrarme cuáles de nuestros clientes están más en riesgo por malas noticias?

Tras unos momentos, el agente devolverá una respuesta perfectamente formateada y completa. Debido a la naturaleza de los LLM, tu respuesta puede estar formateada de forma ligeramente diferente, pero para esta ejecución, el agente devolvió:

¿Lo que acaba de pasar? El razonamiento del agente

El agente no solo "sabía" la respuesta. Ejecutó un plan de varios pasos centrado en seleccionar la mejor herramienta para el trabajo. Aquí tienes un vistazo a su proceso de pensamiento:

• Intención identificada: Relacionó palabras clave de tu pregunta, como "riesgo" y "noticias negativas", con la descripción de la herramienta find_client_exposure_to_negative_news .

• Ejecutó un plan: Extrajo el plazo de tu solicitud y realizó una única llamada a esa herramienta especializada.

• Delegado el trabajo: La herramienta realizaba entonces todo el trabajo pesado: las uniones encadenadas, los cálculos de valor y la clasificación.

• Sintetizamos el resultado: Finalmente, el agente formateaba los datos en bruto de la herramienta en un resumen claro y legible para humanos, siguiendo las reglas de su prompt.

Y no tenemos que adivinar si ampliamos el pensamiento y vemos más detalles.

La ruta API

Puedes iniciar esta misma conversación de forma programática. Solo tienes que enviar la pregunta de entrada al endpoint de la API de converse , cerciorándote de especificar el agent_id de nuestro financial_manager.

Para los desarrolladores: Integración con la API

Aunque la interfaz Kibana ofrece una experiencia fantástica e intuitiva para construir y gestionar tus agentes, todo lo que viste hoy también puede realizar de forma programática. El Constructor de Agentes está construido sobre un conjunto de APIs que te permiten integrar esta funcionalidad directamente en tus propias aplicaciones, canalizaciones CI/CD o scripts de automatización.

Los tres endpoints principales con los que trabajarás son:

• /api/agent_builder/tools: El punto final para crear, listar y gestionar las habilidades reutilizables que tus agentes pueden emplear.

• /api/agent_builder/agents: El punto final para definir las personas de tus agentes, incluyendo sus instrucciones y asignaciones de herramientas tan importantes.

• /api/agent_builder/converse: El punto final para interactuar con tus agentes, iniciar conversaciones y obtener respuestas.

Para una guía completa y práctica sobre cómo usar estas APIs para realizar cada paso de este tutorial, consulta el Jupyter Notebook que lo acompaña disponible aquí en nuestro repositorio de GitHub.

Conclusión: Tu turno de construir

Empezamos haciendo un ES|Consulta QL y transformarla en una habilidad reutilizable. Luego creamos un agente de IA especializado, dándole una misión y reglas claras, y lo empoderamos con esa habilidad. El resultado es un asistente sofisticado que puede entender una pregunta compleja y ejecutar un análisis en varios pasos para ofrecer una respuesta precisa y basada en datos.

Este flujo de trabajo está en el corazón del nuevo Constructor de Agentes en Elastic. Está diseñado para ser lo suficientemente sencillo para que usuarios no técnicos creen agentes a través de la interfaz, pero lo bastante matizado para que los desarrolladores puedan crear aplicaciones personalizadas impulsadas por IA sobre nuestras APIs. Lo más importante es que te permite conectar de forma segura y protegida los LLMs con tus propios datos, regidos por la lógica experta que defines, y chatear con tus datos.

¿Listo para usar Agentes para chatear con tus datos?

La mejor manera de consolidar lo que aprendiste es ensuciarte las manos. Prueba todo lo que comentamos hoy en nuestro taller práctico gratis e interactivo. Vas a pasar por todo este flujo y más en un entorno sandbox dedicado.

En un futuro blog, te mostraremos cómo usar una aplicación independiente que interactúa con nuestro agente Financial Assistant y nos adentraremos en el Protocolo de Contexto del Modelo (MCP) que lo hace todo posible. Y en un blog aparte hablaremos del soporte de Agent Builder para el protocolo en desarrollo Agent2Agent, o A2A.

¡Estad atentos y feliz construcción!

Constructor de Agentes: Una base para construir agentes de IA basados en datos

La promesa de un agente de IA es sencilla: dale un objetivo y cumple su función. Pero para los promotores, la realidad es un serial de desafíos complejos. Primero, un agente solo es tan bueno como su percepción de su entorno y las herramientas que se le proporcionan para alcanzar los objetivos del usuario. Entonces, ofrecer el contexto adecuado a partir de un mar de datos empresariales diversos es un reto enorme. Por último, todo esto debe estar orquestado por un bucle de razonamiento fiable que pueda planear, ejecutar y aprender.

Para solucionar esto, los desarrolladores necesitan construir una pila compleja y frágil desde cero. La arquitectura actual de agentes requiere que unas múltiples piezas dispares: un LLM, una base de datos vectorial, un almacén de metadatos, sistemas separados para registro y trazado, y alguna forma de evaluar si todo funciona siquiera. Esto no es solo complejo; es costosa, propensa a errores y dificulta la construcción de los sistemas de IA de alta calidad y fiables que tus usuarios exigen.

Así que queremos hacerlo más sencillo. Para ello, nuestro enfoque es tomar las piezas esenciales de un agente eficaz basado en el contexto e integrarlas directamente en el núcleo de Elasticsearch con un nuevo conjunto de capacidades llamado Elastic AI Agent Builder. Esta nueva capa proporciona un marco con todos los bloques esenciales para crear Agentes de IA impulsados por Elasticsearch: un conjunto abierto de primitivas, protocolos basados en estándares y acceso seguro a los datos, para que puedas construir sistemas agenticos adaptados a datos y requisitos del mundo real:

Ofrecer experiencias de IA: este es el objetivo final. Con nuestra Plataforma de IA de Búsqueda y tus datos como base, puedes construir cualquier tipo de aplicación de IA generativa: desde interfaces de chat personalizadas hasta integraciones con frameworks de agentes como LangChain o aplicaciones empresariales como Salesforce.

Impulsado por Agentes y Herramientas: sobre la plataforma, exponemos una capa limpia y sencilla de abstracciones. Interactúas directamente con los Agentes y Herramientas, que puedes personalizar para adaptarlos a tus necesidades específicas. También puedes acceder a las capacidades de la plataforma a través de APIs robustas y estándares abiertos como MCP y A2A.

Habilitado por la Plataforma de IA de Búsqueda: este es el motor central donde integramos los componentes. La avanzada base de datos vectorial, la lógica del agente, la construcción de consultas, las características de seguridad, el rastreo para evaluación, todo está aquí, gestionado y optimizado por Elastic.

Desbloquear el poder de tus datos: la base de cualquier gran agente son los grandes datos. Nuestra plataforma comienza con la capacidad de ingerir o federar el acceso a todos los datos de tu compañía

Edificio de agentes en la plataforma

Agent Builder, integrado en la plataforma Search AI, proporciona un marco completo para el desarrollo de agentes. Se basa en cinco pilares clave, cada uno diseñado para abordar un aspecto crítico de la construcción y despliegue de sistemas de IA de grado de producción. Desglosemos cómo los agentes definen el objetivo, las herramientas proporcionan las capacidades, los estándares abiertos garantizan la interoperabilidad, la evaluación aporta transparencia y la seguridad proporciona la confianza.

Agentes

Los agentes son el bloque de construcción de más alto nivel en esta nueva capa de Elasticsearch. Un agente define el objetivo a alcanzar, el conjunto de herramientas disponibles para su ejecución y las fuentes de datos sobre las que puede operar. Los agentes no se limitan a interacciones conversacionales; Pueden impulsar flujos de trabajo completos, automatización de tareas o experiencias orientadas al usuario.

Cuando una consulta se dirige a un agente, sigue un ciclo estructurado:

1. Interpreta tu aportación y objetivo

2. Seleccionar la herramienta y los argumentos adecuados para la ejecución

3. Razón sobre la respuesta de la herramienta

4. Decide si devolver un resultado o continuar con más invocaciones de herramientas

Elastic se encarga de la orquestación, el contexto y la ejecución de este ciclo. Los desarrolladores se centran en definir qué debe hacer el agente: objetivos, herramientas y datos, mientras que el sistema gestiona cómo se llevan a cabo el razonamiento y los flujos de trabajo.

El agente por defecto

Nuestro primer agente construido sobre esta plataforma es un agente conversacional nativo en Kibana, que te da la capacidad de interactuar inmediatamente con tus datos. Proporciona una experiencia lista para usar, sin perder la extensión completa, y permite empezar a interactuar con tus datos de inmediato, sin configuraciones adicionales.

Puedes interactuar con esta experiencia directamente en Kibana a través de una nueva experiencia de chat o a través de API.

Consultar el agente por defecto a través de la API requiere solo una llamada:

Como las conversaciones son con estado, puedes seguir interactuando con un agente usando un conversation_id , o recuperar el historial completo de la conversación:

Agentes de Aduanas

Los desarrolladores también pueden crear sus propios agentes personalizados mediante APIs sencillas. Los agentes encapsulan instrucciones, herramientas y acceso a datos, creando motores de razonamiento personalizados.

Crear un agente personalizado es tan sencillo como hacer una sola llamada a la API. El ejemplo siguiente muestra un ejemplo: el campo "configuración" contiene todos los detalles clave, como instrucciones o herramientas disponibles:

Una vez creado, el agente puede ser consultado directamente:

Este enfoque transforma al agente de un sistema complejo para construir desde cero en una unidad simple y declarativa de lógica de negocio, permitiéndote ofrecer automatización inteligente más rápido.

Para una visión profunda de cómo construir un agente especializado desde cero, consulta nuestra guía detallada paso a paso: Tu primer agente elástico: de una sola consulta a un chat impulsado por IA.

Herramientas

Si los agentes definen qué lograr, las herramientas definen cómo.

Las herramientas exponen capacidades específicas del núcleo Elastic para que los agentes ejecuten y recuperen información o realicen una acción. Las herramientas pueden incluir capacidades clave como obtener índices, obtener mapeos, o capacidades más avanzadas como lenguaje natural a ES|QL.

Elasticsearch viene con un conjunto de herramientas predeterminadas optimizadas para necesidades comunes. Pero la verdadera flexibilidad viene de crear el tuyo propio. Al definir herramientas, decides exactamente qué consultas, índices y campos están expuestos a un agente con ES|QL, que te da un control preciso sobre la velocidad, la precisión y la seguridad.

Registrar una nueva herramienta también es tan sencillo como una sola llamada a la API. Podrías crear una herramienta que aproveche nuestro ES|QL (Elasticsearch Query Language) para encontrar noticias sobre un activo financiero específico:

Una vez registrado, puedes asignar la nueva herramienta a tus agentes personalizados, dándoles un conjunto seleccionado de habilidades para razonar e invocar cuando sea lo adecuado.

Ofrecemos una plataforma para crear herramientas personalizadas según tus necesidades específicas, por ejemplo, con ES|QL que transforma al agente de un agente de propósito general a un experto específico de un dominio, basado en tus datos únicos y en el dominio de negocio.

Estándares abiertos e interoperabilidad

Los Agentes y Herramientas de Elasticsearch se exponen mediante APIs estándar abiertos, lo que facilita su integración como bloques fundamentales dentro del ecosistema más amplio de marcos agenticos. Nuestro enfoque es sencillo: nada de cajas negras. Queremos que seas capaz de tomar la fuerza central de Elastic en busca y combinarla con capacidades complementarias y otros sistemas agentes.

Para hacerlo posible, estamos exponiendo nuestras capacidades a través de APIs, protocolos emergentes y estándares abiertos.

Protocolo de Contexto de Modelo (MCP)

El Protocolo de Contexto de Modelo (MCP) se está convirtiendo rápidamente en el estándar abierto para conectar herramientas entre sistemas. Al soportar MCP, Elasticsearch puede conectar IA conversacional con tus bases de datos, índices y APIs externas. Con un servidor MCP remoto integrado en Elastic Stack, cualquier cliente compatible con MCP puede acceder a las herramientas de Elastic y usarlas como bloques de construcción en tus flujos de trabajo agenticos más amplios.

Esto no es una calle de sentido único. También podrás importar herramientas desde servidores MCP externos y ponerlas a disposición dentro de Elasticsearch. Pronto, los servidores MCP probablemente estarán disponibles para casi todo y serán mucho más completos que cualquier cosa que crearíamos nosotros mismos. Elastic ofrece búsqueda y recuperación a gran escala, y puedes combinarlo con capacidades especializadas de otras plataformas para crear agentes efectivos.

Agente a Agente (A2A)

También estamos trabajando en el soporte Agent-to-Agent (A2A). Mientras que MCP trata de conectar herramientas, A2A trata de conectar agentes. Con un servidor A2A, los agentes Elastic que construyas podrán comunicar directamente con agentes de otros sistemas: compartiendo contexto, delegando tareas y coordinando flujos de trabajo.

Piénsalo como interoperabilidad en la capa de razonamiento. Tu agente de Elastic podría encargar de la búsqueda y recuperación, luego delegar una tarea a un soporte especializado o a un agente de TI, y obtener el resultado sin problemas. El resultado es un ecosistema de agentes cooperantes, cada uno haciendo lo que mejor sabe hacer.

En última instancia, la adopción de MCP y A2A refuerza nuestro compromiso con el papel de Elasticsearch como ciudadano de primera clase, cerciorando una integración abierta en todo el ecosistema agente más amplio.

Rastreo y evaluación

A medida que la búsqueda se integra con los agentes, el desafío de una evaluación efectiva se vuelve crítico. Para desplegar agentes con confianza en entornos empresariales reales, necesitas la seguridad de que no solo son precisos, sino también eficientes y fiables. ¿Cómo mides el rendimiento, diagnosticas una mala respuesta o mejoras la línea base? Todo empieza por la visibilidad.

Por eso diseñamos nuestras APIs de agentes para que sean transparentes desde cero. Considera esta simple interacción con el agente:

La respuesta incluye no solo la respuesta final, sino la traza completa de ejecución, detallando qué herramientas seleccionó el agente, los parámetros que empleó y los resultados de cada paso.

Un rastreo y registro exhaustivos son esenciales para un bucle de mejora continua, y pronto podrás almacenar y ver estos rastros de agentes directamente en Elasticsearch. Mejor aún, estas trazas están construidas sobre el protocolo OpenTelemetry, lo que garantiza que estén estandarizadas y sean portátiles para su integración con la plataforma de observabilidad que elija.

Este nivel de detalle es la base de un verdadero bucle de mejora continua. Te permite construir un conjunto completo de pruebas, depurar fallos, identificar modos de fallo para evitar regresiones y capturar patrones exitosos para afinar el rendimiento. En última instancia, este enfoque basado en datos es la clave para transformar un prototipo prometedor en un sistema de IA fiable y de calidad de producción.

Seguridad

A medida que los agentes y herramientas se vuelven más capaces, la seguridad no es opcional, es fundamental. Exponer APIs, automatizar tareas y flujos de trabajo requiere que los sistemas empresariales sean de confianza. Especialmente a medida que los Agentes empiezan a automatizar más flujos de trabajo, la capacidad de protegerlos y cerciorar de que cumplen con los requisitos empresariales es esencial.

Las capacidades, por encima de todo, heredan los controles ya disponibles en Elastic hoy en día, incluyendo el control de acceso basado en roles (RBAC) para llamadas API y gestión de claves API. También estamos extendiendo los mismos controles a nuevos protocolos como MCP. Eso significa soporte para estándares como OAuth, así como la capacidad de conectar mecanismos de autenticación personalizados.

Nuestro objetivo es ofrecerte la flexibilidad para experimentar con agentes y herramientas, manteniendo al mismo tiempo el nivel de seguridad, cumplimiento y gobernanza que exige tu organización.

Lo que viene después

No solo estamos agregando funcionalidades; estamos ampliando Elasticsearch para la ingeniería de contexto agentica. Planeamos desarrollar en el futuro basándonos en estos principios:

1. Compromiso con el código abierto y los estándares

Nuestro compromiso con el código abierto y los estándares abiertos garantiza que estas capacidades sigan siendo interoperables con los marcos agentes externos. Siempre podrás conectar, ampliar y componer agentes en todo tu ecosistema, manteniendo tus datos y flujos de trabajo bajo tu control.

2. Valor del contexto

El contexto de un agente de IA es su mayor activo. Gestionar el contexto mientras los agentes realizan búsquedas y operaciones de flujo de trabajo puede ser una tarea desafiante. Estamos aprovechando las fortalezas principales de Elastic para resolver la ingeniería de contexto, cerciorando que la información más relevante esté siempre disponible para tu agente.

3. Enfoque en flujos de datos agentes

De ahora en adelante, los agentes serán una fuente cada vez mayor de datos, incluyendo la salida de los agentes (documentos generados, reportes, visualizaciones) y el rastro de ejecución de los agentes (su razonamiento, llamadas a herramientas, memoria/contexto). Elastic es muy adecuado para manejar este tipo de datos, y estamos trabajando en investigaciones relacionadas con la realización de análisis, evaluación y mejora automatizada empleando estos datos.

4. Seguridad y Protección desde el Diseño

Los agentes de IA introducen un conjunto completamente nuevo de desafíos de seguridad y protección. Elastic siempre fue líder en soluciones seguras, y seguimos incorporando barreras de seguridad de nivel empresarial, controles de acceso y principios de "confianza cero".

5. Integrado en la plataforma

Las capacidades para construir agentes de IA están integradas en la plataforma Elasticsearch. Esto significa que capacidades a nivel de plataforma como el trazo, la evaluación, la visualización y el análisis son todas aplicables a los agentes. Quiero desarrollar paneles basados en la ejecución de agentes, eso está incorporado. Quiero evaluar el rendimiento del agente de IA usando análisis de sentimiento? La plataforma lo permite. Esto te permite construir un ciclo de vida completo alrededor de tus experiencias con IA.

El objetivo de Elastic es proporcionarte las interfaces para construir IA conversacional y flujos de trabajo automatizados que estén totalmente integrados, sean extensibles y estén basados en tus datos. Pronto se compartirán más detalles técnicos y avances.

Agent Builder ya está disponible en vista previa privada. Contáctate con nosotros para aplicar acceso. ¿Tienes preguntas u opiniones? Conéctate con nuestra comunidad de desarrolladores en nuestro espacio de trabajo de Slack o en nuestro foro de discusión.

En esta entrada, exploraremos cómo construir un asistente RAG agente usando Mastra y una aplicación sitio web ligero en JavaScript para interactuar con él. Al conectar este agente con Elasticsearch, le damos acceso a datos estructurados de jugadores y la capacidad de ejecutar agregaciones estadísticas en tiempo real, para ofrecerte recomendaciones basadas en estadísticas de jugadores. Visita el repositorio de GitHub para seguirle; el README proporciona instrucciones sobre cómo clonar y ejecutar la aplicación por tu cuenta.

Así debería ver cuando todo esté montado:

Nota: Esta entrada del blog se basa en "Construcción de agentes de IA con SDK de IA y Elastic". Si eres nuevo en los agentes de IA en general y en qué podrían servir, empieza por ahí.

Visión general de la arquitectura

En el núcleo del sistema se encuentra un gran modelo de lenguaje (LLM), que actúa como motor de razonamiento del agente (el cerebro). Interpreta la entrada del usuario, decide qué herramientas llamar y orquesta los pasos necesarios para generar una respuesta relevante.

El propio agente está estructurado por Mastra, un framework de agentes dentro del ecosistema JavaScript. Mastra envuelve el LLM con infraestructura backend, lo expone como un endpoint API y proporciona una interfaz para definir herramientas, indicaciones del sistema y comportamiento de agentes.

En el frontend, usamos Vite para andamiar rápidamente una aplicación sitio web React que proporciona una interfaz de chat para enviar consultas al agente y recibir sus respuestas.

Por último, tenemos Elasticsearch, que almacena estadísticas de jugadores y datos de emparejamientos que el agente puede consultar y agregar.

Fondo

Vamos a repasar algunos conceptos fundamentales:

¿Qué es el RAG agente?

Los agentes de IA pueden interactuar con otros sistemas, operar de forma independiente y realizar acciones basadas en sus parámetros definidos. El RAG agente combina la autonomía de un agente de IA con los principios de generación aumentada por recuperación, permitiendo a un LLM elegir qué herramientas llamar y qué datos usar como contexto para generar una respuesta. Lee más sobre RAG aquí.

Elegir un framework, ¿por qué ir más allá del SDK de IA?

Hay muchos frameworks de agentes de IA disponibles y probablemente oíste hablar de los más populares como CrewAI, AutoGen y LangGraph. La mayoría de estos frameworks comparten un conjunto común de funcionalidades, incluyendo soporte para diferentes modelos, uso de herramientas y gestión de memoria.

Aquí tienes una hoja comparativa de marcos de Harrison Chase (CEO de LangChain).

Lo que despertó mi interés con Mastra es que es un framework JavaScript-first diseñado para que desarrolladores full-stack integren fácilmente agentes en su ecosistema. El AI-SDK de Vercel también hace la mayoría de esto, pero donde Mastra destaca es cuando tus proyectos incluyen flujos de trabajo de agentes más complejos. Mastra mejora los patrones base establecido por el AI-SDK y en este proyecto los usaremos conjuntamente.

Marcos y consideraciones sobre la elección del modelo

Aunque estos frameworks pueden ayudarte a construir agentes de IA rápidamente, existen algunos inconvenientes a tener en cuenta. Por ejemplo, al usar cualquier otro framework fuera de agentes de IA o cualquier capa de abstracción en general, pierdes un poco de control. Si el LLM no emplea correctamente las herramientas o hace algo que no quieres, la abstracción dificulta la depuración. Aun así, en mi opinión, este equilibrio merece la facilidad y rapidez que obtienes al construir, especialmente porque estos frameworks están ganando impulso y se iteran constantemente.

De nuevo, estos frameworks son independientes de los modelos, lo que significa que puedes conectar y jugar diferentes modelos; recuerda que los modelos varían en los conjuntos de datos con los que fueron capacitados y, a su vez, varían en las respuestas que dan. Algunos modelos ni siquiera soportan la llamada de herramientas. Así que es posible cambiar y probar diferentes modelos para ver cuál te da las mejores respuestas, pero ten en cuenta que probablemente tendrás que reescribir el prompt del sistema para cada uno. Por ejemplo, usando Llama3.3 en comparación con GPT-4o, implica mucho más indicación e instrucciones específicas para obtener la respuesta que buscas.

Baloncesto de fantasía de la NBA

El baloncesto de fantasía consiste en empezar una liga con un grupo de colegas (advertencia, dependiendo de lo competitivo que sea tu grupo, esto podría afectar al estado de tus amistades), normalmente con algo de dinero en juego. Cada uno de vosotros selecciona un equipo de 10 jugadores para competir contra los 10 jugadores de otro amigo alternando semanalmente. Los puntos que contribuyen a tu puntaje global son cómo se desempeña cada uno de tus jugadores contra sus oponentes en una semana determinada.

Si un jugador de tu equipo se lesiona, es suspendido, etc., hay una lista de jugadores agentes libres disponibles para agregar a tu equipo. Aquí es donde ocurre gran parte de la dificultad en los deportes de fantasía, porque solo tienes un número limitado de fichas y todos están constantemente a la caza del mejor jugador.

Aquí es donde nuestro asistente de IA de la NBA brillará, especialmente en situaciones en las que tienes que decidir rápidamente qué jugador elegir. En lugar de tener que buscar manualmente cómo rinde un jugador contra un oponente específico, el asistente puede encontrar esos datos rápidamente y comparar promedios para darte una recomendación informada.

Ahora que ya sabes lo básico sobre el RAG agente y el baloncesto fantasy de la NBA, vamos a verlo en la práctica.

Construcción del proyecto

Si te quedas atascado en algún momento o no quieres montarlo desde cero, por favor consulta el repositorio.

Lo que vamos a cubrir

1. Andamiaje del proyecto:

   1. Backend (Mastra): Usa NPX Create mastra@latest para andamiar el backend y definir la lógica del agente.

   2. Frontend (Vite + React): Usa npm create vite@latest para construir la interfaz de chat del frontend y así interactuar con el agente.

2. Configuración de variables de entorno

   1. Instala dotenv para gestionar las variables del entorno.

   2. Crea un .env archiva y proporciona las variables requeridas.

3. Configuración de Elasticsearch

   1. Crea un clúster de Elasticsearch (ya sea localmente o en la nube).

   2. Instala el cliente oficial de Elasticsearch.

   3. Cerciórate de que las variables del entorno sean accesibles.

   4. Establece conexión con el cliente.

4. Ingiriendo en masa datos de la NBA en Elasticsearch

   1. Crea un índice con los mapeos apropiados para permitir agregaciones.

   2. Ingirir en masa las estadísticas de los jugadores de un archivo CSV en un índice de Elasticsearch.

5. Definir agregaciones de Elasticsearch

   1. Consulta para calcular promedios históricos contra un oponente específico.

   2. Consulta para calcular los promedios de temporada contra un rival específico.

6. Archivo utilitario de comparación de jugadores

   1. Consolida funciones auxiliares y agregaciones de Elasticsearch.

7. Construcción del agente

   1. Agrega la definición del agente y el prompt del sistema.

   2. Instala Zod y define herramientas.

   3. Agregar una configuración de middleware para manejar CORS.

8. Integración del frontend

   1. Usando el useChat de AI-SDK para interactuar con el agente.

   2. Crea la interfaz para mantener conversaciones bien formateadas.

9. Ejecutando la aplicación

   1. Inicia tanto el backend (servidor Mestra) como el frontend (app React).

   2. Ejemplos de consultas y uso.

10. Qué sigue: Hacer que el agente sea más inteligente

    1. Agregar capacidades de búsqueda semántica para permitir recomendaciones más profundas.

    2. Habilitar la consulta dinámica moviendo la lógica de búsqueda al servidor Elasticsearch MCP (Model Context Protocol).

Prerrequisitos

• Node.js y NPM: Tanto el backend como el frontend funcionan en Node. Cerciórate de tener instalados Node 18+ y npm v9+ (que vienen incluidos con Node 18+).

• Clúster de Elasticsearch: Un clúster activo de Elasticsearch, ya sea localmente o en la nube.

• Clave API de OpenAI: Genera una en la página de claves API del portal para desarrolladores de OpenAI.

Estructura del proyecto

Paso 1: Estructurar el proyecto

1. Primero, crea el directorio nba-ai-assistant-js y navega dentro usando:

Backend:

1. Usa la herramienta de creación de Mastra con el comando:

2. Deberías recibir algunos prompts en tu terminal; para el primero, llamaremos al backend del proyecto:

3. A continuación, mantendremos la estructura predeterminada para almacenar los archivos Mastra, así que introduzca src/.

4. Luego, elegiremos OpenAI como nuestro proveedor de LLM por defecto.

5. Finalmente, te pedirá la clave de la API de OpenAI. Por ahora, elegiremos la opción de saltarlo y proporcionarlo más adelante en un archivo .env .

Frontend:

1. Vuelve al directorio raíz y ejecuta la herramienta de creación de Vite usando este comando: npm create vite@latest frontend -- --template react

Esto debería crear una aplicación ligera de React llamada frontend con una plantilla específica para React.

Si todo va bien, dentro de tu directorio de proyecto, deberías estar mirando un directorio backend que contenga el código Mastra y un directorio frontend con tu app React.

Paso 2: Configuración de variables de entorno

1. Para gestionar claves sensibles, usaremos el paquete dotenv para cargar nuestras variables de entorno desde el .env archivo. Navega al directorio del backend e instala dotenv:

2. Mientras está en el directorio backend, se proporciona un archivo example.env con las variables adecuadas para rellenar. Si creas el tuyo propio, cerciórate de incluir las siguientes variables:

Nota: Cerciórate de que este archivo esté excluido de tu control de versiones agregando .env a .gitignore.

Paso 3: Configuración de Elasticsearch

Primero, necesitas un clúster activo de Elasticsearch. Hay dos opciones:

• Opción A: Usar Elasticsearch Cloud

  • Apúntate a Elastic Cloud

  • Crear un nuevo despliegue

  • Obtén la URL de tu endpoint y la clave API (codificada)

• Opción B: Ejecutar Elasticsearch localmente

  • Instala y ejecuta Elasticsearch localmente

  • Usa http://localhost:9200 como punto final

  • Generar una clave API

Instalación del cliente Elasticsearch en el backend:

1. Primero, instala el cliente oficial de Elasticsearch en tu directorio backend:

2. Luego crea una lib de directorios para almacenar funciones reutilizables y navega hacia ella:

3. Dentro, crea un nuevo archivo llamado elasticClient.js. Este archivo inicializará el cliente Elasticsearch y lo expondrá para su uso en todo tu proyecto.

4. Como usamos módulos ECMAScript (ESM), __dirname and __nombre de archivo no están disponibles. Para cerciorarte de que tus variables de entorno se carguen correctamente desde el archivo .env Archivo en la carpeta de backend, agrega esta configuración en la parte superior de tu archivo:

5. Ahora, inicializa el cliente Elasticsearch usando tus variables de entorno y comprueba la conexión:

Ahora, podemos importar esta instancia cliente a cualquier archivo que necesite interactuar con tu clúster de Elasticsearch.

Paso 4: Ingirir en masa datos de la NBA en Elasticsearch

Conjunto de datos:

Para este proyecto, consultaremos los conjuntos de datos disponibles en el directorio de backend/datos del repositorio. Nuestro asistente de la NBA empleará estos datos como base de conocimiento para realizar comparaciones estadísticas y generar recomendaciones.

• sample_player_game_stats.csv - Estadísticas de juego de un jugador (por ejemplo, puntos, rebotes, robos, etc., por partido por jugador a lo largo de toda su carrera en la NBA). Emplearemos este conjunto de datos para realizar agregaciones. (Nota: Estos son datos simulados, pregenerados para fines demo y no provenientes de fuentes oficiales de la NBA.)

• playerAndTeamInfo.js - Sustituye los metadatos de jugadores y equipos que normalmente proporcionaría una llamada a la API para que el agente pueda relacionar los nombres de jugadores y equipos con IDs. Como usamos datos de muestra, no queremos la sobrecarga de buscar desde una API externa, así que codificamos de forma fija algunos valores que el agente puede referenciar.

Implementación:

1. Mientras estés en el directorio backend/lib , crea un archivo llamado playerDataIngestion.js.

2. Configura las importaciones, resuelve la ruta del archivo CSV y configura el análisis sintáctico. De nuevo, como estamos usando ESM, necesitamos reconstruir __dirname para resolver el camino hacia el CSV de muestra. Además, importaremos Node.js módulos incorporados, fs y readline, para analizar el archivo CSV dado línea por línea.

Esto te prepara para leer y analizar eficientemente el CSV cuando lleguemos al paso de la ingestión masiva.

3. Crear un índice con el mapeo adecuado. Aunque Elasticsearch puede inferir automáticamente los tipos de campos con mapeo dinámico, queremos ser explícitos aquí para que cada estadística se trate como un campo numérico. Esto es importante porque usaremos estos campos para agregaciones más adelante. También queremos usar el tipo float para estadísticas como puntos, rebotes, etc., para cerciorarnos de incluir valores decimales. Finalmente, queremos agregar la propiedad de mapeo dynamic: 'strict' para que Elasticsearch no mapee dinámicamente campos no reconocidos. 

4. Agregar la función para ingirte en masa los datos CSV en tu índice de Elasticsearch. Dentro del bloque de código, saltamos la línea de cabecera. Luego, divide cada elemento de línea por una coma y empújalos en el objeto documento. Este paso también los limpia y cerciora que sean del tipo adecuado. A continuación, enviamos los documentos al array bulkBody junto con la información del índice, que servirá como carga útil para la ingestión masiva en Elasticsearch.

5. Luego, podemos usar la API Bulk de Elasticsearch con elasticClient.bulk() para ingirse varios documentos en una sola solicitud. La gestión de errores a continuación está estructurada para darte un recuento de cuántos documentos no se ingirieron y cuántos fueron exitosos.

6. Ejecuta la función main() a continuación para ejecutar secuencialmente las funciones createIndex() y bulkIngestCsv() .

Si ves un registro de consola que indique que la ingesta masiva fue exitosa, realiza una comprobación rápida en tu índice de Elasticsearch para ver si los documentos realmente se ingirieron con éxito.

Paso 5: Definición de agregaciones de Elasticsearch y consolidación

Estas serán las funciones principales que se emplearán cuando definamos las herramientas para el Agente de IA para comparar las estadísticas de los jugadores entre sí.

1. Navega al directorio backend/lib y crea un archivo llamado elasticAggs.js.

2. Agregar la consulta siguiente para calcular los promedios históricos de un jugador frente a un oponente específico. Esta consulta emplea un filtro bool con 2 condiciones: una que coincide con player_id y otra que coincide con la opponent_team_id, para recuperar solo los juegos relevantes. No necesitamos devolver ningún documento, solo nos importan las agregaciones, así que establecemos size:0. Bajo el bloque aggs , ejecutamos múltiples agregaciones métricas en paralelo en campos como points, rebounds, assists, steals, blocks y fg_percentage para calcular sus valores medios. Los LLMs pueden ser impredecibles con los cálculos y esto transfiere ese proceso a Elasticsearch, cerciorando que nuestro asistente de IA de la NBA tenga acceso a datos precisos.

3. Para calcular los promedios de temporada de un jugador frente a un oponente específico, usaremos prácticamente la misma consulta que la histórica. La única diferencia en esta consulta es que el filtro bool tiene una condición adicional para game_date. El game_date del campo tiene que estar dentro del rango de la temporada actual de la NBA. En este caso, el rango está entre 2024-10-01 y 2025-06-30. Esta condición adicional a continuación garantiza que las agregaciones que sigan aislarán solo los partidos de esta temporada.

Paso 6: Utilidad de comparación de jugadores

Para mantener nuestro código modular y mantenible, crearemos un archivo de utilidad que consolide las funciones auxiliares de metadatos y las agregaciones de Elasticsearch. Esto alimentará la herramienta principal que emplea el agente. Más sobre eso más adelante:

1. Crear un nuevo archivo comparePlayers.js en el directorio backend/lib .

2. Agregar la función siguiente para consolidar los asistentes de metadatos y la lógica de agregación de Elasticsearch en una única función que alimente la herramienta principal empleada por el agente.

Paso 7: Construir el agente

Ahora que creaste el frontend y el backend de estructura, absorbiste datos de los partidos de la NBA y establecido una conexión con Elasticsearch, podemos empezar a juntar todas las piezas para construir el agente.

Definición del agente

1. Navega al archivo index.ts dentro del directorio backend/src/mastra/agents y agrega la definición del agente. Puedes especificar campos como:

• Nombre: Dale a tu agente un nombre que se use como referencia cuando te llamen en el frontend.

• Instrucciones/prompt del sistema: Un prompt del sistema proporciona al LLM el contexto inicial y las reglas a seguir durante la interacción. Es similar al prompt que los usuarios envían a través del cuadro de chat, pero este se da antes de cualquier entrada del usuario. De nuevo, esto cambiará según el modelo que elijas.

• Modelo: ¿Qué LLM usar (Mastra soporta OpenAI, Anthropic, modelos locales, etc.).

• Herramientas: Una lista de funciones de la herramienta que el agente puede llamar.

• Memoria: (Opcional) si queremos que el agente recuerde el historial de conversaciones, etc. Para simplificar, podemos empezar sin memoria persistente, aunque Mastra la admite.

Definición de herramientas

1. Navega al archivo index.ts dentro del directorio backend/src/mastra/tools .

2. Instala Zod usando el comando:

3. Agregar definiciones de herramientas. Ten en cuenta que importamos la función dentro del archivo comparePlayers.js como la función principal que el agente usará al llamar a esta herramienta. Usando la función createTool() de Mastra, registraremos nuestro playerComparisonTool. Los campos incluyen:

• id: Esta es una descripción en lenguaje natural para ayudar al agente a entender qué hace la herramienta.

• input schema: Para definir la forma de la entrada de la herramienta, Mastra emplea el esquema Zod , que es una biblioteca de validación de esquema TypeScript. Zod ayuda cerciorar de que el agente reciba entradas estructuradas correctamente y evita que la herramienta se ejecute si la estructura de entrada no coincide.

• description: Esta es una descripción en lenguaje natural para ayudar al agente a entender cuándo llamar y usar la herramienta.

• execute: La lógica que se ejecuta cuando se llama a la herramienta. En nuestro caso, estamos usando una función auxiliar importada para devolver estadísticas de rendimiento.

Adición de middleware para manejar CORS

Agregar middleware en el servidor Mastra para manejar CORS. Dicen que hay tres cosas en la vida que no puedes evitar: la muerte, los impuestos, y para los desarrolladores web es el CORS. En resumen, el Intercambio de Recursos entre Orígenes es una función de seguridad en el navegador que bloquea al frontend para que no haga peticiones a un backend que se ejecuta en otro dominio o puerto. Aunque ejecutamos tanto el backend como el frontend en localhost, usan puertos diferentes, lo que activa la política CORS. Necesitamos agregar el middleware especificado en la documentación de Mastra para que nuestro backend permita esas peticiones desde el frontend.

1. Navega al archivo index.ts dentro del directorio backend/src/mastra y agrega la configuración para CORS:

• origin: ['http://localhost:5173']

  • Permite solicitudes solo desde esta dirección (dirección predeterminada de Vite)

• allowMethods: ["GET", "POST"]

  • Métodos HTTP que están permitidos. La mayoría de las veces, será usando POST.

• allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],

  • Estos deciden qué encabezados personalizados pueden usar en las solicitudes

Paso 8: Integración del frontend

Este componente React proporciona una interfaz de chat sencilla que se conecta al agente Mastra AI usando el gancho useChat() de @ai-sdk/react. También vamos a usar este gancho para mostrar el uso de tokens, llamadas a herramientas y para renderizar la conversación. En el prompt del sistema anterior, también pedimos al agente que genere la respuesta en markdown, así que usaremos react-markdown para formatear correctamente la respuesta.

1. Mientras estés en el directorio frontend, instala el paquete @ai-sdk/react para usar el hook useChat().

2. Mientras estés en el mismo directorio, instala React Markdown para que podamos formatear correctamente la respuesta que genera el agente.

3. Implementar useChat(). Este gancho gestionará la interacción entre tu frontend y el backend de tu agente de IA. Gestiona el estado del mensaje, la entrada del usuario, el estado y te proporciona ganchos de ciclo de vida para fines de observabilidad. Las opciones que descartamos incluyen:

• api: Esto define el punto final de tu Mastra AI Agent. Por defecto se pone en el puerto 4111 y también queremos agregar la ruta que soporta respuestas en streaming.

• onToolCall: Esto se ejecuta cada vez que el agente llama a una herramienta; Lo estamos usando para rastrear qué herramientas está llamando nuestro agente.

• onFinish: Esto se ejecuta después de que el agente complete una respuesta completa. Aunque activamos el streaming, onFinish seguirá ejecutar luego de recibir el mensaje completo y no luego de cada chunk. Aquí, lo estamos usando para rastrear nuestro uso de tokens. Esto puede ser útil para monitorizar los costos de los LLM y optimizarlos.

4. Por último, ve al componente ChatUI.jsx en el directorio frontend/components para crear la interfaz que mantenga nuestra conversación. A continuación, envuelve la respuesta en un componente ReactMarkdown para formatear correctamente la respuesta del agente.

Paso 9: Ejecutar la aplicación

¡Felicidades! Ahora estás listo para ejecutar la aplicación. Sigue estos pasos para empezar tanto el backend como el frontend.

1. En una ventana de terminal, empezando desde el directorio raíz, navega hasta el directorio backend e inicia el servidor Mestra:

2. En otra ventana de terminal, empezando desde el directorio raíz, navega hasta el directorio frontend e inicia la aplicación React:

3. Ve a tu navegador y navega a:

http://localhost:5173

Deberías poder ver la interfaz del chat. Prueba estos ejemplos de prompts:

• "Compara a LeBron James y Stephen Curry"

• "¿A quién debería elegir entre Jayson Tatum y Luka Doncic?"

Qué sigue: Hacer que el agente sea más inteligente

Para que el asistente sea más agenciado y las recomendaciones más perspicaces, agregaré algunas mejoras clave en la próxima iteración.

Búsqueda semántica de noticias de la NBA

Hay un montón de factores que pueden afectar al rendimiento de los jugadores, muchos de los cuales no aparecen en las estadísticas brutas. Cosas como reportes de lesiones, cambios en la alineación o incluso análisis postpartido, solo se pueden encontrar en artículos de prensa. Para captar este contexto adicional, agregaré capacidades de búsqueda semántica para que el agente pueda recuperar artículos relevantes de la NBA e incluir esa narrativa en sus recomendaciones.

Búsqueda dinámica con el servidor MCP de Elasticsearch

MCP (Model Context Protocol) se está convirtiendo rápidamente en el estándar para cómo los agentes se conectan a fuentes de datos. Migraré la lógica de búsqueda al servidor Elasticsearch MCP, que permite al agente construir consultas dinámicamente en lugar de depender de funciones de búsqueda predefinidas que proporcionamos. Esto nos permite emplear más flujos de trabajo en lenguaje natural y reduce la necesidad de escribir manualmente cada consulta de búsqueda. Descubre más sobre el servidor MCP de Elasticsearch y el estado actual del ecosistema aquí.

Estos cambios ya están en marcha, ¡estad atentos!

Conclusión

En este blog, creamos un asistente RAG agente que ofrece recomendaciones personalizadas para tu equipo de baloncesto de fantasía usando JavaScript, Mastra y Elasticsearch. Cubrimos lo siguiente:

• Fundamentos del RAG agente y cómo combinar la autonomía de un agente de IA con las herramientas para usar RAG de forma eficaz puede conducir a agentes más matizados y dinámicos.

• Elasticsearch y cómo sus capacidades de almacenamiento de datos y poderosas agregaciones nativas lo convierten en un gran socio como base de conocimiento para un LLM.

• El framework Mastra y cómo simplifica la construcción de estos agentes para desarrolladores en el ecosistema javaScript.

Tanto si eres un fanático del baloncesto, explorando cómo crear agentes de IA, o ambos como yo, espero que este blog te dio algunos cimientos para empezar. El repositorio completo está disponible en GitHub, siéntete libre de clonar y trastear. ¡Ahora, gana esa liga de fantasía!

Model Context Protocol (MCP) lo hace posible. Conecta a la perfección la IA conversacional con sus bases de datos y API externas, transformando solicitudes complejas en conversaciones naturales. Si bien los LLM modernos son excelentes para comprender el lenguaje, su verdadero potencial se desbloquea cuando se integran con sistemas del mundo real. MCP cierra la brecha entre ellos, haciendo que la interacción de datos sea más intuitiva y eficiente.

En esta publicación, exploraremos:

• Arquitectura MCP: cómo funciona bajo el capó

• Beneficios de un servidor MCP conectado a Elasticsearch

• Creación de un servidor MCP con tecnología de Elasticsearch

¡Se avecinan tiempos emocionantes! La integración de MCP con tu Elastic stack transforma la forma en que interactúas con la información, haciendo que las consultas complejas sean tan intuitivas como la conversación diaria.

Protocolo de contexto del modelo

Model Context Protocol (MCP), desarrollado por Anthropic, es un estándar abierto que conecta modelos de IA con fuentes de datos externas a través de canales seguros y bidireccionales. Resuelve una limitación importante de la IA: el acceso en tiempo real a sistemas externos mientras se preserva el contexto de la conversación.

Arquitectura del MCP

La arquitectura del protocolo de contexto del modelo consta de dos componentes clave:

• Clientes MCP : asistentes de IA y chatbots que aplicar información o ejecutan tareas en nombre de los usuarios.

• Servidores MCP : repositorios de datos, motores de búsqueda y API que recuperan información relevante o realizan acciones aplicar (por ejemplo, llamar a API externas).

Los servidores MCP exponen cuatro capacidades principales a los clientes:

• Recursos : datos estructurados, documentos y contenido que se pueden recuperar y emplear como contexto para las interacciones de LLM. Esto permite a los asistentes de IA acceder a información relevante de bases de datos, índices de búsqueda u otras fuentes.

• Herramientas : funciones ejecutables que permiten a los LLM interactuar con sistemas externos, realizar cálculos o realizar acciones en el mundo real. Estas herramientas amplían las capacidades de IA más allá de la generación de texto, lo que permite a los asistentes activar flujos de trabajo, llamar a API o manipular datos dinámicamente.

• Solicitudes : plantillas de solicitudes y flujos de trabajo reutilizables para estandarizar y compartir interacciones comunes de LLM.

• Ejemplificación : aplicar finalizaciones de LLM a través del cliente para habilitar comportamientos sofisticados de agentes mientras mantiene la seguridad y la privacidad.

Servidor MCP + Elasticsearch

Los sistemas tradicionales de generación aumentada de recuperación (RAG) recuperan documentos en función de las consultas de los usuarios, pero MCP va un paso más allá: permite a los agentes de IA construir y ejecutar tareas dinámicamente en tiempo real. Esto permite a los usuarios hacer preguntas en lenguaje natural como:

• "Muéstrame todos los pedidos superiores a $ 500 del mes pasado".

• "¿Qué productos recibieron la mayor cantidad de reseñas de 5 estrellas?"

Y obtén respuestas instantáneas y precisas, sin escribir una sola consulta.

MCP logra esto a través de:

• Selección dinámica de herramientas: los agentes eligen de manera inteligente las herramientas correctas expuestas a través de los servidores MCP en función de la intención del usuario. Los LLM "más inteligentes" son generalmente mejores para seleccionar las herramientas adecuadas con los argumentos apropiados basados en el contexto.

• Comunicación bidireccional: los agentes y las fuentes de datos intercambian información de manera fluida, refinando las consultas según sea necesario (p. ej. mapeo de índice de búsqueda primero, solo luego construya la consulta ES).

• Orquestación de múltiples herramientas: los flujos de trabajo pueden aprovechar las herramientas de varios servidores MCP simultáneamente.

• Contexto persistente: los agentes recuerdan interacciones anteriores, manteniendo la continuidad en todas las conversaciones.

Un servidor MCP conectado a Elasticsearch desbloquea una poderosa arquitectura de recuperación en tiempo real. Los agentes de IA pueden explorar, consultar y analizar datos de Elasticsearch bajo demanda. Sus datos se pueden buscar a través de una interfaz de chat simple.

Más allá de la simple recuperación de datos, MCP permite la acción. Se integra con otras herramientas para activar flujos de trabajo, automatizar procesos y aportar información a los sistemas de análisis. Al separar la búsqueda de la ejecución, MCP mantiene las aplicaciones impulsadas por IA flexibles, actualizadas y perfectamente integradas en los flujos de trabajo de los agentes.

Manos a la obra: servidor MCP para chatear con tus datos de Elasticsearch

Para interactuar con Elasticsearch a través de un servidor MCP, necesitamos al menos funciones para:

• Recuperar índices

• Obtener asignaciones

• Realiza búsquedas con Query DSL de Elasticsearch

Nuestro servidor está escrito en TypeScript y usaremos el SDK oficial de MCP TypeScript. Para la configuración, recomendamos instalar la aplicación de escritorio Claude (la versión gratis es suficiente) ya que incluye un cliente MCP incorporado. Nuestro servidor MCP esencialmente expone el cliente oficial de JavaScript Elasticsearch a través de herramientas MCP.

Comencemos definiendo el cliente de Elasticsearch y el servidor MCP:

Usaremos las siguientes herramientas de servidor MCP que pueden interactuar con Elasticsearch:

• List Indices (list_indices): Esta herramienta recupera todos los índices de Elasticsearch disponibles, proporcionando detalles como el nombre del índice, el estado de salud y el recuento de documentos.

• Obtener asignaciones (get_mappings): esta herramienta obtiene las asignaciones de campos para un índice de Elasticsearch específico, lo que ayuda a los usuarios a comprender la estructura y los tipos de datos de los documentos almacenados.

• Búsqueda (search): esta herramienta ejecuta una búsqueda de Elasticsearch mediante un DSL de consulta proporcionado. Habilita automáticamente los resaltados para los campos de texto, lo que facilita la identificación de resultados de búsqueda relevantes.

La implementación completa del servidor MCP de Elasticsearch está disponible en el repositorio elastic/mcp-server-elasticsearch .

Chatea con tu índice

Exploremos cómo configurar el servidor MCP de Elasticsearch para que puedas hacer preguntas en lenguaje natural sobre tus datos, como "Encuentra todos los pedidos superiores a $500 del mes pasado".

Configure su aplicación de escritorio Claude

• Abra la aplicación de escritorio de Claude

• Vaya a Configuración > Servidores MCP para desarrolladores >

• Haga clic en "Editar configuración" y agregue esta configuración a su claude_desktop_config.json:

Nota: Esta configuración emplea el paquete npm @elastic/mcp-server-elasticsearch publicado por Elastic. Si deseas desarrollar localmente, puedes encontrar más detalles sobre cómo activar el servidor MCP de Elasticsearch aquí.

Rellenar el índice de Elasticseach

• Puede usar nuestros datos de ejemplo para completar el índice de "pedidos" para esta demostración

• Esto le permitirá probar consultas como "Buscar todos los pedidos superiores a $ 500 del mes pasado"

Empieza a usarlo

• Abrir una nueva conversación en la aplicación de escritorio de Claude

• El servidor MCP se conectará automáticamente

• ¡Comienza a hacer preguntas sobre tus datos de Elasticsearch!

Mira esta demostración para ver lo fácil que es consultar tus datos de Elasticsearch usando lenguaje natural:

¿Cómo funciona?

Cuando se le pregunta "Buscar todos los pedidos superiores a $ 500 del mes pasado", el LLM reconoce la intención de buscar en el índice de Elasticsearch con restricciones específicas. Para realizar una búsqueda efectiva, el agente calcula:

• Averigüe el nombre del índice: orders

• Comprender las asignaciones de orders índice

• Construir el DSL de consulta compatible con asignaciones de índice y finalmente ejecutar la solicitud de búsqueda

Esta interacción se puede representar como:

Conclusión

Model Context Protocol mejora la forma en que interactúas con los datos de Elasticsearch, lo que permite conversaciones en lenguaje natural en lugar de consultas complejas. Al unir las capacidades de IA con sus datos, MCP crea un flujo de trabajo más intuitivo y eficiente que mantiene el contexto a lo largo de sus interacciones.

El servidor MCP de Elasticsearch está disponible como un paquete npm público (@elastic/mcp-server-elasticsearch), lo que facilita la integración para los desarrolladores. Con una configuración mínima, su equipo puede comenzar a explorar datos, activar flujos de trabajo y obtener información a través de conversaciones simples.

¿Listo para experimentarlo por ti mismo? Prueba el servidor MCP de Elasticsearch hoy mismo y comienza a chatear con tus datos.

1. Clona el repositorio: Descarga el código de la herramienta desde GitHub usando git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent ay navega por el directorio con cd serverless-ai-agent.

2. Configurar el entorno: Crea un entorno virtual (opcional) con python -m venv venv y actívalo (source venv/bin/activate o venv\Scripts\activate en Windows). Luego, instala los paquetes Python necesarios usando pip install -r requirements.txt.

3. Configurar credenciales: Crea un archivo .env en la raíz del proyecto y replétalo con la URL de la API de Elasticsearch (ES_URL), clave API (API_KEY), región (REGION) y clave API de OpenAI (OPENAI_API_KEY).

4. Ejecuta la herramienta: Ejecuta la herramienta ejecutando python main.py en tu terminal. Esto iniciará al agente de IA y mostrará un prompt para tus comandos.

5. Gestionar proyectos con lenguaje natural: Interactúa con la herramienta usando comandos en inglés sencillo como "Crea un proyecto serverless llamado my\_project", "Get the status of the serverless project named my\_project" o "Delete the serverless project named my\_project". La IA interpretará tus comandos y ejecutará las funciones correspondientes.

Fondo

Esta pequeña herramienta de línea de comandos te permite gestionar tus proyectos de Serverless Elasticsearch en un inglés sencillo. Habla con una IA (en este caso, OpenAI) para averiguar a qué te refieres y llamar a las funciones correctas usando LlamaIndex.

¿Qué puede hacer el agente de IA serverless de Elasticsearch?

• Crea un proyecto: Pone en marcha un nuevo proyecto Serverless Elasticsearch.

• Eliminar un proyecto: Elimina un proyecto existente (sí, limpia luego de ti).

• Consulta el estado del proyecto: Comprueba cómo va tu proyecto.

• Obtén detalles del proyecto: Recoge todos los detalles jugosos sobre tu proyecto.

Consulta el código en GitHub.

Cómo funciona el agente de IA Serverless de Elasticsearch

Cuando escribes algo como:

"Crea un proyecto serverless llamado my_project"

… Esto es lo que ocurre entre bastidores:

• Entrada y contexto del usuario: Tu comando en lenguaje natural se envía al agente de IA.

• Descripciones de funciones: El agente de IA ya conoce algunas funciones —como create_ess_project, delete_ess_project, get_ess_project_status y get_ess_project_details— porque le dimos descripciones detalladas. Estas descripciones indican a la IA qué hace cada función y qué parámetros necesitan.

• Procesamiento de LLM: Tu consulta junto con la información de la función se envía al LLM. Esto significa que la IA ve:

  • La consulta del usuario: Tu instrucción en inglés sencillo.

  • Funciones y descripciones disponibles: Detalles sobre lo que hace cada herramienta para poder elegir la adecuada.

  • Contexto/información histórica del chat: Como es una conversación, recuerda lo que se dijo antes.

• Llamada y respuesta de función: La IA decide qué función llamar, pasa los parámetros correctos (como el nombre de tu proyecto) y luego la función se ejecuta. La respuesta se te envía de vuelta en un formato amigable.

En resumen, enviamos tanto tu consulta en lenguaje natural como una lista de descripciones detalladas de herramientas al LLM para que pueda "entender" y elegir la acción adecuada para tu solicitud.

Configurar el agente de IA

Prerrequisitos:

Antes de ejecutar el agente de IA, cerciórate de tener configurado lo siguiente:

1. Python (v3.7 o posterior) instalado.

2. Cuenta serverless de Elasticsearch configurada en Elastic Cloud.

3. Cuenta OpenAI para interactuar con el modelo de lenguaje.

Pasos:

1. Clonar el repositorio:

2. Crear un entorno virtual (opcional pero recomendado): Si tienes problemas relacionados con el entorno, puedes configurar un entorno virtual para aislamiento:

3. Instalar las dependencias: Cerciorar de que todas las dependencias necesarias se instalen ejecutando:

4. Configura tu entorno: Crea un .env archiva en la raíz del proyecto con las siguientes variables. Aquí tienes un ejemplo .env.example archivo para ayudarte:

Cerciórate de tener los valores correctos para ES_URL, API_KEYy OPENAI_API_KEY. Puedes encontrar tus claves API en los paneles de servicio correspondientes.

5. Archivo de proyectos: La herramienta emplea un archivo projects.json para almacenar los mapeos de tus proyectos (nombres de proyectos con sus detalles). Este archivo se creará automáticamente si no existe ya.

Ejecutando el agente de IA

Verás un prompt como este:

Escribe tu comando y el agente de IA hará su magia. Cuando termines, escribe exit o quit para irte.

Unos pocos detalles más

• Integración con LLM: El LLM recibe tanto tu consulta como descripciones detalladas de cada función disponible. Esto lo ayuda a entender el contexto y decidir, por ejemplo, si llamar a create_ess_project o delete_ess_project.

• Descripciones de herramientas: Cada herramienta funcional (creada usando FunctionTool.from_defaults) tiene una descripción amistosa. Esta descripción se incluye en el prompt enviado al LLM para que "sepa" qué acciones están disponibles y qué espera cada acción.

• Persistencia: Tus proyectos y sus detalles se almacenan en projects.json, Así que no tienes que volver a introducir información cada vez.

• Registro verboso: El agente está configurado en modo verboso, lo cual es genial para depurar y ver cómo se traducen tus instrucciones en llamadas a funciones.

Ejemplo de utilización de agentes de Elasticsearch AI