Para novos usuários, esta é a maneira mais rápida de colocar a busca vetorial de alta qualidade em funcionamento. Se você já usa o Elasticsearch, a nova oferta é a busca vetorial na plataforma onde seus dados já estão, sem nenhum novo sistema para adotar. O Elasticsearch Vector Database oferece suporte a uma variedade de cenários, desde a fundamentação de um grande modelo de linguagem (LLM) e o fornecimento de recuperação e memória para um agente de IA até o atendimento de centenas de bilhões de vetores. Crie um novo projeto e comece em minutos.

Um motor, todos os casos de uso vetoriais

O banco de dados vetorial do Elasticsearch foi desenvolvido para qualquer pessoa que crie aplicativos usando vetores:

• RAG: recupere o contexto certo para o seu LLM com a recuperação de vetores densos e esparsos, ou opte pela busca híbrida combinando a recuperação vetorial e lexical. A qualidade da sua geração melhora com a qualidade da sua recuperação.

• Agentes de IA: forneça aos agentes recuperação rápida e filtrada de documentos e memória de conversação, com as baixas latências que loops de agentes em várias etapas exigem.

• Busca semântica: faça a correspondência por significado, não por palavras-chave, com um tipo de campo e zero código de pipeline.

• Recomendações e similaridade: encontre vizinhos mais próximos em produtos, imagens ou qualquer conteúdo que você tenha, em escala.

Tudo o que sua carga de trabalho vetorial precisa, otimizado e pronto para uso

Criar uma aplicação baseada em vetores significa conectar várias partes separadas: configurar e hospedar modelos de embedding, fazer a indexação dos seus documentos por meio deles, armazenar os vetores com eficiência, aplicar o modelo de embedding a cada consulta, fazer a correspondência com o armazenamento de vetores e, por fim, recuperar os documentos por trás das correspondências. O Elasticsearch Vector Database cuida de tudo isso para você, sem necessidade de configuração ou setup adicional.

Indexação de vetores com o modo de índice vectordb_document

O modo de índice vectordb_document, uma nova configuração de índice desenvolvida especificamente para cargas de trabalho que priorizam vetores, vem ativado por padrão, para que você obtenha as configurações que os especialistas escolheriam. Veja o que ele ativa:

• bfloat16 por padrão: os vetores são armazenados com metade do tamanho do float32 com impacto insignificante no recall, reduzindo o consumo de disco aproximadamente pela metade antes mesmo de a quantização entrar em cena.

• Vetores de origem excluídos: no Elasticsearch, seus embeddings já residem nas estruturas de índice usadas para busca; manter uma segunda cópia bruta no _source apenas infla o armazenamento e desacelera a recuperação de resultados. Excluímos a duplicata para que as respostas retornem mais rápido e você armazene menos.

• Os arquivos certos pré-carregados no cache: as estruturas de dados que as consultas vetoriais acessam primeiro são carregadas na memória antecipadamente, para que sua primeira consulta (e também a milésima) seja ultrarrápida.

• Mesclagem paralela: a mesclagem consolida segmentos em estruturas de vetores mais bem organizadas, o que melhora o recall e reduz a latência, e executar essas mesclagens com várias threads significa que você chega lá mais rápido.

Armazenamento de vetores, compressão e ajuste automático

• Seus vetores são compactados automaticamente. O Better Binary Quantization (BBQ) reduz o consumo de memória dos vetores em até 32x enquanto preserva o recall, e o DiskBBQ reduz ainda mais os requisitos de memória para cargas de trabalho em grande escala. 

• Opte pela calibração automática, que ajusta a quantização de cada segmento aos seus dados e a reajusta a cada mesclagem conforme os dados sofrem desvios. Quando testado em 18 conjuntos de dados, o número de consultas por segundo (QPS) melhorou em uma média de 16,7%, com ganhos de recall na maioria deles.

Embeddings em inferência gerenciada por GPU

• Gere embeddings com os modelos nativos de embedding e reranking da Jina AI, ou traga modelos de terceiros, tudo em GPUs gerenciadas via Elastic Inference Service (EIS), sem precisar operar servidores de modelos. Ou faça a auto-hospedagem, se preferir usar seu próprio modelo.

• O tipo de campo semantic_text lida automaticamente com o particionamento e a geração de embeddings, além de consultas, o caminho mais simples para a busca semântica no mercado. 

Busca híbrida e busca vetorial filtrada

• A busca híbrida é integrada, combinando a recuperação de texto completo e de vetores em uma única consulta. Combine os resultados com reciprocal rank fusion (RRF) ou qualquer outro mecanismo de combinação que você quiser. A busca vetorial normalmente é a parte mais difícil de configurar bem na busca híbrida. Com o banco de dados vetorial do Elasticsearch, você tem tudo sob controle e toda a sua stack híbrida fica ainda melhor. 

• Com a busca vetorial filtrada, aplique filtros de metadados como parte da própria recuperação vetorial, e não como uma etapa adicionada posteriormente que prejudica o recall.

Empresarial desde o primeiro dia

Você também conta com controle de acesso baseado em funções (RBAC), logging de auditoria e as certificações de conformidade que geralmente faltam nos bancos de dados exclusivamente vetoriais.

Acessível em escala e previsível

O banco de dados vetorial do Elasticsearch foi desenvolvido para continuar acessível à medida que você cresce: a compressão com BBQ e DiskBBQ, que mantém o armazenamento linear e o uso de memória baixo, significa que redimensionar para centenas de bilhões de vetores não faz sua conta disparar. E o que você paga é calculado com base em números que já conhece: a quantidade de dados que armazena e indexa, além da capacidade de busca de que precisa. Estime a quantidade de documentos e as dimensões dos vetores, além da carga de consultas, e você poderá calcular o que vai pagar antes de criar o projeto. Você também pode entender sua conta linha por linha no fim do mês. Não há unidades de computação opacas nem cobranças surpresa por operações em segundo plano.

Como começar com o banco de dados vetorial do Elasticsearch

Crie um projeto de banco de dados vetorial serverless

Crie um novo projeto serverless de banco de dados vetorial no Elastic Cloud. Aponte seus dados para o endpoint, e você estará pronto para indexar.

Criar um índice usando semantic_text

O modo de índice vetorial gerencia a configuração do vetor. Usar semantic_text significa que a configuração de embeddings e particionamento, assim como a configuração do índice, é gerenciada para você com inferência gerenciada por GPU, sem a necessidade de criar um pipeline de embeddings.

Ingerir documentos

Indexe texto, e os embeddings são gerados para você.

Execute uma consulta de busca semântica

Consulte o mesmo campo semântico que você acabou de criar:

E você recebe os resultados de volta:

A busca semântica é apenas o começo. Execute consultas totalmente textuais ou combine os dois tipos em consultas híbridas. Você pode até criar suas próprias consultas vetoriais para ter controle total. Siga o guia de início rápido da busca semântica na documentação para obter as instruções completas.

O que vem por aí para a busca vetorial no Elasticsearch

Já estamos trabalhando nas próximas melhorias:

• Melhor gerenciamento multitenant: se os seus dados precisarem permanecer separados por tenant, vamos oferecer uma maneira de fazer isso mais rápido e com menos código.

• Otimização automática de índice: de "índice novo em folha" a "totalmente otimizado", com o mínimo de ajustes possível.

• Melhorias contínuas de infraestrutura: ajuste contínuo das configurações e da infraestrutura do banco de dados vetorial para que você tenha sempre a melhor taxa de transferência e as respostas mais rápidas.

Experimente o banco de dados vetorial do Elasticsearch no Elastic Cloud Serverless

Vá de um projeto vazio a uma consulta vetorial híbrida e filtrada em minutos, com padrões de nível de produção fazendo o ajuste para você. Crie apps de IA rápidos e escaláveis, não infraestrutura.

Comece no Elastic Cloud Serverless, ou mergulhe na documentação completa e na referência da API.

O Elastic Cloud Serverless já elimina a dor de cabeça de gerenciar infraestrutura e atualizações de versão. O CPS vai além. Substituímos o complexo peering de rede e o gerenciamento manual de certificados por um modelo de vinculação simples. Agora, você pode tratar seus projetos Elastic Cloud Serverless como espaços de nome simples para seus dados. Seja lidando com leis rígidas de residência de dados, isolando dados de tenant ou apenas tentando evitar as enormes taxas de saída de rede que surgem da duplicação de logs, o CPS permite que você busque seus dados exatamente onde eles estão com uma única consulta.

