💻 computer science

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

Este estudio de caso industrial en BMW demuestra que el ajuste fino de modelos de lenguaje grandes orientados a código con una representación JSON estructurada y que preserva la ruta de las jerarquías del repositorio supera significativamente a la indicación de referencia y al aprendizaje de un solo ejemplo en la generación de artefactos DSL precisos y multiarchivo que impulsan la generación de código aguas abajo.

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

Publicado 2026-04-28

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

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

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un arquitecto maestro trabajando para una empresa de construcción masiva (BMW). Tu trabajo es diseñar nuevos edificios (configuraciones de mercado) para diferentes ciudades.

En la antigua forma de hacer las cosas, tenías que escribir manualmente cada plano, plan eléctrico y diagrama de fontanería en hojas de papel separadas. Si querías añadir una nueva ventana a la cocina, tenías que recordar actualizar el plan eléctrico, el plan de fontanería y el plan estructural, todos perfectamente sincronizados. Si te perdías un detalle minúsculo, todo el edificio no podía construirse y el equipo de construcción (el generador de código) se quedaría atascado.

Este artículo trata sobre enseñar a un asistente robot superinteligente (un Modelo de Lenguaje Grande, o LLM) a hacer este papeleo manual por ti. Pero hay un truco: el robot nunca ha visto tus planos específicos antes, y tiene que actualizar múltiples documentos interconectados a la vez basándose en solo una frase de instrucciones de tu parte.

Así es como los investigadores enseñaron al robot a hacerlo:

1. El Problema: El Rompecabezas de "Una Instrucción, Muchos Archivos"

Por lo general, la IA es buena escribiendo una sola historia o un solo fragmento de código. Pero en esta empresa, una sola solicitud como "Añadir un nuevo tipo de préstamo para el mercado alemán" requiere cambiar archivos en cinco carpetas diferentes. Si el robot cambia el archivo principal pero olvida actualizar el archivo que lista todos los tipos de préstamos, todo el sistema se rompe.

2. La Solución: Aplanar la Biblioteca

Para ayudar al robot a entender todo el proyecto de una vez, los investigadores no le alimentaron archivo por archivo. En su lugar, tomaron toda la "biblioteca" de planos (la estructura de carpetas) y la aplanaron en un solo libro gigante y organizado (un único documento JSON).

La Analogía: Imagina tomar un escritorio desordenado con 20 carpetas diferentes y extender cada página individual sobre una mesa gigante, pero manteniéndolas en filas ordenadas para que sepas a qué carpeta pertenece cada página. Ahora, el robot puede mirar toda la mesa de una vez y decir: "Bien, veo dónde deben ir los cambios".

3. El Entrenamiento: Tres Maneras de Enseñar al Robot

Los investigadores probaron tres formas diferentes de enseñar al robot este trabajo específico:

El "Arranque en Frío" (Zero-Shot): Simplemente le dieron al robot la instrucción y el libro aplanado y dijeron: "Arréglalo".
- Resultado: El robot estaba bien manteniendo las páginas en el orden correcto, pero a menudo inventaba detalles incorrectos o perdía conexiones diminutas. Era como un estudiante que conoce el alfabeto pero aún no ha aprendido la gramática.
El "Ejemplo" (One-Shot): Le dieron al robot la instrucción, el libro, más un ejemplo de un trabajo anterior realizado correctamente. "Así es como añadimos una ventana la última vez; hazlo así".
- Resultado: Esto ayudó al robot a obtener la estructura correcta (las páginas se mantuvieron en las carpetas adecuadas), pero aún luchaba con los detalles específicos y complicados de la nueva solicitud.
El "Curso Intensivo" (Fine-Tuning): Tomaron al robot y le mostraron cientos de ejemplos de planos "Antes" y "Después". No solo se lo mostraron; ajustaron el cerebro interno del robot (usando una técnica llamada QLoRA) para que aprendiera las reglas específicas de los planos de esta empresa.
- Resultado: Este fue el ganador. El robot se convirtió en un experto. Podía mirar una solicitud y producir un conjunto perfectamente sincronizado de cambios en todos los archivos.

4. Los Resultados: ¿Funcionó?

Los investigadores probaron al robot con tareas reales y pidieron a expertos humanos que revisaran el trabajo.

Estructura: El robot ajustado fue casi perfecto manteniendo los archivos en las carpetas correctas y no inventando carpetas falsas. Obtuvo una puntuación perfecta (1.0) en mantener la "forma" del proyecto correcta.
Detalles: Fue muy bueno con el contenido real, obteniendo aproximadamente el 66% de los cambios exactamente correctos y el 84% de los cambios "suficientemente cercanos" para ser útiles.
La Realidad del "Casi": El robot fue tan bueno que cuando fallaba, generalmente era solo un error tipográfico minúsculo o un número incorrecto, no un archivo faltante. Era como un chef que cocina una comida perfecta pero usa sal en lugar de azúcar por accidente. La estructura estaba bien; el sabor estaba solo ligeramente fuera de lugar.

5. Lo que Dijeron los Expertos Humanos

