Dados da Web e Web Scraping

Visão geral

“Dados da web” refere-se a informações publicadas na internet—páginas HTML, PDFs, imagens, postagens em fóruns, listagens de produtos, respostas de API, e mais. “Raspagem da web (web scraping)” é a extração automatizada dessas informações, tipicamente solicitando recursos da web e analisando seus conteúdos para convertê-los em dados estruturados (tabelas, documentos, conjuntos de dados).

Em IA e aprendizado de máquina (machine learning), dados da web são atrativos porque são:

  • Em grande escala (ordens de magnitude mais dados do que a maioria dos corpora internos)
  • Diversos (idiomas, domínios, estilos, modalidades)
  • Continuamente atualizados (úteis para atualidade e monitoramento de desvio)

Mas a coleta em escala web vem com restrições éticas, legais e operacionais não triviais. Este artigo foca em: ética, legalidade, robots.txt e considerações práticas de engenharia para construir ou usar conjuntos de dados derivados da web de forma responsável.

Este tema se conecta de perto com Privacidade, Governança de Dados, Documentação de Conjuntos de Dados (Datasheets), Segurança de Dados, Versionamento de Dados e Qualidade de Dados e Desvio.

Raspagem vs rastreamento vs APIs

Embora sejam usados como sinônimos, esses termos frequentemente implicam comportamentos diferentes:

  • Rastreamento (crawling): Descobrir URLs seguindo links (construindo uma “fronteira” de páginas).
  • Raspagem (scraping): Extrair campos/conteúdo específicos de páginas (preços, texto, metadados).
  • Coleta via APIs: Usar endpoints oficiais projetados para acesso programático.

Quando possível, prefira APIs oficiais. Elas normalmente oferecem:

  • Termos e limites de taxa claros
  • Esquemas mais estáveis do que HTML
  • Menor carga na infraestrutura do site
  • Melhor postura de conformidade

Se a raspagem for necessária, trate-a como uma integração de produção, não como um script pontual.

Fundamentos éticos: “pode” vs “deve”

Mesmo que algo seja tecnicamente acessível, a coleta ética considera dano, consentimento e externalidades.

Perguntas éticas-chave

  • Expectativas do usuário e consentimento: Os autores esperavam que seu conteúdo fosse coletado em massa e reaproveitado (por exemplo, para treinar Modelos de Linguagem Grandes)?
  • Colapso de contexto: Uma postagem escrita para uma pequena comunidade pode se tornar parte de um conjunto de dados global.
  • Privacidade e dados sensíveis: Conteúdo visível publicamente ainda pode conter PII (informações pessoalmente identificáveis) ou atributos sensíveis. Público ≠ não sensível.
  • Carga na infraestrutura: Raspagem agressiva pode degradar o serviço ou aumentar custos para operadores do site.
  • Uso indevido a jusante: Dados coletados podem viabilizar vigilância, doxxing ou manipulação direcionada.
  • Dano representacional e viés: Corpora da web frequentemente super-representam algumas demografias e pontos de vista enquanto sub-representam outros, impactando equidade e comportamento do modelo.

Prática ética não é apenas “evitar atividade ilegal”—inclui minimizar danos, ser transparente e implementar processos significativos de opt-out e exclusão.

Diretrizes éticas práticas

  • Minimização de dados: Colete apenas o que você precisa para o objetivo declarado de aprendizado de máquina.
  • Limitação de finalidade: Não reutilize silenciosamente um conjunto de dados para objetivos não relacionados sem reavaliar o risco.
  • Respeite normas da comunidade: Fóruns e comunidades de nicho frequentemente têm políticas explícitas de “proibido raspar”.
  • Crie um canal de opt-out: Forneça uma string clara de user-agent e uma página/e-mail para solicitações.
  • Limite de taxa e cache: Seja um “bom cidadão” da web.

Esses princípios se alinham a boas práticas em Documentação de Conjuntos de Dados (Datasheets) e Governança de Dados.

A raspagem da web fica na interseção de múltiplos regimes legais. As regras variam por jurisdição, e a jurisprudência evolui. Trate o que segue como orientação conceitual e consulte assessoria jurídica em implantações reais.

