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

Un motor, todos los casos de uso vectoriales

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Incrustaciones en inferencia por GPU administrada

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

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

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

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

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

Empresarial desde el primer día

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

Accesible a escala y predecible

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

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

Crea un proyecto serverless de base de datos vectorial

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

Crea un índice usando semantic_text

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

Ingestar documentos

Indexa texto y las incrustaciones se generan para ti.

Ejecuta una consulta de búsqueda semántica

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

Y recibes los resultados:

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

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

Ya estamos trabajando en las próximas mejoras:

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

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

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

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

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

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

Elastic Cloud Serverless ya elimina los dolores de cabeza de administrar la infraestructura y las actualizaciones de versiones. CPS lleva eso un paso más allá. Hemos reemplazado el peering de red complejo y la gestión manual de certificados con un modelo de vinculación simple. Ahora puedes tratar tus proyectos Elastic Cloud Serverless como simples espacios de nombres para tus datos. Ya sea que tengas que cumplir con estrictas leyes de residencia de datos, aislar los datos de los usuarios o simplemente evitar los altos costos de tráfico saliente que genera la duplicación de logs, CPS te permite buscar tus datos exactamente donde se encuentran con una sola consulta.

En esta publicación, explicaremos cómo funciona CPS, cómo controlar las búsquedas mediante etiquetas de proyecto y en qué se diferencia este nuevo modelo de la búsqueda entre clústeres tradicional (CCS).

Cómo vincular proyectos para la búsqueda entre proyectos

Para empezar a usar la búsqueda entre proyectos, vincula los proyectos en la consola de Elastic Cloud o mediante la API. La vinculación es simple y unidireccional: eliges un proyecto de origen y luego conectas los proyectos en los que debería buscar. Esos enlaces pueden abarcar distintas regiones, proveedores cloud y tipos de proyectos, por lo que tus datos pueden permanecer donde deben estar sin que por ello renuncies a una experiencia de búsqueda unificada.

Una vez creado el enlace, suele estar vigente en un minuto, aproximadamente. Si ya tienes Kibana abierto, actualiza para ver las nuevas capacidades de búsqueda entre proyectos.

Cómo la búsqueda entre proyectos consulta todos los proyectos vinculados en forma predeterminada

Una vez vinculados los proyectos, la búsqueda entre proyectos convierte los proyectos independientes en una única superficie de búsqueda lógica. Si tus logs están en varios proyectos, una búsqueda como FROM logs* busca en el proyecto de origen y en cualquier proyecto vinculado que tenga datos coincidentes. No es necesario nombrar cada objetivo remoto por adelantado.

Eso es una gran mejora con respecto a la búsqueda entre clústeres. En CCS, llegar a datos locales y remotos suele indicar que hay que escribir algo así como FROM logs*,*:logs*. Para los usuarios, eso significa menos complejidad de búsqueda. Para los equipos, esto nos acerca a una verdadera vista unificada de los datos distribuidos.

Para obtener más información sobre este tema, consulta los documentos del modelo de búsqueda CPS.

Si te interesa conocer los detalles técnicos sobre cómo lo creamos, consulta Cómo funciona la búsqueda entre proyectos (CPS) en Elasticsearch Serverless.

Control de búsquedas mediante el enrutamiento de proyectos

La búsqueda en todos los proyectos vinculados de forma predeterminada es conveniente y útil para muchos flujos de trabajo, pero no todas las búsquedas deben ir a todas partes. La búsqueda entre proyectos presenta el enrutamiento de proyectos, una forma de limitar una búsqueda a un subconjunto específico de proyectos.

Funciona mediante etiquetas de proyecto definidas en Elastic Cloud. Cada proyecto tiene atributos integrados como su alias, el proveedor cloud y la región. También puedes agregar tus propias etiquetas para reflejar cómo tu organización piensa sobre su patrimonio, como environment:prod, environment:test, una unidad de negocio o el nombre de un cliente. Entonces, Elasticsearch puede usar esos metadatos para decidir qué proyectos vinculados deben participar en una búsqueda.

Todos los endpoints de Elasticsearch que admiten la búsqueda entre proyectos aceptan un parámetro project_routing . En la versión preliminar técnica, el enrutamiento se limita al uso de alias de proyecto. Por ejemplo, configurar project_routing en _alias:my-linked-project envía la búsqueda solo a ese proyecto vinculado, mientras que _alias:_origin mantiene la búsqueda en el proyecto de origen. Con el tiempo, este modelo abre la puerta a un enrutamiento mucho más completo, en el que el alcance de la búsqueda puede seguir la estructura lógica de tu organización, en lugar de la disposición física de tu infraestructura.

Consulta los documentos de enrutamiento del proyecto para ver ejemplos y más detalles sobre cómo funcionan.

Enrutamiento de proyecto predeterminado a nivel del espacio de Kibana

Por ejemplo, si necesitas más precisión en la configuración de tus rutas de búsqueda, buscar en todos los proyectos vinculados podría generar una avalancha de falsos positivos en tus reglas de Kibana o resultados confusos en tus dashboards actuales. Para solucionar esto, puedes establecer un alcance de proyecto predeterminado a nivel de espacio en Kibana. Esto actúa como un preset seguro para ese espacio específico, lo que significa que todos los dashboards, las sesiones de Discover y las reglas de alerta lo respetan automáticamente. Los analistas aún pueden modificar el alcance manualmente durante una investigación si necesitan tener una perspectiva más amplia.

Esto es importante para los equipos que comparten un proyecto central, como los MSP, los MSSP y los centros de excelencia: puedes asignar a cada equipo su propio espacio de Kibana y restringirlo para que solo busquen los proyectos específicos de sus clientes, garantizando experiencias específicas para cada usuario. Los analistas aún pueden modificar el alcance manualmente durante una investigación si necesitan tener una perspectiva más amplia.

