OCR nos bastidores: como os computadores aprendem a ler texto de imagens

Abra qualquer imagem em um editor hexadecimal. Uma foto de uma placa de rua, um recibo, uma captura de tela de um PDF. No offset zero você encontra o cabeçalho do formato. Alguns kilobytes depois, você chega aos dados dos pixels: três bytes por pixel em RGB, uma grade de números onde (128, 52, 19) pode ser uma parede de tijolos e (240, 238, 220) pode ser papel. Em algum lugar dessa grade está uma placa de pare com a palavra "STOP" renderizada em Highway Gothic branco sobre fundo vermelho. Um humano vê quatro letras. O computador vê uma região de 47 × 19 pixels com valores próximos ao vermelho, onde o canal R gira em torno de 200 e G e B caem abaixo de 40. Mapear essa região para a string "STOP" é reconhecimento óptico de caracteres, e tem sido um problema de pesquisa em aberto desde que Gustav Tauschek patenteou a primeira máquina de leitura em 1929.

OCR é enganosamente difícil porque ler é enganosamente fácil. Uma criança de seis anos reconhece a letra A em uma dúzia de fontes, em tamanhos variados, sob iluminação irregular, levemente girada, parcialmente ocluída e escrita a lápis. Um computador precisa de uma pipeline: limpar a imagem, encontrar as regiões de texto, segmentar os caracteres ou sequências de glifos e classificar cada um. Cada uma dessas etapas tem um modo de falha, e as falhas se acumulam.

O que torna o OCR difícil

O problema central não é a classificação. Classificar uma imagem de caractere pré-segmentada de 28 × 28 pixels em uma das 62 classes (A–Z, a–z, 0–9) é uma tarefa que uma LeNet dos anos 1990 resolve com 99% de precisão. A parte difícil é tudo o que vem antes do classificador.

Variação de fontes. A letra "g" tem pelo menos quatro variantes estruturais comuns: um andar (escrita à mão), dois andares (a maioria das fontes com serifa), a cauda em laço da Helvetica e a cauda aberta da Futura. Um modelo treinado em Tahoma lerá Univers incorretamente a uma taxa mensurável. O OCR do mundo real cobre centenas de tipos de fonte mais a caligrafia, que não tem nenhuma topologia de traço consistente.

Distorção geométrica. Fotos de documentos raramente são digitalizações planas. Uma foto de celular de um recibo introduz inclinação de perspectiva, curvatura e escala não uniforme. Texto próximo à lombada de um livro se curva. Fotos de quadro branco capturam a sombra do fotógrafo. Uma inclinação de 10 graus reduz a precisão do Tesseract de ~97% para menos de 85% em benchmarks padrão. Algoritmos de endireitamento (detecção de linhas de Hough, transformada de Radon, análise de perfil de projeção) recuperam parte dessa perda, mas nenhum recupera totalmente.

Iluminação e ruído. Iluminação irregular transforma um fundo uniforme em um gradiente, quebrando a limiarização global. Artefatos de compressão JPEG criam ringing ao redor de bordas nítidas. Em termos de OCR, isso significa ringing ao redor dos traços das letras. Ruído sal-e-pimenta de sensores em baixa luminosidade preenche o espaço branco com pixels escuros que parecem pontuação. Uma fotocópia de uma fotocópia funde traços finos, transformando "rn" em "m" e "cl" em "d".

Complexidade de layout. Documentos têm colunas, legendas, tabelas, cabeçalhos, notas de rodapé e barras laterais. O texto flui ao redor das imagens. Alguns idiomas são escritos da direita para a esquerda. Outros misturam direções no mesmo parágrafo. Identificar a ordem de leitura (qual bloco de texto vem depois de qual) é um problema de análise de layout separado do reconhecimento, e errar embaralha a saída mesmo quando cada caractere é classificado corretamente.

Ambiguidade contextual. Considerando apenas o padrão de pixels, "0" (dígito zero), "O" (letra O maiúscula) e "o" (letra o minúscula) são idênticos em muitas fontes sans-serif. "1", "l", "I" e "|" compartilham um traço vertical. A resolução adiciona outra dimensão: com 12 pixels de altura, "e" e "c" diferem por um único traço horizontal de três pixels de largura. Leitores humanos resolvem isso pelo contexto. Máquinas precisam de modelos de linguagem, estatísticos ou aprendidos, para fazer a mesma escolha.

