Como construir produto de IA que não quebra quando o modelo muda

O problema

Muita feature com IA nasce assim:

• escolhe um modelo
• ajusta prompt até “ficar bom”
• conecta no produto
• sobe para produção

Enquanto tudo parece funcionar, o time relaxa.

Aí acontece uma destas coisas:

• o provedor lança versão nova
• o preço muda
• a latência piora
• o formato da resposta vem diferente
• a aderência a instrução cai
• a ferramenta que o modelo chamava muda de comportamento

E de repente o produto quebra por um motivo meio humilhante:

• ele dependia de um comportamento que nunca foi contrato

Esse é o ponto central.

Muita equipe diz que tem “produto com IA”.

Na prática, tem um fluxo frágil preso ao jeito específico como um modelo estava se comportando naquela semana.

Modelo mental

Pense assim:

trocar modelo é trocar uma dependência probabilística, não só atualizar um fornecedor de texto.

Essa frase ajuda porque quebra uma fantasia comum.

Não é só “colocar outro modelo para responder parecido”.

Quando o modelo muda, várias coisas podem mudar junto:

• qualidade
• estilo
• formato
• sensibilidade ao prompt
• uso de contexto
• latência
• custo
• comportamento em caso ambíguo

Então produto robusto não é o que ama um modelo específico.

É o que continua funcional mesmo quando o modelo muda dentro de uma faixa razoável.

Quebrando o problema

O erro raiz é acoplamento implícito

O produto quebra quando o time acopla fluxo a coisas como:

• ordem exata de campos em texto livre
• tom específico da resposta
• decisão sempre igual para caso ambíguo
• chamada de ferramenta em formato não validado
• presença de uma frase que “costuma vir”

Isso é perigoso porque parece estável até deixar de ser.

Modelo probabilístico não te deve consistência perfeita nesse nível.

Se o seu sistema precisa disso, você precisa criar a camada de contrato por cima.

Contrato vem antes de preferência de modelo

Antes de discutir qual modelo usar, vale definir:

• qual entrada o sistema aceita
• qual saída o produto precisa
• o que conta como resposta válida
• o que acontece quando a resposta vem incompleta
• o que acontece quando a confiança está baixa

Exemplo de contrato útil:

• resposta precisa vir em JSON válido
• campos obrigatórios precisam existir
• categorias aceitas são fechadas
• ausência de confiança suficiente manda para fallback

Isso reduz a dependência de estilo e aumenta a dependência de interface.

E interface é bem mais governável do que “o modelo geralmente responde desse jeito”.

Prompt bom não substitui pós-processamento e validação

Esse erro aparece muito.

O time tenta resolver robustez só com prompt:

• “responda sempre nesse formato”
• “não invente”
• “nunca deixe campo vazio”

Isso ajuda.

Mas não é controle suficiente.

Se o produto depende de estrutura, você ainda precisa de:

• parser
• validação
• tratamento de erro
• fallback

Prompt orienta.

Validação protege.

Confundir essas duas coisas é como usar comentário de código no lugar de teste.

Troca de modelo precisa de eval de regressão

Se você muda modelo sem avaliação comparativa, está basicamente apostando.

O mínimo saudável costuma ser:

1. separar casos representativos
2. rodar modelo antigo e novo no mesmo conjunto
3. comparar erros importantes
4. revisar regressões críticas
5. observar custo e latência junto com qualidade

Porque modelo novo pode:

• escrever melhor
• mas errar mais nos casos difíceis

Ou:

• ficar mais barato
• mas aumentar fallback manual

Sem eval, a equipe enxerga só a parte que queria ver.

Robustez também é fallback

Produto robusto não depende de “o modelo não vai falhar”.

Depende de saber o que fazer quando falha.

Fallback pode ser:

• regra simples
• fluxo manual
• resposta mais limitada
• feature parcialmente desativada
• encaminhamento para humano

O importante é o usuário não descobrir, no pior momento, que o sistema inteiro só existia enquanto o modelo acertava.

Observabilidade precisa separar problema de modelo e problema de produto

Quando algo degrada, você precisa conseguir responder perguntas como:

• a taxa de resposta inválida subiu?
• o custo por requisição mudou?
• a latência piorou?
• o fallback aumentou?
• o problema apareceu em um tipo específico de input?

Sem isso, toda troca de modelo vira debate confuso.

Com isso, você consegue dizer:

• “a qualidade geral subiu, mas o modelo novo piorou exatamente no fluxo de cobrança”

Isso é gestão de sistema.

Não torcida.

Rollout gradual existe para IA também

Muita gente pensa em rollout gradual só para backend e deploy.

Mas troca de modelo também merece:

• shadow test
• amostra pequena de tráfego
• comparação paralela
• critério de rollback

Se o seu plano de troca é “subimos e vemos”, o produto ainda está imaturo.

Exemplo simples

Imagine uma feature que classifica ticket e sugere resposta inicial.

Com o modelo atual, o time já sabe que a feature funciona “bem”.

Só que o provedor aumentou preço e vocês querem trocar.

Jeito frágil de fazer:

1. apontar para o modelo novo
2. ajustar prompt por um dia
3. subir

Problemas que podem aparecer:

• JSON volta com campo faltando
• categoria vem fora da lista esperada
• o novo modelo pede mais contexto
• a latência sobe e piora UX
• respostas parecem boas, mas aumentam retrabalho do suporte

Jeito melhor:

1. manter parser e schema de saída rígidos
2. rodar os dois modelos no mesmo conjunto de tickets
3. comparar classificação, formato, custo e latência
4. liberar para pequena fatia do tráfego
5. medir fallback e correção manual
6. manter rollback simples

Aqui a diferença não é “ter processo bonito”.

É que o segundo caminho trata mudança de modelo como mudança real de dependência.

Erros comuns

Tratar comportamento atual como contrato

Se o fluxo depende do modelo “geralmente responder assim”, ele já está frágil.

Medir só qualidade textual

Produto também depende de:

• estrutura
• latência
• custo
• estabilidade
• taxa de fallback

Trocar tudo de uma vez

Mudar modelo, prompt, chunking e uso de ferramentas ao mesmo tempo dificulta saber o que causou a regressão.

Não ter modo degradado

Sem fallback, qualquer oscilação do modelo vira incidente visível para o usuário.

Não observar erro por tipo de caso

Às vezes a média geral fica parecida, mas um fluxo crítico piora bastante.

Como um senior pensa

Um senior costuma olhar para esse problema e pensar:

• “onde exatamente estamos acoplados ao comportamento implícito do modelo?”
• “quais partes precisam de contrato explícito?”
• “qual falha é tolerável e qual quebra a feature?”
• “se eu trocar de modelo amanhã, o que eu consigo validar antes?”

Ele também entende uma coisa importante:

produto robusto com IA não nasce de escolher o melhor modelo.

Nasce de desenhar o sistema para sobreviver quando o modelo não se comporta exatamente como você queria.

Isso inclui:

• interfaces claras
• validação
• evals
• fallback
• rollout controlado
• observabilidade

O modelo importa.

Mas a arquitetura ao redor importa mais do que muita equipe admite.

O que o entrevistador quer ver

Quando alguém pergunta sobre isso em entrevista, normalmente quer entender se você enxerga IA como brinquedo de prompt ou como dependência de produção.

Uma resposta forte costuma mostrar:

1. que modelo pode mudar em qualidade, custo, latência e formato
2. que o produto não deve depender de comportamento implícito
3. que existe contrato de saída, validação e fallback
4. que a troca deve passar por eval comparativa
5. que rollout e observabilidade reduzem risco operacional

Se você responder só:

• “eu testaria outro modelo e veria qual parece melhor”

fica fraco.

Se você responder:

• “eu isolaria a interface, compararia regressão com casos reais, liberaria gradual e manteria fallback”

fica bem mais maduro.

Porque isso mostra engenharia de sistema, não só familiaridade com ferramenta.

Produto de IA quebra menos quando depende de contrato e fallback, e não do humor de um modelo específico.

Maturidade aqui não é escolher o modelo certo para sempre. É conseguir trocar de modelo sem transformar a troca em incidente.