Resumo Técnico: PIXELRAG

Declaração do Problema

A Geração Aumentada por Recuperação (RAG) tornou-se o paradigma dominante para fundamentar Grandes Modelos de Linguagem (LLMs) em conhecimento externo, particularmente para questionamento de domínio aberto e agentes de busca aumentada. No entanto, os sistemas atuais dependem de uma etapa de pré-processamento crítica e frequentemente negligenciada: a análise de HTML para texto (HTML-to-text parsing).

Os pipelines existentes extraem texto limpo de páginas web brutas usando parsers (ex: Trafilatura, mwparserfromhell). Os autores argumentam que esse processo é inerentemente perdedor (lossy) e frágil:

1. Perda de Informação: Parsers descartam pistas visuais (ênfase, layout), conteúdo estruturado (tabelas, gráficos, infoboxes) e imagens.
2. Degradação Estrutural: A conversão de layouts 2D em sequências de tokens 1D achata agrupamentos espaciais e hierarquias, tornando difícil para os recuperadores distinguirem regiões que contêm respostas de textos circundantes.
3. Variabilidade do Parser: A escolha do parser impacta significativamente o desempenho downstream, com diferentes extratores descartando quantidades variadas de texto recuperável.

O artigo postula que, como a web é nativamente visual, o RAG deve operar diretamente no espaço de pixels, em vez de depender de abstrações de texto.

Metodologia: PIXELRAG

PIXELRAG é o primeiro sistema RAG de ponta a ponta que opera inteiramente no espaço de pixels em escala web. Ele ignora completamente o parsing de HTML, representando sites como capturas de tela renderizadas. O pipeline consiste em três etapas principais:

1. Coleta de Dados e Tiling (Fragmentação)

• Renderização Offline: Para escalar para milhões de páginas (ex: 7 milhões de artigos da Wikipedia), o sistema desacopla a coleta da renderização. Ativos (HTML, CSS, imagens) são primeiro armazenados localmente (ex: de arquivos Kiwix ZIM ou via crawling assíncrono).
• Renderização: As páginas são renderizadas offline usando Playwright (Chromium headless) em uma largura de viewport fixa (875px). Elementos não relacionados ao conteúdo (navegação, barras laterais) são removidos.
• Tiling: Capturas de tela de página inteira são fatiadas em tiles não sobrepostos (1024px de altura). Isso gera ~30 milhões de tiles para a Wikipedia e ~3,6 milhões para um corpus de notícias.

2. Construção do Índice

• Embedding Visual: O sistema utiliza uma abordagem de recuperação de vetor único para gerenciar a escala (30 milhões de tiles). Ele emprega um modelo de Qwen3-VL-Embedding (2B parâmetros) para codificar cada tile em um vetor de 2048 dimensões.
• Ajuste Fino Contrastivo (Contrastive Fine-Tuning): O modelo de embedding base é ajustado finamente no datastore de screenshots usando um pipeline de aprendizado contrastivo sintético:
  • Geração de Query Sintética: Um LLM gera perguntas em linguagem natural baseadas no conteúdo visual de um tile, garantindo que a resposta esteja totalmente visível.
  • Mineração Dinâmica de Hard-Negatives: O sistema recupera candidatos top-K para uma query, onde um LLM atua como juiz para filtrar "falsos negativos" (tiles que também respondem à query) e retém "hard negatives" (tiles topicamente relacionados, mas que não respondem).
  • Treinamento: O modelo é ajustado via LoRA tanto no backbone do LLM quanto no ViT (Vision Transformer) para melhorar a discriminação de detalhes visuais finos, como estruturas de tabelas.
• Indexação: Um índice FAISS IVF suporta busca de vizinho mais próximo aproximada, permitindo recuperação eficiente e atualizações incrementais.

3. Recuperação e Geração em Tempo de Execução (Runtime)

• Processamento de Query: Uma query do usuário é codificada usando o mesmo modelo de embedding visual.
• Recuperação: Tiles de screenshot top-K são recuperados com base na similaridade de cosseno.
• Geração: Os tiles recuperados são alimentados diretamente como inputs de pixels para um leitor de Modelo de Linguagem-Visual (VLM) (ex: Qwen3.5-4B), que gera a resposta sem qualquer conversão intermediária para texto.

Principais Contribuições

