Treinamento de modelos de alto desempenho

The power of Machine Learning Models is that they are defined by training data rather than by explicit logic expressed in computer code. This means that extraordinary care is needed when preparing datasets because a model is only as good as the dataset that was used to train it. In that sense, what UiPath® Studio is to RPA workflows, a Document Type session (in Document UnderstandingDocument Understanding^TM Cloud) is to Machine Learning capabilities. Both require some experience to be used effectively.

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.

When in doubt, start by training a single model, but keep the documents in different Document Manager batches (check the Filter drop-down at the top of the view) so you can easily separate them later if needed. In this way, the labeling work is not lost. When it comes to ML Models, the more data, the better. So, having a single model with ample data is a good place to start.

Conjuntos de dados de treinamento e avaliação

O Document Manager pode ser usado para criar dois tipos de conjuntos de dados: conjuntos de dados de treinamento e conjuntos de dados de avaliação.

Os conjuntos de dados de avaliação são relevantes para cientistas de dados ou para solucionar problemas detalhados para reproduzir determinados problemas. No entanto, para a grande maioria dos cenários de automação Enterprise , apenas o conjunto de dados de treinamento é necessário e recomendado. Os pipelines de treinamento agora retornam artefatos de pontuação completos, incluindo os seguintes:

• Precisão geral do modelo - é usada como a principal pontuação exibida na exibição de Detalhes do extrator do Document Understanding e na pasta de artefatos do AI Center (também acessível a partir do Document Understanding).
• Pontuação F1 geral e de nível de campo do modelo - isso é fornecido por motivos históricos na pasta de artefatos do AI Center (também acessível a partir do Document Understanding).
• Métricas detalhadas por campo e por lote, bem como a comparação de desempenho lado a lado no arquivo do Excel disponível na pasta de artefatos do AI Center (também acessível a partir do Document Understanding).

A pontuação do modelo como parte do treinamento é possível porque o conjunto de treinamento é automaticamente dividido aleatoriamente em 80%/20% entre os dados de Treinamento e Validação, e as pontuações são calculadas nos dados de Validação.

À medida que o conjunto de dados aumenta, tanto a divisão de treinamento quanto a de validação evoluem, o que significa que as pontuações não são diretamente comparáveis ao longo do tempo (que é o que um cientista de dados estaria interessado). No entanto, eles refletem o desempenho do modelo nos dados mais recentes e, portanto, são mais representativos do desempenho atual do modelo nos dados de Production atuais (que são os proprietários do processo de negócios interessados).

Com essa abordagem, você tem os seguintes benefícios:

• Você não corre o risco de olhar para pontuações medidas em dados obsoletos, potencialmente antigos.
• Você reduz a quantidade de rotulagem necessária.
• Todos os dados rotulados contribuem para a melhoria do modelo, levando a um melhor desempenho mais rapidamente.

Componentes de extração de dados

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

• Reconhecimento de caracteres óptico
• Pós-processamento de OCR
  • Compilação de Palavra e Linha
  • Agrupando caracteres em palavras e palavras em linhas de texto
• Previsão do modelo de Machine Learning para cada palavra/caixa na página
• Normalização de dados
  • Por exemplo, agrupar palavras em várias linhas em um endereço, formatar uma data no formato padrão aaaa-mm-dd
• Seleção de valor
  • Aplicando um algoritmo para selecionar qual das várias instâncias de um determinado valor é realmente retornada, 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?

When ML models make predictions, they are basically statistical guesses. The model is saying "this is probably the Total amount" of this Invoice. This begs the question: how probably? Confidence levels are an attempt to answer that question, on a scale from 0 to 1. However, they are NOT true probability estimates. They are just how confident the model is about its guesses, and therefore they depend on what the model has been trained on. A better way to think of them is as a measure of familiarity: how familiar is the model with this model input? If it resembles something the model has seen in training, then it might have a higher confidence. Otherwise it might have a lower confidence.

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.

The best way to catch bad predictions, by far, is through enforcing business rules. For example, we know that on an invoice, the net amount plus the tax amount must equal the total amount. Or that the part numbers for the components ordered must have 9 digits. When these conditions do not hold, we know something has gone wrong, and we can trigger the exception handling flow. The is the preferred and strongly recommended approach. It is worth investing significant effort in building these kinds of rules, even using complex Regular Expressions, or even lookups in databases to validate Vendor names, or part numbers, etc. In some cases you may even want to extract some other document that is not of interest but only to cross reference and validate some values to the original document of interest.

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?

Most components in the Document Understanding^TM product return a confidence level. The main components of a Document Understanding^TM workflow are Digitization, Classification and Extraction. Each of these has a certain confidence for each prediction. The Digitization and the Extraction confidence are both visually exposed in the Validation Station, so you can filter predictions and focus only on low confidence ones, to save time.

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

