OODEval: Evaluating Large Language Models on Object-Oriented Design

O artigo apresenta o OODEval, um novo benchmark e conjunto de métricas (CLUE) para avaliar a capacidade de design orientado a objetos em 29 modelos de linguagem, revelando que, embora alguns LLMs atinjam desempenho comparável ao de estudantes universitários, eles ainda apresentam deficiências semânticas significativas e ficam aquém dos melhores designers humanos.

O essencial

Imagine que você está construindo uma cidade inteira, não com tijolos e cimento, mas com ideias e regras de como as coisas se conectam. Isso é o que chamamos de Design Orientado a Objetos (OOD) no mundo do software. É como desenhar o mapa de uma cidade antes de construir as casas: quem são os prédios (classes), o que eles têm dentro (atributos) e como eles se relacionam (estradas e pontes).

Recentemente, surgiram "cérebros digitais" gigantes chamados Modelos de Linguagem (LLMs), como o GPT-4 ou o Llama. Eles são ótimos escrevendo código, mas ninguém sabia se eles eram bons em planejar essa cidade inteira.

Foi aí que os pesquisadores criaram o OODEval. Vamos entender o que eles fizeram usando algumas analogias simples:

1. O Grande Exame (OODEval)

Antes, não havia um teste padronizado para ver se esses cérebros digitais sabiam desenhar mapas de software. Eles criaram o OODEval, que é como um "vestibular" ou um concurso de arquitetura.

• O que tem nele: 50 desafios, desde construir uma pequena barraca de limonada (fácil) até projetar uma metrópole complexa com trânsito e redes de energia (difícil).
• O formato: Em vez de apenas desenhar no papel, eles pedem que a IA escreva o código do desenho (PlantUML), que é como a "receita" para gerar o mapa visual.

2. O Jogo de Comparação (OODEval-Human)

Para saber se a IA é boa, você precisa comparar com alguém que já sabe fazer isso. Eles criaram o OODEval-Human.

• A analogia: Imagine que você tem 940 desenhos feitos por estudantes universitários de arquitetura, cada um com uma nota dada pelo professor.
• O objetivo: Ver se a IA consegue fazer tão bem quanto a média desses estudantes, ou se ela é um gênio que supera todos.

3. O Juiz Perfeito (CLUE)

Como você julga se um desenho de software está "certo"? Se você apenas comparar palavra por palavra, pode errar (ex: chamar um carro de "veículo" em vez de "carro" não significa que está errado).

• Eles criaram o CLUE, que é como um juiz superinteligente. Ele não olha só as palavras; ele olha a estrutura.
• Ele pergunta: "O prédio tem janelas? Tem portas? As ruas conectam os lugares certos?" Ele dá uma nota baseada na lógica e no significado, não apenas na escrita. E o melhor: esse juiz foi treinado para pensar como um professor humano.

O Que Eles Descobriram? (Os Resultados)

Aqui estão as descobertas principais, traduzidas para o dia a dia:

• A IA é ótima em gramática, mas ruim em lógica profunda:
  A IA consegue escrever o código do desenho sem erros de digitação (como se o estudante escrevesse a letra bonita e legível). Mas, quando se trata de entender como as coisas funcionam juntas (a lógica), ela falha. É como um aluno que escreve o poema perfeitamente, mas não entende a história que está contando.

• Onde a IA mais tropeça:
  Ela é muito boa em criar os nomes dos prédios (classes), mas péssima em criar as "regras de funcionamento" (métodos) e as "pontes" entre eles (relacionamentos). É como se ela desenhasse bem as casas, mas esquecesse de colocar as estradas que ligam a cidade.

• IA vs. Humanos:

  • A média da IA: Ainda é inferior à média dos estudantes universitários.
  • A elite da IA: Os modelos mais avançados (como o Qwen3-Coder-30B) estão chegando perto da média dos estudantes. Eles não são mais "crianças", estão quase no nível de um graduado médio.
  • O topo: Mas, se compararmos com o melhor estudante da turma (o gênio), a IA ainda tem uma grande distância. A IA não consegue, ainda, igualar a criatividade e a precisão de um especialista humano de topo.

• Tamanho importa (mas não só isso):
  Modelos maiores e especializados em código funcionam melhor. É como ter um arquiteto que leu milhões de livros de engenharia. Além disso, modelos que foram "ensinados" a seguir instruções (fine-tuning) são muito melhores do que os que apenas "leram" tudo.

