Tour de Algoritmos

Coletamos sinais de busca de várias fontes: consultas do Search Console do cliente, sugestões de autocompletar, perguntas feitas a assistentes de IA e o que os concorrentes já cobrem. Cada ponto é uma consulta bruta — milhares delas, ruidosas e redundantes.

Consultas são transformadas em vetores com um modelo de linguagem. Frases diferentes com a mesma intenção (“apartamento em Botafogo”, “morar em Botafogo”, “Botafogo vale a pena?”) acabam próximas no espaço vetorial.

A proximidade é medida por similaridade de cosseno entre os vetores.

Um algoritmo de agrupamento junta as consultas em intenções. Cada grupo recebe um volume agregado, um nível de dificuldade e um tipo de intenção: informativa, comparativa, transacional.

Os grupos são cruzados com os dados que o cliente já tem. Um grupo de intenção com dados de suporte vira um candidato a tipo de página; um grupo sem dados vira uma lacuna a preencher — ou uma ideia descartada.

Imagine o tipo “Morar em [bairro]” para uma rede imobiliária. A matéria-prima é uma tabela: uma linha por bairro, uma coluna por fato — preço médio do m², número de imóveis, tempo até o centro, escolas, parques, estações.

Primeiro, classificamos cada coluna. Colunas-chave identificam a linha; colunas distintivas variam de verdade entre as linhas; colunas cosméticas mudam pouco ou nada. Só as distintivas sustentam uma página.

Depois, pontuamos cada linha: quantos fatos distintivos ela tem que diferem do valor mais comum da coluna? Uma linha com muitos valores próprios vira uma página rica; uma linha que só repete a moda viraria uma página rasa.

Linhas com fatos idênticos são agrupadas em uma única página, em vez de gerar cópias.

O resultado é um veredito em três níveis: construir todas, construir algumas (com a lista exata das que passam) ou construir só uma página-hub. É um filtro conservador por desenho — uma página a menos custa pouco; mil páginas finas podem custar o domínio inteiro.

Cada página aprovada recebe uma especificação: quais blocos devem vir diretamente dos dados da linha, qual parcela do texto precisa variar entre páginas (nossa meta é acima de 40%), quais blocos de enchimento são proibidos e qual o padrão de título e cabeçalho.

Um agente de pesquisa reúne os fatos da linha e as fontes externas permitidas. Um agente de redação monta o rascunho dentro da especificação. Um agente de verificação confere cada número contra a origem — um número sem fonte é marcado, nunca inventado.

Mas nem toda página é igual. Algumas são rotineiras; outras tocam em assuntos sensíveis, têm dados contraditórios ou pertencem a um cliente com voz editorial forte. Um classificador estima o risco de cada rascunho e decide se ele segue direto ou passa por um editor humano.

Editores também não são intercambiáveis. Atribuímos rascunhos a editores com um problema de otimização parecido com o de atribuir clientes a armazéns: um custo por par (editor, página) que combina especialidade, histórico com o cliente e o tamanho da fila de cada um — e que é recalculado várias vezes por dia.

O editor trabalha em uma interface construída para entender a página rapidamente: dados da linha de um lado, rascunho do outro, cada afirmação ligada à sua fonte. Testamos variações dessa interface o tempo todo; o que aprendemos sobre como editores decidem volta para melhorar os agentes.

Pegamos uma amostra de páginas prontas e substituímos o valor-chave de cada uma por um marcador. Se “Morar em Botafogo” e “Morar na Tijuca” ficam idênticas depois disso, a variação era só o nome — e isso é exatamente o que os mecanismos de busca penalizam.

Depois removemos as frases compartilhadas pela maioria das amostras. O que sobra é o texto realmente próprio de cada página. Medimos a parcela variável contra a meta de 40% e comparamos as páginas entre si por sequências de cinco palavras.

Cada página recebe um de cinco rótulos — ok, quase-duplicata, variação só pela chave, parcela variável baixa ou rasa — e uma ação: manter, fundir com outra, ou publicar com noindex até ganhar conteúdo. Nada disso depende de alguém ler mil páginas.

Primeiro, a hierarquia: um hub, categorias e as páginas folha, cada nível ligado ao de cima. Os sitemaps são divididos por tipo e por lote, dentro dos limites de arquivo do Google, para que possamos observar cada onda separadamente.

Um piloto pequeno vai ao ar — grande o bastante para ser estatisticamente legível, pequeno o bastante para não doer se der errado. A partir daí acompanhamos três contagens por lote: páginas publicadas, páginas indexadas, páginas indexadas sem nenhuma impressão.