Puedes configurar este espacio predeterminado antes o después de vincular tus proyectos en la UI de cloud. Pero como CPS activa inmediatamente la función de "buscar todo" en cuanto se crea un enlace, configurar primero tus valores predeterminados de Kibana garantiza que las reglas de detección existentes no se ejecuten repentinamente contra un gran set de datos global y saturen a tu equipo.

Uso de etiquetas en búsquedas

Además de usar etiquetas para el enrutamiento de proyectos, también puedes usarlas en tus búsquedas ES|QL y _search. Esto puede ser útil para saber de dónde viene cada registro o fila de un conjunto de resultados o para ordenar, filtrar o agregar datos según esas etiquetas.

Por ejemplo, si quieres ver de qué proyecto proviene cada fila de una respuesta ES|QL, puedes agregar la etiqueta _project._alias a la búsqueda ES|QL:

y esto te permite usar _project._alias en otras partes de la búsqueda e incluir cláusulas KEEP para verlo en el resultado final:

Para ver más ejemplos del uso de etiquetas en las búsquedas, consulta este documento que describe cómo usarlas tanto en las API de búsqueda como en ES|QL.

Si le interesa conocer los detalles técnicos sobre cómo agregamos etiquetas a las búsquedas en Search y en ES|QL, consulta Búsqueda entre proyectos más rápida en Elasticsearch Serverless con etiquetas de proyecto y enrutamiento.

Cómo la búsqueda entre proyectos trata por igual los proyectos de origen y los proyectos vinculados

Si usaste CCS, es posible que sepas que el cluster local se trata de forma diferente a los clústeres remotos en varios aspectos.

• Los errores del cluster local se manejan de manera diferente de los errores de los clústeres remotos. En concreto, CCS usa la configuración skip_unavailable para controlar cómo se gestionan los errores de los clústeres remotos, pero esa configuración no existe para el cluster local.

• El cluster local no tiene un "alias de cluster", por lo que la expresión índice *:logs* busca en todos los proyectos remotos, pero omite el cluster local. Para buscar en ambos, tienes que usar la expresión índice logs*,*:logs*.

En CPS, cambiamos ambos de estos comportamientos para igualar el proyecto de origen y los proyectos vinculados.

En primer lugar, la configuración skip_unavailable no se usa en Elastic Cloud Serverless. En cambio, tú controlas si quieres obtener resultados parciales en una búsqueda a través del parámetro allow_partial_search_results en _search o _async_search o del parámetro allow_partial_results en ES|QL.

En segundo lugar, en Elastic Cloud Serverless, el proyecto de origen tiene un alias de proyecto. Se define en Elastic Cloud como todas las etiquetas del proyecto. Por lo tanto, en CPS, todas las búsquedas que figuran a continuación son equivalentes, se dirigen a todos los proyectos con un índice de "logs":

Nota: Hay una diferencia importante entre la expresión índice calificada *:logs y la expresión no calificada logs en cuanto a cómo funciona el manejo de errores en torno a índices faltantes. Para obtener más detalles, consulta Expresiones de búsqueda calificadas y no calificadas en la documentación pública.

Modelo de control de acceso y seguridad para la búsqueda entre proyectos

Elastic ha creado un nuevo modelo de seguridad basado en el cloud, Universal Identity and Access Management (UIAM), que hace posible un principio clave para la búsqueda entre proyectos: los proyectos y los datos a los que puedes acceder no dependen del lugar desde donde lo hagas.

Ya sea que inicies una búsqueda desde tu proyecto principal de observabilidad o desde un proyecto de analítica ad hoc, tu acceso a los datos vinculados se mantiene constante, ya que los derechos de acceso se definieron en una ubicación centralizada. El modelo de autenticación y autorización basado en el cloud usa el servicio UIAM en el cloud para garantizar que tus permisos de acceso sean uniformes, independientemente del proyecto de origen.

Prueba la búsqueda entre proyectos

En definitiva, Elastic Cloud Serverless y CPS juntos reducen los problemas operativos y ofrecen opciones adicionales para organizar los datos sobre la base de consideraciones lógicas, en lugar de físicas u operativas. La búsqueda entre proyectos les permite a tus usuarios centrarse únicamente en la organización lógica de sus datos, lo que ofrece una experiencia de búsqueda unificada sin las complejidades físicas del pasado.

Hoy, esa historia se vuelve mucho más sencilla. Ahora puedes usar las claves de API de Elastic Cloud para autenticarte directamente contra las API de Elasticsearch y Kibana en Elastic Cloud Serverless. Ahora puedes usar una sola credencial para gestionar los recursos de tu organización y ejecutar operaciones de datos, como consultas de ES|QL (lenguaje de búsqueda de Elasticsearch), ingesta de datos y generación de alertas.

Veamos por qué lo creamos, cómo diseñamos una capa de identidad distribuida en todo el mundo para hacerlo posible y cómo sienta las bases para la búsqueda entre proyectos.

La carga secreta de la gestión

Construir pipelines fiables de CI/CD, flujos de trabajo de GitOps o automatización de Terraform alrededor de plataformas de datos conlleva un costo oculto: la proliferación de secretos.

En el modelo anterior, los desarrolladores se enfrentaban a un proceso de autenticación fragmentado:

• Plano de control (claves de la API de Elastic Cloud): Claves con ámbito de organización que se emplean para crear proyectos, invitar a usuarios y gestionar la facturación a través de la API de Elastic Cloud.

• Plano de datos (claves de la API de Elasticsearch): Claves con alcance de proyecto creadas dentro de un proyecto Serverless específico para interactuar con las API de Elasticsearch y Kibana.

