Inkling 2 Small xingou 316 vezes, mas os palavroes quase nao ajudaram a prever falhas

As vezes, um modelo quebra de uma forma quase humana: comete varios erros, declara que “nada funciona”, xinga e continua gerando texto. Pesquisadores da Vals AI encontraram exatamente esse comportamento nos registros internos do Inkling 2 Small, da Thinking Machines. O detalhe engracado rapidamente se transforma em uma questao de engenharia: palavras emocionalmente carregadas podem indicar com antecedencia que o modelo perdeu o caminho para a solucao?

A resposta curta e nao. Os palavroes chamam a atencao, mas funcionam mal como sinal de falha. Para um desenvolvedor, e mais util observar a repeticao de frases, o tamanho da geracao, o consumo de tokens e a ausencia de progresso em direcao ao resultado do que o vocabulario do modelo.

O que os registros revelaram

Os pesquisadores examinaram 2.655 execucoes em 13 testes. A palavra “fuck” e suas variantes apareceram em 50 execucoes, 316 vezes no total. Desses casos, 241 vieram de apenas duas geracoes que ficaram presas em loops.

O episodio mais ilustrativo ocorreu em uma tarefa de calculo da trajetoria de um asteroide. Em vez de apresentar uma solucao compacta, o modelo gerou cerca de 500 mil caracteres: repetiu as mesmas frases e usou o palavrao 158 vezes. Isso ja nao era uma questao de tom. Uma resposta assim desperdica recursos computacionais, aumenta a latencia e pode ocupar o contexto da proxima etapa de um processo com agentes.

O efeito foi especialmente frequente no ProgramBench, aparecendo em 20 de 200 execucoes. Em geral, o modelo xingava depois de cometer o proprio erro, durante um aparente avanco ou antes de desistir de novas tentativas. O padrao e reconhecivel: a solucao nao fecha, o monologo interno fica mais agressivo e, em seguida, a geracao e interrompida ou entra em repeticao.

Por que esse e um detector de erros ruim

A primeira vista, a correlacao parece forte: 46 das 48 execucoes avaliadas que continham palavroes terminaram em falha. Mas a taxa geral de falhas ja era de cerca de 75%. Mais importante ainda: 96% de todas as execucoes malsucedidas nao continham palavrao algum.

Imagine um servico que marque uma resposta como suspeita quando um palavrao aparece no registro interno. Ele realmente detectaria alguns acidentes chamativos, mas deixaria passar a esmagadora maioria dos erros. Seria como monitorar o superaquecimento de um servidor pelo cheiro de plastico: quando aparece, e um sinal grave, mas esperar por ele significa monitorar tarde demais.

Os palavroes podem continuar sendo um sinal diagnostico adicional, mas nao e possivel construir a protecao em torno deles. Eles tambem dependem do idioma, dos dados de treinamento e das configuracoes do modelo. Depois de uma atualizacao do modelo, esse indicador pode desaparecer, embora os loops continuem existindo.

O que os desenvolvedores devem fazer

Sistemas em producao precisam de sinais ligados a propria falha. Limite o numero maximo de tokens e o tempo de execucao. Conte trechos repetidos, monitore o crescimento repentino da resposta e encerre a geracao se o modelo passar varias etapas consecutivas sem se aproximar de um resultado verificavel. Em sistemas com agentes, defina um limite de tentativas e registre o motivo da interrupcao separadamente do texto de raciocinio.

Tambem e util verificar o resultado por meios externos: executar testes para codigo, validar numeros, exigir uma resposta estruturada ou recorrer a um avaliador separado. O registro interno pode ajudar na investigacao de um incidente, mas nao deve ser a unica fonte da verdade.

A conclusao pratica e simples: o vocabulario incomum do modelo e um sintoma interessante, nao uma metrica confiavel. Se um sistema consegue produzir 500 mil caracteres repetidos, o controle da geracao e a primeira coisa que precisa ser corrigida. Um dicionario de palavras proibidas e cosmetico; limites, um detector de loops e a verificacao do resultado sao a protecao de verdade.