A pipeline tradicional de OCR

Antes do deep learning, o OCR era uma sequência de etapas projetadas manualmente. Cada etapa era desenvolvida independentemente, muitas vezes por grupos de pesquisa diferentes, e ajustada para uma degradação específica. A pipeline tinha esta aparência:

Imagem bruta → Pré-processamento → Binarização → Endireitamento → Análise de layout
  → Segmentação de caracteres → Extração de features → Classificação
  → Pós-processamento (modelo de linguagem) → Saída de texto

Pré-processamento e binarização

Imagens coloridas são convertidas para escala de cinza. A redução de ruído suaviza o sinal antes da limiarização. O filtro de mediana lida com ruído sal-e-pimenta. O desfoque gaussiano lida com ruído do sensor. O filtro bilateral é usado quando a preservação de bordas é importante.

A binarização transforma a imagem em escala de cinza em texto preto sobre fundo branco. O algoritmo padrão é o método de Otsu (1979): ele busca exaustivamente o limiar que minimiza a variância intra-classe entre as distribuições de pixels de primeiro plano e de fundo. Otsu assume um histograma bimodal (pixels de texto se agrupam em uma intensidade, pixels de fundo em outra), o que funciona para digitalizações planas sob iluminação controlada e falha para fotos de celular com sombras. Métodos adaptativos locais (Sauvola, Niblack) calculam um limiar diferente por pixel com base em estatísticas de vizinhança, lidando com iluminação irregular ao custo de artefatos próximos às bordas.

Endireitamento e análise de layout

A inclinação do documento é detectada encontrando linhas: seja pela transformada de Hough nos pixels de borda, ou pela análise de perfil de projeção onde o documento é girado em uma faixa de ângulos e o ângulo com os picos de projeção horizontal mais nítidos é escolhido. Uma vez conhecido o ângulo de inclinação, uma transformação afim gira a imagem de volta.

A análise de layout segmenta a página em blocos de texto. A abordagem clássica executa análise de componentes conectados (CCA) para encontrar aglomerados de pixels de primeiro plano, agrupa-os em palavras por proximidade, depois agrupa palavras em linhas e linhas em blocos. O algoritmo XY-cut divide recursivamente a página encontrando lacunas de espaço em branco ao longo de projeções horizontais e verticais, construindo uma árvore de regiões. Implementações modernas usam uma abordagem híbrida: CCA para os aglomerados iniciais, depois um modelo aprendido para classificar cada aglomerado como texto, imagem, tabela ou separador.

Segmentação de caracteres

Para texto impresso mecanicamente, segmentação significa cortar imagens de palavras em caracteres individuais. O perfil de projeção vertical (um histograma de contagens de pixels de primeiro plano por coluna) produz picos nos centros dos caracteres e vales nos limites dos caracteres. Isso funciona até que dois caracteres se toquem, ou um caractere contenha partes desconectadas ("i", "j", ":", "%"). A super segmentação (cortar de forma muito agressiva) seguida de fusão com base na confiança do classificador é uma solução. Outra é pular totalmente a segmentação e reconhecer palavras inteiras, que é o que os métodos modernos baseados em sequência fazem.

Extração de features e classificação

Uma vez que você tem uma imagem de caractere, precisa descrevê-la numericamente para um classificador. As features pré-deep-learning incluíam:

• Valores brutos de pixels como vetor achatado (simples, frágil a translação e escala)
• Zoning: dividir a caixa delimitadora do caractere em uma grade N × N, contar pixels de primeiro plano por célula, usar as contagens como features
• Features baseadas em gradiente (HOG): histograma de gradientes orientados captura direções de borda, robusto a pequenas translações
• Scale-invariant feature transform (SIFT): detecta e descreve pontos-chave invariantes a escala, rotação e iluminação

O classificador era tipicamente uma support vector machine (SVM) com kernel RBF, treinada em dezenas de milhares de imagens de caracteres rotuladas por fonte. Uma pipeline SVM + HOG bem ajustada podia atingir ~98% de precisão por caractere em texto impresso limpo. Com entrada ruidosa, inclinada ou manuscrita, a precisão caía para 70–80%.

