Para resolver isso, mecanismos de busca como o Elasticsearch utilizam duas estratégias principais de otimização:

1. Busca aproximada (mundo pequeno hierárquico navegável [HNSW]): em vez de analisar cada documento, construímos um grafo de navegação para acessar rapidamente a vizinhança provável da resposta.

2. Quantização: Compactamos os vetores (por exemplo, de floats de 32 bits para inteiros de 8 bits ou até mesmo valores binários de 1 bit) para reduzir o uso de memória e acelerar os cálculos.

Mas a otimização geralmente vem acompanhada de uma taxa: a precisão.

O medo é válido: "Se eu compactar meus dados e usar atalhos durante a busca, perderei os melhores resultados?" "Essa otimização degrada a relevância do meu mecanismo de busca?"

Para provar que a quantização do Elastic não degrada os resultados, criamos um ambiente de testes repetíveis usando o DBPedia-14 como conjunto de dados para calcular exatamente quanta precisão (especificamente, recall) sacrificamos em prol da velocidade ao usar as otimizações padrão do Elasticsearch.

Resumindo: é provavelmente muito menos do que você pensa. Confira o caderno aqui e teste você mesmo

As definições (para os não especialistas)

Antes de analisarmos o código, vamos definir alguns termos.

• Relevância versus recuperação: A relevância é subjetiva (encontrei informações úteis?). A recuperação é matemática. Se houver 10 documentos no banco de dados que correspondam perfeitamente à sua consulta, e o mecanismo de busca encontrar nove deles, sua recuperação será de 90% (ou 0,9).

• Busca exata (plana): às vezes chamada de método "força bruta". O mecanismo de busca analisa cada documento em um índice e calcula a distância.

  • Prós: recall perfeito de 100%.

  • Contras: computacionalmente caro e lento em larga escala.

• Busca aproximada (HNSW): O método do "atalho". O mecanismo de busca cria um HNSW gráfico e percorre o gráfico para encontrar os vizinhos mais próximos.

  • Prós: extremamente rápido e escalável.

  • Contras: Você pode perder um vizinho se a travessia do gráfico parar muito cedo.

O experimento: exato x aproximado

Para testar a recuperação, usamos o conjunto de dados DBPedia-14, um grande conjunto de dados de títulos e resumos em 14 classes de ontologia, muito usado para treinar e avaliar modelos de categorização de texto. Especificamente, vamos focar a categoria "Filme". Decidimos comparar as configurações otimizadas de produção com uma verdade matematicamente perfeita.

Neste experimento, estamos usando o modelo jina-embeddings-v5-text-small, um modelo multilíngue de última geração que lidera os benchmarks do setor de representação de textos. Escolhemos esse modelo porque ele define o padrão atual para embeddings de alto desempenho. Ao combinar a precisão de elite do Jina v5 com a quantização nativa do Elasticsearch, podemos demonstrar uma arquitetura de busca que é computacionalmente eficiente e sem prejudicar a qualidade da recuperação.

Configuramos um índice com mapeamento duplo. Ingerimos o mesmo texto em dois campos diferentes simultaneamente:

1. content.rawcom tipo: flat. Isso força o Elasticsearch a realizar uma varredura de força bruta dos vetores Float32 completos. Isso retorna resultados de correspondência exatos e será usado na nossa linha de base.

2. contentcom o tipo semantic_text. Com padrões usando HNSW + melhor quantização binária (BBQ). Esse é o padrão otimizado de produção para correspondência aproximada.

O teste Recall@10

Para nossa métrica, usamos o Recall@10.

Escolhemos 50 filmes aleatórios e executamos a mesma consulta nos dois campos.

• Se a busca exata (plana) indicar que os 10 principais vizinhos são IDs [1, 2, 3... 10], você pode usar a busca exata.

• E a busca aproximada (HNSW) retorna IDs [1, 2, 3... 9, 99].

• Encontramos corretamente nove dos 10 principais. A pontuação é 0,9.

Aqui está o mapeamento que usamos:

Os resultados: a "estagnação" do sucesso

Realizamos um teste de escala, recarregando todo o conjunto de dados e testando com tamanhos de índice de 1.000 a 40.000 documentos.

Veja o que aconteceu com a pontuação de recall:

Documentos

Recall@10 score

1.000

1.000 (100%)

5.000

0,998 (100%)

10.000