The confidence levels of different models will be scaled differently, depending on the model design. For example some models return confidence levels in the range 0.9-1 almost always, and only very rarely below 0.8. Other models have confidence levels spread much more evenly between 0 and 1, even if usually they are clustered at the higher end of the scale. As a result, the confidence thresholds on different models will be different. For example a confidence threshold on the OCR will not be the same as the threshold on the ML Extractor or the ML Classifier. Also, whenever there is a major architecture update on a model, like the one coming up with the release of the Helix Extractor Generative AI-based model architecture, the confidence level distribution will change, and confidence thresholds will need to be re-assessed.

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

Your default option should be UiPath Document OCR for European Latin-based languages, or UiPath Chinese-Japanese-Korean OCR. In case you need to process other languages, including Cyrillic, Devanagiri script, Thai, Vietnamese, Arabic, Hebrew or Persian, you may prefer Microsoft Azure Read OCR (Cloud only), Google Cloud Vision OCR (Cloud only) or Omnipage OCR (Activity pack in Studio). It is worth creating a few different Document Manager sessions with different OCR engines to check which performs best on your documents. Changing OCR engine later in the project can be costly.

Please be aware that the Digitize Document activity has the ApplyOcrOnPDF setting set to Auto by default, which means when operating on .pdf documents by default, Digitize tries to scrape as much text as possible from the .pdf itself, and only OCR images like logos, and combine the results.

However, .pdf documents are sometimes corrupt or unusually formatted leading to errors in the extracted text. In this case, set ApplyOCRonPDFs to Yes.

Another benefit of applying OCR on all .pdf documents using UiPath Document OCR is that UiPath Document OCR recognizes checkboxes which are critical elements of documents like forms. Be aware however that applying OCR on everything will slow down the Digitization a bit.

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.

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

• Content type This is the most important setting as it determines the postprocessing of the values, especially for dates (detects if the format is US-style or non-US style, and then formats them as yyyy-mm-dd) and for numbers (detects the decimal separator – comma or period). ID numbers clean up anything coming before a colon or hash symbol. String content type performs no cleanup and can be used when you want to do your own parsing in the RPA workflow.
• Multi-line checkbox This is for parsing strings like addresses that may appear on more than 1 line of text.
• Multi-valued checkbox This is for handling multiple choice fields or other fields which may have more than one value, but are NOT represented as a table column. For example, an Ethnic group question on a government form may contain multiple checkboxes where you can select all that apply.
• Hidden fields Fields marked as Hidden can be labelled but they are held out when data is exported, so the model cannot be trained on them. This is handy when labeling a field is a work in progress, when it is too rare, or when it is low priority.
• Scoring This is relevant only for Evaluation pipelines, and it affects how the accuracy score is calculated. A field that uses Levenshtein scoring is more permissive: if a single character out of 10 is wrong, the score is 0.9. However, if scoring is Exact Match it is more strict: a single wrong character leads to a score of zero. Only String type fields have the option to select Levenshtein scoring by default.

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:

Each field represents a different concept, and they need to be defined as cleanly as possible, so there is no confusion. If a human might be confused, the ML model will also be confused.

Moreover, the current bill amount can sometimes be composed of a few different amounts, fees, and taxes and may not appear individualized anywhere on the bill. A possible solution to this is to create two fields: a previous-charges field, and a total field. These two always appear as distinct explicit values on the utility bill. Then the current bill amount can be obtained as the difference between the two. You might even want to include all 3 fields (previous-charges, total, and current-charges) in order to be able to do some consistency checks in cases where the current bill amount appears explicitly on the document. So you could go from one to three fields in some cases.

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

The company name usually appears at the top of an invoice or a utility bill, but sometimes it might not be readable because there is just a logo, and the company name is not explicitly written out. There could also be some stamp, or handwriting, or wrinkle over the text. In these cases, people might label the name that appears at the bottom right, in the Remit payment to section of the payslip on utility bills. That name is often the same, but not always, since it is a different concept. Payments can be made to some other parent or holding company, or other affiliate entity, and it is visually different on the document. This might lead to poor model performance. In this case, you should create two fields, vendor-name and payment-addr-name. Then you can look both up in a vendor database and use the one that matches, or use payment-addr-name when the vendor-name is missing.

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.

3. Criar um conjunto de dados de treinamento

Machine Learning technology has the main benefit of being able to handle complex problems with high diversity. When estimating the size of a training dataset, one looks first at the number of fields and their types, and the number of languages. A single model can handle multiple languages as long as they are not Chinese/Japanese/Korean. The later scenarios generally require separate Training datasets and separate models.

Há 3 tipos de campos:

1. Regular fields (date, total amount) For Regular fields, you need at least 20-50 document samples per field. So, if you need to extract 10 regular fields, you need at least 200-500 samples. If you need to extract 20 regular fields, you need at least 400-1000 samples. The amount of samples you need increases with the number of fields. More fields means you need more samples, about 20-50X more.

