Dívida técnica oculta em aprendizado de máquina, dez anos depois

A Figura 1 de "Hidden Technical Debt in Machine Learning Systems" é um diagrama de caixas. Configuração, coleta de dados, extração de atributos, verificação de dados, gerenciamento de recursos de máquina, ferramentas de análise, gerenciamento de processos, infraestrutura de serviço e monitoramento cercam uma única caixa preta pequena, rotulada código de ML. A legenda diz tudo numa frase: apenas uma pequena fração dos sistemas reais de ML é composta pelo código de ML, e a infraestrutura em volta é vasta e complexa. Em outro ponto do artigo, D. Sculley e nove colegas do Google deram um número a uma das partes. Um sistema maduro, escreveram, pode acabar tendo no máximo 5% de código de aprendizado de máquina e no mínimo 95% de código de cola.

O artigo saiu no NeurIPS em dezembro de 2015. O argumento era incômodo para um campo que vivia resultados rápidos. O aprendizado de máquina oferece um conjunto de ferramentas fantasticamente poderoso para construir depressa sistemas úteis de previsão, começa o resumo, e depois adverte que é perigoso pensar que esses ganhos rápidos vêm de graça. O vocabulário do artigo virou padrão para quem opera modelos em produção, e dez anos depois vale relê-lo com uma pergunta específica: quais de suas categorias sobreviveram à passagem de classificadores e modelos de ranqueamento para sistemas construídos sobre grandes modelos de linguagem, quais cresceram e quais foram quitadas?

O que o artigo argumentava

A ideia central é o emaranhamento, e os autores deram à sua consequência o nome de princípio CACE: Changing Anything Changes Everything (mudar qualquer coisa muda tudo). Num modelo que combina muitos sinais, nenhuma entrada é de fato independente das outras. Adicionar um atributo, remover outro, ou mudar um hiperparâmetro, um método de amostragem ou um limiar de convergência desloca o comportamento do conjunto, de modos que não dá para isolar. As fronteiras estritas de abstração, a ferramenta que torna o software comum sustentável, são corroídas porque o comportamento de um modelo é aprendido dos dados e não especificado em código.

Várias outras categorias decorrem disso. Consumidores não declarados são sistemas que começam, sem alarde, a usar a saída de um modelo, de modo que mudar o modelo quebra algo de que ninguém na equipe sabia que dependia. Ciclos de retroalimentação ocultos surgem quando as previsões de um modelo influenciam os dados com que ele será treinado depois. Dependências de dados custam mais que dependências de código porque são mais difíceis de analisar: entradas instáveis cujo significado muda sob os pés do modelo e entradas subutilizadas que acrescentam fragilidade sem ganho. O código de cola se acumula em torno de pacotes de uso geral, e as selvas de pipelines crescem onde etapas de preparação de dados foram acrescentadas uma a uma. Caminhos de código experimentais mortos se empilham como condicionais no código de produção que eram convenientes para um teste e nunca foram removidos. A configuração vira dívida quando é grande, frágil e mal revisada.

O artigo termina com cinco perguntas para avaliar a dívida de um sistema. Com que facilidade uma abordagem algorítmica inteiramente nova pode ser testada em escala real? Qual é o fecho transitivo de todas as dependências de dados? Com que precisão o impacto de uma nova mudança pode ser medido? Melhorar um modelo ou sinal degrada outros? Em quanto tempo novos membros da equipe podem ser postos a par? Os autores acrescentam uma ressalva que vale lembrar: andar depressa muitas vezes introduz dívida, e a ausência de problemas não é prova de dívida baixa, já que o custo total só se revela com o tempo.

Onde os juros se acumulam em sistemas com LLMs

Leve as cinco perguntas a uma aplicação típica construída sobre um modelo de linguagem hospedado, digamos um assistente de suporte com recuperação, algumas ferramentas e um longo prompt de sistema. As categorias reaparecem com roupas novas.

O emaranhamento agora tem um gatilho externo. Em 2015, quem mudava um atributo estava na equipe. Numa aplicação com LLM, o modelo base pode mudar por baixo de você. Os provedores aposentam modelos em calendários publicados, e a documentação de preços da Anthropic em outubro de 2026 lista vários modelos mais antigos como aposentados, com disponibilidade restante só em certas plataformas de nuvem. Um modelo substituto da mesma família de nomes e, em tese, das mesmas capacidades seguirá instruções de modo um pouco diferente, formatará a saída de modo um pouco diferente e recusará coisas diferentes. Todo prompt escrito para o modelo antigo foi sintonizado, de forma implícita, aos hábitos dele. É o CACE, com o agente da mudança fora do prédio.

