Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study

Este estudo avalia a eficácia de nove modelos de linguagem de última geração em um curso de programação funcional utilizando OCaml, apresentando três novos benchmarks ($\lambda$CodeGen, $\lambda$Repair e $\lambda$Explain) que revelam que, embora os modelos se destaquem na correção de erros e na explicação de conceitos, sua capacidade de resolver problemas de programação é significativamente menor nesse ambiente de baixa recursos em comparação com linguagens de alto recurso como Python e Java.

O essencial

Imagine que você está aprendendo a cozinhar em uma cozinha muito específica e difícil, onde as regras são estritas e os ingredientes são raros. Neste caso, o "ingrediente raro" é a linguagem de programação OCaml, usada em um curso avançado de programação funcional. E os "ajudantes de cozinha" são as Inteligências Artificiais (LLMs), como o ChatGPT, que prometem fazer tudo por você.

Este artigo é como um teste de culinária rigoroso para ver se esses robôs realmente sabem cozinhar nessa cozinha difícil ou se apenas fazem um bolo bonito por fora, mas que desmorona por dentro.

Aqui está o resumo da história, dividido em partes simples:

1. O Cenário: A Cozinha Difícil (OCaml)

A maioria dos estudos anteriores testou essas IAs em cozinhas comuns e fáceis, como Python ou Java (que são como cozinhas americanas ou italianas, com muitos ingredientes e receitas na internet). Mas os autores deste estudo foram para uma cozinha mais exótica e difícil: a OCaml.

Eles queriam saber: Se um aluno pedir ajuda a uma IA para fazer a lição de casa, a IA vai entregar um prato delicioso ou vai queimar a cozinha?

2. Os Três Testes de Culinária (Os Benchmarks)

Para testar as IAs, os pesquisadores criaram três desafios diferentes, como se fossem três tipos de exames para um chef:

• O Desafio "Criar do Zero" (λCodeGen):

  • A tarefa: A IA recebe uma receita escrita em linguagem natural (ex: "Faça um programa que organize uma lista de livros") e tem que escrever o código do zero.
  • O resultado: As IAs mais inteligentes (como o GPT-4o e o o3-mini) conseguiram cozinhar cerca de 70% dos pratos perfeitamente. Isso é bom, mas não é perfeito. Elas erraram em receitas mais complexas, como as que exigem "continuações" (um conceito de programação muito abstrato, como tentar fazer um soufflé sem saber a química exata).
  • Comparação: Elas foram muito melhores do que ferramentas antigas feitas especificamente para OCaml, mas ainda não são infalíveis.

• O Desafio "Consertar o Prato Queimado" (λRepair):

  • A tarefa: Os alunos entregaram pratos queimados (códigos com erros) e a IA tinha que consertá-los.
  • O resultado: Aqui a IA brilhou!
    • Erros de Sintaxe (esqueceu um ponto e vírgula): As IAs consertaram quase 80% dos pratos. É como se elas soubessem exatamente onde o sal foi colocado errado.
    • Erros de Tipo (misturou açúcar com sal): Consertaram cerca de 75%.
    • Erros Lógicos (o prato tem gosto estranho, mas os ingredientes estão certos): Aqui foi mais difícil. Elas acertaram cerca de 60-70%. É mais difícil explicar por que o sabor está ruim do que apenas apontar que o sal está fora do lugar.

• O Desafio "Explicar a Teoria" (λExplain):

  • A tarefa: Perguntar à IA conceitos teóricos (ex: "Qual a diferença entre avaliação por valor e por nome?").
  • O resultado: As IAs foram ótimas em dar respostas longas e bem escritas, mas muitas vezes erravam a teoria. Foi como um chef que fala muito bem sobre gastronomia, mas às vezes inventa fatos que não existem. Os alunos podem achar a resposta linda, mas ela pode estar errada.

3. As Lições Aprendidas (O Veredito)

• Elas são ótimas assistentes, mas não mestres: As IAs top de linha (o "Top 3") conseguem fazer a maior parte do trabalho, mas ainda cometem erros. Se você confiar cegamente nelas, pode passar uma lição de casa errada.
• O problema da "Alucinação": Às vezes, a IA inventa regras que não existem ou usa funções proibidas pela lição, porque ela está "alucinando" com base em dados de outras linguagens (como Python).
• O perigo da confiança: Os alunos tendem a gostar das respostas das IAs porque elas são bem escritas e detalhadas, mesmo quando estão erradas. É como receber um prato que cheira bem, mas que tem veneno dentro.
• Ferramentas Específicas vs. IAs Gerais: Existe uma ferramenta antiga feita só para OCaml que é muito precisa em tarefas pequenas, mas falha em tarefas grandes. A IA é como um "canivete suíço": ela faz tudo um pouco menos perfeitamente, mas faz tudo de uma vez só. Para um iniciante, o canivete suíço é mais útil.

