Substituindo OCR por um Vision Language Model

• Este cookbook é um projeto open source que explora algoritmos de processamento de vídeo e imagem por meio de diversos estudos de caso e práticas
• Abrange várias áreas de aplicação, como inferência em vídeo, catálogo de imagens e busca híbrida de imagens de moda
• Em comparação com outros projetos, tem a vantagem de permitir aprender os algoritmos por meio de diversos casos reais
• Principais arquivos e notebooks
  • 00_quickstart.ipynb: guia para início rápido do projeto
  • 01_schema_showcase.ipynb: inclui estudos de caso que mostram vários esquemas de dados
  • 02_case_study_drivers_license.ipynb: reconhecimento de carteira de motorista
  • 03_case_study_tv_news.ipynb: compreensão de telas de telejornal
  • 04_visual_grounding.ipynb: exploração de algoritmos de visual grounding. Extração de JSON dentro de caixas na imagem
  • 05_case_study_image_catalogue.ipynb: análise de catálogo de produtos de moda para reconhecer descrição do produto, categoria, gênero-alvo e estação
  • 06_fashion_images_hybrid_search.ipynb: estudo de caso de busca híbrida de imagens de moda
  • advanced_finetuning_video_inference.ipynb: técnicas avançadas de fine-tuning para inferência em vídeo

[GN⁺]

Comentários no Hacker News

• Ideia interessante, mas ainda não é confiável o suficiente para uso em produção. Modelos tradicionais de OCR, quando não conseguem ler o texto, costumam gerar resultados sem sentido com baixa confiança. Já um VLM, quando não consegue ler, gera um resultado inventado com confiança, e não há uma forma de reportar essa confiança. Em tentativas de reconhecer escrita cursiva, o VLM inventou nomes e datas falsas que combinavam com o clima do documento. Não há como fundamentar o modelo no texto de origem

• Recentemente foi publicado um benchmark open source para avaliar VLM e OCR, e, em geral, os VLMs apresentaram desempenho melhor do que os modelos tradicionais de OCR

• Vantagens do VLM:

  • Reconhecimento de escrita cursiva. A compreensão de contexto ajuda. Ou seja, ele interpreta a palavra/frase inteira, em vez de caractere por caractere
  • Gráficos/infográficos. Um VLM pode interpretar um gráfico ou fluxograma em formato de texto. Inclui até linhas codificadas por cor

• Vantagens do OCR tradicional:

  • Documentos padronizados (por exemplo, formulários de imposto dos EUA)
  • Texto denso. Pense em livros didáticos e artigos acadêmicos com múltiplas colunas. Esse é o caso de uso mais fácil para OCR, mas VLMs sofrem à medida que o número de tokens de saída aumenta
  • Caixas delimitadoras. Ainda não existe um modelo que forneça caixas delimitadoras com altíssima precisão. Gemini e Qwen foram treinados para isso, mas não têm desempenho tão bom quanto os modelos tradicionais

• Ainda há muito espaço para melhoria, mas modelos como Gemini, em especial, são muito competitivos em termos de precisão/custo

• Fico me perguntando por que todo serviço de OCR mostra apenas screenshots perfeitas de documentos digitais. Será que tem tanta gente assim tentando fazer OCR em dados digitais? Não seria só copiar o HTML? Se não forem documentos digitais, onde estão as screenshots com dobras, linhas tortas, gradientes de iluminação, dedos etc.?

• Experimentei vlm-run e definições personalizadas de formulários, e funcionou surpreendentemente bem com Gemini 2.0 Flash. Pelo que entendo, o custo também é baixo. Dá para obter os melhores resultados em formulários simples a moderadamente complexos. São formulários que um humano conseguiria processar com menos de 10 minutos de treinamento

• Ferramentas de OCR fazem muito bem o que está escrito na caixa: reconhecer caracteres no papel. A vantagem de usar modelos de visão-linguagem é poder adicionar lógica como: "isto é uma string, mas parece um timestamp?"

• O que eu quero: escanear/fotografar um documento (incluindo livros inteiros), enviar para um modelo de linguagem e receber um documento Latex que corresponda exatamente ao original. Desconsiderando defeitos da copiadora/câmera e ângulo. Parece que daria para fazer um modelo com aprendizado por reforço para isso. Ele deveria conseguir aprender a gerar Latex que reproduza a imagem em nível de pixel

• Deve-se usar os dois. Se você usar OCR e LLM e depois correlacionar os dois resultados, a qualidade melhora bastante. Você consegue tanto compreensão do documento e contexto quanto caixas delimitadoras etc. Estou criando um app de "nunca mais preencher papelada" e gostaria de conversar com pessoas interessadas

• Pode ser por causa do meu prompt, mas parece haver interpretação demais depois do embedding da imagem. No meu exemplo, ele começou a resumir partes do texto e, infelizmente, resumiu errado. Em uma fatura com texto digitado, o original dizia que, se enviada depois de sexta às 14h, ela não seria lançada até a segunda-feira seguinte, mas ele resumiu como se não fosse lançada por 2–3 dias úteis. Isso é bem diferente. Fico pensando se existe alguma forma de remover essa camada. A detecção e reconhecimento estruturado de texto em one-shot foi muito melhor que OCR básico

• É bom ver que mais trabalho está sendo feito nisso, mas não consigo entender por que isso fica preso à API proprietária de alguém. Trocar de provedor de modelo e adicionar logging básico não deveria ser tão doloroso quanto integrar mais um fornecedor. Especialmente ao lidar com algo sensível como prompts de LLM

• Qual é a ferramenta de OCR via CLI mais rápida e precisa? Meu caso de uso é simples: quero capturar parte da tela (Flameshot é ótimo para isso) e fazer OCR. Preciso disso para anotar coisas durante pair programming no Zoom. Atualmente uso tesseract, e ele é rápido e funciona bem, mas comete erros. Seria ótimo se conseguisse distinguir formato tabular e converter para tabela ASCII ou Markdown. Tentei docling, mas pareceu um pouco exagerado. Também parece lento — preciso extrair texto de screenshots muito rapidamente. Só testei a configuração padrão, então talvez melhore com ajustes. Alguém pode compartilhar opiniões sobre isso? Obrigado!