Desenvolvedor criou um simulador de leitura de código — e se deparou com o não determinismo do LLM

Um desenvolvedor do Habr lançou um projeto inusitado: um treinador onde você não escreve código, mas lê um fragmento funcionando e o explica com suas próprias palavras — e um modelo de linguagem avalia a qualidade da sua explicação. A ideia é simples, mas a implementação se mostrou inesperadamente complexa.

De onde veio a ideia

Duas irritações se acumularam gradualmente. A primeira era meu próprio código de dois meses atrás: em princípio tudo é claro, mas você tem que lê-lo mais tempo do que gostaria. A segunda foi tentar explicar a arquitetura do projeto a amigos: você sabe tudo perfeitamente bem, mas fala em fragmentos, tropeça nas palavras, não consegue conectar seus pensamentos em um todo coerente. O treinador surgiu desses dois problemas.

A mecânica é simples: você vê um fragmento de código funcionando de verdade, explica com suas próprias palavras — oralmente ou por escrito — e recebe uma avaliação de um LLM. Nenhuma escrita de código, apenas leitura e explicação. Algo entre uma revisão de código e uma conversa com um mentor.

A ideia em si não é nova — explicar código em voz alta é usado em programação em par e em entrevistas técnicas. Mas uma versão automatizada, sempre disponível, já é interessante.

Onde quebrou: não-determinismo do LLM

Escrever o treinador em si se mostrou simples. As dificuldades começaram ao configurar a avaliação. A tarefa parece trivial: dar ao modelo dois textos — o código e a explicação do usuário — e pedir para avaliar como um descreve bem o outro. Na prática, o modelo se comportava de forma imprevisível:

• Para a mesma explicação, dava pontuações diferentes em solicitações repetidas
• Valorizava alguns aspectos do código injustamente alto, ignorava outros sem razão
• A "rigorosidade" do avaliador mudava de solicitação para solicitação sem padrões visíveis
• Era impossível dizer o que contar como uma boa explicação — abrangente ou concisa?

Este é o não-determinismo clássico do LLM — uma propriedade que todos conhecem teoricamente, mas que é sentida agudamente precisamente quando você precisa de uma função de avaliação reproduzível do modelo, e não geração de texto.

O que exatamente avaliar

O desenvolvedor descobriu que o principal problema não é técnico, mas conceitual: o que conta como uma boa explicação de código? Deve ser abrangente — cobrindo todos os ramos, casos extremos, efeitos colaterais? Ou é suficiente transmitir com precisão a ideia principal do algoritmo? Você deve mencionar possíveis bugs? A terminologia é importante? O explicador deve demonstrar entendimento do porquê esse código foi escrito, não apenas o que faz?

Sem respostas claras, qualquer critério de avaliação para um LLM fica vago — e o modelo preenche a incerteza arbitrariamente. Este é precisamente o motivo pelo qual a engenharia de prompts para tarefas de avaliação é significativamente mais complexa do que para tarefas generativas.

Possíveis abordagens técnicas: prompts rigorosos com rubricas específicas, votação em múltiplas solicitações independentes ao modelo, explicações de referência como benchmark. Mas primeiro você precisa determinar exatamente o que está medindo.

"A parte mais difícil se mostrou não escrever o treinador, mas fazer a

rede neural avaliar honesta e consistentemente — e entender exatamente o que precisa ser avaliado"

O que isto significa

A história ilustra uma armadilha típica de projetos com LLM: a parte que parece mais simples — "o modelo avaliará" — na verdade requer mais esforço de engenharia do que todo o resto do produto. A tarefa de treinar a habilidade de ler e explicar código é uma necessidade real, especialmente em equipes com grandes quantidades de código legado. Mas construir um avaliador automatizado confiável para tais habilidades práticas continua sendo um desafio de engenharia aberto.