0,992 (99,4%)

20.000

0,999 (99,0%)

40.000

0.992 (98,8%)

Os resultados foram incrivelmente estáveis. Mesmo com o aumento da escala, a busca aproximada coincidiu com a busca exata por força bruta em mais de 99% dos casos.

Por que funcionou tão bem?

Você poderia esperar que comprimir vetores em valores binários prejudicasse mais a precisão do que isso. A razão para isso não ocorrer está em como o Elasticsearch lida com a recuperação.

A maioria dos modelos de embedding hoje gera vetores Float32, que são volumosos. Para deixar a busca eficiente, o Elasticsearch usa quantização para vetores de alta dimensionalidade. Especificamente, desde a versão 9.2, ele usa BBQ como padrão.

O BBQ usa um mecanismo de reclassificação:

1. Percurso: o mecanismo de busca utiliza os vetores comprimidos (quantizados) para percorrer rapidamente o gráfico HNSW. Como os vetores são pequenos, ele pode superamostrar com eficiência, reunindo uma lista maior de candidatos (p. ex., os 100 principais documentos aproximadamente semelhantes) sem penalidade no desempenho.

2. Reclassificação: com esses candidatos, ele recupera os valores de precisão total apenas para esses poucos documentos para calcular a classificação final e precisa.

Ele oferece o melhor dos dois mundos: rapidez na quantização para o trabalho pesado e precisão dos números de ponto flutuante para a classificação final.

Podemos fazer melhor?

É importante notar que os resultados aqui usam configurações padrão e uma amostra aleatória de dados. Pense nisso como um ponto de partida de alto desempenho. Embora o Jina v5 seja excelente, essas pontuações de recall não são garantia de que funcione em todos os conjuntos de dados. Cada coleta de dados tem as próprias peculiaridades e, embora você possa definitivamente ajustar ainda mais as coisas para ter ainda mais desempenho, deve sempre comparar seus dados específicos para saber seu limite.

Conclusão

Este é um teste em pequena escala. Mas o objetivo do exercício não é medir especificamente o modelo de embeddings nem o BBQ, e sim mostrar como medir facilmente o recall do seu conjunto de dados com o mínimo de configuração.

Se você quiser executar esse teste com seus próprios dados, pode conferir o notebook aqui e tentar você mesmo.

Imagine um gerente financeiro que precisa se atualizar antes de uma reunião com um cliente. Em vez de vasculhar manualmente os feeds de notícias e comparar painéis de portfólio, agora eles podem simplesmente fazer uma pergunta direta ao seu agente personalizado. Essa é a vantagem de uma abordagem que prioriza o bate-papo. O gestor tem acesso direto e conversacional aos seus dados, podendo fazer perguntas como: "Quais são as últimas notícias sobre a ACME Corp e como isso afeta os investimentos do meu cliente?" e obtendo uma resposta sintetizada e especializada em segundos.

Embora estejamos criando um especialista financeiro hoje, as aplicações são tão variadas quanto seus dados. O mesmo poder pode criar um analista de cibersegurança para procurar ameaças, um engenheiro de confiabilidade de sites para diagnosticar uma interrupção ou um gerente de marketing para otimizar uma campanha. Independentemente da área, a missão principal é a mesma: transformar seus dados em um especialista com quem você possa conversar.

Etapa 0: Nosso conjunto de dados

Nosso conjunto de dados hoje é um conjunto de dados sintético baseado em finanças, composto por contas financeiras, posições de ativos, notícias e relatórios financeiros. Embora sintética, ela replica uma versão simplificada de um conjunto de dados financeiro real.

financial_accountsPortfólios de clientes com perfis de risco

financial_holdingsPosições em ações/ETFs/títulos com histórico de compras

financial_asset_detailsDetalhes sobre a ação/ETF/título

financial_newsArtigos de mercado gerados por IA com análise de sentimento

financial_reportsResultados da empresa e notas dos analistas

Você pode carregar este conjunto de dados por conta própria seguindo as instruções do notebook que acompanha este documento, localizado aqui.

Etapa 1: A Base — Sua Lógica de Negócios em ES|QL

Toda habilidade de IA começa com uma base lógica sólida. Para o nosso agente de Gestão Financeira, precisamos ensiná-lo a responder a uma pergunta comum: "Estou preocupado com o sentimento do mercado." Você pode me mostrar quais dos nossos clientes correm maior risco em caso de más notícias? Essa questão vai além de uma simples pesquisa. Isso exige que correlacionemos o sentimento do mercado com as carteiras dos clientes.

