OpenOCR agora detecta resultados vazios do Gemini 3.1 Flash-Lite e de qualquer motor subsequente
8 de outubro de 2026. O OpenOCR agora detecta quando um motor lê sua página e não retorna nada. Você recebe um erro claro informando o motivo, em vez de um resultado vazio que parece um sucesso. Você nunca paga mais do que o provedor cobrou pela tentativa e, em um PDF de várias páginas, todas as páginas lidas com sucesso são mantidas.
O padrão começou com o Gemini 3.1 Flash-Lite, mas a proteção se aplica a todos os motores no OpenOCR.
O que detectamos
Nosso monitoramento identificou um padrão no Gemini 3.1 Flash-Lite do Google, um dos motores mais usados no OpenOCR. Em uma pequena parcela de documentos reais (formulários, cartões e cartas com texto impresso nítido), ele não retornou nenhum texto, enquanto a API do Google reportava a requisição como bem-sucedida. Nos últimos 30 dias, isso ocorreu em cerca de 3% das páginas processadas pelo Flash-Lite e respondeu por quase todos os resultados vazios observados na plataforma: cerca de 97%.
Três por cento é fácil de passar despercebido em um pequeno número de requisições. Em escala documental, porém, significa que um fluxo de trabalho pode receber bastante texto de qualidade enquanto perde páginas legíveis. O sinal de sucesso do provedor fazia com que essas perdas parecessem tarefas concluídas.
Tentar novamente não adiantava muito. A mesma imagem voltava vazia de 80 a 93 por cento das vezes; portanto, repetir a requisição apenas custava tempo.
Para uma recusa com motivo declarado, o próximo passo é usar um motor diferente.
Como é a resposta agora
Antes dessa mudança, uma página legível podia gerar uma tarefa bem-sucedida sem nenhum texto extraído. Aqui está um exemplo reduzido mostrando os campos relevantes:
{
"status": "succeeded",
"extracted_text": ""
}
Agora, a recusa do provedor é explícita. Aqui está um exemplo reduzido no qual o Google nos faturou pela tentativa, de modo que a requisição carrega esse custo e nada além:
{
"status": "failed_charged",
"error_code": "provider_refused",
"cost_debited": 0.000327,
"provider_error": "Google declined to read this image (reason: SAFETY). Sending it to this engine again will give the same result; try a different engine."
}
A tarefa não alega mais que um texto de OCR utilizável foi entregue. A cobrança segue o valor real cobrado pelo provedor, conforme descrito a seguir.
Desenvolvido para todos os motores, não apenas um
O Gemini foi onde detectamos o problema, mas nada nessa falha é específico do Google. Qualquer modelo de visão computacional pode apresentar esse comportamento, e alguns outros motores o exibiram ocasionalmente. Assim, em vez de aplicar um ajuste em apenas um motor, mudamos a forma como o OpenOCR trata respostas vazias de qualquer motor:
Uma resposta clara em vez de uma em branco. Um resultado vazio é reportado como uma falha acompanhada de um entre dois códigos:
provider_refused: o provedor recusou a leitura e informou o motivo, como um filtro de segurança. O erro cita o motivo e avisa que reenviar a página para o mesmo motor gerará o mesmo resultado.provider_empty: o modelo não retornou nada e não informou motivo. O OpenOCR relê a página mais uma vez de forma automática antes de reportar a falha.
Os códigos permitem que sua aplicação diferencie uma recusa conhecida de uma resposta vazia sem explicação. O OpenOCR realiza a tentativa adicional para este último caso antes de retornar a falha.
Cobrança justa. Se o provedor nos cobrou pela tentativa, você paga exatamente esse valor, sem margem adicional e nunca acima do seu orçamento. Se ele não cobrou, você não paga nada. Exatamente como se chamasse o provedor de forma direta.
PDFs mantêm as páginas válidas. Se uma página de um PDF de 30 páginas retornar vazia, você ainda recebe as outras 29, e a página vazia é sinalizada com seu respectivo número. Um documento só falha se nenhuma página tiver retornado texto.
Pense em uma digitalização de 30 páginas enviada ao Flash-Lite. As páginas 1 a 11 retornam texto, a página 12 volta vazia e as páginas 13 a 30 retornam texto. O OpenOCR entrega as 29 páginas bem-sucedidas com um aviso indicando a página 12. Você pode enviar essa página para outro motor ou verificá-la manualmente. O valor cobrado nunca ultrapassa o orçamento prévio.
Todos os motores são monitorados. Agora rastreamos a taxa de resultados vazios de cada motor continuamente; assim, se outro modelo começar a apresentar esse comportamento, nós detectaremos em menos de uma hora.
O Gemini agora se explica
O Gemini 3.1 Flash-Lite agora é executado na API nativa do Google. O endpoint que utilizávamos anteriormente reportava essas recusas apenas como "other". A API nativa detalha por que a página foi recusada, e esse motivo agora chega até você na mensagem de erro.
Requisições travadas agora também são encerradas após 60 segundos em vez de três minutos, permitindo que você troque de motor mais rápido. A latência normal do Flash-Lite é de cerca de 3,6 segundos, e seu 99º percentil fica em torno de 12 segundos. Um tempo limite de 180 segundos prendia requisições travadas por muito mais tempo do que as métricas observadas; 60 segundos ainda oferecem margem suficiente além do intervalo habitual.
Como monitoramos isso agora
Acompanhamos a taxa de resultados vazios de cada motor a cada hora e alertamos a equipe quando ela atinge 5%. Uma taxa geral de sucesso pode se manter saudável enquanto um único modelo retorna respostas em branco. Esse sinal individualizado por motor nos mostra exatamente onde investigar.
Para desenvolvedores
Nada na sua integração quebra. Você simplesmente para de receber sucessos vazios. Se você reexecuta requisições com falha, verifique o código de erro: direcione uma página com provider_refused para um motor diferente em vez de repeti-la. Com dezenas de motores integrados a uma única chave de API e um único saldo no OpenOCR, isso exige apenas alterar uma única palavra no campo engine.
Em PDFs, preserve o aviso da página junto com o texto retornado para que você possa identificar a lacuna e decidir o que fazer com essa página.
Dúvidas frequentes
Minha integração vai quebrar? Não. Uma página sem nenhum texto extraído não se parece mais com um resultado de OCR bem-sucedido. Se o seu código faz novas tentativas para qualquer falha, use o error_code para evitar repetir uma requisição com provider_refused no mesmo motor.
Eu pago pelas páginas recusadas? Apenas caso o provedor tenha cobrado o OpenOCR pela tentativa. Você paga exatamente esse custo, sem margem adicional e nunca mais do que a estimativa. Se o provedor não nos cobrou, você não paga nada.
Por que não trocar de motor automaticamente? Você escolheu o modelo intencionalmente. Outro motor pode ter preço ou saída diferentes. Nós informamos o que aconteceu e deixamos a decisão com você.
Quais motores são afetados? Encontramos o padrão principalmente no Gemini 3.1 Flash-Lite, que representou cerca de 97% dos resultados vazios da plataforma nos últimos 30 dias. Alguns outros motores apresentaram isso ocasionalmente. A detecção e o relato agora cobrem todos os motores.
O que devo fazer com páginas separadoras em branco? Trate separadores conhecidos diretamente no fluxo do seu documento. Para folhas em branco ou o verso de digitalizações, use um motor de OCR dedicado a essas páginas. Também estamos testando quando modelos de visão inventam texto nelas.
Próximos passos: medindo texto inventado
Ao testar esta versão, fornecemos ao Gemini 3.1 Flash-Lite uma página em branco totalmente limpa. Ele não retornou vazio. Em todas as quatro tentativas, ele inventou texto: um parágrafo sobre negócios, uma demonstração matemática, uma carta de cliente e "THE END OF THE CHAPTER". Isso acontece em ambos os endpoints do Google, portanto trata-se do próprio modelo.
Um motor que inventa texto é mais difícil de identificar do que um que não retorna nada, pois a saída parece real. Estamos adicionando um teste de página em branco chamado HallucinationBench ao benchmark do OpenOCR: um teste público para verificar quais modelos de OCR enxergam texto em páginas em branco. Os resultados chegarão aos rankings do OpenOCR acompanhados por um ícone de fantasma, para que a taxa de texto inventado de cada motor possa ser mensurada e publicada ao lado da sua precisão. Até lá, se os seus documentos incluírem folhas em branco, como páginas separadoras ou o verso de digitalizações, use um motor de OCR dedicado para essas páginas.