As organizações acumulam grandes coleções de documentos, como chamados de suporte, processos judiciais, notícias, artigos de pesquisa, e precisam entender o que eles contêm antes de poderem fazer as perguntas certas. Sem rótulos nem dados de treinamento, revisar manualmente milhares de documentos é impraticável. A busca tradicional não ajuda quando você não sabe o que procurar.

Esta publicação tem uma abordagem nativa do Elasticsearch para clustering de documentos não supervisionados e rastreamento de histórias temporais que lida com esse problema de descoberta. Ao final, você poderá acompanhar arcos narrativos como este ao longo de vários dias:

O que você vai descobrir:

• Por que embeddings de clustering (e não embeddings de recuperação) são importantes quando se deseja descobrir tópicos sem uma consulta?

• Como a classificação de centroides sondada por densidade agrupa documentos por tópico usando Elasticsearch k-nearest neighbor (kNN) e processamento em lote msearch.

• Como significant_text pode automaticamente rotular clusters para que os temas sejam legíveis sem precisar treinar um modelo?

• Como as cadeias temporais de histórias conectam clusters diários para mostrar como os temas evoluem dia após dia.

O pipeline utiliza ~8.500 artigos de fevereiro de 2025 da BBC News e do The Guardian como um corpus de teste. As notícias são convenientes porque apresentam um comportamento temporal claro, mas esse padrão se aplica a qualquer situação em que a descoberta de documentos seja importante: revisão jurídica, monitoramento de conformidade, síntese de pesquisas, triagem de suporte ao cliente.

Stack:

• Jina v5 clustering embeddings: adaptadores LoRA (Low-Rank Adaptation) específicos para tarefas no agrupamento de tópicos. Jina ingressou na Elastic e os modelos estão disponíveis nativamente por meio do Elastic Inference Service (EIS).

• Elasticsearch: kNN escalável, rotulagem significant_text e armazenamento de vetores.

• DiskBBQ: um formato de índice vetorial baseado em disco que combina quantização binária aprimorada (BBQ) com particionamento hierárquico k-means para aceleração aproximada de vizinhos mais próximos (ANN). Essa partição de índice é interna à busca vetorial e separada do algoritmo de clustering baseado em densidade usado nesta postagem. bbq_disk armazena vetores quantizados em disco e mantém apenas metadados de partição no heap, reduzindo os requisitos de recursos, em comparação com bbq_hnsw, mantendo alta recuperação.

• Clustering global + vinculação temporal diária: descoberta e evolução da narrativa.

O que você precisará:

• Uma implementação do Elasticsearch (Elastic Cloud, Elasticsearch Serverless ou Elastic Self-Managed 8.18+/9.0+): bbq_disk requer a versão 8.18 ou posterior. A seção opcional do diversificador retriever exige 9.3+ ou serverless.

• Uma chave de API Jina: o nível gratuito inclui 10 milhões de tokens, o que cobre o pipeline principal de clusterização (aproximadamente 4,25 milhões de tokens). A comparação opcional entre recuperação e clustering usa uma segunda passagem de incorporação.

• Uma chave de API do Guardian (gratuita).

Configuração

Instale os pacotes necessários:

Opcional (somente se você executar ferramentas de scraping deste repositório):

Depois, configure chaves de API em um arquivo .env na raiz do projeto:

Este notebook chama load_dotenv(override=True), portanto os valores locais .env têm precedência.

Parte 1: clustering de descoberta – Por que fazer clustering de embeddings?

A maioria das buscas vetoriais utiliza embeddings de recuperação treinados para associar uma consulta a documentos relevantes. Isso é perfeito para buscas, mas não para descobertas. Quando você quer descobrir quais tópicos existem em um corpus sem qualquer consulta, precisa de embeddings que agrupem documentos semelhantes.

O Jina v5 resolve isso com adaptadores Low-Rank Adaptation (LoRA) específicos para cada tarefa. O LoRa adiciona pequenas atualizações de baixa classificação às camadas internas específicas, mantendo a maioria dos pesos do modelo base congelados, de modo que o comportamento do modelo se adapta a uma tarefa específica sem a necessidade de um novo treinamento completo. O mesmo modelo base produz embeddings diferentes dependendo do parâmetro task:

Tarefa

Preparado para

Caso de uso

retrieval.passage

Correspondência entre consulta e documento

Busca, retrieval augmented generation (RAG)

clustering

Agrupamento de tópicos (otimizado para clusters compactos)

Descoberta, categorização

O adaptador de clustering é treinado para aproximar documentos sobre o mesmo tópico no espaço de incorporação e distanciar documentos sobre tópicos diferentes. A comparação visual abaixo torna a diferença concreta.

Recuperação vs. clustering: uma comparação visual

Para ver a diferença, uma amostra de documentos recebe embedding de ambos os tipos de tarefa. O clustering é realizado no espaço de incorporação original de 1024 dimensões; a aproximação e projeção uniforme de variedades (UMAP) é usada apenas para projetar essas incorporações em 2D para visualização. A UMAP preserva a estrutura local de vizinhança, tornando-a útil para comparar a separação de clusters.

Abaixo, o mesmo exemplo de 480 documentos é incorporado com ambos os tipos de tarefas e projetado para 2D com UMAP. Procure grupos de cores mais fechados e separados no painel de clustering.

Os embeddings de recuperação (à esquerda) espalham amplamente os tópicos; os embeddings de clustering (à direita) produzem grupos mais coesos e separados a partir dos mesmos documentos.

Os embeddings de clustering produzem grupos mais compactos e visualmente distintos. Os embeddings de recuperação distribuem os tópicos de maneira mais uniforme, ideais para busca (similaridade refinada); mas, para descoberta, o que importa são os clusters temáticos compactos.

É por isso que o task="clustering" é usado no restante deste guia.

Carregando o conjunto de dados

O corpus combina duas fontes de notícias para fevereiro de 2025:

• BBC News através do conjunto de dados RealTimeData/bbc_news_alltime HuggingFace.

• The Guardian através da API da Guardian Open Platform.

Ter múltiplas fontes ajuda a validar se o clustering encontra tópicos em vez de estilos específicos de cada fonte.

Embedding com a tarefa de clustering

A API Jina v5 é chamada com task="clustering" para todos os documentos. Os embeddings são armazenados em cache no disco, portanto, as execuções subsequentes ignoram a API completamente.

A chamada da API é direta. O parâmetro task é a principal diferença em relação ao uso típico de embeddings:

O tempo abaixo reflete uma taxa de acerto do cache. A primeira execução contra a API demora mais, dependendo do tamanho do corpus.

Indexação em um único índice do Elasticsearch

Para clustering de descoberta, o mês inteiro é dedicado a um índice (docs-clustering-all). A partição diária vem depois para a ligação temporal da história.

O mapeamento do índice usa bbq_disk para o campo vetorial:

Um vetor float32 de dimensão 1024 tem 4 KB. bbq_disk utiliza k-means hierárquicos para particionar vetores em pequenos clusters, quantificá-los de forma binária e armazenar os vetores de precisão total no disco para repontuação. Apenas os metadados de partição permanecem no heap, então os requisitos de memória permanecem baixos mesmo para corpora grandes. Para cargas de trabalho que podem suportar mais heap, bbq_hnsw constrói um gráfico Hierarchical Navigable Small World (HNSW) para consultas mais rápidas com mais custo de recursos.

O tipo de campo dense_vector suporta múltiplas estratégias de quantização: bbq_disk e bbq_hnsw são os melhores ajustes para embeddings de alta dimensão como os vetores de dimensão 1024 usados aqui.

Clusteringo: classificação de centroides baseada em densidade

Algoritmos de clustering tradicionais, como o HDBSCAN, pressupõem que você possa manter a matriz vetorial completa de N×d na memória e executar atualizações de passagem completa repetidas. Para 8.495 documentos em 1024 dimensões, isso é administrável (aproximadamente 35 MB), mas a abordagem não é escalável para milhões de documentos sem infraestrutura adicional.

Este algoritmo é conceitualmente semelhante à inicialização do KMeans++ com atribuição de Voronoi e um nível de ruído, mas utiliza a busca kNN do Elasticsearch como primitiva de computação, mantendo quase todo o trabalho no lado do servidor:

1. Amostra de 5% de documentos como sondas de densidade (amostra aleatória, mínimo de 50).

2. Densidade da sonda por meio de lote msearch kNN. Cada sonda dispara uma consulta kNN e registra a semelhança média dos vizinhos. Alta similaridade média = região densa do espaço de embedding. msearch envia várias solicitações de pesquisa em uma única chamada HTTP, o que é fundamental aqui: a sondagem de densidade gera centenas de consultas kNN e processá-las em lote evita a sobrecarga por solicitação.

3. Selecione sementes de alta densidade com diversificação: os candidatos acima da densidade média são classificados por densidade decrescente e aceitos avidamente somente quando a semelhança de cosseno com cada semente existente estiver abaixo de um limite de separação. Este é o único processamento do lado do cliente (~0,01s para 8k documentos).

4. Classificar todos os documentos em relação aos centroides via msearch kNN: cada semente atua como um centroide; uma pesquisa kNN recupera documentos próximos acima de um limite de similaridade. Cada documento é atribuído ao centroide que o retornou com a maior pontuação. Pequenos clusters são dissolvidos em ruído.

O Elasticsearch cuida do trabalho pesado: msearch para sondas de densidade, msearch para classificação e significant_text para rotulagem. Para esse corpus (8.495 documentos), a amostra de sonda de densidade de 5% executa consultas de sonda de 425 kNN, que msearch agrupam lotes em nove chamadas HTTP (no tamanho de lote 50), evitando a sobrecarga de uma solicitação por sonda. Combinado com bbq_disk busca ANN, isso mantém a etapa de clustering rápida e escalável. As consultas kNN usam um valor mínimo de num_candidates para velocidade durante a passagem de clustering; consultas de busca em produção devem usar valores de num_candidates mais altos para melhorar a recordação, mas isso custa latência.

Clusters têm tamanhos naturais determinados pela densidade do espaço de embedding ao redor de cada centroide, não por um limite de k rígido. Regiões temáticas densas produzem clusters maiores; tópicos de nicho produzem agrupamentos menores.

Por que escolher KMeans ou HDBSCAN?

O algoritmo KMeans pressupõe clusters esféricos e requer a matriz completa N×d na memória. Para corpora que cabem na memória, HDBSCAN é uma excelente alternativa. Ele lida com formatos de cluster arbitrários e possui semântica de densidade bem compreendida.

