Reparar ou Reconstruir: Cinco Sinais de que um Sistema de IA Chegou ao Fim do Caminho

Um sistema de IA raramente morre de uma maneira que exija uma decisão

Ele continua respondendo, continuando a pontuar, continuando a produzir um arquivo todas as manhãs. Enquanto isso, a equipe contorna o problema, os pedidos de mudança se acumulam e o gasto anual cresce sem que alguém decida aumentá-lo. O fim da vida chega como um aumento lento no custo de manter o sistema em funcionamento, exatamente o tipo de custo que nunca aparece na agenda.

Portanto, a decisão é adiada. Reconstruir parece caro e disruptivo; continuar parece gratuito. Não é gratuito, e a tarefa de um líder aqui é notar o momento em que os custos de manutenção superam o custo de substituição.

Os cinco sinais

Estes são os que se mantêm consistentes entre diferentes indústrias e tipos de sistemas. Qualquer sinal individual é um alerta para investigar mais. Três juntos significam que a decisão já foi tomada para você.

Pequenas mudanças deixaram de ser pequenas. Uma regra de precificação que levava dois dias para ajustar no primeiro ano agora leva três semanas e afeta quatro outras coisas. O sistema acumulou tantos casos especiais que ninguém consegue prever o alcance de uma mudança.
Os contornamentos tornaram-se o processo. As pessoas exportam a saída e corrigem-na em uma planilha antes que alguém a utilize. Essa planilha agora tem um proprietário, uma convenção de nomenclatura e um backup. O sistema real é o contorno; o oficial é uma fonte de dados.
Você não consegue responder às perguntas básicas sobre ele. Por que o sistema rejeitou este cliente em março? Qual versão estava em execução quando os números mudaram? Se ninguém puder responder sem uma semana de escavação, você está enfrentando exposição regulatória e reputacional que não foi contabilizada.
O conhecimento reside em uma ou duas pessoas. Cada mudança aguarda a mesma pessoa. Elas não estão guardando nada; simplesmente são a única cópia sobrevivente das decisões de design. Isso é um risco de pessoal disfarçado como técnico.
A restrição mudou. O sistema foi construído ao redor de uma limitação que não existe mais — uma janela de contexto, um limite de latência, um preço por chamada, uma funcionalidade que precisava de três componentes e agora precisa de apenas um. Grande parte do que você mantém é estrutura para um problema que desapareceu.

O que não é um sinal

Um único trimestre ruim de qualidade de saída geralmente é um problema de dados, não de design. Um novo lançamento de modelo não é motivo para reconstruir nada; se o seu sistema estiver bem estruturado, trocar o modelo é uma mudança de configuração e você deve testar se é isso. Um incidente barulhento também não é evidência — incidentes ocorrem em torno de sistemas visíveis, não frágeis.

A distinção importante é entre um sistema que está funcionando mal e um sistema que ficou caro de mudar. O primeiro é consertável. O segundo é um veredicto estrutural, e nenhuma quantidade de remendo reverte isso.

Preze pelo custo da manutenção, não apenas pela reconstrução

As propostas de reconstrução perdem porque apenas uma das partes do balanço recebe um número. Coloque um valor na outra parte antes de tomar a decisão.

Adicione o que o sistema atual consumiu nos últimos doze meses: horas de engenharia em manutenção e incidentes, a conta do fornecedor e do computador, as horas que as pessoas passam corrigindo manualmente para baixo, e o valor das mudanças que o negócio solicitou e não recebeu. Este último item é geralmente o maior e quase nunca é contabilizado. Em seguida, compare com os mesmos doze meses dois anos atrás. Se a linha estiver subindo enquanto a saída está plana, você tem sua resposta, e está em uma moeda que um conselho argumenta.

Reconstrua em fatias e mantenha os dados

Reconstruir não significa um programa de dois anos com uma data de troca. Os sistemas que se adaptam bem são substituídos uma capacidade de cada vez: levante o novo caminho para uma fatia estreita do tráfego, execute-o ao lado do antigo, compare as saídas em casos reais, mova a fatia para lá, repita. O sistema antigo permanece no ar até que a última fatia deixe. Em nenhum momento o negócio depende de um único final de semana de troca.

A única coisa digna de ser mantida é os dados — os exemplos rotulados, as correções, o registro do que o sistema errou e como as pessoas o corrigiram. Essa avaliação acumulada é o verdadeiro ativo valioso. O código ao seu redor é substituível e, em algum momento, deve ser substituído.

A maioria das organizações espera cerca de um ano a mais do que o necessário. O custo desse ano raramente é visível, que é exatamente por que precisa ser medido. Construímos nossa prática em torno de carregar esse peso para nossos clientes, mas a medição está em suas mãos e vale a pena fazer antes do próximo ciclo orçamentário, não depois.