Geração automática de schemas para processamento inteligente de documentos

O problema clássico do ovo e da galinha no processamento de documentos

Quem já trabalhou com Processamento Inteligente de Documentos (IDP) conhece bem o dilema inicial: antes de extrair informações de documentos, você precisa de um schema que defina o que deve ser extraído. Mas como criar esses schemas quando você tem milhares de documentos sem saber quais tipos existem na coleção? Fazer isso manualmente, em escala, consome tempo e recursos consideráveis, tornando difícil justificar o investimento em iniciativas de IDP.

Para resolver exatamente esse problema, a AWS apresentou a funcionalidade de descoberta multi-documento no IDP Accelerator. Ela atua como uma etapa de pré-processamento automatizada, analisando documentos desconhecidos, agrupando-os por tipo e gerando schemas prontos para uso.

O que é o IDP Accelerator

O IDP Accelerator é uma solução escalável, serverless e de código aberto para processamento automatizado de documentos e extração de informações. Para configurá-lo para tipos específicos de documentos, é necessário um arquivo de configuração que define as classes e os campos a serem extraídos. Um exemplo mínimo está disponível no repositório GitHub do IDP Accelerator.

O IDP Accelerator já contava com um Módulo de Descoberta capaz de gerar uma configuração de classe a partir de um único documento de exemplo. O problema é que esse recurso exige que o usuário já conheça as classes de documentos e consiga identificar um exemplo representativo para cada uma. A nova funcionalidade multi-documento remove esse pré-requisito, acelerando o caminho para aplicar o IDP Accelerator a coleções de documentos sem rótulo.

Como a solução funciona

A nova funcionalidade está integrada ao Módulo de Descoberta existente como uma capacidade “Múltiplos Documentos”, ao lado da opção “Documento Único” já disponível. A orquestração é feita por uma máquina de estados do AWS Step Functions e por funções do AWS Lambda para computação serverless.

Os documentos são processados a partir de um bucket do Amazon Simple Storage Service (Amazon S3) ou de um arquivo Zip enviado diretamente. Os modelos disponíveis pelo Amazon Bedrock geram os schemas, que são automaticamente integrados ao arquivo de configuração do IDP Accelerator.

O fluxo completo acontece em três grandes etapas: geração de embeddings, agrupamento de documentos e geração agêntica de schemas — com uma etapa adicional de análise e reflexão ao final.

Detalhes técnicos do pipeline

Geração de embeddings

O processo começa convertendo cada documento em um embedding vetorial — uma representação numérica das características visuais do documento. Para documentos com múltiplas páginas, apenas a primeira página é utilizada.

A solução usa embeddings visuais em vez de texto extraído por OCR (Reconhecimento Óptico de Caracteres). A razão é que embeddings visuais capturam layout, formatação e pistas estruturais que distinguem tipos de documentos mesmo quando o conteúdo textual é semelhante. O modelo padrão adotado é o Cohere Embed v4, disponível pelo Amazon Bedrock. A etapa de embedding já trata automaticamente questões como compressão de imagem, lógica de retry e controle de taxa de requisições.

Agrupamento de documentos

Com os embeddings gerados, a solução precisa descobrir quantos tipos de documentos existem na coleção. Para isso, utiliza o silhouette score (pontuação de silhueta), uma métrica que mede o quão bem separados estão os grupos entre si e o quão compactos são os documentos dentro de cada grupo.

Usando o algoritmo k-means, o sistema testa valores de k (número de grupos) de 2 a 20 por padrão e seleciona o agrupamento com a maior pontuação de silhueta. Para garantir grupos significativos, cada cluster precisa ter pelo menos dois documentos. Se necessário, o limite superior de k é reduzido abaixo de 20 para satisfazer essa restrição.

Validação da abordagem de embeddings e clustering

