💻 computer science

Leveraging LLMs for Multi-File DSL Code Generation: An Industrial Case Study

Este estudo de caso industrial na BMW demonstra que o ajuste fino de LLMs orientados a código com uma representação JSON estruturada e que preserva caminhos das hierarquias de repositórios supera significativamente a abordagem de prompting de base e o aprendizado de um único exemplo na geração de artefatos DSL precisos e multiarquivo que impulsionam a geração de código a jusante.

Autores originais: Sivajeet Chand, Kevin Nguyen, Peter Kuntz, Alexander Pretschner

Publicado 2026-04-28

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Sivajeet Chand, Kevin Nguyen, Peter Kuntz, Alexander Pretschner

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um arquiteto mestre trabalhando para uma gigante empresa de construção (BMW). Sua função é projetar novos edifícios (configurações de mercado) para diferentes cidades.

No antigo modo de fazer as coisas, você tinha que escrever manualmente cada planta, cada projeto elétrico e cada diagrama hidráulico em pedaços separados de papel. Se você quisesse adicionar uma nova janela à cozinha, tinha que lembrar de atualizar o projeto elétrico, o projeto hidráulico e o projeto estrutural, todos perfeitamente sincronizados. Se você perdesse um único detalhe minúsculo, todo o edifício não poderia ser construído, e a equipe de construção (o gerador de código) ficaria travada.

Este artigo trata de ensinar um assistente robótico superinteligente (um Modelo de Linguagem de Grande Escala, ou LLM) a fazer essa papelada manual por você. Mas há uma pegadinha: o robô nunca viu seus projetos específicos antes, e ele precisa atualizar múltiplos documentos interconectados de uma só vez com base em apenas uma frase de instrução sua.

Veja como os pesquisadores ensinaram o robô a fazer isso:

1. O Problema: O Enigma "Uma Instrução, Muitos Arquivos"

Geralmente, a IA é boa em escrever uma única história ou um único trecho de código. Mas, nesta empresa, um único pedido como "Adicionar um novo tipo de empréstimo para o mercado alemão" exige a alteração de arquivos em cinco pastas diferentes. Se o robô alterar o arquivo principal, mas esquecer de atualizar o arquivo que lista todos os tipos de empréstimo, todo o sistema quebra.

2. A Solução: Achatar a Biblioteca

Para ajudar o robô a entender todo o projeto de uma só vez, os pesquisadores não alimentaram o sistema arquivo por arquivo. Em vez disso, eles pegaram toda a "biblioteca" de projetos (a estrutura de pastas) e a achataram em um único livro gigante e organizado (um único documento JSON).

A Analogia: Imagine pegar uma mesa bagunçada com 20 pastas diferentes e espalhar cada página individual sobre uma única mesa gigante, mantendo-as em fileiras organizadas para que você saiba qual página pertence a qual pasta. Agora, o robô pode olhar para toda a mesa de uma vez e dizer: "Certo, vejo onde as alterações precisam ser feitas".

3. O Treinamento: Três Maneiras de Ensinar o Robô

Os pesquisadores tentaram três maneiras diferentes de ensinar o robô a realizar esta tarefa específica:

O "Início Frio" (Zero-Shot): Eles apenas deram ao robô a instrução e o livro achatado e disseram: "Conserte isso".
- Resultado: O robô era razoável em manter as páginas na ordem correta, mas frequentemente inventava detalhes errados ou perdia conexões minúsculas. Era como um aluno que conhece o alfabeto, mas ainda não aprendeu a gramática.
O "Exemplo" (One-Shot): Eles deram ao robô a instrução, o livro, mais um exemplo de um trabalho anterior feito corretamente. "Veja como adicionamos uma janela da última vez; faça assim".
- Resultado: Isso ajudou o robô a acertar a estrutura (as páginas permaneceram nas pastas corretas), mas ele ainda lutava com os detalhes específicos e complicados do novo pedido.
O "Curso Intensivo" (Fine-Tuning): Eles pegaram o robô e mostraram a ele centenas de exemplos de projetos "Antes" e "Depois". Eles não apenas mostraram; ajustaram o cérebro interno do robô (usando uma técnica chamada QLoRA) para que ele aprendesse as regras específicas dos projetos desta empresa.
- Resultado: Este foi o vencedor. O robô tornou-se um especialista. Ele podia olhar para um pedido e produzir um conjunto perfeitamente sincronizado de alterações em todos os arquivos.

4. Os Resultados: Funcionou?

Os pesquisadores testaram o robô com tarefas reais e pediram a especialistas humanos que verificassem o trabalho.

Estrutura: O robô ajustado foi quase perfeito em manter os arquivos nas pastas corretas e não inventar pastas falsas. Ele obteve uma pontuação perfeita (1,0) em manter a "forma" do projeto correta.
Detalhes: Foi muito bom no conteúdo real, acertando cerca de 66% das alterações exatamente e 84% das alterações "suficientemente próximas" para serem úteis.
A Realidade do "Quase": O robô era tão bom que, quando falhava, geralmente era apenas um pequeno erro de digitação ou um número errado, e não um arquivo faltante. Era como um chef que cozinha uma refeição perfeita, mas acidentalmente usa sal em vez de açúcar. A estrutura estava certa; o sabor estava apenas ligeiramente fora.

