Engenharia para Confiabilidade
Como construir sistemas confiáveis a partir de componentes não confiáveis – e por que isso não é tão novo quanto parece.
O desconforto
Todo desenvolvedor conhece este contrato:
Mesma entrada → mesma lógica → mesmo output. Sempre.
A IA quebra esse contrato. O mesmo prompt, o mesmo modelo, a mesma entrada podem produzir outputs diferentes em execuções consecutivas. Para engenheiros treinados em sistemas determinísticos, isso parece fundamentalmente quebrado.
A resistência não é puramente intelectual. É emocional. Os engenheiros constroem identidade em torno da qualidade do seu output, do controle sobre o comportamento do sistema. Quando um componente produz resultados inconsistentes, isso não desafia apenas uma premissa técnica. Desafia o senso de domínio que torna o trabalho significativo. Reconhecer isso é o primeiro passo para superá-lo.
Não está quebrado. É um tipo diferente de sistema. E requer um tipo diferente de engenharia de confiabilidade.
Você já faz isso
O desconforto é real, mas o problema não é novo. Os desenvolvedores já trabalham com componentes não confiáveis no dia a dia:
- Redes falham. Você faz retry. Adiciona timeouts. Projeta para falha parcial.
- APIs de terceiros mudam. Você versiona. Escreve testes de contrato. Adiciona fallbacks.
- Race conditions existem. Você usa locks, filas e idempotência.
- Usuários fornecem lixo como entrada. Você valida, sanitiza e rejeita.
Nenhum desses sistemas é determinístico no nível do componente. Eles são confiáveis no nível do sistema – porque você projetou confiabilidade em torno de partes não confiáveis.
A IA é o mesmo padrão. O modelo é um componente não confiável. Seu trabalho é construir um sistema confiável em torno dele.
O enquadramento
O software tradicional pergunta: Funciona?
Os sistemas de IA perguntam: Com que frequência funciona?
Este não é um padrão mais baixo. É um mais honesto. O software tradicional também falha – apenas falha de formas que aprendemos a esconder (tratamento de erros, retries, degradação graciosa). A IA torna a não confiabilidade visível em vez de enterrá-la.
Confiabilidade não é "dá sempre a mesma resposta". Confiabilidade é "o sistema funciona consistentemente dentro de limites aceitáveis". Os limites são seus para definir.
O conjunto de ferramentas
A transição de sistemas determinísticos para probabilísticos requer práticas de engenharia específicas. Nenhuma delas é exótica – são a mesma disciplina que você já aplica a sistemas distribuídos, aplicada a um novo tipo de componente.
A avaliação substitui os testes unitários
No software tradicional, os testes verificam outputs exatos. Nos sistemas de IA, você avalia distribuições.
Todo sistema de IA deve ter:
- Um conjunto de dados de avaliação que representa o comportamento esperado
- Execuções de avaliação automatizadas a cada mudança
- Verificações de regressão que detectam degradação
Isso desempenha o mesmo papel de uma suíte de testes. Sem isso, os sistemas de IA degradam silenciosamente – não porque o código mudou, mas porque o modelo mudou.
Guardrails substituem a confiança
O output de LLM quase nunca deve ser confiado diretamente. O modelo fornece raciocínio. O sistema fornece confiabilidade.
Os sistemas em produção devem incluir camadas de validação:
- Outputs estruturados ou schemas que impõem o formato
- Regras de negócio determinísticas que sobrepõem o julgamento do modelo quando apropriado
- Validação de output que detecta alucinações e violações de restrições
- Loops de retry e reparo para falhas recuperáveis
- Revisão humana onde o custo do erro é alto
Os guardrails não são uma admissão de que a IA é ruim. São a engenharia que torna a IA útil.
Etapas menores substituem prompts grandes
Prompts grandes que tentam resolver tudo são frágeis. Eles combinam muitos modos de falha em uma única chamada.
Os sistemas de IA confiáveis decompõem as tarefas:
- Classificar a entrada
- Recuperar contexto relevante
- Gerar output
- Validar estrutura e qualidade
- Reparar se necessário
Cada etapa pode ser avaliada, monitorada e melhorada independentemente. Unidades de raciocínio menores aumentam a confiabilidade pelo mesmo motivo que funções pequenas são mais confiáveis do que monolíticas.
A observabilidade substitui as premissas
Os sistemas de IA em produção devem expor:
- Logs de prompts – o que entrou
- Respostas do modelo – o que saiu
- Pontuações de avaliação – quão bom foi
- Casos de falha – o que deu errado
- Métricas de custo e latência – o que custa
Você não pode melhorar o que não consegue ver. E os sistemas de IA falham de formas invisíveis sem instrumentação – o output parece plausível, mas está errado.
O versionamento substitui a estabilidade
Os modelos de IA evoluem continuamente. Uma atualização de modelo pode mudar o comportamento de formas que nenhuma mudança de código explicaria.
As práticas de engenharia devem incluir:
- Versionamento de modelo – fixe a versão do modelo em produção. Atualize deliberadamente.
- Versionamento de prompt – trate os prompts como código. Rastreie mudanças. Revise diffs.
- Avaliação na atualização – execute sua suíte de avaliação antes e depois de cada mudança de modelo, da mesma forma que você roda testes antes de implantar uma nova dependência.
- Iteração rápida – quando algo quebra, itere rápido. A correção geralmente está no prompt, nos guardrails ou na avaliação – não no modelo.
Trate mudanças de modelo como atualizações de dependência. Você já sabe como gerenciar isso.
A mudança de papel
Nesse modelo, os engenheiros não estão escrevendo lógica principalmente. Eles estão projetando sistemas que supervisionam inteligência. Isso é, estruturalmente, gestão: especificar intenção a um executor imperfeito, avaliar output em vez de controlar o processo, e iterar na sua própria comunicação quando o resultado não corresponde à intenção. Os gestores sempre operaram em um mundo probabilístico. Os engenheiros estão se juntando a eles.
- •Escrever lógica de negócio
- •Implementar algoritmos conhecidos
- •Debugar linha por linha
- •Otimizar caminhos de execução
- •Projetar prompts e interfaces de ferramentas
- •Construir camadas de validação e avaliação
- •Projetar loops de retry e correção
- •Monitorar desempenho em nível de sistema
Isso não é um rebaixamento. É uma mudança para um nível mais alto de abstração, a mesma mudança que aconteceu quando os engenheiros migraram de assembly para linguagens de alto nível, ou de bare metal para infraestrutura em nuvem. Cada transição pareceu perda de controle. Cada uma foi, na verdade, ganho de alavancagem.
O princípio central
Não programamos inteligência. Projetamos ambientes onde a inteligência performa de forma confiável.
A não confiabilidade não é o problema. É a natureza do componente. A engenharia é o que transforma um componente não confiável em um sistema confiável.
Isso não é novo. É o que os engenheiros sempre fizeram.
← Voltar para o início · O Lab de IA · Padrões de Execução de IA · O Framework de Referência