Treinamento de modelos de alto desempenho

O poder dos modelos de Machine Learning é que são definidos por dados de treinamento, e não por lógica explícita expressa em código de computador. Isso significa que é necessário um cuidado na prática ao preparar conjuntos de dados porque um modelo terá a qualidade do conjunto de dados usado para treiná-lo. Nesse sentido, o que o UiPath Studio representa para os fluxos de trabalho de RPA , uma sessão do Tipo de documento (no Document &Understanding Cloud) representa para os recursos de Machine Learning . Ambos requerem certa experiência para serem usados de forma eficaz.

O que um modelo de ML de extração de dados pode fazer?

Um Modelo de ML pode extrair dados de um único tipo de documento, embora possa abranger vários idiomas diferentes. É essencial que cada campo (Valor Total, Data, etc.) tenha um significado único e consistente. Se um ser humano pode se confundir em relação ao valor correto de um campo, um Modelo de ML também pode se confundir.

Situações ambíguas podem aparecer. Por exemplo, uma conta de serviços públicos é apenas outro tipo de fatura? Ou são dois tipos de documentos diferentes que exigem dois Modelos de ML diferentes? Se os campos que você precisa extrair são os mesmos (ou seja, eles têm o mesmo significado), você pode tratá-los como um único tipo de documento. No entanto, se você precisar extrair campos diferentes por motivos diferentes (processos de negócios diferentes), precisará tratá-los como dois tipos de documentos distintos e, portanto, treinar dois modelos diferentes.

Em caso de dúvida, comece treinando um único modelo, mas mantenha os documentos em lotes diferentes do Document Manager (consulte o menu suspenso Filtro na parte superior da exibição) para poder separá-los facilmente posteriormente, se necessário. Desta forma, o trabalho de rotulagem não é perdido. Quando se trata de Modelos de ML, quanto mais dados, melhor. Portanto, ter um único modelo com dados amplos é um bom ponto de partida.

Conjuntos de dados de treinamento e avaliação

O Document Manager pode ser usado para construir dois tipos de conjuntos de dados:

• conjuntos de dados de treinamento
• conjuntos de dados de avaliação

Ambos os tipos de conjunto de dados são essenciais para criar um Modelo de ML de alto desempenho e exigem tempo e esforço para criação e manutenção. Um conjunto de dados de avaliação que seja representativo do tráfego de documentos de produção é necessário para obter um Modelo de ML de alto desempenho.

Cada tipo de conjunto de dados é rotulado de uma maneira diferente:

• Os conjuntos de dados de treinamento dependem das caixas delimitadoras das palavras na página que representam as diferentes informações que você precisa extrair.
• Ao rotular um conjunto de treinamento, concentre-se na própria página e nas caixas de palavras.
• Os conjuntos de dados de avaliação dependem dos valores dos campos, que aparecem na barra lateral (para campos Regulares) ou na barra superior (para campos de Coluna).
• Ao rotular um conjunto de avaliação, concentre-se nos valores sob os nomes dos campos na barra lateral ou na barra superior. Isso não significa que você precisa digitá-los manualmente. Recomendamos rotular clicando nas caixas da página e verificando a exatidão dos valores.

Mais detalhes sobre como conduzir Avaliações adequadas podem ser encontrados abaixo.

Componentes de extração de dados

A extração de dados depende dos seguintes componentes:

• Reconhecimento de caracteres óptico
• Compilação de Palavra e Linha
• Agrupando caracteres em palavras e palavras em linhas de texto da esquerda para a direita
• Previsão do modelo de Machine Learning para cada palavra/caixa na página
• Limpeza, análise e formatação dos intervalos de texto
• Por exemplo, agrupar palavras em várias linhas em um endereço, formatar uma data no formato padrão aaaa-mm-dd
• Aplicando um algoritmo para selecionar qual valor é retornado
• Para os casos em que o documento tem duas ou mais páginas e alguns campos aparecem em mais de uma página

Níveis de confiança

O que são níveis de confiança?

Quando os modelos de ML fazem previsões, elas são basicamente suposições estatísticas. O modelo está dizendo este é "provavelmente o Valor Total" desta Fatura. Isso levanta a pergunta: qual a probabilidade? Os níveis de confiança são uma tentativa de responder a essa pergunta em uma escala de 0 a 1. No entanto, eles NÃO são estimativas de probabilidade verdadeiras. São apenas o grau de confiança que o modelo tem de suas suposições, portanto, dependem de como o modelo foi treinado. Uma maneira melhor de pensar neles é como uma medida de familiaridade: qual é o grau de familiaridade do modelo com essa entrada do modelo? Se ela for semelhante a algo que o modelo viu no treinamento, pode ter uma confiança maior. Caso contrário, pode ter uma confiança menor.

