Boas práticas integradas e práticas para operar IA sem desperdiçar dinheiro

• Para operar LLMs e plataformas de IA com estabilidade em ambientes de produção, é necessário um método de design centrado na arquitetura capaz de responder a mudanças
• Para se preparar para mudanças de modelo e API, separe todas as chamadas de IA em serviços e aplique um padrão de migração com execução dupla
• Ao usar o Flex service tier da OpenAI, é possível reduzir os custos em 50% com o mesmo modelo e a mesma qualidade de dados
• Coloque os dados repetidos no início do prompt para maximizar a eficiência do uso de cache tokens e pagar apenas 10% do custo
• Para evitar custos excessivos, é essencial implementar Rate Limiting e Circuit Breaker no backend

---

Estratégia de integração de IA preparada para mudanças

• Modelos e APIs de IA mudam continuamente, e a forma como algo funciona hoje pode falhar a qualquer momento
• Em vez de seguir ferramentas ou modelos individuais, o essencial é projetar sistemas capazes de se adaptar à mudança
• O objetivo do uso de IA não é perseguir a tecnologia mais recente, mas sim operação estável e controle de custos

Padrão de migração (The Migration Pattern)

• Extraia todas as chamadas de API de IA para serviços, tratando internamente conexão, composição de prompts e prompts específicos
• Esses serviços devem operar em estado de migrabilidade permanente (permanent migratability), permitindo sempre usar a versão e o modelo mais recentes ou a versão anterior
• Houve problemas ao migrar do GPT 4.1 para o GPT-5
  • Um prompt perfeitamente ajustado para GPT 4.1 perdeu confiabilidade no GPT-5, como ao omitir chaves JSON
  • O GPT-5 prefere structured JSON schemas em vez de JSON simples
  • É preciso explicar a abordagem de definir chaves e valores possíveis e preenchê-los no prompt
• Implementação da estratégia de migração
  • Durante um período específico ou em ambientes de teste/staging, execute simultaneamente o prompt e modelo antigos e o prompt e modelo novos
  • Também são possíveis estruturas de dados e chamadas de API completamente diferentes (a OpenAI recomenda migrar de chat-style API para response-style API)
  • Registre os resultados de ambos os lados e, se houver diferenças importantes, o sistema deve avisar e mostrar o diff
  • O servidor de execução dupla gera custo em dobro, mas permite entender como diferenças entre modelo antigo e novo, e entre prompts, afetam qualidade, previsibilidade e confiabilidade
• É especialmente útil para análise em background, processamento de dados e análise semântica, não apenas para usos puramente conversacionais
• Se o novo resultado não atender às expectativas, é possível fazer rollback para a versão legada a qualquer momento
• Como sistemas de API acabam sendo deprecated em algum momento, estar preparado para migração é essencial
• Verificar o diff de dados JSON ajuda a reconstruir prompts
  • É possível usar Claude Code ou OpenAI Codex para ajustar prompts até que os resultados dos dois lados fiquem semelhantes
• Esse padrão se aplica a todos os serviços que se comunicam com modelos externos de ML
• Se um novo serviço apresentar degradação repentina, basta trocar a chave para voltar à versão anterior e recuperar dados confiáveis como antes

O segredo das camadas de serviço (The Service Tier Secret)

• Serviços em nuvem oferecem service tiers, com preços diferentes conforme a importância da chamada de API
• No caso da OpenAI
  • default tier: o preço exibido no site
  • batched requests: bem mais baratas, mas como não dá para saber quando o lote será preenchido e processado, não servem para tarefas semissíncronas
  • Flex tier: metade do preço da camada padrão
    • Pode ser 50% mais lenta e ficar indisponível em certos momentos, mas oferece o mesmo modelo e a mesma qualidade de dados
• Casos de uso do Flex tier
  • Aplicado a tarefas de backend (extração de convidados, análise do conteúdo falado, resumos etc.)
  • Com o recurso de auto-retries do SDK da OpenAI, não é necessária lógica extra
  • Implementação de fallback em caso de erro 429: tentar algumas vezes com Flex e, se falhar, trocar para a camada standard e tentar de novo
• Resultados em larga escala
  • Redução imediata de 50% nos custos (o Flex tier fica disponível na maior parte do tempo)
  • Quando há muitos tokens de entrada e poucos de saída (grandes transcrições de podcast → poucos dados JSON resumidos), cache tokens também custam metade
  • É possível dobrar o volume de extração e inferência, melhorando a qualidade da plataforma e aumentando a conversão