Los investigadores pidieron a cuatro arquitectos senior (desarrolladores) que revisaran el trabajo del robot.

Veredicto: Les encantó. Le dieron altas calificaciones por legibilidad y estructura.
Ahorro de Tiempo: Estimaron que para proyectos pequeños y simples, el robot podría ahorrarles del 40% al 80% de su tiempo. Sin embargo, para proyectos masivos y complejos, el robot seguía siendo un "ayudante" que necesitaba que un humano revisara los detalles finales.
El Truco: El robot a veces se confundía sobre qué tipo específico de parte usar en un escenario complejo, requiriendo que un humano hiciera una corrección rápida.

La Conclusión

Este artículo demuestra que puedes enseñar a una IA a gestionar proyectos complejos de múltiples archivos si:

Organizas los archivos en un formato único y fácil de leer.
Le das un "curso intensivo" específico (ajuste fino) sobre tus reglas específicas.

No reemplazará a los arquitectos humanos todavía, pero puede hacer el trabajo pesado de redactar los planos, ahorrándoles horas de trabajo tedioso y permitiéndoles centrarse en las partes creativas.

1. Planteamiento del Problema

El artículo aborda el desafío de utilizar Modelos de Lenguaje Grandes (LLMs) para generar y modificar Lenguajes Específicos de Dominio (DSL) a escala de repositorio en un entorno industrial.

Contexto: BMW Financial Services utiliza un DSL personalizado basado en Xtext para generar código Java/TypeScript aguas abajo. Este DSL sirve como la fuente autorizada para configuraciones específicas de mercado.
El Desafío: Actualmente, los desarrolladores redactan y actualizan manualmente los archivos DSL. Una sola instrucción en lenguaje natural (NL) a menudo requiere cambios coordinados en múltiples archivos y carpetas (por ejemplo, agregar un atributo en una capa requiere actualizaciones en capas relacionadas).
Limitaciones de los LLMs actuales: Aunque los LLMs funcionan bien con código de propósito general, su aplicabilidad a DSLs empresariales está poco explorada. Los obstáculos clave incluyen:
- Dependencias multi-archivo: Mantener la consistencia a través de una estructura de carpetas desde un solo prompt.
- Sintaxis Estricta: Los DSLs tienen gramáticas rígidas; errores menores rompen la generación de código aguas abajo.
- Límites de Contexto: Generar un estado completo del proyecto (múltiples archivos) a menudo excede las ventanas de contexto estándar.
- Dificultad de Evaluación: Las métricas estándar (como BLEU) no capturan la fidelidad estructural ni la corrección de las ediciones en cambios a escala de repositorio.

2. Metodología

Los autores desarrollaron una pipeline de extremo a extremo que involucra la construcción de conjuntos de datos, la representación de tareas, la adaptación del modelo y un marco de evaluación especializado.

A. Representación de Tareas: Linealización

Para permitir la generación de una sola respuesta de un repositorio multi-archivo, los autores linealizaron toda la jerarquía de carpetas del DSL en un único documento JSON estructurado.

Estructura: Las carpetas son objetos JSON anidados, los archivos son claves y los contenidos de los archivos son valores de cadena (preservando los saltos de línea).
Entrada/Salida: El modelo recibe un par (Instrucción, Contexto JSON) y genera un (JSON Objetivo) que representa el estado completamente actualizado del proyecto.
Beneficio: Esto permite que el LLM opere a nivel de "raíz del proyecto", aprendiendo dependencias entre archivos en un solo paso de generación.

B. Construcción del Conjunto de Datos

Fuente: Un conjunto de datos propietario y anonimizado construido manualmente por expertos en DSL (no existe un conjunto de datos público para este DSL).
Tamaño: 774 ejemplos de entrenamiento y 105 ejemplos de evaluación retenidos.
Operaciones: Tres familias de tareas: (1) Crear un nuevo mercado, (2) Agregar características (atributos/productos), (3) Eliminar características.
Variantes: Incluye variantes de "contexto completo" (todo el proyecto) y "contexto mínimo" (solo archivos relevantes) para probar la reducción de ruido.
División: División cuidadosa para evitar la filtración de datos entre variantes de instrucciones.

C. Selección y Adaptación del Modelo

El estudio evaluó dos LLMs de código de código abierto ajustados con instrucciones (7B parámetros): Qwen2.5-Coder y DeepSeek-Coder. Se probaron tres configuraciones:

Zero-Shot (Línea base): Instrucción cruda + contexto linealizado.
Aprendizaje en Contexto One-Shot (ICL): Se agregó un resumen de las reglas gramaticales del DSL y una demostración de ejemplo.
Ajuste Fino Eficiente en Parámetros (PEFT): Se utilizó QLoRA (cuantización de 4 bits) con rango $r=16$ para ajustar finamente los modelos en el conjunto de datos propietario.

D. Marco de Evaluación

Los autores introdujeron una estrategia de evaluación híbrida que combina métricas estándar con medidas específicas de la tarea:

Métricas Estándar: Coincidencia Exacta (EM), BLEU, Verificación de JSON válido.
Métricas Personalizadas:
- Similitud de Cambio: Se centra solo en las líneas que fueron realmente cambiadas (ignorando el contexto sin cambios), utilizando la distancia de Levenshtein a nivel de token para penalizar errores en las ediciones.
- Fidelidad Estructural: Mide la precisión/recall/F1 del árbol de carpetas/archivos generado frente al objetivo, asegurando que no haya archivos espurios o faltantes.
Validación:
- Aceptación de la Cadena de Herramientas: Ejecutar el DSL generado a través del generador DSL-a-código existente para verificar errores de compilación/construcción.
- Evaluación Humana: Encuesta a 4 desarrolladores senior de DSL calificando la calidad, utilidad y ahorro de tiempo.

3. Contribuciones Clave

Estudio de Caso Industrial: Primer informe detallado sobre la aplicación de LLMs a la generación de DSL multi-archivo a escala de repositorio en un entorno empresarial de alto riesgo (BMW).
Linealización Estructurada: Un método novedoso para codificar jerarquías de carpetas complejas en una única entrada/salida JSON, habilitando la generación desde la raíz del proyecto y el aprendizaje de dependencias entre archivos.
Evaluación Específica de Tareas: Un marco que va más allá de la superposición de texto para medir la corrección de la edición (similitud de cambio) y la fidelidad estructural, que son críticas para los DSLs.
Comparación Empírica: Una comparación rigurosa de Zero-shot, One-shot ICL y ajuste fino QLoRA, demostrando que el ajuste fino es esencial para la corrección estricta en este dominio.

4. Resultados

El estudio evaluó los modelos en el conjunto retenido utilizando las métricas definidas.

RQ1 (Viabilidad): Los modelos de línea base (Zero-shot) produjeron estructuras JSON válidas pero fallaron en la corrección estricta (Coincidencia Exacta: Qwen 0.076, DeepSeek 0.371). Podían formatear la salida pero luchaban con dependencias semánticas.
RQ2 (Impacto de la Adaptación):
- ICL One-Shot: Mejoró significativamente la corrección estructural (especialmente para Qwen, saltando de 0.663 a 0.958) pero tuvo un impacto limitado en la coincidencia exacta o la corrección de edición compleja.
- Ajuste Fino (QLoRA): Logró las ganancias más significativas.
  - DeepSeek-FT: Logró 0.657 de Coincidencia Exacta, 0.841 de Similitud de Cambio y 1.000 de Fidelidad Estructural.
  - Qwen-FT: Logró 0.629 de Coincidencia Exacta, 0.834 de Similitud de Cambio y 0.990 de Fidelidad Estructural.
- Insight Clave: Se requirió ajuste fino para dominar las dependencias entre archivos y la semántica del DSL. El ICL ayudó con el formato pero no con la lógica profunda.
RQ3 (Utilidad para Desarrolladores):
- Revisión Humana: Los desarrolladores senior calificaron las salidas ajustadas finamente muy alto (Media 4.50/5), particularmente para Fidelidad Estructural y Legibilidad (5.00/5).
- Utilidad: Calificada 4.50/5. Los desarrolladores estimaron un ahorro de tiempo del 40–80% para crear nuevos mercados (arranque), aunque los ahorros disminuyen para mercados grandes y complejos que requieren corrección manual.
- Validación de la Cadena de Herramientas: El generador procesó con éxito las operaciones "Crear" y "Eliminar" (100% de éxito) pero tuvo un éxito menor (75%) para las operaciones "Agregar" debido a tipos de atributos alucinados o violaciones de reglas.

5. Significado e Implicaciones

Viabilidad de NL-a-DSL: El estudio demuestra que con la adaptación adecuada (ajuste fino) y la representación de contexto (linealización), los LLMs pueden generar de manera confiable conjuntos de cambios DSL complejos y multi-archivo a partir de lenguaje natural.
El Ajuste Fino es Crítico: Para DSLs empresariales con gramáticas estrictas y dependencias entre archivos, el aprendizaje en contexto es insuficiente para tareas de alta precisión; el ajuste fino eficiente en parámetros es necesario para lograr una precisión de nivel de producción.
Cambio en la Evaluación: Las métricas estándar como BLEU son engañosas para cambios a escala de repositorio. Las métricas propuestas de "Similitud de Cambio" y "Fidelidad Estructural" son esenciales para evaluar la utilidad real del código generado.
Ruta de Despliegue: Aunque es altamente efectivo para plantillas y arranque de mercados, la adopción total requiere integrar salvaguardas automatizadas (por ejemplo, decodificación consciente de la gramática o bucles de retroalimentación del generador) para capturar los errores semánticos restantes de "casi fallo", particularmente en operaciones "Agregar".

En conclusión, este artículo proporciona un plano para integrar LLMs en flujos de trabajo de ingeniería de software industrial que involucran DSLs, demostrando que la combinación de contexto linealizado y ajuste fino puede automatizar significativamente la generación de código a escala de repositorio mientras se mantiene la integridad estructural.