2. Column fields (item unit price, item quantity)

   Para campos de coluna, você precisa de pelo menos 50-200 amostras de documentos por campo de coluna, portanto, para campos de 5 colunas, com layouts limpos e simples, você pode obter bons resultados com 300 amostras de documentos, mas para layouts altamente complexos e diversos, pode exigir mais 1.000. Para abranger vários idiomas, você precisa de pelo menos 200 a 300 amostras por idioma, supondo que cubram todos os campos diferentes. Portanto, para 10 campos de cabeçalho e 4 campos de coluna com 2 idiomas, 600 amostras podem ser suficientes (400 para as colunas e cabeçalhos mais 200 para o idioma adicional), mas alguns casos podem exigir 1200 ou mais.

3. Classification fields (currency) Classification fields generally require at least 10-20 samples from each class.

O intervalo recomendado para o tamanho do conjunto de dados é baseado nas informações fornecidas na guia Calculadora. Para cenários mais simples com poucos campos regulares e layouts de documentos claros, é possível obter bons resultados com conjuntos de dados no intervalo baixo laranja. Para cenários complexos, principalmente envolvendo tabelas complexas com muitas colunas, bons resultados podem exigir conjuntos de dados no intervalo alto laranja, ou até mesmo verde.

Importante:

A tecnologia 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.

Além disso, essas estimativas pressupõem que a maioria das páginas contém todos ou a maioria dos campos. Nos casos em que você possui documentos com várias páginas, mas a maioria dos campos está em uma única página, o número relevante de páginas é o número de exemplos daquela página em que 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, é possível que a maioria dos layouts em nosso fluxo de documentos de produção tenha zero amostras em seu conjunto de treinamento, ou talvez 1 ou 2 amostras. Isso é desejável, pois você deseja aproveitar o poder da IA para entender os documentos e ser capaz de fazer previsões corretas sobre documentos que não viu durante o treinamento. Um grande número de amostras por layout não é obrigatório, pois a maioria dos layouts pode não estar presente ou estar presente apenas 1 ou 2 vezes, e o modelo ainda seria capaz de prever corretamente, com base no aprendizado de outros layouts.

Treinamento em um modelo predefinido

Uma situação comum é extrair dados de Faturas, para as quais temos um modelo predefinido pré-treinado, mas, além disso, você tem mais 2 campos Regulares e mais 1 campo Coluna que o modelo de Faturas pré-treinado não reconhece. Nesse caso, você geralmente precisará de um conjunto de dados muito menor do que se tivesse treinado todos os campos do zero. A estimativa do tamanho do conjunto de dados é fornecida ao criar um Tipo de Documento no Document Understanding Cloud e é então acessível na visualização do Diagnóstico do Conjunto de Dados. No entanto, lembre-se de que quaisquer documentos que você use para treinar um modelo devem ser rotulados completamente, incluindo os novos campos, que o modelo predefinido não reconhece, e também o original dos campos, que o robô o modelo pré-configurado reconhece.

Ocorrências de campo desiguais