A abordagem de centroide sondado por densidade mira em um nicho diferente: corpora onde você quer armazenamento, recuperação e clustering em um único sistema, ou onde a escala torna as operações matriciais do lado do cliente impraticáveis. Ele usa o Elasticsearch kNN como primitiva de computação, lida com tamanhos arbitrários de cluster e mantém quase toda a computação no lado do servidor.

Entendendo a taxa de ruído

A taxa de ruído de ~28% é intencional, não uma falha. Documentos que não cabem em nenhum cluster denso na similarity_threshold configurada ficam sem atribuição, em vez de serem forçados a uma correspondência ruim. Isso funciona como um filtro de qualidade: colunas de opinião, artigos curtos e reportagens isoladas naturalmente resistem ao clustering porque falta a densidade temática que define um grupo coerente.

O limiar é ajustável: reduzir similarity_threshold produz clusters mais abrangentes (mais documentos atribuídos, mas clusters menos coesos), enquanto aumentá-lo torna os clusters mais compactos e aumenta a fração de ruído. Para este corpus de conteúdo de notícias misto, ~30% de ruído é um ponto de operação razoável. Implantações em produção devem ajustar o limiar com base em critérios de qualidade específicos do domínio.

Rótulos automáticos com significant_text

Agora, cada cluster precisa de um rótulo de fácil compreensão. A agregação significant_text do Elasticsearch encontra termos que aparecem com frequência incomum em um conjunto em primeiro plano (o cluster) em comparação com um conjunto em segundo plano (o corpus completo).

Nos bastidores, ele usa uma heurística estatística (pontuação JLH por padrão) que equilibra mudanças de frequência absolutas e relativas, sem machine learning, sem chamadas de grandes modelo de linguagem (LLM). Um cluster sobre política do Reino Unido pode apresentar termos como starmer, labour, downing porque esses termos são desproporcionalmente comuns nesse cluster em comparação ao conjunto geral de notícias.

Para essa passagem global, os rótulos são calculados diretamente contra docs-clustering-all, então tanto o plano de frente quanto o plano de fundo são extraídos do mês inteiro. Na parte 2, a rotulagem utiliza o padrão de indexação diário (docs-clustering-*), um caractere curinga que permite que consultas abranjam todos os índices correspondentes simultaneamente, para dar significant_text um plano de fundo mais amplo e melhor contraste.

Um formato de consulta mínimo tem a seguinte aparência:

significant_text serve também como um filtro de qualidade: clusters que não produzem termos significativos não possuem vocabulário distintivo. São agrupamentos incoerentes que devem ser dissolvidos e reduzidos a ruído, em vez de receberem um rótulo enganoso.

Uma etapa de limpeza determinística e leve remove termos de rótulos irrelevantes (tokens numéricos, palavras genéricas) e recorre a um título representativo quando necessário. Isso mantém os rótulos nativos do Elasticsearch enquanto melhora a legibilidade.

Visualizando os clusters

As visualizações abaixo mostram o que a análise de clustering global descobriu: uma análise por data de documentos agrupados versus documentos de ruído, uma projeção UMAP para o mês inteiro e um gráfico de composição de fontes confirmando que os agrupamentos refletem tópicos em vez de fontes.

Distribuição diária de documentos agrupados versus ruídos ao longo de fevereiro de 2025.

Cada ilha colorida no UMAP representa um cluster: um grupo de artigos sobre o mesmo tema descobertos puramente por similaridade de incorporação. Os pontos de ruído cinza são artigos que não se encaixavam perfeitamente em nenhum cluster (artigos curtos, artigos de opinião ou histórias isoladas).

O gráfico de detalhamento da fonte confirma que os clusters contêm artigos de ambos BBC News e The Guardian. O clustering está encontrando tópicos, não fontes, exatamente o que a descoberta não supervisionada deve produzir.

Explorando a amplitude do cluster com o diversificador

O algoritmo kNN simples retorna os documentos mais semelhantes ao centroide de um cluster (o núcleo denso). Mas clusters reais abrangem subtópicos. O recuperador de diversificação usa a relevância marginal máxima (MMR) para destacar documentos que são relevantes para o centroide, mas também diferentes entre si.

O parâmetro chave é λ (lambda):

• λ = 1,0 → relevância pura (o mesmo que kNN simples).

• λ = 0,0 → diversidade pura (resultados de distribuição máxima).

• λ = 0,5 → equilibrado: relevante para o tópico, mas abordando diferentes perspectivas.

Uma forma mínima de solicitação de recuperador é assim:

Os parâmetros type, field, e query_vector são necessários no nível de diversificação: field informa à MMR qual campo dense_vector usar para similaridade entre resultados, e query_vector fornece o ponto de referência para a pontuação de relevância.

Isso permite que você responda: "O que esse cluster cobre de fato?" em vez de apenas "Qual é o ponto central?"

Os resultados simples kNN se agrupam em torno de um ângulo do tema: os documentos mais semelhantes ao centroide e entre si. O recurso de recuperação de diversidade revela diferentes facetas do mesmo cluster: subtópicos, fontes diversas e perspectivas variadas.

A métrica de diversidade confirma isso quantitativamente: a similaridade média entre pares é menor para os resultados do recuperador diversificado, o que significa que os documentos retornados abrangem um espectro mais amplo.

Isso é útil para você:

• Entender o que um cluster cobre, não apenas o centro, mas também as bordas.

• Geração de resumos. Documentos representativos diversos oferecem um material melhor para um LLM.

• Encontrar exemplos representativos para análise humana ou rotulagem posterior.

• Verificações de qualidade. Se os resultados diversos parecerem incoerentes, o cluster pode precisar ser dividido.

Parte 2: Cadeias de histórias temporais

Acompanhando histórias ao longo dos dias

A parte 1 fez o clustering de todo o mês global para descoberta de tópicos. Para o fluxo temporal, a mesma classificação de centroides sondados por densidade é executada independentemente por dia em índices diários, e depois os clusters são vinculados ao longo de dias consecutivos. Observe que os clusters diários são independentes dos clusters globais da parte 1; cada dia produz as próprias atribuições de agrupamento e rótulos ajustados ao conteúdo daquele dia.

A abordagem de vinculação: amostragem e consulta

Para cada cluster no dia A:

1. Você pode ver uma amostra de alguns documentos representativos.

2. Executar kNN contra o índice do dia B.

3. Conte quantos acessos caem em cada cluster B do dia.

4. Se a fração de acerto ultrapassar um limite (fração de kNN ≥ 0,4), registre um link.

Isso é rápido (apenas alguns documentos por cluster são consultados, nem todos) e usa o kNN nativo do Elasticsearch, sem necessidade de ferramentas externas.

Uma fração de kNN de 100% significa que todos os documentos mostrados do cluster de origem foram atribuídos ao mesmo cluster de destino, o vínculo mais forte possível entre os dias. A maioria dos links acima está relacionada ao futebol, o que faz sentido: a cobertura da Premier League é feita diariamente com alta consistência de tópicos.

O link score | operator | gedling → league | striker | season é um exemplo de um cluster de futebol local de nicho (Gedling é um clube fora da liga) sendo absorvido pelo cluster mais amplo da Premier League no dia seguinte, um efeito natural do clustering diário em diferentes granularidades.

Criar cadeias de histórias

Uma cadeia de histórias é uma sequência de clusters ligados ao longo de dias consecutivos.

Ligações pareadas individuais indicam que o cluster "política do Reino Unido" de segunda-feira está conectado ao de terça-feira. As cadeias revelam o arco completo: uma história que começa na segunda-feira, evolui durante a semana e encerra na sexta-feira.

As cadeias são construídas de forma ávida a partir de links com uma fração kNN ≥ 0,4, o que significa que pelo menos 40% dos documentos mostrados do cluster de origem chegaram a um único cluster de destino. A partir do cluster mais antigo, o algoritmo sempre segue o link de saída mais forte.

A rede mais longa acompanha a cobertura Ucrânia–Rússia por 19 dias consecutivos, o que não surpreende dada a intensidade geopolítica em fevereiro de 2025. O segundo mais longo acompanha o futebol da Premier League ao longo de 19 dias do mês. Cadeias mais curtas captam a temporada de premiações (filme/prêmios, seis dias), o rúgbi Six Nations (10 dias) e a cobertura da liderança política do Reino Unido (sete dias). Cada cadeia representa um arco narrativo que o algoritmo descobriu ao incorporar similaridade entre índices diários.

Sankey: Visualizando o fluxo da história

Um diagrama de Sankey é uma visualização de fluxo onde a largura da ligação representa a força da conexão. Aqui, cada faixa vertical representa um dia, cada nó é um cluster diário (dimensionado pela contagem de documentos), e cada caminho colorido traça uma cadeia de histórias ao longo do tempo. A largura do link codifica a força de sobreposição kNN: links mais espessos indicam que mais documentos mostrados caíram no cluster alvo. As cores são consistentes por cadeia, então um único caminho colorido da esquerda para a direita representa o progresso de uma história.

Por exemplo, a cadeia Ucrânia-Rússia (visível como um dos caminhos mais longos) flui continuamente desde o início de fevereiro até a terceira semana, com elos consistentemente espessos indicando forte continuidade temática ao longo dos dias.

Cadeias temporais de histórias que fluem ao longo de fevereiro de 2025. Cada caminho colorido representa uma história que persiste ao longo dos dias; com a largura indicando a força de sobreposição do kNN.

O que essa abordagem oferece

Esta análise abordou um pipeline completo de clustering de documentos não supervisionado construído no Elasticsearch:

1. Embeddings de clustering: os adaptadores específicos de tarefa do Jina v5 produzem embeddings otimizadas para agrupamento de tópicos, e não apenas para correspondência de consulta-documento.

2. Clustering de descoberta global: clustering o mês inteiro em um único índice maximiza a descoberta de tópicos ao longo dos dias.

3. Classificação de centroides com base na densidade: amostra 5%, sondar a densidade via msearch kNN, selecionar sementes diversas de alta densidade, classificar todos os documentos em relação aos centroides. O Elasticsearch cuida do processamento pesado; apenas a seleção de sementes executa do lado do cliente (~0,01s).

4. significant_text rotulagem: o teste de significância produz rótulos de cluster significativos sem qualquer modelo de ML ou anotação manual. Clusters que não produzem termos significativos são incoerentes e são rebaixados a ruído, uma porta de qualidade integrada.

5. Vinculação temporal de histórias: índices diários e kNN de índice cruzado entre amostra e consulta rastreiam como as histórias evoluem ao longo do tempo.

Principais conclusões:

• O tipo de tarefa de incorporação importa: embeddings de clustering produzem grupos tópicos mensuravelmente mais compactos.

• O Elasticsearch pode atuar tanto como camada de armazenamento quanto como motor de clustering por meio da busca kNN.

