Pular camadas de visão funciona, até que você peça para ler texto

Pergunte a um modelo de visão-linguagem para contar os carros em uma foto de estacionamento, e ele executará a mesma quantidade de computação que quando você pede para transcrever um recibo borrado. Mesmo codificador, mesmo número de camadas, mesmos milissegundos e dólares gastos, seja a tarefa "quantos" ou "o que isso diz". Isso deveria incomodá-lo um pouco, porque essas são obviamente tarefas diferentes. Contar carros precisa de um layout espacial aproximado. Ler um recibo precisa de detalhes finos em caracteres minúsculos. Ninguém projetou esses modelos para tratar ambas as tarefas de forma idêntica. É apenas o que acontece quando você constrói um codificador de visão único e o executa em tudo.

Um novo artigo de Tarun Tomar faz uma pergunta direta: se um modelo de visão-linguagem já funciona, você pode torná-lo mais barato pulando parte de seu processamento de visão interno, sem treinar novamente? E, se sim, ajuda pular partes diferentes dependendo se a pergunta é sobre texto, contagem, objetos, cores ou relações espaciais? A resposta é sim e também, de uma maneira importante, não. O artigo encontra ganhos reais e transferíveis da poda inteligente e então descobre que sua ideia mais tentadora (personalizar o atalho por tarefa) colapsa exatamente no caso que os leitores do OpenOCR mais se importam: ler texto.

Passaporte 8 — por Ken_Mayer via flickr, BY 2.0.

O que realmente está dentro dos "olhos" de um modelo de visão-linguagem

Um modelo de visão-linguagem (VLM) recebe uma imagem e um prompt de texto e produz uma resposta em texto. Antes que qualquer raciocínio linguístico ocorra, a imagem passa por um codificador de visão: uma pilha de blocos transformer, cada um refinando um pouco mais a representação visual. O Bloco 1 pode identificar bordas e texturas. O Bloco 12 pode representar algo mais próximo de "este é o total do recibo na região inferior direita". Quando a imagem chega ao modelo de linguagem, ela já passou por todos os blocos da pilha, em ordem, independentemente da pergunta feita.

Esse é o cenário que este artigo questiona. A ideia é pular completamente um número fixo de blocos, chamemos de K, durante a inferência. Sem ajuste fino, sem retreinamento, apenas decidindo "não vamos executar os blocos 4, 9, 15 e 21 desta vez" e observando o impacto na precisão. Se a precisão cair pouco enquanto o custo computacional diminuir significativamente, você encontrou eficiência gratuita. Faça isso em uma família de modelos e você pode ter encontrado algo que generalize.

A primeira tentativa óbvia é classificar os blocos pela importância que parecem ter individualmente (remova um, meça o prejuízo, repita para cada bloco) e depois exclua os K blocos que parecem menos importantes isoladamente. O artigo chama isso de classificação independente, e é a linha de base natural que qualquer um adotaria primeiro. Outro instinto natural é simplesmente remover um conjunto contíguo de blocos, na teoria de que as camadas intermediárias são redundantes. Ambas as abordagens são baratas computacionalmente. Ambas, como se mostra, deixam precisão real para trás.

Criando melhores rotas em vez de apenas classificar blocos

O problema com a classificação independente é o mesmo que você encontraria ao avaliar jogadores de basquete individualmente e depois escolher seu "melhor quinteto" sem nunca verificar se eles jogam bem juntos. Os blocos interagem. Remover o bloco 9 pode ser inofensivo se o bloco 10 ainda estiver lá para cobrir por ele, mas prejudicial uma vez que o bloco 15 também estiver ausente. A importância não é aditiva, então pontuar blocos isoladamente e combinar as melhores escolhas perde interações que só aparecem quando você testa combinações diretamente.