Alguns campos podem existir em todos os documentos (por exemplo, data, número da fatura), enquanto alguns campos podem aparecer apenas em 10% dos documentos (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 (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 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 apenas 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é degradar 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 aparência diferente, então você precisa ter certeza de ter amostras de documentos de todos as três. Isso é relevante não apenas para o treinamento do modelo em si, mas também para fins de rotulagem porque, 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 de Austrália.

Divisão de treinamento/validação

Qualquer conjunto de dados de treinamento é dividido automaticamente nos bastidores em um conjunto de treinamento (selecionado aleatoriamente em 80%) e um conjunto de validação (selecionado aleatoriamente em 20%). Durante o treinamento de modelos de aprendizagem profunda, o conjunto de treinamento é usado para backpropagation, a parte que modifica os pesos dos nós na rede, enquanto o conjunto de validação é usado apenas para saber quando interromper o treinamento. Em outras palavras, é usada para evitar o sobreajuste ao conjunto de treinamento.

É assim que podemos obter pontuações de avaliação completas no final de qualquer execução de treinamento: retornamos as pontuações no conjunto de Validação. Este conjunto não é tecnicamente usado para treinar a rede, apenas para evitar o sobreajuste. No entanto, como é selecionado aleatoriamente 20% de todo o conjunto de dados, ele costuma ser distribuído de forma semelhante para o conjunto de treinamento. Essa consistência é boa, porque significa que as pontuações obtidas refletem a capacidade do modelo de aprender com os dados, que geralmente nos preocupamos. Se um modelo não consegue aprender, isso significa que os dados são inconsistentes ou que o modelo tem uma limitação, e essas são coisas críticas que precisamos saber imediatamente ao treinar um modelo.

A desvantagem dessa abordagem é que as pontuações não podem necessariamente ser comparadas exatamente com uma maçã à medida que o conjunto de dados cresce, e também que as pontuações não refletem a capacidade do modelo de generalizar – apenas sua capacidade de aprender. No entanto, as comparações de maiúsculas e minúsculas e medir a capacidade de generalizar são preocupações técnicas da ciência de dados, que têm apenas um impacto indireto no desempenho dos negócios ou no ROI para a maioria das automações.

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.

As you label, remain vigilant about fields that may have multiple or overlapping meanings/concepts, in case you might need to split a field into two separate fields, or fields that you do not explicitly need, but which, if labelled, might help you to do certain validation or self-consistency check logic in the RPA workflow. Typical examples are quantity,unit-price, and line-amount on invoice line items. Line-amount is the product of quantity and unit-price, but this is very useful to check for consistency without the need for confidence levels.

5. Treine o extrator

To create an extractor, go to the Extractors view in Document Understanding and select the Create Extractor button at the top right. You can then select the Document Type, the ML Model and Version you would like to use. You can monitor the progress on the Extractors tab, or in the Details view of the Extractor, which contains a link to the AI Center pipeline, where you can check the detailed logs in real time.

When evaluating an ML model, the most powerful tool is the evaluation_<package name>.xlsx file generated in the artifacts/eval_metrics folder in AI Center pipeline details view. On the first sheet you can check a detailed Accuracy scores report, including overall scores, and also per field and per batch.

Nesse arquivo do Excel, você pode verificar quais previsões estão falhando e em quais arquivos, e você pode observar imediatamente se é um erro de OCR ou um erro de extração de ML ou de análise de dados e se ele pode ser corrigido por lógica simples no fluxo de trabalho de RPA ou requer um mecanismo de OCR diferente, mais dados de treinamento ou ajustes na rotulagem ou nas configurações de campos 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.

Overall, the evaluation_<package_name>.xlsx Excel file is a key resource you need to focus on to get the best results from your AI automation.

Importante:

GPU training is highly recommended for large and production datasets. CPU training is much slower and should be used sparingly, for small datasets for demo or testing purposes. For more information, check the Training Pipelines page.

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
• through applying lookups in Systems of Record in the customer organization
• 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:

  In case of numbers, a rounding to eight decimals is performed.

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:

When defining Business Rules, please keep in mind that the Starts with, Ends with, and Contains values are case sensitive.

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.

The main tool to set this threshold is the Excel spreadsheet which is output by the Training pipeline in the Outputs > artifacts > eval_metrics folder.

This evaluation_<package name>.xlsx file contains a column for each field, and a column for the confidence level of each prediction. By sorting the table based on the confidence columns you may check where the errors start appearing for any given field and set a threshold above that level to ensure that only correctly extracted documents are sent straight through.

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

Validation Station data can help improve the model predictions, yet, in many cases, it turns out that most errors are NOT due to the model itself but to the OCR, labelling errors or inconsistencies, or to postprocessing issues (e.g., date or number formatting). So, the first key aspect is that Validation Station data should be used only after the other Data extraction components have been verified and optimized to ensure good accuracy, and the only remaining area of improvement is the model prediction itself.

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:

It is often wrongly assumed that the way to use Validation Station data is to iteratively train the previous model version, so the current batch is used to train package X.1 to obtain X.2. Then the next batch trains on X.2 to obtain X.3 and so on. This is the wrong way to use the product. Each Validation Station batch needs to be imported into the same Document Manager session as the original manually labeled data making a larger dataset, which must be used to train always on the X.0 ML Package version.

Avisos sobre o uso de dados do Validation Station

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

A recomendação é adicionar no máximo 2-3 vezes o número de páginas de dados do Document Manager e, além disso, escolher apenas os fornecedores ou amostras onde você observa falhas graves. Se houver alterações importantes conhecidas nos dados de produção, 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), dados representativos para esses idiomas e regiões devem ser adicionados ao Document Manager para rotulagem manual. dados de idioma ou região geográfica sendo adicionados ao processo de negócios (expansão dos EUA para a Europa ou Os dados da Estação de validação não são apropriados para essa expansão de escopo importante.

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.

Here is a sample scenario. You have chosen a good OCR engine, labeled 500 pages in Document Manager, resulting in good performance, and you have deployed the model in a production RPA workflow. Validation Station is starting to generate data. You should randomly select up to a maximum of 1000-1500 pages from Validation Station and import them into the Document Manager together with the first 500 pages and train your ML model again. After that, you should look very carefully at the evaluation_<package name>.xlsx to make sure the model actually improved, and then you should deploy the new model to production.

9. Implante sua automação

Make sure to use the Document Understanding Process template from the Templates section in the Studio start screen in order to apply best practices in Enterprise RPA architecture.