4. O Conselho Final para Professores e Alunos

• Para os Alunos: Não use a IA como uma "muleta" para fazer a lição. Use-a como um tutor para entender onde você errou, mas sempre verifique se a resposta faz sentido. Aprenda a criticar o que a IA diz.
• Para os Professores: Em vez de pedir apenas "faça o código", peça aos alunos para achar os erros na IA, explicar por que a IA errou ou melhorar o código que a IA gerou. Isso força o aluno a pensar, e não apenas copiar.
• Para os Pesquisadores: Precisamos ensinar as IAs a pensar mais como um cientista da computação e menos como um imitador de padrões.

Em resumo: As IAs são como aprendizes de chef muito talentosos que leram todos os livros de culinária do mundo, mas nunca cozinhou em uma cozinha tão específica quanto a OCaml. Elas são incrivelmente úteis, mas ainda precisam de um "Chef Chefe" (o aluno ou professor) para supervisionar e garantir que o prato final esteja seguro e saboroso.

Resumo técnico

Resumo Técnico: Avaliação de LLMs em um Curso de Programação Funcional

1. Problema e Contexto

Os Modelos de Linguagem de Grande Escala (LLMs) estão transformando a forma como os estudantes aprendem e resolvem problemas de programação. Estudos anteriores demonstraram que esses modelos são eficazes em cursos introdutórios de Ciência da Computação utilizando linguagens de alto recurso (como Python e Java). No entanto, há uma lacuna significativa no conhecimento sobre o desempenho de LLMs em linguagens de baixo recurso (como OCaml) e em contextos educacionais mais avançados, especificamente em cursos de Programação Funcional.

A questão central é: os LLMs atuais conseguem gerar código correto, reparar erros complexos e explicar conceitos teóricos em um paradigma funcional rigoroso, ou eles falham devido à escassez de dados de treinamento específicos? Além disso, existe o risco de os estudantes confiarem excessivamente em respostas que parecem bem articuladas, mas contêm erros lógicos ou conceituais.

2. Metodologia

Os autores desenvolveram um estudo empírico abrangente baseado em três benchmarks específicos, criados a partir de dados reais de um curso de Programação Funcional de 2º ano na Universidade McGill (Canadá). O estudo avaliou 9 LLMs de última geração (incluindo GPT-4o, o3-mini, Claude 3.7 Sonnet, Llama 3.1, Gemini, etc.).

Os três benchmarks são:

• $\lambda$CodeGen (Geração de Código):

  • Dados: 10 tarefas de programação (53 subtarefas) de trabalhos de casa reais.
  • Escopo: Varia de conceitos básicos (padrão de correspondência, recursão) a técnicas avançadas (continuações, backtracking, semântica operacional) e teoria de linguagens de programação (inferência de tipos, unificação).
  • Avaliação: Utiliza compilador OCaml e um autograder para correção, seguido de avaliação manual por assistentes de ensino para verificar design de algoritmo e legibilidade.

• $\lambda$Repair (Reparação de Código):

  • Dados: 150 programas com erros reais de estudantes, divididos em três categorias:
    1. Erros de Sintaxe ($\lambda$RepairSyntax).
    2. Erros de Tipo ($\lambda$RepairType).
    3. Erros Lógicos ($\lambda$RepairProg).
  • Configuração: Avaliação em zero-shot (sem exemplos) e one-shot (com um exemplo) para reparo.
  • Avaliação: O modelo deve corrigir o código para que passe no compilador e nos testes, mantendo a concisão.

• $\lambda$Explain (Explicação Conceitual):

  • Dados: 50 perguntas teóricas extraídas de exames e materiais de preparação.
  • Escopo: Conceitos como escopo de variáveis, indução, avaliação (call-by-value vs. call-by-name) e substituição.
  • Avaliação: Focada na precisão conceitual, estratégia de resolução e clareza da explicação, sem uso de compilador.

Critérios de Avaliação:
Os modelos foram classificados em uma escala hierárquica: Mastery (Domínio), Proficient, Developing, Beginning e Non-gradable. A avaliação manual considerou três pilares:

1. Correção: Passar em todos os casos de teste.
2. Design de Algoritmo: Adequação às especificações do problema (ex: uso de funções de ordem superior permitidas, recursão de cauda).
3. Legibilidade: Concisão e ausência de ruído (verbosidade excessiva).

