Construindo do zero, em 2 meses, um mecanismo de busca na web com 300 milhões de embeddings neurais

• Em meio à queda na qualidade dos mecanismos de busca e ao avanço dos modelos de embedding baseados em Transformer, o autor relata a experiência de desenvolver, em 2 meses, um mecanismo de busca web baseado em 300 milhões de embeddings
• Com um total de 200 clusters de GPU, um crawler distribuído em larga escala, RocksDB, HNSW e outras infraestruturas e algoritmos de alto desempenho, foi implementada uma busca com compreensão de linguagem natural em tempo real
• Em vez de correspondência por palavras-chave, o objetivo é resposta a consultas centrada na intenção, aplicando várias técnicas de NLP/ML como normalização, chunking e encadeamento de sentenças para parsing de documentos e preservação de contexto
• O texto apresenta o projeto de sistemas distribuídos em larga escala em cada camada, como pipeline, armazenamento, service mesh e índice vetorial, além de estratégias de otimização de gargalos e custos
• Por fim, descreve o surgimento de um mecanismo de busca personalizado com latência ultrabaixa, grande escala distribuída e alta precisão

---

Visão geral e motivação

• Diante da percepção recente de piora na qualidade dos mecanismos de busca, spam de SEO e aumento de conteúdo irrelevante, e em um contexto em que os modelos de embedding baseados em Transformer passaram a compreender melhor a linguagem natural, o autor decidiu construir do zero um mecanismo de busca
• As limitações dos mecanismos de busca existentes decorrem da falta de capacidade de entender perguntas em nível humano e da simples correspondência baseada em palavras-chave
• O objetivo é um ranking centrado na intenção, que faça com que conteúdo de boa qualidade apareça sempre no topo e explore de forma equilibrada até a cauda longa
• O processo de construção de um mecanismo de busca web abrange várias áreas, como ciência da computação, linguística, ontologia, NLP, ML, sistemas distribuídos e engenharia de performance
• Este projeto é o desafio de começar sozinho, sem infraestrutura prévia nem experiência anterior, e implementar um mecanismo de busca totalmente novo em 2 meses

Arquitetura geral do sistema

• Foram gerados 300 milhões de embeddings de texto baseados em SBERT em 200 clusters de GPU
• Centenas de crawlers simultâneos coletaram 50.000 páginas por segundo, construindo ao todo um índice de 280 milhões de itens
• RocksDB e HNSW foram armazenados e indexados com sharding em 200 núcleos, 4 TB de RAM e 82 TB de SSD
• A latência total de resposta a consultas foi definida em cerca de 500 ms
• A arquitetura e o fluxo gerais foram divididos em crawler, pipeline, armazenamento, índice vetorial de embeddings, service mesh e áreas de front-end/back-end

Experimentos e melhorias em busca baseada em embeddings

Neural Embedding Playground

• Experimentos confirmaram que a busca com modelos de embedding como SBERT oferece entendimento de consulta mais natural e maior precisão do que a busca tradicional focada em palavras-chave
• Tornou-se possível captar a intenção da consulta em nível de contexto e frase, extraindo respostas realmente relevantes

Exemplo de busca tradicional vs. busca neural

• Busca tradicional: resultados aleatórios, focados em correspondência de palavras-chave
• Busca por embeddings: entende o contexto e a intenção da pergunta, fornecendo resultados centrados em frases-chave ou conceitos corretos
• Para combinações complexas de conceitos, perguntas implícitas/compostas e consultas com sinais de qualidade, torna-se possível buscar respostas com base em significado

Parsing e normalização de páginas web

• O objetivo da normalização é extrair do HTML apenas elementos de texto semanticamente relevantes, removendo ruído como layout e elementos de controle

• Seguindo padrões como WHATWG e MDN, preserva estruturas como p, table, pre, blockquote, ul, ol e dl

• Elementos de interface como menus, navegação, comentários e outros componentes de chrome são removidos por completo

• Regras especiais por site (por exemplo, en.wikipedia.org) são aplicadas para resolver problemas de extração excessiva ou insuficiente

• Dados estruturados baseados em significado (meta, OpenGraph, schema.org etc.) também podem ser usados para construir um grafo de conhecimento e melhorar o ranking

Chunking e preservação de contexto

Chunking em nível de sentença

• Para superar as limitações dos modelos de embedding, foi adotado chunking baseado em sentenças, em vez de usar a página inteira
• Durante o chunking, o spaCy sentencizer distingue com precisão vários casos, como fronteiras naturais de frases, gramática, abreviações, URLs e expressões informais