“Categorias” legais comuns que afetam a raspagem

  1. Direitos autorais

    • Muitas páginas da web contêm texto, imagens e layout protegidos por direitos autorais.
    • Copiar conteúdo para um conjunto de dados (especialmente em escala) pode implicar direitos de reprodução.
    • Alguns usos podem se qualificar como exceções (por exemplo, fair use nos EUA), mas isso é específico ao contexto e incerto—especialmente para treinamento comercial de aprendizado de máquina e redistribuição.

  2. Termos de Serviço (ToS) / contrato

    • Sites frequentemente proíbem acesso automatizado ou reutilização nos Termos de Serviço.
    • Violar os Termos de Serviço pode gerar reivindicações contratuais (mesmo que o conteúdo seja publicamente acessível).
    • A exigibilidade dos Termos de Serviço pode depender de como o aceite é formado (clickwrap vs browsewrap).

  3. Acesso a computadores / leis anti-hacking

    • Em algumas jurisdições, acessar um sistema “sem autorização” ou contornar barreiras técnicas pode ser ilegal.
    • Raspar atrás de logins, contornar paywalls ou evitar bloqueios pode aumentar o risco.

  4. Privacidade e proteção de dados

    • Se você coleta dados pessoais (nomes, e-mails, IDs, rastros de localização etc.), leis como GDPR/UK GDPR, CCPA/CPRA e outras podem se aplicar.
    • Requisitos podem incluir base legal, transparência, minimização de dados, limites de retenção, segurança e direitos de exclusão.
    • Isso se sobrepõe fortemente a Privacidade e Segurança de Dados.

  5. Direitos sobre bases de dados (notadamente na UE)

    • Algumas jurisdições reconhecem direitos especiais sobre bases de dados, afetando extração/reutilização de partes substanciais.

  6. Licenciamento

    • Alguns sites publicam conteúdo sob licenças explícitas (por exemplo, Creative Commons).
    • Licenças podem impor obrigações (atribuição, compartilhamento pela mesma licença, restrições de uso não comercial).
  • Prefira fontes licenciadas ou claramente permitidas (por exemplo, texto CC-BY, portais de dados abertos).
  • Mantenha proveniência no nível da fonte e licenças em metadados (veja Versionamento de Dados e Documentação de Conjuntos de Dados (Datasheets)).
  • Evite contornar controles de acesso e evite raspar áreas autenticadas/privadas, a menos que explicitamente permitido.
  • Implemente fluxos de exclusão e remoção (takedown).
  • Considere se você precisa armazenar conteúdo bruto ou se pode armazenar características/embeddings derivados (ainda potencialmente dados pessoais dependendo da reversibilidade).

robots.txt e controles relacionados a robots

O que é `robots.txt`?

robots.txt faz parte do Protocolo de Exclusão de Robôs (Robots Exclusion Protocol): uma convenção que permite que sites especifiquem regras de acesso para rastreadores. Ele normalmente é hospedado em:

https://example.com/robots.txt

Ele inclui diretivas como:

  • User-agent: a qual rastreador a regra se aplica
  • Disallow: prefixos de caminho que não devem ser buscados
  • Allow: exceções sob um prefixo desautorizado
  • Crawl-delay: atraso solicitado entre requisições (não é universalmente respeitado)
  • Sitemap: ponteiros para sitemaps

Exemplo:

User-agent: *
Disallow: /account/
Disallow: /checkout/
Allow: /blog/

Sitemap: https://example.com/sitemap.xml

O que robots.txt é (e não é)

  • Ele não é um mecanismo de segurança e não oculta conteúdo.
  • Ele não é universalmente vinculante do ponto de vista legal por si só, mas pode influenciar interpretações legais/éticas.
  • Ele é um forte sinal da intenção do operador e deve ser respeitado como parte de uma raspagem responsável.

Outros sinais do site além de robots.txt

Coletores responsáveis também consideram:

  • <meta name="robots" content="noindex,nofollow">: diretivas para mecanismos de busca (nem sempre destinadas a raspadores, mas indicam intenção relevante).
  • Cabeçalhos HTTP como X-Robots-Tag
  • Cabeçalhos de limite de taxa (comuns em APIs)
  • CAPTCHAs / proteções anti-bot: em geral sinalizam “não automatize”, e tentar contornar aumenta o risco.
  • Políticas dedicadas para crawlers de IA: alguns sites publicam orientação explícita para uso em treinamento de modelos.

Tratamento prático de robots.txt

Em escala, você deve:

  • Buscar e armazenar em cache o robots.txt por host, respeitando seus cabeçalhos de cache ou usando um TTL razoável.
  • Aplicar regras de robots a toda URL antes de agendá-la.
  • Usar um User-Agent claro identificando seu rastreador e informações de contato.

Construindo um raspador educado: considerações de engenharia

Etiqueta de requisições e gestão de carga