Neste post, vamos explicar como funciona o CPS, como controlar as buscas usando tags de projeto e como esse novo modelo difere da busca entre clusters (CCS) tradicional.

Como vincular projetos para busca entre projetos

Para começar com a busca entre projetos, vincule os projetos no console Elastic Cloud ou na API. O vínculo é simples e unidirecional: você escolhe um projeto de origem e conecta os projetos que ele deve buscar. Essas ligações podem abranger regiões, provedores de serviços em nuvem e tipos de projeto, para que seus dados permaneçam onde pertencem sem abrir mão de uma experiência de busca unificada.

Depois que o link é criado, ele geralmente está ativo em um minuto. Se você já está com o Kibana aberto, atualize para ver as novas capacidades de busca entre projetos.

Como a busca nos projetos consulta todos os projetos vinculados por padrão

Depois que os projetos estejam vinculados, a busca entre projetos transforma projetos separados em uma única superfície de busca lógica. Se seus logs aparecem em vários projetos, uma consulta como FROM logs* busca o projeto de origem e qualquer projeto vinculado que tenha dados correspondentes. Você não precisa nomear cada alvo remoto antecipadamente.

Isso já é uma melhoria em relação à busca entre clusters. No CCS, alcançar dados locais e remotos geralmente significa algo como FROM logs*,*:logs*. Para os usuários, isso significa menos complexidade de consulta. Para as equipes, isso nos aproxima de um verdadeiro painel único entre os dados distribuídos.

Para mais informações, veja a documentação do modelo de busca do CPS.

Se você tem interesse em saber detalhes técnicos de como criamos isso, veja Como funciona a busca entre projetos (CPS) no Elasticsearch Serverless.

Controle de buscas via roteamento de projetos

A possibilidade de buscar em todos os projetos vinculados por padrão é conveniente e útil para muitos fluxos de trabalho, mas nem toda pesquisa deve abranger todos os lugares. A busca entre projetos introduz o roteamento por projeto, uma forma de limitar uma consulta a um subconjunto específico de projetos.

Ele funciona por meio de tags de projeto definidas no Elastic Cloud. Cada projeto possui atributos integrados, como o alias, provedor de serviços em nuvem e região. Você também pode adicionar suas próprias tags para refletir como sua organização vê seu patrimônio, como environment:prod, environment:test, uma unidade de negócio ou um nome de cliente. O Elasticsearch pode então usar esses metadados para decidir quais projetos vinculados devem participar de uma busca.

Todos os endpoints Elasticsearch compatíveis com busca entre projetos aceitam um parâmetro project_routing. Na pré-visualização técnica, o roteamento é limitado ao uso de alias do projeto. Por exemplo, definir project_routing como _alias:my-linked-project envia a consulta somente para esse projeto vinculado, enquanto _alias:_origin mantém a consulta no projeto de origem. Com o tempo, esse modelo abre as portas para um roteamento muito mais rico, em que o escopo da pesquisa pode seguir a estrutura lógica da sua organização em vez do layout físico da sua infraestrutura.

Consulte os documentos de roteamento do projeto para ver exemplos e mais detalhes sobre como eles funcionam.

Roteamento padrão de projeto em nível de espaço Kibana

Como exemplo de uma situação em que é necessária mais precisão no roteamento da sua busca, pesquisar todos os projetos vinculados pode gerar uma enxurrada de falsos positivos nas suas regras do Kibana ou resultados confusos nos seus dashboards existentes. Para resolver isso, você pode definir um escopo padrão de projeto em nível de espaço no Kibana. Funciona como uma predefinição segura para aquele espaço específico, ou seja, todos os dashboards, sessões de descoberta e regras de alerta o respeitam automaticamente. Analistas ainda podem alterar manualmente o escopo durante uma investigação se precisarem de uma visão mais ampla.

Isso é importante para equipes que compartilham um projeto central, como MSPs, MSSPs e centros de excelência: você pode atribuir a cada equipe o próprio espaço no Kibana e restringir o acesso para consultar apenas os projetos específicos dos seus clientes, garantindo experiências personalizadas para cada tenant. Analistas ainda podem alterar manualmente o escopo durante uma investigação se precisarem de uma visão mais ampla.

Você pode configurar esse padrão do Space antes ou depois de vincular seus projetos na UI da nuvem. Mas como o CPS ativa imediatamente o comportamento de "pesquisar tudo" assim que um link é criado, definir seus padrões de Kibana primeiro garante que suas regras de detecção existentes não sejam executadas repentinamente contra um enorme conjunto global de dados e sobrecarreguem sua equipe.

Uso de tags em pesquisas

Além de usar tags para roteamento de projetos, você também pode usar tags nas suas consultas ES|QL e _search. Isso pode ser útil para identificar de onde veio cada registro ou linha em um conjunto de resultados, ou para ordenar, filtrar ou agregar por essas tags.

Por exemplo, se você quiser ver de qual projeto cada linha em uma resposta ES|QL veio, você pode adicionar a tag _project._alias à consulta ES|QL:

E isso permite que você use _project._alias em outras partes da consulta, incluindo cláusulas KEEP para que ela apareça no resultado final:

Para mais exemplos de uso de tags em consultas, veja este documento que descreve como usá-las tanto em APIs de busca quanto no ES|QL.

Se você tem interesse em saber detalhes técnicos de como adicionamos tags às consultas do Search e ES|QL, veja busca mais rápida entre projetos no Elasticsearch Serverless com tags de projeto e roteamento.

Como a busca entre projetos lida igualmente com projetos de origem e vinculados

Se você já usou CCS, talvez saiba que o cluster local é tratado de forma diferente dos clusters remotos em alguns aspectos.

• Erros do cluster local são tratados de forma diferente dos erros dos clusters remotos. Em particular, o CCS usa a configuração skip_unavailable para controlar como os erros de clusters remotos se comportam, mas essa configuração não existe para o cluster local.

• O cluster local não tem um "alias de cluster", então a expressão de índice *:logs* pesquisa todos os projetos remotos, mas ignora o cluster local. Para buscar ambos, você precisa usar a expressão de índice logs*,*:logs*.

No CPS, mudamos ambos os comportamentos para colocar o projeto de origem e os projetos vinculados em um nível mais equilibrado.

Primeiro, a configuração skip_unavailable não é usada no Elastic Cloud Serverless. Em vez disso, você controla se deseja resultados parciais em uma busca via o parâmetro allow_partial_search_results em _search ou _async_search ou o parâmetro allow_partial_results em ES|QL.

Segundo, no Elastic Cloud Serverless, o projeto de origem tem um alias de projeto. Ele é definido no Elastic Cloud assim como todas as tags de projeto. Assim, no CPS, todas as consultas abaixo são equivalentes, elas direcionam todos os projetos com um índice de "logs":

Observação: existe uma diferença importante entre a expressão de índice qualificada *:logs e a expressão não qualificada logs em termos de como funciona o tratamento de erros em torno de índices ausentes. Para mais detalhes, consulte Expressões de pesquisa não qualificadas e qualificadas na documentação pública.

Controle de acesso e modelo de segurança para fazer busca entre projetos

A Elastic criou um novo modelo de segurança baseado na nuvem, o Gerenciamento universal de identidade e acesso (UIAM), que permite um princípio fundamental para a busca entre projetos: os projetos e dados que você pode acessar não dependem de onde você os acessa.

Independentemente de você iniciar uma pesquisa em seu projeto de observabilidade principal ou em um projeto de análise ad hoc, seu acesso aos dados vinculados permanece consistente, pois os direitos de acesso foram definidos em um local centralizado. O modelo de autenticação e autorização baseado em nuvem utiliza o serviço UIAM em nuvem para garantir que suas permissões de acesso sejam uniformes, independentemente do projeto de origem.

Experimente a busca entre projetos

Por fim, o Elastic Cloud Serverless e o CPS juntos reduzem o atrito operacional e oferecem opções adicionais para organizar os dados com base em considerações lógicas, em vez de considerações físicas ou operacionais. A busca entre projetos permite que seus usuário se concentrem exclusivamente na organização lógica dos dados, oferecendo uma experiência de busca unificada sem as complexidades físicas do passado.

Hoje, essa história fica muito mais simples. Chaves de API do Elastic Cloud agora podem ser usadas para autenticar diretamente em comparação a APIs do Elasticsearch e Kibana no Elastic Cloud Serverless. Agora você pode usar uma única credencial para gerenciar os recursos da sua organização e executar operações de dados, como a Elasticsearch Query Language (ES|QL), ingestão de dados e alertas.

