Partindo dos exemplos da parte 1, este post explora como usar diferentes técnicas e o conjunto avançado de ferramentas de busca vetorial do Elasticsearch para preparar vetores de interação tardia para cargas de trabalho de produção em grande escala.

Os exemplos completos de código estão disponíveis no GitHub.

Desafios dos modelos de interação tardia

O ColPali cria mais de 1.000 vetores por página para os documentos do nosso índice.

Isso resulta em dois desafios ao trabalhar com vetores de interação tardia:

1. Espaço em disco: salvar todos esses vetores em disco gera um volume significativo de armazenamento, o que se torna caro em ambientes de grande escala.

2. Computação: ao classificar documentos usando a comparação maxSimDotProduct(), precisamos comparar todos esses vetores de cada documento com os N vetores da consulta.

Vamos analisar algumas técnicas para lidar com esses desafios.

Técnicas para otimizar modelos de interação tardia

Vetores de bits

Para reduzir o espaço em disco, podemos comprimir as imagens em vetores de bits. Podemos usar uma função simples em Python para transformar nossos multivetores em vetores de bits:

O conceito central da função é simples: valores acima de 0 se tornam 1, e valores abaixo de 0 se tornam 0. Isso resulta em uma matriz de 0s e 1s, que depois transformamos em uma string hexadecimal que representa nosso vetor de bits.

Para o mapeamento de índice, configuramos o parâmetro element_type para bit:

Depois de gravar todos os novos vetores de bits no índice, podemos ranquear nossos vetores de bits usando o código a seguir:

Ao abrir mão de um pouco de precisão, isso nos permite usar a distância de Hamming (maxSimInvHamming(...)), que consegue explorar otimizações como bit masks, SIMD, entre outras. Saiba mais sobre vetores de bits e distância de Hamming em nosso blog.

Como alternativa, podemos não converter o vetor de consulta em vetores de bits e realizar a busca usando o vetor de interação tardia com fidelidade total:

Nesse caso, os vetores são comparados usando uma função de similaridade assimétrica.

Vamos considerar uma distância de Hamming padrão entre dois vetores de bits. Suponha que temos um vetor de documento D:

E um vetor de consulta Q:

A quantização binária simples transforma o vetor D em 10101101 e o vetor Q em 11111011. Para calcular a distância de Hamming, precisamos apenas de operações diretas em bits, algo extremamente rápido. Nesse caso, a distância de Hamming é 01010110, que possui uma contagem de bits igual a 4.Assim, a pontuação passa a ser o inverso dessa distância de Hamming. Lembre-se de que vetores mais semelhantes têm uma distância de Hamming MENOR, portanto inverter esse valor permite que vetores mais semelhantes recebam pontuações mais altas. Especificamente aqui, a pontuação seria 1/4 = 0.25.

No entanto, observe que perdemos a magnitude de cada dimensão. Um 1 é um 1. Assim, para Q, a diferença entre 0.01 e 0.79 desaparece. Como estamos simplesmente quantizando de acordo com >0, podemos aplicar um pequeno truque em que o vetor Q não é quantizado. Isso não permite a matemática bit a bit extremamente rápida, mas mantém o custo de armazenamento baixo, já que D continua quantizado.

Em resumo, essa abordagem preserva as informações contidas em Q, aumentando a qualidade da estimativa de distância e mantendo baixo o custo de armazenamento.

O uso de vetores de bits permite economizar significativamente espaço em disco e reduzir a carga computacional no momento da consulta. Mas ainda há mais que podemos fazer.

Vetores médios

Para redimensionar a busca para centenas de milhares de documentos, mesmo os ganhos de desempenho proporcionados pelos vetores de bits não serão suficientes. Para dar conta desse tipo de carga, será necessário aproveitar a estrutura de índice HNSW do Elasticsearch para busca vetorial.

