Quão difícil é criar um mecanismo de busca realmente bom? — Index: Um sistema de recuperação dinâmica de documentos em nível de milissegundos, projetado especificamente para agentes de IA. Esta apresentação técnica completa, feita por Abhi, fundador do @opennote, foca-se no Index, o sistema de busca desenvolvido internamente pela empresa. Este sistema não é um mecanismo de busca baseado em intervenção humana; em vez disso, foi projetado para que agentes de IA realizem uma recuperação extremamente rápida e precisa dentro das bases de conhecimento pessoais dos usuários. Por que os sistemas de busca existentes não conseguem atender às necessidades de agentes inteligentes? Os mecanismos de busca tradicionais são projetados para humanos. Os humanos aprendem gradualmente a entender as peculiaridades do sistema, aprendendo a substituir ou complementar palavras e a ignorar falhas. Os agentes inteligentes, no entanto, carecem completamente dessa capacidade. Cada consulta começa do zero; eles não têm memória nem "sensibilidade" para a base de conhecimento. E o que é ainda mais grave: • Agentes inteligentes são altamente suscetíveis a alucinações; se o contexto estiver ligeiramente errado, toda a resposta pode ruir. • O Opennote normalmente lida com apenas alguns milhares (e não centenas de milhões) de documentos, com tolerância praticamente zero para erros, exigindo que o segmento mais correto seja encontrado na primeira tentativa. • Como o produto se destina a consumidores comuns, não pode esperar alguns segundos como uma ferramenta de pesquisa; a latência de ponta a ponta deve ser estável em algumas centenas de milissegundos. Os autores enfatizam repetidamente que um índice deve atender simultaneamente aos seguintes requisitos quase contraditórios: 1. Latência extremamente baixa: P99 < 300ms (mesma velocidade em qualquer lugar do mundo) 2. Alta precisão: Quando o mesmo conceito aparece em documentos diferentes, também é necessário encontrar aquele com o contexto mais preciso. 3. Multilocação e escopo dinâmico: Suporta buscas simultâneas de qualquer combinação de "somente eu", "compartilhado com amigos", "comunidade inteira" e "mais páginas públicas" sem perda de desempenho. 4. Baixa latência global: Usuários e agentes podem estar em lados opostos da Terra. 5. Os dados nunca são estáticos: os usuários podem editar, compartilhar, excluir e alterar permissões a qualquer momento. Seleção de tecnologias-chave (muitas das quais são contraintuitivas) 1. O mecanismo de armazenamento e busca principal escolhido é o Postgres (pgvector + pg_trgm + tsvector), hospedado no PlanetScale, em vez de bancos de dados vetoriais dedicados convencionais, como Pinecone, Weaviate, Qdrant e Chroma. O motivo é: • Filtragem de metadados extremamente rápida, minimizando o conjunto de candidatos antes dos cálculos vetoriais. • Suporte nativo para recuperação híbrida verdadeira (texto completo + correspondência aproximada + semântica). • Limites multi-inquilinos, filtragem dinâmica e UPSERT/DELETE são inerentemente eficientes. • Testes em situações reais mostram que a latência P99 foi reduzida de 475 ms para 209 ms. 2. Toda a arquitetura de tempo de execução distribuída global é executada no ecossistema Cloudflare: Workers + Hyperdrive + R2 + Workers AI + Vectorize + KV. A vantagem é que o código é executado naturalmente em dezenas de nós de borda ao redor do mundo e, ao acessar o banco de dados, a velocidade é a mesma de um acesso local, graças à aceleração proporcionada pelo Hyperdrive. 3. Fluxo de processamento de documentos (Ingestão) Adota um design de armazenamento de objetos Worker + R2 completamente sem estado, adaptando-se estritamente ao limite de memória de 128 MB do Worker. O processo é o seguinte: 1. Decomposição recursiva em blocos (robusta o suficiente para todos os tipos de documentos complexos) 2. Utilize o hash para comparar com precisão os blocos antigos e novos, recalculando apenas as partes que foram realmente alteradas. 3. Reincorpore apenas os trechos alterados (economiza tempo e dinheiro) 4. Gere resumos para documentos e parágrafos importantes, fornecendo ao agente contexto adicional sobre "sobre o que trata o documento como um todo". 5. UPSERT Novo Bloco 6. Exclua o bloco antigo e acione a invalidação do cache. 4. Processo de Busca 1. Ao receber uma consulta do agente, primeiro execute a limpeza de parâmetros e a concatenação de condições de filtro. 2. No Postgres, utilize metadados para pré-minimizar o espaço de busca (tenant, source, tag, time, exclusão explícita, etc.). 3. Execute a pesquisa de texto completo e a pesquisa vetorial em paralelo no conjunto de dados filtrado. 4. Normalize os dois conjuntos de pontuações para 0-1 e funda-os dinamicamente usando um parâmetro chamado alfa (0 = palavras-chave puras, 1 = semântica pura). 5. Realizar a desduplicação, a classificação e a recuperação dos K principais elementos dentro do banco de dados. 6. Opcionalmente, use o Workers AI para realizar uma reordenação leve e, finalmente, retornar o resultado. 5. Sistema de cache (a parte mais engenhosa) Os caches regulares ficam sujos após atualizações de documentos; o autor projetou um mecanismo de três camadas para resolver completamente esse problema: • Cache preciso: A mesma consulta + as mesmas condições de filtragem atingem diretamente o par chave-valor. • Cache semântico: Use o Vectorize para armazenar representações vetoriais de consultas, garantindo que consultas semelhantes possam ser armazenadas em cache. • Invalidação de índice invertido: Cada bloco registra em quais consultas ele aparece no cache; se um bloco se tornar inválido, todos os caches relacionados são excluídos proativamente. Isso reduz significativamente a pressão sobre o banco de dados e garante que conteúdo desatualizado nunca seja retornado. Os resultados reais dos testes foram rigorosamente comparados com o ChromaDB usando o conjunto de dados padrão MSMARCO (10.000 pares de perguntas e respostas) + modelo BGE-M3. Em termos de quatro métricas — Recall@10, MRR@10, MAP@10 e NDCG@10 — o Index apresenta desempenho semelhante ou ligeiramente superior ao do Chroma. Ele também possui recursos adicionais, como recuperação híbrida, isolamento multi-inquilino e filtragem dinâmica. Em um ambiente de produção real, a latência P99 se mantém estável em até 300 ms. O Index agora é oficialmente responsável por toda a carga de busca dos recursos da comunidade Opennote. O autor acredita que o índice atual é meramente uma ferramenta de "recuperação" e que o próximo passo é transformá-lo em uma ferramenta de "compreensão". • Adicionar relações temporais, causais e evolutivas entre os blocos de dados. • Introduzir sinais de importância/popularidade. • Continuar aprimorando modelos de incorporação menores, mais rápidos e mais especializados. • Permitir que os agentes personalizem estratégias de recuperação em várias etapas. O objetivo final é permitir que agentes inteligentes realmente possuam um "modelo mental" da base de conhecimento do usuário, em vez de adivinhar às cegas, partindo do zero, todas as vezes.