Vamos ver por que construímos isso, como projetamos uma camada de identidade distribuída globalmente para possibilitar o recurso e como ele estabelece a base para a busca entre projetos.

O ônus da gestão de segredos

Construir pipelines confiáveis de CI/CD, fluxos de trabalho GitOps ou automação Terraform em plataformas de dados tem um custo oculto: a proliferação de segredos.

No modelo anterior, os desenvolvedores lidavam com uma história de autenticação desarticulada:

• Plano de controle (chaves da API do Elastic Cloud): chaves com escopo organizacional usadas para criar projetos, convidar usuários e gerenciar as cobranças via API do Elastic Cloud.

• Plano de dados (chaves da API do Elasticsearch): Chaves com escopo de projeto criadas dentro de um projeto Serverless específico para interagir com as APIs do Elasticsearch e do Kibana.

Nesse caso, seu script de implantação precisava se autenticar no Elastic Cloud, provisionar um projeto Serverless, extrair uma chave de API do Elasticsearch recém-criada desse projeto específico e, em seguida, inserir essa segunda chave na aplicação ou na ferramenta de automação mais adiante, o que resultava em pipelines complexos, logs de auditoria fragmentados e maior risco de vazamento de credenciais.

Autenticação unificada no Elastic Cloud Serverless

Com este lançamento, a separação para projetos Serverless foi eliminada. Agora você pode criar uma chave de API do Elastic Cloud explicitamente autorizada para nuvem, Elasticsearch e Kibana APIs.

• Antes: a chave de API do Elastic Cloud era estritamente um token do plano de controle. Ela podia criar projetos, gerenciar cobranças e convidar usuários, mas tinha um limite rígido; não podia ser usada para chamar as APIs do Elasticsearch nem Kibana dentro desses projetos. Você sempre precisava de uma segunda chave específica do projeto para operações de dados.

• Agora: ao ter acesso a nuvem, Elasticsearch e a API Kibana ao criar uma chave de API do Elastic Cloud, o limite rígido é retirado para o Serverless. Essa chave de API se torna uma credencial verdadeiramente unificada. Ela mantém a capacidade de gerenciar a infraestrutura da sua organização, ao mesmo tempo que ganha acesso nativo para consultar, ingerir e analisar dados em qualquer projeto Serverless autorizado.

Ao unificar tudo sob uma única chave de API do Elastic Cloud, você ganha uma única identidade que pode ter escopo definido, ser auditada, rotacionada e revogada como uma unidade. Cada chamada de API, seja para provisionar um novo projeto ou executar uma consulta ES|QL, aparece sob a mesma credencial nos seus logs de auditoria, fornecendo um único rastro a ser seguido durante investigações de incidentes ou revisões de conformidade. A rotação de credenciais agora é feita em uma etapa em vez de ser uma atualização coordenada em segredos separados do plano de controle e do plano de dados. E, como as alocações de função são por projeto, uma só chave pode abranger vários projetos, gerenciando a ingestão no seu projeto de observabilidade e executando consultas no seu projeto de segurança, sem precisar lidar com credenciais separadas para cada um.

Importante: unificado não significa todo-poderoso. Ao usar a carga útil role_assignments, você pode definir uma chave unificada estritamente para um único projeto e uma função específica (como somente leitura), garantindo que o raio de explosão continue totalmente contido caso uma credencial seja exposta. Se um desenvolvedor sair ou uma aplicação for desativada, você pode revogar uma única chave do console Elastic Cloud, encerrando imediatamente o acesso tanto no plano de controle quanto em todos os projetos Elasticsearch associados.

(Atenção: nas implantações Elastic Cloud Hosted/gerenciadas, as chaves da API da nuvem ainda gerenciam apenas o plano de controle. O suporte para estender isso às APIs de pilha hospedada está planejado para uma versão futura.)

Automatizando seus fluxos de trabalho

Começar é simples. Você pode configurar inteiramente no console Elastic Cloud ou automatizar usando a API do Elastic Cloud.

O processo da IU não muda, mas agora você pode selecionar Nuvem, Elasticsearch e API Kibana na alocação de função do projeto.

Veja como criar uma chave unificada programaticamente usando a API do Elastic Cloud. Observe o application_roles conjunto, pois é o que concede ao principal acesso nativo ao plano de dados do Elasticsearch:

Uma vez criado, você passa exatamente essa mesma chave no cabeçalho Authorization: ApiKey tanto para api.elastic-cloud.com quanto para seus endpoints específicos do Serverless Elasticsearch.

Nos bastidores: construindo uma camada de identidade distribuída

Fazer uma chave da API da nuvem funcionar tanto no plano de controle quanto no plano de dados não é tão simples como passar um token. É preciso resolver um desafio fundamental nos sistemas distribuídos.

Historicamente, as chaves de API da nuvem ficavam em um cluster de segurança global centralizado. Isso funciona nas operações de plano de controle cuja latência mais alta é aceitável. No entanto, requisições de dados do Elasticsearch exigem latência ultrabaixa. Não podemos viajar pelo globo até um plano de controle central para validar cada busca ou solicitação de ingestão.

Para resolver, introduzimos uma nova arquitetura de autenticação apoiada por um datastore distribuído globalmente. O diagrama sequencial a seguir mostra um cliente enviando uma consulta Elasticsearch, usando uma chave API do Elastic Cloud, ilustrando como a autenticação ocorre inteiramente dentro da região, sem a viagem por todo o plano de controle global. O Elasticsearch delega a autenticação ao Serviço IAM Regional, que valida a chave e resolve as alocações de função em uma réplica local do banco de dados distribuído globalmente. Uma vez autorizado, o Elasticsearch executa a consulta e retorna os resultados ao cliente.

Persistência distribuída globalmente

Em vez de depender exclusivamente de um cluster de segurança centralizado, as chaves de API do Elastic Cloud e as respectivas definições de função agora ficam em um banco de dados globalmente distribuído e de alta disponibilidade. Esse banco de dados sincroniza os dados de gerenciamento de identidade e acesso (IAM) no plano de controle global e nos planos de dados regionais onde seus projetos Serverless são executados.

Validação local com IAM regional

Quando seu cliente envia uma requisição para o Elasticsearch usando uma chave API do Elastic Cloud, a solicitação não retorna ao plano de controle global. Em vez disso, ela é encaminhada para o novo serviço regional IAM. Ele valida a chave em relação à réplica do banco de dados local, garantindo que a autenticação ocorra com latência quase zero e completamente isolada de interrupções no plano de controle global.

Mapeamento dinâmico de funções

A autenticação é metade do caminho; o sistema também precisa autorizar a solicitação. O serviço IAM regional traduz na hora suas alocações de função no nível da nuvem, por exemplo, application_roles), em privilégios nativos do Elasticsearch. O Elasticsearch pode então autorizar e executar a solicitação no local, sem precisar de um .security índice local.

A base para a busca entre projetos

Essa arquitetura de identidade distribuída é um elemento fundamental para o futuro da plataforma Elastic.

Como a identidade e o acesso agora estão unificados e sincronizados globalmente, temos o framework necessário para transmitir sua identidade com segurança entre diferentes projetos. Isso possibilita as futuras capacidades de Busca Cruzada por Projetos (CPS) para Serverless.

Com o CPS, você poderá consultar dados que abrangem vários projetos Serverless remotos, como combinar cargas de trabalho de segurança e observabilidade, como se fossem um único conjunto de dados. Ao depender de chaves de API unificadas, o sistema pode avaliar automaticamente suas permissões simultaneamente em todos os projetos, sem exigir que você configure relacionamentos de confiança complexos, certificados ou credenciais duplicadas em cada projeto-alvo.

Saiba mais

Pronto para simplificar sua pilha?

• Leia a documentação das chaves de API do Elastic Cloud para aprender como atribuir acesso ao stack.

• Confira a referência Criar chave de API (Elastic Cloud API) para automatizar a geração de chaves.

• Consulte Chaves de API Elastic para uma comparação completa dos tipos de chave em toda a plataforma Elastic.

Comece ou continue construindo no Elastic Cloud hoje.

Aviso de isenção

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.

A festa está ficando cheia

Você está organizando uma festa da pizza. Você tem alguns amigos ajudando a servir, cada um em diferentes pontos da sala. Você dá uma pizza para cada amigo, e eles começam a distribuir fatias para os convidados famintos conforme chegam.

No começo, as coisas correm tranquilamente. Alguns convidados vão chegando, seus amigos servem as fatias, e todo mundo fica feliz. Mas então a notícia sobre suas pizzas de massa fermentada começa a se espalhar. A campainha continua tocando. Os convidados chegam em massa. Logo, uma multidão começa a se formar em torno de um de seus amigos, aquele que está segurando a pizza de pepperoni, que todo quer.