3. Principais Contribuições

• Novos Benchmarks Específicos: Criação de $\lambda$CodeGen, $\lambda$Repair e $\lambda$Explain, focados exclusivamente em OCaml e programação funcional, preenchendo a lacuna de avaliações em linguagens de baixo recurso.
• Avaliação Híbrida Rigorosa: Combinação de avaliação automatizada (compilador) com avaliação manual detalhada (design e estilo), indo além das métricas simples de "pass/fail" comuns em benchmarks como HumanEval.
• Comparação com Ferramentas Especializadas: Inclusão de uma comparação com o BURST, uma ferramenta de síntese de código específica para OCaml, demonstrando que LLMs gerais superam ferramentas especializadas em tarefas abertas, apesar de terem taxas de erro menores em tarefas muito específicas.
• Análise de Viés e Viabilidade: Identificação de como o tamanho do modelo e o tipo de tarefa (geração vs. reparo vs. explicação) impactam drasticamente o desempenho.

4. Resultados Chave

• Desempenho Geral: Os três melhores modelos (o3-mini, Claude 3.7 Sonnet e GPT-4o) demonstraram alta eficácia, alcançando taxas de "Mastery" entre 69% e 74% em geração de código. No entanto, esses números são significativamente menores do que os observados em benchmarks de Python/Java (onde superam 90%), indicando que o contexto funcional e de baixo recurso é mais desafiador.
• Hierarquia de Desempenho:
  • Top Tier: Modelos comerciais de ponta (o3-mini, Claude, GPT-4o) obtiveram notas finais na faixa de B+ a A-.
  • Bottom Tier: Modelos menores ou open-source (Llama 3.1 8B, Qwen2.5 7B, Gemini 1.5 Flash 8B) tiveram desempenho precário, com muitas respostas "Não graduáveis" (código que não compila) e notas finais de F.
• Geração vs. Reparo vs. Explicação:
  • Reparo de Erros: LLMs performam melhor na correção de erros de sintaxe e tipo (acima de 78% de Mastery para os melhores) do que na correção de erros lógicos (cerca de 60-70%).
  • Explicação Teórica: O desempenho varia drasticamente. O o3-mini alcançou 80% de Mastery, enquanto modelos menores caíram para menos de 20%.
  • Geração de Código: É a tarefa mais difícil. Mesmo os melhores modelos falham frequentemente em seguir restrições específicas (ex: usar recursão de cauda ou evitar funções imperativas).
• Impacto da Dificuldade: O desempenho cai drasticamente em tarefas avançadas de teoria de linguagens de programação (PT) e conceitos abstratos. Modelos menores falharam completamente (0% de Mastery) em questões de inferência de tipos complexas.
• Verbosidade: Um problema recorrente foi a falta de concisão. Mesmo com prompts solicitando respostas curtas, muitos modelos (especialmente Claude e Gemini) forneciam explicações excessivamente longas e fora do tópico, o que foi penalizado na avaliação manual.
• One-Shot Learning: A introdução de um único exemplo de correção (one-shot) melhorou o desempenho de reparo, especialmente para modelos menores (como Llama 70B), reduzindo respostas não graduáveis.

5. Significado e Implicações

• Para Educadores: O estudo fornece evidências concretas para alertar os alunos sobre as limitações dos LLMs. As ferramentas não são confiáveis o suficiente para serem usadas cegamente em cursos avançados. Os instrutores devem adaptar avaliações para focar em crítica, depuração e verificação de código gerado por IA, em vez de apenas na geração de código.
• Para Estudantes: É crucial desenvolver a habilidade de avaliar criticamente as saídas dos LLMs. A confiança excessiva em respostas "bem escritas" pode levar à propagação de conceitos errôneos, especialmente em tópicos teóricos complexos.
• Para a Comunidade de Pesquisa (PL e IA):
  • Há uma oportunidade clara para integrar raciocínio específico de domínio (teoria de linguagens de programação) nos LLMs.
  • Ferramentas especializadas (como BURST) ainda são superiores em tarefas muito restritas e bem definidas, sugerindo que uma abordagem híbrida (LLM + Ferramentas Específicas) pode ser o caminho ideal.
  • A necessidade de mais dados de treinamento de alta qualidade para linguagens funcionais de baixo recurso é evidente.

Em conclusão, embora os LLMs de ponta sejam ferramentas poderosas e adaptáveis para auxiliar no aprendizado de programação funcional, eles ainda não atingem um nível de confiabilidade total para tarefas complexas e teóricas. O estudo destaca a necessidade de uma abordagem crítica e supervisionada na integração de IA na educação de ciência da computação.