Esto significaba que tu script de despliegue tenía que autenticarse en Elastic Cloud, aprovisionar un proyecto Serverless, extraer una clave de API de Elasticsearch recién creada de ese proyecto específico y luego inyectar esa segunda clave en la aplicación o herramienta de automatización downstream, lo que resultaba en pipelines complejos, logs de auditoría fragmentados y un mayor riesgo de fugas de credenciales.

Autenticación unificada en Elastic Cloud Serverless

Con este lanzamiento, la división ha desaparecido para los proyectos Serverless. Ahora puedes crear una clave de la API de Elastic Cloud que esté explícitamente autorizada para las API de Cloud, Elasticsearch y Kibana.

• Antes: Una clave de API de Elastic Cloud era estrictamente un token del plano de control. Podía crear proyectos, gestionar la facturación e invitar a usuarios, pero tenía una limitación importante: no se podía usar para llamar a las API de Elasticsearch o Kibana dentro de esos proyectos. Siempre necesitabas una segunda clave específica del proyecto para las operaciones con datos.

• Ahora: Al optar por el acceso a la API de Cloud, Elasticsearch y Kibana cuando creas una clave de la API de Elastic Cloud, se elimina el límite rígido para Serverless. Esa clave de la API se convierte en una credencial verdaderamente unificada. Mantiene su capacidad para gestionar la infraestructura de tu organización, mientras obtiene acceso nativo para consultar, ingerir y analizar datos en cualquier proyecto Serverless autorizado.

Al unificarlo bajo una única clave de API de Elastic Cloud, obtienes una única identidad que puede ser delimitada, sometida a auditoría, rotada y revocada como una sola unidad. Cada llamada a la API, ya sea que aprovisione un nuevo proyecto o ejecute un ES|QL, aparece bajo la misma credencial en tus logs de auditoría, dándote un único rastro a seguir durante investigaciones de incidentes o revisiones de cumplimiento. La rotación de credenciales se convierte en una operación de un solo paso en lugar de una actualización coordinada a través de secretos separados del plano de control y del plano de datos. Y dado que las asignaciones de roles son por proyecto, una única clave puede abarcar varios proyectos, gestionando la ingesta en tu proyecto de observabilidad y ejecutando consultas en tu proyecto de seguridad, sin tener que gestionar credenciales separadas para cada uno.

Es importante destacar que unificado no significa todopoderoso. Al usar la carga útil role_assignments, puedes asignar una clave unificada estrictamente a un solo proyecto y a un rol específico (como solo lectura), cerciorando que el radio de alcance permanezca completamente contenido si alguna vez se expone una credencial. Si un desarrollador se marcha o una aplicación es desactivada, puedes revocar una sola clave de la Consola de Elastic Cloud, terminando inmediatamente el acceso tanto en el plano de control como en todos los proyectos asociados de Elasticsearch.

(Nota: Para despliegues gestionados/alojados en Elastic Cloud Hosted, las claves de API de la cloud siguen gestionando solo el plano de control. La función para extenderlo a las API de pila alojadas está previsto para una versión futura).

Automatiza tus flujos de trabajo

Los primeros pasos son simples. Puedes configurarlo completamente a través de la consola de Elastic Cloud o automatizarlo empleando la API de Elastic Cloud.

El proceso de la UI sigue igual, pero ahora puedes seleccionar acceso a la API de Cloud, Elasticsearch y Kibana bajo la asignación de rol del proyecto.

Aquí te mostramos cómo crear una clave unificada mediante programación empleando la API de Elastic Cloud. Fíjate en el array application_roles, ya que es el que otorga acceso nativo al plano de datos de Elasticsearch:

Una vez creada, simplemente pasas esta misma clave en el encabezado Authorization: ApiKey tanto a api.elastic-cloud.com como a tus puntos finales específicos de Serverless Elasticsearch.

Bajo el capó: construyendo una capa de identidad distribuida

Hacer que una clave API de Cloud funcione tanto en el plano de control como en el plano de datos no es tan simple como pasar un token. Implica resolver un reto fundamental de los sistemas distribuidos.

Históricamente, las claves de API de Cloud residían en un clúster de seguridad global centralizado. Esto funciona bien para las operaciones del plano de control donde una latencia más alta es aceptable. Sin embargo, las solicitudes de datos de Elasticsearch requieren una latencia ultrabaja. No podemos permitirnos un viaje de ida y vuelta alrededor del mundo hasta un plano de control central para validar cada consulta de búsqueda o solicitud de ingesta.

Para resolverlo, implementamos una nueva arquitectura de autenticación respaldada por un almacén de datos distribuido a nivel mundial. El siguiente diagrama de secuencia muestra a un cliente enviando una consulta a Elasticsearch con una clave de API de Elastic Cloud, lo que ilustra cómo la autenticación se lleva a cabo íntegramente dentro de la región local, sin necesidad de un viaje de ida y vuelta al plano de control global. Elasticsearch delega la autenticación al servicio regional de IAM, que valida la clave y comprueba las asignaciones de roles en una réplica local de la base de datos distribuida en todo el mundo. Una vez autorizado, Elasticsearch ejecuta la consulta y devuelve los resultados al cliente.

Persistencia distribuida a nivel global

En lugar de depender únicamente de un clúster de seguridad centralizado, las claves de la API de Elastic Cloud y las definiciones de roles asociadas ahora se almacenan permanentemente en una base de datos distribuida en todo el mundo y de alta disponibilidad. Esta base de datos sincroniza los datos de administración de identidad y acceso (IAM) a través del plano de control global y los planos de datos regionales donde realmente se ejecutan tus proyectos sin servidor.

Validación local con IAM regional