Tesseract: dos HP Labs ao LSTM

O Tesseract é o motor de OCR open-source de referência. Começou como um projeto de doutorado no HP Labs Bristol nos anos 1980, foi aberto em 2005 e é mantido pelo Google desde 2006. Sua arquitetura se divide nitidamente em duas eras.

Versão 3: a pipeline clássica

O Tesseract 3 implementava a pipeline tradicional com algumas inovações. Sua análise de layout usava um algoritmo de detecção de tab-stop que encontrava limites de colunas alinhando caixas delimitadoras de palavras, uma heurística pragmática calibrada para o tipo de documento que a HP digitalizava nos anos 1990. A segmentação de caracteres usava lógica chopper/associator: o chopper super segmentava a imagem da palavra em cortes candidatos, e o associator usava a confiança do classificador e um dicionário para decidir quais cortes unir.

O classificador era um sistema de duas passagens. A primeira passagem (classificador estático) combinava aglomerados segmentados com protótipos (amostras de treinamento agrupadas) usando uma busca de vizinho mais próximo. A segunda passagem (classificador adaptativo) se ajustava ao próprio documento, aprendendo a fonte específica usada naquela imagem. O classificador adaptativo precisava de aproximadamente uma página de texto para se tornar eficaz, razão pela qual o Tesseract 3 tinha desempenho ruim em imagens de palavras únicas como placas de rua e legendas.

O Tesseract 3 distribuía arquivos .traineddata: arquivos contendo os clusters de protótipos, definições de conjuntos de caracteres, um dicionário de frequência de palavras e uma tabela de ambiguidade unichar mapeando pares de caracteres confundíveis. Treinar um novo idioma exigia alimentar o Tesseract com imagens de texto pareadas com transcrições de referência, delimitando cada caractere e executando as ferramentas de treinamento. Um processo de horas por idioma.

Versão 4/5: LSTM substitui a pipeline

O Tesseract 4 (2018) substituiu todo o caminho de reconhecimento por uma única rede neural LSTM. A LSTM opera em uma sequência de fatias verticais da imagem da linha de texto, cada fatia com um pixel de largura e a altura total da linha de texto. Cada fatia é alimentada em uma pilha de camadas LSTM bidirecionais. A saída é uma sequência de probabilidades de caracteres com uma perda Connectionist Temporal Classification (CTC) que alinha a sequência de saída de comprimento variável ao texto de referência sem exigir posições de caracteres pré-segmentadas.

O modelo LSTM lida com caracteres de largura variável, caracteres que se tocam e variação de fonte sem o mecanismo chopper/associator. Ele ainda depende da análise de layout legada do Tesseract para encontrar linhas de texto, mas o reconhecimento de linha é neural de ponta a ponta. No benchmark ICDAR 2017, o Tesseract 4 alcançou 4,4% de taxa de erro de caractere (CER) em inglês impresso, comparado a 7,2% do Tesseract 3. O processo de treinamento mudou da ferramenta legada de delimitação para o pareamento de linhas de texto com transcrições. Ainda supervisionado, mas com um rótulo por linha em vez de por caractere.

O formato .traineddata foi estendido para armazenar os pesos do modelo LSTM (vários megabytes) junto com os dados legados (dicionário, tabelas unichar) em um único arquivo. Treinar um modelo LSTM rápido do zero leva cerca de 24 horas em uma GPU moderna para um idioma de escrita latina com aproximadamente 100 classes de caracteres; idiomas CJK levam mais tempo devido a conjuntos de caracteres maiores.

Características de precisão

O Tesseract 5 melhorou a versão 4 com um corpus de treinamento maior e parâmetros padrão melhores, mas a arquitetura permanece inalterada. A precisão depende fortemente da entrada:

O modelo LSTM remove a maioria dos problemas de sensibilidade a fontes da versão 3, mas o motor ainda se degrada em baixa resolução (abaixo de 200 DPI, a entrada de fatia de pixel da LSTM perde detalhes de traço), texto manuscrito (o modelo foi treinado em fontes impressas; a caligrafia tem estatísticas de traço fundamentalmente diferentes) e layouts complexos (a análise de layout ainda é o caminho de código legado, não o neural).