O prompt é configuração escrita em linguagem natural, e carrega as piores propriedades da dívida de configuração. É grande, já que prompts de sistema com vários milhares de tokens são comuns. Não tem sistema de tipos. Seus diffs são difíceis de interpretar, porque uma mudança de uma palavra pode alterar o comportamento em todo lugar e uma mudança de trinta linhas pode não alterar nada. E raramente é revisado com o rigor que se dá ao código, em parte porque quem o edita inclui gerentes de produto e líderes de suporte que não estão no processo de revisão de engenharia. A recomendação do artigo para configuração, de que uma mudança deve ser fácil de ver, fácil de verificar com afirmações e revisada por inteiro, vale sem alterações. As ferramentas para fazê-lo são mais escassas.

Os consumidores não declarados se multiplicam quando a saída é texto. Um pipeline que pede ao modelo que devolva JSON ganha consumidores para cada campo. Um painel conta com que frequência as respostas contêm certa expressão. Um script adiante divide uma resposta em quebras de linha e lê a terceira linha. Nenhum deles foi declarado como dependente da formatação do modelo, e todos quebram quando ela muda. O remédio é antigo: ponha um contrato na saída, com um esquema, imposto por recursos de saída estruturada onde o provedor os oferece e validado em código onde não oferece.

Os ciclos de retroalimentação passam pelo texto gerado. Se as respostas de um assistente são salvas como artigos na base de conhecimento da qual o mesmo assistente recupera, os erros se reforçam: uma resposta errada, depois de indexada, é recuperada como evidência para a seguinte. A literatura sobre colapso de modelos, como o estudo de 2023 de Ilia Shumailov e colegas mostrando que treinar com dados gerados faz as caudas de uma distribuição desaparecerem, trata de treinamento. A mesma dinâmica opera em escala menor na hora da recuperação, e nada numa arquitetura típica marca quais documentos do índice foram escritos pelo sistema.

A proporção de código de cola provavelmente foi no sentido oposto. Quando o modelo é uma chamada de API, o "código de ML" na caixa preta são poucas linhas e quase todo o resto é cola: montagem do prompt, recuperação, interpretação da saída, novas tentativas, cache, wrappers de ferramentas, scripts de avaliação. Os arcabouços de agentes acrescentam uma camada que envolve essas, o que o artigo teria identificado como um pacote de uso geral cujas premissas ficam travadas. O conselho dele, de envolver pacotes caixa-preta em APIs comuns para que possam ser trocados, continua sendo o melhor disponível.

Os caminhos de código experimentais mortos são os mais fáceis de subestimar. Uma variante de prompt atrás de uma flag, uma segunda estratégia de recuperação em teste, um modelo reserva acrescentado por causa de um incidente: cada um é barato de adicionar e caro de aposentar, porque ninguém lembra o que a flag faz. A história de alerta mais vívida vem de fora do aprendizado de máquina. Em 1º de agosto de 2012, os sistemas de negociação da Knight Capital enviaram milhões de ordens não intencionais em cerca de 45 minutos, o que, segundo o próprio documento da empresa na SEC, custou aproximadamente US$ 461 milhões. Segundo a ordem posterior da SEC, conforme resumida em relatos secundários, uma antiga função de roteamento de ordens sem uso desde 2003 nunca havia sido removida, uma flag foi reaproveitada para acionar código novo e um dos oito servidores não recebera a atualização, de modo que ali a flag despertou a função antiga. Um ramo que ninguém limpou, somado a uma chave de configuração cujo significado mudou, encerrou a trajetória da Knight como empresa independente.

O conselho de monitoramento do artigo ainda funciona

A seção sobre mudanças no mundo externo oferece conselhos de monitoramento que se transferem quase sem alteração. Os autores sugeriram comparar a distribuição dos rótulos previstos com a dos observados, o que chamaram de verificação de viés de previsão. Está longe de ser um teste completo, já que um modelo que sempre prevê a média passa nele, mas é barato e detecta deriva depressa. A versão para LLMs é um conjunto de verificações de distribuição nas saídas: a fração de respostas que recusam, o comprimento mediano e do percentil 95, a fração que falha na validação de esquema, o número de chamadas de ferramenta por conversa, a fração que cita uma fonte. Nenhuma delas diz se uma resposta está correta. Cada uma se move quando algo mudou a montante, seja um provedor que atualizou um modelo, um documento do índice que foi substituído ou uma edição de prompt que foi ao ar, e um gráfico delas ao longo de semanas dá um aviso precoce que uma avaliação de qualidade, que roda com menos frequência, confirmará depois.

O segundo conselho é o limite de ação. Onde um sistema toma ações no mundo, como enviar mensagens ou conceder créditos, os autores recomendaram definir limites amplos que não disparem sem motivo, com alertas automáticos e intervenção manual quando um deles for atingido. Um assistente que pode emitir reembolsos deve ter um teto por reembolso e por hora, imposto fora do modelo, e uma violação deve chamar uma pessoa. O limite não torna o sistema correto. Torna o pior caso limitado, o que permite à equipe dormir enquanto o modelo muda de comportamento por baixo.

