Do protótipo à produção
O que separa um demo bonito de um sistema de IA confiável em produção.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Todo demo de IA funciona na primeira apresentação. O problema começa quando você tenta colocar isso em produção e o modelo alucina, o custo explode, o timeout estoura e ninguém sabe por quê. A distância entre um protótipo bonito e um sistema confiável não é pequena, mas é cruzável se você souber o que adicionar e em que ordem.
O vale entre demo e produção
Um protótipo de IA tem três características que o tornam enganosamente bom: você controla os inputs, você está presente para corrigir falhas na hora, e você não tem volume real. Retire qualquer um desses três e o sistema começa a mostrar suas rachaduras.
O "vale" é o conjunto de problemas que só aparecem em produção: inputs inesperados que quebram o prompt, latência variável do modelo que estoura o SLA, custos que sobem com o uso real, dados sensíveis que vazam pelo contexto, e ausência de visibilidade para diagnosticar qualquer coisa disso.
A boa notícia: esses problemas são conhecidos e têm soluções de engenharia. Não é magia, é a mesma disciplina que você já aplica em APIs e pipelines de dados, adaptada para sistemas que têm um componente não-determinístico no meio. As aulas anteriores cobriram cada peça isolada (avaliação na aula 09, guardrails na aula 10, ferramentas na aula 07). Esta aula conecta tudo em uma jornada de prontidão.
Jornada do protótipo à produção
Cada fase adiciona uma camada de confiabilidade. Você não precisa de tudo no dia um, mas precisa saber onde está no mapa.
- Prompt fixo · no código
- Modelo único · sem fallback
- Evals contínuos · (golden set)
- Versionamento · de prompts
- Traces / spans · por chamada
- Medição de tokens · e custo
- Guardrails · (input + output)
- PII redaction · antes do contexto
- Timeout + retry · exponencial
- Fallback de modelo · ou resposta padrão
- Idempotência · em tool calls
- Coleta de feedback · (thumbs / flags)
- Sinal para ajuste · de prompt / modelo
O que adicionar, e por quê cada peça importa
Avaliação contínua é o seu cinto de segurança. Sem um golden set de casos testados a cada deploy, você não sabe se uma mudança de prompt melhorou ou quebrou o comportamento. Mantenha pelo menos 30–50 casos representativos e rode os evals no CI antes de qualquer promoção.
Observabilidade com traces é diferente de logging tradicional. Você precisa de spans que cubram: latência da chamada ao modelo, tokens consumidos (input + output), qual versão do prompt foi usada, e o resultado do guardrail. Ferramentas como AWS CloudWatch, Langfuse ou OpenTelemetry com exportador customizado resolvem isso. Sem isso, você está voando às cegas.
Versionamento de prompts parece burocracia até o dia que você precisa reverter. Trate prompts como código: hash, changelog, e rollback. Não deixe o prompt viver só na cabeça de alguém ou em um .env sem histórico.
Limites de custo devem ser hard limits, não alertas. Defina um teto de tokens por usuário por hora e um teto global diário. Sem isso, um loop de agente mal configurado ou um usuário abusivo pode gerar uma conta inesperada antes do próximo ciclo de monitoramento.
Degradação graciosa significa que quando o modelo primário falha ou está lento demais, o sistema responde com algo útil, seja um modelo menor, uma resposta cacheada, ou uma mensagem honesta de que o serviço está temporariamente limitado. Silêncio ou erro 500 são piores do que uma resposta parcial.
Na prática, o erro mais comum que vejo é times que instrumentam o front-end mas esquecem de rastrear o que acontece dentro do loop do agente. Você vê a requisição entrar e a resposta sair, mas não vê quantas tool calls foram feitas, qual delas demorou, ou qual retornou dado incorreto. Trace cada passo do agente como se fosse uma transação distribuída, porque é exatamente isso que é.
Confiabilidade, segurança e o loop de melhoria
Timeouts e retries em chamadas de modelo não são opcionais. Modelos grandes têm latência variável, p99 pode ser 3–5x o p50. Defina um timeout agressivo (ex: 15s para respostas síncronas) e implemente retry com backoff exponencial e jitter. Mas atenção: retry sem idempotência em tool calls pode causar efeitos colaterais duplicados. Se a ferramenta escreve no banco ou envia e-mail, ela precisa ser idempotente ou você precisa de um mecanismo de deduplicação.
Segurança e privacidade têm duas frentes. A primeira é a proteção contra prompt injection, coberta na aula 10, que exige guardrails tanto na entrada quanto na saída. A segunda é privacidade de dados: nunca envie PII diretamente ao modelo sem necessidade. Faça redação antes de montar o contexto, e revise o que vai para o histórico de conversas armazenado.
O loop de melhoria é o que separa sistemas que ficam bons de sistemas que ficam obsoletos. Colete feedback estruturado (thumbs up/down, flags de resposta incorreta), armazene com o trace correspondente, e use isso para atualizar o golden set de evals e eventualmente ajustar prompts ou trocar de modelo. Sem esse loop, você está operando no escuro, e a qualidade vai degradar silenciosamente com mudanças de modelo ou de dados do mundo real.
A aula 17 (Bedrock AgentCore) e a aula 18 (Knowledge Bases) mostram como a AWS gerencia partes desse ciclo. Mas a responsabilidade de definir o que é "bom" e de fechar o loop de feedback é sempre sua.
Ordene a jornada à produção
Do protótipo a um sistema operável.
- 1Operar, monitorar e melhorar continuamente
- 2Adicionar avaliação (evals) e medir qualidade/custo
- 3Protótipo funcional com prompt + modelo
- 4Adicionar guardrails, observabilidade e limites de custo
Checklist de prontidão para produção
- 1
Evals no CI
Golden set com pelo menos 30 casos. Nenhum deploy sem passar nos evals.
- 2
Prompts versionados
Hash + changelog + capacidade de rollback em menos de 5 minutos.
- 3
Traces por chamada
Latência, tokens, versão do prompt, resultado do guardrail, tudo em um span rastreável.
- 4
Guardrails ativos
Validação de input e output. PII redactado antes de entrar no contexto.
- 5
Limites de custo configurados
Hard limit de tokens por usuário/hora e teto diário global. Alerta antes de 80% do teto.
- 6
Timeout + retry + fallback
Timeout definido, retry com backoff, e resposta de fallback para quando o modelo primário falha.
- 7
Tool calls idempotentes
Toda ferramenta com efeito colateral tem chave de idempotência ou deduplicação.
- 8
Loop de feedback ativo
Coleta de feedback ligada ao trace. Processo definido para atualizar evals e prompts.
Perguntas frequentes
Preciso de tudo isso antes do primeiro deploy em produção?
Não, mas precisa de um subconjunto mínimo: evals básicos, timeout/retry, e guardrails de input. O resto você adiciona nas primeiras semanas. O que não pode é ir a produção sem nenhuma dessas peças.
Como versionar prompts sem uma ferramenta dedicada?
Git resolve o problema básico. Coloque os prompts em arquivos de texto no repositório, com nome semântico e changelog no commit. Se quiser mais controle, o Bedrock Prompt Management ou o Langfuse têm versionamento nativo.
O que é um 'golden set' de evals na prática?
É uma coleção de pares (input, output esperado ou critério de avaliação) que representa os casos mais importantes do seu sistema, incluindo casos felizes, casos de borda, e casos que já falharam antes. Você roda esses casos a cada mudança e compara o resultado com o esperado, seja por match exato, por LLM-as-judge, ou por métrica customizada.
O que vem a seguir
A próxima aula é o projeto guiado: você vai construir um sistema completo, do RAG ao agente, aplicando cada uma dessas camadas. O checklist desta aula é o seu critério de aceitação. Se o projeto passar em todos os itens, você tem um sistema que pode ir a produção de verdade.