LLM local coletou anúncios pelo DOM e parou após a sexta requisição

Um scraper comum de sites de anúncios costuma quebrar antes mesmo da primeira linha útil: o servidor responde 403, limita a frequência de requisições ou entrega uma página montada por JavaScript. O autor do experimento tentou outro caminho: encarregou um Qwen local da classe 7B/8B de trabalhar com o site por meio de um navegador comum e extrair dados não por frágeis classes CSS, mas por indícios semânticos.

Em um exemplo simples, a tarefa era esta: encontrar uma estação de trabalho móvel rara com uma determinada placa de vídeo e coletar o nome, o preço, a cidade e o link do vendedor. O agente abria os resultados no Edge controlado pelo Playwright, examinava o DOM e procurava pontos de referência conhecidos: o símbolo da moeda, um texto grande ao lado e o identificador do anúncio no link. Se os dados do vendedor ficavam em outra parte da página, os registros eram vinculados pelo Item ID.

Por que o DOM se mostrou mais útil que o CSS

Uma interface moderna pode mudar os nomes das classes a cada atualização. Um seletor que funcionava ontem amanhã retorna uma lista vazia. Os indícios textuais são mais estáveis: o preço ainda contém o símbolo da moeda, o cartão leva a um endereço único e o título continua ao lado do preço na estrutura da página.

O agente usou esses indícios como referências. Primeiro encontrava o nó com o preço, depois subia até o contêiner do cartão, extraía o título e o link e, em seguida, cruzava os campos adicionais pelo identificador. Essa abordagem lembra o trabalho de uma pessoa: também não sabemos o nome da classe CSS de um botão, mas entendemos sua função pelo texto e pela posição.

Há também um resultado mais interessante. Em um anúncio, o título prometia uma placa de vídeo superior, enquanto a descrição indicava um modelo inferior com 16 GB de memória. O agente percebeu a divergência e marcou o cartão para revisão manual. Para uma equipe de produto, isso importa mais do que uma demonstração vistosa de autonomia: o modelo não apenas transferiu linhas, mas verificou a consistência dos dados dentro do anúncio.

Onde o experimento esbarrou na realidade

Na sexta requisição, a plataforma retornou um erro 429: excesso de requisições. O agente parou de fazer novas chamadas e gerou um relatório com os dados já salvos. É um comportamento sensato, mas ao mesmo tempo derruba a tese bombástica de uma «vitória» sobre o antifraude. Abrir um navegador comum não torna o sistema invulnerável: a plataforma continua vendo a frequência das ações e pode restringir o acesso.

A precisão de cem por cento na correspondência de dados declarada pelo autor também não foi confirmada por um teste independente. São desconhecidos o tamanho da amostra, o número de cartões perdidos e a taxa de erros em outras páginas. O experimento incluiu depuração interativa e observação manual, portanto é cedo para chamar o sistema de totalmente autônomo.

Há ainda um limite jurídico. A possibilidade técnica de ler uma página não significa permissão para coleta em massa de dados. Antes da execução, é preciso verificar os termos da plataforma, o robots.txt, a carga admissível e as regras de tratamento de dados pessoais. Os mecanismos de proteção não devem ser vistos como um incômodo a ser contornado às escondidas.

O que o desenvolvedor pode aproveitar

O valor do trabalho não está em uma receita para contornar bloqueios, mas em uma técnica de arquitetura. Em cenários permitidos, um agente de navegador pode combinar três camadas: verificação visual da captura de tela, análise do DOM por marcadores semânticos e um buffer local que permita encerrar corretamente o trabalho após um erro.

Em produção, são necessários limites rígidos de frequência, novas tentativas com atraso crescente, registro das ações, verificação da completude da amostra e confirmação manual de resultados duvidosos. O ideal é começar no próprio site ou em um ambiente de teste, onde haja permissão explícita para automação.

A conclusão prática é simples: um pequeno LLM local já é capaz de controlar um navegador e coletar dados estruturados de uma página dinâmica. Mas um bom agente se define não pela capacidade de superar a proteção a qualquer custo, e sim pela capacidade de respeitar limites, notar contradições e parar com segurança quando o site diz «chega».