Qual a utilidade dos níveis de confiança?

As automações de negócios precisam de maneiras de detectar e lidar com exceções, ou seja, instâncias em que uma automação apresenta erro. Nas automações tradicionais, isso é bastante óbvio porque quando um fluxo de trabalho de RPA apresenta erro, ele simplesmente para, trava ou gera um erro. Esse erro pode ser detectado e tratado de acordo. No entanto, os modelos de machine learning não geram erros quando fazem previsões ruins. Então, como determinamos quando um modelo de ML cometeu um erro e o fluxo de processamento de exceções precisa ser disparado? Isso geralmente envolve o envolvimento manual humano, talvez usando o Action Center.

A melhor maneira de detectar previsões ruins é, indiscutivelmente, por meio da aplicação das regras de negócios. Por exemplo, sabemos que, em uma fatura, o valor líquido mais o valor do imposto deve ser igual ao valor total. Ou que os números de peça dos componentes solicitados devem ter 9 dígitos. Quando essas condições não se aplicam, sabemos que algo deu errado e podemos disparar o fluxo de processamento de exceções. Essa é a abordagem preferida e fortemente recomendada. Vale a pena empregar um esforço significativo na criação desses tipos de regras, mesmo usando Expressões Regulares complexas ou até mesmo pesquisas em bancos de dados para validar nomes de fornecedores, números de peça etc. Em alguns casos, você pode até extrair outro documento que não seja de interesse, mas apenas cruzar a referência e validar alguns valores para o documento original de interesse.

No entanto, em alguns casos, nenhuma dessas opções existe e você ainda deseja detectar previsões potencialmente ruins. Nesses casos, você pode basear-se no nível de confiança. Quando o nível de confiança de uma previsão é baixo, digamos, abaixo de 0,6, o risco de que a previsão esteja incorreta é maior do que se a confiança for 0,95. No entanto, essa correlação é bastante fraca. Há muitas instâncias em que um valor é extraído com baixa confiança, mas está correto. Também é possível, embora relativamente raro, que um valor seja extraído com alta confiança (acima de 0,9), mas está incorreto. Por esses motivos, recomendamos fortemente que os usuários confiem nas regras de negócios o máximo possível e usem apenas os níveis de confiança como último recurso.

Quais tipos de níveis de confiança existem?

A maioria dos componentes no produto do Document Understanding retorna um nível de confiança. Os principais componentes de um fluxo de trabalho do Document Understanding são Digitalização, Classificação e Extração. Cada um deles tem uma certa confiança para cada previsão. As confianças da Digitalização e da Extração são expostas visualmente na Estação de Validação, então você pode filtrar previsões e se concentrar apenas nas de baixa confiança, para economizar tempo.

Escalonamento de pontuação de confiança (ou calibração)

Os níveis de confiança de diferentes modelos serão dimensionados de forma diferente, dependendo do design do modelo. Por exemplo, alguns modelos retornam níveis de confiança no intervalo 0,9 a 1 quase sempre, e muito raramente, abaixo de 0,8. Outros modelos têm níveis de confiança espalhados muito mais uniformemente entre 0 e 1, mesmo que geralmente estejam clusterizados na extremidade superior da escala. Como resultado, os limites de confiança em modelos diferentes serão diferentes. Por exemplo, um limite de confiança no OCR não será o mesmo que o limite no Extrator de ML ou no Classificador de ML. Além disso, sempre que houver uma importante atualização de arquitetura em um modelo, como a que está chegando com o lançamento da arquitetura de modelo generativo de IA baseado em DocPath, a distribuição do nível de confiança será alterada, e os limites de confiança precisarão ser reavaliados.

Crie um modelo de ML de alto desempenho

Para obter o melhor resultado em termos de taxa de automação (redução percentual do trabalho manual medido em pessoas-mês por ano necessário para processar seu fluxo de documentos), você deve seguir estas etapas com atenção:

1. Escolha o melhor mecanismo de OCR para seus documentos

   Isso influencia tanto o OCR quanto a construção de palavras e linhas (que depende parcialmente do OCR) e, por consequência, tudo relacionado.

2. Selecione um conjunto de dados bem equilibrado e representativo para treinamento
3. Defina os campos a serem extraídos
4. Rotule o conjunto de dados de treinamento
5. Treine o Extrator
6. Defina e implemente as regras de negócios para processamento do output do modelo
7. (Opcional) Escolha os limites de confiança para a extração
8. Treinamento usando dados do Validation Station
9. Implante sua automação

1. Escolha o mecanismo de OCR