1. Primeiro RAG de Pixel em Escala Web: O PIXELRAG é o primeiro sistema a operar sobre um corpus completo da Wikipedia (7M artigos, 30M tiles) e corpora de notícias inteiramente no espaço de pixels, eliminando a etapa de parsing de HTML-para-texto.
2. Pipeline de Treinamento e Escala: Os autores desenvolveram um pipeline de renderização offline escalável e uma receita de treinamento contrastivo usando pares de QA sintéticos e mineração dinâmica de hard-negatives para adaptar modelos de embedding visual a screenshots da web.
3. Superioridade de Desempenho: O sistema demonstra que a recuperação no espaço de pixels supera consistentemente as baselines de RAG baseadas em texto em diversos benchmarks, incluindo tarefas centradas em texto (NQ, SimpleQA) e tarefas multimodais (MMSearch, LiveVQA).
4. Eficiência via Compressão: O artigo identifica a resolução da imagem como um novo alavancador de eficiência. Ao treinar o leitor VLM para tolerar resoluções mais baixas, o PIXELRAG alcança uma redução de até 3× no custo de tokens mantendo a precisão.

Resultados Experimentais

O artigo avalia o PIXELRAG contra baselines de "Sem Recuperação" e RAG baseado em texto (usando parsers Trafilatura e mwparserfromhell) em seis benchmarks:

• Tarefas Centradas em Texto (NQ, SimpleQA): Surpreendentemente, o PIXELRAG supera o RAG baseado em texto mesmo em tarefas onde as perguntas são respondíveis apenas via texto.
  • Em SimpleQA, o PIXELRAG (ajustado) atinge 78,8% de precisão contra 71,6% da melhor baseline de texto (Trafilatura).
  • Em NQ-Tables, a diferença é significativa (48,8% vs. 35,9%), atribuída à preservação das estruturas de tabelas que os parsers destroem.
• Tarefas Multimodais e Ruidosas:
  • LiveVQA (corpus de notícias ruidoso): O PIXELRAG melhora a precisão em 11,3% sobre as baselines de texto.
  • MMSearch e Encyclopedic VQA: O PIXELRAG mostra ganhos fortes, particularmente em recall de recuperação (ex: +5× em EVQA).
• Análise de Falhas: Os autores identificam três modos de falha para o RAG baseado em texto:
  1. Perda de Parser: Conteúdo estruturado (tabelas) é achatado ou perdido inteiramente.
  2. Perda de Ranking: Texto que contém a resposta existe, mas é classificado baixo devido ao "deslocamento de infobox" (infoboxes linearizados combinam com palavras-chave, mas carecem da resposta específica).
  3. Perda de Leitor: Listas/tabelas linearizadas confundem a capacidade do leitor de mapear linhas para cabeçalhos.
     O PIXELRAG mitiga isso preservando a estrutura visual 2D.
• Escalabilidade: O desempenho escala com a capacidade do VLM. Modelos com leitura de texto visual mais forte (ex: Qwen3-VL-4B e superiores) mostram um cruzamento onde a recuperação de pixels supera a de texto.
• Busca Agêntica: No benchmark de QA multi-salto MoNaCo, o PIXELRAG atinge o maior F1 score com o menor custo (2–4× mais barato que as baselines de texto) devido à maior densidade de informação por etapa de recuperação.

Significância e Alegações

O artigo afirma que o RAG web pode operar diretamente na forma visual nativa da web, desafiando a necessidade de representações de texto.

• Desempenho: Representações de pixels preservam pistas estruturais 2D críticas (tabelas, infoboxes, layout) que os parsers de texto inevitavelmente degradam, levando a uma melhor precisão de recuperação e geração.
• Eficiência: A compressão de imagem permite reduções significativas no custo de tokens sem sacrificar a precisão, oferecendo uma nova dimensão para otimizar sistemas RAG.
• Mudança de Paradigma: À medida que os VLMs continuam a melhorar na leitura de texto renderizado como pixels, a lacuna entre o RAG baseado em pixels e o baseado em texto deve aumentar, sugerindo um futuro de mudança para a recuperação visual nativa para a escala da web.

Os autores concluem que, embora o parsing de texto tenha sido uma etapa de pré-processamento necessária para os LLMs atuais, o avanço dos VLMs torna um pipeline nativo de pixels não apenas viável, mas superior tanto em desempenho quanto em eficiência.