Resumo Técnico: Tornando a Falha Segura: Um Framework de Agente Constrito e Verificável para Coleta de Dados da Web Aberta

1. Definição do Problema

O artigo aborda a falta de confiabilidade no uso de Grandes Modelos de Linguagem (LLMs) e agentes para a coleta direta de dados da web aberta. Embora os LLMs possam gerar código de raspagem (scraping) a partir de linguagem natural, a aplicação direta sofre de fragilidade estrutural devido à heterogeneidade das páginas web e à inconsistência estocástica da geração de código por LLM. Os modos comuns de falha incluem erros de dependência, seletores quebrados, incompatibilidades de esquema e formatos de saída inconsistentes. Pipelines tradicionais dependem de esforço manual, enquanto abordagens de agentes sem restrições carecem de verificabilidade, dificultando a auditoria, medição ou correção de falhas em um ambiente de produção.

O desafio central é mudar de um "raciocínio de agente perfeito" para um "pipeline de coleta verificável", onde cada estágio de entrada e saída pode ser checado, medido e auditado.

2. Metodologia

Os autores propõem um framework de agente constrito e verificável que substitui a geração de código livre por a geração de configurações de coletores em JSON tipado. O sistema opera em um ciclo fechado de "gerar–executar–checar–corrigir", desacoplando o papel do LLM (compreensão de requisitos e geração de configuração) do motor de execução (DAGs estáticos do Airflow).

2.1 Taxonomia de Seis Tipos de Coletores

Para impor limites estruturais, o framework define uma taxonomia de seis tipos de coletores, cada um com limites funcionais explícitos e regras de composição:

1. Busca (Search): Descobre URLs candidatas via palavras-chave (sem extração de conteúdo).
2. Lista (List): Percorre listas paginadas para encontrar links de detalhes (sem extração profunda de conteúdo).
3. Detalhe (Detail): Extrai campos estruturados de uma única página.
4. API: Chama APIs públicas e mapeia campos de resposta (sem interação de navegador).
5. Interativo (Interactive): Executa cliques e entradas em páginas dinâmicas (sem contornar autenticação/CAPTCHA).
6. Arquivo (File): Baixa e analisa arquivos públicos (PDF, Excel).

2.2 Framework de Agente Constrito

O framework consiste em cinco módulos operando sob quatro categorias de restrições:

1. Agente de Compreensão de Requisitos: Converte descrições em linguagem natural ($d$) em uma representação completa da tarefa ($R$) ao sondar proativamente o site alvo (página inicial, sitemap, páginas de amostra) para extrair o contexto da fonte ($x$).
2. Agente de Instanciação de Coletor: Gera configurações JSON ($M$) usando uma abordagem de "codificação de referência + preenchimento de slots de template". Em vez de escrever código, o agente preenche slots em templates pré-construídos, restritos por:
   • Restrições de tipo de tarefa: Garantindo que o tipo correto de coletor seja selecionado.
   • Restrições de estrutura de configuração: Impondo conformidade com o JSON Schema.
   • Restrições de reuso de ferramentas: Reutilizando funções utilitárias pré-construídas em vez de gerar novo código.
3. Validação e Execução em Escala via Airflow: Um DAG estático do Airflow executa as configurações JSON. Execuções de validação utilizam parâmetros de pequena amostra para deslocar erros para um estágio de pré-produção de baixo custo, enquanto execuções em escala utilizam parâmetros de produção. Isso garante que zero tokens de LLM sejam consumidos durante a execução.
4. Módulo de Verificação de Qualidade: Um avaliador determinístico baseado em regras (sem LLM) pontua os resultados em cinco dimensões: Estrutura, Conteúdo, Relevância, Anexo e Execução. Ele produz uma pontuação composta ($S$) e um relatório de erro.
5. Módulo de Correção de Feedback: Converte relatórios de qualidade em restrições de feedback estruturadas (ex: listas negras de falhas, hipóteses proibidas). O agente de instanciação regenera a configuração sob essas novas restrições, formando um ciclo fechado.

3. Principais Contribuições