Cuando tu cliente envía una solicitud a Elasticsearch usando una clave de API de Elastic Cloud, la solicitud no se remite al plano de control mundial. En su lugar, es redirigido al nuevo servicio regional de IAM. Valida la clave contra la réplica de la base de datos local, asegurando que la autenticación ocurra con una latencia cercana a cero y esté completamente aislada de las interrupciones del plano de control mundial.

Mapping dinámico de roles

La autenticación es solo la mitad del camino; el sistema también tiene que autorizar la solicitud. El servicio regional de IAM traduce instantáneamente tus asignaciones de rol a nivel de cloud (por ejemplo, application_roles) en privilegios nativos de Elasticsearch. Elasticsearch puede entonces autorizar y ejecutar la solicitud localmente, sin necesidad de un índice .security local.

La base para la búsqueda entre proyectos

Esta arquitectura de identidad distribuida es un pilar fundamental para el futuro de la plataforma Elastic.

Como la identidad y el acceso ahora están unificados y sincronizados globalmente, contamos con el marco de trabajo necesario para transferir tu identidad de forma segura entre diferentes proyectos. Esto permite las próximas funcionalidades de búsqueda entre proyectos (CPS) para Serverless.

Con CPS, podrás consultar datos que abarcan varios proyectos serverless remotos, como combinar cargas de trabajo de seguridad y observabilidad, tan fácilmente como si fueran un solo set de datos. Al utilizar claves API unificadas, el sistema puede evaluar automáticamente tus permisos en todos los proyectos a la vez, sin que tengas que configurar relaciones de confianza complejas, certificados ni duplicar credenciales en cada proyecto de destino.

Más información

¿Listo para simplificar tu stack?

• Lee la documentación sobre las claves de la API de Elastic Cloud para saber cómo asignar acceso a la pila.

• Consulta la referencia Crear clave de la API (Elastic Cloud API) para automatizar la generación de claves.

• Consulta las claves de API de Elastic para ver una comparación completa de los tipos de claves disponibles en toda la Platform de Elastic.

Empieza o continúa construyendo en Elastic Cloud hoy mismo.

Descargo de responsabilidad

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a exclusivo criterio de Elastic. Es posible que alguna característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.

La fiesta se está llenando de gente

Organizas una fiesta de pizzas. Tienes a unos cuantos amigos que te ayudan a servirlas, cada uno en un lugar distinto de la sala. Le das a cada amigo una pizza y ellos empiezan a repartir rebanadas a los invitados hambrientos a medida que llegan.

Al principio, todo marcha sin problemas. Unos cuantos invitados van llegando de a poco, tus amigos sirven porciones y todos están contentos. Pero entonces se corre la voz sobre tus pizzas de masa madre. El timbre sigue sonando. Los invitados siguen llegando en masa. Pronto se forma una multitud alrededor de uno de tus amigos, el que lleva la pizza de pepperoni, que parece ser la que quieren todos.

Tu amigo con la pizza de pepperoni está abrumado. Los invitados están esperando, se ponen impacientes y se formó una larga cola. Mientras tanto, tu amiga que sostiene la pizza margherita está de pie con casi nadie pidiéndole una porción.

¿Qué haces?

Pides un par de pizzas de pepperoni más y se las das a otros amigos. Ahora tres amigos tienen pepperoni en lugar de uno. La multitud se dispersa y, de repente, puedes atender a tres veces más invitados a la vez.

A medida que organizas más fiestas, hay algunas cosas que se vuelven claras:

• No todas las pizzas son igual de populares. Algunas tienen mucha demanda; otras tienen menos interesados. No necesitas "copias" adicionales de las menos populares. Necesitas más de las que todos esperan en cola.

• Pide más pizzas antes de que la fila se haga demasiado larga. Si esperas hasta que tu amigo esté completamente abrumado y los invitados se estén yendo enojados, esperaste demasiado tiempo. Es mejor pedir una pizza más cuando ves que se está formando una multitud.

• No deseches las pizzas demasiado rápido. Solo porque la multitud alrededor del pepperoni se redujo durante cinco minutos no significa que la avalancha haya terminado. Tal vez solo están sirviéndose bebidas, o incluso hablando entre ellos (¿eso todavía se hace?). Mantén las pizzas adicionales listas. Si la calma se mantiene por un rato, entonces puedes guardarlas.

• Solo puedes repartir tantas pizzas como amigos tengas que te estén ayudando. Si solo tienes cuatro amigos ayudándote, diez pizzas no cambiarán el resultado. Solo se pueden servir cuatro a la vez. Haz coincidir tu cantidad de pizzas con tus manos disponibles.

• Cuando un amigo se vaya, llévate su pizza. Si uno de tus amigos necesita salir, toma su pizza inmediatamente. No puedes dejar las pizzas sin supervisión. Dásela a otra persona, o guárdala.

Desde pizzas hasta réplicas

Vamos a mapear esto de vuelta a Elasticsearch.

En nuestra analogía, las pizzas son réplicas (copias de tus fragmentos de índice), tus colegas ayudando a servir son nodos de búsqueda, los invitados hambrientos son consultas de búsqueda, y esa pizza popular con mucha gente alrededor es un índice caliente con alta carga de búsqueda.

Cuando el tráfico de búsqueda aumenta en un índice en particular, creamos réplicas adicionales y las distribuimos en tus nodos de búsqueda. Cualquier réplica puede responder a cualquier consulta sobre ese índice, igual que cualquier amigo que tenga pepperoni puede repartir rebanadas de pepperoni. Más réplicas significan un mayor rendimiento: tres réplicas pueden manejar tres veces las consultas por segundo de una sola réplica.

Medir el hambre

Antes de decidir cuántas pizzas pedir, necesitamos saber qué tan hambrienta está la multitud.