• Onde a IA falha mais:
  Os erros mais comuns são esquecer de colocar uma peça inteira (uma classe), errar o tipo de conexão (colocar uma ponte onde deveria ser um túnel) ou alucinar coisas que não foram pedidas.

Por que isso é importante?

1. Para quem usa IA: Se você quer usar uma IA para ajudar a desenhar seu software, saiba que ela é uma ótima "assistente de rascunho", mas você precisa de um humano experiente para revisar a lógica e as conexões. Não confie cegamente no desenho final.
2. Para escolas e universidades: Como a IA consegue fazer o trabalho de um estudante médio, os professores precisam mudar como avaliam. Não adianta pedir apenas o "desenho final", pois a IA pode fazer isso. Eles precisam avaliar o processo de pensamento e a defesa oral do projeto.
3. Para o futuro: Os pesquisadores agora sabem exatamente onde melhorar as IAs: focar mais na criação de regras complexas e conexões entre as partes.

Em resumo: O OODEval é o teste de realidade que mostrou que as IAs de software estão crescendo rápido e já são úteis, mas ainda precisam de um "chefe humano" para garantir que a cidade planejada não tenha buracos na lógica.

Resumo técnico

1. Problema e Motivação

Os avanços recentes em Grandes Modelos de Linguagem (LLMs) têm sido amplamente avaliados em tarefas de engenharia de software, mas a maioria dos estudos foca na geração de código (nível de sintaxe e testes unitários). Existe uma lacuna significativa na avaliação das capacidades dos LLMs no Design Orientado a Objetos (OOD), especificamente na análise de requisitos naturais e na geração de diagramas de classes.

As principais limitações das pesquisas existentes são:

• Ausência de Benchmarks Padronizados: A maioria dos estudos usa casos isolados ou conjuntos de dados não públicos, simples ou em formato de imagem (difícil de avaliar automaticamente).
• Falta de Métricas Automáticas Robustas: Métricas tradicionais (como BLEU) falham em capturar a estrutura e a semântica de diagramas de classes. Métricas baseadas em embeddings (como BertScore) ignoram detalhes estruturais finos.
• Desconhecimento do Desempenho Real: Não há consenso sobre como os LLMs se comparam a humanos (estudantes ou especialistas) em tarefas de design, nem quais fatores (tamanho do modelo, complexidade da tarefa) influenciam esse desempenho.

2. Metodologia

Os autores propõem um novo framework de avaliação composto por três pilares principais:

A. OODEval (Benchmark de Tarefas)

• Construção: Um conjunto de dados manual com 50 tarefas de OOD, cobrindo requisitos de software até a geração de diagramas de classes.
• Diversidade: As tarefas são divididas em três níveis de dificuldade (Simples, Moderado, Difícil) baseados em métricas como número de classes, métodos, relacionamentos e legibilidade do texto (Flesch-Kincaid).
• Formato: Os dados são fornecidos em código PlantUML (para avaliação automática) e imagens PNG (para revisão humana), garantindo consistência e reprodutibilidade.

B. OODEval-Human (Benchmark Humano)

• Dados: Coletado a partir de 940 soluções submetidas por estudantes de graduação em quatro tarefas de OOD, com notas atribuídas por instrutores.
• Propósito: Serve como "Ground Truth" para comparar o desempenho dos LLMs com o de humanos e para validar a correlação das novas métricas automáticas com a avaliação humana.
• Processamento: As imagens originais dos alunos foram convertidas para PlantUML via LLMs e validadas manualmente por três pesquisadores para garantir fidelidade.

C. CLUE (Class Likeness Unified Evaluation)

• Métrica Proposta: Um conjunto de métricas automáticas para avaliar a similaridade entre o diagrama gerado e o diagrama de referência.
• Funcionamento: Utiliza o modelo CodeBERT para embeddings semânticos e o algoritmo Hungarian para correspondência ótima entre elementos (classes, atributos, métodos, relacionamentos).
• Granularidade: Avalia a similaridade global e local (classe, atributo, método, relação), ponderando a estrutura e a semântica.
• Validação: Os pesos da métrica foram otimizados via Otimização Bayesiana para maximizar a correlação com as notas humanas no conjunto OODEval-Human.

3. Contribuições Principais

