Pipeline de OCR do Dropbox

01 · CONTEXTO E DECISÃO

Comprar para validar, construir para controlar

O scanner de documentos do Dropbox para celular entrega apenas uma imagem: para o computador, o texto nela é só um conjunto de pixels. O OCR extrai o texto de verdade, o que permite indexá-lo para busca e criar uma camada oculta que deixa copiar e colar o texto dos PDFs.

Na primeira versão, a equipe integrou uma biblioteca comercial de OCR para validar o produto antes de investir num sistema próprio de aprendizado de máquina. Confirmada a forte demanda dos usuários, decidiu construir o OCR interno.

A equipe aponta o controle como talvez o motivo mais importante: construir o próprio sistema daria mais controle sobre o próprio destino e abriria espaço para funcionalidades mais inovadoras no futuro.

Havia também uma mudança técnica. Os OCRs tradicionais eram muito encadeados, com módulos feitos à mão para imagens de scanner de mesa. O aprendizado profundo permitiu depender de grandes quantidades de dados para que o sistema aprendesse sozinho várias etapas antes projetadas à mão.

02 · PESQUISA E PROTÓTIPO

Provar que é possível: dados, meta e dois estágios

Para saber o que superar, a equipe reuniu imagens de documentos doadas por uma pequena parcela de usuários, como recibos, faturas e cartas. Como os dados são privados, criou uma plataforma própria de anotação, a DropTurk, que envia os trabalhos de dados doados a contratados sob acordo de confidencialidade.

Num conjunto de documentos completos, a meta de acurácia ficava em meados dos 90%: a medida dos sistemas existentes dizia a pontuação a igualar ou superar.

O problema foi dividido em duas partes. O Word Detector usa visão computacional para segmentar a imagem em linhas e palavras; o Word Deep Net recebe cada palavra e a converte em texto. A equipe achou o detector relativamente simples e começou pela rede, da qual tinha menos certeza.

A rede combina arquiteturas de visão computacional e de reconhecimento de fala. Imagens de palavras recortadas passam por uma CNN com várias camadas convolucionais; as características resultantes seguem como sequência para uma LSTM bidirecional; e uma camada CTC produz a previsão de texto.

Para o detector, a escolha foi uma abordagem clássica, a MSER. Um motivo é que documentos têm centenas ou milhares de palavras, ordens de grandeza acima do que os detectores de objetos neurais da época encontravam; outro é que abordagens clássicas podem ser mais fáceis de depurar.

Um detalhe de interface entre os estágios: a rede aceita imagens de palavra de tamanho fixo, então o detector às vezes inclui mais de uma palavra numa caixa ou corta uma palavra longa ao meio. Essa informação precisa ser propagada pelo pipeline para remontar o resultado depois.

03 · DADOS SINTÉTICOS

Gerar dados de treino em vez de rotular tudo

Redes profundas precisam de muitos dados, e a quantidade deles costuma ser o maior gargalo. Coletar e rotular tudo à mão é lento e caro, e na maioria dos problemas de visão é difícil demais gerar imagens realistas o bastante. Aqui havia uma exceção: documentos e seu texto são sintéticos, e a variabilidade dos caracteres é relativamente limitada.

O pipeline de dados sintético tem três peças: um corpus de palavras, uma coleção de fontes e um conjunto de transformações geométricas e fotométricas que simulam distorções do mundo real. O gerador amostra de cada uma para criar exemplos únicos.

A primeira versão era simples: palavras de livros do Projeto Gutenberg, cerca de mil fontes e distorções leves como rotação, sublinhado e desfoque. Com cerca de um milhão de palavras sintéticas, a acurácia ficou em torno de 79%, o que a equipe considerou razoável, mas insuficiente.

A seleção de fontes também amadureceu: cerca de 2.000 fontes escolhidas à mão, com um sistema de frequência que amostra mais as comuns, como Helvetica ou Times New Roman, mas mantém uma cauda longa de fontes raras. As fontes com símbolos, números ou caixa inválidos foram marcadas à mão para não treinar a rede com dados incorretos.

As iterações levaram a acurácia de palavra isolada (SWA) à faixa alta dos 80%. A equipe então coletou cerca de 20.000 imagens reais de palavras, contra cerca de um milhão sintéticas, e as usou para fine-tuning, chegando a meados dos 90%.

Os treinos rodaram em instâncias GPU G2 da Amazon EC2, com muitos experimentos em paralelo. Cada experimento ia para um caderno de laboratório registrando, entre outros itens, o hash do git do código usado e ponteiros para dados gerados e resultados no S3.