Abordagens modernas de deep learning

Academicamente, o OCR superou o paradigma CTC + LSTM por volta de 2019. Três arquiteturas agora dominam a literatura.

CRNN + CTC

A Convolutional Recurrent Neural Network (CRNN), publicada por Shi et al. em 2015, une um extrator de features CNN com um modelo de sequência RNN e decodificação CTC. A CNN extrai features espaciais da imagem, essencialmente aprendendo o que a LSTM do Tesseract recebia manualmente (representações de fatias verticais). A RNN modela dependências sequenciais entre as features extraídas. O CTC lida com o alinhamento. CRNN-CTC tornou-se a linha de base padrão: treinável de ponta a ponta, boa generalização, inferência rápida (~20 ms por linha em GPU).

Encoder-decoder baseado em atenção

Modelos baseados em atenção adaptaram o paradigma seq2seq da tradução automática. Um encoder CNN ou de visão produz um mapa de features da imagem. Um decoder RNN gera o texto de saída um caractere por vez, prestando atenção às regiões espaciais relevantes do mapa de features a cada passo. O mecanismo de atenção remove a restrição monotônica do CTC: o decoder pode voltar a partes anteriores da imagem quando o modelo de linguagem espera um padrão repetido, embora essa flexibilidade também introduza risco de alucinação para entrada ilegível. Decoders baseados em atenção atingem ~1,5–3% de CER em inglês impresso limpo, superando modelos apenas CTC em sequências longas e layouts irregulares.

Vision Transformers (TrOCR, Donut)

O TrOCR (Microsoft, 2021) aplicou a arquitetura Transformer ao OCR. A imagem é dividida em patches, codificada por um encoder ViT (Vision Transformer), e o texto é decodificado autoregressivamente por um decoder Transformer de texto. É a arquitetura de um modelo multimodal padrão, treinado especificamente para OCR. O TrOCR alcança resultados de ponta em texto impresso (CER abaixo de 1% em digitalizações limpas) sem nenhum pré-processamento CNN, modelo de linguagem explícito ou segmentação em nível de caractere.

O Donut (NAVER, 2022) estendeu a abordagem para compreensão de documentos: a entrada é uma imagem completa do documento, e a saída é JSON estruturado extraído diretamente das features visuais, pulando completamente a pipeline OCR → NLP. Isso borra a linha entre OCR e análise de documentos de uma forma que importa para aplicações reais: extrair o total de uma fatura, um número de passaporte ou uma tabela de um artigo de pesquisa torna-se uma única chamada de modelo em vez de OCR + regex + heurísticas.

Comparação de desempenho (inglês impresso, 300 DPI limpo)

A diferença entre o Tesseract e os melhores modelos Transformer é real nos benchmarks. Na prática, a diferença diminui porque a maioria dos sistemas em produção alimenta o Tesseract com entrada limpa, bem iluminada e a 300 DPI, e nessa entrada, 1,8% de CER significa um caractere errado a cada 55. Aceitável para indexação de busca, menos para a transcrição de um documento legal.

OCR não-inglês: por que é mais difícil

O OCR em inglês é um problema resolvido. Um conjunto de caracteres de 26 maiúsculas, 26 minúsculas, 10 dígitos e um punhado de pontuação resulta em cerca de 70 classes. Um problema de classificação multi-classe confortavelmente dentro da capacidade de uma LeNet dos anos 1990. Os outros sistemas de escrita do mundo são menos indulgentes.

CJK: explosão do conjunto de caracteres

Chinês, japonês e coreano (CJK) representam o desafio de OCR mais difícil apenas pelo tamanho do conjunto de caracteres. O chinês simplificado usa cerca de 3.500 caracteres comuns e mais de 6.000 em texto geral. O chinês tradicional adiciona outro milhar de formas variantes. O japonês mistura dois silabários (hiragana, katakana: 46 caracteres cada) com cerca de 2.000 kanji comuns mais alfanuméricos latinos na mesma frase. O hangul coreano é foneticamente regular (24 letras básicas que se combinam em blocos silábicos), mas visualmente denso: um único bloco pode conter até seis componentes jamo individuais comprimidos em um espaço aproximadamente do tamanho de dois caracteres latinos lado a lado.