• Pontos a verificar em cada plataforma
  • O preço de Batch é igual ao custo de processamento do Flex
  • Preços Flex existem para GPT-5, 5.1, o3 e o4
  • Codex, Pro, GPT-4o e ferramentas de áudio em tempo real podem não ter Flex disponível com facilidade
• Se existe uma camada de preço e você não a usa, isso é negligência financeira (financial negligence)
• Se for preciso resultado rápido mesmo em momentos de congestionamento, é possível configurar a Priority tier (preço dobrado, resposta mais rápida)
  • Priority também pode não existir para alguns modelos
• Como os modelos e formas de uso variam, a implementação e a otimização precisam ser flexíveis

Front-loading para eficiência de cache (Front-Loading for Cache Efficiency)

• Quando há muitos dados para analisar, coloque as partes repetidas no início
• Coloque o prompt de sistema primeiro e, se os mesmos dados forem analisados várias vezes, comece o prompt com esses dados
• Ordem do prompt
  1. Prompt de sistema (explicação do papel)
  2. Instruções de sistema sempre iguais ("extraia os dados neste formato")
  3. Dados que podem se repetir entre prompts
  4. Instruções específicas de cada prompt
• Os dados colocados no início são tratados como cache tokens, e você paga apenas 10% do custo dos demais tokens
• Caso real de uso
  • Inserir primeiro a transcrição completa e, ao final dela, as instruções específicas da tarefa (encontrar um convidado específico, identificar patrocinadores, tratar perguntas de clientes etc.)
• Como verificar a otimização de vários prompts
  • Coloque os prompts como dados no Claude Code ou em uma conversa no ChatGPT e peça uma análise de otimização
  • Não aceite o resultado da IA cegamente; use-o apenas como referência (IA é previsão de tokens, então dizer que algo é mais útil não significa que realmente seja)
  • Analisar vários prompts ao mesmo tempo pode gerar insights significativos

Rate Limiting e Circuit Breakers

• Ao usar plataformas externas com custo baseado em tokens, Rate Limiting é obrigatório
• Onde aplicar Rate Limit
  • Ações voltadas ao cliente que disparam interações com IA
  • Interações com IA que podem ser enviadas pelo servidor de backend
• É preciso evitar situações em que, por race condition, o mesmo processo reinicia repetidamente e dispara a mesma chamada várias vezes (mesmo com cache tokens, ainda há custo)
• Detecção de anomalias
  • Se o consumo de tokens de IA em um certo período subir para 10x o normal, é preciso receber alerta e ter como interromper
• Implementação de Circuit Breaker
  • Um circuit breaker geral para todas as funções de IA da aplicação ou para partes específicas
  • Um recurso de feature toggle com ativação/desativação por comando Laravel ou interface administrativa
  • Até recursos de auto-onboarding, como um botão de "gerar configuração incrível", devem poder ser ligados/desligados
  • Se alguém automatizar isso e gerar centenas de dólares por hora em custo, o toggle deve bloquear imediatamente
• Feature toggles devem ser implementados no backend, não no frontend (o controle precisa estar no ponto real de ocorrência)
• Uso de AI scan
  • Usar ferramentas de agentic coding para escanear o código, identificar pontos onde chamadas de IA podem ser exploradas e onde adicionar toggles
• Todo uso de IA deve obrigatoriamente passar pelo sistema de backend
  • Não faça chamadas diretas da plataforma de IA pelo client-side usando tokens (isso já é uma prática ruim por si só)
  • Só passando pelo backend é possível ligar/desligar recursos e receber alertas de alto uso
• Camadas de proteção implementadas
  • Rate limits em todas as funções
  • Rate limits para usuários do frontend
  • Rate limits no backend
  • Feature toggles
  • Alertas de abuso de funcionalidade (por conta, tipo de assinante e IP)
• Espera-se que essas funções passem a existir por padrão nas ferramentas e frameworks no futuro, mas hoje ainda é preciso implementá-las manualmente

Lição principal: construir sistemas preparados para mudanças

• Como o ambiente de IA muda sem parar (modelos, APIs e preços), é impossível acompanhar tudo
• O ponto central da operação de IA não é o modelo mais recente, e sim projetar sistemas que consigam se adaptar quando ocorrerem mudanças
• Componentes essenciais:
  • Padrão de migração
  • Otimização de service tiers
  • Caching de prompts
  • Rate limiting
  • Circuit breakers
• Esses itens não são apenas nice-to-have, e sim a base para evitar prejuízos ao operar IA em produção
• A partir do momento em que você usa IA em produção, custo e estabilidade deixam de ser um problema técnico e passam a ser um problema de arquitetura

"Build for Change" — construa a base para a mudança