Extraindo Dados com Pipelines Sob Demanda e em Lote no Amazon Bedrock

O problema: documentos em volume e inteligência represada

Muitas empresas acumulam grandes volumes de documentos em papel ou em formato eletrônico que contêm informações valiosas ainda não exploradas. Com o avanço da IA generativa, modelos de linguagem de grande porte (LLMs) passaram a ser capazes de extrair dados relevantes desses documentos com precisão considerável.

A AWS publicou um artigo técnico demonstrando como construir um pipeline inteligente de processamento de documentos usando o Amazon Bedrock, com duas modalidades de inferência: sob demanda e em lote. A proposta é oferecer flexibilidade para equilibrar tempo de processamento e custo, dependendo da urgência de cada requisição.

O cenário de exemplo utilizado é bastante concreto: centenas de milhões de documentos de arrendamento de terras em formato PDF digitalizado — ou seja, PDFs que contêm apenas imagens, sem texto editável — acumulados no backlog, com novos arquivos chegando diariamente.

Visão geral da solução

A solução é composta por dois pipelines de inferência que podem ser acionados dinamicamente, conforme a necessidade:

• Pipeline sob demanda: processa documentos individualmente, retornando resultados em segundos. Indicado para requisições com urgência de tempo.
• Pipeline em lote: processa múltiplos documentos em um único job de inferência em lote do Amazon Bedrock, de forma assíncrona. É a opção mais econômica.

Em ambos os pipelines, o usuário pode especificar o ID e a versão do prompt desejado. Os textos dos prompts são gerenciados centralmente pelo serviço de Gerenciamento de Prompts (Prompt Management) do Amazon Bedrock, o que permite padronizar e versionar as instruções dadas ao modelo. Isso é especialmente útil quando os documentos variam em formato — alguns apresentam atributos em listas numeradas, outros em tabelas, e alguns até em desenhos de terrenos.

Pipeline sob demanda

O pipeline sob demanda utiliza uma fila do AWS SQS do tipo Primeiro a Entrar, Primeiro a Sair (FIFO — First-In, First-Out). Quando uma mensagem chega à fila contendo o ID do documento, o ID do modelo LLM, o ID e versão do prompt e do prompt de sistema, uma função AWS Lambda é acionada automaticamente.

Essa função executa as seguintes etapas:

• Baixa o documento PDF do bucket Amazon S3 indicado na mensagem.
• Converte as páginas do PDF em imagens PNG para que o modelo multimodal possa processá-las.
• Se o documento tiver mais de 20 páginas, ele é dividido em blocos de 20 imagens — limite atual do modelo Claude 4 Sonnet por invocação multimodal.
• Recupera os textos dos prompts no Gerenciamento de Prompts do Bedrock.
• Compõe a mensagem para o LLM e envia a requisição ao Amazon Bedrock via Converse API.
• Salva o resultado extraído em uma tabela do Amazon DynamoDB, junto com métricas de desempenho do modelo.
• Após o processamento bem-sucedido, a mensagem é deletada da fila SQS.

Por que usar fila FIFO?

A escolha pela fila FIFO garante entrega confiável de mensagens (cada mensagem é processada exatamente uma vez), ordenação estrita e suporte ao agrupamento de mensagens por produtor, mantendo a previsibilidade do processamento.

As mensagens podem ser criadas externamente via AWS CLI ou AWS SDK. O exemplo de comando CLI fornecido no artigo original é:

aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/1111111111/ondemand-data-pipeline-queue.fifo --message-group-id "1" --message-body "msg 1" --message-attributes file://message_txt.txt

Estrutura dos dados armazenados

Para documentos com múltiplos blocos, o DynamoDB armazena três campos de controle:

• doc_id: identificador do documento.
• chunk_count: total de blocos gerados para aquele documento.
• chunk_id: identificador de cada bloco individualmente.

Pipeline em lote

O pipeline em lote foi projetado para alto volume. Ele utiliza uma fila SQS padrão (não FIFO), que oferece maior throughput. O fluxo envolve os seguintes componentes principais:

• Amazon EventBridge Scheduler: aciona a função Lambda de inferência em lote de acordo com uma agenda configurada.
• Lambda de inferência em lote: pré-processa os PDFs digitalizados, cria os arquivos JSONL e submete o job de inferência em lote ao Amazon Bedrock.
• Regra do Amazon EventBridge: captura o evento de conclusão do job e aciona a Lambda de pós-processamento.
• Lambda de pós-processamento: lê os resultados do job e salva os dados extraídos no DynamoDB.

Como a Lambda de lote funciona

Antes de iniciar, a função verifica se há mensagens suficientes na fila — o Amazon Bedrock exige no mínimo 100 registros para criar um job de inferência em lote. Em seguida, ela:

• Lê as mensagens da fila e extrai IDs de documento, modelo e prompts.
• Baixa e converte os documentos, assim como no pipeline sob demanda, ignorando duplicatas (já que filas SQS padrão não garantem entrega única).
• Recupera os textos dos prompts do Gerenciamento de Prompts do Bedrock.
• Cria um arquivo metadata.json no bucket S3 de dados de inferência em lote, contendo os atributos das mensagens SQS para uso posterior pelo pós-processamento.
• Gera os arquivos JSONL necessários para o job, usando o módulo de multiprocessamento do Python para paralelizar o trabalho.
• Faz upload dos arquivos JSONL para o S3 e deleta as mensagens da fila.
• Cria o job de inferência em lote no Amazon Bedrock.