Um sistema de OCR CJK não pode tratar o reconhecimento como uma classificação de 70 vias. É uma classificação de 4.000 vias para japonês, 6.000 vias para chinês simplificado e mais de 10.000 vias para chinês tradicional, no mínimo. Apenas a camada de saída softmax tem mais parâmetros do que um modelo de OCR inteiro para escrita latina. Os dados de treinamento precisam escalar com o conjunto de caracteres: ~100 amostras rotuladas por classe para precisão aceitável, então conjuntos de treinamento chineses começam em 600.000 imagens de linhas de texto.

O Tesseract fornece arquivos traineddata CJK (chi_sim, chi_tra, jpn, kor), mas eles são significativamente maiores que os modelos latinos. chi_sim.traineddata tem ~50 MB contra ~15 MB do eng.traineddata, e o reconhecimento é mais lento porque o espaço de saída é maior. A precisão em texto CJK impresso limpo fica em 2–5% de CER para o Tesseract 5, aproximadamente 2–3 vezes a taxa de erro do inglês em condições equivalentes.

Árabe e escritas da direita para a esquerda

O árabe adiciona dois problemas além do conjunto de caracteres (28 letras com formas contextuais que mudam com base na posição dentro da palavra). Primeiro, é escrito da direita para a esquerda, então o motor de OCR deve detectar a direção do texto e inverter a ordem de saída. Segundo, o árabe é cursivo. As letras dentro de uma palavra se conectam por um traço de linha de base, tornando a segmentação inerentemente mais difícil do que com as formas de letras majoritariamente desconectadas das escritas latina e cirílica. Uma imagem de palavra árabe é um aglomerado contíguo; a segmentação baseada em caracteres é efetivamente impossível, razão pela qual a abordagem LSTM/CTC (que opera em imagens de palavras sem segmentação de caracteres) foi um avanço maior para o OCR árabe do que para o OCR inglês.

Hebraico, urdu, farsi e pashto compartilham alguma combinação desses desafios. O Tesseract fornece traineddata para árabe, mas a precisão é de aproximadamente 5–8% de CER em texto impresso limpo, cerca de 4 vezes pior que o inglês sob as mesmas condições.

Escritas índicas: o problema dos conjuntos

Devanagari (hindi, marata, nepalês) e outras escritas brâmanes representam um desafio distinto: a unidade de escrita não é o caractere, mas o conjunto, um aglomerado visualmente fundido de uma consoante, um modificador vocálico e, às vezes, uma consoante adicional. O bloco Unicode Devanagari tem 128 pontos de código, mas o número de conjuntos possíveis excede 1.000. A "shirorekha" (a linha horizontal superior que conecta caracteres em uma palavra) torna a segmentação mais difícil porque a linha funde caracteres adjacentes em uma unidade visual.

O traineddata hindi do Tesseract (hin) cobre os conjuntos comuns, mas a precisão fica atrás do inglês em 3–4 vezes no texto impresso. Tâmil, telugo, bengali e outras escritas indianas são menos suportadas, com algumas sem nenhum arquivo traineddata oficial. A causa raiz é o volume de dados de treinamento: imagens de linhas de texto anotadas de alta qualidade para hindi existem aos milhões, enquanto para canarês os conjuntos de dados disponíveis estão na casa das dezenas de milhares.

Texto vertical e layouts de direção mista

Japonês e chinês tradicional às vezes são compostos verticalmente, com linhas indo de cima para baixo e colunas da direita para a esquerda. A análise de layout do Tesseract assume texto horizontal; texto vertical requer pré-rotação ou um motor separado. Texto misto horizontal e vertical na mesma página, comum em jornais japoneses e mangás, quebra totalmente a suposição de direção única e exige detecção de direção em nível de região antes do reconhecimento.

Idiomas menores e dados de treinamento