5. O Que os Especialistas Humanos Disseram

Os pesquisadores pediram a quatro arquitetos seniores (desenvolvedores) que revisassem o trabalho do robô.

Veredito: Eles adoraram. Deram notas altas por legibilidade e estrutura.
Economia de Tempo: Eles estimaram que, para projetos pequenos e simples, o robô poderia economizar 40% a 80% do tempo deles. No entanto, para projetos massivos e complexos, o robô ainda era um "ajudante" que precisava de um humano para verificar os detalhes finais.
A Pegadinha: O robô às vezes ficava confuso sobre qual tipo específico de parte usar em um cenário complexo, exigindo que um humano fizesse um ajuste rápido.

A Conclusão

Este artigo prova que você pode ensinar uma IA a gerenciar projetos complexos com múltiplos arquivos se você:

Organizar os arquivos em um único formato fácil de ler.
Dar a ela um "curso intensivo" específico (fine-tuning) sobre suas regras específicas.

Ela ainda não substituirá os arquitetos humanos, mas pode fazer o trabalho pesado de rascunhar os projetos, economizando horas de trabalho tedioso e permitindo que eles se concentrem nas partes criativas.

1. Declaração do Problema

O artigo aborda o desafio de usar Modelos de Linguagem de Grande Escala (LLMs) para gerar e modificar Linguagens Específicas de Domínio (DSLs) em escala de repositório dentro de um ambiente industrial.

Contexto: A BMW Financial Services utiliza uma DSL personalizada, baseada em Xtext, para gerar código Java/TypeScript a jusante. Esta DSL serve como fonte autoritativa para configurações específicas de mercado.
O Desafio: Atualmente, os desenvolvedores escrevem e atualizam manualmente os arquivos DSL. Uma única instrução em linguagem natural (NL) frequentemente exige alterações coordenadas em múltiplos arquivos e pastas (por exemplo, adicionar um atributo em uma camada exige atualizações em camadas relacionadas).
Limitações dos LLMs Atuais: Embora os LLMs se saiam bem com código de propósito geral, sua aplicabilidade a DSLs empresariais é pouco explorada. Os principais obstáculos incluem:
- Dependências multi-arquivo: Manter a consistência em toda uma estrutura de pastas a partir de um único prompt.
- Sintaxe Rigorosa: DSLs possuem gramáticas rígidas; erros mínimos quebram a geração de código a jusante.
- Limites de Contexto: Gerar um estado completo de projeto (múltiplos arquivos) frequentemente excede as janelas de contexto padrão.
- Dificuldade de Avaliação: Métricas padrão (como BLEU) falham em capturar a fidelidade estrutural ou a correção de edições em alterações em escala de repositório.

2. Metodologia

Os autores desenvolveram um pipeline de ponta a ponta envolvendo construção de conjunto de dados, representação de tarefas, adaptação de modelo e um framework de avaliação especializado.

A. Representação de Tarefa: Linearização

Para permitir a geração de resposta única de um repositório multi-arquivo, os autores linearizaram toda a hierarquia de pastas DSL em um único documento JSON estruturado.

Estrutura: Pastas são objetos JSON aninhados, arquivos são chaves e o conteúdo dos arquivos são valores de string (preservando quebras de linha).
Entrada/Saída: O modelo recebe um par (Instrução, JSON de Contexto) e gera um (JSON de Alvo) representando o estado completo do projeto atualizado.
Benefício: Isso permite que o LLM opere no nível da "raiz do projeto", aprendendo dependências entre arquivos em uma única etapa de geração.

B. Construção do Conjunto de Dados

Fonte: Um conjunto de dados proprietário e anonimizado, construído manualmente por especialistas em DSL (não existe conjunto de dados público para esta DSL).
Tamanho: 774 exemplos de treinamento e 105 exemplos de avaliação retidos.
Operações: Três famílias de tarefas: (1) Criar um novo mercado, (2) Adicionar recursos (atributos/produtos), (3) Excluir recursos.
Variantes: Inclui variantes de "contexto completo" (projeto inteiro) e "contexto mínimo" (apenas arquivos relevantes) para testar a redução de ruído.
Divisão: Divisão cuidadosa para evitar vazamento de dados entre variantes de instrução.

C. Seleção e Adaptação do Modelo

O estudo avaliou dois LLMs de código de código aberto, ajustados para instruções (7B parâmetros): Qwen2.5-Coder e DeepSeek-Coder. Três configurações foram testadas:

Zero-Shot (Linha de Base): Instrução bruta + contexto linearizado.
Aprendizado em Contexto One-Shot (ICL): Adicionou um resumo das regras gramaticais da DSL e uma demonstração de exemplo.
Ajuste Fino Eficiente em Parâmetros (PEFT): Utilizou QLoRA (quantização de 4 bits) com rank $r=16$ para ajustar finamente os modelos no conjunto de dados proprietário.

D. Framework de Avaliação