Práticas-chave:

  • Limitação de taxa: taxa de requisições por host e limites de concorrência.
  • Backoff exponencial em 429 Too Many Requests, 503 Service Unavailable, timeouts.
  • Respeitar cabeçalhos Retry-After quando presentes.
  • Cache e requisições condicionais:
    • Use ETag e If-None-Match
    • Use Last-Modified e If-Modified-Since
  • Evitar horário de pico se você puder agendar.

Um exemplo mínimo em Python ilustrando busca “educada”:

import time
import random
import requests

SESSION = requests.Session()
UA = "MyResearchCrawler/1.0 (+contact: crawler@example.org)"

def fetch(url, timeout=20):
    # Jitter helps avoid thundering herds in distributed crawlers
    time.sleep(1.0 + random.random())

    for attempt in range(6):
        r = SESSION.get(url, headers={"User-Agent": UA}, timeout=timeout)
        if r.status_code == 200:
            return r.text
        if r.status_code in (429, 503):
            retry_after = r.headers.get("Retry-After")
            if retry_after:
                sleep_s = int(retry_after)
            else:
                sleep_s = min(60, 2 ** attempt)
            time.sleep(sleep_s)
            continue
        r.raise_for_status()

    raise RuntimeError(f"Failed to fetch after retries: {url}")

Em produção, integre verificação de robots, filas por host e armazenamento persistente.

Normalização e canonicalização de URLs

O mesmo conteúdo pode aparecer sob múltiplas URLs devido a:

  • Parâmetros de consulta de rastreamento (utm_source=...)
  • IDs de sessão
  • http vs https, www vs domínio raiz
  • Barras finais, páginas index padrão

A canonicalização reduz duplicatas e tráfego desperdiçado:

  • Remova parâmetros de rastreamento conhecidos
  • Normalize capitalização de esquema/host
  • Siga <link rel="canonical" href="..."> (com cuidado; pode estar errado)

O tratamento de duplicatas se conecta a Qualidade de Dados e Desvio e higiene do conjunto de dados.

Páginas dinâmicas e renderização em JavaScript

Muitos sites renderizam conteúdo no lado do cliente. Opções:

  • Procure JSON subjacente em chamadas de rede (geralmente mais fácil e menos frágil do que renderizar).
  • Use navegadores headless (Playwright/Selenium) quando necessário, mas observe:
    • Maior custo computacional
    • Maior risco de acionar sistemas anti-bot
    • Postura de privacidade/segurança mais complicada

Prefira HTML renderizado no servidor ou APIs documentadas quando viável.

Extração e parsing de conteúdo

HTML é bagunçado. Abordagens práticas de extração:

  • Seletores CSS/XPath para páginas estruturadas
  • Remoção de boilerplate para corpora de texto (menus, rodapés, banners de cookies)
  • Extratores DOM-para-texto (por exemplo, algoritmos estilo readability)

Tenha cuidado com:

  • Scripts embutidos que parecem texto
  • Elementos ocultos
  • Texto de navegação repetido que polui corpora

Para corpora de treinamento de aprendizado de máquina (por exemplo, modelagem de linguagem), você frequentemente precisa de:

  • Identificação de idioma
  • Filtragem de spam/toxicidade
  • Deduplicação e clusterização de quase-duplicatas
  • Detecção de fronteiras de documento

Considerações multimodais

Ao coletar imagens/áudio/vídeo, surgem problemas adicionais:

  • Maior sensibilidade a direitos autorais e complexidade de licenciamento
  • Faces/biometria embutidas (risco de privacidade)
  • Metadados EXIF podem conter coordenadas GPS ou IDs de dispositivo

Veja também Conjuntos de Dados Multimodais e Privacidade.

Considerações de segurança para ingestão em escala web

Trate conteúdo da web como entrada não confiável:

  • Armazene HTML bruto de forma a evitar execução acidental em dashboards internos (risco de XSS).
  • Varra downloads por malware (especialmente PDFs, documentos de escritório).
  • Isole (sandbox) pipelines de renderização/processamento.
  • Controle acesso aos dados brutos (princípio do menor privilégio) e registre acessos.

Isso se alinha com Segurança de Dados.

Gestão de conjuntos de dados para dados derivados da web

Proveniência e rastreabilidade

No mínimo, armazene:

  • URL de origem
  • Timestamp de coleta
  • Status HTTP, cabeçalhos (quando permitido)
  • Hash do conteúdo
  • Versão do parser e método de extração
  • Notas de licença/ToS (se conhecidas)
  • Status de robots no momento da coleta (se você se basear nisso)

Isso viabiliza auditorias, reprodutibilidade e remoções, e se encaixa bem com Versionamento de Dados.

Documentação: datasheets para conjuntos de dados da web