Preservação e conexão de contexto

• As relações de dependência entre sentenças, headings, parágrafos, tabelas etc. são identificadas, e essas informações de contexto são incorporadas junto com os embeddings
• Por exemplo, mesmo a estrutura de tabelas é inserida de forma encadeada com headings/cláusulas superiores para que o significado de cada linha não se perca

Encadeamento de sentenças (Statement Chaining)

• Com um classificador DistilBERT, uma frase e a frase anterior são analisadas em conjunto, automatizando a verificação de dependência contextual e a extração de cadeias
• No momento do embedding, todas as sentenças superiores dependentes são incluídas juntas para aumentar a preservação do contexto

Resultados do uso do protótipo

• Em um ambiente sandbox, experimentos com várias consultas reais confirmaram perguntas e respostas muito mais precisas (ajustadas ao contexto) em comparação com métodos anteriores
• Mesmo com divergência de palavras-chave, omissões/metáforas/perguntas compostas, o app reconhece a intenção e faz correspondência com as frases corretas no contexto, revelando de forma eficaz conhecimento e relações ocultas

Crawler web em larga escala (baseado em nós)

• Foram considerados diversos aspectos de estabilidade e eficiência, como work stealing para distribuição de trabalho, controle de concorrência/tráfego por domínio e validação de DNS/URL/headers
• O crawler aplica Promise com I/O assíncrono, mecanismos resistentes a DDoS, gerenciamento de recursos (memória, delay, backoff) e detecção de domínios ruidosos
• Também houve reforço da filtragem de URLs duplicadas/anormais por meio de normalização de URL, restrições de protocolo, porta e informações de usuário, além de canonicalization

Pipeline (fila de tarefas distribuída)

• O estado de cada página foi gerenciado no PostgreSQL; no início, foram usados polling e transações diretamente
• Em ambiente distribuído de grande escala (milhares de crawlers), surgiram problemas de escala e gargalos de filas/locks → o estado da fila passou a ser gerenciado por um coordenador em memória baseado em Rust
• Estrutura das tarefas: índice baseado em hash map, binary heap, grupos por domínio, polling aleatório, swap_remove e outras formas de indexação
• Cada tarefa usa cerca de 100 B de memória, permitindo processar até 1 bilhão de tarefas em um servidor com 128 GB
• Depois, foi desenvolvido um substituto open source do SQS, baseado em RocksDB, com suporte a 300 mil ops/seg em um único nó

Projeto de armazenamento (Oracle → PostgreSQL → RocksDB)

• No início foram usados Oracle Cloud (egress/armazenamento de baixo custo) e depois PostgreSQL (TOAST), mas o sistema encontrou limites de escalabilidade de escrita e performance
• Devido a características do PostgreSQL como MVCC, write amplification e WAL, houve gargalos em INSERTs paralelos em grande escala, levando à migração para o KV store RocksDB
• Com armazenamento separado de blobs no RocksDB (BlobDB), arquivos SST, multithreading e indexação por hash, foi possível aproveitar o desempenho máximo de SSDs NVMe
• Houve expansão para 64 shards de RocksDB — cada shard faz roteamento com base em xxHash(key) e usa serialização Serde + MessagePack
• No fim, milhares de clientes (crawlers/parsers/vectorizers) processavam 200 mil ops/seg, com armazenamento separado e comprimido de metadados e blobs

Service mesh e rede

• Para descoberta automática de instâncias de serviço e segurança na comunicação à medida que a infraestrutura crescia, foi adotado um projeto baseado em mTLS + HTTP2
• Cada nó recebeu certificados com base em uma root CA, usando serialização MessagePack diretamente, além de DNS interno, CoreDNS e um SDK de cliente customizado
• Embora houvesse experiência prévia com VPNs existentes (ZeroTier, Tailscale), por problemas de rede, performance e operação, a escolha final foi por HTTP + mTLS próprios
• O controle dos serviços do sistema (systemd + cgroup + journald) unificou a administração, trazendo leveza e padronização

Pipeline de geração de embeddings em GPU em larga escala

• Inicialmente foi usada a API da OpenAI, mas por questões de custo a operação migrou para ambientes de GPU de alto desempenho como Runpod
• O pipeline separa cada estágio de forma assíncrona, alcança mais de 90% de eficiência das GPUs e gera 100 mil embeddings por segundo em 250 GPUs
• Pipeline em Rust, inferência em Python → IPC por named pipe, com backpressure estruturado para ajuste automático de recursos

Indexação vetorial (HNSW/sharding)