Precisamos encontrar os ativos mencionados em artigos negativos, identificar todos os clientes que possuem esses ativos, calcular o valor de mercado atual da sua exposição e, em seguida, classificar os resultados para priorizar o maior risco. Essa análise complexa de múltiplas junções é a tarefa perfeita para nossa ferramenta avançada ES|QL.

Aqui está a consulta completa que usaremos. Parece impressionante, mas os conceitos são simples.

Analisando em detalhes: Junções e guarda-corpos

Nesta consulta, dois conceitos importantes entram em jogo e são essenciais para a criação do Agent Builder.

1. A junção de pesquisa

Durante anos, uma das funcionalidades mais solicitadas no Elasticsearch tem sido a capacidade de unir dados de diferentes índices com base em uma chave comum. Com ES|QL, isso agora é possível com LOOKUP JOIN.

Em nossa nova consulta, realizamos uma cadeia de três LOOKUP JOIN: primeiro conectando notícias negativas aos detalhes dos ativos, depois vinculando esses ativos às participações do cliente e, finalmente, unindo às informações da conta do cliente. Isso gera um resultado incrivelmente rico a partir de quatro índices diferentes em uma única consulta eficiente. Isso significa que podemos combinar conjuntos de dados distintos para criar uma resposta única e esclarecedora sem precisar desnormalizar todos os nossos dados em um único índice gigante antecipadamente.

2. Parâmetros como guarda-corpos LLM

Você notará que a consulta usa ?time_duration. Isso não é apenas uma variável; é uma proteção para a IA. Embora os Modelos de Linguagem de Grande Porte (LLMs, na sigla em inglês) sejam ótimos para gerar consultas, permitir que eles tenham livre acesso aos seus dados pode levar a consultas ineficientes ou até mesmo incorretas.

Ao criar uma consulta parametrizada, forçamos o LLM a funcionar dentro da lógica de negócios testada, eficiente e correta que um especialista humano já definiu. É semelhante à forma como os desenvolvedores usam modelos de pesquisa há anos para expor com segurança os recursos de consulta aos aplicativos. O agente pode interpretar a solicitação de um usuário como "esta semana" para preencher o parâmetro time_duration , mas deve usar nossa estrutura de consulta para obter a resposta. Isso nos proporciona o equilíbrio perfeito entre flexibilidade e controle.

Em última análise, essa consulta permite que um especialista que entende os dados incorpore seu conhecimento em uma ferramenta. Outras pessoas — e agentes de IA — podem então usar essa ferramenta para obter resultados correlacionados, fornecendo simplesmente um único parâmetro, sem precisar saber nada sobre a complexidade subjacente.

Etapa 2: A Habilidade — Transformar uma Consulta em uma Ferramenta Reutilizável

Uma consulta ES|QL é apenas texto até que a registremos como uma ferramenta. No Construtor de Agentes, uma ferramenta é mais do que apenas uma consulta salva; é uma "habilidade" que um agente de IA pode entender e optar por usar. A mágica está na descrição em linguagem natural que fornecemos. Essa descrição serve de ponte entre a pergunta do usuário e a lógica de consulta subjacente. Vamos registrar a consulta que acabamos de criar.

O Caminho da Interface do Usuário

Criar uma ferramenta no Kibana é um processo simples.

1. Navegue até Agentes

• Clique em Ferramentas ou Gerenciar Ferramentas e clique no botão Nova ferramenta .

2. Preencha o formulário com os seguintes dados:

• ID da ferramenta: find_client_exposure_to_negative_news

eu. Este é o ID exclusivo da ferramenta.

• Descrição: "Identifica a exposição da carteira de clientes a notícias negativas." Esta ferramenta analisa notícias e relatórios recentes em busca de sentimentos negativos, identifica o ativo associado e encontra todos os clientes que possuem esse ativo. Retorna uma lista ordenada pelo valor de mercado atual da posição para destacar o maior risco potencial."

eu. É isso que o LLM lê para decidir se essa ferramenta é a adequada para o trabalho.

• Rótulos: retrieval e risk-analysis

Etiquetas são usadas para ajudar a agrupar várias ferramentas.

