Professor criou um bot para corrigir o Exame Estatal Unificado: o modelo classifica e o código calcula a nota

O que acontece quando um modelo de linguagem recebe a tarefa de atribuir uma nota à resposta dissertativa de um estudante? Ele avalia com generosidade: o aluno “em geral entende ciências sociais”, enquanto os critérios do FIPI são rígidos. Um exemplo sobre o “país Z” em vez da Rússia recebe zero, e um plano sem três itens obrigatórios perde todo o critério. Um professor e especialista do Exame Estatal Unificado explicou como passou dois anos construindo um bot que leva tudo isso em conta.

O modelo classifica, o código calcula

O princípio central é que o modelo não escreve: “Dou 2 pontos porque…”. Ele preenche um esquema JSON por meio de tool_use: quais exemplos são específicos, quais afirmações estão corretas e quais itens do plano são essenciais. Em seguida, entra em ação um código convencional: ele recalcula as pontuações com base nos critérios, verifica tudo o que pode ser conferido sem o modelo e executa verificações adicionais que só podem reduzir a nota.

Cada tarefa tem seu próprio plugin: um handler, um avaliador e uma especificação. Não existe um prompt universal. O padrão fica evidente no volume de código: a tarefa 17 ocupa 942 linhas, enquanto as tarefas 24 e 25 têm entre 6,8 mil e 7,2 mil linhas cada. Quanto mais complexos os critérios, mais código é necessário ao redor do modelo — e não um prompt mais longo.

Como não punir uma resposta inocente

Na tarefa 19, o modelo considerava a reformulação da função de um órgão público como um exemplo da atuação desse órgão. O autor adicionou uma segunda chamada com um esquema separado, mas a primeira versão era acionada em todos os casos e retirava pontos de exemplos sobre famílias e cidadãos, mesmo quando o enunciado não mencionava nenhum órgão. Agora, a verificação adicional só é ativada por marcadores explícitos no texto da tarefa. Além disso, um exemplo só é rejeitado quando pelo menos dois de quatro indicadores negativos coincidem. A lição: a proteção contra notas infladas pode, por si só, gerar avaliações baixas demais, e o escopo de ativação é tão importante quanto a própria verificação.

Na tarefa 24, as pontuações do primeiro e do segundo critérios são calculadas inteiramente por código: os lemas são obtidos com pymorphy2 e comparados com 185 planos de referência. Títulos sinônimos, como “atributos” e “características”, são normalizados para uma única forma. O teste é simples: todos os planos de referência devem receber a pontuação máxima. Antes da correção do tratamento de sinônimos, isso ocorria em 147 dos 185 casos; agora ocorre em todos.

Um ponto só pode ser retirado por erro factual depois de passar por quatro filtros: uma lista fechada de tipos de erro, uma citação literal com pelo menos 8 caracteres, duas execuções independentes e um verificador separado. O último é necessário porque duas respostas idênticas do mesmo modelo não equivalem a duas opiniões independentes: nos planos de referência, ambas as execuções encontravam de forma consistente o mesmo erro inexistente.

Uma falha assumida em vez de um zero inventado

O erro mais traiçoeiro é o zero silencioso: o modelo não responde, o código insere zero e o estudante vê o que parece ser uma correção normal. Na tarefa 25, houve 16 zeros desse tipo em 110 casos, e metade deles coincidiu com a referência, entrando nas métricas como acertos exatos. Agora, qualquer falha aciona o indicador ai_unavailable: a nota não é exibida, a tentativa não é descontada e o administrador recebe um alerta. A tentativa gratuita só é descontada depois que o resultado é entregue.

O autor reconhece abertamente o que ainda está incompleto: nas tarefas 21 e 23, uma falha ainda gera uma pontuação simplificada, enquanto o YandexGPT de reserva precisa ser ativado manualmente.

Custo e conclusão prática

Uma execução feita em novembro com 393 respostas gerou 497 chamadas e custou US$ 8,87: em média, 1,26 chamada, 2,3 centavos e 9 segundos por correção. O componente mais caro não são as avaliações longas, mas as verificações adicionais. O cache do prompt cobre até 66% da entrada, mas não é ativado nos prompts curtos das tarefas 17, 21 e 22.

Para quem desenvolve sistemas de avaliação com LLMs: obrigue o modelo a responder em uma estrutura com indicadores explícitos, mantenha a aritmética no código, faça com que as verificações adicionais funcionem em uma única direção, exija execuções independentes e diferencie uma falha de um zero. Nas versões mais recentes do Claude, um tool_choice forçado retorna um erro 400; por isso, envie auto e peça ao modelo que invoque a ferramenta no fim do prompt.