• A classificação de centroides baseada em densidade mantém quase toda a computação no lado do servidor e produz clusters com tamanhos naturais determinados pela densidade do espaço de incorporação.

• significant_text é rápido, compreensível e eficaz tanto para autorrotulagem quanto para controle de qualidade.

Quando essa abordagem é útil:

• Você tem texto com carimbo de data e hora e quer descobrir tópicos sem dados de treinamento rotulados.

• Você precisa de uma plataforma para armazenamento, busca vetorial, rotulagem e ligação temporal.

Extensões para explorar:

• Clustering por múltiplos períodos (semanal, pacotes mensais).

• Ingestão em tempo real com atribuição incremental de cluster.

• Resumos de cluster gerados pelo LLM usando os termos significant_text como sementes.

• Em escala maior, centroides KMeans mostrados podem servir como sementes de aquecimento para clustering baseado em densidade, reduzindo o custo da fase da sonda.

Experimente você mesmo

Troque seu próprio corpus de documentos com carimbo de data; qualquer coleção de texto com datas funciona com esse pipeline. O notebook completo e o código de suporte estão disponíveis no repositório complementar.

• Inicie uma avaliação gratuita do Elastic Cloud: instale um cluster gerenciado com suporte bbq_disk em questão de minutos.

• Experimente o Elasticsearch Serverless: sem gerenciamento de cluster, escala automática e com suporte.

Nosso objetivo era fazer a transição para uma abordagem automatizada e adaptativa capaz de lidar com a análise de logs (extração de campos) e o particionamento de logs (identificação da fonte). Nossa hipótese é que os grandes modelos de linguagem (LLMs), com a compreensão inerente da sintaxe do código e dos padrões semânticos, poderiam automatizar essas tarefas com o mínimo de intervenção humana.

Temos o prazer de anunciar que esse recurso já está disponível no Streams!

Descrição do conjunto de dados

Escolhemos uma coleção de logs do Loghubpara fins de PoC. Para nossa investigação, selecionamos amostras representativas das seguintes áreas-chave:

• Sistemas distribuídos: utilizamos os conjuntos de dados HDFS (Hadoop Distributed File System) e Spark. Esses contêm uma mistura de informações, mensagens de debug e erros típicos das plataformas de big data.

• Servidores e aplicações web: logs dos servidores web Apache e do OpenSSH forneceram uma fonte valiosa de acesso, erro e eventos relevantes para a segurança. Esses são fundamentais para monitorar o tráfego web e detectar ameaças potenciais.

• Sistemas operacionais: incluímos logs do Linux e do Windows. Esses conjuntos de dados representam os eventos comuns e semiestruturados em nível de sistema que as equipes de operações enfrentam diariamente.

• Sistemas móveis: para garantir que nosso modelo pudesse lidar com logs de ambientes móveis, incluímos o conjunto de dados Android. Esses logs costumam ser extensos e captam uma ampla gama de atividades em nível de aplicação e sistema em dispositivos móveis.

• Supercomputadores: para testar o desempenho em ambientes de computação de alto desempenho (HPC), incorporamos o conjunto de dados BGL (Blue Gene/L), que apresenta logs altamente estruturados com terminologia específica de domínio.

Uma das principais vantagens da coleção Loghub é que os logs são, em grande parte, não higienizados e não rotulados, espelhando um ambiente de produção real e ruidoso com arquitetura de microsserviços.

Exemplos de logs:

Além disso, criamos um cluster Kubernetes com uma configuração típica de aplicação web + banco de dados para minerar logs extras no domínio mais comum.

Exemplo de campos de log comuns: carimbo de tempo, nível de log (INFO, AVISO, ERRO), origem, mensagem.

Análise de logs com poucos exemplos usando um LLM

Nosso primeiro conjunto de experimentos concentrou-se em uma questão fundamental: Um LLM pode identificar áreas-chave de forma confiável e gerar regras consistentes de análise para extraí-las?

Solicitamos a um modelo que analisasse amostras de registros brutos e gerasse regras de análise sintática de log nos formatos de expressão regular (regex) e Grok. Nossos resultados mostraram que essa abordagem tem muito potencial, mas também apresenta desafios significativos de implementação.

Alto nível de confiança e consciência contextual

Os resultados iniciais foram promissores. O LLM demonstrou uma forte habilidade de gerar regras de análise sintática que correspondiam aos exemplos de poucos disparos fornecidos com alta confiança. Além da simples correspondência de padrões, o modelo demonstrou capacidade de compreensão de logs, pois ele conseguiu identificar e nomear corretamente a fonte do log (por exemplo, aplicativo de monitoramento de saúde, aplicativo web Nginx, banco de dados MongoDB).

O dilema "Cachinhos Dourados" das amostras de entrada

Nossos experimentos logo revelaram uma falta significativa de robustez devido à extrema sensibilidade à amostra de entrada. O desempenho do modelo varia muito com base nos exemplos específicos de logs incluídos no prompt. Observamos um problema de similaridade de log, onde a amostra de logs precisa incluir logs diversos:

• Homogeneidade excessiva (sobreajuste): se os logs de entrada forem muito semelhantes, o LLM tende a superespecificar. Ele trata dados de variáveis, como nomes específicos de classes Java em um rastreio de pilha, como partes estáticas do template. Isso resulta em regras frágeis que cobrem uma proporção minúscula de logs e extraem campos inutilizáveis.

• Muito heterogêneo (confusão): por outro lado, se a amostra contiver uma variação significativa de formatação, ou pior, "registros de lixo" como barras de progresso, tabelas de memória ou arte ASCII, o modelo terá dificuldades para encontrar um denominador comum. Geralmente, ele recorre à geração de expressões regulares complexas e quebradas ou à generalização lenta de toda a linha em um único campo blob de mensagem.

A restrição da janela de contexto

Também encontramos um gargalo na janela de contexto. Quando os registros de entrada eram longos, heterogêneos ou ricos em campos extraíveis, a saída do modelo geralmente se deteriorava, tornando-se "confusa" ou muito longa para caber na janela de contexto de saída. Naturalmente, a fragmentação ajuda nesse caso. Ao dividir os logs usando delimitadores baseados em caracteres e em entidades, podemos ajudar o modelo a se concentrar na extração dos campos principais sem ser sobrecarregado por ruídos.

A lacuna de consistência e padronização

Mesmo quando o modelo gerou regras com sucesso, notamos pequenas inconsistências:

• Variações de nomenclatura de serviço: o modelo propõe diferentes nomes para a mesma entidade (por exemplo, rotulando a fonte como "Spark", "Apache Spark" e "Spark Log Analytics" em diferentes execuções).

• Variações na nomenclatura dos campos: os nomes dos campos não tinham padronização (por exemplo, id X service.id X device.id). Normalizamos os nomes usando uma nomenclatura de campo padronizada do Elastic.

• Variância de resolução: a resolução da extração de campo variava dependendo de o quão semelhantes eram os logs de entrada entre si.

Formato de log impressão digital

Para enfrentar o desafio da similaridade de log, apresentamos uma heurística de alto desempenho: impressão digital de formato de log (LFF).

Em vez de inserir logs brutos e ruidosos diretamente em um LLM, primeiro aplicamos uma transformação determinística para revelar a estrutura subjacente de cada mensagem. Essa etapa de pré-processamento abstrai os dados das variáveis, gerando uma "impressão digital" simplificada que nos permite agrupar logs relacionados.

A lógica de mapeamento é simples para garantir velocidade e consistência:

1. Abstração de dígitos: qualquer sequência de dígitos (0-9) é substituída por um único "0".

2. Abstração de texto: qualquer sequência de caracteres alfabéticos com espaço em branco é substituída por um único "a".

3. Normalização de espaço em branco: todas as sequências de espaço em branco (espaços, tabulações, novas linhas) são reduzidos a um único espaço.

4. Preservação de símbolos: pontuação e caracteres especiais (por exemplo, :, [, ], /) são preservados, pois normalmente são os indicadores mais fortes da estrutura log.

Apresentamos a abordagem de mapeamento de log. Os padrões básicos de mapeamento incluem os seguintes:

• Dígitos de 0 a 9 de qualquer comprimento -> até "0".

• Texto (caracteres alfabéticos com espaços) de qualquer comprimento -> para "a".

• Espaços em branco, abas e novas linhas -> para um único espaço.

Vamos ver um exemplo de como esse mapeamento nos permite transformar os logs.

Como resultado, obtemos as seguintes máscaras de log:

Observe as impressões digitais dos dois primeiros logs. Apesar dos diferentes carimbos de data e hora, classes de origem e conteúdo da mensagem, os prefixos (0/0/0 0:0:0 a a.a:) são idênticos. Esse alinhamento estrutural nos permite colocar automaticamente esses logs em buckets no mesmo cluster.

O terceiro log, no entanto, produz uma impressão digital completamente divergente (0-0-0...). Isso nos permite separá-lo algoritmicamente do primeiro grupo antes mesmo de invocarmos um LLM.

Parte bônus: Implementação instantânea com ES|QL

É tão simples quanto passar essa consulta no Discover.

Detalhamento da consulta:

DE loghub: direcionado para nosso índice contendo os dados de registro bruto.

Padrão EVAL = ...: a lógica de mapeamento do núcleo. Encadeamos funções REPLACE para realizar a abstração (por exemplo, dígitos para '0', texto para 'a', etc.) e salvamos o resultado em um campo "padrão".

STATS [column1 =] expression1, … POR SUBSTRING(pattern, 0, 15):

Esta é uma etapa de clustering. Agrupamos logs que compartilham os primeiros 15 caracteres de seu padrão e criamos campos agregados, como contagem total de log por grupo, lista de fontes de dados de log, prefixo do padrão, 3 exemplos de log

SORT total_count DESC | LIMITE 100: destaca os 100 padrões de log mais frequentes

Os resultados das consultas no LogHub estão exibidos abaixo:

Como demonstrado na visualização, essa abordagem "livre de LLM" particiona logs com alta precisão. Ela agrupou com sucesso 10 das 16 fontes de dados (com base nos rótulos do LogHub) (>90%) e alcançou clustering majoritário em 13 das 16 fontes (>60%), tudo isso sem necessidade de limpeza adicional, pré-processamento nem ajuste fino.

A impressão digital do formato de Log oferece uma alternativa pragmática e de alto impacto, além de ser um complemento para soluções sofisticadas de ML, como a análise de padrões de log. Ele fornece insights imediatos sobre relacionamentos de logs e gerencia efetivamente grandes clusters de logs.

• Versatilidade como primitiva