Para escolher um mecanismo de OCR, você deve criar diferentes sessões do Document Manager, configurar diferentes mecanismos de OCR e tentar importar os mesmos arquivos para cada um deles para examinar as diferenças. Concentre-se nas áreas que você deseja extrair. Por exemplo, se você precisar extrair nomes de empresas que aparecem como parte de logotipos em faturas, convém verificar qual mecanismo de OCR tem melhor desempenho no texto dos logotipos.

Sua opção padrão deve ser UiPath Document OCR, pois está incluída gratuitamente nas licenças do Document Understanding. No entanto, nos casos em que alguns idiomas não suportados são necessários ou alguns documentos muito difíceis de ler estão envolvidos, você pode tentar o Google Cloud (somente na nuvem) ou o Microsoft Read (nuvem ou localmente), que oferecem melhor cobertura de idioma. Esses mecanismos têm um custo, apesar de baixo, mas se a precisão for maior em alguns campos de dados críticos para o seu processo de negócios, é altamente recomendável usar o melhor OCR disponível – economizando seu tempo mais tarde, pois todo o downstream depende disso.

Esteja ciente de que a atividade Digitalizar documento tem a configuração ApplyOcrOnPDF definida como Auto por padrão, determinando se o documento requer a aplicação do algoritmo OCR dependendo do documento de entrada. Evite perder informações importantes (de logotipos, cabeçalhos, rodapés, etc.) durante a extração definindo o ApplyOcrOnPDF como Sim, certificando-se de que todo o texto seja detectado, embora possa retardar o processo.

2. Definir campos

A definição de campos é uma conversa que precisa acontecer com o especialista no assunto ou o especialista no domínio, que sejam responsáveis pelo processo de negócios. Para faturas, seria o proprietário do processo de Contas a Pagar. Essa conversa é crítica, precisa acontecer antes que qualquer documento seja rotulado para evitar perda de tempo e requer avaliar juntos um mínimo de 20 amostras de documentos escolhidas aleatoriamente. Um intervalo de uma hora precisa ser reservado para isso e, muitas vezes, precisa ser repetido após alguns dias, pois a pessoa que prepara os dados se depara com situações ambíguas ou casos extremos.

Não é incomum que a conversa comece com a suposição de que você precisa extrair, digamos, 10 campos, e termina com 15. Alguns exemplos são descritos nas subseções abaixo.

Algumas configurações importantes que você precisa conhecer:

• Tipo de Conteúdo

  Esta é a configuração mais importante, pois determina o pós-processamento dos valores, especialmente para datas (detecta se o formato é estilo americano ou não americano e os formata como aaaa-mm-dd) e para números (detecta o separador decimal – vírgula ou ponto). Os números de identificação limpam qualquer coisa que venha antes de dois pontos ou símbolo de hash. O tipo de conteúdo String não realiza limpeza e pode ser usado quando você deseja fazer sua própria análise no fluxo de trabalho RPA.

• Caixa de seleção multi-linha

  Isto é para analisar strings como endereços que podem aparecer em mais de 1 linha de texto.

• Caixa de seleção de vários valores

  Isso é para lidar com campos de múltipla escolha ou outros campos que podem ter mais de um valor, mas NÃO são representados como uma coluna de tabela. Por exemplo, uma pergunta de grupo Étnica em um formulário do governo pode conter várias caixas de seleção onde você pode selecionar todas as que se aplicam.

• Campos ocultos

  Os campos marcados como Ocultos podem ser rotulados, mas são mantidos quando os dados são exportados, de modo que o modelo não pode ser treinado neles. Isso é útil quando rotular um campo é um trabalho em andamento, quando é muito raro ou quando é de baixa prioridade.

• Pontuação

  Isso é relevante apenas para pipelines de avaliação e afeta como a pontuação de precisão é calculada. Um campo que usa pontuação Levenshtein é mais permissivo: se um único caractere entre 10 estiver errado, a pontuação é 0,9. No entanto, se a pontuação for uma Correspondência Exata , é mais rigorosa: um único caractere errado leva a uma pontuação de zero. Apenas os campos do tipo String têm a opção de selecionar a pontuação Levenshtein por padrão.

Quantidades em contas de serviço público

Um valor total pode parecer bastante simples, mas as contas de serviços públicos contêm muitos valores. Às vezes, você precisa do valor total a ser pago. Outras vezes, você precisa apenas do valor da fatura atual – sem os valores acumulados de períodos de cobrança anteriores. Neste último caso, você precisa rotular de forma diferente, mesmo que a fatura atual e o valor total possam ser os mesmos. Os conceitos diferem e os valores são, muitas vezes, diferentes.

Observação: cada campo representa um conceito diferente e eles precisam ser definidos da maneira mais clara possível, para não haver confusão. Se um humano pode ficar confuso, o modelo de ML também ficará confuso.