Para validar a abordagem, a AWS realizou experimentos com o Cohere Embed v4 sobre um subconjunto do dataset OCR-benchmark, disponível no bucket de conjunto de testes implantado com o stack CloudFormation do IDP Accelerator. Esse subconjunto contém 293 documentos distribuídos em 9 tipos: cheque bancário, contrato de locação comercial, extrato de cartão de crédito, nota de entrega, inspeção de equipamento, glossário, formulário de petição, imóvel e escala de turnos.

O objetivo era verificar se o k-means conseguia identificar corretamente esses agrupamentos usando o modelo de embedding. O resultado foi expressivo: a maior pontuação de silhueta ocorreu exatamente em k=9, correspondendo ao número real de tipos de documentos no dataset.

Para visualizar os resultados, foi gerado um gráfico t-SNE (Incorporação de Vizinhos Estocásticos Distribuídos em t — t-SNE), uma técnica de visualização que reduz dados de alta dimensionalidade para um espaço bidimensional preservando as relações entre os pontos. O gráfico mostrou os clusters claramente separados, cada um correspondendo a um tipo de documento.

O agrupamento atingiu um Índice Rand Ajustado (ARI) e uma Informação Mútua Normalizada (NMI) perfeitos, ambos com valor 1.0. O ARI mede o quão bem o agrupamento corresponde aos grupos reais, enquanto o NMI quantifica a informação compartilhada entre os clusters previstos e os reais. Cada cluster mapeou um-para-um para uma classe de documento real com 100% de pureza.

Esses resultados demonstram que embeddings multimodais de alta qualidade permitem classificação de documentos totalmente não supervisionada — sem nenhum dado de treinamento rotulado. Vale ressaltar, porém, que o desempenho nesse dataset de benchmark não garante resultados similares em outras coleções de documentos, pois as características específicas de cada dataset influenciam diretamente a qualidade dos resultados.

Geração agêntica de schemas

Após a identificação dos clusters, o pipeline entra na fase agêntica. Para cada cluster, um Strands Agent é invocado para determinar o tipo de documento e gerar um schema. A escolha pelo Strands Agents se deve à abordagem orientada pelo modelo, que oferece ao LLM a flexibilidade de raciocinar autonomamente sobre cada schema.

O agente precisa visualizar documentos em diferentes posições dentro do cluster para capturar toda a variedade antes de gerar o schema — por exemplo, um documento próximo ao centro, um na periferia e um a distância intermediária. Uma abordagem determinística e fixa de amostragem não funcionaria aqui, pois a qualidade do agrupamento depende fortemente dos documentos específicos de cada coleção.

Para isso, o agente conta com duas ferramentas especializadas:

Ferramenta de Análise de Cluster — Recupera IDs de documentos ordenados por distância do centróide do cluster, permitindo que o agente amostre estrategicamente ao longo do espectro de variação dentro do cluster.
Ferramenta de Visualização de Documento — Busca e comprime imagens de documentos para inspeção visual, tratando automaticamente as restrições de tamanho para a janela de contexto do modelo.

O prompt de sistema do agente incorpora conhecimento de domínio sobre convenções de JSON Schema e requisitos da configuração do IDP Accelerator. O agente é instruído a:

Amostrar documentos estrategicamente, parando cedo se já tiver cobertura suficiente.
Gerar JSON Schemas com metadados adequados, definições de tipo e descrições.
Incluir anotações específicas do IDP Accelerator como x-aws-idp-document-type e x-aws-idp-evaluation-method. O campo x-aws-idp-evaluation-method é utilizado pela extensão de avaliação baseada no Stickler.
Criar definições reutilizáveis ($defs) para estruturas comuns como endereços, itens de linha e informações fiscais.
Aplicar métodos de avaliação adequados conforme o tipo de campo: EXACT para strings, NUMERIC_EXACT para números e LLM para objetos complexos ou aninhados.

Os agentes rodam em paralelo, então não é necessário esperar que um cluster termine para o próximo começar.

Análise e reflexão dos schemas