• Foi usada a algoritmo HNSW para busca vetorial em memória, com ANN (Approximate Nearest Neighbor) para latência ultrabaixa
• Ao atingir o limite de RAM, aplicou-se sharding uniforme por nó (64 nós), e cada shard foi pesquisado em paralelo com seu próprio índice HNSW
• Como o HNSW exige muita RAM e tem limitações para atualizações em produção, houve migração posterior para o CoreNN, um vector DB open source baseado em disco
• O CoreNN permite consultas de alta precisão sobre 3 bilhões de embeddings mesmo em um único nó com 128 GB de RAM

UX do mecanismo de busca e otimização de latência

• Na UX de mecanismo de busca, a resposta imediata é o ponto central (sem indicador de carregamento, SSR tradicional)
• Com Cloudflare Argo e afins, o sistema se aproxima de edge PoPs e adota HTTP/3 para minimizar a latência de transmissão
• Todos os dados são preparados no nível do servidor da aplicação, minimizando round trips de API individuais e devolvendo imediatamente páginas minificadas e comprimidas

---

Este resumo mostra em detalhes como um mecanismo de busca web em larga escala, com as mais recentes tecnologias de processamento de linguagem natural e ML, pode ser construído end-to-end em apenas 2 meses, cobrindo de forma concreta os principais pontos de projeto e otimização em sistemas, algoritmos e infraestrutura.

[GN⁺]

Comentários do Hacker News

• É surpreendente que o modelo de embeddings mais recente da OpenAI ofereça um custo tão baixo de $0.0001 por 1 milhão de tokens em inferência em lote; fazendo embeddings de 1 bilhão de páginas com 1.000 tokens cada, o total sairia por apenas $100. Se eu rodasse a inferência por conta própria em GPUs spot da Runpod, ficaria 100 vezes mais caro. Deixando outros custos de API de lado, fico me perguntando se isso não é uma espécie de estratégia de honeypot da OpenAI para capturar dados-fonte especializados por domínio.

  • Pelo que sei, a OpenAI não costuma retreinar com dados processados pela maioria das APIs; salvo exceções muito específicas, entendo que isso não acontece.

• No fim do texto ele menciona a ideia de adicionar dados do Common Crawl. Acho que a informação de ranking baseada em web graph da nossa equipe poderia ajudar bastante a decidir quais páginas rastrear. Foi interessante ver um caso em larga escala tão concreto, e fiquei surpreso com o quanto um banco de dados vetorial pode ser custo-eficiente.

• Minha admiração é sincera. O texto também está incrivelmente bem organizado. Concordo que o coração de um buscador são dados limpos e filtrados (garbage in, garbage out). Isso reforça de novo que, no treinamento de LLMs, uma pequena quantidade de dados de alta qualidade acaba sendo mais importante. Fico curioso sobre como seria o desempenho de um buscador em que todo o conteúdo fosse avaliado por um LLM.

  • Atualmente estou cuidando pessoalmente do SEO do site de uma pequena empresa de um amigo. Fiz vários ajustes técnicos e também escrevi bastante conteúdo manual, adaptado à região. Depois de 2 meses, o Bing ainda nem conseguiu puxar o favicon; o Google também levou 1 mês. Mesmo assim, continuam aparecendo no topo sites nacionais de captura de leads sem nenhuma relação, spam de blog do Yelp e páginas de outras empresas sem qualquer vínculo com a região. Parece bem claro que há algo errado no pagerank e no sistema de crawling.

• Tenho um respeito enorme por isso. É impressionante juntar tantas tecnologias e fazer tudo funcionar como um sistema só. Acho que o valor decisivo de um buscador está no algoritmo de ranking em si. Não entendi muito bem como o LLM é usado no ranking neste projeto. Entre as técnicas antigas de ranking havia a coleta de dados reais de busca → clique dos usuários; isso é literalmente dado de treino humano de consulta de busca → link clicado. Mesmo com poucos cliques, o ranking melhora de forma perceptível. Se você jogar esses dados numa rede neural, dá para transformar isso em um problema de classificação e melhorar o ranking. Quanto mais pessoas clicam, maior o peso.

• Só dá para dizer que é realmente impressionante. Na prática, funciona muito bem. Se 10 mil pessoas assinassem por $5 por mês e isso cobrisse os custos, então um buscador financiado pela comunidade talvez não seja uma ideia tão absurda.

  • Para quem conhece encoder-only LLM, é claro que o Google já praticamente perdeu. O Google ainda se sustenta porque leva tempo para rastrear toda a web mundial e manter o índice sempre atualizado. Se uma organização aberta como o Common Crawl, ou mesmo um serviço pago, resolver o problema do crawling da web em tempo real, a muralha defensiva de 25 anos do Google desmorona, e a busca em si vai se comoditizar.

  • Indo além, estamos testemunhando em tempo real a substituição de praticamente todas as funções do grande enterprise IT, e os modelos agora reduzem drasticamente as barreiras tecnológicas das empresas.