O ColPali gera cerca de 1.000 vetores por documento, o que é excessivo para adicionar ao grafo HNSW. Portanto, precisamos reduzir a quantidade de vetores. Para isso, podemos criar uma única representação do significado do documento calculando a média de todos os vetores do documento produzidos pelo ColPali quando incorporamos a imagem.

No momento, isso não é possível diretamente no Elastic, sendo necessário pré-processar os vetores antes de ingeri-los no Elasticsearch.

Isso pode ser feito com o Logstash ou com pipelines de ingestão, mas aqui usaremos uma função simples em Python:

Também normalizamos o vetor para que possamos usar a similaridade por produto escalar.

Depois de transformar todos os vetores do ColPali em vetores médios, podemos indexá-los no campo dense_vector:

Precisamos considerar que isso aumentará o uso total de disco, pois estamos salvando mais informações junto com nossos vetores de interação tardia. Além disso, usaremos RAM adicional para manter o grafo HNSW, o que nos permite redimensionar a busca para bilhões de vetores. Para reduzir o uso de RAM, podemos recorrer ao nosso conhecido recurso BBQ. Com isso, obtemos resultados de busca rápidos em conjuntos de dados massivos que, de outra forma, não seriam viáveis.

Agora, simplesmente fazemos a busca com a consulta knn para encontrar os documentos mais relevantes.

O que antes era a melhor correspondência acabou caindo para a 3ª posição.

Para corrigir esse problema, podemos usar uma recuperação em vários estágios. No primeiro estágio, usamos a consulta knn para buscar os melhores candidatos para a consulta em meio a milhões de documentos. No segundo estágio, fazemos a reclassificação apenas dos top k (neste caso, 10) usando a maior fidelidade dos vetores de interação tardia do ColPali. 

Aqui, estamos usando o rescore retriever, introduzido na versão 8.18, para reclassificar nossos resultados. Após a reclassificação, vemos que a melhor correspondência volta a ocupar a primeira posição.

Observação: em uma aplicação de produção, podemos usar um valor de k muito maior que 10, já que a função max sim ainda é relativamente eficiente em termos de performance.

Agrupamento de tokens

O agrupamento de tokens reduz o comprimento da sequência de embeddings multivetoriais ao agrupar informações redundantes, como regiões de fundo branco. Essa técnica diminui o número de embeddings ao mesmo tempo que preserva a maior parte do sinal da página.

O agrupamento de tokens funciona reunindo embeddings de tokens semelhantes dentro de um documento em clusters, usando um algoritmo de clusterização. Em seguida, calcula-se a média dos vetores em cada cluster para criar uma única representação agregada. Esse vetor agregado substitui os tokens originais do grupo, reduzindo o número total de vetores sem perda significativa do sinal do documento.

O artigo do ColPali propõe um valor inicial de agrupamento factor igual a 3 para a maioria dos conjuntos de dados, mantendo 97,8% da performance original ao mesmo tempo que reduz o número total de vetores em 66,7%. 

Mas é preciso cautela: o conjunto de dados Shift, que contém documentos muito densos e com grande volume de texto e pouco espaço em branco, apresenta uma queda rápida de desempenho conforme o fator de agrupamento aumenta.

Para criar os vetores agrupados, podemos usar a biblioteca colpali_engine:

Agora temos um vetor que teve suas dimensões reduzidas em cerca de 66,7%. Nós o indexamos normalmente e conseguimos realizar buscas usando nossa função maxSimDotProduct().

Conseguimos obter bons resultados de busca ao custo de uma leve perda de precisão nos resultados.

Dica: com um pool_factor mais alto (100-200), também é possível encontrar um meio-termo entre a solução de vetor médio e a abordagem discutida aqui. Com cerca de 5 a 10 vetores por documento, torna-se viável indexá-los em um campo aninhado para aproveitar o índice HNSW.

Cross-encoder vs. interação tardia vs. bi-encoder

Com tudo o que aprendemos até aqui, onde isso posiciona os modelos de interação tardia, como ColPali ou ColBERT, em comparação com outras técnicas de recuperação baseadas em IA?