Elasticsearch rastrea la carga de búsqueda de cada fragmento. Es una métrica que mide el volumen de actividad de búsqueda que gestiona un fragmento. Sumamos estos datos de todos los fragmentos de un índice para conocer la demanda total de búsquedas.

Lo que más importa es la carga de búsqueda relativa: ¿qué proporción del tráfico de búsqueda total de tu proyecto está llegando a cada índice? Si un índice recibe el 60 % de todas las búsquedas mientras que otro recibe el 5 %, sabemos dónde debemos aumentar la capacidad.

La matemática detrás de las pizzas

Calculamos el número óptimo de réplicas siguiendo esta fórmula:

Dónde:

• L = la carga de búsqueda relativa del índice (entre 0 y 1).

• N = el número de nodos de búsqueda deseados en tu proyecto.

• S = la cantidad de fragmentos en el índice.

• X = un umbral para evitar puntos calientes (predeterminado: 0,5).

Un ejemplo: cuatro nodos de búsqueda, un índice con dos fragmentos primarios que reciben el 80 % del tráfico de búsqueda:

Este índice activo tiene cuatro réplicas distribuidas entre los nodos de búsqueda.

El umbral X (con un valor predeterminado de 0,5) es importante. No esperamos hasta que una réplica esté completamente saturada, sino que escalamos cuando está a la mitad de su capacidad. Reparte la pizza adicional cuando veas que la multitud empieza a formarse, no cuando los invitados ya se están yendo.

Escala rápido, reduce la escala lentamente

Cuando aumenta la carga de búsqueda, agregamos réplicas inmediatamente. No hay razón para hacer esperar a los usuarios.

Cuando la carga de búsqueda disminuye, esperamos un poco antes de tomar alguna acción. Necesitamos ver una demanda baja constante durante unos 30 minutos antes de reducir las réplicas. (Esto es para manejar el tráfico irregular donde un momento de calma no significa que la fiesta haya terminado.)

Esto importa porque agregar una réplica tiene un costo. La réplica nueva copia datos y calienta sus cachés antes de servir las consultas de manera eficiente. Si eliminas las réplicas con demasiada prisa, terminarás pagando este costo inicial constantemente, ya que el tráfico fluctúa de forma natural.

Respetando los límites de la topología

Las réplicas nunca pueden superar el número de nodos de búsqueda. Tener más réplicas que nodos no aporta ningún beneficio (solo puedes servir tantas pizzas como colegas que ayuden a servir las porciones).

Cuando se eliminan nodos de tu proyecto, reducimos las réplicas inmediatamente para que coincidan. Sin esperar el enfriamiento, ya que no puedes tener réplicas sin asignar. En cuanto un usuario se va, le quitamos la pizza.

El panorama general de Elastic Cloud Serverless

Las réplicas para el balanceo de carga de búsqueda funcionan junto con otros sistemas de autoescalado:

• El escalado automático de búsqueda ajusta el número de nodos de búsqueda (cuántos amigos están ayudando).

• Las réplicas para el balanceo de carga de búsqueda distribuyen el tráfico al ajustar la cantidad de réplicas por índice (cuántas pizzas de cada tipo necesitamos).

• La fragmentación automática de flujos de datos optimiza el número de particiones para las operaciones de escritura (cómo cortar cada pizza, como se explicó en la publicación anterior).

Un principio de diseño importante: las réplicas para el equilibrio de carga no activan directamente el escalado automático de búsqueda. En cambio, distribuir las consultas de búsqueda entre más réplicas permite aumentar la utilización de recursos en todos tus nodos de búsqueda. Este mayor uso luego activa nuestra lógica de escalado automático existente para agregar capacidad si es necesario. Las réplicas para el balanceo de carga permiten que el autoescalado haga su trabajo, lo que asegura que tus nodos de búsqueda realmente se estén utilizando, en lugar de que todo el tráfico esté bloqueado en una sola réplica mientras otros nodos permanecen inactivos.

Qué significa esto para ti

No necesitas predecir qué índices serán populares. No necesitas ajustar manualmente las réplicas cuando cambian los patrones de tráfico. No necesitas despertarte a las 3 a. m. porque un aumento repentino sobrecargó tu índice más ocupado.

El sistema observa dónde se están formando colas y pide más pizzas para esos lugares. Los índices fríos no desperdician recursos en réplicas innecesarias. Los índices calientes obtienen la capacidad que necesitan. Tu presupuesto se destina a donde importa.

Conclusión

En la publicación sobre la autofragmentación (autosharding) nos aseguramos de que tus pizzas estén cortadas correctamente. Ahora, con réplicas para el equilibrio de carga de búsqueda, nos aseguramos de que tengas suficientes pizzas, en las manos adecuadas, cuando llegue la multitud hambrienta.

Prueba Elastic Cloud Serverless y déjanos encargarnos de la logística de la pizza.

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

Completamos una importante actualización de infraestructura para todos los proyectos de Elastic Cloud Serverless que funcionan en AWS, al migrar a hardware más nuevo y rápido. Este cambio se ha implementado automáticamente en todos los proyectos sin servidor. Ofrece mayor rendimiento y menor latencia para proyectos serverless de Elasticsearch, Elastic Observability y Elastic Security en AWS.

Beneficios clave de rendimiento para desarrolladores

La nueva infraestructura de hardware de AWS sustenta todo lo que haces con Elastic Cloud Serverless, lo que se traduce en beneficios tangibles para la velocidad y la capacidad de respuesta de tus aplicaciones.

Latencia de consulta reducida… rendimiento aumentado.

El hardware mejorado aumenta drásticamente la velocidad de los recursos informáticos, lo que significa que tus consultas de búsqueda se procesan más rápido que nunca.

