Inteligência de documentos evoluída: construindo e avaliando soluções KIE que escalam

TL;DR

• Este artigo apresenta uma abordagem de ponta a ponta para construir e avaliar uma solução KIE (extração de informações-chave) usando modelos Amazon Nova através do Amazon Bedrock.
• Abrange três fases: preparação de dados, desenvolvimento da solução e medição de desempenho, com um estudo de caso prático baseado no conjunto de dados de faturas FATURA.
• É enfatizada uma estratégia de prompts independentes de modelo, incluindo templates com Jinja2 e o uso da API Converse do Bedrock para interação unificada com modelos.
• A avaliação combina precisão com valor de negócio, usando F1-score e levando em consideração latência e custo por documento.

Contexto e antecedentes

A Inteligência de Documentos (IDP) refere-se à extração, classificação e processamento automáticos de dados de documentos em vários formatos, estruturados ou não estruturados. Dentro da IDP, a Extração de Informações-chave (KIE) permite que sistemas identifiquem e extraiam dados críticos com intervenção humana mínima. Organizações de setores como serviços financeiros, saúde, jurídico e cadeia de suprimentos vêm aumentando a adoção de IDP para reduzir entrada manual de dados e acelerar processos de negócio. Com o aumento do volume de documentos, soluções IDP vão além da automação; elas viabilizam fluxos de trabalho agentivos, nos quais sistemas de IA podem analisar dados extraídos e realizar ações com intervenção humana reduzida. A capacidade de processar com precisão faturas, contratos, prontuários médicos e documentos regulatórios tornou-se uma necessidade de negócios, não apenas uma vantagem competitiva. Desenvolver soluções IDP eficazes requer não apenas capacidades de extração robustas, mas também marcos de avaliação adaptados às necessidades da indústria e aos casos de uso organizacionais. Este post demonstra uma abordagem de ponta a ponta para construir e avaliar uma solução KIE usando modelos Nova disponíveis no Amazon Bedrock, com três fases: preparação de dados (entender e preparar seus documentos), desenvolvimento da solução (implementando a lógica de extração com modelos apropriados) e avaliação de desempenho (avaliando precisão, eficiência e custo-benefício). O conjunto de dados FATURA é utilizado como proxy realista para dados empresariais, fornecendo cenários de processamento de documentos realistas e uma ground truth confiável para avaliação. O post também discute como selecionar, implementar e avaliar modelos de base para tarefas de processamento de documentos, equilibrando precisão de extração, velocidade de processamento e custos. Está voltado para cientistas de dados, desenvolvedores e analistas de negócio que desejam entender as possibilidades de automação. O conjunto FATURA contém 10.000 faturas com 50 layouts distintos; para a avaliação, foram amostradas 40 amostras de 49 layouts, totalizando 1.960 amostras com anotações de 24 campos por documento. Observou-se que a distribuição de campos é desigual, com ocorrências variando de aproximadamente 250 a 1.800 para 18 campos diferentes. Esse viés reflete a natureza real de documentos onde nem todos os campos aparecem em cada documento, destacando o desafio de lidar com campos ausentes. Desafios adicionais incluem lidar com múltiplos valores para um único campo, representar informações ausentes de diferentes formas (vazios, N/A, traços) e gerir campos que podem conter texto estruturado ou não estruturado (endereços) ou hierarquias de valor (por exemplo, impostos dependentes de subtotais). A Bedrock pode simplificar o processamento de documentos ao fornecer acesso a LLMs para extração de informações estruturadas sem sistemas baseados em regras complexos. A API Converse facilita a experimentação entre diferentes modelos para tarefas de extração. Para invocar modelos através da Converse API, os parâmetros necessários incluem model_id e as mensagens contendo prompts e contexto. O artigo também destaca o uso de estruturas de entrada unificadas para suportar modalidades de entrada variadas (texto, imagem ou multimodal) sem exigir lógica separada para cada caso. A estratégia de prompt usa frameworks de templating como Jinja2, mantendo um único formato de prompt adaptável a diferentes cenários de extração. A aplicação prática envolve carregar o template com LangChain PromptTemplate, inserir dados específicos do documento (OCR, descrições de campos) e gerar o prompt final.

O que há de novo

• Fluxo de KIE de ponta a ponta com modelos de base da Bedrock (família Nova) via Converse API. A Converse API oferece interface unificada para interagir com modelos de base, simplificando experimentação e comparação entre modelos para tarefas de extração de documentos.
• Abordagem de prompting independente de modelo com templates, permitindo manter um único código de prompt entre modelos diferentes, com lógica baseada em regras incorporada quando necessário.
• Tratamento de desafios de dados do mundo real: campos ausentes, múltiplos valores, textos com formatos variados e hierarquias de valor (por exemplo, impostos dependentes de subtotais).
• Suporte a múltiplas modalidades de entrada (texto, imagem ou multimodal) com uma estrutura de entrada única que facilita o processamento de documentos com várias fontes de informação.
• Preparação de dados e padronização de ground truth para avaliação justa, incluindo normalização de prefixos e formatos de campo para alinhar com a saída esperada pelo modelo.
• Uso de templates Jinja2 carregados via LangChain PromptTemplate para popular prompts com dados específicos do documento, incluindo OCR e descrições de campos.
• Avaliação de desempenho com F1-score, equilibrando precisão e recall, e incluindo considerações práticas de latência e custo por documento.