Graças à implementação do ES|QL, o LFF funciona tanto como uma ferramenta independente para diagnósticos/visualizações de dados rápidos, quanto como um componente essencial em pipelines de análise de logs para casos de uso de alto volume.

• Flexibilidade

O LFF é fácil de personalizar e estender para captar padrões específicos, ou seja, números hexadecimais e endereços IP.

• Estabilidade determinística

Ao contrário dos algoritmos de clustering baseados em ML, a lógica LFF é direta e determinística. Novos logs recebidos não afetam retroativamente os clusters de logs existentes.

• Desempenho e memória

Requer memória mínima, sem treinamento nem GPU, tornando-o ideal para ambientes de alta taxa em tempo real.

Combinando a impressão digital do formato de log com um LLM

Para validar a arquitetura híbrida proposta, cada experimento continha um subconjunto aleatório de 20% dos registros de cada fonte de dados. Essa restrição simula um ambiente de produção real onde os logs são processados em lotes, em vez de um despejo histórico monolítico.

O objetivo era demonstrar que o LFF atua como uma camada de compressão eficaz. Nosso objetivo era provar que regras de análise de alta cobertura poderiam ser geradas a partir de amostras pequenas e selecionadas e generalizadas com sucesso para todo o conjunto de dados.

Pipeline de execução

Implementamos um pipeline de múltiplas etapas que filtra, agrupa e aplica amostragem estratificada aos dados antes que cheguem ao LLM.

1. Clustering hierárquico em dois estágios

• Subclasses (correspondência exata): os logs são agregados por impressões digitais idênticas. Todo log em uma subclasse compartilha exatamente a mesma estrutura de formato.

• Limpeza de discrepâncias. Nós descartamos quaisquer subclasses que representam menos de 5% do volume total de log. Isso garante que o LLM se concentre no sinal dominante e não seja desviado por ruído ou logs malformados.

• Metaclasses (correspondência de prefixo): as subclasses restantes são agrupadas em metaclasses pelos primeiros N caracteres da correspondência da impressão digital do formato. Essa estratégia de agrupamento divide efetivamente formatos lexicalmente semelhantes sob uma mesma categoria. Escolhemos N=5 para análise de log e N=15 para particionamento de log quando as fontes de dados são desconhecidas.

2. Amostragem estratificada. Após a construção da árvore hierárquica, construímos a amostra de log para o LLM. O objetivo estratégico é maximizar a cobertura de variações enquanto minimiza o uso de tokens.

• Selecionamos logs representativos de cada subclasse válida dentro da metaclasse mais ampla.

• Para gerenciar um caso extremo de subclasses muito numerosas, aplicamos subamostragem aleatória para ajustar ao tamanho da janela alvo.

3. Geração de regras Final, solicitamos ao LLM que gere uma regra de análise regex que se encaixe em todos os logs da amostra fornecida para cada metaclasse. Para nossa PoC, usamos o modelo mini GPT-4o.

Resultados experimentais e observações

Alcançamos 94% de precisão de análise sintática e 91% de precisão de particionamento no conjunto de dados do Loghub.

A matriz de confusão acima ilustra os resultados da partição log. O eixo vertical representa as fontes de dados reais e o eixo horizontal representa as fontes de dados previstas. A intensidade do heatmap corresponde ao volume do log, com blocos mais claros indicando uma contagem maior. O alinhamento diagonal demonstra a alta fidelidade do modelo na atribuição da fonte, com espalhamento mínimo.

Nossos insights sobre benchmarks de desempenho:

• Linha de base ideal: uma janela de contexto de 30 a 40 amostras de log por categoria provou ser o ponto ideal, produzindo consistentemente uma análise robusta com padrões Regex e Grok.

• Minimização da entrada: aumentamos o tamanho da entrada para 10 registros por categoria para padrões Regex e observamos uma queda de apenas 2% no desempenho da análise, confirmando que a amostragem baseada na diversidade é mais importante do que o volume bruto.

Filtros vs facetas

Antes de começarmos, vamos definir o que são filtros e facetas. Os filtros são atributos predefinidos usados para restringir um conjunto de resultados. Em um mercado online, por exemplo, os filtros estão disponíveis mesmo antes de uma busca ser realizada. O usuário pode selecionar uma categoria, como "Videogames", antes de pesquisar por "PS5", refinando a busca para um subconjunto mais específico em vez de toda a base de dados. Isso aumenta significativamente as chances de se obter resultados mais relevantes.

Os facets funcionam de forma semelhante aos filtros, mas só ficam disponíveis após a realização da pesquisa. Em outras palavras, a pesquisa retorna resultados e, com base neles, é gerada uma nova lista de opções de refinamento. Por exemplo, ao pesquisar um console PS5, características como capacidade de armazenamento, custo de envio e cor podem ser exibidas para ajudar os usuários a escolher o produto ideal.

Agora que definimos filtros e facetas, vamos discutir o impacto das abordagens clássicas e baseadas em Aprendizado de Máquina (ML) em sua implementação e uso. Cada método possui vantagens e desafios que influenciam a eficiência da busca.

Abordagem clássica de filtros e facetas

Nessa abordagem, os filtros e as facetas são definidos manualmente com base em regras predefinidas. Isso significa que os atributos disponíveis para refinar a busca são fixos e planejados antecipadamente, levando em consideração a estrutura do catálogo e as necessidades do usuário.

Por exemplo, em um marketplace, categorias como "Eletrônicos" ou "Moda" podem ter filtros específicos como marca, formato e faixa de preço. Essas regras são criadas estaticamente, garantindo consistência na experiência de busca, mas exigindo ajustes manuais sempre que novos produtos ou categorias surgirem.

Embora essa abordagem proporcione previsibilidade e controle sobre os filtros e facetas exibidos, ela pode ser limitada quando surgem novas tendências que exigem refinamento dinâmico.

Prós:

• Previsibilidade e controle: Como os filtros e as facetas são definidos manualmente, o gerenciamento torna-se mais fácil.

• Baixa complexidade: Não há necessidade de treinar modelos.

• Facilidade de manutenção: Como as regras são predefinidas, ajustes e correções podem ser feitos rapidamente.

Contras:

• Reindexação necessária para novos filtros: Sempre que um novo atributo precisar ser usado como filtro, todo o conjunto de dados deverá ser reindexado para garantir que os documentos contenham essa informação.

• Falta de adaptação dinâmica: os filtros são estáticos e não se ajustam automaticamente às mudanças no comportamento do usuário.

Implementação de filtros/facetas – Abordagem clássica

Nas Ferramentas de Desenvolvimento, Kibana, criaremos uma demonstração de filtros/facetas usando a abordagem clássica.

Primeiro, definimos o mapeamento para estruturar o índice:

Os campos de marca e armazenamento são definidos como palavras-chave, permitindo que sejam usados diretamente em agregações (facetas). O campo de preço é do tipo float, permitindo a criação de intervalos de preço.

Na próxima etapa, os dados do produto serão indexados:

Agora, vamos recuperar as características clássicas agrupando os resultados por marca, armazenamento e faixa de preço. Na consulta, foi definido o tamanho:0. Nesse cenário, o objetivo é recuperar apenas os resultados da agregação, sem incluir os documentos correspondentes à consulta.

A resposta incluirá contagens para Marca, Armazenamento e Preço, ajudando a criar filtros e segmentações.

Abordagem baseada em machine learning/IA para filtros e facetas

Nessa abordagem, modelos de Aprendizado de Máquina (ML), incluindo técnicas de Inteligência Artificial (IA), analisam atributos de dados para gerar filtros e facetas relevantes. Em vez de depender de regras predefinidas, o aprendizado de máquina/inteligência artificial aproveita as características dos dados indexados. Isso possibilita a descoberta dinâmica de novas facetas e filtros.

Prós:

• Atualizações automáticas: Novos filtros e facetas são gerados automaticamente, sem a necessidade de ajustes manuais.

• Descoberta de novos atributos: Pode identificar características de dados anteriormente não consideradas como filtros, enriquecendo a experiência de busca.

• Redução do esforço manual: a equipe não precisa definir e atualizar constantemente as regras de filtragem, pois a IA aprende com os dados disponíveis.

Contras:

• Complexidade de manutenção: O uso de modelos pode exigir pré-validação para garantir a consistência dos filtros gerados.

• Requer experiência em aprendizado de máquina e inteligência artificial: A solução exige profissionais qualificados para ajustar e monitorar o desempenho do modelo.

• Risco de filtros irrelevantes: Se o modelo não estiver bem calibrado, poderá gerar facetas que não sejam úteis para os usuários.

• Custo: O uso de aprendizado de máquina e inteligência artificial pode exigir serviços de terceiros, aumentando os custos operacionais.

Vale ressaltar que, mesmo com um modelo bem calibrado e um prompt bem elaborado, as facetas geradas ainda devem passar por uma etapa de revisão. Essa validação pode ser manual ou baseada em regras de moderação, garantindo que o conteúdo seja apropriado e seguro. Embora não seja necessariamente uma desvantagem, é importante considerar a qualidade e a adequação dos recursos antes que sejam disponibilizados aos usuários.

Implementação de filtros/facetas – abordagem de IA

Nesta demonstração, utilizaremos um modelo de IA para analisar automaticamente as características do produto e sugerir atributos relevantes. Com um prompt bem estruturado, extraímos informações do catálogo e as transformamos em filtros e facetas. A seguir, apresentamos cada etapa do processo.

Inicialmente, usaremos a API de Inferência para registrar um endpoint para integração com um serviço de aprendizado de máquina. Abaixo, segue um exemplo de integração com o serviço da OpenAI.

Agora, definimos o pipeline para executar o prompt e obter os novos filtros gerados pelo modelo.

Executando uma simulação desse pipeline para o produto "PlayStation 5", com a seguinte descrição:

Jogabilidade impressionante: Maravilhe-se com gráficos deslumbrantes e experimente os recursos do novo PS5.

Imersão de tirar o fôlego: Descubra uma experiência de jogo mais profunda com suporte para feedback tátil, gatilhos adaptáveis e tecnologia de áudio 3D.

Design fino: Com o PS5 Digital Edition, os jogadores têm acesso a uma poderosa tecnologia de jogos em um design elegante e compacto.

1 TB de armazenamento: Tenha seus jogos favoritos prontos para jogar com 1 TB de armazenamento SSD integrado.

Compatibilidade com versões anteriores e Game Boost: O console PS5 pode rodar mais de 4.000 jogos de PS4. Com o Game Boost, você pode desfrutar de taxas de quadros mais rápidas e suaves até mesmo em alguns dos melhores jogos para PS4.

Vamos observar a saída de comando gerada por esta simulação.

Agora, um novo campo, dynamic_facets, será adicionado ao novo índice para armazenar as facetas geradas pela IA.

