Por que tiramos a busca, as tags e as recomendações da nuvem

A maioria das extensões de navegador ditas "com IA" envia tudo para um servidor — incluindo partes que nada têm a ver com inteligência artificial. Busca, limpeza de tags, "encontrar itens semelhantes": são técnicas consolidadas há décadas. Elas não precisam de um modelo de linguagem e definitivamente não precisam de uma requisição de rede. Analisamos o AI Summary Helper recurso por recurso e perguntamos: isso realmente precisa da nuvem ou estamos apenas recorrendo a ela por ser a arquitetura mais fácil?

A maioria não precisava.

O que realmente passou a rodar no dispositivo

Busca. Originalmente, a extensão só buscava correspondências no título do artigo e nas tags — rápido, mas cego a qualquer conteúdo no corpo do texto. Em vez de varrer todo o texto por força bruta a cada tecla digitada ou enviar cada consulta a um servidor, construímos um pequeno índice TF-IDF a partir do arquivo salvo do próprio usuário. Campos mais leves — título, tags — são verificados primeiro e instantaneamente, como antes. Consultas mais longas são ampliadas no índice, que é gerado uma vez por sessão e atualizado incrementalmente, sem nova varredura a cada tecla.

Detecção de duplicatas. Antes de concluir um salvamento, ocorre uma verificação em etapas: primeiro, correspondência exata de URL normalizada (baixo custo, O(1)); depois, similaridade de título nos poucos candidatos que passam por esse filtro; e só então — para os raros casos restantes — uma comparação completa de similaridade por cosseno via TF-IDF. A maioria dos salvamentos nunca chega à etapa mais pesada, pois as etapas anteriores já resolvem o caso.

Normalização de tags. As tags acumulam variações ao longo do tempo — "ML", "Machine Learning", "machine-learning" significam a mesma coisa para um humano, mas nada igual para um filtro. Uma pequena tabela de aliases cuida dos casos óbvios; uma mesclagem por distância de edição aproximada (fuzzy edit-distance) em todo o vocabulário de tags cuida do restante, adotando a grafia mais utilizada pelo usuário como padrão, em vez de impor uma forma "correta".

Legibilidade e tom. O índice de legibilidade Flesch–Kincaid é pura aritmética sobre contagem de frases e sílabas — nenhum modelo é necessário. A análise de sentimento usa uma lista de palavras AFINN embutida com uma verificação simples de negação nos dois tokens anteriores. Nenhum dos dois precisava sair do navegador.

"Artigos semelhantes" e Resumo. Ambos reutilizam exatamente os mesmos vetores TF-IDF já gerados para a busca. Teria sido fácil criar três sistemas de similaridade separados para três recursos distintos. Criar um único índice compartilhado entre busca, recomendações e curadoria do resumo manteve o sistema enxuto e garantiu que qualquer melhoria no índice aprimorasse todos os três recursos de uma só vez.

O que decidimos manter na nuvem

A etapa de sumarização em si — a parte que genuinamente exige um modelo de linguagem — ainda requer uma chamada de rede. Não há como contornar isso com o tamanho atual dos modelos locais se o objetivo for manter a qualidade de saída de um modelo de ponta em nuvem. Os usuários utilizam sua própria chave de API para essa etapa (OpenAI, Gemini, Mistral, DeepSeek) ou apontam a extensão para uma instância local do Ollama, eliminando a rede também nesse processo. Esse é o único ponto onde a execução local não é o padrão — é opcional, pois a contrapartida é real: um modelo local é mais lento e tem menor qualidade do que um modelo hospedado, e preferimos ser transparentes quanto a isso.

Por que isso vai além de um discurso sobre privacidade

A questão da privacidade é legítima — uma extensão com amplas permissões de acesso enviando conteúdo da página para um servidor para tarefas desnecessárias levanta dúvidas reais de confiança. Mas a razão mais prática para fazer isso é que costuma ser a decisão técnica correta. Uma busca TF-IDF não precisa de 200 ms de latência de rede. A deduplicação de tags não precisa gerar custos de API. Adequar a ferramenta à tarefa real, em vez de direcionar tudo para uma chamada na nuvem por padrão, tende a resultar em algo mais rápido, mais econômico e mais resiliente ao uso offline — com o benefício da privacidade vindo como consequência natural, e não o oposto.