1. Taxonomia de Seis Tipos de Coletores: Um sistema de classificação formal com limites explícitos e regras de composição para padronizar tarefas de coleta.
2. Framework de Agente Constrito: Um sistema que desloca a saída do LLM de código livre para configurações JSON tipadas sob uma hierarquia de quatro níveis de restrições aninhadas (tipo $\to$ template $\to$ utilitário $\to$ validação).
3. Ciclo Fechado Verificável: Um mecanismo de "gerar–executar–checar–corrigir" usando portões de qualidade baseados em regras e correção de feedback estruturado, permitindo sinais de falha auditáveis.
4. Validação Experimental Multinível: Testes abrangentes cobrindo classificação de requisitos, instanciação de coletores, trade-offs de qualidade-custo contra baselines de LLM em tempo de execução e compatibilidade com Airflow.

4. Resultados Experimentais

O framework foi avaliado em um conjunto de dados de 138 tarefas de coleta (80 verificadas pela fonte).

• Classificação de Requisitos: O sistema alcançou um Macro-F1 de 0,7793 na classificação de tipos de coletores a partir de descrições, superando uma baseline de palavras-chave baseada em regras (0,7562). No entanto, os autores observam que descrições sozinhas são insuficientes para tarefas ambíguas (ex: "detalhe" vs. "lista"), necessitando de sondagem proativa.
• Instanciação de Coletor: O framework constrito alcançou uma pontuação de qualidade média de 0,5369 e uma taxa de passagem de 55,07%, superando significativamente a geração de LLM não constrita (0,4876 de qualidade, 18,84% de correspondência de tipo) e as baselines baseadas em regras.
• Trade-off Qualidade-Custo (80 Tarefas Verificadas pela Fonte):
  • Baselines de LLM em Tempo de Execução (ex: LLM com restrição de esquema, Crawl4AI): Alcançaram maior qualidade de tentativa única (0,7051 e 0,6996) e taxas de passagem (81,25% e 80,00%), mas incorreram em altos custos (3.400–4.200 tokens por execução) e tempos de execução (wall-clock time) mais longos (14–16s).
  • Framework Proposto: Alcançou menor qualidade de tentativa única (0,5631) e taxa de passagem (50,00%), mas utilizou zero tokens de LLM na fase de execução e alcançou o menor tempo de execução (5,052s).
• Correção de Feedback: Quando aplicado a configurações intencionalmente falhas, a correção de feedback melhorou a qualidade média final de 0,5087 para 0,9007 e a taxa de passagem de 0,72% para 100%, demonstrando a eficácia do mecanismo de reparo para tipos de defeitos conhecidos.
• Verificação de Engenharia: Todas as 138 configurações geradas foram fundamentadas em templates compartilhados (taxa de reuso de 100%) e executadas com sucesso no Airflow 2.8.0.

5. Significância e Alegações

O artigo posiciona o framework não como um substituto geral para a extração de LLM em tempo de execução, mas como um caminho de execução reutilizável, de baixo custo e verificável adequado para coleta de dados repetitiva e agendada.

• Filosofia de "Tornar a Falha Segura": Os autores argumentam que uma falha controlada e explícita (via restrições de tipo, validação de esquema e portões baseados em regras) é preferível ao sucesso silencioso e não controlado. As falhas tornam-se sinais auditáveis e rastreáveis em vez de corrupção silenciosa de dados.
• Reconhecimento de Trade-off: O artigo admite modestamente que, embora as baselines de LLM em tempo de execução ofereçam qualidade de tentativa única superior, o framework proposto oferece um modelo de custo determinístico e amortizado. Ao deslocar os custos de LLM para uma etapa de geração de configuração única, o framework torna-se economicamente viável para tarefas de coleta de alta frequência e agendadas, onde a velocidade de execução e o custo de tokens são críticos.
• Limitações: Os autores declaram explicitamente limitações, incluindo o uso de requisitos construídos em vez de solicitações brutas de usuários, a falta de testes de significância de longo prazo e a sensibilidade do sistema a páginas interativas complexas e fronteiras de autenticação. O framework é projetado para cenários de dados públicos e de conformidade.