• Búsqueda y búsqueda vectorial: ya sea que estés ejecutando búsquedas de texto tradicionales o empleando una búsqueda vectorial de vanguardia para tus aplicaciones de inteligencia artificial generativa y RAG, verás una marcada disminución en la latencia. La evaluación interna mostró una disminución promedio del 35% en la latencia de búsqueda.

• Indexación más rápida: Las tasas de ingesta de datos están optimizadas, lo que te permite indexar volúmenes masivos de datos y documentos complejos con mayor rendimiento. Esto es crucial para las aplicaciones que requieren visibilidad de datos casi en tiempo real. La evaluación comparativa interna mostró un aumento promedio del 26% en el rendimiento al indexar.

Rendimiento constante bajo carga

Elastic Cloud Serverless está diseñado para escalar dinámicamente en tiempo real y satisfacer la demanda, lo que minimiza la latencia, independientemente de tu carga de trabajo. Gracias a esta actualización de hardware, ahora el escalado es más eficaz y ofrece una mayor capacidad de respuesta.

• Manejar los picos con facilidad: ya sea que te enfrentes a un aumento repentino en el tráfico de usuarios o a una ingesta masiva de datos batch, la nueva infraestructura garantiza que tus recursos de búsqueda e indexación se escalen de manera más eficiente para mantener una latencia constantemente baja.

• Desacoplamiento optimizado de computación y almacenamiento: La arquitectura serverless separa computación y almacenamiento, lo que permite que las cargas de trabajo escalen de forma independiente para lograr un rendimiento óptimo y eficiencia de costos. El hardware más rápido mejora la capa de cómputo, lo que maximiza la eficiencia de este diseño desacoplado.

Por dentro: Resultados de evaluación comparativa interna

Para cuantificar el impacto de la actualización de nuestra infraestructura de AWS, el equipo de ingeniería de Elastic llevó a cabo una exhaustiva evaluación comparativa interna con una serie de cargas de trabajo sin servidor. Estas cargas de trabajo proporcionaron evidencia empírica de mejoras de rendimiento que puedes esperar en todas tus aplicaciones, independientemente de tu caso de uso.

El enfoque comparativo

Centramos nuestras pruebas en las métricas clave que afectan directamente a la experiencia de los desarrolladores y a la capacidad de respuesta de las aplicaciones: el tiempo de respuesta (es decir, la latencia) y el rendimiento en las operaciones de búsqueda e indexación.

• Cargas de trabajo probadas: Las pruebas incluyeron operaciones de búsqueda de alta concurrencia típicas de las aplicaciones orientadas al usuario, consultas de búsqueda vectorial complejas y la ingesta/indexación de grandes volúmenes de datos para casos de uso de observabilidad y seguridad. En concreto, nuestra metodología de pruebas utilizó sets de datos disponibles públicamente para Rally, la herramienta de evaluación comparativa de Elastic.

  • wikipedia: Un conjunto de datos derivado de un snapshot del contenido textual de Wikipedia, para medir el rendimiento de la búsqueda de texto de propósito general.

  • MSMARCO-Passage-Ranking: Un conjunto de datos derivado de la comprensión de lectura automática de Microsoft (MS MARCO), para medir el rendimiento de búsqueda en campos vectoriales dispersos.

  • OpenAI_Vector: Un set de datos derivado del NQ de BEIR y enriquecido con incrustaciones generadas por el modelo text-embedding-ada-002 de OpenAI, para medir el rendimiento de búsqueda en campos vectoriales densos.

• Medición: Comparamos el rendimiento en la infraestructura antigua y nueva, al medir la latencia en el percentil 99 (P99) para capturar el peor de los casos, el rendimiento de latencia en la cola y las operaciones por segundo. Cada pista se ejecutó cinco veces para cada perfil de hardware para garantizar la consistencia en los resultados.

• El objetivo: nuestro objetivo era validar la capacidad de la infraestructura para ofrecer un rendimiento más rápido y predecible de forma constante en todos los ámbitos, incluso durante los periodos de autoescalado rápido.

Resumen de datos de rendimiento

Los resultados confirman un aumento significativo en la eficiencia y la velocidad. Estas ganancias se traducen directamente en tiempos de respuesta más bajos para tus usuarios y menores costos operativos como resultado de la capacidad de completar la misma cantidad de trabajo con menos recursos de cómputo.

Las siguientes tablas detallan las mejoras cuantitativas. Los valores más altos son mejores para el rendimiento; los valores más bajos son mejores para la latencia.

Búsqueda de resultados del índice de referencia:

Benchmark

Comparación

Infraestructura antigua

Nueva infraestructura

Diferencial

`wikipedia` (texto sin formato)

Rendimiento de operaciones de búsqueda (ops/s)

729

1107

+52 %

`wikipedia` (texto sin formato)

Latencia de la operación de búsqueda (p99, ms)

56

35

-37 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Rendimiento de operaciones de búsqueda (ops/s)

22

31

+40 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Latencia de la operación de búsqueda (p99, ms)

108

67

-38 %

`OpenAI_Vector` (vectores densos)

Rendimiento de operaciones de búsqueda (ops/s)

475

624

+31 %

`OpenAI_Vector` (vectores densos)

Latencia de la operación de búsqueda (p99, ms)

35

22

-37 %

Resultados de referencia de indexación:

Benchmark

Comparación

Infraestructura antigua

Nueva infraestructura

Diferencial

`wikipedia` (texto sin formato)

Rendimiento de operaciones de búsqueda (ops/s)

2845

3220

+13 %

`wikipedia` (texto sin formato)

Latencia de la operación de búsqueda (p99, ms)

1769

1120

-37 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Rendimiento de operaciones de búsqueda (ops/s)

7087

8900

+26 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Latencia de la operación de búsqueda (p99, ms)

824

677

-18 %

