Você provavelmente já passou por isso no trabalho: guarda conversas e páginas da web como capturas de tela para consultar depois, mas, quando precisa delas, descobre que o texto dentro dessas imagens não é pesquisável. Ou então um contrato importante, assinado e carimbado, precisa ser digitalizado em PDF para preservar o registro original. Mais tarde, quando você quer procurar uma informação ou citar um trecho, não consegue pesquisar dentro dele, não consegue copiar o texto e acaba folheando páginas e redigitando tudo à mão.
É exatamente esse o problema que o OCR integrado do Gety foi criado para resolver.
Para descobrir o quão bem ele faz isso, pegamos as imagens de documentos de dois datasets públicos (MDPBench e OmniDocBench) e construímos nossa própria avaliação em torno delas, voltada diretamente para o OCR que roda na sua própria máquina. Colocamos o Gety contra as principais opções locais de OCR que usuários provavelmente encontram em fluxos de trabalho reais: PaddleOCR (PP-OCRv6), o candidato mais forte do código aberto; Tesseract, a referência tradicional; e o OCR que vem embutido no macOS e no Windows. OCR em nuvem e modelos em nuvem como o Gemini ficaram fora da comparação de propósito. Eles exigem upload, chamada de API, conexão à internet e, muitas vezes, cobrança por uso, enquanto o Gety roda inteiramente no dispositivo.
Os resultados mostram duas vantagens claras:
- Entre os mecanismos locais de OCR executados no dispositivo, o Gety ocupa o primeiro lugar em precisão multilíngue e lidera no resultado agregado em 17 idiomas.
- Ele usa cerca de um quinto da memória de modelos comparáveis executados no dispositivo, tornando viável manter OCR em segundo plano por longos períodos e fazer indexação em tempo real.
1. Multilíngue: onde o Gety abre mais vantagem
Muitos mecanismos lidam bem o suficiente com inglês e francês. O problema começa quando o sistema de escrita muda. Passe para coreano, russo, tailandês ou híndi e a maioria dos modelos despenca, de acima de 0.9 para 0.2 ou 0.1, um nível praticamente inútil na prática. Veja como o conjunto se sai nos 17 idiomas, usando as imagens de documentos do MDPBench:
| Idioma / Métrica | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| Geral (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| Escritas latinas (méd.) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| Inglês | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| Alemão | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| Francês | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| Espanhol | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| Italiano | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| Português | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| Holandês | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| Indonésio | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| Vietnamita | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| Escritas não latinas (méd.) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| Chinês (simplificado) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| Chinês (tradicional) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| Japonês | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| Coreano | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| Russo | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| Tailandês | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| Híndi | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| Árabe | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
A linha para observar é a das escritas não latinas. É aí que os modelos de código aberto desmoronam, caindo para a faixa de 0.1 a 0.4, enquanto o Gety se mantém em 0.832. Para você, essa é a diferença entre conseguir buscar um documento em chinês, japonês, coreano ou russo e descobrir que o sistema de escrita, sozinho, tornou aquele conteúdo praticamente invisível para a busca. Com o Gety, documentos nessas línguas têm muito menos chance de virar pontos cegos da sua busca.
Fotografias são um caso à parte. Quando a entrada é uma foto de um documento, com borrão, inclinação ou reflexo, em vez de um arquivo digital limpo, todos os modelos têm dificuldade:
| Modelo | Nativo digital (F1) | Fotografado (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
Ninguém é realmente bom nisso ainda. As pontuações caem da faixa de 0.9 para a faixa de 0.2 a 0.4 em toda a linha, e o 0.421 do Apple Vision é o melhor resultado do grupo. O Gety fica um pouco à frente dos modelos de código aberto, mas, para a busca do dia a dia, essa coluna importa menos do que parece: os arquivos que você normalmente quer pesquisar são capturas de tela e digitalizações limpas, não fotos tortas. Isso é a coluna da esquerda.
2. Layouts complexos: no mesmo pelotão de ponta do melhor modelo de código aberto
O idioma é um eixo. O layout é o outro. Páginas com múltiplas colunas, tabelas, cabeçalhos e rodapés recorrentes: esse é o tipo de documento em que um modelo mais fraco começa a perder linhas ou embaralhar sua ordem. O OmniDocBench foi construído para testar exatamente isso:
| Modelo | Precisão de layout (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
O 0.963 do Gety fica meio ponto percentual atrás do PP-OCRv6 small (0.968), uma diferença que você dificilmente perceberia no uso. Os dois modelos estão efetivamente empatados no topo, e ambos deixam os mecanismos de sistema integrados bem para trás.
3. A mesma precisão, uma fração do consumo
Ler bem é uma coisa. Ler bem consumindo pouco o suficiente para ficar ativo o dia todo é outra. Medimos na mesma máquina, com a mesma entrada, o mesmo orçamento de threads e na CPU:
| Modelo | Precisão multilíngue (F1) | Tempo mediano por página | Pico de memória por página |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
O Gety precisa de cerca de 908 MB por página. As versões tiny e small do PP-OCRv6 precisam de 4.7 GB e 6.3 GB, de cinco a sete vezes mais. Essa é a diferença entre um modelo que pode permanecer residente e outro mais adequado a tarefas iniciadas sob demanda. Como o Gety é leve, o OCR pode ficar ativo, capturar cada novo arquivo assim que ele chega e indexá-lo sem que você mexa um dedo.
(O Apple Vision e o Windows OCR rodam dentro de suas próprias plataformas em hardware diferente, então uma comparação de memória ou velocidade não seria justa. Eles aparecem apenas nas tabelas de precisão.)
4. O que testamos, e contra o quê
Os datasets
Pegamos as imagens de documentos de dois datasets públicos e construímos nossa própria avaliação em torno delas. Cada dataset responde a uma pergunta diferente, por isso relatamos os resultados separadamente em vez de misturá-los em um único número que diria pouco:
| Dataset | A pergunta que ele responde |
|---|---|
| MDPBench | A precisão se mantém nos 17 idiomas, tanto em páginas limpas quanto fotografadas? |
| OmniDocBench | Ela continua precisa quando o layout fica complicado? |
Para deixar claro o que isto é: usamos esses datasets como fonte de documentos reais. O método de avaliação, as métricas e o conjunto de modelos são nossos e diferem das avaliações oficiais publicadas pelos autores dos datasets.
Como pontuamos
Pontuamos a saída do OCR com um F1 no nível de caractere, agnóstico ao layout. Ele mede apenas se o texto foi reconhecido corretamente, não o layout, as quebras de linha, a estrutura de parágrafos ou onde o texto está na página.
Mantemos o método agnóstico ao layout porque, para os usos que importam (busca, cópia, indexação), o que conta é se cada caractere foi lido corretamente, não se o layout foi reconstruído. Um texto totalmente correto, mas em ordem diferente ou com quebras de linha diferentes, não deve ser penalizado. Este é um teste de OCR, não um teste de layout.
Para cada página, comparamos a saída do OCR com o texto rotulado manualmente e calculamos:
Antes da pontuação, tanto a referência quanto a saída do OCR passam pela mesma normalização: normalização Unicode, remoção de caracteres invisíveis, unificação de espaços em branco e remoção de elementos de página como cabeçalhos, rodapés e números de página.
A correspondência de caracteres usa contagem de multiconjunto: um caractere que aparece várias vezes é contado a cada ocorrência. Isso evita que diferenças na ordem de leitura, nas quebras de linha e nas divisões de parágrafo afetem a pontuação, de modo que a métrica permanece focada em se o OCR leu corretamente os caracteres da página.
Os números finais são F1 por página, com macromédia entre idiomas e grupos de dados; o relatório completo também fornece um intervalo de confiança bootstrap de 95%.
Contra o que comparamos
Para a comparação, escolhemos as principais opções que usuários provavelmente encontram em fluxos de trabalho reais:
- PaddleOCR (PP-OCRv6), o melhor que o código aberto tem a oferecer. Ele vem nas versões tiny, small e medium; rodamos as duas versões para dispositivo, tiny e small. A medium é um modelo de 34.5M de parâmetros voltado para GPUs de servidor, e colocá-la em um teste de CPU no dispositivo seria comparar coisas erradas.
- Tesseract, o velho cavalo de batalha, presente em todo lugar por padrão, a referência que a maioria das pessoas conhece.
- Apple Vision e Windows OCR, o OCR que você já tem se não instalar nada.
5. A precisão é a base. A utilidade é o ponto.
Os números dizem que o Gety lê com precisão. Mas a precisão é apenas o ponto de partida, não a razão pela qual algo disso importa.
Pense em como você usa uma ferramenta de OCR comum:
Encontrar a imagem -> Abrir ou arrastar para uma ferramenta de OCR -> Iniciar o reconhecimento manualmente -> Esperar o resultado -> Obter texto utilizávelVocê precisa primeiro perceber que há um texto que vale a pena extrair, depois encontrar o arquivo, levá-lo para outra ferramenta, iniciar o reconhecimento, esperar e usar o resultado. Quase sempre, essa cadeia nunca começa. A digitalização, a captura de tela, o contrato fotografado simplesmente ficam ali desde o dia em que chegam, invisíveis para a busca.
Essa lacuna é exatamente o problema que o Gety se propôs a resolver. O OCR roda em segundo plano, então, no momento em que um arquivo chega, ele é lido e indexado automaticamente. Nada para converter, nada para clicar. Você digita na caixa de busca e o texto dentro da imagem simplesmente está lá.
Ou seja, a precisão decide se algo pode ser encontrado; rodar discretamente em segundo plano decide se ele um dia será. Não nos propusemos apenas a lançar mais um mecanismo de OCR. Nos propusemos a fazer com que “as palavras nesta imagem não são pesquisáveis” deixe de acontecer no seu computador.
Estes são nossos próprios resultados internos. Usamos as imagens de documentos dos datasets públicos MDPBench e OmniDocBench como material de teste, mas o método de avaliação e as métricas são nossos e diferem das avaliações oficiais publicadas pelos autores dos datasets. Cada dataset possui sua própria licença e seus termos de uso, alguns apenas para pesquisa; estamos apresentando conclusões aqui, não redistribuindo nenhuma amostra.