Jeff Vestal - Elasticsearch Labs

Rapidez vs. precisión: medición de recuperación de la búsqueda vectorial cuantificada

Jeff Vestal — Fri, 20 Mar 2026 00:00:00 GMT

Todos quieren que la búsqueda de vectores sea instantánea. Pero los vectores de alta dimensión son pesados. Un único vector float-32 de 1024 dimensiones ocupa una memoria significativa, y compararlo con millones de otros es computacionalmente costoso.

Para resolver esto, los motores de búsqueda como Elasticsearch usan dos estrategias principales de optimización:

Búsqueda aproximada (mundo pequeño jerárquico navegable [HNSW]): en lugar de examinar cada documento, construimos un grafo de navegación para saltar rápidamente al vecindario probable de la respuesta.
Cuantización: Comprimimos los vectores (por ejemplo, de flotantes de 32 bits a enteros de 8 bits o incluso valores binarios de 1 bit) para reducir el uso de memoria y acelerar los cálculos.

Pero la optimización a menudo tiene un precio: la precisión.

El miedo es válido: "Si comprimo mis datos y tomo atajos durante la búsqueda, ¿me perderé los mejores resultados?". "¿Esta optimización degrada la relevancia de mi motor de búsqueda?".

Para demostrar que la cuantificación de Elastic no degrada los resultados, construimos un marco de pruebas repetible mediante el conjunto de datos de DBPedia-14 para calcular exactamente cuánta precisión intercambiamos (específicamente, la recuperación) por velocidad al usar las optimizaciones predeterminadas en Elasticsearch.

Resumen: es probable que sea mucho menos de lo que piensas. Echa un vistazo al cuaderno aquí e inténtalo por tu cuenta

Las definiciones (para los no expertos)

Antes de ver el código, establezcamos algunos términos.

Relevancia versus recuperación: La relevancia es subjetiva (¿encontré cosas buenas?). La recuperación es matemática. Si hay 10 documentos en la base de datos que son las coincidencias matemáticas perfectas para tu consulta, y el motor de búsqueda encuentra nueve de ellos, tu recuperación es del 90 % (o 0,9).
Búsqueda exacta (plana): A veces denominado el método de "fuerza bruta". El motor de búsqueda analiza cada uno de los documentos de un índice y calcula la distancia.
- Pros: 100 % de recuperación perfecta.
- Contras: computacionalmente caro y lento en escala.
Búsqueda aproximada (HNSW): El método del "atajo". El motor de búsqueda crea un grafo HNSW. Recorre el grafo para encontrar a los vecinos más cercanos.
- Ventajas: extremadamente rápido y escalable.
- Desventajas: podrías perderte algún vecino si el recorrido del grafo se detiene demasiado pronto.

El experimento: exactitud versus aproximación

Para probar la recuperación, usamos el conjunto de datos DBPedia-14, un gran set de datos de títulos y resúmenes de 14 clases de ontología que normalmente se utilizan para entrenar y evaluar modelos de categorización de texto. En concreto, nos centraremos en la categoría de "Cine". Queríamos comparar los ajustes de producción optimizados con una verdad de base matemáticamente perfecta.

Para este experimento, utilizamos el modelo jina-embeddings-v5-text-small, un modelo multilingüe de última generación que lidera los estándares de la industria para la representación de texto. Elegimos este modelo porque define el estándar actual para embeddings de alto rendimiento. Al combinar la precisión de élite de Jina v5 con la cuantización nativa de Elasticsearch, podemos demostrar una arquitectura de búsqueda que es tanto computacionalmente eficiente como intransigente en la calidad de la recuperación.

Configuramos un índice con un mapeo doble. Ingerimos el mismo texto en dos campos diferentes de forma simultánea:

content.rawcon el tipo: flat. Esto obliga a Elasticsearch a realizar un escaneo por fuerza bruta de los vectores Float32 completos. Esto devuelve resultados de coincidencia exacta y se utilizará para nuestra línea de base.
contentcon tipo semantic_text. Con valores predeterminados que utilizan HNSW + la mejor cuantificación binaria (BBQ). Esta es la configuración de producción estándar y optimizada para una coincidencia aproximada.

La prueba de recall@10

Para nuestra métrica, usamos Recall@10.

Elegimos 50 películas aleatorias y ejecutamos la misma consulta en ambos campos.

Si la búsqueda exacta (plana) indica que los 10 vecinos más cercanos son los ID [1, 2, 3... 10].
Y la búsqueda aproximada (HNSW) devuelve los ID [1, 2, 3... 9, 99].
Encontramos nueve de los 10 principales correctamente. La puntuación es 0,9.

Este es el mapeo que utilizamos:

# The "Control Group": Forces exact brute-force scan "raw": { "type": "semantic_text", "inference_id": ".jina-embeddings-v5-text-small", "index_options": { "dense_vector": { "type": "flat" } } }

Los resultados: la "línea plana" del éxito

Realizamos una prueba de escala, recargando el conjunto de datos completo y probando con tamaños de índice de entre 1000 y 40 000 documentos.

Esto es lo que sucedió con la puntuación de recuperación:

Documentos

Puntuación de recall@10

1000

1000 (100 %)

5000

0,998 (100 %)

10,000

0,992 (99,4 %)

20 000

0,999 (99,0 %)

40 000

0,992 (98,8 %)

Los resultados fueron increíblemente estables. Incluso a medida que escalábamos, la búsqueda aproximada coincidió con la búsqueda exacta de fuerza bruta >99 % del tiempo.

¿Por qué funcionó tan bien?

Podrías esperar que comprimir vectores a valores binarios perjudicaría más la precisión. La razón por la que esto no ocurre está en la forma en que Elasticsearch gestiona la recuperación.

La mayoría de los modelos de incrustación actuales dan como salida vectores Float32, que son grandes. Para hacer la búsqueda eficiente, Elasticsearch emplea cuantización para vectores de alta dimensión. Concretamente, desde la versión 9.2, usa BBQ por defecto.

BBQ usa un mecanismo de recalificación:

Recorrido: el motor de búsqueda utiliza los vectores comprimidos (cuantificados) para recorrer rápidamente el grafo HNSW. Como los vectores son pequeños, puedes realizar un sobremuestreo de manera eficiente, recopilando una lista más amplia de candidatos (por ejemplo, los 100 documentos más parecidos) sin que afecte al rendimiento.
Recálculo de la puntuación: una vez que obtiene esos candidatos, recupera los valores de precisión completa solo para esos pocos documentos para calcular la clasificación final y precisa.

Esto te brinda lo mejor de ambos mundos, la velocidad de la cuantización para el trabajo pesado y la precisión de los flotantes para la ordenación final.

¿Podemos hacerlo mejor?

Cabe destacar que los resultados que vemos aquí utilizan la configuración predeterminada y una muestra aleatoria de datos. Piensa en esto como un punto de partida de alto rendimiento. Aunque Jina v5 es una bestia, estas puntuaciones de recuperación no son una garantía de "talla única" para todos los conjuntos de datos. Cada conjunto de datos tiene sus propias peculiaridades, y aunque sin duda puedes seguir ajustando los parámetros para obtener un mejor rendimiento, siempre debes realizar pruebas con tus propios datos específicos para ver cuál es tu límite.

Conclusión

Esta es una prueba a muy pequeña escala. Pero el punto del ejercicio no es medir el modelo de incrustación o BBQ específicamente, sino demostrar cómo puedes medir fácilmente la recuperación de tu conjunto de datos con una configuración mínima.

Si quieres ejecutar esta prueba con tus propios datos, puedes consultar el cuaderno aquí e intentarlo por tu cuenta.

Tu primer Agente Elastic: De una sola consulta a un chat impulsado por IA

Jeff Vestal — Thu, 25 Sep 2025 00:00:00 GMT

Con el nuevo Agent Builder de Elastic, puedes crear agentes de IA especializados que actúen como expertos para tus dominios de negocio específicos. Esta función te lleva más allá de simples paneles de control y barras de búsqueda, transformando tus datos de un recurso pasivo en un interlocutor activo y conversacional.

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.

POST kbn://api/agent_builder/tools { "id": "find_client_exposure_to_negative_news", "type": "esql", "description": "Finds client portfolio exposure to negative news. This tool scans recent news and reports for negative sentiment, identifies the associated asset, and finds all clients holding that asset. It returns a list sorted by the current market value of the position to highlight the highest potential risk.", "configuration": { "query": """ FROM financial_news, financial_reports METADATA _index | WHERE sentiment == "negative" | WHERE coalesce(published_date, report_date) >= NOW() - TO_TIMEDURATION(?time_duration) | RENAME primary_symbol AS symbol | LOOKUP JOIN financial_asset_details ON symbol | LOOKUP JOIN financial_holdings ON symbol | LOOKUP JOIN financial_accounts ON account_id | WHERE account_holder_name IS NOT NULL | EVAL position_current_value = quantity * current_price.price | RENAME title AS news_title | KEEP account_holder_name, symbol, asset_name, news_title, sentiment, position_current_value, quantity, current_price.price, published_date, report_date | SORT position_current_value DESC | LIMIT 50 """, "params": { "time_duration": { "type": "keyword", "description": """The timeframe to search back for negative news. Format is "X hours" DEFAULT TO 8760 hours """ } } }, "tags": [ "retrieval", "risk-analysis" ] }

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.

You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.**

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.

POST kbn://api/agent_builder/agents { "id": "financial_assistant", "name": "Financial Assistant", "description": "An assistant for analyzing and understanding your financial data", "labels": [ "Finance" ], "avatar_color": "#16C5C0", "avatar_symbol": "💰", "configuration": { "instructions": """You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.** """, "tools": [ { "tool_ids": [ "platform.core.search", "platform.core.list_indices", "platform.core.get_index_mapping", "platform.core.get_document_by_id", "find_client_exposure_to_negative_news" ] } ] } }

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

Navega hacia Agentes en Kibana.
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 .
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.

POST kbn://api/agent_builder/converse { "input": "Show me our largest positions affected by negative news", "agent_id": "financial_assistant" }

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!