Resiliência em sistemas de IA: quando tudo que pode falhar eventualmente falha

Um sistema que depende de IA tem mais pontos de falha do que um sistema tradicional equivalente, não porque IA seja inerentemente mais frágil, mas porque adiciona uma camada inteira de comportamento não determinístico em cima de tudo que já podia falhar antes: rede instável, serviço fora do ar, dado inesperado. A pergunta não é se algo vai falhar. É quantas dessas camadas de falha o sistema realmente trata, e quantas ele só espera que nunca aconteçam.

A primeira camada: validar o que entra, antes de gastar token com isso

Boa parte da resiliência de um sistema de IA começa antes de qualquer chamada a um modelo acontecer: validar entrada. Um campo vazio, um formato inesperado, um tamanho de entrada que estoura o limite prático de contexto para aquela tarefa, tudo isso é mais barato de rejeitar na borda do sistema do que de descobrir só depois de já ter gasto uma chamada inteira ao modelo para produzir uma resposta sobre um pedido malformado. Validação de entrada não é exclusiva de sistemas de IA, mas costuma receber menos atenção neles, porque é fácil assumir que o modelo “vai dar um jeito” em qualquer entrada recebida, mesmo quando isso significa gastar recurso tentando interpretar algo que deveria ter sido rejeitado antes.

A segunda camada: o provedor pode simplesmente não responder

Indisponibilidade de provedor, rate limit e timeout são esperados, não exceção. Tratar isso bem envolve retry com backoff para falha transitória, circuit breaker para parar de insistir quando o padrão de falha indica problema persistente, e, quando a criticidade justifica, um provedor alternativo assumindo via fallback. Essa camada específica, incluindo como decidir se vale a pena manter um segundo provedor configurado, já é assunto suficiente para um post próprio, e foi tratada com mais profundidade em outro texto aqui no blog sobre fallback entre modelos.

A terceira camada: a resposta pode vir no formato errado

Mesmo com o provedor disponível e respondendo, o conteúdo da resposta pode não vir no formato esperado: um JSON malformado, uma propriedade obrigatória ausente, um tipo de dado diferente do esperado pelo código que vai consumir aquilo. Suporte nativo a Structured Output, validando a resposta contra um JSON Schema antes dela chegar ao restante do sistema, reduz bastante esse risco, mas não elimina totalmente a necessidade de tratar o caso em que, por qualquer motivo, a resposta ainda chega em formato inesperado.

Degradação graciosa: nem toda falha de formato precisa virar erro para o usuário

Quando o parse de uma resposta falha mesmo depois de toda validação anterior, a pergunta relevante é o que a aplicação faz com isso. Propagar uma exceção genérica para o usuário final é a opção mais simples de implementar e a pior do ponto de vista de experiência. Alternativas mais graciosas incluem: tentar novamente a mesma chamada uma vez, considerando que a falha pode ter sido pontual; cair para uma versão mais simples da resposta, menos rica mas ainda utilizável; ou devolver uma mensagem clara de indisponibilidade temporária daquela funcionalidade específica, em vez de deixar o erro técnico vazar sem contexto nenhum para quem está usando o sistema.

Camadas se somam, não se substituem

Nenhuma dessas camadas sozinha cobre o sistema inteiro. Validação de entrada não impede o provedor de ficar indisponível. Retry e fallback de provedor não garantem que a resposta, quando chega, está no formato certo. Structured Output reduz erro de formato, mas não resolve o provedor estar fora do ar. Um sistema resiliente de verdade trata essas camadas como complementares, cada uma cobrindo um tipo específico de falha que as outras não cobrem, em vez de escolher uma única camada e esperar que ela dê conta de tudo sozinha.

Assumir que vai falhar é mais barato do que descobrir depois

A diferença prática entre um sistema de IA frágil e um resiliente raramente está em usar um modelo melhor ou um provedor mais confiável. Está em quantas dessas camadas foram pensadas de propósito, antes da falha acontecer, contra quantas foram adicionadas correndo, depois de um incidente já ter mostrado exatamente onde faltava proteção. Tudo que pode falhar, eventualmente falha. A única variável real é se isso acontece num ambiente que já esperava por aquilo, ou não.