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, pontuando e produzindo um arquivo todas as manhãs. Enquanto 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 um deles é um sinal para investigar mais de perto. Três juntos significam que a decisão já foi tomada para você.

Mudanças pequenas 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 se tornaram o processo. As pessoas exportam a saída e corrigem em uma planilha antes que qualquer um use. 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 a perguntas básicas sobre ele. Por que esse cliente foi recusado em março? Qual versão estava em execução quando os números mudaram? Se ninguém conseguir responder sem uma semana de escavação, você está exposto a riscos regulatórios e de reputação que não foram quantificados.
O conhecimento vive em uma ou duas pessoas. Cada mudança depende da mesma pessoa. Eles não estão guardando nada; são simplesmente 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 capacidade 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 é necessário. Um incidente barulhento também não é evidência — incidentes tendem a ocorrer em 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 parte do balanço recebe um número. Coloque um valor na outra parte antes de tomar uma decisão.

Adicione o que o sistema atual consumiu nos últimos doze meses: horas de engenharia em manutenção e incidentes, a fatura do fornecedor e dos computadores, as horas que as pessoas passam corrigindo manualmente abaixo da linha, e o valor das mudanças que o negócio pediu e não recebeu. Este último item é geralmente o maior e quase nunca é contabilizado. Depois, olhe para 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 dirige.

Reconstrua em fatias e mantenha os dados

Reconstruir não significa um programa de dois anos com uma data de mudança. Os sistemas que se substituem 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, 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 mudança.

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

A maioria das organizações espera cerca de um ano a mais do que deveria. 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 cabe a você, e vale fazer antes do próximo ciclo orçamentário, não depois.