Embora a função max sim seja mais barata do que o uso de cross-encoders, ela ainda exige muito mais comparações e processamento do que a busca vetorial com bi-encoders, em que comparamos apenas dois vetores para cada par consulta-documento.

Por isso, nossa recomendação para modelos de interação tardia é, em geral, usá-los apenas para reclassificação dos primeiros k resultados de busca. Também refletimos isso no nome do tipo de campo: rank_vectors.

Mas e o cross-encoder? Modelos de interação tardia são melhores por serem mais baratos de executar no momento da consulta? Como acontece com frequência, a resposta é: depende. Os cross-encoders normalmente produzem resultados de maior qualidade, mas exigem muito processamento, já que cada par consulta-documento precisa passar completamente pelo modelo transformer. Eles também se beneficiam do fato de não exigirem indexação de vetores e poderem operar de forma stateless. Isso resulta em:

• Menor uso de espaço em disco

• Um sistema mais simples

• Maior qualidade nos resultados de busca

• Maior latência, o que limita a profundidade da reclassificação

Por outro lado, os modelos de interação tardia podem deslocar parte desse custo computacional para o momento da indexação, tornando a consulta mais barata. O preço a pagar é a necessidade de indexar vetores, o que torna os pipelines de indexação mais complexos e exige mais espaço em disco para armazená-los.

No caso específico do ColPali, a análise de informações provenientes de imagens é muito custosa, já que elas contêm grandes volumes de dados. Nesse cenário, o equilíbrio pende a favor do uso de um modelo de interação tardia como o ColPali, pois avaliar essas informações no momento da consulta seria lento demais e exigiria muitos recursos.

Já para um modelo de interação tardia como o ColBERT, que trabalha com dados textuais, assim como a maioria dos cross-encoders, por exemplo o elastic-rerank-v1, a decisão pode favorecer o uso do cross-encoder, aproveitando a economia de disco e a maior simplicidade operacional.

Recomendamos que você avalie esses prós e contras no seu caso de uso e experimente as diferentes ferramentas que o Elasticsearch oferece para criar as melhores aplicações de busca.

Conclusão

Neste blog, exploramos várias técnicas para otimizar modelos de interação tardia, como o ColPali, para busca vetorial em grande escala no Elasticsearch. Embora esses modelos ofereçam um forte equilíbrio entre eficiência de recuperação e qualidade de classificação, eles também introduzem desafios relacionados a armazenamento e computação.

Para enfrentar esses desafios, analisamos diferentes abordagens e técnicas:

• Vetores de bits para reduzir significativamente o uso de espaço em disco, ao mesmo tempo que aproveitam computações de similaridade eficientes, como a distância de Hamming ou a similaridade máxima assimétrica.

• Vetores médios para comprimir múltiplos embeddings em uma única representação densa, permitindo recuperação eficiente com indexação HNSW.

• Agrupamento de tokens para unir embeddings redundantes de forma inteligente, mantendo a integridade semântica e reduzindo a sobrecarga computacional no momento da consulta.

O Elasticsearch oferece um conjunto poderoso de ferramentas para personalizar e otimizar aplicações de busca de acordo com suas necessidades. Seja priorizando velocidade de recuperação, qualidade de ranqueamento ou eficiência de armazenamento, essas técnicas permitem equilibrar desempenho e qualidade conforme as exigências de aplicações do mundo real.

Depurar erros de concorrência não é tarefa fácil, mas vamos abordar o assunto. Apresentamos o Fray, uma estrutura de teste de concorrência determinística do PASTA Lab da CMU, que transforma falhas instáveis em falhas reproduzíveis de forma confiável. Graças ao engenhoso design de trava sombreada e ao controle preciso da rosca do Fray, conseguimos localizar e finalmente eliminar um bug complexo do Lucene. Este artigo explora como ferramentas e projetos de código aberto estão tornando a depuração de concorrência menos trabalhosa — e o mundo do software muito melhor.

Erros de concorrência: o pesadelo dos engenheiros de software