Seu amigo com a pizza de pepperoni está sobrecarregado. Os convidados estão esperando, ficando impacientes, e uma grande fila se formou. Enquanto isso, seu amigo segurando a pizza margherita está parado com quase ninguém pedindo uma fatia.

O que você faz?

Você pede mais algumas pizzas de pepperoni e as entrega para outros amigos. Agora, três amigos estão segurando fatias de pepperoni em vez de um. A multidão se espalha e, de repente, você pode servir três vezes mais convidados ao mesmo tempo.

Algumas coisas ficam claras conforme você organiza mais festas:

• Nem todas as pizzas são igualmente populares. Algumas têm alta demanda, enquanto outras têm menos interessados. Você não precisa de "cópias" extras das impopulares; você precisa de mais das que têm filas.

• Peça mais pizzas antes que a fila fique muito longa. Se esperar até que seu amigo esteja completamente sobrecarregado e os convidados estejam indo embora com raiva, você já esperou demais. Melhor pegar uma pizza extra quando você vê uma multidão se formando.

• Não jogue as pizzas fora muito rápido. Só porque a multidão ao redor do pepperoni diminuiu por cinco minutos não significa que a correria acabou. Talvez eles estejam apenas reabastecendo as bebidas, ou até conversando entre si (isso ainda existe?). Mantenha as pizzas extras prontas. Se a pausa continuar por um tempo, você pode guardá-las.

• Você só pode distribuir tantas pizzas quanto o número de amigos que estão ajudando. Se você só tem quatro amigos ajudando, dez pizzas não mudarão o resultado. Apenas quatro podem ser servidas de uma vez. Ajuste a quantidade de pizzas ao número de mãos disponíveis.

• Quando um amigo for embora, pegue a pizza dele. Se algum dos seus amigos precisar sair, pegue a pizza dele imediatamente. Você não pode deixar pizzas sem vigilância. Entregue para outra pessoa ou guarde.

De pizzas a réplicas

Vamos mapear isso de volta para o Elasticsearch.

Na nossa analogia, as pizzas são réplicas (cópias dos seus shards de índice), seus amigos ajudando a servir são nodes de busca, convidados famintos são consultas de busca e aquela pizza popular com uma multidão ao redor é um índice em alta com alta carga de busca.

Quando o tráfego de busca aumenta em um índice específico, criamos réplicas adicionais e as distribuir entre seus nodes de busca. Qualquer réplica pode atender a qualquer consulta para esse índice, assim como qualquer amigo com pepperoni pode distribuir fatias de pepperoni. Mais réplicas significam maior rendimento: três réplicas podem lidar com três vezes mais consultas por segundo de uma única réplica.

Medindo a fome

Antes de decidirmos quantas pizzas pedir, precisamos saber o quão faminta está a multidão.

O Elasticsearch rastreia a carga de busca para cada shard. É uma métrica que captura quanta atividade de busca um shard está gerenciando. Agregamos isso em todos os shards de um índice para entender a demanda total de busca.

O que mais importa é a carga relativa de busca: qual a proporção do tráfego total de busca do seu projeto está atingindo cada índice? Se um índice recebe 60% de todas as buscas enquanto outro recebe 5%, sabemos onde adicionar capacidade.

A matemática por trás das pizzas

Calculamos o número ótimo de réplicas seguindo esta fórmula:

Onde:

• L = a carga de pesquisa relativa do índice (entre 0 e 1).

• N = o número de nodes de busca desejados em seu projeto.

• S = o número de fragmentos no índice.

• X = um limite para evitar pontos em alta (padrão: 0,5).

Um exemplo: quatro nós de busca, um índice com dois shards principais recebendo 80% do tráfego de busca:

Este índice em alta possui quatro réplicas distribuídas pelos nodes de busca.

O limiar X (padrão para 0,5) é importante. Não esperamos até que uma réplica seja completamente sobrecarregada; redimensionamos quando está com metade da capacidade. Distribua a pizza extra quando vir a multidão se formando, não quando os convidados já estiverem saindo.

Aumente rápido, reduza devagar.

Quando a carga de busca aumenta, adicionamos réplicas imediatamente. Não há motivo para deixar os usuários esperando.

Quando a carga de busca diminui, esperamos um pouco antes de agir. Precisamos ver uma demanda consistentemente baixa por cerca de 30 minutos antes de reduzir as réplicas. (Isso é para lidar com o tráfego irregular, onde um momento de silêncio não significa que a festa acabou.)

Isso é importante porque adicionar uma réplica tem um custo. A nova réplica copia os dados e esquenta seus caches antes de atender as consultas de forma eficiente. Remover réplicas de forma precipitada significa pagar constantemente esse custo inicial, já que o tráfego naturalmente flutua.

Respeitando os limites da topologia

As réplicas nunca podem exceder o número de nós de busca. Ter mais réplicas do que nós não traz benefício (você só pode servir tantas pizzas quanto amigos ajudam a servir fatias).

Quando nós são removidos do seu projeto, reduzimos as réplicas imediatamente para acompanhar. Sem esperar o cooldown, já que você não pode ter réplicas não atribuídas. No momento em que um amigo vai embora, removemos a pizza dele.

O panorama maior do Serverless

As réplicas para balanceamento de carga de busca funcionam junto com outros sistemas de autoescalonamento:

• O autoescalonamento de busca ajusta o número de nós de busca (quantos amigos estão ajudando).

• Réplicas para balanceamento de carga em buscas distribuem o tráfego ajustando a quantidade de réplicas por índice (quantas "pizzas" de cada tipo precisamos).

• O particionamento automático de fluxo de dados otimiza a quantidade de shards para gravações (como dividir cada pizza, explicado na postagem anterior).

Um princípio importante de design: réplicas para balanceamento de carga não acionam diretamente o autoescalonamento da busca. Em vez disso, ao distribuir as requisições de busca entre mais réplicas, isso permite aumentar a utilização de recursos entre seus nós de busca. Essa maior utilização então ativa nossa lógica de autoescalonamento existente para aumentar a capacidade, se necessário. Réplicas para balanceamento de carga permitem que o autoescalonamento faça seu papel, garantindo que seus nós de busca estejam realmente sendo usados, em vez de ter todo o tráfego preso em uma única réplica enquanto outros nós ficam parados.

O que isso significa para você

Você não precisa prever quais índices serão populares. Você não precisa ajustar as réplicas manualmente quando os padrões de tráfego mudam. Você não precisa acordar às 3 da manhã porque um pico sobrecarregou seu índice mais ocupado.

O sistema observa onde as filas estão se formando e pede mais pizzas para esses lugares. Índices em baixa não desperdiçam recursos com réplicas desnecessárias. Os índices em alta recebem a capacidade necessária. Seu orçamento vai aonde realmente importa.

Conclusão

Na postagem sobre particionamento automático, garantimos que suas pizzas sejam cortadas corretamente. Agora, com réplicas para balanceamento de carga de busca, garantimos que você tenha pizzas suficientes, nas mãos certas, quando as multidões famintas chegarem.

Experimente Elastic Cloud Serverless e deixe a logística da pizza com a gente.

Os agentes estão ganhando força, impulsionados pelo potencial de entregar ganhos de eficiência e melhores experiências para os clientes. Mas, na prática, fornecer aos agentes o contexto correto é difícil, principalmente quando se trabalha com dados empresariais desorganizados e não estruturados. Os desenvolvedores precisam gerenciar ferramentas, prompts, estado, lógica de raciocínio, modelos e, principalmente, recuperar o contexto relevante das fontes comerciais para fornecer resultados e ações precisos. O Elastic Agent Builder oferece esses componentes essenciais para desenvolver agentes seguros, confiáveis e orientados ao contexto.

Principais funcionalidades do Agent Builder

O Agent Builder aproveita os investimentos de longo prazo da Elastic na relevância de busca e retrieval-augmented generation, e trabalha para tornar o Elasticsearch o melhor banco de dados vetorial para simplificar o desenvolvimento de agentes de IA contextuais e focados em dados.

O Agent Builder permite que você:

• Comece com um agente conversacional integrado que pode responder a perguntas, realizar análises e conduzir investigações sobre quaisquer dados no Elasticsearch.

• Passe de dados complexos não estruturados para um agente personalizado com uma experiência de desenvolvimento baseada em configuração.