É aí que entra o método principal do artigo: uma busca evolutiva sobre qual conjunto específico de K blocos pular. Em vez de pontuar blocos individualmente, ele testa combinações inteiras (rotas inteiras através do codificador de visão) diretamente contra um conjunto retido de 876 exemplos e evolui para combinações melhores. Comece com uma população de rotas candidatas, mantenha as que pontuam bem, mutas e recombine-as, repita. É a mesma lógica que os criadores usam para melhorar uma cultura: você não decide antecipadamente qual gene único é mais importante, você seleciona com base em resultados do mundo real e deixa que as boas combinações sobrevivam.

Um detalhe importa aqui: a busca é "balanceada por fonte", o que significa que o conjunto retido contra o qual ela é avaliada mistura deliberadamente diferentes tipos de tarefas (OCR, contagem, reconhecimento de objetos, atributos, relacionamentos espaciais) em proporções balanceadas, em vez de permitir que uma categoria domine. Isso visa impedir que a busca encontre uma rota que seja ótima, digamos, em contagem e medíocre em tudo o mais apenas porque os exemplos de contagem acabaram sendo super-representados.

O artigo testa isso em dois modelos, Qwen2.5-VL-3B-Instruct e SmolVLM2-2.2B-Instruct, ambos VLMs abertos de tamanho médio, e compara com classificação independente, remoção contígua e seleção aleatória de blocos em orçamentos correspondentes (mesmo número de blocos pulados, escolha diferente de quais).

O resultado que deve levar as pessoas a repensar a poda ingênua

O número principal: no SmolVLM2, a rota compartilhada de quatro blocos encontrada pela busca evolutiva (um conjunto fixo de quatro blocos para pular, usado para cada pergunta, independentemente da tarefa) supera a construção de classificação independente por 4,91 pontos percentuais. Essa é uma diferença significativa para uma mudança que não custa nada no momento da inferência, além de decidir quais quatro blocos deixar de fora. E como esse padrão aparece em ambas as arquiteturas testadas, é um sinal razoável de que a busca combinatória (verificando rotas inteiras juntas, em vez de pontuar blocos um por um) é uma maneira genuinamente melhor de construir esses atalhos do que a abordagem óbvia inicial.

Se o artigo parasse por aí, a conclusão seria simples: buscar boas combinações de blocos supera classificá-los individualmente, e isso vale a pena saber se você está tentando reduzir o custo de inferência em um VLM sem retreiná-lo.

Onde a ideia de especialização seduz, e depois falha

A próxima pergunta que o artigo faz é mais ambiciosa: e se você não usar uma única rota fixa para todas as perguntas, mas sim escolher uma rota diferente de K blocos dependendo do tipo de pergunta? Se você souber (ou puder adivinhar) que uma pergunta é sobre OCR versus contagem versus raciocínio espacial, talvez os blocos ideais para pular sejam diferentes para cada um. Isso requer um rótulo de capacidade, algum sinal que indique ao sistema em qual categoria de tarefa a pergunta atual se enquadra.

No Qwen2.5-VL, isso parece valer a pena, à primeira vista. A política específica de capacidade de seis blocos supera a rota compartilhada e única por 2,17 pontos no geral, e quase todo o ganho vem de uma única categoria: uma melhoria de 7,10 pontos especificamente no OCR. Esse é um resultado real, e se se mantivesse em todos os lugares, seria genuinamente útil: usar uma rota genérica por padrão, alternar para uma rota especializada em OCR quando souber que está lendo texto e obter um aumento significativo de precisão gratuitamente.

Exceto que não se mantém. Quando o artigo verifica a rota específica de OCR do SmolVLM2 contra o IIIT5K, um benchmark padrão de texto em cena (fotos de texto no mundo real: fachadas de lojas, placas de estrada, rótulos de produtos), essa rota especializada fica 13,6 pontos atrás da rota compartilhada simples. Não é um erro de arredondamento. Um atalho especializado que parecia uma vitória no conjunto de retenção da própria busca acabou prejudicando ativamente o desempenho em um teste de OCR separado e selado.