• Configuração: Cole a consulta ES|QL completa da Etapa 1.

eu. Esta é a pesquisa que o agente usará.

3. Clique em Inferir parâmetros da consulta. A interface do usuário encontrará automaticamente ?time_duration e listará abaixo. Adicione uma descrição simples para cada um, para ajudar o agente (e outros usuários) a entender sua finalidade.

• time_durationO período de tempo para pesquisar notícias negativas. O formato é "X horas", com o valor padrão de 8760 horas.

4. Teste!

• Clique em Salvar e testar.

• Você verá um novo menu suspenso onde poderá testar a consulta para garantir que ela esteja funcionando conforme o esperado.

eu. Em time_duration insira o intervalo desejado; aqui, estamos usando “8760 horas”.

• Clique em “Enviar” e, se tudo correr bem, você verá uma resposta em formato JSON. Para garantir que funcione como esperado, role para baixo e observe o objeto values . É aí que os documentos correspondentes são devolvidos.

5. Clique no “X” no canto superior direito para fechar a janela de teste. Sua nova ferramenta agora aparecerá na lista, pronta para ser atribuída a um agente.

O caminho da API

Para desenvolvedores que preferem automação ou precisam gerenciar ferramentas programaticamente, é possível obter o mesmo resultado com uma única chamada de API. Basta enviar uma solicitação POST para o endpoint /api/agent_builder/tools com a definição da ferramenta.

Etapa 3: O Cérebro — Criando seu Agente Personalizado

Criamos uma habilidade reutilizável (a Ferramenta). Agora, precisamos criar o Agente, a persona que de fato irá utilizá-lo. Um Agente é a combinação de um LLM (Licença de Aprendizagem Baseada em Leis), um conjunto específico de ferramentas às quais você lhe concede acesso e, mais importante, um conjunto de Instruções Personalizadas que atuam como sua constituição, definindo sua personalidade, regras e propósito.

A Arte do Prompt

O aspecto mais importante na criação de um agente confiável e especializado é o prompt. Um conjunto de instruções bem elaborado é o que diferencia um chatbot genérico de um assistente profissional e focado. É aqui que você define as diretrizes, define a saída e atribui ao agente sua missão.

Para o nosso agente Financial Manager , usaremos o seguinte prompt.

Vamos analisar por que essa estratégia é tão eficaz:

• Define uma persona sofisticada: a primeira frase estabelece imediatamente o agente como um "Assistente de Inteligência de Dados especializado", definindo um tom profissional e competente.

• Isso fornece uma estrutura de raciocínio: ao dizer ao agente para "Compreender, Planejar, Executar e Sintetizar", estamos lhe dando um procedimento operacional padrão. Isso melhora sua capacidade de lidar com questões complexas e de várias etapas.

• Isso promove o diálogo interativo: a instrução para "fazer perguntas esclarecedoras" torna o agente mais robusto. Isso minimizará suposições incorretas sobre solicitações ambíguas, levando a respostas mais precisas.

O Caminho da Interface do Usuário

1. Navegue até Agentes.

• Clique em Ferramentas ou Gerenciar Ferramentas e clique no botão Nova ferramenta .

2. Preencha os dados básicos:

• ID do agente: financial_assistant.

• Instruções: Copie o enunciado acima.

• Rótulos: Finance.

• Nome de exibição: Financial Assistant.

• Descrição da exibição: An assistant for analyzing and understanding your financial data.

3. De volta ao topo, clique em Ferramentas.

• Marque a caixa ao lado da nossa ferramenta find_client_exposure_to_negative_news .

4. Clique em Salvar.

O caminho da API

Você pode criar o mesmo agente com uma solicitação POST para o endpoint /api/agent_builder/agents . O corpo da solicitação contém todas as mesmas informações: o ID, o nome, a descrição, o conjunto completo de instruções e uma lista das ferramentas que o agente tem permissão para usar.

Passo 4: A Recompensa — Ter uma Conversa

Temos nossa lógica de negócios encapsulada em uma ferramenta e um "cérebro" pronto para usá-la em nosso Agente. Chegou a hora de ver tudo se concretizar. Agora podemos começar a interagir com nossos dados usando um agente especializado.

O Caminho da Interface do Usuário

1. Navegue até Agentes no Kibana.

2. Utilizando o menu suspenso no canto inferior direito da janela de chat, alterne do agente padrão Elastic AI para o nosso novo agente Assistente Financeiro .