Para idiomas com menos de 10 milhões de falantes, dados de treinamento de OCR de alta qualidade raramente existem. O consórcio Unicode codificou mais de 150 escritas, mas o Tesseract distribui traineddata para aproximadamente 120 idiomas, muitos deles gerados a partir de texto sintético renderizado com fontes padrão em fundos limpos. Dados sintéticos funcionam para texto impresso em fontes comuns e falham para as fontes, papéis e qualidade de impressão encontrados em documentos reais desses idiomas. Um modelo treinado em Arial sintético a 300 DPI não lerá um documento amárico datilografado dos anos 1970.

OCR no lado do navegador com Tesseract.js

Executar OCR no navegador era impraticável até o WebAssembly ser lançado. O Tesseract.js compila o Tesseract 5 (LSTM) para WebAssembly via Emscripten, envolvendo o motor C++ em uma API JavaScript que executa um Web Worker por tarefa de reconhecimento. O motor, os dados de idioma e o worker são carregados de ativos estáticos. Nenhum round-trip ao servidor para os dados da imagem.

A superfície da API é direta: crie um worker com um ou mais códigos de idioma, forneça uma imagem, receba o texto reconhecido com pontuações de confiança por caractere. Vários workers podem ser executados em paralelo, limitados pelos núcleos de CPU disponíveis. Tipicamente quatro tarefas de reconhecimento paralelas em um laptop comum, seis a oito em telefones recentes.

O desempenho é limitado por três fatores. Primeiro, o WebAssembly roda a aproximadamente 50–70% da velocidade nativa; uma linha de texto que leva 100 ms no Tesseract nativo leva cerca de 160 ms no navegador. Segundo, os arquivos traineddata são carregados pela rede. eng.traineddata tem ~15 MB, chi_sim.traineddata tem ~50 MB, e ambos devem ser completamente baixados antes do início do reconhecimento. Terceiro, a decodificação de imagens (JPEG/PNG/WebP/HEIC para dados brutos de pixels) usa os decodificadores integrados do navegador, que são rápidos mas variam por formato e dispositivo.

A vantagem de privacidade é estrutural. OCR no lado do cliente significa que a imagem nunca sai do dispositivo. Uma foto de passaporte, um extrato bancário, um registro médico. Os pixels são decodificados no navegador, o equivalente ao Textract roda em um Web Worker, e o resultado é uma string de texto que o usuário pode copiar ou salvar. Nenhum data center processa a imagem. Isso não é uma funcionalidade; é a ausência de um servidor, que é categoricamente diferente de uma política de privacidade prometendo não olhar.

Nossa ferramenta Image to Text executa exatamente essa stack: Tesseract.js com reconhecimento LSTM, Web Workers para processamento paralelo e traineddata para 12 idiomas (inglês, espanhol, francês, alemão, português, italiano, chinês simplificado e tradicional, japonês, coreano, hindi e russo). Solte uma foto, selecione idiomas, obtenha texto. A ferramenta lê entrada JPEG, PNG, WebP, BMP e GIF, aplica pré-dimensionamento sensível à resolução (imagens acima de 3.000 pixels no lado mais longo são reduzidas para manter a latência de reconhecimento razoável) e produz texto simples por imagem com confiança por caractere disponível.

A escolha do formato de imagem afeta a qualidade do OCR na prática. Fotos HEIC de iPhones, convertidas para JPEG antes do OCR, adquirem artefatos de compressão ao redor das bordas do texto que reduzem a precisão do reconhecimento. Converter HEIC para PNG primeiro (sem perdas, sem artefatos de quantização) preserva as bordas nítidas das quais a LSTM depende. Nossos conversores HEIC to JPG e HEIC to PNG lidam com essa etapa de pré-processamento diretamente no navegador. Da mesma forma, fotos tiradas em baixa luminosidade se beneficiam da conversão para um formato que preserva a faixa tonal completa antes da limiarização: JPG to PNG evita os artefatos JPEG de segunda geração que se acumulam quando uma fonte JPEG é recodificada.

A stack de OCR no navegador não é competitiva com modelos server-side acelerados por GPU em throughput. Um servidor rodando Tesseract em 32 núcleos de CPU com C++ nativo sempre será mais rápido que uma aba do navegador. Ela vence em privacidade, zero infraestrutura e zero custo por requisição. Para digitalizar algumas páginas, um recibo ou um punhado de placas, a diferença de latência entre 200 ms e 50 ms é invisível.