Utilizando a API Reindex, vamos reindexar o índice de videogames para videogames_1, aplicando o pipeline generate_filter_ai durante o processo. Este pipeline irá gerar automaticamente facetas dinâmicas durante a indexação.

Agora, vamos executar uma pesquisa e obter os novos filtros:

Resultados:

Para simbolizar a implementação das facetas, segue abaixo um exemplo simples de interface:

O código da interface do usuário apresentado está aqui.

Conclusão

Ambas as abordagens para a criação de filtros e facetas têm seus benefícios e pontos de atenção. A abordagem clássica, baseada em regras manuais, oferece controle e custos mais baixos, mas requer atualizações constantes e não se adapta dinamicamente a novos produtos ou recursos.

Por outro lado, a abordagem baseada em IA e Aprendizado de Máquina automatiza a extração de facetas, tornando a busca mais flexível e permitindo a descoberta de novos atributos sem intervenção manual. No entanto, essa abordagem pode ser mais complexa de implementar e manter, exigindo calibração para garantir resultados consistentes.

A escolha entre as abordagens clássicas e as baseadas em IA depende das necessidades e da complexidade do negócio. Para cenários mais simples, onde os atributos dos dados são estáveis e previsíveis, a abordagem clássica pode ser mais eficiente e fácil de manter, evitando custos desnecessários com infraestrutura e modelos de IA. Por outro lado, o uso de aprendizado de máquina/inteligência artificial para extrair facetas pode agregar valor significativo, melhorando a experiência de busca e tornando a filtragem mais inteligente.

O importante é avaliar se a automação justifica o investimento ou se uma solução mais tradicional já atende às necessidades do negócio de forma eficaz.

Entendendo o benchmark BEIR na avaliação de relevância de busca

Para melhorar qualquer sistema, é preciso conseguir medir o quão bem ele está funcionando. No contexto de busca, o BEIR (ou, de forma equivalente, a seção de recuperação da tabela de classificação do MTEB) é considerado o “santo graal” pela comunidade de recuperação de informação, e isso não é por acaso. Trata-se de um benchmark muito bem estruturado, com conjuntos de dados variados que abrangem diferentes tarefas. Mais especificamente, as seguintes áreas são contempladas:

• Recuperação de argumentos (ArguAna, Touche2020)

• QA de domínio aberto (HotpotQA, Natural Questions, FiQA)

• Recuperação de passagens (MSMARCO)

• Recuperação de perguntas duplicadas (Quora, CQADupstack)

• Verificação de fatos (FEVER, Climate-FEVER, Scifact)

• Recuperação de informações biomédicas (TREC-COVID, NFCorpus, BioASQ)

• Recuperação de entidades (DBPedia)

• Previsão de citações (SCIDOCS)

O benchmark fornece uma única métrica, nDCG@10, relacionada a quão bem um sistema corresponde aos documentos mais relevantes para cada exemplo de tarefa entre os principais resultados retornados. Para um sistema de busca com o qual pessoas interagem, a relevância dos primeiros resultados é fundamental. No entanto, existem muitas nuances na avaliação de busca que uma única métrica resumida não consegue capturar.

Estrutura de um conjunto de dados BEIR

Cada benchmark é composto por três artefatos:

• o corpus, ou seja, os documentos a serem recuperados

• as consultas

• Os julgamentos de relevância para as consultas (também conhecidos como qrels).

Os julgamentos de relevância são fornecidos como uma pontuação igual ou maior que zero. Pontuações diferentes de zero indicam que o documento tem alguma relação com a consulta.

Conjunto de dados

Tamanho do corpus

#Consultas no conjunto de testes

#qrels com rótulo positivo

#qrels igual a zero

#duplicatas no corpus

ArguAna

8.674

1.406

1.406

0

96

Climate-FEVER

5.416.593

1.535

4.681

0

0

DBPedia

4.635.922

400

15.286

28.229

0

FEVER

5.416.568

6.666

7.937

0

0

FiQA-2018

57.638

648

1.706

0

0

HotpotQA

5.233.329

7.405

14.810

0

0

Natural Questions

2.681.468

3.452

4.021

0

16.781

NFCorpus

3.633

323

12.334

0

80

Quora

522.931

10.000

15.675

0

1.092

SCIDOCS

25.657

1.000

4.928

25.000

2

SciFact

5.183

300

339

0

0

Touche2020

382.545

49

932

1.982

5.357

TREC-COVID

171.332

50

24.763

41.663

0

MSMARCO

8.841.823

6.980

7.437

0

324

CQADupstack (soma)

457.199

13.145

23.703

0

0

Tabela 1: Estatísticas dos conjuntos de dados. Os números foram calculados com base na porção de teste dos conjuntos de dados (dev para MSMARCO).

A Tabela 1 apresenta algumas estatísticas dos conjuntos de dados que compõem o benchmark BEIR, como o número de documentos no corpus, o número de consultas no conjunto de teste e o número de pares positivos/negativos (consulta, documento) no arquivo qrels. Com uma análise rápida dos dados, é possível inferir imediatamente o seguinte:

• maioria dos conjuntos de dados não contém relações negativas no arquivo qrels, ou seja, pontuações zero que indicariam explicitamente que um documento é irrelevante para determinada consulta.