1. OODEval: O primeiro benchmark padronizado e público para avaliação de geração de diagramas de classes, com 50 tarefas de múltiplos níveis de dificuldade.
2. OODEval-Human: O primeiro dataset com soluções humanas avaliadas por instrutores, permitindo comparações diretas LLM vs. Humano.
3. Métricas CLUE: Uma nova família de métricas automáticas que superam métodos existentes (BLEU, CodeBERTScore) na correlação com avaliações humanas, capturando tanto estrutura quanto semântica.
4. Estudo Empírico Abrangente: Avaliação de 29 LLMs diversos (incluindo modelos de código, gerais, open-source e fechados) e análise de 5 questões de pesquisa (desempenho geral, comparação humana, dimensões do modelo, características da tarefa e modos de falha).

4. Resultados Chave

Desempenho Geral (RQ1)

• Sintaxe vs. Semântica: Os LLMs apresentam alta precisão sintática (Pass@1 > 80% para a maioria), mas sofrem deficiências significativas na correção semântica.
• Pontos Fracos: A geração de métodos e relacionamentos entre classes é o maior gargalo, especialmente em tarefas difíceis. A geração de nomes de classes e atributos é mais robusta.
• Top Performers: O modelo Qwen3-Coder-30B obteve o melhor desempenho geral, superando modelos online como GPT-4o e DeepSeek-R1. Modelos locais menores, como Gemma3-4B-IT, superaram o GPT-4o-mini.

Comparação com Humanos (RQ2)

• Média vs. Média: Os LLMs de ponta aproximam-se do desempenho médio de estudantes universitários, mas ainda ficam abaixo dos melhores humanos.
• Gap de Pico: Existe uma lacuna considerável entre os melhores LLMs e os melhores estudantes (que atingem quase 100% de acurácia).
• Implicação: Modelos atuais podem realizar tarefas de design no nível de um estudante médio, levantando preocupações sobre integridade acadêmica.

Análise de Dimensões do Modelo (RQ3)

• Fatores de Sucesso: Escala de parâmetros, especialização em código e ajuste fino por instrução (Instruction Tuning) são os principais impulsionadores de desempenho.
• Modelos de Código: Modelos específicos para código (ex: CodeLlama, Qwen-Coder) superam modelos de propósito geral.
• Capacidade de Raciocínio: Modelos com "raciocínio" explícito (RLMs) não mostraram vantagem clara sobre modelos não-RLMs neste contexto específico.

Análise de Características da Tarefa (RQ4)

• Complexidade: O desempenho cai drasticamente com o aumento do número de classes, métodos e relacionamentos.
• Legibilidade: Requisitos com menor legibilidade (menor pontuação Flesch-Kincaid) prejudicam a extração de métodos.
• Relacionamentos: A proporção de generalização (herança) em relação à associação impacta negativamente o desempenho.

Análise de Casos de Falha (RQ5)

• Erros Comuns: Erros de palavras-chave, classes ausentes, associações faltantes e omissão de métodos são os mais frequentes.
• Diversidade de Erros: Modelos como DeepSeek-R1, GPT-4o e Gemma3-IT exibem baixa diversidade de erros (são mais consistentes), enquanto outros modelos cometem uma variedade maior de falhas estruturais.

5. Significado e Implicações

• Para Pesquisa e Desenvolvimento: A necessidade de focar na melhoria da compreensão semântica de métodos e relacionamentos em LLMs. A combinação de forças complementares de diferentes modelos (ensemble) pode ser uma via promissora.
• Para Seleção de Modelos:
  • Recursos Ilimitados: Qwen3-Coder-30B é recomendado para implantação local de alta performance.
  • Recursos Limitados: Gemma3-4B-IT é ideal para fine-tuning devido ao seu baixo custo e alta precisão.
  • Produção: DeepSeek-R1 (API) oferece o melhor equilíbrio entre custo e desempenho.
• Para Educação em Engenharia de Software:
  • Risco Acadêmico: Como os LLMs atingem o nível de estudantes médios, há um risco iminente de plágio e má conduta acadêmica. É necessário mudar a avaliação para focar em processos, defesas orais e ferramentas de detecção de IA.
  • Oportunidade: Os LLMs podem ser usados como ferramentas de apoio para explorar designs, desde que integrados de forma ética no currículo.
• Para Futuros Benchmarks: A necessidade de expandir os conjuntos de dados para incluir designs mais complexos, com mais métodos e relacionamentos de generalização, para refletir cenários reais de software.

Em suma, o OODEval estabelece um padrão rigoroso para avaliar LLMs em design de software, revelando que, embora a sintaxe esteja madura, a semântica do design orientado a objetos ainda é um desafio significativo, exigindo avanços focados na compreensão estrutural e semântica profunda.