`OpenAI_Vector` (vectores densos)

Rendimiento de operaciones de búsqueda (ops/s)

2972

3187

+7 %

`OpenAI_Vector` (vectores densos)

Latencia de la operación de búsqueda (p99, ms)

2946

2944

0 %

La ventaja adicional: reducción de costos

Aunque nuestro objetivo es ofrecer un rendimiento de baja latencia, la eficiencia del nuevo hardware también tiene un impacto directo y positivo en los costos de los proyectos de Elasticsearch.

El precio de Elasticsearch Serverless se basa en el uso, lo que significa que solo pagas por los recursos de ingesta y búsqueda que consumes. Debido a que el hardware más nuevo y rápido es más eficiente, tus cargas de trabajo a menudo completarán tareas empleando menos recursos, lo que genera una reducción de costos inherente para la mayoría de los proyectos. Obtendrás un aumento de rendimiento superior sin un precio premium: la definición de eficiencia optimizada.

¿Qué significa esto para ti, el desarrollador?

Esta actualización de infraestructura está gestionada íntegramente por Elastic, así que no tienes que mover un dedo: no hay migraciones ni cambios de configuración. La mejora es inmediata y automática en todos tus proyectos serverless basados en AWS.

Esta actualización te permite:

• Crea aplicaciones más rápidas: concéntrate en la velocidad de las características, sabiendo que tu plataforma de búsqueda subyacente ofrece la velocidad que exigen tus usuarios.

• Innova con confianza: despliega nuevas características de búsqueda, observabilidad y seguridad, incluidas capacidades complejas de IA, como búsqueda vectorial y clasificación de relevancia, con la seguridad de que la Platform puede manejar la carga al máximo rendimiento.

• Simplifica tu stack: Usa un servicio totalmente gestionado que gestione la infraestructura, la planificación de la capacidad y el escalado, para que puedas centrarte en tu código y 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

Donde empezamos

La primera versión de Elasticsearch se lanzó en 2010 como un motor de búsqueda distribuido y escalable que permite a los usuarios buscar rápidamente y mostrar información crítica. Doce años y más de 65.000 commits después, Elasticsearch sigue ofreciendo a los usuarios soluciones probadas para una amplia variedad de problemas de búsqueda. Gracias al esfuerzo de más de 1.500 colaboradores, incluidos cientos de empleados a tiempo completo de Elastic, Elasticsearch evolucionó constantemente para afrontar los nuevos retos que surgen en el campo de la búsqueda.

Al principio de la vida de Elasticsearch, cuando surgieron preocupaciones sobre la pérdida de datos, el equipo de Elastic llevó a cabo un esfuerzo de varios años para reescribir el sistema de coordinación del clúster y garantizar que los datos reconocidos se almacenen de forma segura. Cuando quedó claro que gestionar índices en grandes clústeres era un engorro, el equipo trabajó en la implementación de una solución ILM extensa para automatizar este trabajo permitiendo a los usuarios predefinir patrones de índices y acciones del ciclo de vida. A medida que los usuarios notaron la necesidad de almacenar cantidades significativas de datos métricos y de seriales temporales, se agregaron varias características como una mejor compresión para reducir el tamaño de los datos. A medida que aumentaba el costo de almacenamiento de buscar grandes cantidades de datos fríos, invertimos en crear Instantáneas Buscables como una forma de buscar datos de usuario directamente en almacenes de objetos de bajo costo.

Estas inversiones sentan las bases para la siguiente evolución de Elasticsearch. Con el crecimiento de los servicios nativos en la nube y los nuevos sistemas de orquestación, decidimos que es hora de evolucionar Elasticsearch para mejorar la experiencia al trabajar con sistemas nativos en la nube. Creemos que estos cambios presentan oportunidades para mejoras operativas, de rendimiento y de costos al ejecutar Elasticsearch en Elastic Cloud.

Hacia dónde vamos — Adoptar una arquitectura sin estado

Uno de los principales retos al operar u orquestar Elasticsearch es que depende de numerosas piezas de estado persistente, por lo que es un sistema con estado. Las tres piezas principales son el translog, el almacenamiento de índices y los metadatos del clúster. Este estado significa que el almacenamiento debe ser persistente y no puede perder durante un resetear o reemplazo de nodo.

La arquitectura existente de Elasticsearch en Elastic Cloud debe duplicar la indexación en múltiples zonas de disponibilidad para proporcionar redundancia en caso de caídas. Nuestra intención es trasladar la persistencia de estos datos de los discos locales a un almacén de objetos, como AWS S3. Al depender de servicios externos para almacenar estos datos, eliminaremos la necesidad de replicación indexada, reduciendo significativamente el hardware asociado a la ingestión. Esta arquitectura también ofrece garantías de durabilidad muy altas debido a la forma en que los almacenes de objetos en la nube como AWS S3, GCP Cloud Storage y Azure Blob Storage replican los datos entre zonas de disponibilidad.

Transferir el almacenamiento indexado a un servicio externo también nos permitirá reestructurar Elasticsearch separando las responsabilidades de indexación y búsqueda. En lugar de que las instancias primarias y réplicas gestionen ambas cargas de trabajo, pretendemos tener un nivel de indexación y un nivel de búsqueda. Separar estas cargas de trabajo permitirá escalarlas de forma independiente y seleccionar el hardware más dirigido a los casos de uso respectivos. También ayuda a resolver un reto de larga duración en el que la carga de búsqueda e indexación puede afectar mutuamente.