Além disso, o valor atual da fatura, às vezes, pode ser composto de alguns valores, taxas e impostos diferentes e pode não aparecer individualizado em nenhum lugar da fatura. Uma possível solução para isso é criar dois campos: um campo de cobranças anteriores e um campo total . Esses dois sempre aparecem como valores explícitos distintos na conta de serviços públicos. Em seguida, o valor da fatura atual pode ser obtido como a diferença entre os dois. Você pode até querer incluir todos os 3 campos (cobranças anteriores, totaise cobranças atuais) para poder fazer algumas verificações de consistência nos casos em que o valor da fatura atual aparece explicitamente no documento. Assim, você pode optar de um a três campos em alguns casos.

Números de ordem de compra em faturas

Os números de pedido podem aparecer como valores únicos para uma fatura ou podem aparecer como parte da tabela de itens de linha em uma fatura, onde cada item de linha tem um número de pedido diferente. Nesse caso, pode fazer sentido ter dois campos diferentes: po-no (número de pedido) e item-po-no (número de pedido por item). Ao manter cada campo visual e conceitualmente consistente, o modelo provavelmente fará um trabalho muito melhor. No entanto, você precisa garantir que ambos estejam bem representados em seus conjuntos de dados de treinamento e avaliação.

Nome do fornecedor e nome do endereço de pagamento nas faturas

O nome da empresa geralmente aparece no topo de uma fatura ou conta de serviços públicos, mas, às vezes, pode não ser legível, pois há apenas um logotipo e o nome da empresa não está escrito explicitamente. Também pode haver algum carimbo, manuscrito ou vinco sobre o texto. Nesses casos, alguns podem rotular o nome que aparece no canto inferior direito, na seção Enviar pagamento para do recibo de pagamento de contas de serviços públicos. Esse nome é, muitas vezes, o mesmo, mas nem sempre, pois é um conceito diferente. Os pagamentos podem ser feitos para outra empresa controladora ou holding, ou outra entidade afiliada, e é visualmente diferente no documento. Isso pode levar a um desempenho pobre do modelo. Neste caso, você deve criar dois campos, vendor-name para nome do fornecedor e payment-addr-name para o destinatário do pagamento. Em seguida, você pode procurar ambos em um banco de dados de fornecedores e usar aquele que corresponde, ou usar o payment-addr-name quando o nome do fornecedor estiver ausente.

Linhas de tabelas

Há dois conceitos distintos a serem lembrados: linhas de tabela e linhas de texto. Uma linha de tabela inclui todos os valores de todos os campos de colunas que pertencem a essa linha. Às vezes, todos podem fazer parte da mesma linha de texto que atravessa a página. Outras vezes, podem estar em linhas diferentes.

Se uma linha da tabela consiste em mais de uma linha de texto, você precisa agrupar todos os valores nessa linha da tabela usando a tecla de atalho “/”. Ao fazer isso, uma caixa verde aparecerá cobrindo toda a linha da tabela. Aqui está um exemplo de uma tabela em que as duas primeiras linhas consistem em várias linhas de texto e precisam ser agrupadas usando a tecla de atalho “/”, enquanto a terceira linha é uma única linha de texto e não precisa ser agrupada.

Este é um exemplo de uma tabela em que cada linha consiste em uma única linha de texto. Você não precisa agrupá-los usando a tecla de atalho “/”, pois isso é feito implicitamente pelo Document Manager.

Identificar onde uma linha termina e outra começa durante a leitura de cima para baixo pode ser um grande desafio para os modelos de extração de ML, especialmente em documentos como formulários em que não há linhas horizontais visuais separando linhas. Dentro dos nossos pacotes de ML, há um modelo especial que é treinado para dividir as tabelas em linhas corretamente. Este modelo é treinado usando esses grupos que você rotula com as teclas “/” ou “Enter” e que são indicados pelas caixas transparentes verde.

2. Selecione um conjunto de dados bem equilibrado e representativo para treinamento

A tecnologia Machine Learning tem como principal benefício poder lidar com problemas complexos com alta diversidade. Ao estimar o tamanho de um conjunto de dados de treinamento, deve-se observar primeiro o número de campos e seus tipos e o número de idiomas. Um único modelo pode lidar com vários idiomas, com exceção de chinês/japonês/coreano. Cenários com chinês/japonês/coreano, geralmente, exigem conjuntos de dados de treinamento separados e modelos separados.

Há 3 tipos de campos:

1. Campos regulares (data, valor total)
   • Para campos regulares, você precisa de pelo menos 20 a 50 amostras de documentos por campo. Portanto, se você precisar extrair 10 campos regulares, precisará de pelo menos 200-500 amostras de documentos. Se você precisar extrair 20 campos regulares, precisará de pelo menos 400-1000 amostras de documentos. A quantidade de amostras de documentos necessárias aumenta com o número de campos. Mais campos significa que você precisa de mais amostras de documentos, cerca de 20 a 50 vezes mais.