Um último item é cultural, e o artigo o nomeia. Ele observa que a separação entre pesquisadores que constroem modelos e engenheiros que os operam gera atrito, e propõe pôr os dois nas mesmas equipes. A versão para LLMs é a distância entre quem escreve prompts, muitas vezes especialistas de produto ou de domínio, e quem mantém os sistemas em volta deles. Um prompt que um especialista edita num console web, sem revisão nem testes, é uma mudança de produção com outro nome. Qualquer processo que governe o código deve governar o prompt.

O que foi quitado

Nem tudo piorou. As ferramentas que o artigo de 2015 desejava existem agora de alguma forma: rastreadores de experimentos que registram quais dados, código e configurações produziram um modelo, repositórios de atributos que dão ao treino e ao serviço a mesma definição de um atributo, bibliotecas de validação de dados que conferem as entradas contra expectativas, registros de modelos que anotam o que está implantado. Em 2017, Eric Breck, Sculley e colegas publicaram o ML Test Score, uma rubrica de 28 testes e necessidades de monitoramento específicos para julgar a prontidão para produção. Uma equipe que adota qualquer lista de verificação séria desse tipo tornou a sua dívida visível, que é o primeiro passo para geri-la.

Para sistemas com LLMs, o equivalente é a suíte de avaliação: um conjunto fixo de casos que roda a cada mudança no prompt, no índice de recuperação ou no modelo. Ela faz o papel de testes unitários para um sistema cujo comportamento não pode ser especificado em código, e responde diretamente à terceira e à quarta perguntas do artigo, que tratam de medir o impacto de uma mudança e de perceber quando melhorar uma coisa degrada outra.

As cinco perguntas, reescritas

As perguntas finais do artigo se traduzem bem. A coluna da direita é o que uma equipe deveria conseguir responder numa revisão, com evidências.

Pergunta original	Num sistema com LLM	Como é uma boa resposta
Com que facilidade uma nova abordagem algorítmica pode ser testada em escala real?	Conseguimos trocar o modelo, ou o método de recuperação, e rodar a avaliação completa em um dia?	Um script e um painel, não um projeto
Qual é o fecho transitivo das dependências de dados?	Quais documentos, ferramentas e APIs podem influenciar uma resposta, e quem é o dono de cada um?	Uma lista que alguém mantém atualizada
Com que precisão o impacto de uma mudança pode ser medido?	Uma edição de prompt vem com pontuações de antes e depois e um intervalo?	Sim, em cada pull request
Melhorar um modelo ou sinal degrada outros?	A correção de um modo de falha causa regressão em outro?	A suíte é fatiada por modo de falha
Em quanto tempo novos membros podem ser postos a par?	Um engenheiro novo consegue explicar por que o prompt de sistema diz o que diz?	Cada instrução tem um motivo registrado

A última linha é a menos técnica e a mais reveladora. Um prompt de sistema em que cada linha existe por causa de um incidente que ninguém lembra é um conjunto de regras sem procedência, e regras sem procedência não podem ser apagadas com segurança. Anexar um motivo curto e um caso de teste a cada instrução é barato na hora de escrever e caríssimo de reconstruir depois.

Dívida é um empréstimo, não um pecado

A ideia de dívida tem uma leitura lisonjeira e uma pouco lisonjeira. A lisonjeira é que assumir dívida para entregar mais cedo às vezes é a decisão certa. Um protótipo que comprova demanda antes do fim do trimestre pode justificar um prompt bagunçado e um monte de cola. A pouco lisonjeira é que a maior parte da dívida não é escolhida. Acumula-se por decisões que pareciam razoáveis cada uma, e seu custo é invisível até que a aposentadoria de um modelo, uma auditoria ou um incidente o torne concreto.

O que separa um empréstimo de uma armadilha é se a dívida é visível e tem dono. Uma equipe consegue responder às cinco perguntas acima para o seu maior sistema com LLM em uma hora. As perguntas que ela não consegue responder são a dívida, e anotá-las com um nome ao lado de cada uma é a gestão de risco mais barata disponível. Vale agendar essa hora para a próxima tarde tranquila.

Fontes

Sculley, D., Holt, G., Golovin, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28.
Breck, E., Cai, S., Nielsen, E., Salib, M., Sculley, D. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. IEEE Big Data 2017.
Anthropic. Pricing e descontinuação de modelos, documentação para desenvolvedores do Claude (modelos aposentados em outubro de 2026). platform.claude.com/docs/en/about-claude/pricing.
Shumailov, I., Shumaylov, Z., Zhao, Y., Gal, Y., Papernot, N., Anderson, R. (2023). The Curse of Recursion: Training on Generated Data Makes Models Forget. arXiv:2305.17493.
Knight Capital Group (2012). Formulário 8-K e documentos relacionados na Securities and Exchange Commission dos EUA, agosto de 2012; U.S. Securities and Exchange Commission (2013), ordem no caso Knight Capital Americas LLC.