Tras realizar una fase de prueba de concepto y experimental de varios meses, estamos convencidos de que estos servicios de almacenamiento de objetos cumplen los requisitos que prevemos para el almacenamiento de índices y los metadatos de clústeres. Nuestras pruebas y benchmarks indican que estos servicios de almacenamiento pueden satisfacer las altas necesidades de indexación de los clústeres más grandes que vimos en Elastic Cloud. Además, respaldar los datos en el almacén de objetos reduce los costos de indexación y permite un ajuste sencillo del rendimiento de la búsqueda. Para buscar datos, Elasticsearch empleará el modelo Searchable Snapshots, probado en batalla, donde los datos persisten permanentemente en el almacén de objetos nativos de la nube y los discos locales se emplean como cachés para los datos frecuentemente consultados.

Para ayudar a diferenciar, describimos nuestro modelo existente como replicación "nodo a nodo". En el nivel caliente de este modelo, tanto los fragmentos primarios como los réplica hacen el mismo trabajo pesado para gestionar las solicitudes de búsqueda de ingesta y servicio. Estos nodos son "con estado" en el sentido de que dependen de sus discos locales para conservar de forma segura los datos de los fragmentos que alojan. Además, los fragmentos primarios y réplica están constantemente comunicar para mantener sincronizados. Lo hacen replicando las operaciones realizadas en el shard principal al shard réplica, lo que significa que el costo de esas operaciones (principalmente CPU) se incurre por cada réplica especificada. Los mismos fragmentos y nodos que realizan este trabajo para la ingesta también están atendiendo las solicitudes de búsqueda, por lo que el aprovisionamiento y el escalado deben hacer teniendo en cuenta ambas cargas de trabajo.

Más allá de buscar e ingerir, los fragmentos en el modelo de replicación nodo a nodo gestionan otras responsabilidades intensivas, como fusionar segmentos Lucene. Aunque este diseño tiene sus méritos, vimos muchas oportunidades basadas en lo que aprendimos con los clientes a lo largo de los años y en la evolución del ecosistema cloud más amplio.

La nueva arquitectura permite muchas mejoras inmediatas y futuras, incluyendo:

1. Puedes aumentar significativamente el rendimiento de ingesta en el mismo hardware o, dicho de otra manera, mejorar significativamente la eficiencia para la misma carga de trabajo de ingestión. Este aumento se debe a eliminar la duplicación de operaciones de indexación para cada réplica. Las operaciones de indexación intensivas en CPU solo necesitan realizar una vez en el nivel de indexación, que entonces transporta los segmentos resultantes a un almacén de objetos. A partir de ahí, los datos están listos para ser consumidos tal cual por el nivel de búsqueda.

2. Puedes separar el cálculo del almacenamiento para simplificar la topología de tu clúster. Hoy en día, Elasticsearch dispone de múltiples niveles de datos (contenido, caliente, caliente, frío y congelado) para emparejar datos con el perfil de hardware. El hot tier es para búsquedas casi en tiempo real y el congelado es para datos menos frecuentemente buscados. Aunque estos niveles aportan valor, también aumentan la complejidad. En la nueva arquitectura, los niveles de datos dejarán de ser necesarios, lo que simplificará la configuración y funcionamiento de Elasticsearch. También estamos separando la indexación de la búsqueda, lo que reduce aún más la complejidad y nos permite escalar ambas cargas de trabajo de forma independiente.

3. Puedes experimentar una mejora en los costos de almacenamiento en el nivel de indexación al reducir la cantidad de datos que deben almacenar en un disco local. Actualmente, Elasticsearch debe almacenar una copia completa del fragmento en nodos calientes (tanto primarios como réplicas) para fines de indexación. Con el enfoque sin estado de indexar directamente al almacén de objetos, solo se requiere una parte de esos datos locales. Para casos de uso solo de anexo, solo ciertos metadatos deberán almacenar para indexar. Esto reducirá significativamente el almacenamiento local necesario para la indexación.

4. Puedes reducir los costos de almacenamiento asociados a las búsquedas. Al convertir el modelo de Instantáneas Buscables en el modo nativo de búsqueda de datos, el costo de almacenamiento asociado a las consultas de búsqueda disminuirá significativamente. Dependiendo de las necesidades de latencia de búsqueda de los usuarios, Elasticsearch permitirá ajustes para aumentar la caché local en los datos aplicar con frecuencia.

Benchmarking — Mejora del 75% en el rendimiento de la indexación

Para validar este enfoque, implementamos una prueba de concepto extensa en la que los datos solo se indexaban en un solo nodo y la replicación se realizaba mediante almacenes de objetos en la nube. Descubrimos que podíamos lograr una mejora del 75% en el rendimiento de indexación eliminando la necesidad de dedicar hardware a la replicación de indexación. Además, el costo de CPU asociado simplemente a extraer datos del object store era mucho menor que indexar los datos y escribirlos localmente, como es necesario para la fase caliente hoy en día. Esto significa que los nodos de búsqueda podrán dedicar completamente su CPU a la búsqueda.

Estas pruebas de rendimiento se realizaron en un clúster de dos nodos contra los tres principales proveedores de nube pública (AWS, GCP y Azure). Tenemos la intención de seguir desarrollando benchmarks más amplios mientras buscamos una implementación sin estado en producción.

Rendimiento de indexación

Uso de la CPU

Apátrida para nosotros, ahorros para ti

La arquitectura sin estado de Elastic Cloud te permitirá reducir la sobrecarga de indexación, escalar de forma independiente la ingesta y la búsqueda, simplificar la gestión de los niveles de datos y acelerar operaciones, como escalar o actualizar. Este es el primer hito hacia una modernización sustancial de la plataforma Elastic Cloud.

Forma parte de nuestra visión sin estado de Elasticsearch

¿Te interesa probar esta solución antes que nadie? Puedes contactarnos en Discuss o en nuestro canal comunitario de Slack. Nos encantaría recibir vuestros comentarios para ayudar a definir la dirección de nuestra nueva arquitectura.