Os piores bugs relacionados à concorrência são os seguintes. Além de serem difíceis de consertar, o mais complicado é justamente fazê-los falhar de forma consistente. Tomemos como exemplo esta falha de teste, TestIDVersionPostingsFormat#testGlobalVersions. Isso gera várias threads de escrita e atualização de documentos, desafiando o modelo de concorrência otimista do Lucene. Este teste revelou uma condição de corrida no controle de concorrência otimista. Ou seja, uma operação em um documento pode alegar falsamente ser a última em uma sequência de operações 😱. Ou seja, em certas condições, uma operação de atualização ou exclusão pode, na verdade, ter sucesso quando deveria ter falhado, considerando restrições de concorrência otimistas.

Pedimos desculpas àqueles que detestam rastreamentos de pilha do Java. Note que "excluir" não significa necessariamente "excluir". Também pode indicar uma "atualização" do documento, já que os segmentos do Lucene são somente leitura.

O Apache Lucene gerencia cada thread que está escrevendo documentos através da classe DocumentsWriter . Esta classe criará ou reutilizará threads para escrita de documentos e cada ação de escrita controla suas informações dentro da classe DocumentsWriterPerThread (DWPT). Além disso, o escritor mantém o controle de quais documentos são excluídos no DocumentsWriterDeleteQueue (DWDQ). Essas estruturas mantêm todas as ações de mutação de documentos na memória e são periodicamente liberadas, liberando recursos na memória e persistindo as estruturas em disco.

Na tentativa de evitar o bloqueio de threads e garantir alto desempenho em sistemas concorrentes, o Apache Lucene tenta sincronizar apenas em seções críticas. Embora isso possa ser bom na prática, como em qualquer sistema concorrente, existem problemas.

Uma falsa esperança

Minha investigação inicial apontou para algumas seções críticas que não estavam devidamente sincronizadas. Todas as interações com um dado DocumentsWriterDeleteQueue são controladas pelo seu envolvente DocumentsWriter. Assim, embora os métodos individuais possam não estar devidamente sincronizados no DocumentsWriterDeleteQueue, o seu acesso ao mundo está (ou deveria estar). (Não vamos entrar em detalhes sobre como isso complica as questões de propriedade e acesso — é um projeto de longa data escrito por muitos colaboradores.) Dê um desconto para isso.)

No entanto, encontrei um ponto durante a descarga que não estava sincronizado.

Essas ações não são sincronizadas em uma única operação atômica. Significa que, entre a criação de newQueue e a chamada de getMaxSeqNo, outro código poderia ter sido executado incrementando o número de sequência na classe documentsWriter . Encontrei o bug!

Mas, como acontece com a maioria dos bugs complexos, encontrar a causa raiz não foi simples. Foi então que um herói entrou em cena.

Um herói na batalha

Apresentamos nosso herói: Ao Li e seus colegas do Laboratório PASTA. Deixarei que ele explique como eles salvaram o dia com a ajuda de Fray.

Fray é uma estrutura de teste de concorrência determinística desenvolvida por pesquisadores do PASTA Lab, da Universidade Carnegie Mellon. A motivação por trás da criação do Fray surge de uma lacuna notável entre a academia e a indústria: embora os testes de concorrência determinísticos tenham sido amplamente estudados em pesquisas acadêmicas por mais de 20 anos, os profissionais continuam a depender de testes de estresse — um método amplamente reconhecido como não confiável e instável — para testar seus programas concorrentes. Assim, nosso objetivo principal era projetar e implementar uma estrutura de teste de concorrência determinística, tendo como metas a generalidade e a aplicabilidade prática.

A ideia central

Em sua essência, o Fray se baseia em um princípio simples, porém poderoso: a execução sequencial. O modelo de concorrência do Java oferece uma propriedadefundamental: se um programa estiver livre de condições de corrida (data races), todas as execuções parecerão sequencialmente consistentes. Isso significa que o comportamento do programa pode ser representado como uma sequência de instruções do programa.

