When Uncertainty Isn't Enough: An Empirical Study of Self-Correction in Code Generation

No mundo da inteligência artificial, os grandes modelos de linguagem tornaram-se notavelmente habilidosos na escrita de código de computador. Eles podem receber uma descrição simples de uma tarefa e produzir um programa funcional que a resolva. No entanto, esses assistentes digitais têm um ponto cego: frequentemente produzem códigos quebrados sem sequer perceberem que estão quebrados. Ao contrário de um programador humano, que poderia pausar e conferir novamente um cálculo complexo, o modelo simplesmente emite sua resposta, esteja ele confiante ou não, sem qualquer sinal de alerta para o usuário. Isso cria um ciclo frustrante onde os usuários devem testar manualmente cada código gerado para ver se ele funciona, desperdiçando tempo e poder computacional em soluções que falham. Pesquisadores há muito esperam que, se conseguissem ensinar esses modelos a reconhecer sua própria incerteza — essencialmente dando a eles um senso de dúvida quando não estão seguros —, poderiam construir sistemas que corrigissem seus próprios erros antes de mostrar o resultado a um humano.

Uma equipe de pesquisadores decidiu testar essa ideia no contexto específico da escrita de código. Eles queriam saber se métodos desenvolvidos para medir a incerteza na linguagem natural, como escrever ensaios ou responder perguntas, funcionariam tão bem quanto para o mundo rígido e lógico da programação. Eles também queriam ver se usar esses sinais de incerteza para disparar a autocorreção realmente tornaria o código melhor. A equipe testou cinco maneiras diferentes de medir o quão inseguro um modelo estava sobre sua resposta. Alguns métodos analisavam a matemática interna que o modelo usou para escolher cada palavra, enquanto outros pediam ao modelo que simplesmente declarasse o quão confiante se sentia, ou geravam múltiplas versões do mesmo código para ver o quanto elas diferiam. Eles realizaram esses testes em três modelos de codificação diferentes usando dois conjuntos padrão de desafios de programação.

Os resultados revelaram uma divisão acentuada entre o que funciona e o que não funciona. A maneira mais confiável de dizer se o código estava correto envolvia gerar muitas versões diferentes da solução e verificar quais delas passavam nos testes, um método que mostrou uma ligação muito forte com o sucesso real. No entanto, essa abordagem é cara e lenta porque exige que o modelo faça o trabalho de escrever código muitas vezes. Os métodos mais baratos e rápidos que os pesquisadores esperavam que servissem como um sistema de alerta rápido falharam amplamente. As técnicas que analisavam a matemática interna do modelo ou pediam que ele avaliasse sua própria confiança mostraram quase nenhuma capacidade de prever se o código realmente funcionaria. Na verdade, para modelos menores, pedir ao modelo que avaliasse sua própria confiança produziu números que eram essencialmente ruído aleatório.

Quando os pesquisadores tentaram usar esses sinais de incerteza fracos para corrigir o código, o resultado foi pior do que esperavam. Eles construíram um sistema que reescreveria o código automaticamente sempre que o modelo parecesse inseguro. Em vez de melhorar os resultados, essa abordagem tornou o código pior na maioria dos casos. Em cinco de seis configurações diferentes que testaram, o sistema de autocorreção na verdade reduziu a taxa de sucesso, fazendo com que os modelos produzissem mais códigos quebrados do que se tivessem apenas deixado a primeira resposta como estava. A única estratégia que consistentemente melhorou a qualidade do código foi aquela que dependia de executar o código contra um conjunto de casos de teste para verificar se estava correto. Isso sugere que, para a geração de código, o sentimento interno de dúvida de um modelo não é uma ferramenta útil para corrigir erros por conta própria.

O estudo conclui que, embora os sinais de incerteza não sejam fortes o suficiente para substituir a necessidade de realmente executar e testar o código, eles ainda podem ter um papel a desempenhar. Os pesquisadores sugerem que esses sinais baratos e imperfeitos poderiam ser usados como um porteiro. Em vez de tentar corrigir o código por conta própria, o sistema poderia usar uma verificação rápida de incerteza para decidir quando vale a pena gastar o tempo e o poder computacional extras para executar os testes de verificação completos e caros. Dessa forma, o sinal de incerteza atua como uma chave que liga a verificação pesada apenas quando é mais necessária, em vez de tentar ser a solução em si. As descobertas desafiam a esperança de que os modelos possam simplesmente aprender a ser mais cuidadosos por conta própria, apontando, em vez disso, para a necessidade de verificações externas para uma geração de código confiável.