Um detalhe importante: cada job em lote só pode usar um modelo. Se as mensagens da fila especificarem modelos diferentes, a Lambda utiliza um mecanismo de seleção que escolhe o modelo mais frequentemente solicitado naquele conjunto.

Fluxo de conclusão do job

Quando o Amazon Bedrock conclui o job, ele armazena os resultados no bucket S3 configurado e envia um evento de mudança de status ao Amazon EventBridge. Uma regra do EventBridge captura esse evento e aciona a Lambda de pós-processamento, que lê os arquivos JSONL de saída e salva os atributos extraídos no DynamoDB.

Pré-requisitos e implantação

Para reproduzir a solução, é necessário ter uma conta AWS com acesso ao Console de Gerenciamento e permissões de Gerenciamento de Identidade e Acesso (IAM) suficientes para criar e gerenciar stacks do AWS CloudFormation, incluindo as permissões: cloudformation:CreateStack, cloudformation:DescribeStacks, cloudformation:UpdateStack e cloudformation:DeleteStack.

A implantação é feita via CloudFormation, com stacks separados para o pipeline sob demanda e o pipeline em lote. O processo segue o fluxo padrão: criação da stack, revisão e confirmação dos recursos de IAM que serão criados.

Testando os pipelines

O artigo original disponibiliza três documentos de arrendamento de terras do Texas para testes: dos condados de Winkler, Andrews e Sutton, adquiridos no site Texas Land Records and County Records.

O fluxo de teste do pipeline sob demanda consiste em:

• Baixar os PDFs de exemplo e fazer upload para o bucket S3 criado pelo CloudFormation.
• Criar um arquivo JSON de atributos da mensagem (message_txt.json) com os IDs do documento, modelo, prompts e localização no S3.
• Enviar a mensagem para a fila SQS via AWS CLI.
• Acompanhar os logs da Lambda no Amazon CloudWatch.
• Verificar o resultado extraído na tabela DynamoDB.

O arquivo de exemplo de mensagem fornecido no artigo original é:

{
  "application": {
    "DataType": "String",
    "StringValue": "bedrock-example"
  },
  "id": {
    "DataType": "String",
    "StringValue": "Winkler_2024-06-05_N_C42758_V_OPR"
  },
  "model_id": {
    "DataType": "String",
    "StringValue": "anthropic.claude-sonnet-4-20250514-v1:0"
  },
  "prompt_id": {
    "DataType": "String",
    "StringValue": "6CT88W3MWT"
  },
  "prompt_version": {
    "DataType": "String",
    "StringValue": "1"
  },
  "s3_location": {
    "DataType": "String",
    "StringValue": "s3://ondemand-data-pipeline-bucket-111111111/Winkler_2024-06-05_N_C42758_V_OPR.pdf"
  },
  "system_prompt_id": {
    "DataType": "String",
    "StringValue": "R2NFLXFXOJ"
  },
  "system_prompt_version": {
    "DataType": "String",
    "StringValue": "1"
  }
}

O resultado esperado para o documento do condado de Winkler, armazenado na coluna model_response do DynamoDB, é uma estrutura JSON com os atributos de cada área de terra identificada no documento:

[
  {
    "tract": 1,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1239",
    "survey": "PSL Survey",
    "section": "8",
    "range_block": "B2",
    "quarter": "N/2 of N/2"
  },
  {
    "tract": 2,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1239",
    "survey": "PSL Survey",
    "section": "8",
    "range_block": "B2",
    "quarter": "N/2 of S/2"
  },
  {
    "tract": 3,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1240",
    "survey": "PSL Survey",
    "section": "9",
    "range_block": "B2",
    "quarter": "S/2 of N/2"
  },
  {
    "tract": 4,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1240",
    "survey": "PSL Survey",
    "section": "9",
    "range_block": "B2",
    "quarter": "S/2 of S/2"
  }
]

Limpeza dos recursos

Para remover os recursos criados, basta deletar as stacks pelo console do CloudFormation. O serviço cuida automaticamente da ordem de exclusão respeitando as dependências. Vale destacar que os buckets S3 e a tabela DynamoDB não são deletados automaticamente — a política de retenção foi configurada para evitar perda acidental de dados. Para removê-los, é necessário acessar cada serviço individualmente no console e excluí-los manualmente.

Considerações finais

A solução apresentada pela AWS demonstra como é possível combinar flexibilidade e economia no processamento inteligente de documentos. A escolha entre o pipeline sob demanda e o em lote deve levar em conta tanto a urgência do processamento quanto o custo: segundo os testes mencionados no artigo original, o pipeline em lote pode reduzir em 50% o custo do Amazon Bedrock em comparação com a modalidade sob demanda.

Outro diferencial relevante é a capacidade de especificar o modelo e o prompt em nível de documento individual, o que torna os pipelines adaptáveis a diferentes tipos de conteúdo dentro do mesmo fluxo. Com paralelismo habilitado via módulo de multiprocessamento do Python, as funções Lambda do pipeline em lote conseguem processar 1.000 documentos em até 15 minutos.

Para quem quiser escalar ainda mais, o artigo sugere migrar o código das Lambdas para o AWS Batch, o que permitiria processar dezenas de milhares de documentos em um único job de inferência em lote. O ponto de partida recomendado é o repositório de quick start disponível no GitHub.

Fonte

Extract Data with On-demand and Batch Pipelines Dynamically (https://aws.amazon.com/blogs/machine-learning/extract-data-with-on-demand-and-batch-pipelines-dynamically/)