O Fray funciona executando o programa alvo de forma sequencial: a cada passo, ele pausa todas as threads, exceto uma, permitindo que o Fray controle com precisão o agendamento das threads. Os threads são selecionados aleatoriamente para simular a concorrência, mas as escolhas são registradas para posterior reprodução determinística. Para otimizar a execução, o Fray realiza trocas de contexto apenas quando uma thread está prestes a executar uma instrução de sincronização, como bloqueio ou acesso atômico/volátil. Uma propriedade interessante da ausência de condições de corrida em relação aos dados é que essa troca de contexto limitada é suficiente para explorar todos os comportamentos observáveis devido a qualquer intercalação de threads (nosso artigo contém um esboço da demonstração).

O desafio: controlar o agendamento de threads

Embora a ideia central pareça simples, a implementação do Fray apresentou desafios significativos. Para controlar o agendamento de threads, o Fray precisa gerenciar a execução de cada thread da aplicação. À primeira vista, isso pode parecer simples: substituir primitivas de concorrência por implementações personalizadas. No entanto, o controle de concorrência na JVM é complexo, envolvendo uma combinação de instruções de bytecode, bibliotecas de alto nível e métodos nativos.

Isso acabou se revelando um verdadeiro labirinto:

• Por exemplo, cada instrução MONITORENTER deve ter uma correspondente MONITOREXIT no mesmo método. Se Fray substituir MONITORENTER por uma chamada de método para um stub/mock, também precisará substituir MONITOREXIT.

• Em código que faz uso de object.wait/notify, se MONITORENTER for substituído, o object.wait correspondente também deverá ser substituído. Esta cadeia de substituição estende-se até object.notify e além.

• A JVM invoca certos métodos relacionados à concorrência (por exemplo, object.notify quando uma thread termina) dentro do código nativo. Substituir essas operações exigiria modificar a própria JVM.

• Funções da JVM, como carregadores de classe e threads de coleta de lixo (GC), também usam primitivas de concorrência. Modificar esses elementos primitivos pode criar incompatibilidades com essas funções da JVM.

• A substituição de primitivas de concorrência no JDK frequentemente resulta em falhas da JVM durante sua fase de inicialização.

Esses desafios deixaram claro que uma substituição completa das primitivas de concorrência não era viável.

Nossa solução: design de fechadura sombreada

Para lidar com esses desafios, o Fray utiliza um novo mecanismo de bloqueio sombra para orquestrar a execução de threads sem substituir as primitivas de concorrência. Os bloqueios de sombra atuam como intermediários que orientam a execução das threads. Por exemplo, antes de adquirir um bloqueio, um thread de aplicação deve interagir com seu bloqueio sombra correspondente. O mecanismo de travamento por sombra determina se a rosca consegue obter a trava. Se a thread não puder prosseguir, o bloqueio sombra a bloqueia e permite que outras threads sejam executadas, evitando impasses e permitindo concorrência controlada. Este design permite que o Fray controle o entrelaçamento de threads de forma transparente, preservando a correção da semântica de concorrência. Cada primitiva de concorrência é cuidadosamente modelada dentro da estrutura de bloqueio sombra para garantir solidez e completude. Mais detalhes técnicos podem ser encontrados em nosso artigo.

Além disso, este projeto foi concebido para ser à prova de futuro. Ao exigir apenas a instrumentação de bloqueios de sombra em torno de primitivas de concorrência, garante-se a compatibilidade com versões mais recentes da JVM. Isso é viável porque as interfaces das primitivas de concorrência na JVM são relativamente estáveis e permaneceram inalteradas por anos.

Testando Fray