Após cada agente gerar seu schema de forma independente, uma etapa de análise avalia a diferenciação entre os resultados. Ela verifica se os agrupamentos descobertos estão bem separados ou se há sobreposições, e se os schemas gerados são completos e consistentes. O sistema identifica redundâncias ou duplicações entre tipos de documentos e apresenta recomendações concretas, como mesclar clusters ou refinar definições de campos. O resultado final é um relatório de qualidade com uma visão geral legível das classes identificadas, visível nos detalhes do job de descoberta no IDP Accelerator.

Como executar a descoberta multi-documento

Passo 1: Criar uma nova configuração

Acesse a seção de Configuração no console do IDP Accelerator e selecione Visualizar/Editar Configuração. Escolha Schema de Documento > Limpar Tudo para criar uma configuração vazia. Em seguida, selecione Salvar como Versão, forneça um nome descritivo e confirme.

Passo 2: Executar a descoberta multi-documento

Com a configuração criada, acesse a seção de Descoberta e selecione a opção Múltiplos Documentos. Escolha a versão de configuração recém-criada e configure a fonte de documentos: selecione Caminho S3 ou Upload Zip, escolha o bucket de origem e especifique o prefixo S3 onde os documentos estão armazenados. Os documentos precisam estar em um dos buckets existentes do IDP Accelerator (Discovery Bucket, Test Bucket ou Input Bucket) para usar a opção de bucket de origem. Clique em Iniciar Descoberta para acionar a máquina de estados.

Passo 3: Monitorar o job e visualizar os resultados

Uma nova entrada aparecerá na tabela de jobs de Descoberta Multi-Documento, mostrando o status de execução, a etapa atual e metadados. Após a conclusão, acesse os detalhes do job para visualizar o Relatório de Qualidade. As classes descobertas e seus schemas JSON são automaticamente integrados ao arquivo de configuração.

Boas práticas para melhores resultados

Antes de executar o job de descoberta multi-documento em larga escala, vale considerar algumas recomendações:

Como o workflow processa apenas a primeira página de cada PDF, certifique-se de que os arquivos de entrada sejam documentos individuais. Pacotes com múltiplos documentos ainda não são suportados.
Após obter os resultados iniciais, revise o relatório de qualidade com cuidado para identificar problemas como clusters sobrepostos ou distribuições desiguais de documentos antes de finalizar os schemas.
Se a qualidade dos schemas for inconsistente entre clusters, verifique se a coleção tem uma distribuição muito desigual de tipos de documentos. Executar o job em um subconjunto mais balanceado pode ajudar o agente a produzir clusters e schemas mais confiáveis.

Próximos passos após a descoberta

O que fazer depois depende do que o workflow encontrou nos documentos:

Schemas limpos e baixa sobreposição no relatório: o caminho está livre para executar o IDP em escala. Os schemas já estão automaticamente adicionados ao campo de classes do arquivo de configuração do IDP Accelerator.
Relatório indicou clusters sobrepostos: revise as recomendações e use-as para refinar os schemas gerados, o que pode incluir mesclar schemas similares em uma única classe ou ajustar definições de campos para reduzir sobreposição.
Qualidade inconsistente entre clusters: verifique a distribuição dos tipos de documentos na coleção e considere executar o job em um subconjunto mais balanceado.

Conclusão

A funcionalidade de descoberta multi-documento resolve um desafio clássico no processamento de documentos: você precisa de schemas para processar documentos, mas precisa processar documentos para construir schemas. A solução combina embeddings visuais, agrupamento automático e geração agêntica de schemas com LLMs multimodais, transformando uma coleção opaca de documentos desconhecidos em classes e schemas estruturados, prontos para revisão humana.

Quem quiser experimentar ou contribuir com a solução pode acessar o repositório GitHub do IDP Accelerator para abrir issues ou pull requests.

Fonte

Automate schema generation for intelligent document processing (https://aws.amazon.com/blogs/machine-learning/automate-schema-generation-for-intelligent-document-processing/)