• Aproveite a relevância de pesquisa híbrida de ponta por meio do ES|QL integrado ou de ferramentas personalizadas para melhorar a qualidade do contexto e a confiabilidade do agente.

• Execute fluxos de trabalho complexos (pré-visualização) como ferramentas reutilizáveis para enriquecer dados, atualizar registros, enviar mensagens e muito mais para automação baseada em regras.

• Conecte-se a fontes de dados fora do Elasticsearch usando fluxos de trabalho e MCP para correlacionar e combinar o contexto dos agentes.

• Integre-se a qualquer framework agêntico ou aplicação usando ferramentas integradas e personalizadas expostas via MCP, além da capacidade de conectar-se a MCPs externos (em pré-visualização), suporte para A2A e suporte completo à API.

• Amplie os recursos do Agent Builder com integração a soluções de terceiros, como o LlamaIndex para processamento complexo de documentos ou o Arcade.dev para acesso seguro e estruturado a ferramentas.

Para ampliar ainda mais a funcionalidade do Agent Builder, apresentamos o Elastic Workflows, nossos novos recursos de automação baseados em regras, agora em versão prévia técnica. Para tarefas organizacionais, os agentes às vezes precisam de certeza e confiabilidade de ações baseadas em regras, que geralmente são necessárias para implementar uma lógica comercial específica. O Elastic Workflows oferece aos agentes uma maneira simples e declarativa de orquestrar sistemas internos e externos para executar ações, coletar e transformar dados e contexto. Os fluxos de trabalho são totalmente componíveis, orientados a eventos e flexíveis, e podem ser expostos como ferramentas a um agente via MCP.

De dados a agentes em questão de minutos

Os agentes de desenvolvimento podem levar semanas de trabalho inicial para consolidar armazenamentos de dados separados, criar pipelines manuais, ajustar consultas e gerenciar orquestrações complexas. O Agent Builder reduz o tempo de desenvolvimento para os agentes, acabando com a necessidade de armazenamentos de dados separados, bancos de dados vetoriais, pipelines RAG, camadas de pesquisa, tradutores de consultas e orquestradores de ferramentas, permitindo que você se concentre na lógica do agente e na entrega do aplicativo.

O Agent Builder integra de forma nativa primitivas da plataforma Elasticsearch para agilizar o desenvolvimento de agentes.

• Comece com um agente conversacional integrado que pode conversar e raciocinar imediatamente com seus dados indexados.

• Integre agentes em aplicações, dashboards ou sistemas de CI/CD com acesso interativo via Kibana, APIs ou MCP e A2A.

• Crie com as ferramentas padrão para entender a estrutura dos seus dados, selecionar o índice apropriado, gerar consultas híbridas, semânticas e estruturadas otimizadas e criar visualizações configuráveis usando ES|QL com base em comandos em linguagem natural.

Para se aprofundar, veja um passo a passo prático e completo.

Crie com o Elasticsearch, uma plataforma de dados completa para engenharia de contexto

Para agentes de IA, a qualidade do contexto é essencial para fornecer raciocínio eficaz e reduzir os riscos de alucinação. Para muitos agentes de IA corporativa, os dados de negócios necessários para realizar uma tarefa são a peça fundamental de contexto. Como um armazenamento de dados altamente escalável, banco de dados vetorial e líder em relevância, o Elasticsearch já oferece muitas primitivas fortes de engenharia de contexto. A engenharia de contexto vai além da simples retrieval-augmented generation, permitindo que você personalize e redimensione como os dados são obtidos, ranqueados, filtrados e apresentados aos agentes, ajudando a reduzir ruído e ambiguidade.

O Elasticsearch oferece um mecanismo de contexto que combina busca lexical, busca vetorial e filtragem estruturada para recuperação de dados, o que melhora o desempenho do LLM ao garantir que o modelo opere em um contexto relevante e preciso. Essa capacidade é suportada por recuperação agêntica, juntamente com ferramentas integradas e lógica de busca que selecionam automaticamente os índices corretos e transformam a linguagem natural em consultas otimizadas para o contexto.

Com o Agent Builder, você garante que os agentes recebam primeiro o contexto mais útil com controles de relevância e classificação, permitindo que você ajuste a lógica de pontuação, classificação e filtragem. O Elasticsearch permite que você controle o que importa, por que importa e como é priorizado, em vez de depender de um comportamento opaco de recuperação. Tudo isso é sustentado pelo Elasticsearch como uma plataforma de dados escalável para armazenar e escalar todos os seus dados de texto, vetores, metadados, logs e muito mais em uma plataforma, facilitando o gerenciamento do contexto para os agentes.

Executar fluxos de trabalho complexos como ferramentas reutilizáveis

Enquanto agentes de IA permitem o raciocínio para tarefas complexas, grande parte da automação depende da execução confiável de ações baseadas em regras que aplicam lógica de negócios específica. O Elastic Workflows oferece uma maneira simples e declarativa de orquestrar sistemas internos e externos para realizar ações, coletar contexto ou dados e integrá-los como parte dos agentes. Definidos em YAML, os fluxos de trabalho são totalmente componíveis, permitindo que sejam tão simples ou complexos quanto o trabalho exigir. Isso oferece aos agentes uma maneira eficiente de agir em toda a plataforma e nas soluções do Elasticsearch, bem como com aplicativos de terceiros.

A integração de um fluxo de trabalho com o Agent Builder pode ser feita em três etapas (pré-requisito: habilitar fluxos de trabalho com detalhes fornecidos aqui)

1. Criar e salvar um novo fluxo de trabalho usando o editor simples baseado em YAML com autopreenchimento e testes integrados.

2. Crie uma nova ferramenta no Agent Builder com o tipo “Fluxo de trabalho” e informe uma descrição para ajudar o agente a determinar quando usar a ferramenta de fluxo de trabalho.

3. Adicione a ferramenta de fluxo de trabalho ao seu agente personalizado.

4. É isso aí! Agora o agente pode chamar o fluxo de trabalho dentro de uma conversa.

Seu agente, suas regras

O Agent Builder não te prende a um único paradigma de desenvolvimento. Em vez disso, ele foi projetado para permitir abordagens de desenvolvimento abertas e flexíveis para agentes com controle total de dados, relevância, modelos, interoperabilidade, security e design de agentes.

As definições de agentes personalizados permitem que você escolha exatamente quais ferramentas um agente pode acessar, incorpore avisos de sistema personalizados, adapte as instruções do agente e defina limites de segurança. Os agentes permanecem independentes do modelo, permitindo que você configure com flexibilidade um LLM preferido, tanto nativo quanto em todo o ecossistema, sem ficar preso a um único provedor.

Crie ferramentas extensíveis que encapsulem lógica específica do domínio (por exemplo, filtros de índice específicos, junções ES|QL, pipelines analíticos) e restrinja-as para uso seguro em produção. O suporte completo à API permite a interoperabilidade com outras frameworks de agentes, com suporte nativo ao Protocolo de Contexto do Modelo (MCP). A integração A2A significa que você pode expor seus agentes Elastic a outros frameworks, serviços e apps clientes, reutilizando a mesma lógica de engenharia de dados e contexto em todas as integrações.

O Agent Builder suporta desenvolvimento flexível e aberto e foi projetado para se integrar com frameworks e plataformas populares de agentes. Essas integrações podem ser essenciais para entregar agentes eficazes. Como descreve Sam Partee, cofundador da Arcade.dev,

"Sistemas agênticos falham hoje porque conectar IA a ferramentas e dados é algo complexo. O Elastic Agent Builder com Arcade.dev oferece aos desenvolvedores uma maneira estruturada e segura de lidar com a forma como os agentes recuperam o contexto, raciocinam e agem, levando os agentes da demonstração ao nível de produção."

O Agent Builder também aproveita a extensibilidade do Elasticsearch para lidar com dados complexos. Como descreve Jerry Liu, CEO da LlamaIndex ,

“Extrair o contexto empresarial de fontes de dados não estruturadas é fundamental para a criação de agentes eficazes. O Elastic Agent Builder combinado com o processamento de documentos complexos do LlamaIndex fortalece a camada fundamental de contexto, ajudando as equipes a recuperar, processar e preparar dados para que os agentes possam raciocinar com mais precisão e oferecer melhores resultados."

O que você pode construir?

O Agent Builder já está sendo usado para vários casos de uso. Abaixo estão alguns exemplos e arquiteturas de referência para começar a usar agentes:

• Automatizar infraestrutura: em cenários de suporte, os agentes têm sido usados para ler, pensar e conversar, mas até o momento, eles não conseguem acessar e tocar a infraestrutura que possam precisar gerenciar. A equipe de engenharia da Elastic criou um agente para gerenciamento automatizado de infraestrutura como parte de um hackathon. O agente investiga ativamente problemas com a infraestrutura da aplicação e age de forma automatizada. Ele usa fluxos de trabalho para otimizar configurações, responder a problemas e redimensionar recursos, tudo com base em uma compreensão inteligente dos logs de infraestrutura.

• Análise de ameaças à segurança: um agente de vulnerabilidade de segurança foi desenvolvido com Elastic Agent Builder, MCP e Elasticsearch. Ele automatiza a análise de ameaças correlacionando dados de segurança internos com inteligência de ameaças externa. O agente realiza buscas semânticas em incidentes e configurações históricas, amplia os resultados com dados da internet em tempo real e aplica o raciocínio LLM para avaliar a relevância ambiental, priorizar riscos e produzir medidas corretivas viáveis. Consulte a arquitetura de referência.

• Suporte técnico ao cliente: os agentes podem executar diversas tarefas de suporte, incluindo resumo de casos, identificação e criação de problemas duplicados e investigação técnica aprofundada. O Agent Builder permite isso com uma pesquisa híbrida de várias etapas para encontrar somente os problemas, soluções e procedimentos relacionados mais relevantes e formular hipóteses de causa raiz e planos de remediação. O Agent Builder pode simplificar a arquitetura de sistemas de suporte complexos e acelerar o tempo de entrega.

• Descoberta de produtos e conteúdo: o Agent Builder simplifica o processo de expor catálogos complexos de produtos para experiências conversacionais, ao mesmo tempo em que permite que as organizações mantenham flexibilidade para incluir a própria lógica e requisitos de negócios.

• Crie você mesmo: participe do Hackathon do Agent Builder, que ocorrerá de 22 de janeiro a 27 de fevereiro de 2026. Trabalhe com a comunidade para criar agentes de IA orientados por contexto e em várias etapas que combinem buscar, fluxos de trabalho, ferramentas e raciocínio para automatizar tarefas do mundo real*

Comece a criar agentes personalizados agora

Comece com um teste do Elastic Cloud e confira a documentação aqui. Para clientes existentes, o Agent Builder está disponível no Cloud Serverless e no nível Empresarial no Elastic Cloud Hosted e autogerenciado.

* Clique aqui para ver os termos, condições e requisitos de elegibilidade para o hackathon

Concluímos um grande upgrade na infraestrutura de todos os projetos Elastic Cloud Serverless executados na AWS, migrando para hardware mais novo e mais rápido. Essa mudança foi implementada automaticamente em todos os projetos sem servidor. Ele oferece maior taxa de transferência e menor latência em projetos sem servidor com Elasticsearch, Elastic Observability e Elastic Security na AWS.

Principais benefícios de desempenho para desenvolvedores

A nova infraestrutura de hardware da AWS sustenta tudo o que você faz com o Elastic Cloud Serverless, traduzindo-se em benefícios tangíveis para a velocidade e a capacidade de resposta das suas aplicações.

Latência reduzida nas consultas… aumento no rendimento

O hardware aprimorado aumenta drasticamente a velocidade dos recursos de computação, o que significa que suas consultas de busca são processadas mais rápido do que nunca.

• Busca e busca vetorial: seja executando consultas de texto completo tradicionais ou usando a busca vetorial de ponta para suas aplicações de IA generativa e retrieval-augmented generation (RAG), você verá uma redução significativa na latência. O benchmarking interno mostrou uma redução média de 35% na latência de busca.

• Indexação mais rápida: as taxas de ingestão de dados são otimizadas, permitindo que você indexe volumes massivos de dados e documentos complexos com maior taxa de throughput. Isso é crucial para aplicações que exigem visibilidade de dados em quase tempo real. Benchmarking interno mostrou um aumento médio de 26% na taxa de throughput de indexação.

Desempenho consistente sob carga

O Elastic Cloud Serverless foi projetado para escalar automaticamente de forma dinâmica em tempo real para atender à demanda, minimizando a latência, independentemente da sua carga de trabalho. Com esse upgrade no hardware, esse redimensionamento agora é mais eficiente e responsivo.

• Lidando com picos com facilidade: seja enfrentando um aumento repentino no tráfego de usuários ou uma ingestão massiva de dados em lote, a nova infraestrutura garante que seus recursos de busca e indexação sejam redimensionados de forma mais eficiente para manter uma latência consistentemente baixa.

• Desacoplamento otimizado de computação e armazenamento: a arquitetura sem servidor separa computação e armazenamento, permitindo que cargas de trabalho sejam redimensionadas de forma independente para desempenho ideal e eficiência de custos. O hardware mais rápido aprimora a camada de computação, maximizando a eficiência desse design desacoplado.

Por trás do capô: resultados internos de benchmarking

Para quantificar o impacto do nosso upgrade de infraestrutura da AWS, a equipe de engenharia da Elastic realizou um benchmarking interno abrangente em relação a uma variedade de cargas de trabalho sem servidor. Essas cargas de trabalho forneceram evidências empíricas de melhorias no desempenho que você pode esperar em todas as suas aplicações, independentemente do seu caso de uso.

A abordagem de benchmarking

Concentramos nossos testes nas principais métricas que afetam diretamente a experiência do desenvolvedor e a capacidade de resposta da aplicação: tempo de resposta (ou seja, latência) e taxa de transferência em operações de busca e indexação.

• Cargas de trabalho testadas: os testes incluíram operações de busca de alta concorrência típicas de aplicações voltados para o usuário, consultas de busca vetorial complexas e ingestão/indexação de dados de alto volume para casos de uso de observabilidade e segurança. Em particular, nossa metodologia de teste usou publicamente conjuntos de dados disponíveis para o Rally, a ferramenta de benchmarking da Elastic.

  • wikipedia: Um conjunto de dados derivado de um snapshot do conteúdo textual da Wikipédia, para medir o desempenho em busca de texto de uso geral.

  • MSMARCO-Passage-Ranking: Um conjunto de dados derivado do Machine Reading Comprehension (MS MARCO) da Microsoft, para medir o desempenho da busca em campos vetoriais esparsos.

  • OpenAI_Vector: Um conjunto de dados derivado do NQ do BEIR e enriquecido com embeddings gerados pelo modelo text-embedding-ada-002 da OpenAI, para medir o desempenho da busca em campos vetoriais densos.

• Medição: comparamos o desempenho na infraestrutura antiga e na nova, medindo a latência no 99º percentil (P99) para capturar o pior caso, o desempenho da latência de cauda e as operações por segundo. Cada pista era executada cinco vezes em cada perfil de hardware para garantir consistência nos resultados.

• A meta: nosso objetivo era validar a capacidade da infraestrutura de fornecer um desempenho consistentemente mais rápido e previsível em todos os aspectos, mesmo durante períodos de rápida expansão automática.

Resumo de dados de desempenho

Os resultados confirmam ganhos significativos em eficiência e velocidade. Essas melhorias se traduzem diretamente em tempos de resposta mais baixos para os seus usuários e custos operacionais mais baixos, como resultado da capacidade de concluir a mesma quantidade de trabalho com menos recursos computacionais.

As tabelas a seguir detalham as melhorias quantitativas. Valores mais altos são melhores para a throughput; valores mais baixos são melhores para a latência.

Procurando resultados de benchmarks:

Benchmark

Comparação

Infraestrutura antiga

Nova infraestrutura

Diferencial

`wikipedia` (texto simples)

Throughput da operação de buscar (ops/s)

729

1.107

+52%

`wikipedia` (texto simples)

Latência da operação de busca (p99, ms)

56

35

-37%

`MSMARCO-Passage-Ranking` (vetores esparsos)

Throughput da operação de buscar (ops/s)

22

31

+40%

`MSMARCO-Passage-Ranking` (vetores esparsos)

Latência da operação de busca (p99, ms)

108

67

-38%

`OpenAI_Vector` (vetores densos)

Throughput da operação de buscar (ops/s)

475

624

+31%

`OpenAI_Vector` (vetores densos)

Latência da operação de busca (p99, ms)

35

22

-37%

Resultados de benchmarks de indexação:

Benchmark

Comparação

Infraestrutura antiga

Nova infraestrutura

Diferencial

`wikipedia` (texto simples)

Throughput da operação de buscar (ops/s)

2845

3.220

+13%

`wikipedia` (texto simples)

Latência da operação de busca (p99, ms)

1769

1.120

-37%

