Serviços que somam ao Bedrock I: IA especializada e ML clássico
- ⬜⊕ Claude na AWS: os quatro caminhos e onde cada um encaixa(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Existe uma família de serviços na AWS que faz uma coisa só, muito bem e muito barato: ler tabela de PDF, detectar dado pessoal em texto, transcrever áudio, reconhecer objeto em imagem. Nenhum deles é generativo — e é exatamente por isso que eles importam. Metade do que os times mandam para o LLM é resolvido melhor, mais rápido e por uma fração do preço por um desses serviços. Este módulo percorre cada um: o que é, o que soma quando está junto do Bedrock, quando usar e o limite que decide a arquitetura. É a alavanca número um do playbook de custo aplicada a serviços concretos.
Como escolher nesta camada
- A tarefa tem resposta verificável? Extrair um CNPJ de um formulário tem gabarito; resumir uma cláusula não tem. Tarefa com gabarito quase sempre pertence a um serviço dedicado.
- A entrada tem estrutura conhecida? Formulário, tabela, áudio e imagem têm serviço próprio. Texto livre com ambiguidade é onde o generativo ganha.
- O volume justifica? Serviço especializado brilha em escala. Em cem documentos por mês, a diferença de preço é irrelevante e a simplicidade de uma chamada só pode valer mais.
A regra que resume a camada
Use o serviço especializado para PREPARAR a entrada e para resolver o que é determinístico. Use o Bedrock para o que exige julgamento. Quase todo pipeline caro que aparece em revisão de custo está mandando ao modelo generativo algo que uma dessas caixas resolveria por ordens de grandeza menos.
Documento e texto
Esta é a família com maior impacto financeiro imediato, porque documento é a entrada mais comum de IA corporativa e a mais cara de mandar inteira para um modelo multimodal — a imagem de uma página consome muitos tokens de entrada.
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Textract | OCR que entende estrutura: devolve texto, tabelas, pares campo-valor e assinaturas com coordenadas | Entrega o conteúdo já estruturado, para o modelo só interpretar o que exige julgamento — em vez de fazer OCR a preço de geração | Cobra por página e por tipo de análise; formulário e tabela custam mais que texto puro. Verifique no pricing |
| Amazon Comprehend | NLP gerenciado: entidades, sentimento, idioma, frases-chave e detecção de dado pessoal | Rede de PII antes do prompt e classificação barata que evita a chamada de modelo. É o filtro na entrada e na saída | Cobra por unidade de texto; a detecção de PII tem preço próprio. Modelo customizado exige treino |
| Amazon Translate | Tradução automática em escala, com terminologia customizada | Normaliza o idioma na entrada (um só prompt para N idiomas) ou traduz a saída sem gastar tokens de geração | Tradução de texto muito curto tem preço mínimo por request; terminologia customizada é o que salva jargão interno |
import boto3
comp = boto3.client("comprehend")
br = boto3.client("bedrock-runtime")
# Tipos que nunca devem chegar ao prompt de um assistente de suporte.
# Nome e cidade costumam ser necessarios para a resposta fazer sentido;
# documento, cartao e credencial, nunca.
BLOQUEADOS = {"CREDIT_DEBIT_NUMBER", "BANK_ACCOUNT_NUMBER", "SSN",
"PASSWORD", "CREDIT_DEBIT_CVV", "PIN", "AWS_ACCESS_KEY"}
def mascarar(texto: str, idioma: str = "pt") -> tuple[str, list[str]]:
"""Mascara PII sensivel ANTES de montar o prompt.
Por que aqui e nao no guardrail: o guardrail atua na fronteira do modelo,
entao o dado ja viajou e ja pode ter entrado em log. Mascarar antes e mais
barato (Comprehend cobra por unidade de texto, nao por token) e reduz o
proprio tamanho do prompt.
"""
r = comp.detect_pii_entities(Text=texto, LanguageCode=idioma)
achados = [e for e in r["Entities"]
if e["Type"] in BLOQUEADOS and e["Score"] >= 0.85]
# Substitui de tras para frente: mexer no comeco desloca os offsets seguintes.
saida = texto
for e in sorted(achados, key=lambda x: x["BeginOffset"], reverse=True):
saida = saida[:e["BeginOffset"]] + f"[{e['Type']}]" + saida[e["EndOffset"]:]
return saida, [e["Type"] for e in achados]
def responder(pergunta: str, contexto: str, model_id: str) -> str:
limpa, removidos = mascarar(pergunta)
if removidos:
metrica("pii.mascarado", tipos=removidos) # sinal de que o canal vaza dado
r = br.converse(
modelId=model_id,
system=[{"text": SYSTEM}, {"cachePoint": {"type": "default"}}],
messages=[{"role": "user", "content": [{"text": f"{contexto}\n\n{limpa}"}]}],
inferenceConfig={"maxTokens": 500},
)
return r["output"]["message"]["content"][0]["text"]
Mascarar antes não substitui o guardrail
São camadas diferentes e você quer as duas. O Comprehend na entrada evita que o dado sensível viaje e entre em log — e é mais barato, porque cobra por texto e não por token. O guardrail atua na fronteira do modelo e cobre também a SAÍDA, que é onde o dado pode reaparecer vindo do contexto recuperado. Quem só tem o guardrail paga tokens de dado que nunca deveria ter enviado; quem só tem o Comprehend não protege a resposta.
Voz
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Transcribe | Fala para texto, em lote ou em tempo real, com vocabulário e modelo de linguagem customizáveis | É o que entrega texto ao Bedrock em qualquer canal de voz. Sem ele, não existe assistente por telefone | Latência da transcrição entra no orçamento de tempo da resposta; vocabulário customizado é o ajuste de maior retorno |
| Amazon Polly | Texto para fala com vozes neurais e controle de prosódia via marcação | Fecha o ciclo de voz devolvendo a resposta em áudio, sem você operar síntese | Frase longa é insuportável em áudio — o limite real é de UX, não técnico: force resposta curta no prompt |
Em voz, transcrição, retrieval, inferência, guardrail e síntese acontecem em série — e o usuário sente a soma, não a média. É por isso que o case público de contact center com latência na casa de poucos segundos impressiona: cada etapa precisou caber num orçamento apertado. A regra prática é medir o tempo de cada etapa separadamente desde o primeiro dia, porque quando o total estourar você vai precisar saber quem consumiu o quê.
Vocabulário customizado é o ajuste mais barato do canal de voz
Nome de produto, sigla interna, código de plano e sobrenome regional são exatamente o que a transcrição genérica erra — e um erro de transcrição contamina tudo depois: o retrieval busca a palavra errada e o modelo responde com confiança sobre outra coisa. Alimentar o vocabulário customizado com os termos do seu domínio custa algumas horas e melhora mais a qualidade percebida do assistente do que trocar de modelo.
Visão e decisão especializada
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Rekognition | Detecção de objeto, rosto, texto em imagem, conteúdo impróprio e comparação facial | Triagem visual barata antes de acionar o modelo multimodal: descarta o que não interessa e classifica o que é fechado | Não interpreta cena complexa nem responde pergunta aberta sobre a imagem — é aí que o multimodal entra |
| Amazon Personalize | Recomendação treinada no comportamento de uso do seu produto | Divisão de trabalho limpa: ele escolhe QUAL item recomendar, o modelo escreve o texto que apresenta a escolha | Precisa de volume de interação para treinar; em catálogo novo, sofre com o problema de partida a frio |
| Amazon Fraud Detector | Detecção de fraude com modelo dedicado treinado no seu histórico | Mantém a decisão de risco num serviço determinístico e auditável, em vez de pedir julgamento de risco a um LLM | Exige histórico rotulado de fraude; sem dado, não há modelo |
Decisão de risco não pertence ao generativo
Aprovar crédito, negar sinistro ou classificar fraude com um LLM é um problema em três frentes: não é reprodutível (a mesma entrada pode variar), não é explicável no formato que o regulador aceita, e não tem métrica de discriminação estabelecida. Serviço dedicado — ou classificador próprio no SageMaker — entrega score reprodutível e auditável. O generativo tem papel aqui, mas é outro: redigir a justificativa da decisão que o modelo determinístico tomou.
Assistente pronto: quando comprar em vez de construir
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Q Developer | Assistente de desenvolvimento integrado à IDE e ao console | Produtividade do time que constrói a plataforma, sem você construir nada | Você não controla prompt, modelo nem retrieval — é caixa-preta gerenciada |
| Amazon Q Business | Assistente corporativo com conectores para as fontes internas | Caminho rápido para Q&A sobre acervo interno quando o prazo não permite montar RAG | Mesma limitação: sem controle sobre chunking, tier ou lógica de recuperação |
📋 A diretoria quer um assistente de Q&A sobre políticas internas no ar em quatro semanas. O acervo está no SharePoint e no Confluence, e o time de plataforma tem duas pessoas.
Em quatro semanas, com duas pessoas e acervo espalhado, montar ingestão, chunking, vector store e avaliação é aposta. O gerenciado entrega valor no prazo e, principalmente, produz o dado que você precisa para decidir depois: quais perguntas as pessoas realmente fazem e onde o conteúdo está faltando.
Alt: Knowledge Bases do Bedrock — É o caminho certo para o longo prazo — controle de chunking, tier, filtro de permissão e citação — mas não cabe em quatro semanas com esse time.
Alt: Ficar no gerenciado para sempre — Você não controla prompt, modelo nem retrieval; quando precisar de filtro de permissão fino ou de trocar de tier por custo, não terá onde mexer.
Um pipeline manda o PDF escaneado inteiro para o modelo multimodal extrair campos, e o custo por documento ficou alto. Qual é a mudança de arquitetura de maior efeito?
SageMaker para quem usa Bedrock
A pergunta "Bedrock ou SageMaker?" está mal colocada: eles convivem. O Bedrock é inferência gerenciada de modelos de fundação; o SageMaker é a plataforma de quando o modelo é o produto — mas duas peças dele servem a qualquer projeto de Bedrock sem que você treine nada, e são justamente as que os times constroem à mão, mal e com atraso.
| Peça | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Ground Truth | Rotulagem gerenciada, com fluxo de revisão e força de trabalho | Produz o golden set da eval — o ativo que destrava rebaixamento de tier e, portanto, toda alavanca de custo | Custa por item rotulado; o gargalo real é definir o critério de rotulagem, não a ferramenta |
| Augmented AI (A2I) | Fluxo gerenciado de revisão humana: fila, interface, distribuição e consolidação | Entrega pronto o ramo de revisão do confidence routing, que é a parte que sempre é construída às pressas | A interface padrão é genérica; caso complexo exige template customizado |
| Treino e hospedagem | Treinar e servir modelo próprio em endpoint gerenciado | Classificador dedicado que substitui o LLM em triagem de altíssimo volume | Endpoint cobra por hora ligado, não por chamada — dinheiro parado se o volume não justificar |
| JumpStart | Catálogo de modelos abertos prontos para hospedar | Caminho para modelo que não está no Bedrock, ou para exigência de isolamento total | Você volta a operar infraestrutura de inferência, com GPU e escala por conta |
| Model Monitor / Clarify | Monitoramento de deriva e análise de viés em modelo hospedado | Só se aplica ao modelo PRÓPRIO do fluxo; o gerenciado do Bedrock você observa por outras vias | Exige baseline capturado; sem ele, não há do que derivar |
| Pipelines / Feature Store | Orquestração versionada de treino e atributos consistentes entre treino e inferência | Reprodutibilidade quando existe modelo próprio ao lado do generativo | Complexidade que só se paga quando há mais de um modelo em ciclo de vida |
Vale explicitar por que Ground Truth é peça de FinOps e não de ciência de dados. O conjunto de referência é o que permite afirmar que o modelo barato empata com o caro numa categoria de tarefa. Sem esse conjunto, ninguém assina o rebaixamento de tier — e a conta fica congelada no patamar mais alto. O gargalo do golden set nunca é a ferramenta: é ter alguém do domínio disponível para rotular. Rotulagem gerenciada resolve exatamente essa escassez.
Duas peças do SageMaker que quase todo projeto de Bedrock deveria usar
Rotulagem gerenciada resolve o gargalo do golden set — o ativo que destrava eval e, por consequência, todas as alavancas de custo. E o fluxo gerenciado de revisão humana entrega pronta a fila e a interface que o confidence routing precisa, que é justamente a parte que os times acabam construindo às pressas e mal. Nenhuma das duas exige que você treine nada.
- → dispara o pipeline
- → só o que a regra não resolveu
- → confiança alta segue direto
- → faixa média vai para revisão
- Armazenamento
- Integração de apps
- IA e machine learning
- Compute
- Fora da AWS
- Banco de dados
Os passos 2 a 4 tiram a maior parte do trabalho do caminho do LLM — cada um custa ordens de grandeza menos por documento. Quando a IA está cara, é a primeira coisa a olhar.
- Chega e dispara. S3 recebe o arquivo e emite o evento. Nenhuma IA ainda — e nenhum custo de modelo.
- OCR estrutural. Textract extrai texto, tabelas e campos. É determinístico, barato e melhor que o modelo generativo nessa tarefa específica.
- Triagem de sensibilidade. Comprehend detecta dado pessoal. O que for sensível é mascarado ou roteado antes de entrar em qualquer prompt.
- Regras antes do modelo. Dígito verificador, formato de data, total que precisa fechar. O que a regra resolve não vira chamada de LLM.
- O Bedrock entra no julgamento. Só o que exige interpretação chega aqui — e chega com a entrada já limpa e estruturada.
- Rotear por confiança. Alta segue direto; média vai para revisão humana com o trecho de origem destacado; baixa reprocessa em tier maior.
- Registrar a evidência. Hash, versões de modelo e prompt, saída bruta, validações, rota tomada e a decisão humana. Não é reconstituível depois.
Combinações que se repetem
| Preparar | Filtrar | Julgar | Devolver | |
|---|---|---|---|---|
| Documento escaneado | Textract extrai texto, tabela e campo | Comprehend detecta PII; regra valida formato | Bedrock interpreta cláusula e classifica | Gravação no sistema + evidência |
| Áudio de atendimento | Transcribe converte fala em texto | Comprehend detecta PII e sentimento | Bedrock responde ou sugere ao atendente | Polly sintetiza a resposta em áudio |
| Imagem de produto | Rekognition detecta objeto e conteúdo impróprio | Regra descarta o que não passa na triagem | Bedrock multimodal descreve e categoriza | Enriquecimento do catálogo em batch |
| Texto livre do cliente | Translate normaliza o idioma | Comprehend classifica intenção e mascara PII | Bedrock gera a resposta ancorada | Guardrail aplica grounding e PII na saída |
| Formulário estruturado | Textract lê pares campo-valor | Regra determinística resolve quase tudo | Bedrock só nos campos ambíguos | Faixa média vai para revisão humana |
Leia as linhas, não as colunas
Repare que a coluna "Julgar" — a única em que o Bedrock aparece — é sempre a mais estreita. É esse o desenho de uma arquitetura de IA madura: o modelo generativo faz o pedaço que só ele faz, e o resto é serviço dedicado ou regra. Pipeline em que o Bedrock aparece em todas as colunas é pipeline caro.
Erros clássicos desta camada
- Mandar o PDF escaneado inteiro para o modelo multimodal: você paga tokens de imagem para que ele faça OCR, tarefa em que não é o melhor nem o mais barato.
- Pedir julgamento de risco ao generativo: não é reprodutível, não é explicável no formato que o regulador aceita e não tem métrica de discriminação estabelecida.
- Confiar só no guardrail para PII: o dado já viajou e já pode ter entrado em log. Mascare na entrada e proteja a saída — são camadas diferentes.
- Transcrição sem vocabulário customizado: o erro de transcrição contamina o retrieval, e o modelo responde com confiança sobre a palavra errada.
- Endpoint do SageMaker ligado sem volume: cobra por hora, não por chamada. É o equivalente ao vector store ocioso do lado de ML.
- Comprar o assistente gerenciado sem plano de migração: resolve o prazo e depois você descobre que não há onde ajustar tier, filtro de permissão ou chunking.
- Adotar Personalize em catálogo novo: sem histórico de interação, o modelo não tem do que aprender — partida a frio não se resolve com prompt.
- Tratar Ground Truth como assunto de ciência de dados: é peça de FinOps, porque sem golden set ninguém aprova rebaixar de tier.
A economia mais previsível que existe
Num pipeline documental típico, os passos 2 a 4 removem a maior parte do trabalho do caminho do LLM — e cada um deles custa ordens de grandeza menos por documento. Quando alguém pergunta "por que a nossa IA custa tanto?", esta é a primeira coisa a olhar: quanto do que passa pelo modelo generativo poderia ter sido resolvido por OCR, por classificador ou por regra.
O time quer rebaixar de tier para economizar, mas ninguém aprova sem prova de que a qualidade se mantém. Não existe conjunto de referência. Qual serviço destrava isso?
Num assistente de suporte, por que mascarar dado pessoal com um serviço de NLP na entrada, se o guardrail já faz redação de PII?
Próximo passo
Você viu a camada que decide quanto do trabalho o modelo generativo realmente precisa fazer. A próxima é a que decide se o projeto é aprovado: identidade, criptografia, rede privada e governança organizacional — os controles que não impedem nada durante o desenvolvimento e viram bloqueio absoluto na véspera do lançamento.
Perguntas frequentes
❓ Quando usar serviço de IA especializada em vez de modelo generativo?
❓ Dá para combinar serviço especializado com modelo generativo?
❓ Machine learning clássico ainda vale em 2026?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…