Introdução
Esse artigo inaugura uma série em que compartilho aprendizados como liderança de IA em uma FinTech. Nos últimos meses, estive envolvido na criação de um produto de Intelligent Document Processing (IDP) voltado para o processamento de comprovantes de pagamento. Nossa meta era extrair informações estruturadas de PDFs e imagens de forma confiável e escalável.
Para acelerar o desenvolvimento, apostamos no AWS Bedrock Data Automation (BDA). A ferramenta nos touxe bons resultados, porém também nos revelou limitações inesperadas. A seguir, compartilho três desafios que enfrentamos, mas sem deixar de lado os bons resultados: reconhecer os pontos fortes do BDA e expor as armadilhas que encontramos no uso real.
Por que escolhemos o BDA?
O BDA é um serviço da AWS voltado à automação da extração de dados em documentos e imagens. Um recurso útil para nosso caso de uso é a criação de blueprints, artefatos que descrevem como os dados devem ser extraídos, normalizados e formatados. O BDA oferece duas alternativas para criação de blueprints:
- Manual (via JSON Schema): o desenvolvedor define toda a estrutura.
- Automática (via prompt): basta escrever em linguagem natural quais campos extrair e como tratá-los.
A segunda opção parecia irresistível e preguiçosa. Instantâneamente já tínhamos blueprints funcionando e saídas promissoras na extração de dados de comprovantes. Essa facilidade, seguida das recorrentes atualizações que foram realizadas no decorrer do desenvolvimento nos convenceu a seguir por esse caminho.
Tudo parecia bem. A funcionalidade estava no ambiente produtivo, estávamos performando as extrações como esperado. Porém em algum momento nos deparamos com uma anomalia de custos e após uma análise mais apurada sobre o comportamento esbarramos com alguns problemas que não foram observados durante o desenvolvimento.
Pitfall #1 – Blueprints criadas por prompt sempre são da Modalidade de Documentos
Algo que demorou para identificarmos: toda blueprint criada por prompt é tratada como Documento, mesmo que o documento base para esta blueprint seja de imagem. Durante os testes e durante o período de desenvolvimento, essa característica passou despercebida sem gerar qualquer impacto aparente em nossas extrações e testes.
Essa característica veio nos impactar mais tarde, mas de uma forma muito mais séria: gerando uma anomalia de custos!
Pitfall #2 – Modalidade incorreta e impacto financeiro
O BDA possui o recurso de roteamento por modalidade, que define se um arquivo será processado como documento ou como imagem. Embora pareça ser apenas uma configuração mais técnica, essa configuração tem um impacto direto no custo da solução, já que a AWS te cobra da seguinte forma:
- Documento: USD 0,040 por página.
- Imagem: USD 0,005 por imagem.
Como criamos as blueprints via prompt, todas foram tratadas como Documentos. Durante os testes não percebemos diferença, mas em agosto o pior aconteceu: quase USD 1.000 extras na fatura.
Após investigar o comportamento, entendemos o motivo: as blueprints criadas automaticamente não respeitam a modalidade de imagem. Depois de identificado o motivo, a solução foi recriá-las manualmente com JSON Schema, configurando corretamente Documento ou Imagem, além de ativar a configuração de roteamento.
Reconhecer as falhas e estar mais preparado para evitar erros é o que nos faz crescer. Então assumo aqui que poderíamos ter sido mais ágeis em validar esse comportamento e garantir o esperado, mas a crítica à AWS permanece: a documentação não destaca um detalhe tão importante. Essa falta de clareza pode gerar prejuízos.
Pitfall #3 – Latência média de 30 segundos
O terceiro ponto foi a latência. Cada processamento no BDA levava em torno de 30 segundos.
Na arquitetura, lidamos bem com isso. Implementamos fluxos assíncronos baseados em eventos, o que permite esperar sem travar o sistema. Porém, do ponto de vista do usuário, 30 segundos são sentidos como lentidão.
O cliente que envia um comprovante precisa esperar meio minuto até ter retorno. Para mitigar, adaptamos nossa aplicação, mas a comparação com alternativas foi inevitável. Em alguns casos, pipelines com Textract + LLM ou OCR + pós-processamento conseguem latências menores, com custo semelhante.
O lado positivo do BDA
Apesar das dificuldades, o BDA trouxe benefícios claros:
- Abstração da complexidade: não começamos do zero na construção do IDP.
- Velocidade inicial: rapidamente colocamos um protótipo em produção.
- Acesso facilitado: equipes menores conseguem experimentar IDP sem montar toda a infraestrutura.
No nosso caso, ele serviu como acelerador inicial. Sem o BDA, levaríamos mais tempo para lançar a primeira versão. O ponto central é saber medir quando ele faz sentido e quando outras alternativas são mais vantajosas.
Conclusão
Depois de três meses de uso, esses foram nossos principais aprendizados:
- Blueprints criadas por prompt sempre são Documentos.
- Modalidade mal configurada pode disparar os custos.
- Latência de 30s compromete a experiência do usuário.
Esses pontos não aparecem de forma clara na documentação. Só a prática mostrou seus impactos. Isso reforça uma lição importante: liderar em IA exige tanto entusiasmo por novas soluções quanto senso crítico para avaliar trade-offs.
O BDA tem valor, mas não é solução universal. Saber quando adotá-lo e quando substituí-lo é parte da maturidade técnica.
Nos próximos artigos, pretendo compartilhar outros bastidores de projetos de IA no mercado financeiro. Espero que esses insights ajudem a evitar armadilhas semelhantes e inspirem decisões mais conscientes.
Top comments (0)