A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

Este artigo propõe um framework genérico para avaliar a capacidade de modelos de linguagem em gerar código de linguagens de domínio específico (DSLs) baseadas em restrições, como OCL e Alloy, demonstrando que, embora seu desempenho seja inferior ao de linguagens gerais como Python, técnicas como reparo de código e múltiplas tentativas podem melhorar significativamente a qualidade dos resultados.

O essencial

Imagine que você tem um chef de cozinha extremamente talentoso (o Modelo de Linguagem, ou LLM) que aprendeu a cozinhar lendo milhões de receitas de livros famosos. Ele é incrível fazendo pratos de culinária geral, como pizza, hambúrgueres ou massas (linguagens de programação comuns como Python).

No entanto, o problema surge quando você pede a ele para cozinhar pratos muito específicos e raros, feitos apenas para uma única festa ou com ingredientes que ninguém mais usa (linguagens de programação especializadas, chamadas DSLs, como OCL e Alloy). Como ele nunca viu essas receitas antes, ele tende a errar: coloca sal no lugar do açúcar ou esquece de ligar o forno.

Este artigo apresenta um sistema de avaliação para testar o quanto esse "chef" é bom nessas tarefas difíceis e como podemos ajudá-lo a melhorar.

Aqui está o resumo da pesquisa, explicado de forma simples:

1. O Problema: O Chef e as Receitas Especiais

Os modelos de IA atuais são ótimos em linguagens comuns (como Python) porque há milhões de exemplos na internet para eles aprenderem. Mas, em linguagens de nicho usadas para regras de segurança de sistemas (chamadas OCL e Alloy), há poucos exemplos.

• O Desafio: A IA precisa entender não apenas a regra ("não pode haver mais de 50 funcionários"), mas também o contexto do sistema onde essa regra vive. É como pedir para alguém desenhar uma regra de trânsito sem mostrar o mapa da cidade.

2. A Solução: O "Laboratório de Testes"

Os autores criaram um laboratório de testes (um framework) para avaliar a IA. Eles não apenas pedem para a IA escrever o código e pronto. Eles fazem o seguinte:

• Verificação de Estrutura (Bem-formado): A IA escreveu a receita de forma que dá para ler? (Ex: Ela usou os ingredientes corretos ou inventou um?)
• Verificação de Sabor (Correção): A receita funciona? Ela realmente impede que o carro bata no muro, como foi pedido?

3. O Que Eles Descobriram (As Lições)

Ao testar o "chef" com várias receitas, eles descobriram algumas coisas interessantes:

• O Chef é melhor com pratos comuns: A IA escreve Python (comum) muito melhor do que OCL ou Alloy (específicos). É como se ela fosse um mestre em pizza, mas um iniciante em sushi.
• O Chef precisa de um "Guia de Cozinha":
  • Tentar várias vezes: Se você pedir para o chef tentar 3 vezes, a chance de ele acertar o prato aumenta muito. É como pedir para ele provar e ajustar o tempero várias vezes.
  • Pedir para consertar: Se o prato sair errado, você pode mostrar o erro para a IA e pedir: "Ei, queimou o pão, tente de novo". Isso ajuda muito a melhorar o resultado final.
  • O segredo não é o "papel" (Prompt): Surpreendentemente, mudar muito a forma como você escreve o pedido (o prompt) não faz tanta diferença assim. O que importa mais é qual chef você escolheu e quantas vezes você deixou ele tentar.
• Escolha o Chef certo: Alguns chefs (modelos de IA) são melhores em certos tipos de culinária. Usar um modelo pequeno e barato pode não funcionar para receitas complexas; às vezes, você precisa de um chef mais experiente (modelos maiores).

4. A Conclusão Prática

Se você quiser usar Inteligência Artificial para escrever regras complexas de software:

1. Não confie na primeira tentativa: Deixe a IA tentar várias vezes.
2. Use o "Conserto": Se ela errar, mostre o erro e peça para ela corrigir.
3. Escolha a ferramenta certa: Para linguagens difíceis, não use qualquer modelo barato; escolha um que já tenha visto algo parecido antes.
4. Não se preocupe demais com o texto do pedido: O que importa é a qualidade do modelo e a estratégia de tentativa e erro, não apenas como você formula a pergunta.

Em resumo: A IA é uma ferramenta poderosa, mas para tarefas muito específicas, ela precisa de um pouco mais de paciência (várias tentativas) e de um guia que ajude a corrigir os erros, em vez de apenas esperar que ela acerte de primeira. Os autores criaram um manual para ajudar empresas a fazerem exatamente isso.

Resumo técnico

Título: Um Framework para Avaliar as Capacidades de Geração de Código de Linguagens de Domínio Específico (DSLs) de Restrição com Grandes Modelos de Linguagem (LLMs)

1. Problema

Os Grandes Modelos de Linguagem (LLMs) demonstraram grande eficácia na geração de código para linguagens de programação de propósito geral (GPLs) populares, como Python e Java, devido à vasta quantidade de dados de treinamento disponíveis. No entanto, sua performance degrada significativamente quando aplicada a Linguagens de Domínio Específico (DSLs), especialmente aquelas de baixo recurso (poucos exemplos de código disponíveis) e focadas em restrições formais (como OCL e Alloy).

As principais dificuldades identificadas para DSLs de restrição incluem:

• Baixo recurso: A escassez de dados de treinamento limita a capacidade do LLM de aprender a sintaxe e semântica da linguagem.
• Complexidade de contexto: A geração de código de restrição exige gerenciar simultaneamente a definição do modelo de domínio (esquema) e a aplicação da restrição sobre ele.
• Natureza Declarativa: Diferente de linguagens procedurais, restrições são globais e declarativas, exigindo verificação contra casos positivos e negativos em vez de execução direta.
• Interações Globais: Restrições frequentemente interagem entre si, tornando difícil tratá-las isoladamente sem causar efeitos colaterais indesejados.

A falta de frameworks padronizados para avaliar a qualidade (correção e bem-formação) do código gerado por LLMs nessas linguagens específicas é uma lacuna crítica.

2. Metodologia

Os autores propõem um framework modular e altamente configurável para avaliar a geração de código baseada em LLMs. O framework permite a parametrização de todas as decisões do processo de geração.

Arquitetura do Framework:
O processo é dividido em quatro estágios principais (ilustrados na Figura 1 do artigo):

1. Construção do Prompt (A): O framework suporta diferentes estratégias de prompting, incluindo:
   • Augmentation (Aumento): Uso de técnicas como Chain of Thought (CoT) e fornecimento de descrições de domínio e modelos formais (ex: PlantUML).
   • Task-Oriented Prompting: Estratégias de entrega de tarefas (Lote/Batch, Sequencial em Cadeia, ou Isolada).
   • O framework testa 9 templates de prompt (PT1 a PT9) combinando descrições de domínio, modelos formais e explicações geradas pelo próprio LLM.
2. Geração e Extração (B): O LLM gera o código com base no prompt. O sistema suporta múltiplas tentativas (k-attempts) para o mesmo task.
3. Verificação de Bem-Formação (C): O código gerado é validado sintaticamente e semanticamente usando parsers (ANTLR) e ferramentas de execução (ex: USE para OCL, Alloy Analyzer). Se falhar, um processo de reparo de código (single-pass) é acionado, onde o LLM recebe a mensagem de erro e tenta corrigir o código.
4. Verificação de Correção (D): O código bem-formado é avaliado quanto à sua funcionalidade. O framework utiliza uma abordagem "LLM-as-a-Judge" (usando GPT-4o-mini como juiz) para comparar a saída com a especificação natural, além de validação manual para calibração.

Experimentos:

• Linguagens Alvo: OCL (Object Constraint Language), Alloy e Python (como base de comparação de alto recurso).
• Modelos LLM Testados: DeepSeek Coder 6.7B, Llama 3.1, GPT-4o e GPT-4o-mini.
• Dados: 30 domínios, 182 restrições, totalizando cerca de 98.397 tarefas de geração de código avaliadas.
• Métricas: Accuracy (precisão na primeira tentativa) e pass@k (probabilidade de pelo menos uma das k tentativas ser correta).

3. Principais Contribuições

1. Framework Modular de Avaliação: Uma ferramenta flexível que permite isolar e analisar o impacto de variáveis como template de prompt, escolha do LLM, estratégias de reparo de código e número de tentativas.
2. Estudo Comparativo em DSLs de Restrição: Uma análise aprofundada dos desafios específicos de gerar código em OCL e Alloy, comparando-os com Python, e enriquecendo conjuntos de dados existentes com descrições de domínio sintéticas.
3. Avaliação em Grande Escala: Execução de mais de 90 mil experimentos para identificar a configuração ótima, algo inviável com avaliação puramente manual.
4. Validação de "LLM-as-a-Judge": Demonstração de que LLMs podem substituir avaliadores humanos com precisão razoável (acordo de 85% em métricas de correção), permitindo a escalabilidade da avaliação.

4. Resultados Chave

• Impacto da Linguagem: O Python apresentou o melhor desempenho em bem-formação e correção. OCL e Alloy tiveram desempenho inferior, com taxas de bem-formação significativamente menores, especialmente para modelos de código aberto (DeepSeek, Llama), que muitas vezes falharam em gerar código sintaticamente válido.
• Impacto do LLM: Modelos proprietários (GPT-4o e GPT-4o-mini) superaram amplamente os modelos de código aberto. O GPT-4o foi o melhor geral, sugerindo que seu conjunto de treinamento incluiu exemplos de OCL/Alloy, enquanto o GPT-4o-mini e os modelos open-source tiveram dificuldades com a sintaxe específica dessas DSLs.
• Templates de Prompt: Não houve um "template vencedor" universal. As diferenças de desempenho entre os 9 templates foram estatisticamente insignificantes na maioria dos casos. O PT1 (o mais simples e com menor contagem de tokens) foi recomendado por eficiência.
• Estratégias de Entrega: A entrega de tarefas em lote (batch) foi preferível à entrega isolada para evitar inconsistências no modelo de domínio entre restrições diferentes.
• Reparo e Múltiplas Tentativas:
  • Aumentar o número de tentativas (k) melhora linearmente a probabilidade de sucesso (pass@k), embora com retornos decrescentes.
  • O reparo de código (pedir ao LLM para corrigir o erro) aumentou a taxa de sucesso em 10-20%.
  • A combinação de múltiplas tentativas + reparo de código foi a estratégia mais eficaz, apesar do maior custo computacional.

5. Significância e Conclusão

O artigo estabelece que, para DSLs de baixo recurso como OCL e Alloy, a escolha do modelo LLM e a familiaridade prévia com a linguagem são fatores mais críticos do que o prompt engineering complexo.

Diretrizes Práticas Derivadas:

1. Priorize modelos que já demonstram conhecimento da linguagem alvo (evite modelos open-source pequenos para DSLs complexas).
2. Se o modelo já domina a linguagem, evite engenharia de prompt excessiva; foque em validação automática e múltiplas tentativas.
3. Agrupe restrições relacionadas no mesmo prompt para garantir consistência no modelo de domínio.
4. Utilize estratégias de múltiplas tentativas combinadas com reparo de código para maximizar a qualidade, mesmo que isso aumente o custo.

O framework proposto é um passo fundamental para tornar a geração de código assistida por IA viável em contextos de engenharia de software formal e de domínio específico, oferecendo um método sistemático para avaliar e melhorar essas capacidades. O código e os artefatos do experimento estão disponíveis publicamente para reprodutibilidade.