• Nunca tinha imaginado que uma pessoa sozinha pudesse construir algo desse nível. Não parece estar tão distante assim de um buscador comercial. Talvez até esteja a uma distância alcançável do Google. Custar $50 mil por ano é absurdamente barato; dá vontade de mandar dinheiro semente agora mesmo.

• Projeto realmente muito legal. Testei aqui também uma pergunta que não costumava aparecer bem em buscadores famosos (opções recomendadas de monitor ultrawide de alta resolução), mas ainda existe a tendência de páginas meta grandes, especializadas apenas em ranking, aparecerem acima de páginas com informação realmente especializada. Parece haver uma obsessão excessiva com ranking. Se eu mesmo fosse buscar a resposta, selecionaria alguns fóruns de hardware e blogs para comparar com cuidado as especificações, vantagens e desvantagens. Como é difícil verificar se um site realmente fez esse tipo de análise, em casos específicos seria mais razoável valorizar mais sites que citam dados concretos. Como usuário, eu gostaria de ver os materiais-fonte usados na análise. Mas os buscadores reais não costumam elevar esse tipo de evidência de baixo para cima.

  • Talvez isso nem seja, em essência, um problema de busca (search query). Não é uma página única com uma “resposta definida” exata, e sim uma pergunta que exige combinação de várias fontes e “raciocínio”.

• Acho isso realmente incrível. Pensei em tentar substituir tudo por isso, e embora talvez seja um pouco perda de tempo, ainda assim vou fazer várias buscas e deixar minhas impressões. Em geral, ele me levou para lugares quase certos, mas não acertou 100%. Por exemplo, tentei encontrar o fediverse com lemmy e apareceu uma página do Liberapay. Espero muito que a promessa de integrar o Common Crawl seja cumprida, e que também consulte outros sites como archive.org. Bilhões estão sendo investidos no setor de IA, então eu realmente gostaria que experimentos assim dessem certo, nem que fosse com financiamento da comunidade ou compartilhamento de trabalho. Sinceramente, muita gente está cansada da situação quase monopolista dos buscadores atuais. Pelo que sei, a Ecosia também está preparando seu próprio buscador, e seria ótimo se colaborasse com este projeto ou recebesse ajuda dele. Eu realmente quero um buscador descentralizado. Entendo a hesitação em open source por motivos de sustentabilidade, mas é frustrante ver tanto dinheiro sendo desperdiçado sem muito sentido, e este projeto tem potencial enorme, então eu gostaria muito que fosse aberto. Acredito que a comunidade acabaria encontrando uma forma sustentável, talvez via crowdfunding. Ainda nem terminei de ler o post, mas fiquei tão empolgado que fui testar imediatamente. O texto em si é muito profundo, e acho que esse tipo de abordagem pode servir bastante de referência para outras pessoas. Sinceramente, parece mágica, e fazia muito tempo que eu não sentia esse nível de empolgação do começo ao fim com um projeto. Entendo que open source seja difícil, e também entendo o contexto de um país de terceiro mundo, mas eu realmente estaria disposto a doar nem que fosse $50 do meu próprio dinheiro. Eu, que nunca fiz um pagamento online sequer, me senti tão disposto a apoiar assim. Então espero muito que isso caminhe junto com a comunidade, usando o Common Crawl e afins. Torço sinceramente pelo projeto e pela carreira da pessoa.

• Foi uma das leituras mais perspicazes que tive recentemente. Gostei especialmente de como ele explicou em detalhes os elementos escolhidos para reduzir custos e onde de fato houve economia. Embora o foco tenha sido busca neural, queria saber se ele também tentou busca híbrida combinando BM-25 + embeddings. E também gostaria de perguntar quais modelos de reranking foram mais úteis e eficientes.

• Foi um relato realmente divertido. Eu também estou desenvolvendo algo parecido para busca de negócios e tenho enfrentado muitos desafios semelhantes. Muita gente acha que crawling/processamento/indexação será fácil, mas fazer isso em escala e com eficiência de custo é um problema completamente diferente. Meus aplausos para wilsonzlin; adoraria trocar ideias sobre isso. São pouquíssimas as pessoas que constroem algo assim ponta a ponta.