2. Campos de coluna (preço unitário do item, quantidade do item)
   • Para campos de coluna, você precisa de pelo menos 50-200 amostras de documentos por campo de coluna, portanto, para 5 campos de coluna, com layouts limpos e simples, você pode obter bons resultados com 300 amostras de documentos. Para layouts altamente complexos e diversos, mais de 1000 amostras de documentos podem ser necessárias. Para abranger vários idiomas, você precisa de pelo menos 200 a 300 amostras de documentos por idioma, supondo que eles cubram todos os campos diferentes. Portanto, para 10 campos de cabeçalho e 4 campos de coluna com 2 idiomas, 600 amostras de documentos podem ser suficientes (400 para as colunas e cabeçalhos, mais 200 para o idioma adicional), porém, em alguns casos, 1200 ou mais amostras de documentos podem ser necessárias.
3. Campos de classificação (moeda)
   • Os campos de classificação geralmente exigem pelo menos 10 a 20 amostras de documentos de cada classe.

As diretrizes acima pressupõem que você está resolvendo um cenário de alta diversidade, como faturas ou pedidos de compra com dezenas a centenas, ou milhares de layouts. No entanto, se estiver resolvendo um cenário de baixa diversidade, como um formulário de imposto ou faturas com muito poucos layouts (menos de 5 a 10), o tamanho do conjunto de dados será determinado, de forma majoritária, pelo número de layouts. Nesse caso, você deve começar com 20 a 30 páginas por layout e adicionar mais se necessário - principalmente se as páginas forem muito densas com grande número de campos a serem extraídos. Por exemplo, criar um modelo para extrair 10 campos de 2 layouts pode exigir 60 páginas, mas se você precisar extrair 50 ou 100 campos de 2 layouts, poderá começar com 100 ou 200 páginas e adicionar mais conforme necessário para obter o resultado desejado. precisão. Nesse caso, a distinção campos regulares/campos de coluna é menos importante.

Importante: a tecnologia de ML foi projetada para lidar com cenários de alta diversidade. Usá-la para treinar modelos em cenários de baixa diversidade (1-10 layouts) requer cuidado especial para evitar modelos frágeis, sensíveis a pequenas alterações no texto OCR. Evite isso tendo alguma variabilidade deliberada nos documentos de treinamento, imprimindo e digitalizando ou fotografando-os com aplicativos de scanner no celular. As pequenas distorções ou mudanças de resolução tornam o modelo mais robusto.

Essas estimativas pressupõem que a maioria das páginas contém todos ou a maioria dos campos. Para documentos com várias páginas, porém com a maioria dos campos em uma única página, o número relevante de páginas é o número de exemplares da página na qual a maioria dos campos aparece.

Os números acima são diretrizes gerais, não requisitos rigorosos. Em geral, você pode começar com um conjunto de dados menor e continuar adicionando dados até obter uma boa precisão. Isso é especialmente útil para paralelizar o trabalho de RPA com a construção do modelo. Além disso, uma primeira versão do modelo pode ser usada para pré-rotular dados adicionais (consulte a modo de exibição Configurações e o botão Prever no Document Manager), o que pode acelerar a rotulagem de dados de treinamento adicionais.

Os modelos de Deep Learning podem generalizar

Você não precisa ter todos os layouts representados em um conjunto de treinamento. Na verdade, a maioria dos layouts em nosso fluxo de documentos de produção tem zero amostras em seu conjunto de treinamento ou uma, ou duas amostras de documentos. Isso é desejável, pois você se beneficia ao aproveitar o poder da IA para entender documentos e conseguir fazer previsões corretas em documentos que não foram vistos durante o treinamento. Muitas amostras de documentos por layout não são obrigatórias, pois a maioria dos layouts pode não estar presente ou estar presente apenas uma ou duas vezes, e o modelo ainda conseguiria prever corretamente, com base no aprendizado de outros layouts.

Treinamento em um modelo predefinido

Há três tipos principais de cenários ao treinar um modelo de ML para o Document Understanding:

• treinar um novo tipo de documento do zero usando o Pacote de ML DocumentUnderstanding no AI Center
• retreinamento sobre um modelo pronto para uso pré-treinado para otimizar a precisão
• retreinar com um modelo pronto para uso e pré-treinado para otimizar a precisão e adicionar alguns novos campos

As estimativas de tamanho do conjunto de dados para o primeiro tipo de cenário são descritas na primeira parte desta seção intitulada "Crie um conjunto de treinamento".