3. Faça uma pergunta que permita ao agente usar nossa ferramenta especializada:

   1. Estou preocupado com o sentimento do mercado. Você pode me mostrar quais dos nossos clientes correm maior risco em caso de más notícias?

Após alguns instantes, o agente retornará uma resposta completa e perfeitamente formatada. Devido à natureza dos LLMs, sua resposta pode ser formatada de maneira ligeiramente diferente, mas nesta execução, o agente retornou:

O que acabou de acontecer? O Raciocínio do Agente

O agente não apenas "sabia" a resposta. Executou um plano de várias etapas centrado na seleção da melhor ferramenta para o trabalho. Eis uma análise do seu processo de pensamento:

• Intenção identificada: Correspondeu a palavras-chave da sua pergunta, como "risco" e "notícias negativas", à descrição da ferramenta find_client_exposure_to_negative_news .

• Plano executado: o sistema extraiu o período de tempo da sua solicitação e fez uma única chamada para essa ferramenta especializada.

• Delegou o trabalho: a ferramenta então realizou todo o trabalho pesado: as junções encadeadas, os cálculos de valor e a classificação.

• Resultado Sintetizado: Por fim, o agente formatou os dados brutos da ferramenta em um resumo claro e legível para humanos, seguindo as regras do prompt.

E não precisamos apenas supor, se ampliarmos nosso pensamento e observarmos mais detalhes.

O caminho da API

Você pode iniciar essa mesma conversa programaticamente. Basta enviar a pergunta de entrada para o endpoint da API converse , certificando-se de especificar o agent_id do nosso financial_manager.

Para desenvolvedores: Integração com a API

Embora a interface do Kibana ofereça uma experiência fantástica e intuitiva para criar e gerenciar seus agentes, tudo o que você viu hoje também pode ser feito programaticamente. O Agent Builder é baseado em um conjunto de APIs, permitindo que você integre essa funcionalidade diretamente em seus próprios aplicativos, pipelines de CI/CD ou scripts de automação.

Os três principais endpoints com os quais você trabalhará são:

• /api/agent_builder/toolsO ponto de extremidade para criar, listar e gerenciar as habilidades reutilizáveis que seus agentes podem usar.

• /api/agent_builder/agentsO ponto final para definir as personas dos seus agentes, incluindo as importantíssimas instruções e atribuições de ferramentas.

• /api/agent_builder/converse: O ponto de acesso para interagir com seus agentes, iniciar conversas e obter respostas.

Para um passo a passo completo e prático de como usar essas APIs para executar cada etapa deste tutorial, confira o Jupyter Notebook que acompanha o tutorial, disponível aqui em nosso repositório do GitHub.

Conclusão: Sua vez de construir

Começamos por pegar numa consulta ES|QL e transformá-la numa habilidade reutilizável. Em seguida, criamos um agente de IA especializado, atribuindo-lhe uma missão e regras claras, e capacitando-o com essa habilidade. O resultado é um assistente sofisticado que consegue entender uma pergunta complexa e executar uma análise em várias etapas para fornecer uma resposta precisa e baseada em dados.

Esse fluxo de trabalho é fundamental para o novo Construtor de Agentes da Elastic. Ele foi projetado para ser simples o suficiente para que usuários sem conhecimento técnico possam criar agentes por meio da interface do usuário, mas também sofisticado o bastante para que desenvolvedores criem aplicativos personalizados com inteligência artificial utilizando nossas APIs. Mais importante ainda, permite que você conecte LLMs aos seus próprios dados de forma segura e protegida, regida pela lógica especializada que você define, e converse com seus dados.

Pronto para usar agentes para conversar com seus dados?

A melhor maneira de consolidar o que você aprendeu é colocar a mão na massa. Experimente tudo o que discutimos hoje em nossa oficina prática, gratuita e interativa. Você passará por todo esse processo e muito mais em um ambiente sandbox dedicado.

Em um post futuro do blog, mostraremos como usar um aplicativo independente que interage com nosso agente Financial Assistant e exploraremos o Protocolo de Contexto de Modelo (MCP) que torna tudo isso possível. E em um post separado, discutiremos o suporte do Agent Builder ao protocolo Agent2Agent, ou A2A, ainda em desenvolvimento.

Fiquem ligados e boas construções!