04 · JUNTAR AS PEÇAS

Da palavra isolada ao documento inteiro

Ao encadear detector e rede e medir documentos completos, a primeira acurácia ponta a ponta ficou em torno de 44%, bem pior que a concorrência. Os problemas principais eram espaçamento e texto lixo vindo do ruído da imagem.

A solução foi modificar a camada CTC para devolver também uma pontuação de confiança junto ao texto previsto, e usá-la para separar as previsões em três faixas.

Um módulo chamado Wordinator gera caixas delimitadoras discretas para cada palavra reconhecida. A equipe também treinou a rede com mais de dez milhões de palavras sintéticas, e o conjunto do trabalho resultou em números de acurácia, precisão e recall que igualavam ou superavam o estado da arte.

1. O Word Detector usa uma técnica clássica de visão computacional, a MSER, para achar palavras e linhas na imagem do documento.

2. Cada palavra recortada entra no Word Deep Net: uma CNN extrai características, uma LSTM bidirecional lê a sequência e uma camada CTC produz o texto.

3. O pós-processamento usa a confiança para manter, descartar ou checar num léxico cada previsão, e o Wordinator gera uma caixa para cada palavra reconhecida.

4. No refinamento, um preditor de orientação passou a girar a imagem para a posição correta antes da detecção de palavras.

05 · PRODUÇÃO

Do protótipo ao serviço distribuído

O protótipo eram scripts Python e Lua em torno do Torch, longe de um sistema para usuários reais. Era preciso um pipeline distribuído para milhões de usuários, sem interromper o OCR comercial que já atendia em produção.

1. A equipe criou uma abstração de motores de OCR, com o próprio e o comercial atrás dela, controlada por um framework de experimentos.

2. O motor próprio passou a rodar em silêncio ao lado do comercial, para provar com dados reais de usuários que era melhor.

3. Com desempenho igual ou melhor num teste com imagens doadas, o motor próprio foi ampliado a todos os usuários Dropbox Business.

O modelo foi portado do Torch para TensorFlow, que já era padrão em produção, e a equipe também preferia Python a Lua.

No novo pipeline, clientes móveis enviam as imagens a uma fila de trabalho assíncrona e, ao fim do envio, a imagem segue por RPC a um cluster que roda o serviço de OCR. O serviço usa OpenCV e TensorFlow, ambos escritos em C++ e com dependências complicadas de bibliotecas, então exploits de segurança são uma preocupação real: a parte de OCR foi isolada em jails, e quem comprometer um jail continua separado do resto do sistema.

1. O app do scanner envia a imagem para a fila de trabalho assíncrona.

2. Quando o envio termina, a imagem segue por RPC para um cluster de servidores com o serviço de OCR.

3. O OCR roda isolado num jail; modelos caros carregados uma vez na inicialização são clonados para cada pedido.

4. O texto e as caixas de palavras voltam como uma camada oculta mesclada ao PDF gerado pelo scanner.

5. O texto reconhecido também entra no índice de busca, e o documento passa a ser encontrado por ele.

Na otimização de custo da inferência, o hardware era uma escolha: GPUs de ponta num data center de produção eram um tanto exóticas; a equipe decidiu que atingiria as metas de desempenho só com CPUs, a custo similar ou menor que com máquinas com GPU.

O Word Detector também era um gargalo significativo. A equipe reescreveu a implementação MSER do OpenCV de forma modular para evitar repetir trabalho lento nas duas passadas, uma para texto escuro em fundo claro e outra para o inverso.

06 · REFINAMENTO

O que só o mundo real mostrou

Com o sistema rodando em silêncio ao lado do comercial, a equipe precisava confirmar que ele era melhor com dados reais. Num teste caixa-preta qualitativo com imagens doadas, o desempenho foi igual ou melhor que o do SDK comercial, o que permitiu ampliar o sistema a 100% dos usuários Dropbox Business.

Nem tudo funcionou: ajustar a rede com os documentos doados, em vez de com o conjunto de ajuste escolhido à mão, não fez diferença na acurácia.

Outro refinamento foi a detecção de orientação, que o pipeline original não tinha. Poucas imagens estão giradas, então era preciso garantir que o sistema não girasse por engano as imagens já retas.

Houve ainda um problema de ecossistema: o aplicativo Preview, da Apple, usa heurísticas próprias para decidir os limites das palavras com base na posição do texto, o que prejudicou o copiar e colar a partir da camada oculta do PDF.

Ao todo, pesquisa, produtivização e refinamento levaram cerca de 8 meses.