Para o segundo tipo de cenário, o tamanho do conjunto de dados depende de quão bem os modelos pré-treinados já funcionam em seus documentos. Se eles já funcionam muito bem, então você pode precisar de muito poucos dados de 50 a 100 páginas. Se eles falharem em vários campos importantes, você pode precisar de mais, porém um bom ponto de partida ainda seria quatro vezes menor do que se você estivesse treinando do zero.

E, finalmente, para o terceiro tipo de cenário, comece com o tamanho do conjunto de dados para o segundo cenário acima e, em seguida, aumente o conjunto de dados dependendo de quantos novos campos você possui, usando a mesma orientação do treinamento do zero: pelo menos 20 a 50 páginas por novo campo regular ou pelo menos 50-200 páginas por campo de coluna.

Em todos esses casos, todos os documentos precisam ser rotulados de forma completa, incluindo os novos campos, que o modelo predefinido não reconhece, e também o original dos campos, que o modelo predefinido reconhece.

Ocorrências de campo desiguais

Alguns campos podem aparecer em todos os documentos (por exemplo, data, número da fatura), enquanto alguns campos podem aparecer apenas em 10% das páginas (por exemplo, taxas de manuseio, desconto). Nesses casos, você precisa tomar uma decisão de negócios. Se esses campos incomuns não forem críticos para sua automação, um pequeno número de amostras de documentos (10-15) desse campo específico será suficiente, ou seja, páginas que contenham um valor para esse campo. No entanto, se esses campos forem críticos, você precisará incluir em seu conjunto de treinamento pelo menos 30 a 50 amostras de documentos desse campo para garantir a cobertura total da diversidade.

Conjuntos de dados equilibrados

No caso de faturas, se um conjunto de dados contém faturas de 100 fornecedores, mas metade do conjunto de dados consiste em faturas de um único fornecedor, esse é um conjunto de dados muito desequilibrado. Um conjunto de dados perfeitamente equilibrado exige que cada fornecedor apareça um número igual de vezes. Os conjuntos de dados não precisam ser perfeitamente equilibrados, mas você deve evitar que mais de 20% de todo o seu conjunto de dados seja proveniente de um único fornecedor. Em algum ponto, mais dados não ajudam e podem até afetar a precisão de outros fornecedores, pois o modelo se otimizará demasiadamente (ajuste em excesso) para um fornecedor.

Conjuntos de dados representativos

Os dados devem ser escolhidos para cobrir a diversidade de documentos que provavelmente serão vistos no fluxo de trabalho de produção. Por exemplo, se você recebe faturas em inglês, mas algumas delas vêm dos EUA, Índia e Austrália, provavelmente terão layout distintos, então você precisa ter certeza de ter amostras de documentos de todos os três. Isso é relevante não apenas para o treinamento do modelo em si, mas também para fins de rotulagem. Ao rotular os documentos, você pode descobrir que precisa extrair campos novos e diferentes de algumas dessas regiões, como código GSTIN da Índia ou código ABN da Austrália. Veja mais na seção Definir campos.

4. Rotule o conjunto de dados de treinamento

Ao rotular dados de treinamento, você precisa se concentrar nas caixas delimitadoras das palavras no painel de documentos do Document Manager. Os valores analisados nas barras laterais direita ou superior não são importantes, pois não são usados para treinamento.

Sempre que um campo aparecer várias vezes em uma página, desde que representem o mesmo conceito, todos eles devem ser rotulados.

Quando o OCR perder uma palavra ou errar alguns caracteres, apenas rotule a caixa delimitadora, se houver, e, se não, ignore-a e continue. Não há possibilidade de adicionar uma palavra no Document Manager, pois, mesmo que você tenha feito isso, a palavra ainda estaria ausente durante a execução, portanto, adicioná-la não ajuda em nada o modelo.

Ao rotular, fique atento aos campos que podem ter significados/conceitos múltiplos ou sobrepostos, caso você precise dividir um campo em dois campos separados ou campos dos quais não precisa explicitamente, mas que, se rotulados, podem ajudá-lo para fazer determinada lógica de verificação de validação ou autoconsistência no fluxo de trabalho de RPA. Exemplos típicos são quantidade, preço unitário e valor de linha em itens de linha de fatura. Valor de linha é o produto da quantidade e preço unitário, o que é muito útil para verificar a consistência sem a necessidade de níveis de confiança.

5. Treine o extrator

Para criar um extrator, acesse a visualização de Extratores no Document Understanding e clique no botão Criar extrator no canto superior direito. Em seguida, é possível selecionar o Tipo de documento, o Modelo de ML e a Versão que deseja usar. Você pode monitorar o progresso na guia Extratores ou na visualização Detalhes do Extrator, que contém um link para o pipeline do AI Center, onde você pode ver os logs detalhados em tempo real.