Os critérios de parada são regras explícitas sobre essas razões. Se a taxa de indexação cai abaixo do limite, ou a parcela de páginas indexadas sem impressões sobe acima dele, a onda seguinte não abre. Cada causa tem sua própria ação de reversão: reforçar links internos, enriquecer dados, aplicar noindex ou fundir páginas.

Quando o lote passa, o próximo abre maior. O mesmo mecanismo que acelera um conjunto saudável freia um conjunto doente — e a decisão está registrada, lote a lote, para quem quiser auditar.

Uma vez no ar, cada página tem um estado: publicada, indexada, com impressões, com cliques, citada por uma IA. Registramos cada mudança de estado, junto com tudo o que aconteceu entre uma e outra — uma edição, um dado atualizado, um link novo.

Com milhares de páginas, as transições viram uma matriz. Ela nos diz, por exemplo, qual a probabilidade de uma página indexada passar a ser citada por um assistente de IA em 30 dias — e como essa probabilidade muda quando a página tem uma tabela de dados, uma resposta direta no topo ou uma fonte citada.

Esse é um modelo de cadeia de Markov simples, e ele é surpreendentemente útil: deixa-nos simular o conjunto inteiro meses à frente, comparar tipos de página entre si e identificar quais características de uma página mais movem a probabilidade de citação.

O que o modelo aprende volta para os agentes de redação como regras de especificação, para o classificador de risco como novas variáveis e para a viabilidade como pesos de coluna. O ciclo fecha — e a próxima onda já começa melhor que a anterior.

Páginas envelhecem em ritmos diferentes. Um guia de bairro muda devagar; uma página de imóveis à venda muda todo dia. Cada página tem um modelo simples de “frescor”: quanto seus dados mudaram, quanto tráfego ela recebe e há quanto tempo foi revalidada.

Esse modelo decide a ordem de regeneração. Em vez de reconstruir tudo a cada hora, regeneramos primeiro as páginas em que o ganho esperado é maior — e o mesmo sinal alimenta o orçamento de rastreamento que pedimos aos mecanismos de busca.

Olhando ainda mais longe, a demanda de busca é sazonal e previsível. Com séries históricas por intenção, antecipamos quais conjuntos de páginas precisam estar prontos — e revisados por pessoas — meses antes do pico, para que a capacidade editorial esteja onde o tráfego vai estar.

Em cada bairro, a carteira de imóveis funciona como um estoque: cada venda ou locação retira uma unidade, e a captação de novos imóveis a repõe. Sem reposição, as páginas de “imóveis à venda” esvaziam e os corretores ficam sem o que oferecer.

O difícil é o momento e o tamanho da captação. Captar demais deixa imóveis parados, anúncios envelhecendo e capital imobilizado; captar de menos deixa o bairro sem oferta. Queremos minimizar a soma do custo de captação e do custo de carregar estoque — este proporcional à área sob a curva.

Somando os dois custos, aparece um tamanho de lote que os equilibra. Captar em lotes maiores dilui o custo fixo de cada campanha, mas infla o estoque; lotes menores fazem o oposto. O mínimo da curva é o lote econômico.

Mexa nos controles ao final deste capítulo para ver o mínimo se deslocar.

A pergunta real é maior: quanto captar de cada tipo, em qual bairro, e quais anúncios antigos baixar para abrir espaço. Respondemos com um modelo da dinâmica do sistema, ajustado ao histórico e usado em otimização robusta, com incerteza quantificada nas previsões de demanda.

x = níveis de estoque por bairro · u = captação, realocação e baixa · w = previsão de demanda. Na prática olhamos cada tipo de imóvel em cada bairro; aqui ficamos no caso simples.

Os dados do cliente entram por conectores e viram tabelas versionadas: cada linha carrega a fonte e a data de origem. É essa linhagem que permite ao agente de verificação dizer “este número vem daqui” e ao editor confiar nele.

Em cima disso, uma camada de serviços internos: viabilidade, geração, controle de qualidade, lançamento e aprendizado são serviços independentes, cada um com sua fila e seus registros. As equipes de algoritmos escrevem a lógica; a plataforma cuida de escalar, repetir e observar.

Na ponta, as páginas são servidas estaticamente e regeneradas de forma incremental, página a página, na ordem que o modelo de frescor decide. Para o visitante — e para o rastreador — a página sempre existe e sempre responde rápido; a complexidade fica toda atrás dela.