Os autores introduziram uma estratégia de avaliação híbrida combinando métricas padrão com medidas específicas de tarefa:

Métricas Padrão: Correspondência Exata (EM), BLEU, Verificação de JSON Válido.
Métricas Personalizadas:
- Similaridade de Mudança: Foca apenas nas linhas que foram realmente alteradas (ignorando o contexto inalterado), usando a distância de Levenshtein em nível de token para penalizar erros nas edições.
- Fidelidade Estrutural: Mede a precisão/recall/F1 da árvore de pastas/arquivos gerada em relação ao alvo, garantindo que não haja arquivos espúrios ou ausentes.
Validação:
- Aceitação da Ferramenta: Executar a DSL gerada através do gerador DSL-para-código existente para verificar erros de compilação/construção.
- Avaliação Humana: Pesquisa com 4 desenvolvedores sênior de DSL avaliando qualidade, utilidade e economia de tempo.

3. Principais Contribuições

Estudo de Caso Industrial: Primeiro relatório detalhado sobre a aplicação de LLMs à geração de DSL multi-arquivo em escala de repositório em um ambiente empresarial de alto risco (BMW).
Linearização Estruturada: Um método inovador para codificar hierarquias complexas de pastas em uma única entrada/saída JSON, permitindo geração na raiz do projeto e aprendizado de dependências entre arquivos.
Avaliação Específica de Tarefa: Um framework que vai além da sobreposição de texto para medir correção de edição (similaridade de mudança) e fidelidade estrutural, que são críticas para DSLs.
Comparação Empírica: Uma comparação rigorosa entre Zero-shot, One-shot ICL e ajuste fino QLoRA, demonstrando que o ajuste fino é essencial para correção estrita neste domínio.

4. Resultados

O estudo avaliou os modelos no conjunto retido usando as métricas definidas.

RQ1 (Viabilidade): Os modelos de linha de base (Zero-shot) produziram estruturas JSON válidas, mas falharam na correção estrita (Correspondência Exata: Qwen 0.076, DeepSeek 0.371). Eles conseguiam formatar a saída, mas lutavam com dependências semânticas.
RQ2 (Impacto da Adaptação):
- ICL One-Shot: Melhorou significativamente a correção estrutural (especialmente para o Qwen, saltando de 0.663 para 0.958), mas teve impacto limitado na correspondência exata ou na correção de edição complexa.
- Ajuste Fino (QLoRA): Produziu os ganhos mais significativos.
  - DeepSeek-FT: Alcançou 0.657 de Correspondência Exata, 0.841 de Similaridade de Mudança e 1.000 de Fidelidade Estrutural.
  - Qwen-FT: Alcançou 0.629 de Correspondência Exata, 0.834 de Similaridade de Mudança e 0.990 de Fidelidade Estrutural.
- Insight Chave: O ajuste fino foi necessário para dominar dependências entre arquivos e semântica da DSL. O ICL ajudou na formatação, mas não na lógica profunda.
RQ3 (Utilidade para Desenvolvedores):
- Revisão Humana: Desenvolvedores sênior avaliaram as saídas ajustadas finamente como altamente positivas (Média 4.50/5), particularmente para Fidelidade Estrutural e Legibilidade (5.00/5).
- Utilidade: Avaliada em 4.50/5. Os desenvolvedores estimaram economia de tempo de 40–80% para criar novos mercados (inicialização), embora as economias caiam para mercados grandes e complexos que exigem correção manual.
- Validação da Ferramenta: O gerador processou com sucesso operações "Criar" e "Excluir" (100% de sucesso), mas teve sucesso menor (75%) para operações "Adicionar" devido a tipos de atributo alucinados ou violações de regras.

5. Significado e Implicações

Viabilidade de NL-para-DSL: O estudo prova que, com adaptação adequada (ajuste fino) e representação de contexto (linearização), os LLMs podem gerar conjuntos de alterações de DSL complexos e multi-arquivos de forma confiável a partir de linguagem natural.
O Ajuste Fino é Crítico: Para DSLs empresariais com gramáticas estritas e dependências entre arquivos, o aprendizado em contexto é insuficiente para tarefas de alta precisão; o ajuste fino eficiente em parâmetros é necessário para alcançar precisão de nível de produção.
Mudança na Avaliação: Métricas padrão como BLEU são enganosas para alterações em escala de repositório. As métricas propostas "Similaridade de Mudança" e "Fidelidade Estrutural" são essenciais para avaliar a utilidade real do código gerado.
Caminho de Implantação: Embora altamente eficaz para boilerplate e inicialização de mercado, a adoção total requer a integração de salvaguardas automatizadas (por exemplo, decodificação consciente de gramática ou loops de feedback do gerador) para capturar os erros semânticos restantes de "quase-acerto", particularmente em operações de "Adicionar".

Em conclusão, este artigo fornece um roteiro para integrar LLMs em fluxos de trabalho de engenharia de software industrial envolvendo DSLs, demonstrando que a combinação de contexto linearizado e ajuste fino pode automatizar significativamente a geração de código em escala de repositório, mantendo a integridade estrutural.