Um conjunto de dados derivado da web deve ter um datasheet abordando:

  • Metodologia de coleta (estratégia de rastreamento, seeds, filtragem)
  • Período de tempo e política de atualização
  • Regras de inclusão/exclusão (robots, idiomas, domínios)
  • Vieses e lacunas conhecidos
  • Tratamento de privacidade (remoção de PII, retenção)
  • Usos pretendidos e usos proibidos

Veja Documentação de Conjuntos de Dados (Datasheets).

Retenção, exclusão e “direito ao esquecimento”

Operacionalmente, você precisa de mecanismos para:

  • Remover URLs/domínios específicos sob solicitação
  • Propagar exclusões para artefatos derivados (índices, embeddings, shards de treinamento)
  • Rastrear quais versões de modelo treinaram com quais dados (linhagem)

Isso é parte governança, parte engenharia: Governança de Dados, Versionamento de Dados e Privacidade.

Alternativas práticas à raspagem direta

Raspar não é o único caminho para dados em escala web.

Arquivos públicos da web e conjuntos de dados

Projetos como Common Crawl fornecem grandes instantâneos da web. Benefícios:

  • Menor carga em sites individuais (o rastreamento é centralizado)
  • Mais fácil reproduzir experimentos

Custos/riscos:

  • Ainda inclui conteúdo protegido por direitos autorais e dados pessoais
  • Você herda as políticas de rastreamento e o viés de cobertura de outra entidade
  • Exige filtragem pesada e deduplicação

Parcerias e licenciamento de dados

Para sistemas comerciais de aprendizado de máquina, licenciamento pode ser a opção mais robusta:

  • Direitos claros para treinamento e redistribuição
  • Maior estabilidade e suporte dos dados
  • Menor incerteza legal

Dados sintéticos como complemento

Quando a raspagem é arriscada ou insuficiente, Dados Sintéticos podem complementar o treinamento—embora introduzam seus próprios problemas (mudança de distribuição, artefatos, vazamento).

Modos de falha comuns (e como evitá-los)

  • Ignorar robots.txt: leva a dano reputacional e bloqueios; implemente verificação de robots centralmente.
  • Sobrecarregar servidores: “funciona em dev” vira um DDoS em produção; imponha cotas por host.
  • Raspar dados privados sem intenção: por exemplo, perfis de usuário indexados por páginas internas de busca; aplique allowlists estritas de URL e varredura de PII.
  • Contaminação do conjunto de dados: boilerplate de navegação, spam, páginas duplicadas; invista em extração e filtragem.
  • Sem proveniência: não consegue cumprir remoções ou auditar; armazene URL+timestamp+hash+metadados.
  • Assumir que “público” implica “seguro”: trate dados da web como potencialmente pessoais e sensíveis.

Juntando tudo: um pipeline responsável de dados da web (conceitual)

Um pipeline típico em escala web se parece com:

  1. Seleção de fontes e política

    • Allowlist/denylist de domínios
    • Revisão de licença/ToS
    • Plano de conformidade com robots

  2. Rastreamento

    • Fronteira de URLs, filas por host
    • busca/cache de robots
    • limitação de taxa, backoff, tentativas

  3. Captura bruta

    • Armazenar respostas brutas com segurança (controle de acesso)
    • Computar hashes de conteúdo

  4. Extração e normalização

    • Remoção de boilerplate, parsing estruturado
    • ID de idioma, normalização de codificação

  5. Filtragem

    • Deduplicação, remoção de spam
    • Detecção/anonimização (redaction) de PII (quando apropriado)

  6. Versionamento e documentação

    • Snapshots do conjunto de dados com linhagem
    • Datasheet descrevendo coleta e limitações

  7. Uso a jusante

  8. Operações de conformidade

    • Solicitações de takedown, remoções de domínios
    • Aplicação de retenção e auditoria

Isso é essencialmente uma extensão focada em aprendizado de máquina de Pipelines de Dados (ETL/ELT para ML), com restrições legais/éticas adicionais.

Resumo

Dados da web podem ser transformadores para sistemas de IA, mas raspar a web não é apenas uma tarefa técnica—é uma atividade sociotécnica e legal. Prática responsável requer:

  • Respeitar robots.txt e sinais do site
  • Gerenciar privacidade e dados sensíveis de forma intencional
  • Implementar rastreamento educado (limites de taxa, backoff, cache)
  • Manter proveniência, versionamento e documentação
  • Construir processos operacionais para remoções (takedowns) e governança

Quando bem feitos, conjuntos de dados derivados da web podem ser úteis, reprodutíveis e defensáveis—apoiando melhores resultados de aprendizado de máquina enquanto reduzem danos e risco de conformidade.