Ao avaliar um modelo de ML, a ferramenta mais poderosa é a avaliação_<package name>.xlsx gerado na pasta artefatos/eval_metrics na exibição de detalhes do pipeline do AI Center. Na primeira planilha, você pode ver um relatório detalhado de pontuações de precisão, incluindo pontuações gerais e também por campo e por lote.

Nesse arquivo do Excel, você pode visualizar quais previsões estão falhando e em quais arquivos, e também ver imediatamente se é um erro de OCR, ou um erro de extração ou análise de ML e se pode ser corrigido por lógica simples no fluxo de trabalho de RPA, ou é necessário um mecanismo de OCR diferente, mais dados de treinamento ou melhoria da rotulagem ou das configurações de campo no Document Manager.

Esse arquivo do Excel também é muito útil para identificar as regras de negócios mais relevantes que você precisa aplicar ao fluxo de trabalho de RPA para detectar erros comuns no roteamento para o Validation Station no Actions Center para revisão manual. As regras de negócios são, de longe, a maneira mais confiável de detectar erros.

Para os erros que não podem ser detectados pelas regras de negócios, você também pode usar níveis de confiança. O arquivo do Excel também contém níveis de confiança para cada previsão para que você possa usar os recursos do Excel, como classificação e filtragem, e determinar qual é um bom limite de confiança para seu cenário de negócios.

No geral, o arquivo de avaliação_<package_name>.xlsx O arquivo do Excel é um recurso importante no qual você precisa se concentrar para obter os melhores resultados de sua automação de IA.

Importante: o treinamento de GPU é altamente recomendado para conjuntos de dados grandes e de produção. O treinamento de CPU é muito mais lento e deve ser usado com moderação, para pequenos conjuntos de dados para fins de demonstração ou teste. Para mais informações, consulte a página Pipelines de treinamento.

6. Defina e implemente regras de negócios

Nesta etapa, você deve se preocupar com os erros do modelo e como detectá-los. Existem duas maneiras principais de detectar erros:

• através da aplicação de regras de negócios
• por meio da aplicação de pesquisas em Sistemas de Registro na organização do cliente
• através da aplicação de um limite mínimo de nível de confiança

A maneira mais eficaz e confiável de detectar erros é definindo regras de negócios e pesquisas. Os níveis de confiança nunca podem ser 100% perfeitos, sempre haverá uma porcentagem pequena, mas diferente de zero, de previsões corretas com baixa confiança ou previsões erradas com alta confiança. Além disso, e talvez o mais importante, um campo ausente não tem confiança, portanto, um limite de confiança nunca pode detectar erros nos quais um campo não é extraído. Consequentemente, os limites de nível de confiança devem ser usados apenas como um fallback, uma rede de segurança, mas nunca como a principal maneira de detectar erros críticos para os negócios.

Exemplos de regras de negócios:

• O valor líquido mais o valor do imposto deve ser igual ao valor total
• O valor total deve ser maior ou igual ao valor líquido
• Número da fatura, data, valor total (e outros campos) devem estar presentes
• O número de PO (se presente) deve existir no banco de dados PO
• A data de fatura deve estar no passado e não pode ter mais de X meses
• A data de vencimento deve ser no futuro e não mais de Y dias/meses
• Para cada item de linha, a quantidade multiplicada pelo preço unitário deve ser igual ao valor da linha
• A soma dos valores das linhas deve ser igual ao valor líquido ou total
• etc.

Observação: no caso de números, é realizado um arredondamento para oito casas decimais.

Em específico, os níveis de confiança dos campos de coluna quase nunca devem ser usados como um mecanismo de detecção de erros, uma vez que os campos de coluna (por exemplo, itens de linha em faturas ou ordens de compra) podem ter dezenas de valores, portanto, definir um limite mínimo para tantos valores pode ser especialmente não confiável, pois é mais do que provável que um valor tenha pouca confiança, portanto, isso levaria a maioria/todos os documentos a serem encaminhados para validação humana, muitas vezes desnecessariamente.

As regras de negócios devem ser aplicadas como parte do fluxo de trabalho de RPA, e a falha da regra de negócios é passada ao validador humano para direcionar sua atenção e acelerar o processo.

Observação: ao definir Regras de negócios, tenha em mente que os valores Inicia com, Termina com e Contém diferenciam maiúsculas e minúsculas..

7. (Opcional) Escolha um limite de confiança

Após a definição das regras de negócios, às vezes, pode haver um pequeno número de campos para os quais não há regras de negócios em vigor ou para os quais as regras de negócios provavelmente não detectarão todos os erros. Para isso, pode ser necessário usar um limite de confiança como último recurso.

A principal ferramenta para definir esse limite é a planilha do Excel, gerada pelo pipeline de treinamento na pasta Outputs > artifacts > eval_metrics .