Por que é relevante (impacto para desenvolvedores/empresas)

Para desenvolvedores e cientistas de dados, o guia esclarece como experimentar com modelos de base para processamento de documentos em um formato independente de modelo, reduzindo a dependência de regras manuais. A API Converse simplifica a interação com modelos, permitindo ciclos mais rápidos de experimentação e comparação de qualidade de extração, velocidade e custo. Para empresas, o estudo oferece um modelo para avaliar soluções KIE com metas de negócio em mente. Ao incorporar um conjunto de dados realista como o FATURA e enfatizar métricas que refletem valor operacional (precisão, recall, F1, latência e custo por documento), as organizações podem escolher modelos e configurações que equilibrem a acurácia com a capacidade de processamento e o orçamento. A ênfase em lidar com dados ausentes, campos com múltiplos valores e modalidades de entrada reflete cenários reais onde a qualidade dos dados varia entre documentos e layouts. O resultado é um caminho para processamento de documentos escalável, preciso e com custo controlado que se alinha a fluxos de trabalho automatizados. AWS ML Blog

Detalhes técnicos ou Implementação

A implementação segue um pipeline de três fases e um conjunto de técnicas práticas para soluções KIE escaláveis:

• Preparação de dados e normalização da ground truth: o FATURA compreende 10.000 faturas em 50 layouts com 24 campos por documento. Para avaliação justa, houve normalização para eliminar variações de prefixos e representações de campo. Uma amostra de 40 documentos de 49 layouts resultou em 1.960 amostras, com distribuição de campos desigual (18 campos; variação de ocorrências de ~250 a ~1.800).
• Interação com modelos via Converse API: a API oferece interface unificada para invocar modelos de base, removendo a complexidade de formatação específica de cada modelo e permitindo comparar rapidamente diferentes abordagens de extração.
• Promoções e templating: prompts consistentes são criados com templating (Jinja2) para incorporar regras e conteúdo de domínio. A configuração é alimentada por LangChain PromptTemplate, que carrega o template Jinja2 e substitui variáveis com OCR e descrições de campos para gerar o prompt final.
• Tratamento de multimodalidade: os fluxos aceitam entradas de texto, imagem ou multimodal em uma única solicitação, concatenando in forma de array de conteúdo contendo entradas de imagem codificadas e o prompt de texto.
• Processamento de imagem: a função image_to_bytes converte a imagem do documento para o formato aceitável pelo modelo, com ajustes de redimensionamento conforme necessário para desempenho ideal.
• Estrutura de avaliação: a comparação entre extração e ground truth usa classificações de verdadeiro positivo, falso positivo e falso negativo com base em correspondência de valores, levando em conta variações de formatação (datas, valores monetários). A avaliação vai além de acurácia simples, incorporando métricas de qualidade de dados (valor crítico de campos) e métricas operacionais (latência e custo).
• Máquina de dados para apresentação: é apresentada uma visão consolidada de FATURA com características relevantes para avaliação de desempenho, incluindo o fato de existir várias layouts e a necessidade de lidar com campos ausentes e diferentes formatos. | Aspecto do conjunto de dados | Descrição |--- |--- |FATURA | 10.000 faturas, 50 layouts |Variedade de layouts | 50 layouts distintos; 24 campos por documento |Amostra de ground truth | 1.960 amostras (40 documentos de 49 layouts) |Distribuição de campos | 18 campos com ocorrências desiguais (250 a 1.800) |Normalização de ground truth | Remoção de prefixos inconsistentes e alinhamento com a saída do modelo |
• Mecanismo de avaliação de desempenho: utiliza F1-score para medir precisão (exatidão das extrações) e recall (capacidade de localizar os campos relevantes). A avaliação envolve um conjunto de comparadores específicos de campo que determinam quando uma extração conta como verdadeiro positivo, levando em conta variações de formato (datas, moedas). A métrica também considera o custo/latência por documento para refletir valor de negócio. AWS ML Blog

Principais conclusões (Takeaways)

• Soluções KIE baseadas em modelos de base podem ser exploradas com Bedrock por meio de uma API unificada, facilitando experimentação e comparação entre modelos.
• A padronização da ground truth é crítica para avaliações justas em cenários de documentos com layouts variados.
• Abordagens de prompting multiformato e o uso de templates flexíveis permitem extrair dados de diferentes tipos de documentos.
• A avaliação deve equilibrar métricas técnicas (precisão, recall, F1) com métricas de negócio (latência, custo por documento).
• O FATURA oferece um proxy realista para faturas empresariais, destacando desafios comuns como campos ausentes, múltiplos valores e hierarquias de dados.

Referências

• https://aws.amazon.com/blogs/machine-learning/document-intelligence-evolved-building-and-evaluating-kie-solutions-that-scale/