Para onde o OCR está indo

O OCR deixou de ser um campo de pesquisa independente por volta de 2022 e se fundiu ao espaço mais amplo de document AI e modelos multimodais. Três mudanças estão em andamento.

LLMs multimodais como OCR zero-shot. GPT-4V, Claude e Gemini podem ler texto de imagens sem treinamento explícito de OCR. Forneça uma foto de um documento e peça o texto, e o modelo o retorna. Não porque tenha um cabeçalho de OCR dedicado, mas porque o reconhecimento de texto emerge do treinamento em bilhões de pares imagem-texto. A qualidade é irregular. Em inglês impresso limpo, o GPT-4V alcança ~1% de CER, comparável a um TrOCR ajustado. Em fotos de baixa resolução de recibos chineses, pode superar o Tesseract porque o modelo aproveita o contexto (ele sabe como é um recibo e quais números esperar) em vez de depender apenas de evidências em nível de pixel. Em caligrafia, é pior que um reconhecedor ajustado porque a distribuição de treinamento não incluiu imagens manuscritas suficientes.

O trade-off é custo e latência. Uma chamada de API ao GPT-4V para OCR custa 1–3 centavos por página dependendo da contagem de tokens e leva 1–3 segundos. O Tesseract roda localmente em 100–500 ms e não custa nada por página. Para digitalizar um documento de 200 páginas, a diferença é de $2–6 e vários minutos de tempo real versus zero e menos de um minuto. Para uso pontual (um único recibo, uma foto de quadro branco), o modelo multimodal é mais simples e frequentemente mais preciso.

Inferência no dispositivo. Os modelos por trás do OCR de servidor estão encolhendo. O ONNX Runtime Web executa modelos CRNN quantizados e pequenos ViT no navegador a 50–100 ms por linha de texto em WebGPU. O framework Vision da Apple inclui um modelo de OCR compacto no dispositivo para iOS e macOS, acessível via VNRecognizeTextRequest sem chamada de rede. A lacuna entre "modelo GPU de servidor" e "modelo de navegador" está se fechando porque ambos estão convergindo para o mesmo ponto ideal arquitetural: um pequeno encoder ViT (~20–50M parâmetros) com um decoder leve, quantizado para INT8 ou FP16.

Compreensão de documentos, não apenas transcrição. A saída do OCR é uma string. A maioria das tarefas do mundo real envolve extrair informações estruturadas dessa string: números de fatura, datas, totais, nomes, endereços. A abordagem tradicional encadeia OCR com regex, reconhecimento de entidades nomeadas e mapeamento de esquema. Cada etapa é um modelo separado com seus próprios modos de falha. Modelos de compreensão de documentos de ponta a ponta (Donut, LayoutLMv3, Pix2Struct) pulam o OCR e mapeiam imagens de documentos diretamente para saídas estruturadas. Um modelo Donut ajustado para recibos não produz uma transcrição de texto para depois analisar. Ele produz {"total": "42.50", "date": "2026-07-27", "vendor": "..."} diretamente da entrada de pixels. A etapa de OCR, a parte sobre a qual este artigo trata, torna-se um detalhe de implementação invisível.

Isso não torna o OCR obsoleto. Torna-o um bloco de construção. A pipeline ainda precisa lidar com os casos extremos: o recibo fotografado em ângulo em um restaurante escuro, o documento datilografado de 50 anos em papel amarelado, a placa em um idioma para o qual nenhum grande modelo multimodal foi treinado. Motores de OCR especializados treinados nessas distribuições específicas superarão em velocidade e desempenho um modelo de propósito geral por anos, porque um modelo de propósito geral treinado em toda a internet aloca uma fração minúscula de sua capacidade para ler a saída de uma máquina de escrever amárica dos anos 1970.

OCR não é um problema resolvido para a maioria dos idiomas do mundo e para a maioria das condições reais de imagem. É um problema resolvido para texto impresso mecanicamente, limpo, a 300 DPI, em inglês, coluna única — a fatia mais estreita e mais bem financiada do espaço do problema. O resto ainda está em aberto.