A maioria dos pipelines RAG empresariais começam da mesma maneira: um analisador de texto converte páginas da internet e documentos em texto simples para que possam ser agrupados e indexados para recuperação. Essa etapa de conversão destrói os sinais de recuperação – e de acordo com uma nova pesquisa, é responsável pela maioria das respostas erradas.
Uma equipe de pesquisa da UC Berkeley, Universidade de Princeton, EPFL e Databricks publicou um artigo esta semana apresentando PixelRAG, um sistema que ignora totalmente essa conversão. Em vez de analisar as páginas em texto, o PixelRAG as renderiza como capturas de tela, indexa essas imagens e alimenta os blocos recuperados diretamente para um leitor de modelo de linguagem de visão. Testado em 30 milhões de blocos de captura de tela cobrindo toda a Wikipédia, ele supera o RAG baseado em texto em seis benchmarks, melhorando a precisão em até 18,1% em relação às linhas de base baseadas em texto.
Os analisadores são o lugar errado para procurar soluções, de acordo com a equipe de pesquisa.
“Melhorar os analisadores é um processo interminável porque cada website requer tratamento especial”, disse Yichuan Wang, autor principal e estudante de doutorado da UC Berkeley, ao VentureBeat. “Nosso objetivo period explorar se os avanços recentes nos VLMs tornam possível contornar todo esse problema e construir um sistema de recuperação que funcione em websites sem engenharia específica do website.”
Os analisadores HTML destroem os sinais de recuperação dos quais o RAG corporativo depende
O objetivo dos pesquisadores period desenvolver uma arquitetura limpa de ponta a ponta.
“Os pipelines RAG da internet modernos geralmente envolvem renderização, análise, limpeza, fragmentação e muitos outros estágios artesanais”, disse Wang. “Cada estágio introduz possíveis erros em cascata e abstrações que nos afastam ainda mais da página unique. Estávamos interessados em saber se poderíamos eliminar a maior parte dessa complexidade e operar diretamente na página renderizada.”
Wang também observou que a análise inevitavelmente perde informações. Imagens, hierarquia visible, tipografia, ênfase (por exemplo, texto em negrito), tabelas e format são descartados ou convertidos em aproximações textuais imperfeitas.
“Não importa quão bom seja um analisador, algumas informações são fundamentalmente perdidas durante a conversão”, disse ele.
A pesquisa identifica três maneiras pelas quais o RAG baseado em texto perde a resposta antes de chegar ao leitor. Todos os três foram medidos no SimpleQA, um benchmark padrão de 1.000 perguntas factuais da Wikipédia:
-
Perda do analisador (36,6% das falhas). A conversão de HTML em texto destrói o conteúdo estruturado tão completamente que nenhum pedaço de texto no corpus contém a resposta.
-
Perda de classificação (55,2% de falhas). A resposta existe no corpus, mas é superada por infoboxes densas em palavras-chave que chegam à classificação 1 em 75,9% das consultas, levando os parágrafos com respostas para a classificação 20 ou inferior.
-
Perda de leitor (8,2% de falhas). O conteúdo correto chega ao leitor, mas a estrutura achatada causa atribuição incorreta.
Como funciona o PixelRAG
Ao contrário de um LLM padrão que lê apenas texto, um modelo de linguagem de visão utiliza imagens como entrada junto com o texto, o que significa que pode ler uma página da internet renderizada da mesma forma que um ser humano, com format e estrutura intactos. “Para muitas tarefas estruturadas de extração de informações, acreditamos que os VLMs modernos têm uma vantagem inerente porque podem raciocinar conjuntamente sobre o conteúdo e o format, em vez de depender de uma representação de texto achatada”, disse Wang.
PixelRAG é construído em torno desse princípio, substituindo o pipeline de análise de texto por um sistema de quatro estágios que opera inteiramente em capturas de tela renderizadas.
-
Renderização. As páginas são renderizadas usando Playwright, uma biblioteca de automação de navegador, em uma janela de visualização fixa de 875 pixels e divididas em blocos de 1.024 pixels de altura. Os 7 milhões de artigos da Wikipedia produzem cerca de 30 milhões de blocos. Os ativos são armazenados em cache localmente e renderizados totalmente offline.
-
Indexação. Cada bloco é codificado como um único vetor de 2048 dimensões usando Qwen3-VL-Embedding-2B e armazenado em um índice FAISS aproximado do vizinho mais próximo. O índice completo atinge aproximadamente 120 GB no fp16 e oferece suporte a atualizações incrementais sem reindexação completa.
-
Treinamento. O modelo de recuperação é ajustado em dados contrastivos sintéticos gerados a partir do armazenamento de dados, usando mineração dinâmica de negativos fortes para filtrar falsos negativos. LoRA, um método leve de ajuste fino que atualiza uma pequena fração dos pesos do modelo, é aplicado tanto ao spine do modelo de linguagem quanto ao codificador visible. O treinamento em aproximadamente 40.000 pares é concluído em menos de três horas em um único H100.
-
Armazenar. Os blocos de captura de tela brutos para a Wikipedia exigem 5,6 TB, mas uma abordagem de renderização sob demanda elimina o armazenamento persistente: incorpore todos os blocos, exclua as capturas de tela e renderize novamente as páginas sob demanda no momento da consulta. O índice vetorial requer aproximadamente 120 GB.
Seis benchmarks, economia de 10x em tokens de agente e um problema não resolvido
Os pesquisadores testaram o PixelRAG em seis benchmarks que abrangem controle de qualidade factual da Wikipedia, consultas baseadas em tabelas, controle de qualidade multimodal e recuperação de notícias ao vivo. Eles disseram que ele superou o RAG baseado em texto em todos os seis, inclusive em tarefas em que as perguntas podem ser respondidas apenas com texto. No SimpleQA atinge 78,8% de precisão contra 71,6% para o analisador de texto mais forte, aumentando para 48,8% contra 42,5% em consultas de tabelas estruturadas. As equipes precisam de modelos da classe Qwen3-VL-4B ou superior para ver os benefícios. Modelos menores perdem na recuperação de texto em mais de 12,5 pontos percentuais.
A vantagem de custo do agente é o caso mais forte de curto prazo para o PixelRAG. Em testes de benchmark, um agente de IA usando PixelRAG como back-end de pesquisa executou 3,6 milhões de tokens de immediate contra 37,5 milhões para recuperação de texto, a um custo 2 a 4 vezes menor do que alternativas, incluindo o Google, ao mesmo tempo em que alcançou maior precisão. A compactação de imagens pode reduzir o orçamento de tokens em mais um terço.
A fragmentação visible é o principal problema não resolvido. Os sistemas RAG baseados em texto passaram anos refinando como dividir documentos em unidades de recuperação significativas com base em tópico, seção ou conteúdo semântico. Atualmente, o PixelRAG não tem equivalente: ele corta as páginas por altura fixa de pixel, o que significa que uma tabela ou parágrafo pode ser cortado ao meio, sem conhecimento dos limites do conteúdo.
“A comunidade de recuperação de texto passou anos estudando estratégias de agrupamento, enquanto a recuperação visible recebeu muito menos atenção”, disse Wang. “Achamos que esta é uma área importante para pesquisas futuras.”
Transformação VB · 14 a 15 de julho · Menlo Park · Camadas de contexto agente
Seus agentes são tão bons quanto os dados que podem alcançar.
As sessões no Remodel cobrem as arquiteturas RAG que alimentam os sistemas de agentes em escala – incluindo como as empresas estão conectando agentes a dados genômicos, clínicos e empresariais em tempo actual.
Veja a agenda completa →
O que isso significa para as empresas
O problema de qualidade de recuperação que o PixelRAG aborda reflete uma mudança mais ampla de mercado já em andamento. Os dados do VB Pulse Q1 2026 de empresas qualificadas entrevistadas descobriram que a intenção de adotar a recuperação híbrida triplicou de 10,3% em janeiro para 33,3% em março, a posição estratégica de crescimento mais rápido no conjunto de dados. Os próprios autores do PixelRAG apontam a implantação híbrida como o caminho mais prático no curto prazo – colocar a recuperação visible em camadas sobre os sistemas de texto existentes, em vez de substituí-los.
Para as equipes que já executam pipelines RAG, o caminho para essas economias é mais simples do que uma reconstrução completa.
“Um caminho prático é usar o PixelRAG como uma camada de aprimoramento junto com os sistemas de recuperação de texto existentes”, disse Wang. “A recuperação híbrida que combina pesquisa de texto e visible é direta e é provável que quantas implantações de produção evoluiriam.”
