- Introdução
- Componentes do framework
- Pacotes de ML
- Pipelines
- Gerenciador de Dados
- Serviços de OCR
- Document Understanding implantado no Automation Suite
- Document Understanding implantado no AI Center autônomo
- Aprendizagem profunda
- Treinamento de modelos de alto desempenho
- Licenciamento
- Referências
- UiPath.Abbyy.Activities
- UiPath.AbbyyEmbedded.Activities
- UiPath.DocumentUnderstanding.ML.Activities
- UiPath.DocumentUnderstanding.OCR.LocalServer.Activities
- UiPath.IntelligentOCR.Activities
- UiPath.OCR.Activities
- UiPath.OCR.Contracts
- UiPath.DocumentProcessing.Contracts
- UiPath.OmniPage.Activities
- UiPath.PDF.Activities
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
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 extraordinário 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, o Data Manager representa para os recursos de Machine Learning. Ambos requerem certa experiência para serem usados de forma eficaz.
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 ficar confuso sobre o valor correto de um campo, um modelo de ML também ficará.
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), isso pode indicar que você precisará tratá-los como dois tipos de documentos distintos e, portanto, treinar dois modelos diferentes.
Sempre que tiver dúvidas, comece treinando um único modelo, mas mantenha os documentos em lotes diferentes do Data Manager (consulte o menu suspenso Filtro no centro superior do modo de exibição do Data Manager) 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.
O Data Manager pode ser usado para criar dois tipos de conjuntos de dados: conjuntos de dados de treinamento e conjuntos de dados de avaliação. Ambos são essenciais para a construção de um modelo de ML de alto desempenho e você precisa orçar tempo e esforço para criar e manter ambos. Você não pode obter um modelo de ML de alto desempenho sem um conjunto de dados de avaliação representativo do tráfego de documentos de produção.
Cada tipo de conjunto de dados é rotulado de uma maneira diferente:
- Os conjuntos de dados de treinamento contam apenas com as 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 somente na própria página e nas caixas de palavras.
- Os conjuntos de dados de avaliação contam apenas com os campos que aparecem na barra lateral (para campos Regulares) ou na barra superior (para campos Colunas).
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ê precise digitá-los manualmente, pois isso é propenso a erros tipográficos, portanto ainda é recomendável rotular clicando nas caixas da página, mas certifique-se de verificar se os valores estão corretos.
Mais detalhes sobre como conduzir Avaliações adequadas podem ser encontrados abaixo.
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 2 ou mais páginas e alguns campos aparecem em mais de uma página
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:
Para escolher um mecanismo de OCR, você deve criar diferentes sessões do Data Manager, configurar diferentes mecanismos de OCR e tentar importar os mesmos arquivos para cada um deles para examinar as diferenças. Você deve se concentrar nas áreas que pretende 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 – o que economizará seu tempo mais tarde, pois todo o downstream depende disso.
Esteja ciente de que a atividade Digitize Document tem a configuração ForceApplyOCR definida como False por padrão, o que significa ao ser executada em documentos .pdf, por padrão, o mecanismo de OCR não é usado, o texto é extraído diretamente do documento .pdf no caso de documentos .pdf nativos. No entanto, muitos arquivos .pdf nativos pode conter logotipos ou mesmo cabeçalhos ou rodapés que não são capturados. Tais campos podem conter informações de identificação da empresa, como o seu nome, endereço, código de IVA ou informação de pagamento, sendo esta de grande relevância nos processos empresariais. Se o seu processo tiver que lidar com essa situação, defina ForçarAplicaçãoDeOCR para True garantir que todo o texto seja detectado, embora isso possa causar lentidão.
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 CJK (chinês/japonês/coreano), geralmente, exigirão conjuntos de dados de treinamento separados e modelos separados.
Há 3 tipos de campos:
- Campos regulares (data, valor total) Para campos regulares, você precisa de pelo menos 20 a 50 amostras por campo. Portanto, se você precisar extrair 10 campos regulares, precisará de pelo menos 200 a 500 amostras. Se você quiser extrair 20 campos regulares, precisaria de pelo menos 400-1000 amostras de documentos. A quantidade de amostras que você precisa aumenta com o número de campos. Mais campos significa que você precisa de mais amostras, cerca de 20 a 50 vezes mais.
- Campos de coluna (preço unitário do item, quantidade do item) Para campos de coluna, você precisa de pelo menos 50 a 200 amostras por campo de coluna, portanto, para campos de 5 colunas, com layouts limpos e simples, você pode obter bons resultados com 300 amostras, mas para layouts altamente complexos e diversos, mais de 1000 podem ser necessárias. 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 em alguns casos podem exigir 1200 ou mais.
- Campos de classificação (moeda) Os campos de classificação geralmente requerem pelo menos 10-20 amostras 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.
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 seção Configurações e o botão Prever no Data 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, mas você também tem mais 2 campos Regulares e mais 1 campo Coluna que o modelo de Faturas predefinido não reconhece. Nesse caso, você precisa de um conjunto de treinamento com 50 amostras por novo campo Regular e um mínimo de 100 amostras por novo campo de Coluna. Então, 200 páginas é um bom começo. Este é geralmente um conjunto de dados muito menor do que se você tivesse treinado todos os campos do zero.
Essas 200 páginas precisam ser rotuladas completamente, incluindo os novos campos, que o modelo pré-configurado não reconhece, e também o original dos campos, que 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% 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 (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é 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 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. Veja mais na seção Definir campos.
Por outro lado, quando nos referimos aos conjuntos de treinamento as páginas e o número de páginas são o mais importante, no caso dos conjuntos de avaliação, nos referimos apenas aos documentos e ao número de documentos. As pontuações para as versões v2021.10 e posteriores são calculadas por documento.
Os conjuntos de dados de avaliação podem ser menores. Eles podem ser de 50 a 100 documentos (ou mesmo apenas 30 a 50 em cenários de baixa diversidade) e podem aumentar ao longo do tempo para algumas centenas de documentos. É importante que eles sejam representativos do fluxo de dados de produção. Portanto, uma boa abordagem é selecionar aleatoriamente entre os documentos processados no fluxo de trabalho da RPA. Mesmo que alguns fornecedores sejam super-representados, não há problema. Por exemplo, se um único fornecedor representa 20% do seu tráfego de faturas, não há problema se esse fornecedor também represente 20% do seu conjunto de avaliação, pois as métricas de avaliação se aproximam da sua métrica de negócios, ou seja, redução de pessoas-mês gastas no processamento manual de documentos.
Ao importar dados de avaliação para o Data Manager, você precisa certificar-se de marcar a caixa “Tornar este um conjunto de avaliação” na janela de diálogo Importar. Dessa forma, você garante que os dados sejam mantidos durante o treinamento e também pode exportá-los facilmente para a execução de Avaliações usando a opção de conjunto de avaliação no menu suspenso Filtro no Data Manager.
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.
- 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 serão 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 será 0,9. No entanto, se marcar Correspondência exata, será mais rigoroso: um único caractere errado levará a uma pontuação de zero. Todos os campos são, por padrão, Correspondência Exata. Apenas os campos do tipo String têm a opção de selecionar a pontuação Levenshtein.
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, precisa apenas do valor da fatura atual – sem os valores transportados 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.
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, totais e 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. Ou pode haver algum outro carimbo ou manuscrito ou ruga 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ê deveria criar 2 campos, nome-do-fornecedor e endereço-de-pagamento. Em seguida, você pode procurar ambos em um banco de dados de fornecedores e usar aquele que corresponde, ou apenas usar o endereço-de-pagamento 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 2 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 Data Manager.
Dividir itens
Split Items (dividir itens) é uma configuração que aparece apenas para campos de Coluna e ajuda o modelo a saber quando um item de linha termina e outro começa. Como um humano olhando para um documento, para saber quantas linhas existem, você provavelmente olha quantos valores existem no lado direito. Cada valor refere-se a um item de linha em geral. Isso é uma indicação de que o valor da linha é uma coluna na qual você deve habilitar Dividir itens. Outras colunas também podem ser marcadas, caso o OCR perca o valor da linha ou o modelo não o reconheça: quantidade e preço unitário geralmente também são marcados como 'Dividir itens'.
A configuração mais importante é o Tipo de Conteúdo, com exceção de String:
- Número
- Data
- Telefone
- Número de ID
Isso afeta o pós-processamento, especialmente a limpeza, a análise e a formatação. A mais complexa é a formatação de data, mas a formatação de número também requer a determinação do separador de ponto decimal e do decorador de milhares. Em alguns casos, se a análise falhar, sua opção é relatar o problema ao suporte da UiPath e retornar ao tipo de conteúdo String, que não faz análise. Nesse caso, você precisaria analisar o valor em sua lógica de fluxo de trabalho de RPA.
Outra configuração relevante é a caixa de seleção Linhas múltiplas, relevante principalmente para campos do tipo String. Sempre que algum outro campo produz resultados inesperados ou nenhum resultado, a primeira coisa a tentar é alterá-lo para o campo String Multi-line para verificar a saída inalterada da previsão do modelo.
Ao rotular dados de treinamento, você precisa se concentrar nas caixas delimitadoras das palavras no painel de documentos do Data 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 (consulte a seção Definir campos acima), todos 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 Data Manager porque, mesmo que você o fizesse, a palavra ainda estaria faltando no tempo de execução, portanto, adicioná-la não ajudaria 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 você potencialmente 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.
Ao rotular conjuntos de dados de avaliação (também chamados de conjuntos de dados de teste), você precisa se concentrar em algo um pouco diferente do que rotular conjuntos de dados de treinamento. Enquanto para conjuntos de dados de treinamento apenas as caixas delimitadoras dos campos no documento importam, para conjuntos de dados de avaliação apenas os valores dos campos importam. Você pode editá-los clicando no valor na barra lateral direita ou superior e editando-o. Para retornar ao valor analisado automaticamente, clique no ícone de cadeado.
A exportação de todo o conjunto de dados, incluindo lotes de treinamento e teste, é permitida porque os pipelines de treinamento no AI Center ignoram os dados de teste. No entanto, os pipelines de avaliação irão executar a avaliação em todo o conjunto de dados de avaliação, independentemente de ser composto de dados de treinamento ou teste. O tipo de um determinado documento é exibido logo abaixo do nome do arquivo, na parte superior central da janela do Data Manager.
Ao avaliar um modelo de ML, a ferramenta mais poderosa é o arquivo assessment.xlsx gerado na pasta artefatos/eval_metrics. 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 uma extração de ML ou um erro de análise e se 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 melhoria da rotulagem ou das configurações de campo no Data 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 Action 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 do Excel assessment.xlsx é um recurso importante no qual você precisa se concentrar para obter os melhores resultados de sua automação de IA.
Nesta etapa, você deve se preocupar com os erros do modelo e como detectá-los. Há 2 maneiras principais de detectar erros:
- através da aplicação de regras de negócios
- 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. 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 de fatura, Data, Valor total (e potencialmente 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.
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 do RPA e seria ideal se a falha da regra de negócios fosse passada para a validação manual para direcionar sua atenção e agilizar o processo.
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 é o recurso de pipeline de avaliação no AI Center e, especificamente, a planilha do Excel gerada pelo pipeline de avaliação na pasta Outputs > artifacts > eval_metrics.
Esta planilha contém uma coluna para cada campo e uma coluna para o nível de confiança de cada previsão. Você pode adicionar uma coluna chamada min_confidence que leva o mínimo de todas as confidências sobre todos os campos que são importantes para o seu processo de negócios e ainda não são cobertos por regras de negócios. Por exemplo, talvez você não queira colocar um limite nas confianças dos itens de linha, mas sim no nome do fornecedor, valor total, data, data de vencimento, número da fatura e outros campos essenciais. Ao classificar a tabela com base na coluna min_confidence, você poderá visualizar onde os erros começam a aparecer e definir um limite acima desse nível para garantir que apenas os documentos extraídos corretamente sejam enviados diretamente.
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 da Estação de Validação 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 da Estação de validação têm uma densidade de informações menor do que os dados rotulados no Data 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 Data 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 precisará treinar no pacote de ML com a versão secundária 0 (zero), que é a versão pré-configurada lançada pela UiPath.
Os dados do Validation Station podem ter um volume muito maior, pois são usados no fluxo de trabalho de produção. Como consequência, você precisa de uma diretriz sobre a quantidade de dados que provavelmente será útil, já que o treinamento do modelo requer tempo e infraestrutura. Além disso, 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 Data 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 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), os dados representativos para esses idiomas e regiões devem ser adicionados ao Data Manager para rotulagem manual. Os dados do Validation Station não são apropriados para essa grande expansão de escopo.
Este é um cenário de amostra. Você escolheu um bom mecanismo de OCR, rotulado como 500 páginas no Data Manager, resultando em bom desempenho e implantou o modelo em um fluxo de trabalho de RPA de produção. O Validation Station está começando a gerar dados. Você deve selecionar aleatoriamente até um máximo de 1.000 a 1.500 páginas do Validation Station e importá-las para o Data Manager com as primeiras 500 páginas e treinar novamente seu modelo de ML. Depois disso, você deve executar um pipeline de avaliação para garantir que o modelo realmente melhorou e, em seguida, deve implantar o novo modelo em produção.
O loop de ajuste fino automático é um recurso de Visualização que se torna útil para manter um modelo de alta performance que você já criou usando as etapas descritas acima. Para garantir que o ajuste fino automático produza versões melhores do modelo, é essencial que você tenha um bom conjunto de dados de avaliação e use um pipeline completo reprogramado automaticamente que execute o treinamento e a avaliação ao mesmo tempo. Dessa forma, você pode ver se o treinamento mais recente produziu um modelo mais preciso do que o anterior e, em caso afirmativo, está pronto para implantar o novo modelo na Habilidade de ML invocada pelos Robôs em seu processo de negócios.
O AI Center oferece a possibilidade de atualizar automaticamente a Habilidade de ML quando uma nova versão de um Pacote de ML é treinada novamente. No entanto, essa atualização automática não leva em consideração a pontuação do pipeline completo e, portanto, não é recomendável usar esse recurso com os pipelines de retreinamento automático do Document Understanding.
Conforme mencionado acima na seção Crie um conjunto de dados de avaliação, as implementações de pipeline de avaliação para pacotes de ML versão 21.10 ou posterior calculam pontuações por documento - o que reflete com precisão os resultados que você vê em um fluxo de trabalho de RPA. Isso pressupõe que seu conjunto de dados foi rotulado por documento no Data Manager. É possível saber se um documento de várias páginas é rotulado por documento se você puder rolar naturalmente pelas páginas, como em um leitor de PDF comum. Se for necessário clicar em próximo para passar de uma página para a próxima, cada página será considerada um documento separado.
Certifique-se de usar o Document Understanding Process da seção Modelos na tela inicial do Studio para aplicar as práticas recomendadas na arquitetura Enterprise RPA.
- O que um modelo de ML de extração de dados pode fazer?
- Conjuntos de dados de treinamento e avaliação
- Componentes de extração de dados
- Crie um modelo de ML de alto desempenho
- 1. Escolha o mecanismo de OCR
- 2. Crie um conjunto de dados de treinamento
- 3. Crie um conjunto de dados de avaliação
- 4. Defina campos
- 5. Configure os campos
- 6. Rotule o conjunto de dados de treinamento
- 7. Rotule o conjunto de dados de avaliação
- 8. Treine e avalie o modelo
- 9. Defina e implemente regras de negócios
- 10. (Opcional) Escolha um limite de confiança
- 11. Treinamento usando dados do Validation Station
- 12. O Loop de ajuste automático (Pré-visualização)
- 13. Implante sua automação