Este arquivo de avaliação_<package name>.xlsx contém uma coluna para cada campo e uma coluna para o nível de confiança de cada previsão. Ao classificar a tabela com base nas colunas de confiança, você poderá visualizar onde os erros começam a aparecer para qualquer campo fornecido e definir um limite acima desse nível para garantir que apenas os documentos extraídos corretamente sejam enviados diretamente.

8. Ajuste fino com Dados da Estação de Validação

Os dados do Validation Station podem ajudar a melhorar as previsões do modelo, mas, muitas vezes, verifica-se que a maioria dos erros não se deve ao modelo em si, mas ao OCR, erros de rotulagem, inconsistências ou problemas de pós-processamento (por exemplo, formatação de data ou número). Portanto, o primeiro aspecto chave é que os dados do Validation Station devem ser usados somente após os outros Componentes de Extração de Dados terem sido verificados e otimizados para garantir uma boa precisão, e a única área restante de melhoria é a própria previsão do modelo.

O segundo aspecto fundamental é que os dados do Validação Station têm uma densidade de informações menor do que os dados rotulados no Document Manager. Fundamentalmente, o usuário do Validação Station só se preocupa com obter o valor certo uma vez. Se uma fatura tiver 5 páginas e o número da fatura aparecer em todas as páginas, o usuário do Validation Station a validará apenas na primeira página. Assim, 80% dos valores permanecem não rotulados. No Document Manager, todos os valores são rotulados.

Por fim, lembre-se de que os dados do Validation Station precisam ser adicionados ao conjunto de dados rotulado manualmente original para que você sempre tenha um único conjunto de dados de treinamento que aumenta de tamanho ao longo do tempo. Você sempre precisa treinar no Pacote de ML com a versão secundária 0 (zero), sendo a versão predefinida (Out of the Box) lançada pela UiPath.

Importante: muitas vezes, supõe-se erroneamente que a maneira de usar os dados da Estação de Validação é treinar iterativamente a versão do modelo anterior, de modo que o lote atual seja usado para treinar o pacote X.1 e obter X.2. Em seguida, o próximo lote treina X.2 para obter X.3, e assim por diante. Esta é a maneira errada de usar o produto. Cada lote da Estação de validação precisa ser importado para a mesma sessão do Document Manager que os dados originais rotulados manualmente, criando um conjunto de dados maior, que deve ser usado para treinar sempre na versão X.0 do Pacote de ML.

Avisos sobre o uso de dados do Validation Station

Os dados do Validation Station podem ter um volume muito maior, pois são usados no fluxo de trabalho de Production . Você não deseja que o conjunto de dados fique sobrecarregado com dados do Validation Station, pois isso pode degradar a qualidade do modelo devido ao problema de densidade de informações mencionado acima.

A recomendação é adicionar no máximo 2 a 3 vezes o número de páginas de dados do Document Manager e, além disso, selecionar apenas os fornecedores ou amostras em que você vê grandes falhas. Se houver grandes alterações conhecidas nos dados de Production , como um novo idioma ou uma nova região geográfica sendo integrada ao processo de negócios (expandindo dos EUA para a Europa ou Sul da Ásia), os dados representativos para esses idiomas e regiões devem ser adicionados. ao Document Manager para rotulagem manual. Os dados do Validation Station não são apropriados para essa grande expansão de escopo.

Um outro problema potencial com os dados do Validation Station é o balanceamento. Na Production , é comum que a maior parte do tráfego venha de um pequeno subconjunto de fornecedores/clientes/regiões do mundo. Se permitido no conjunto de treinamento como está, isso pode levar a um modelo altamente viesado, que tem um bom desempenho em um pequeno subconjunto dos dados, mas tem um desempenho ruim na maior parte dos dados restantes. Portanto, é importante ter um cuidado especial ao adicionar dados do Validation Station a um conjunto de treinamento.

Este é um cenário de amostra. Você escolheu um bom mecanismo de OCR, rotulou 500 páginas no Document Manager, resultando em um bom desempenho e implantou o modelo em um fluxo de trabalho de RPA de produção. A Estação de validação está começando a gerar dados. Você deve selecionar aleatoriamente até um máximo de 1.000 a 1.500 páginas da Estação de validação e importá-las para o Document Manager junto com as primeiras 500 páginas e treinar novamente seu modelo de ML. Depois disso, você deve examinar com muita atenção o evaluation_<package name>.xlsx para certificar-se de que o modelo realmente melhorou, e então você deve implantar o novo modelo na produção.

9. Implante sua automação

Certifique-se de usar o processo do Document Understanding Process: modelo Studio da seção Modelos na tela inicial do Studio para aplicar as práticas recomendadas na arquitetura Enterprise RPA.