`MSMARCO-Passage-Ranking` (vetores esparsos)

Throughput da operação de buscar (ops/s)

7.087

8.900

+26%

`MSMARCO-Passage-Ranking` (vetores esparsos)

Latência da operação de busca (p99, ms)

824

677

-18%

`OpenAI_Vector` (vetores densos)

Throughput da operação de buscar (ops/s)

2972

3187

+7%

`OpenAI_Vector` (vetores densos)

Latência da operação de busca (p99, ms)

2.946

2.944

0%

O bônus adicional: redução de custos

Embora nosso foco seja entregar desempenho de baixa latência, a eficiência do novo hardware também tem um impacto direto e positivo nos custos dos projetos Elasticsearch.

O preço do Elasticsearch Serverless é baseado no uso, o que significa que você paga apenas pelos recursos de ingestão e buscas que você consumir. Como o hardware mais novo e mais rápido é mais eficiente, suas cargas de trabalho geralmente concluem tarefas usando menos recursos, levando a uma redução de custo inerente à maioria dos projetos. Você recebe um aumento de desempenho premium sem o preço premium — a definição de eficiência otimizada.

O que isso significa para você, o desenvolvedor?

Esse upgrade na infraestrutura é totalmente gerenciado pela Elastic, então você não precisa mexer um dedo — sem migrações e sem mudanças de configuração. A melhoria é imediata e automática em todos os seus projetos sem servidor baseados na AWS.

Esse upgrade permite que você:

• Construa aplicações mais rápidas: foque a agilidade no desenvolvimento de recursos, sabendo que sua plataforma de busca está entregando a velocidade que seus usuários exigem.

• Inove com confiança: implante novos recursos de busca, observabilidade e segurança, incluindo recursos complexos de IA, como busca vetorial e classificação por relevância, com a garantia de que a plataforma possa lidar com a carga em desempenho máximo.

• Simplifique sua pilha: use um serviço totalmente gerenciado que lide com o gerenciamento da infraestrutura, o planejamento da capacidade e o redimensionamento, para que você possa se concentrar no código e nos dados.

1. Clone o repositório: Baixe o código da ferramenta do GitHub usando git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent ae navegue até o diretório com cd serverless-ai-agent.

2. Configurar ambiente: Crie um ambiente virtual (opcional) com python -m venv venv e ative-o (source venv/bin/activate ou venv\Scripts\activate no Windows). Em seguida, instale os pacotes Python necessários usando pip install -r requirements.txt.

3. Configure as credenciais: Crie um arquivo .env na raiz do projeto e preencha-o com o URL da API do Elasticsearch (ES_URL), a chave da API (API_KEY), a região (REGION) e a chave da API do OpenAI (OPENAI_API_KEY).

4. Execute a ferramenta: Execute a ferramenta executando python main.py em seu terminal. Isso iniciará o agente de IA e exibirá uma tela para que você insira seus comandos.

5. Gerencie projetos com linguagem natural: interaja com a ferramenta usando comandos em inglês simples, como "Criar um projeto serverless chamado my_project", "Obter o status do projeto serverless chamado my_project" ou "Excluir o projeto serverless chamado my_project". A IA interpretará seus comandos e executará as funções correspondentes.

Histórico

Esta pequena ferramenta de linha de comando permite gerenciar seus projetos Serverless Elasticsearch em linguagem simples. Ele se comunica com uma IA (neste caso, a OpenAI) para entender o que você quer dizer e chamar as funções corretas usando o LlamaIndex!

O que o agente de IA Serverless do Elasticsearch pode fazer?

• Criar um projeto: Inicie um novo projeto Elasticsearch sem servidor.

• Excluir um projeto: Remove um projeto existente (sim, ele limpa tudo depois).

• Obtenha o status do projeto: verifique como está o andamento do seu projeto.

• Obtenha detalhes do projeto: Descubra todas as informações relevantes sobre o seu projeto.

Confira o código no GitHub.

Como funciona o agente de IA sem servidor do Elasticsearch

Quando você digita algo como:

"Crie um projeto sem servidor chamado my_project"

…eis o que acontece nos bastidores:

• Entrada e contexto do usuário: Seu comando em linguagem natural é enviado ao agente de IA.

• Descrição das funções: O agente de IA já conhece algumas funções — como create_ess_project, delete_ess_project, get_ess_project_status e get_ess_project_details — porque fornecemos descrições detalhadas. Essas descrições informam à IA o que cada função faz e quais parâmetros elas precisam.

• Processamento LLM: Sua consulta, juntamente com as informações da função, é enviada para o LLM. Isso significa que a IA vê:

  • Consulta do usuário: Sua instrução em linguagem simples.

  • Funções e descrições disponíveis: Detalhes sobre o que cada ferramenta faz para que você possa escolher a mais adequada.

  • Informações de contexto/histórico do chat: Como se trata de uma conversa, o sistema se lembra do que foi dito anteriormente.

• Chamada e resposta de função: A IA determina qual função chamar, passa os parâmetros corretos (como o nome do seu projeto) e, em seguida, a função é executada. A resposta será enviada a você em um formato amigável.

Resumindo, estamos enviando ao LLM tanto sua consulta em linguagem natural quanto uma lista de descrições detalhadas das ferramentas para que ele possa "entender" e escolher a ação correta para sua solicitação.

Configure o agente de IA

Pré-requisitos:

Antes de executar o agente de IA, certifique-se de que a seguinte configuração esteja correta:

1. Python (versão 3.7 ou posterior) instalado.

2. Configuração de uma conta serverless do Elasticsearch no Elastic Cloud.

3. Conta OpenAI para interagir com o modelo de linguagem.

Passos:

1. Clone o repositório:

2. Criar um ambiente virtual (opcional, mas recomendado): Se você estiver enfrentando problemas relacionados ao ambiente, pode configurar um ambiente virtual para isolamento:

3. Instale as dependências: Certifique-se de que todas as dependências necessárias estejam instaladas executando o seguinte comando:

4. Configure seu ambiente: Crie um arquivo .env Arquivo na raiz do projeto com as seguintes variáveis. Aqui está um exemplo de arquivo .env.example para te ajudar:

Certifique-se de que você tem os valores corretos para ES_URL, API_KEY e OPENAI_API_KEY. Você pode encontrar suas chaves de API nos respectivos painéis de serviço.

5. Arquivo de Projetos: A ferramenta usa um arquivo projects.json para armazenar seus mapeamentos de projetos (nomes de projetos para seus detalhes). Este arquivo será criado automaticamente caso ainda não exista.

Executando o agente de IA

Você verá uma mensagem como esta:

Digite o comando e o agente de IA fará a sua mágica! Quando terminar, digite exit ou quit para sair.

Mais alguns detalhes

• Integração com o LLM: O LLM recebe tanto a sua consulta quanto descrições detalhadas de cada função disponível. Isso ajuda a entender o contexto e a decidir, por exemplo, se deve chamar create_ess_project ou delete_ess_project.

• Descrição das ferramentas: Cada ferramenta de função (criada usando FunctionTool.from_defaults) Possui uma descrição amigável. Essa descrição está incluída no prompt enviado ao LLM para que ele "saiba" quais ações estão disponíveis e o que cada ação espera.

• Persistência: Seus projetos e seus detalhes são salvos em projects.json. Assim você não precisa inserir as informações novamente toda vez.

• Registro detalhado: O agente está configurado para o modo detalhado, o que é ótimo para depuração e para ver como suas instruções são traduzidas em chamadas de função.

Exemplo de utilização do agente de IA do Elasticsearch

Onde tudo começou

A primeira versão do Elasticsearch foi lançada em 2010 como um mecanismo de busca distribuído e escalável, permitindo aos usuários pesquisar e encontrar rapidamente informações importantes. Doze anos e mais de 65.000 commits depois, o Elasticsearch continua a fornecer aos usuários soluções testadas e comprovadas para uma ampla variedade de problemas de busca. Graças aos esforços de mais de 1.500 colaboradores, incluindo centenas de funcionários em tempo integral da Elastic, o Elasticsearch evoluiu constantemente para atender aos novos desafios que surgem na área de buscas.

