O aprendizado de máquina é a maneira errada de extrair dados da maioria dos documentos

Os documentos passaram décadas protegendo obstinadamente seu conteúdo contra software. No final dos anos 1960, as primeiras técnicas de OCR (reconhecimento óptico de caracteres) transformavam documentos digitalizados em texto bruto. Ao indexar e pesquisar o texto desses documentos digitalizados, o software acelerou a descoberta legal e os projetos de pesquisa antes trabalhosos.

Hoje, Google, Microsoft e Amazon fornecem OCR de alta qualidade como parte de suas ofertas de serviços em nuvem. Mas os documentos permanecem subutilizados em cadeias de ferramentas de software e dados valiosos definham em trilhões de PDFs . O desafio mudou de identificar texto em documentos para transformá-los em dados estruturados adequados para consumo direto por fluxos de trabalho baseados em software ou armazenamento direto em um sistema de registro.

A suposição predominante é que o aprendizado de máquina, muitas vezes embelezado como “IA”, é a melhor maneira de conseguir isso, substituindo técnicas baseadas em modelos desatualizadas e frágeis. Essa suposição é equivocada. A melhor maneira de transformar a grande maioria dos documentos em dados estruturados é usar a próxima geração de modelos poderosos e flexíveis que localizam os dados em um documento da mesma forma que uma pessoa faria.

As promessas e falhas do aprendizado de máquina

A promessa do aprendizado de máquina é que você pode treinar um modelo uma vez em um grande corpus de documentos representativos e, em seguida, generalizar suavemente para layouts de documentos fora da amostra sem retreinamento. Por exemplo, você deseja treinar um modelo de ML nas apólices de seguro residencial das empresas A, B e C e, em seguida, extrair os mesmos dados de documentos semelhantes emitidos pela empresa Z. Isso é muito difícil de conseguir na prática por três motivos:

A extração de documentos é uma tarefa excepcionalmente granular para aprendizado de máquina

Seu objetivo geralmente é extrair dezenas ou centenas de elementos de dados individuais de cada documento. Um modelo no nível de granularidade do documento frequentemente perderá alguns desses valores, e esses erros são bastante difíceis de detectar. Depois que seu modelo tenta extrair essas dezenas ou centenas de elementos de dados de tipos de documentos fora da amostra, você obtém uma explosão de oportunidades para falhas de generalização.

Elementos de dados em documentos geralmente têm um relacionamento hierárquico entre si

Embora alguns documentos simples possam ter uma ontologia simples de chave/valor, a maioria terá uma subestrutura: pense em uma lista de deficiências em um relatório de inspeção residencial ou no conjunto de transações em um extrato bancário. Em alguns casos, você encontrará até mesmo subestruturas aninhadas complexas: pense em uma lista de apólices de seguro, cada uma com um histórico de sinistros. Você precisa de seu modelo de aprendizado de máquina para inferir essas hierarquias ou precisa parametrizar manualmente o modelo com essas hierarquias e a ontologia geral desejada antes do treinamento.

Um "documento" é um alvo vago para um projeto de ML

Um documento é qualquer coisa que caiba em uma ou mais folhas de papel e contenha dados! Os documentos são realmente apenas sacos de representações de dados diversas e arbitrárias. Tabelas, rótulos, texto livre, seções, imagens, cabeçalhos e rodapés: você nomeia e um documento pode usá-lo para codificar dados. Não há garantia de que dois documentos, mesmo com a mesma semântica, usarão as mesmas ferramentas de representação.

Não é nenhuma surpresa que os projetos de análise de documentos baseados em ML possam levar meses, exigir toneladas de dados antecipadamente, levar a resultados inexpressivos e, em geral, ser "cansativos" (para citar diretamente um participante em um desses projetos com um fornecedor líder no espaço ).

O desafio com modelos

Essas questões sugerem fortemente que o ângulo de ataque apropriado para estruturar documentos está no nível do elemento de dados, e não no nível do documento como um todo. Em outras palavras, precisamos extrair dados de tabelas, rótulos e texto livre; não de um “documento” holístico. E no nível dos elementos de dados, precisamos de ferramentas poderosas para expressar a relação entre o universo dos modos de representação encontrados nos documentos e as estruturas de dados úteis para o software.

Então, vamos voltar aos modelos.