Após a construção do Fray, o próximo passo foi a avaliação. Felizmente, muitas aplicações, como o Apache Lucene, já incluem testes de concorrência. Esses testes de concorrência são testes JUnit regulares que criam várias threads, executam algum trabalho e, em seguida (geralmente), esperam que essas threads terminem para então verificar alguma propriedade. Na maioria das vezes, esses testes são aprovados porque utilizam apenas uma intercalação. Pior ainda, alguns testes falham apenas ocasionalmente no ambiente CI/CD, como descrito anteriormente, tornando essas falhas extremamente difíceis de depurar. Ao executarmos os mesmos testes com o Fray, descobrimos inúmeros bugs. Notavelmente, Fray redescobriu bugs relatados anteriormente que permaneceram sem correção devido à falta de uma reprodução confiável, incluindo o foco deste blog: TestIDVersionPostingsFormat.testGlobalVersions. Felizmente, com o Fray, podemos reproduzi-los de forma determinística e fornecer aos desenvolvedores informações detalhadas, permitindo que eles reproduzam e corrijam o problema de forma confiável.

Próximos passos para Fray

Estamos muito satisfeitos em saber, por parte dos desenvolvedores da Elastic, que o Fray tem sido útil na depuração de bugs de concorrência. Continuaremos trabalhando no Fray para torná-lo disponível para mais desenvolvedores.

Nossos objetivos de curto prazo incluem aprimorar a capacidade do Fray de reproduzir deterministicamente a programação, mesmo na presença de outras operações não determinísticas, como um gerador de valores aleatórios ou o uso de object.hashcode. Nosso objetivo também é melhorar a usabilidade do Fray, permitindo que os desenvolvedores analisem e depurem testes de concorrência existentes sem qualquer intervenção manual. E, mais importante ainda, se você estiver enfrentando dificuldades para depurar ou testar problemas de concorrência em seu programa, gostaríamos muito de ouvir sua opinião. Por favor, não hesite em criar uma issue no repositório do Fray no Github.

Hora de corrigir o bug de concorrência

Graças a Ao Li e ao laboratório PASTA, agora temos uma instância confiável que falha neste teste! Finalmente podemos resolver isso. A questão principal residia em como DocumentsWriterPerThreadPool permitia a reutilização de threads e recursos.

Aqui podemos ver cada thread sendo criada, fazendo referência à fila de exclusão inicial na geração 0.

Então, o avanço da fila ocorrerá no momento do flush, visualizando corretamente as 7 ações anteriores na fila.

Mas, antes que todas as threads terminem de ser processadas, duas são reutilizadas para um documento adicional:

Esses valores incrementarão o seqNo acima do máximo assumido, que foi calculado durante o flush como 7. Observe o numDocsInRAM adicional para os segmentos _3 e _0

Isso faz com que o Lucene contabilize incorretamente a sequência de ações do documento durante um flush, acionando essa falha no teste.

Como toda boa correção de bugs, a solução em si consiste em cerca de 10 linhas de código. Mas dois engenheiros levaram vários dias para descobrir:

Nem todos os heróis usam capas.

Sim, é clichê, mas é verdade.

A depuração de programas concorrentes é extremamente importante. Esses bugs de concorrência complexos levam uma quantidade excessiva de tempo para serem depurados e resolvidos. Embora novas linguagens como Rust possuam mecanismos integrados para ajudar a prevenir condições de corrida como essa, a maior parte do software no mundo já está escrita, e escrita em alguma linguagem diferente de Rust. Java, mesmo depois de todos esses anos, ainda é uma das linguagens mais utilizadas. A melhoria da depuração em linguagens baseadas na JVM torna o mundo da engenharia de software melhor. E considerando que algumas pessoas acreditam que o código será escrito por Grandes Modelos de Linguagem, talvez nosso trabalho como engenheiros acabe sendo apenas depurar código LLM ruim, em vez de apenas nosso próprio código ruim. Mas, independentemente do futuro da engenharia de software, a depuração de programas concorrentes continuará sendo fundamental para a manutenção e o desenvolvimento de software.

Obrigado, Ao Li, e seus colegas do PASTA Lab, por tornarem tudo ainda melhor.

Este blog em particular é diferente do habitual. Não se trata de uma explicação de uma nova funcionalidade ou de um tutorial. Trata-se de uma única linha de código que levou três dias para ser escrita. Vamos corrigir uma possível corrupção no índice do Apache Lucene. Algumas informações importantes que espero que você tenha absorvido:

• Todos os testes instáveis são repetíveis, desde que haja tempo suficiente e as ferramentas certas.

• Várias camadas de testes são essenciais para sistemas robustos. No entanto, níveis mais altos de testes tornam-se cada vez mais difíceis de depurar e reproduzir.

• Sleep é um excelente depurador.

Como o Elasticsearch realiza testes

Na Elastic, temos uma infinidade de testes que são executados no código-fonte do Elasticsearch. Alguns são testes funcionais simples e focados, outros são testes de integração de "caminho feliz" de nó único, e outros ainda tentam quebrar o cluster para garantir que tudo se comporte corretamente em um cenário de falha. Quando um teste falha continuamente, um engenheiro ou uma ferramenta de automação cria um problema no GitHub e o sinaliza para que uma equipe específica o investigue. Este erro específico foi descoberto durante um teste do último tipo. Esses testes são complicados, às vezes só podendo ser repetidos após muitas tentativas.

O que esse teste realmente avalia?

Este teste em particular é interessante. Isso criará um mapeamento específico e o aplicará a um fragmento primário. Então, ao tentar criar uma réplica. A principal diferença é que, quando a réplica tenta analisar o documento, o teste injeta uma exceção, fazendo com que a recuperação falhe de uma forma surpreendente (mas esperada).

Tudo estava funcionando como esperado, com uma exceção importante. Durante a limpeza dos testes, validamos a consistência e, nesse ponto, o teste encontrou um problema.

Este teste não apresentou o resultado esperado. Durante a verificação de consistência, verificaríamos se todos os arquivos de segmento Lucene replicados e primários estavam consistentes. Significa não corrompido e totalmente replicado. Ter dados parciais ou corrompidos é muito pior do que ter uma falha completa. Segue abaixo o rastreamento de pilha assustador e resumido da falha.

De alguma forma, durante a falha de replicação forçada, o fragmento replicado acabou sendo corrompido! Deixe-me explicar a parte principal do erro em linguagem simples.

O Lucene é uma arquitetura baseada em segmentos, o que significa que cada segmento conhece e gerencia seus próprios arquivos somente leitura. Este segmento específico estava sendo validado por meio de seus SegmentCoreReaders para garantir que tudo estivesse em ordem. Cada leitor principal possui metadados armazenados que indicam quais tipos de campos e arquivos existem para um determinado segmento. No entanto, ao validar o formato Lucene90PointsFormat, alguns arquivos esperados estavam faltando. Com o arquivo de segmentos _0.cfs esperávamos um arquivo de formato de ponto chamado kdi. cfs significa "sistema de arquivos composto", no qual o Lucene às vezes combina todos os tipos de campo e todos os arquivos pequenos em um único arquivo maior para replicação mais eficiente e utilização de recursos. Na verdade, todas as três extensões de arquivo de ponto: kdd, kdi e kdm estavam faltando. Como é possível acessar um segmento do Lucene que espera encontrar um arquivo de ponto, mas ele está faltando?! Parece um bug de corrupção assustador!

O primeiro passo para qualquer correção de bug é replicá-lo.

Reproduzir a falha para esse bug específico foi extremamente difícil. Embora aproveitemos os testes de valores aleatórios no Elasticsearch, garantimos que cada falha seja acompanhada de uma semente aleatória (esperamos) reproduzível para que todas as falhas possam ser investigadas. Bem, isso funciona muito bem para todas as falhas, exceto aquelas causadas por uma condição de corrida.

Não importa quantas vezes eu tentasse, aquela semente específica nunca repetia a falha localmente. Mas existem maneiras de praticar os testes e buscar uma falha mais repetível.