Por que isso acontece é a parte importante. A rota específica de capacidade foi otimizada contra um pool limitado de exemplos rotulados como OCR do conjunto de seleção. Ela aprendeu a pular blocos que por acaso eram irrelevantes para aquela fatia particular de exemplos de leitura de texto, não blocos que são irrelevantes para a leitura de texto em geral. O texto em cena do IIIT5K (placas curvas, fontes estranhas, fundos poluídos) aparentemente precisa de algum do processamento visual exato que a rota especializada decidiu descartar. A rota sofreu overfitting para uma definição estreita de "OCR" em vez de encontrar algo que generalize para o que o OCR realmente parece no mundo real.

Por que isso importa para quem está construindo ou escolhendo OCR

Se você está construindo um pipeline de processamento de documentos ou avaliando em qual motor de OCR ou backbone de VLM confiar, este artigo é uma advertência útil sobre um tipo específico de truque de eficiência, e não um motivo para desconfiar do OCR baseado em VLM em geral.

A boa notícia: a omissão de blocos por meio de uma busca combinatória adequada, e não por poda ad hoc, é uma maneira legítima de reduzir o custo de inferência em um modelo de visão-linguagem sem precisar treiná-lo novamente, e os ganhos foram transferidos entre duas famílias de modelos diferentes neste estudo. Se um fornecedor lhe disser que encontrou um caminho de inferência mais barato por meio de uma busca cuidadosa, em vez de adivinhação, isso é plausível e merece ser levado a sério.

O problema: sempre que um provedor lhe disser que construiu um caminho rápido "especializado para tarefas" ou "otimizado para OCR" através de um modelo compartilhado, pergunte contra o que ele foi validado. Este artigo mostra que uma rota especializada para OCR pode parecer excelente no benchmark exato usado para construí-la, mas perder mais de 13 pontos em um teste padrão de OCR diferente. Essa lacuna é exatamente o tipo de coisa que seria invisível se você verificasse apenas os números relatados pelo próprio fornecedor. Se você está escolhendo entre motores de OCR, a jogada prática é a mesma implicada por este artigo: teste em seus próprios documentos, especialmente os do mundo real e desordenados (recibos, placas, manuscritos, digitalizações de baixo contraste), e não apenas no benchmark contra o qual a otimização do fornecedor foi ajustada.

Para quem está construindo, em vez de comprando: este é um forte argumento para manter uma única rota compartilhada e bem testada como padrão e tratar qualquer caminho rápido específico para uma tarefa como um complemento experimental que precisa de sua própria validação em um conjunto de teste genuinamente diferente antes de ser lançado, e não apenas uma pontuação mais alta no conjunto que você usou para encontrá-lo.

O que ainda é incerto aqui

Este é um estudo de pequena escala e com modelos pequenos, e deve ser lido dessa forma. Ambos os modelos testados são relativamente compactos (3B e 2,2B de parâmetros), portanto, é uma questão em aberto se a mesma lacuna entre rotas compartilhadas e especializadas aparece em VLMs de produção maiores. Apenas duas arquiteturas foram testadas, o que é suficiente para mostrar que o padrão não é um acaso isolado, mas não o suficiente para chamá-lo de universal.

Há também uma complicação prática que o artigo não resolve totalmente: usar uma rota específica de capacidade exige conhecer o rótulo da capacidade no momento da inferência, o que significa que algo (um classificador, uma dica fornecida pelo usuário, um modelo roteador) precisa marcar corretamente cada pergunta recebida como OCR, contagem, espacial ou outra, antes de escolher uma rota. Errar essa classificação não significa apenas perder o benefício da especialização; você pode estar ativamente roteando uma pergunta de OCR por uma rota otimizada para contagem.

A limitação mais importante, no entanto, é aquela sobre a qual o artigo é honesto em sua própria formulação: a busca combinatória melhora consistentemente como você constrói uma rota, mas os rótulos de capacidade não definem consistentemente uma rota que generalize. Essa é uma afirmação mais estreita e mais útil do que "o poda específica de tarefa funciona", e é aquela que vale a pena lembrar da próxima vez que alguém apresentar um modelo que foi especialmente otimizado para leitura de texto. Pergunte o que ele faz com textos que não se parecem com os textos nos quais foi otimizado.