• O número médio de relações entre documentos por consulta (#qrels / #queries) varia de 1,0 no caso de ArguAna até 493,5 (TREC-COVID), mas fica em torno de <5 na maioria dos casos.

• Alguns conjuntos de dados apresentam documentos duplicados no corpus, o que em certos casos pode levar a avaliações incorretas, por exemplo quando um documento é considerado relevante para uma consulta, mas seu duplicado não é. Como exemplo, em ArguAna, identificamos 96 casos de pares de documentos duplicados em que apenas um documento do par foi marcado como relevante para uma consulta. Ao “expandir” a lista inicial de qrels para incluir também os duplicados, observamos um aumento relativo médio de aproximadamente 1% na pontuação nDCG@10.

Exemplo de pares duplicados no ArguAna. No arquivo qrels, apenas o primeiro aparece como relevante (como contra-argumento) para a consulta (“test-economy-epiasghbf-pro02a”).

Ao comparar modelos na tabela de classificação do MTEB, é tentador focar na qualidade média de recuperação. Essa é uma boa aproximação da qualidade geral do modelo, mas não necessariamente indica como ele vai se comportar no seu caso de uso específico. Como os resultados são reportados por conjunto de dados, vale a pena entender o quanto cada conjunto se relaciona com a sua tarefa de busca e reavaliar os modelos usando apenas os mais relevantes. Se quiser se aprofundar ainda mais, também é possível verificar a sobreposição de tópicos entre os diferentes corpora dos conjuntos de dados. Estratificar as métricas de qualidade por tópico fornece uma avaliação muito mais detalhada de pontos fortes e limitações específicas.

Um ponto importante a destacar é que, quando um documento não está marcado no arquivo qrels , ele é considerado irrelevante para a consulta por padrão. Aprofundamos um pouco mais essa análise e reunimos evidências para esclarecer melhor a seguinte pergunta: “Com que frequência um avaliador se depara com pares (consulta, documento) para os quais não existe informação de comprovação?” Isso é importante porque, quando apenas anotações superficiais estão disponíveis (ou seja, nem todos os documentos relevantes são rotulados como tal), um sistema de recuperação de informação pode ser avaliado como pior do que outro simplesmente porque ele “escolhe” destacar documentos relevantes diferentes, porém não marcados. Essa é uma armadilha comum na criação de conjuntos de avaliação de alta qualidade, especialmente em conjuntos de dados grandes. Para que a rotulagem manual seja viável, ela normalmente se concentra nos principais resultados retornados pelo sistema atual, o que pode deixar de fora documentos relevantes que estão fora do seu campo de visão. Por isso, em geral é preferível concentrar mais recursos em uma anotação mais completa de um número menor de consultas, em vez de realizar uma anotação ampla porém superficial.

Usando o benchmark BEIR para avaliação de relevância de busca

Para iniciar nossa análise, implementamos o seguinte cenário (ver o notebook):

1. Primeiro, carregamos o corpus de cada conjunto de dados em um índice do Elasticsearch.

2. Para cada consulta no conjunto de teste, recuperamos os top 100 documentos usando BM25.

3. Em seguida, fazemos a reclassificação dos documentos recuperados usando uma variedade de modelos de reclassificação de última geração.

4. Por fim, reportamos a “taxa de julgamento” para os top 10 documentos provenientes das etapas 2 (após a recuperação) e 3 (após a reclassificação). Em outras palavras, calculamos a porcentagem média dos top 10 documentos que possuem uma pontuação no arquivo qrels.

A lista de modelos de reclassificação que usamos é a seguinte:

• Cohere rerank-english-v2.0 e rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Recuperação

Reclassificação

Conjunto de dados

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

ArguAna

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15,1

14,02

14,42

Natural Questions

5,94

8,84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

SciFact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (média)

5,47

6,32

6,87

5,89

6,22

6,16

Tabela 2: Taxa de julgamento por pares (conjunto de dados, reclassificador), calculada sobre os top 10 documentos recuperados/reclassificados

A partir da Tabela 2, com exceção de TREC-COVID (cobertura de >90%), DBPedia (~65%), Touche2020 e nfcorpus (~35%), observamos que a maioria dos conjuntos de dados apresenta uma taxa de rotulagem entre 5% e pouco mais de 10% após a recuperação ou a reclassificação. Isso não significa que todos esses documentos não marcados sejam relevantes, mas pode haver um subconjunto deles — especialmente aqueles posicionados no topo — que seja positivo.

Com a chegada de modelos de linguagem de propósito geral ajustados por instruções, passamos a contar com uma nova e poderosa ferramenta que pode, potencialmente, automatizar a avaliação de relevância. Esses métodos normalmente são computacionalmente caros demais para uso online em sistemas de busca, mas aqui estamos tratando de avaliação offline. A seguir, usamos esses modelos para explorar evidências de que alguns conjuntos de dados do BEIR sofrem com anotações superficiais.

Para investigar melhor essa hipótese, decidimos focar no MSMARCO e selecionar um subconjunto de 100 consultas, juntamente com os top 5 documentos reclassificados (com Cohere v2) que atualmente não estão marcados como relevantes. Primeiro, usamos um prompt cuidadosamente ajustado (falaremos mais sobre isso em um post futuro) para preparar o modelo Phi-3-mini-4k, lançado recentemente, a prever se um documento é ou não relevante para a consulta. Em paralelo, esses mesmos casos também foram rotulados manualmente, de modo a avaliar a taxa de concordância entre a saída do LLM e o julgamento humano. De forma geral, podemos tirar as duas conclusões a seguir:

• A taxa de concordância entre as respostas dos LLMs e os julgamentos humanos ficou próxima de 80%, o que parece um ponto de partida razoável nessa direção.

• Em 57,6% dos casos (com base em julgamento humano), os documentos retornados foram considerados realmente relevantes para a consulta. Colocando isso de outra forma: para 100 consultas, temos 107 documentos julgados como relevantes, mas pelo menos 0,576 × 5 × 100 = 288 documentos adicionais que também são, de fato, relevantes.

Aqui estão alguns exemplos extraídos do conjunto de dados MSMARCO/dev que incluem a consulta, o documento positivo anotado (de qrels) e um documento falso negativo devido a anotações incompletas:

Exemplo 1:

Exemplo 2:

Avaliar manualmente consultas específicas dessa forma é uma técnica geralmente útil para entender a qualidade da busca e complementa métricas quantitativas como o nDCG@10. Se você tiver um conjunto representativo de consultas que sempre executa ao fazer alterações no sistema de busca, isso fornece informações qualitativas importantes sobre como a performance muda, algo que não aparece nas estatísticas. Por exemplo, essa abordagem oferece muito mais visibilidade sobre resultados incorretos retornados pela busca: ajuda a identificar erros evidentes nos documentos recuperados, classes de falhas recorrentes, como interpretações equivocadas de terminologia específica de um domínio, entre outros.

Nossos resultados estão alinhados com pesquisas relevantes sobre avaliação em MSMARCO. Por exemplo, Arabzadeh et al. seguem um procedimento semelhante ao empregar trabalhadores de crowdsourcing para realizar julgamentos de preferência. Entre outros achados, eles mostram que, em muitos casos, os documentos retornados pelos módulos de reclassificação são preferidos em relação aos documentos presentes no arquivo qrels do MSMARCO. Outra evidência vem dos autores do reclassificador RocketQA, que relatam que mais de 70% dos documentos reclassificados foram considerados relevantes após inspeção manual.

Atualização – 9 de setembro: após uma reavaliação cuidadosa do conjunto de dados, identificamos mais 15 casos de documentos relevantes, aumentando o total de 273 para 288.

Principais conclusões e próximos passos

• A busca por uma comprovação melhor é contínua e extremamente importante para benchmarking e comparação de modelos. Os LLMs podem auxiliar em algumas áreas da avaliação, desde que usados com cautela e ajustados com instruções adequadas.

• De forma mais geral, considerando que benchmarks nunca serão perfeitos, pode ser preferível migrar de uma comparação puramente baseada em pontuações para técnicas mais robustas, capazes de capturar diferenças estatisticamente significativas. O trabalho de Arabzadeh et al. oferece um bom exemplo disso: com base em seus resultados, os autores constroem intervalos de confiança de 95% para indicar se as diferenças entre diferentes execuções são estatisticamente significativas ou não. No notebook que acompanha este conteúdo, fornecemos uma implementação de intervalos de confiança usando bootstrapping.

• Do ponto de vista do usuário final, é útil pensar em alinhamento com a tarefa ao interpretar resultados de benchmarks. Por exemplo, para um engenheiro de IA que constrói um pipeline de RAG e sabe que o caso de uso mais comum envolve reunir múltiplas informações de diferentes fontes, faz mais sentido avaliar o desempenho do modelo de recuperação em conjuntos de dados de QA multi-hop, como o HotpotQA, em vez de considerar apenas a média global de todo o benchmark BEIR.

No próximo post do blog, vamos nos aprofundar no uso do Phi-3 como avaliador baseado em LLM e no processo de ajuste do modelo para prever relevância.

Embora o HNSW seja uma maneira poderosa e flexível de armazenar e pesquisar vetores, ele exige uma quantidade significativa de memória para funcionar rapidamente. Por exemplo, consultar vetores float32 de 1 milhão de dimensões e 768 dimensões requer aproximadamente de RAM. Quando você começa a pesquisar um número significativo de vetores, isso se torna caro. Uma forma de usar cerca de menos memória é através da quantização de bytes. O Lucene, e consequentemente o Elasticsearch, já suportam a indexação de vetores há algum tempo, mas a construção desses vetores era responsabilidade do usuário. Isso está prestes a mudar, pois introduzimos a quantização escalar no Lucene.

Quantização escalar 101

Todas as técnicas de quantização são consideradas transformações com perda dos dados brutos. Significa que algumas informações são perdidas em função do espaço disponível. Para uma explicação detalhada da quantização escalar, veja: Quantização Escalar 101. Em termos gerais, a quantização escalar é uma técnica de compressão com perdas. Uma matemática simples permite economizar espaço significativamente com pouco impacto na capacidade de memorização.

Explorando a arquitetura

Quem já está acostumado a trabalhar com o Elasticsearch provavelmente já conhece esses conceitos, mas aqui vai uma breve visão geral da distribuição de documentos para pesquisa.

Cada índice do Elasticsearch é composto por múltiplos shards. Embora cada fragmento só possa ser atribuído a um único nó, vários fragmentos por índice proporcionam paralelismo computacional entre os nós.

Cada fragmento é composto por um único Índice Lucene. Um índice Lucene consiste em múltiplos segmentos somente leitura. Durante a indexação, os documentos são armazenados em buffer e periodicamente transferidos para um segmento somente leitura. Quando determinadas condições são atendidas, esses segmentos podem ser mesclados em segundo plano, formando um segmento maior. Tudo isso é configurável e possui seu próprio conjunto de complexidades. Mas, quando falamos de segmentos e fusão, estamos falando de segmentos Lucene somente leitura e da fusão periódica automática desses segmentos. Aqui está uma análise mais aprofundada sobre a fusão de segmentos e as decisões de design.

Quantização por segmento no Lucene

Cada segmento no Lucene armazena o seguinte: os vetores individuais, os índices do grafo HNSW, os vetores quantizados e os quantis calculados. Por uma questão de brevidade, vamos nos concentrar em como o Lucene armazena vetores quantizados e brutos. Para cada segmento, mantemos o controle dos vetores brutos no arquivo , dos vetores quantizados e de um único multiplicador corretivo de ponto flutuante em , além dos metadados relativos à quantização no arquivo .

Figura 1: Layout simplificado de um arquivo de armazenamento vetorial bruto. Ocupa de espaço em disco, já que os valores têm 4 bytes. Como estamos utilizando quantização, esses dados não serão carregados durante a busca por HNSW. Eles só são usados se forem especificamente solicitados (por exemplo, força bruta secundária via reavaliação), ou para requantização durante a fusão de segmentos.

Figura 2: Layout simplificado do arquivo arquivo. Ocupa de espaço e será carregado na memória durante a busca. Os bytes servem para contabilizar o multiplicador corretivo de ponto flutuante, usado para ajustar a pontuação visando maior precisão e melhor recuperação da informação.

Figura 3: Layout simplificado do arquivo de metadados. Aqui, monitoramos a quantização e a configuração vetorial, juntamente com os quantis calculados para este segmento.

Assim, para cada segmento, armazenamos não apenas os vetores quantizados, mas também os quantis usados na criação desses vetores quantizados e os vetores brutos originais. Mas, afinal, por que ainda guardamos os vetores brutos?

Quantização que cresce com você

Como o Lucene periodicamente limpa os segmentos para que fiquem somente leitura, cada segmento possui apenas uma visão parcial de todos os seus dados. Isso significa que os quantis calculados se aplicam diretamente apenas a esse conjunto de amostras do total de seus dados. Isso não é um grande problema se sua amostra representar adequadamente todo o seu conjunto de dados. Mas o Lucene permite que você classifique seu índice de várias maneiras. Portanto, você pode estar indexando dados classificados de uma forma que introduza viés nos cálculos de quantis por segmento. Além disso, você pode apagar os dados quando quiser! Seu conjunto de amostras pode ser minúsculo, até mesmo contendo apenas um vetor. Outro fator complicador é que você tem controle sobre quando as fusões ocorrem. Embora o Elasticsearch tenha configurações padrão e mesclagem periódica definidas, você pode solicitar uma mesclagem sempre que desejar por meio da API _force_merge . Como podemos, então, manter toda essa flexibilidade e, ao mesmo tempo, fornecer uma boa quantização que proporcione uma boa recuperação?

A quantização vetorial do Lucene se ajustará automaticamente ao longo do tempo. Como o Lucene foi projetado com uma arquitetura de segmentos somente leitura, temos a garantia de que os dados em cada segmento não foram alterados e demarcações claras no código para quando as coisas podem ser atualizadas. Isso significa que, durante a fusão de segmentos, podemos ajustar os quantis conforme necessário e, possivelmente, requantizar os vetores.

Figura 4: Três exemplos de segmentos com diferentes quantis.

Mas a requantização não é cara? Possui alguma sobrecarga, mas o Lucene lida com quantis de forma inteligente e só requantiza completamente quando necessário. Vamos usar os segmentos da Figura 4 como exemplo. Vamos atribuir e , e apenas documentos ao segmento O Lucene calculará a média ponderada dos quantis e, se o quantil resultante da fusão for suficientemente próximo dos quantis originais do segmento, não será necessário requantizar esse segmento, utilizando-se os quantis recém-combinados.

Figura 5: Exemplo de quantis combinados onde os segmentos e têm documentos e tem apenas .

Na situação visualizada na figura 5, podemos ver que os quantis resultantes da fusão são muito semelhantes aos quantis originais em e Portanto, eles não justificam a quantização dos vetores. O segmento parece desviar-se demasiado. Consequentemente, os vetores em seriam requantizados com os valores de quantil recém-combinados.

Existem, de fato, casos extremos em que os quantis combinados diferem drasticamente de quaisquer quantis originais. Neste caso, iremos extrair uma amostra de cada segmento e recalcular completamente os quantis.

Desempenho e números da quantização

Então, é rápido e ainda oferece boa capacidade de memorização? Os números a seguir foram coletados executando o experimento em uma instância c3-standard-8 do GCP. Para garantir uma comparação justa com usamos uma instância grande o suficiente para armazenar vetores brutos na memória. Indexamos vetores do Cohere Wiki usando o método do produto interno máximo.

Figura 6: Recall@10 para vetores quantizados versus vetores brutos. O desempenho de busca de vetores quantizados é significativamente mais rápido do que o de vetores brutos, e a recuperação é rapidamente possível reunindo apenas mais 5 vetores; visível por .

A Figura 6 ilustra a história. Embora haja uma diferença na recordação, como era de se esperar, ela não é significativa. Além disso, a diferença na taxa de recall desaparece ao coletar apenas mais 5 vetores. Tudo isso com fusões de segmentos mais rápidas e 1/4 da memória dos vetores .

Conclusão

O Lucene oferece uma solução única para um problema difícil. Não há necessidade de uma etapa de "treinamento" ou "otimização" para a quantização. No Lucene, simplesmente funcionará. Não há necessidade de se preocupar com a possibilidade de ter que "re-treinar" seu índice vetorial caso seus dados mudem. O Lucene detectará mudanças significativas e cuidará disso automaticamente ao longo da vida útil dos seus dados. Aguardem ansiosamente o momento em que implementaremos essa funcionalidade no Elasticsearch!

O que faz o Sysgrok?

O Sysgrok pode fazer coisas como:

• Selecione as funções e os processos mais dispendiosos identificados por um analisador de desempenho, explique a funcionalidade que cada um oferece e sugira otimizações.

• Receba um host e uma descrição do problema que esse host está enfrentando e depure automaticamente o problema, sugerindo soluções e ações adicionais.

• Pegue o código-fonte que foi anotado por um profiler, explique os caminhos críticos (hot paths) e sugira maneiras de melhorar o desempenho do código.

A funcionalidade do Sysgrok visa três grandes categorias de soluções:

1. Como mecanismo de análise para desempenho, confiabilidade e outros dados relacionados a sistemas. Nesse modo, o LLM recebe a saída de alguma outra ferramenta usada pelo engenheiro (por exemplo, uma ferramenta de linha de comando do Linux, um profiler ou uma plataforma de observabilidade). O objetivo do Sysgrok é interpretar, resumir e formular hipóteses sobre o estado do sistema usando um Modelo de Liderança Linear (LLM). Também pode sugerir otimizações ou correções.

2. Como uma solução automatizada e focada para tarefas específicas relacionadas a desempenho e confiabilidade. Existem algumas tarefas que surgem repetidamente no trabalho de engenharia de desempenho e SRE (Confiabilidade de Site). Para isso, podemos construir assistentes automatizados e focados que podem ser usados diretamente pelo engenheiro ou pelo próprio Sysgrok na resolução de outros problemas. Por exemplo, em engenharia de desempenho, é comum responder à pergunta: "Existe uma versão mais rápida desta biblioteca com funcionalidade equivalente?". O sysgrok oferece suporte direto a isso.

3. Como uma ferramenta automatizada de análise de causa raiz para problemas de desempenho e confiabilidade. As duas primeiras categorias de solução são uma mistura de análise de dados, interpretação, pesquisa e sumarização. Fundamentalmente, elas são aplicadas de forma direcionada aos dados que o próprio engenheiro coletou. No Sysgrok, também estamos investigando uma terceira abordagem para a resolução de problemas com LLMs, na qual o LLM é combinado com outras ferramentas para realizar, de forma autônoma, a análise da causa raiz e a resolução de um determinado problema. Nessa abordagem, o LLM recebe uma descrição do problema (por exemplo, "O servidor web está apresentando alta latência") e é informado sobre quais recursos estão disponíveis para ele (por exemplo, "conectar-se a um host via SSH", "executar ferramentas de linha de comando Linux arbitrárias"). Em seguida, o LLM é questionado sobre as ações a serem tomadas, utilizando os recursos disponíveis, para priorizar o problema. Essas ações são executadas pelo Sysgrok, e o Gerente de Liderança de Equipe (LLM) é solicitado a analisar os resultados, priorizar o problema, sugerir soluções e recomendar os próximos passos.

O sysgrok ainda está em seus estágios iniciais, mas estamos lançando-o porque já se mostrou útil para diversas tarefas — esperamos que seja uma base conveniente para que outros realizem experimentos semelhantes. Fique à vontade para nos enviar PRs ou abrir issues no GitHub se tiver alguma ideia!

Analisando problemas de desempenho com LLMs

Os modelos de linguagem natural (LLMs), como os modelos GPT da OpenAI, explodiram em popularidade nos últimos meses, fornecendo uma interface de linguagem natural e servindo como mecanismo central para todos os tipos de produtos, desde chatbots de atendimento ao cliente até assistentes de manipulação de dados e assistentes de programação. Um aspecto interessante dessa tendência é que, essencialmente, todas essas aplicações utilizam modelos genéricos e prontos para uso, que não foram especificamente treinados ou ajustados para a tarefa em questão. Em vez disso, foram treinadas em grandes extensões da internet como um todo e, como resultado, são aplicáveis a uma ampla variedade de tarefas.

Então, podemos usar esses modelos para auxiliar na análise de desempenho, depuração e otimização? Existem diversas metodologias para investigar problemas de desempenho, identificar as causas principais e propor otimizações. Em sua essência, qualquer trabalho de análise de desempenho envolverá a observação da saída de várias ferramentas, como ferramentas de linha de comando do Linux ou uma plataforma de observabilidade, e a interpretação dessa saída para formular uma hipótese sobre o estado do sistema. Entre os materiais utilizados no treinamento dos modelos GPT, encontram-se fontes que abrangem engenharia de software, depuração, análise de infraestrutura, funcionamento interno de sistemas operacionais, Kubernetes, comandos Linux e sua utilização, além de metodologias de análise de desempenho. Como resultado, os modelos podem ser usados para resumir, interpretar e formular hipóteses sobre os dados e problemas que os engenheiros de desempenho encontram no dia a dia, o que pode acelerar o ritmo com que um engenheiro realiza suas análises.

Podemos ir além e utilizar o LLM não apenas para análise de dados e resposta a perguntas, mas também no contexto do processo investigativo do próprio engenheiro. Como mostraremos mais adiante neste post, o próprio LLM pode ser usado para direcionar o processo em alguns cenários, decidindo quais comandos executar ou quais fontes de dados analisar para depurar um problema.

Demos

Para obter a lista completa de recursos suportados pelo sysgrok, consulte o repositório do GitHub. De forma geral, apoia três abordagens para a resolução de problemas:

Abordagem 1: Como um mecanismo de análise para desempenho, confiabilidade e outros dados relacionados a sistemas.

Nesse modo, o LLM recebe a saída de outra ferramenta que está sendo usada pelo engenheiro, como uma ferramenta de linha de comando do Linux, um profiler ou uma plataforma de observabilidade. O objetivo do Sysgrok é interpretar, resumir e sugerir soluções.

Por exemplo, o subcomando topn analisa as funções mais custosas, conforme relatado por um profiler, explica a saída e, em seguida, sugere maneiras de otimizar o sistema.

Este vídeo também mostra a funcionalidade de chat oferecida pelo Sysgrok. Ao receber o argumento –chat, o sysgrok iniciará uma sessão de bate-papo após cada resposta do LLM.

Essa funcionalidade também pode ser aplicada genericamente à saída de ferramentas de linha de comando do Linux. Por exemplo, no artigo Análise de desempenho do Linux em 60 segundos, Brendan Gregg descreve 10 comandos que um SRE deve executar ao se conectar pela primeira vez a um host que esteja apresentando um problema de desempenho ou estabilidade. O subcomando analyzecmd recebe como entrada um host ao qual se conectar e um comando a ser executado, analisando e resumindo a saída do comando para o usuário. Podemos usar isso para automatizar o processo descrito por Gregg e fornecer ao usuário um resumo de um parágrafo com todos os dados gerados pelos 10 comandos, evitando que ele tenha o trabalho de analisar a saída de cada comando individualmente.

Abordagem 2: Como uma solução focada e automatizada para tarefas específicas relacionadas a desempenho e confiabilidade.

Existem algumas tarefas que surgem repetidamente no trabalho de engenharia de desempenho e SRE (Confiabilidade de Site). Para isso, podemos construir assistentes automatizados e focados que podem ser usados diretamente pelo engenheiro ou pelo próprio Sysgrok na resolução de outros problemas.

Por exemplo, o subcomando findfaster recebe como entrada o nome de uma biblioteca ou programa e usa o LLM para encontrar uma alternativa equivalente mais rápida. Essa é uma tarefa muito comum em engenharia de desempenho.

Outro exemplo dessa abordagem no Sysgrok é o subcomando explainfunction . Este subcomando recebe o nome de uma biblioteca e uma função dentro dessa biblioteca. O texto explica o que a biblioteca faz e seus casos de uso comuns, e em seguida explica a função. Por fim, sugere possíveis otimizações caso essa biblioteca e função estejam consumindo uma quantidade significativa de recursos da CPU.

Abordagem 3: Como uma ferramenta automatizada de análise de causa raiz para problemas de desempenho e confiabilidade.

A utilização de LLMs não se limita apenas a respostas a perguntas específicas, sumarização e tarefas semelhantes. E não se limita a um uso pontual, em que lhes é feita uma única pergunta isolada. O subcomando sysgrok debughost demonstra como um LLM pode ser usado como o "cérebro" em um agente com o objetivo de resolução automatizada de problemas. Nesse modo, o LLM está incorporado em um processo que o utiliza para decidir como depurar um problema específico e lhe confere a capacidade de se conectar a hosts, executar comandos e acessar outras fontes de dados.

O comando debughost é provavelmente a parte mais experimental do sysgrok no momento. Isso demonstra um passo no caminho rumo a agentes automatizados para análise de desempenho, mas ainda é necessário um investimento significativo em pesquisa e desenvolvimento para chegarmos lá.

Conclusão

Neste post, apresentei o Sysgrok, um novo assistente de IA de código aberto para analisar, compreender e otimizar sistemas. Também discutimos as três categorias gerais de abordagem que o Sysgrok implementa:

1. Um mecanismo de análise para desempenho, confiabilidade e outros dados relacionados a sistemas: consulte os subcomandos topn, stacktrace, analyzecmd e code.

2. Soluções automatizadas e focadas em tarefas específicas relacionadas a desempenho e confiabilidade: consulte os subcomandos explainprocess, explainfunction e findfaster.

3. Análise automatizada da causa raiz para problemas de desempenho e confiabilidade: consulte o subcomando debughost.

Você pode encontrar o projeto sysgrok no GitHub. Fique à vontade para criar PRs e Issues, ou entre em contato comigo diretamente pelo e-mail sean.heelan@elastic.co se quiser discutir o projeto ou as aplicações de LLMs em geral.

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.

Histórico

Ao desenvolver o Elasticsearch, ocasionalmente nos deparamos com um problema importante para o qual não existe uma abordagem simples ou estabelecida para resolvê-lo. É natural perguntar: "Hum, existe algum artigo acadêmico que aborde esse assunto?" Outras vezes, o trabalho acadêmico é uma fonte de inspiração. Nos deparamos com um artigo que propõe um novo algoritmo ou estrutura de dados e pensamos: "Isso seria muito útil!" Aqui estão alguns exemplos de como o Elasticsearch e o Apache Lucene incorporam o trabalho acadêmico:

• HyperLogLog++ para agregações de cardinalidade

• Algoritmo C3 para seleção adaptativa de réplicas

• Grafos Hierárquicos Navegáveis de Pequeno Mundo (HNSW) para busca de vetor mais próximo no Lucene.

• Estatística MIC para aprimorar a classificação em aprendizado de máquina.

• Block-max WAND para recuperação mais rápida dos melhores resultados no Lucene

• ... e muito mais

Artigos acadêmicos são um recurso inestimável para engenheiros que desenvolvem sistemas com uso intensivo de dados. Mas implementá-los pode ser intimidante e propenso a erros — as descrições dos algoritmos costumam ser complexas, com detalhes práticos importantes omitidos. E os testes representam um verdadeiro desafio: por exemplo, como podemos testar minuciosamente um algoritmo de aprendizado de máquina cujo resultado depende fortemente do conjunto de dados?

Avalie o artigo como se fosse uma dependência de software.

Adicionar uma nova dependência de software exige uma avaliação cuidadosa: se o outro pacote estiver incorreto, lento ou inseguro, nosso projeto também poderá estar. Antes de incluir uma dependência, os desenvolvedores certificam-se de avaliar sua qualidade.

O mesmo se aplica aos artigos acadêmicos que você está considerando publicar. Pode parecer que, pelo simples fato de um algoritmo ter sido publicado em um artigo, ele deve estar correto e ter um bom desempenho. Mas, mesmo tendo passado por um processo de revisão, um artigo acadêmico pode apresentar problemas. Talvez a prova de correção dependa de pressupostos que não são realistas. Ou talvez a seção de "experimentos" mostre um desempenho muito melhor do que a linha de base, mas isso só se aplica a um conjunto de dados específico. Mesmo que o artigo seja de ótima qualidade, sua abordagem pode não ser adequada para o seu projeto.

Ao considerar se devemos ou não nos “depender” de um artigo acadêmico, é útil fazer as mesmas perguntas que faríamos sobre um pacote de software:

• A biblioteca é amplamente utilizada e "testada em situações reais"? → Outros pacotes implementaram este artigo e funcionou bem para eles?

• Existem parâmetros de comparação de desempenho disponíveis? Essas medidas parecem precisas e justas? → O artigo inclui experimentos realistas? Eles são bem projetados?

• A melhoria de desempenho é suficientemente significativa para justificar a complexidade? → O artigo se compara a uma abordagem de referência robusta? Em quanto ele supera essa linha de base?

• Essa abordagem se integrará bem ao nosso sistema? → As premissas e as compensações do algoritmo são adequadas ao nosso caso de uso?

Por algum motivo, quando um pacote de software publica uma comparação de desempenho com seus concorrentes, ele sempre acaba sendo o mais rápido! Se os parâmetros de referência fossem elaborados por terceiros, eles poderiam ser mais equilibrados. O mesmo fenômeno se aplica a artigos acadêmicos. Se um algoritmo apresenta bom desempenho não apenas no artigo original, mas também aparece em outros artigos como uma base de referência sólida, então é muito provável que seja confiável.

Seja criativo nos testes.

Os algoritmos descritos em artigos acadêmicos geralmente apresentam um comportamento mais sofisticado do que os tipos de algoritmos que encontramos rotineiramente. Talvez seja um algoritmo de aproximação que prioriza a velocidade em detrimento da precisão. Ou talvez seja um método de aprendizado de máquina que recebe um grande conjunto de dados e produz resultados (às vezes inesperados). Como podemos escrever testes para esses algoritmos se não conseguimos caracterizar seu comportamento de forma simples?

Foco nos invariantes

Ao projetar testes unitários, é comum pensar em termos de exemplos: se fornecermos ao algoritmo esta entrada de exemplo, ele deverá produzir aquela saída. Infelizmente, para a maioria dos algoritmos matemáticos, os testes baseados em exemplos não abrangem suficientemente seu comportamento.

Vamos considerar o algoritmo C3, que o Elasticsearch usa para determinar qual nó deve processar uma solicitação de pesquisa. O sistema classifica cada nó usando uma fórmula complexa que incorpora o serviço anterior do nó, os tempos de resposta e o tamanho da sua fila. Testar alguns exemplos não garante que entendemos a fórmula corretamente. É útil dar um passo atrás e pensar em testar invariantes: se o tempo de serviço aumentar, a classificação do nó diminui? Se o tamanho da fila for 0, a classificação é determinada pelo tempo de resposta, como afirma o artigo?

Focar nos invariantes pode ajudar em diversos casos comuns:

• O método deve ser independente da ordem? Nesse caso, passar os dados de entrada em uma ordem diferente deve resultar na mesma saída.

• Alguma etapa do algoritmo produz probabilidades de classe? Nesse caso, a soma dessas probabilidades deve ser igual a 1.

• A função é simétrica em relação à origem? Nesse caso, inverter o sinal da entrada deve simplesmente inverter o sinal da saída.

Quando implementamos o C3 pela primeira vez, encontramos um erro na fórmula em que, acidentalmente, usamos o inverso do tempo de resposta em vez do próprio tempo de resposta. Isso significava que os nós mais lentos podiam ser classificados em posições mais altas! Ao corrigir o problema, garantimos a adição de verificações de invariância para evitar erros futuros.

Compare com uma implementação de referência.

Juntamente com o artigo, espera-se que os autores tenham publicado uma implementação do algoritmo. (Isso é especialmente provável se o artigo contiver experimentos, já que muitas revistas exigem que os autores publiquem o código para reproduzir os resultados.) Você pode testar sua abordagem em relação a esta implementação de referência para garantir que não tenha deixado passar detalhes importantes do algoritmo.

Ao desenvolver a implementação HNSW do Lucene para busca de vizinhos mais próximos, realizamos testes em relação a uma biblioteca de referência dos autores do artigo. Executamos o Lucene e a biblioteca no mesmo conjunto de dados, comparando a precisão dos resultados e o número de cálculos realizados. Quando esses números coincidem de perto, sabemos que o Lucene implementa o algoritmo fielmente.

Ao incorporar um algoritmo em um sistema, muitas vezes é necessário fazer modificações ou extensões, como escalá-lo para vários núcleos ou adicionar heurísticas para melhorar o desempenho. O ideal é primeiro implementar uma versão "vanilla", testá-la em comparação com a versão de referência e, em seguida, fazer alterações incrementais. Dessa forma, você pode ter certeza de que capturou todas as partes principais antes de fazer personalizações.

Duelo contra um algoritmo existente

A última seção levanta outra ideia para um invariante de teste: comparar a saída do algoritmo com a saída de um algoritmo mais simples e melhor compreendido. Como exemplo, considere o algoritmo block-max WAND do Lucene, que acelera a recuperação de documentos ignorando aqueles que não podem aparecer nos primeiros resultados. É difícil descrever exatamente como o WAND com block-max deve se comportar em todos os casos, mas sabemos que aplicá-lo não deve alterar os melhores resultados! Assim, nossos testes podem gerar diversas consultas de pesquisa aleatórias e, em seguida, executá-las com e sem a otimização WAND , verificando se os resultados sempre coincidem.

Um aspecto importante desses testes é que eles geram entradas aleatórias para realizar a comparação. Isso pode ajudar a analisar casos que você não teria imaginado e revelar problemas inesperados. Como exemplo, o teste de comparação aleatória do Lucene para pontuação BM25F ajudou a detectar erros em casos extremos sutis. A ideia de alimentar um algoritmo com entradas aleatórias está intimamente relacionada ao conceito de fuzzing, uma técnica de teste comum em segurança da computação.

Elasticsearch e Lucene frequentemente utilizam essa abordagem de teste. Se você vir um teste que menciona um "duelo" entre dois algoritmos (TestDuelingAnalyzers, testDuelTermsQuery...), então você sabe que essa estratégia está em ação.

Utilize a terminologia do artigo.

Quando outro desenvolvedor trabalhar com seu código, ele precisará consultar o documento para seguir os detalhes. O comentário sobre a implementação do HyperLogLog++ do Elasticsearch resume bem a situação: "Tentar entender o que essa classe faz sem ter lido o artigo é considerado uma aventura." Este comentário sobre o método também serve de bom exemplo. Inclui um link para o artigo acadêmico e destaca as modificações feitas no algoritmo em relação à sua descrição original.

Como os desenvolvedores irão basear sua compreensão do código no documento, é útil usar exatamente a mesma terminologia. Como a notação matemática é concisa, isso pode resultar em nomes que normalmente não seriam considerados de "bom estilo", mas que são muito claros no contexto do artigo. As fórmulas de artigos acadêmicos são uma das poucas ocasiões em que você encontrará nomes de variáveis enigmáticos no Elasticsearch, como rS e muBarSInverse.

A maneira recomendada pelo autor para ler um artigo: com um café bem forte.

Você pode enviar um e-mail ao autor.

Ao analisar uma prova difícil, você pode passar horas tentando decifrar uma fórmula, sem saber se está entendendo errado ou se há apenas um erro de digitação. Se fosse um projeto de código aberto, você poderia fazer a pergunta no GitHub ou no StackOverflow. Mas onde você pode encontrar um artigo acadêmico? Os autores parecem estar ocupados e podem se incomodar com seus e-mails.

Pelo contrário, muitos acadêmicos adoram saber que suas ideias estão sendo colocadas em prática e ficam felizes em responder a perguntas por e-mail. Se você trabalhar em um produto com o qual eles estejam familiarizados, eles podem até listar o aplicativo em seu site!

Há também uma tendência crescente entre os acadêmicos de discutir artigos publicamente, utilizando muitas das mesmas ferramentas do desenvolvimento de software. Se um artigo for acompanhado de um pacote de software, você poderá encontrar respostas para perguntas frequentes no Github. Comunidades do Stack Exchange como "Theoretical Computer Science" e "Cross Validated" também contêm discussões detalhadas sobre artigos populares. Algumas conferências começaram a publicar todas as resenhas de artigos online. Essas resenhas contêm discussões com os autores que podem revelar informações úteis sobre a abordagem.

Continua

Este post aborda os princípios básicos da escolha de um artigo acadêmico e

implementá-lo corretamente é suficiente, mas não abrange todos os aspectos da implantação do algoritmo. Por exemplo, se o algoritmo for apenas um componente em um sistema complexo, como podemos garantir que as alterações nesse componente levem a melhorias de ponta a ponta? E se a integração do algoritmo exigir modificações ou extensões substanciais que o artigo original não aborda? Esses são tópicos importantes sobre os quais esperamos compartilhar mais em publicações futuras.