Nosso conjunto de testes específico permite que um determinado teste seja executado mais de uma vez no mesmo comando por meio do parâmetro -Dtests.iters . Mas isso não era suficiente, eu precisava garantir que os threads de execução estivessem alternando e, assim, aumentando a probabilidade de ocorrência dessa condição de corrida. Outro problema no sistema era que o teste acabava demorando tanto para ser executado que o programa de execução do teste excedia o tempo limite. No fim, usei o seguinte comando bash extremamente complexo para executar o teste repetidamente:

E aí entra o estresse. Isso permite iniciar rapidamente um processo que consumirá todos os núcleos da CPU num instante. Executar o stress-ng aleatoriamente em várias iterações do teste com falha finalmente me permitiu replicar a falha. Mais um passo. Para sobrecarregar o sistema, basta abrir outra janela do terminal e executar o seguinte comando:

Revelando o bug

Agora que a falha no teste que revelou o bug é praticamente repetível, é hora de tentar encontrar a causa. O que torna este teste em particular estranho é que o Lucene está gerando um erro porque espera valores pontuais, mas nenhum valor pontual é adicionado diretamente pelo teste. Somente valores de texto. Isso me levou a considerar analisar as mudanças recentes em nossos campos de controle de concorrência otimista : _seq_no e _primary_term. Ambos são indexados como pontos e existem em todos os documentos do Elasticsearch.

De fato, um commit alterou nosso mapeador _seq_no ! SIM! Essa deve ser a causa! Mas minha empolgação durou pouco. Isso apenas alterou a ordem em que os campos foram adicionados ao documento. Antes dessa alteração, os campos _seq_no eram adicionados por último ao documento. Depois, eles foram adicionados primeiro. De jeito nenhum a ordem de adição de campos a um documento Lucene causaria essa falha...

Sim, a alteração na ordem em que os campos foram adicionados causou a falha. Isso foi surpreendente e acabou sendo um bug no próprio Lucene! Alterar a ordem em que os campos são analisados não deve alterar o comportamento da análise de um documento.

O bug no Lucene

De fato, o bug no Lucene se concentrava nas seguintes condições:

• Indexando um campo de valor de pontos (por exemplo) _seq_no)

• Ao tentar indexar um campo de texto, ocorre um erro durante a análise.

• Nesse estado atípico, abrimos um leitor quase em tempo real do escritor que apresentou a exceção de análise do índice de texto.

Mas, por mais que eu tentasse, não conseguia replicar completamente. Adicionei pontos de pausa para depuração diretamente em toda a base de código do Lucene. Tentei abrir leitores aleatoriamente durante o caminho da exceção. Cheguei a imprimir megabytes e megabytes de registros tentando encontrar o caminho exato onde ocorreu essa falha. Eu simplesmente não consegui. Passei um dia inteiro lutando e perdendo.

Então eu dormi.

No dia seguinte, reli o rastreamento de pilha original e descobri a seguinte linha:

Em todas as minhas tentativas de recriação, nunca configurei especificamente a política de mesclagem de retenção. A política SoftDeletesRetentionMergePolicy é usada pelo Elasticsearch para que possamos replicar com precisão as exclusões nas réplicas e garantir que todos os nossos controles de concorrência sejam responsáveis por quando os documentos são realmente removidos. Caso contrário, o Lucene terá controle total e os removerá em qualquer mesclagem.

Assim que adicionei essa política e reproduzi os passos mais básicos mencionados acima, a falha se repetiu imediatamente.

Nunca fiquei tão feliz em abrir um bug no Lucene.

Embora se apresentasse como uma condição de corrida no Elasticsearch, era simples escrever um teste que falhasse repetidamente no Lucene, uma vez que todas as condições fossem atendidas.

No fim, como todos os bons bugs, ele foi corrigido com apenas uma linha de código. Vários dias de trabalho para apenas uma linha de código.

Mas valeu a pena.

Não é o fim

Espero que tenham gostado dessa jornada incrível comigo! Escrever software, especialmente software tão amplamente utilizado e complexo quanto o Elasticsearch e o Apache Lucene, é gratificante. No entanto, às vezes, é extremamente frustrante. Eu amo e odeio software. A correção de erros nunca termina!

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!