Historicamente, os modelos têm um meio empobrecido de expressar esse mapeamento entre o modo de representação e a estrutura de dados. Por exemplo, eles podem instruir: vá para a página 3 e retorne qualquer texto dentro dessas coordenadas de caixa. Isso falha imediatamente por vários motivos, incluindo se:

• uma varredura é inclinada
• há uma capa, ou
• o autor do documento adicionou uma seção adicional antes dos dados de destino.

Nenhuma dessas pequenas alterações no layout do documento incomodaria um leitor humano.

Uma linguagem de consulta para documentos

Para que o software estruture documentos complexos com êxito, você deseja uma solução que evite a batalha de projetos de ML de meses contra modelos frágeis. Em vez disso, vamos criar uma linguagem de consulta específica do documento que (quando apropriado) incorpore ML no elemento de dados, em vez de no nível do documento.

Primeiro, você deseja primitivas (ou seja, instruções) na linguagem que descreva os modos de representação (como um par rótulo/valor ou subseções repetidas) e permaneça resiliente a variações típicas de layout. Por exemplo, se você disser:

“Encontre uma linha começando com esta palavra e pegue o valor mais baixo dela”

Você deseja um reconhecimento de “linha” que seja resiliente à variação de espaço em branco, tremulação vertical, capas e distorção de documentos, além de detecção e filtragem de tipo poderosas.

Em segundo lugar, para representações de dados com um componente visual ou de linguagem natural, como tabelas, caixas de seleção e parágrafos de texto livre, os primitivos devem incorporar ML. Nesse nível de análise, Google, Amazon, Microsoft e OpenAI têm ferramentas que funcionam muito bem na prateleira.

Tempo para valorizar como uma estrela do norte

O Sensible adota exatamente essa abordagem: combinar modelos poderosos e flexíveis com aprendizado de máquina. Com SenseML , nossa linguagem de consulta baseada em JSON para documentos, você pode extrair dados estruturados da maioria dos layouts de documentos em minutos com apenas uma única amostra de referência. Não há necessidade de milhares de documentos de treinamento e meses gastos ajustando algoritmos, e não há necessidade de escrever centenas de regras para explicar pequenas diferenças de layout.

A ampla variedade de primitivos do SenseML permite que você mapeie rapidamente os modos de representação para estruturas de dados úteis, incluindo subestruturas aninhadas complexas. Nos casos em que as primitivas não usam ML, elas se comportam de forma determinística para fornecer comportamento forte e garantias de precisão. E mesmo para a saída não determinística de nossas primitivas de ML, como tabelas, as regras de validação podem identificar erros na saída de ML.

Isso significa que a análise de documentos com o Sensible é incrivelmente rápida, transparente e flexível. Se você deseja adicionar um campo a um modelo ou corrigir um erro, é fácil fazê-lo.

A desvantagem do rápido tempo de valorização do Sensible é que cada layout de documento significativamente distinto requer um modelo separado. Mas essa troca acaba não sendo tão ruim no mundo real. Na maioria dos casos de uso de negócios, há um número contável de layouts (por exemplo, dezenas de transportadoras gerando confirmações de taxas nos EUA; um punhado de sistemas de software gerando relatórios de inspeção residencial). Nossos clientes não criam milhares de modelos de documentos – a maioria gera um valor tremendo com apenas alguns.

Obviamente, para cada formulário de imposto amplamente utilizado, apólice de seguro e verificação de emprego, precisamos criar um modelo apenas uma vez. É por isso que apresentamos…

Biblioteca de código aberto da Sensible de modelos pré-construídos

Nosso código aberto Biblioteca de configuração sensata é uma coleção de mais de 100 layouts de documentos analisados com mais frequência, desde apólices de seguro automóvel para formulários ACORD , corridas de perda , formulários de impostos , e mais . Se você tiver um documento de grande interesse, faremos a integração para você e o disponibilizaremos gratuitamente ao público. Também será gratuito para você usar até 150 extrações por mês em nosso nível de conta gratuita.

Acreditamos que essa abordagem híbrida é o caminho para resolver de forma transparente e eficiente o problema de transformar documentos em dados estruturados para uma ampla gama de setores, incluindo logística, serviços financeiros, seguros e saúde. Se você gostaria de se juntar a nós nesta jornada e conectar seus documentos ao software, agende uma demonstração ou Inscreva-se para obter um conta grátis !