No início da trajetória do Elasticsearch, quando surgiram preocupações com a perda de dados, a equipe da Elastic realizou um esforço de vários anos para reescrever o sistema de coordenação do cluster, garantindo que os dados confirmados fossem armazenados com segurança. Quando ficou claro que gerenciar índices em grandes clusters era um problema, a equipe trabalhou na implementação de uma solução ILM abrangente para automatizar esse trabalho, permitindo que os usuários predefinissem padrões de índice e ações de ciclo de vida. À medida que os usuários perceberam a necessidade de armazenar grandes quantidades de dados métricos e de séries temporais, vários recursos, como melhor compressão, foram adicionados para reduzir o tamanho dos dados. À medida que o custo de armazenamento para pesquisar grandes quantidades de dados inativos aumentava, investimos na criação de Snapshots Pesquisáveis como uma forma de pesquisar dados do usuário diretamente em armazenamentos de objetos de baixo custo.

Esses investimentos lançam as bases para a próxima evolução do Elasticsearch. Com o crescimento dos serviços nativos da nuvem e dos novos sistemas de orquestração, decidimos que é hora de evoluir o Elasticsearch para melhorar a experiência ao trabalhar com sistemas nativos da nuvem. Acreditamos que essas mudanças representam oportunidades para melhorias operacionais, de desempenho e de custos ao executar o Elasticsearch no Elastic Cloud.

Para onde estamos indo — Adotando uma arquitetura sem estado

Um dos principais desafios ao operar ou orquestrar o Elasticsearch é que ele depende de inúmeros elementos de estado persistente, sendo, portanto, um sistema com estado. Os três componentes principais são o translog, o armazenamento de índice e os metadados do cluster. Este estado significa que o armazenamento deve ser persistente e não pode ser perdido durante a reinicialização ou substituição de um nó.

A arquitetura Elasticsearch existente no Elastic Cloud precisa duplicar a indexação em várias zonas de disponibilidade para fornecer redundância em caso de interrupções. Pretendemos transferir o armazenamento persistente desses dados de discos locais para um armazenamento de objetos, como o AWS S3. Ao utilizar serviços externos para armazenar esses dados, eliminaremos a necessidade de replicação de indexação, reduzindo significativamente o hardware associado à ingestão. Essa arquitetura também oferece garantias de durabilidade muito altas devido à forma como os armazenamentos de objetos em nuvem, como AWS S3, GCP Cloud Storage e Azure Blob Storage, replicam dados entre as zonas de disponibilidade.

Ao transferir o armazenamento de índices para um serviço externo, também nos será possível reestruturar o Elasticsearch, separando as responsabilidades de indexação e pesquisa. Em vez de termos instâncias primárias e réplicas gerenciando ambas as cargas de trabalho, pretendemos ter uma camada de indexação e uma camada de busca. A separação dessas cargas de trabalho permitirá que elas sejam dimensionadas independentemente e que a seleção de hardware seja mais direcionada para os respectivos casos de uso. Isso também ajuda a resolver um desafio antigo, em que a carga de busca e a carga de indexação podem afetar uma à outra.

Após uma fase experimental e de prova de conceito que durou vários meses, estamos convencidos de que esses serviços de armazenamento de objetos atendem aos requisitos que previmos para armazenamento de índices e metadados de cluster. Nossos testes e benchmarks indicam que esses serviços de armazenamento podem atender às altas necessidades de indexação dos maiores clusters que vimos no Elastic Cloud. Além disso, armazenar os dados em um repositório de objetos reduz os custos de indexação e permite um ajuste simples do desempenho da busca. Para pesquisar dados, o Elasticsearch usará o modelo Searchable Snapshots, amplamente testado, no qual os dados são armazenados permanentemente no armazenamento de objetos nativo da nuvem e os discos locais são usados como caches para dados acessados com frequência.

Para facilitar a diferenciação, descrevemos nosso modelo atual como replicação "nó a nó". Na camada de processamento intensivo deste modelo, os shards primário e de réplica realizam o mesmo trabalho pesado para lidar com a ingestão e atender às solicitações de pesquisa. Esses nós são "com estado", pois dependem de seus discos locais para persistir com segurança os dados dos fragmentos que hospedam. Além disso, os shards primários e de réplica estão em constante comunicação para se manterem sincronizados. Isso é feito replicando as operações realizadas no shard primário para o shard de réplica, o que significa que o custo dessas operações (principalmente CPU) é incorrido para cada réplica especificada. Os mesmos fragmentos e nós que realizam esse trabalho de ingestão também atendem às solicitações de pesquisa, portanto, o provisionamento e o dimensionamento devem ser feitos levando em consideração ambas as cargas de trabalho.

Além da busca e ingestão, os shards no modelo de replicação nó a nó lidam com outras responsabilidades intensivas, como a fusão de segmentos do Lucene. Embora esse design tenha seus méritos, vimos muitas oportunidades com base no que aprendemos com os clientes ao longo dos anos e na evolução do ecossistema de nuvem em geral.

A nova arquitetura possibilita diversas melhorias imediatas e futuras, incluindo:

1. É possível aumentar significativamente a taxa de transferência de ingestão no mesmo hardware ou, visto de outra forma, melhorar significativamente a eficiência para a mesma carga de trabalho de ingestão. Esse aumento resulta da eliminação da duplicação de operações de indexação para cada réplica. As operações de indexação que exigem muito processamento da CPU precisam ocorrer apenas uma vez na camada de indexação, que então envia os segmentos resultantes para um armazenamento de objetos. A partir daí, os dados estão prontos para serem consumidos tal como estão pela camada de pesquisa.

2. Você pode separar o processamento do armazenamento para simplificar a topologia do seu cluster. Atualmente, o Elasticsearch possui vários níveis de dados (conteúdo, quente, morno, frio e congelado) para adequar os dados ao perfil de hardware. O nível "hot" é para buscas quase em tempo real, enquanto o nível "frozen" é para dados pesquisados com menos frequência. Embora esses níveis ofereçam valor, eles também aumentam a complexidade. Na nova arquitetura, as camadas de dados não serão mais necessárias, simplificando a configuração e a operação do Elasticsearch. Estamos também separando a indexação da pesquisa, o que reduz ainda mais a complexidade e nos permite dimensionar ambas as cargas de trabalho de forma independente.

3. É possível obter custos de armazenamento mais baixos na camada de indexação reduzindo a quantidade de dados que precisam ser armazenados em um disco local. Atualmente, o Elasticsearch precisa armazenar uma cópia completa do shard nos nós ativos (tanto primários quanto réplicas) para fins de indexação. Com a abordagem sem estado de indexação direta ao armazenamento de objetos, apenas uma parte desses dados locais é necessária. Para casos de uso de simples anexação, apenas determinados metadados precisarão ser armazenados para indexação. Isso reduzirá significativamente o armazenamento local necessário para a indexação.

4. Você pode reduzir os custos de armazenamento associados às consultas de pesquisa. Ao tornar o modelo de Snapshots Pesquisáveis o modo nativo de pesquisa de dados, o custo de armazenamento associado às consultas de pesquisa diminuirá significativamente. Dependendo das necessidades de latência de pesquisa dos usuários, o Elasticsearch permitirá ajustes para aumentar o armazenamento em cache local dos dados solicitados com frequência.

Benchmarking — melhoria de 75% na taxa de transferência de indexação

Para validar essa abordagem, implementamos uma extensa prova de conceito onde os dados foram indexados em um único nó e a replicação foi realizada por meio de armazenamentos de objetos na nuvem. Constatamos que poderíamos obter uma melhoria de 75% na taxa de transferência de indexação , eliminando a necessidade de dedicar hardware à replicação de indexação. Além disso, o custo de CPU associado à simples extração de dados do armazenamento de objetos era muito menor do que indexar os dados e gravá-los localmente, como é necessário para a camada de processamento ativa atualmente. Isso significa que os nós de busca poderão dedicar totalmente sua CPU à busca.

Esses testes de desempenho foram realizados em um cluster de dois nós, utilizando os três principais provedores de nuvem pública (AWS, GCP e Azure). Pretendemos continuar a desenvolver benchmarks maiores à medida que avançamos para uma implementação sem estado em produção.

Taxa de transferência de indexação

Utilização da CPU

Sem pátria para nós, economia para você.

A arquitetura sem estado do Elastic Cloud permitirá reduzir a sobrecarga de indexação, dimensionar a ingestão e a pesquisa de forma independente, simplificar o gerenciamento de camadas de dados e acelerar operações como escalonamento ou atualização. Este é o primeiro marco rumo a uma modernização substancial da plataforma Elastic Cloud.

Junte-se à nossa visão de Elasticsearch sem estado.

Interessado em experimentar esta solução antes de todos os outros? Você pode entrar em contato conosco pelo Discord ou pelo nosso canal da comunidade no Slack. Gostaríamos muito de receber seu feedback para nos ajudar a definir a direção da nossa nova arquitetura.