Using LLMs to Evaluate Architecture Documents: Results from a Digital Marketplace Environment

Resumen Técnico: Uso de LLMs para Evaluar Documentos de Arquitectura – Resultados de un Entorno de Mercado Digital

Planteamiento del Problema
El desarrollo de software depende cada vez más de la IA generativa, pero la calidad de los resultados de la IA depende fundamentalmente de la calidad de su entrada. Los artefactos de las etapas iniciales, como los documentos de arquitectura de software, son entradas críticas para la implementación posterior. Los defectos, ambigüedades o la falta de información en estos documentos pueden derivar en ciclos de corrección costosos más adelante en el ciclo de vida del desarrollo. Los métodos tradicionales para evaluar la documentación de arquitectura existen (por ejemplo, ATAM, SAAM, listas de verificación manuales), pero suelen ser lentos y difíciles de escalar. Los autores investigan si los Modelos de Lenguaje de Gran Tamaño (LLM) pueden evaluar eficazmente la calidad de los documentos de arquitectura y proporcionar una retroalimentación comparable a la de los arquitectos de software humanos, específicamente dentro del contexto de un mercado digital para soluciones de ciudades inteligentes.

Metodología
La investigación se llevó a cabo dentro de la herramienta "Quasar", un sistema basado en LLM desarrollado para apoyar la evaluación de soluciones de código abierto en el mercado "Deutschland Digital". El estudio se centró en dos proyectos de código abierto específicos con niveles variables de completitud de documentación:

1. Proyecto 1: Una solución con documentación exhaustiva (266 archivos, incluyendo Markdown, PDF e imágenes).
2. Proyecto 2: Una solución con documentación básica (11 archivos Markdown y 25 imágenes).

Arquitectura del Sistema e Implementación:

• Procesamiento de Entrada: El sistema acepta diversos formatos de documentación (PDF, DOCX, Markdown, imágenes). Un convertidor (usando Docling) los transforma en formatos legibles.
• Lógica de Evaluación: El sistema emplea un modelo de calidad ponderado donde se evalúan criterios específicos frente a prompts predefinidos.
• Integración de LLM: El backend de "Quasar" utiliza un componente de "cliente de LLM" para desacoplar la lógica de evaluación de proveedores de modelos específicos. Para el estudio, los autores utilizaron Qwen2 (multimodal, capaz de procesar texto y diagramas) y Llama3.1 (solo texto) alojados localmente en GPUs NVIDIA Tesla V100.
• Procedimiento: Dos arquitectos de software evaluaron manualmente los dos proyectos basándose en 25 enunciados predefinidos (calificados de 0 a 4). Simultáneamente, Quasar evaluó los mismos proyectos tres veces cada uno utilizando los mismos 25 prompts para evaluar la consistencia y el acuerdo con los expertos humanos.

Contribuciones Clave

1. Desarrollo de Herramientas: La creación de "Quasar", una herramienta modular capaz de ingerir diversos formatos de documentación y generar puntuaciones de calidad basadas en el análisis de LLM.
2. Comparación Empírica: Una comparación directa de la evaluación basada en LLM frente a la evaluación de expertos humanos a través de dos escenarios de documentación distintos (exhaustiva frente a escasa).
3. Análisis Contextual: Una investigación sobre cómo la calidad y la densidad de los artefactos de entrada influyen en la fiabilidad de las evaluaciones de los LLM.

Resultados
El estudio arrojó hallazgos significativos respecto a la relación entre la calidad de la entrada y el rendimiento del LLM:

• Consistencia (RQ 1.2):
  • Proyecto 1 (Entrada de alta calidad): Las tres ejecuciones automatizadas mostraron resultados mayoritariamente consistentes.
  • Proyecto 2 (Entrada de baja calidad): Las ejecuciones mostraron una consistencia débil. En tres instancias, el modelo no logró producir un resultado para enunciados específicos en todas las ejecuciones.
• Acuerdo con Humanos (RQ 1.3):
  • Proyecto 1: Hubo una fuerte correlación. Dos enunciados coincidieron exactamente, y el 36% de las evaluaciones diferían en un máximo de 15%. La desviación promedio fue del 27%.
  • Proyecto 2: No se estableció una correlación aparente. La desviación promedio fue del 43%, lo que indica que el LLM no pudo replicar de manera fiable el juicio humano en documentación escasa.
• Esfuerzo (RQ 1.1):
  • Los tiempos de procesamiento fueron comparables entre humanos y la máquina para el conjunto de datos más pequeño (22 min humanos vs. 14 min Quasar para el Proyecto 2; 60 min humanos vs. 68 min Quasar para el Proyecto 1). Los autores señalan que, para conjuntos de datos más grandes, se espera que la solución automatizada sea más rápida.

Significancia y Reivindicaciones
El artículo afirma que los LLM son una herramienta de apoyo prometedora para los arquitectos de software, pero enfatiza que su utilidad es altamente condicional a la calidad de los artefactos de entrada.

• Dependencia de la Entrada: El hallazgo central es que cuanto mejor sea la calidad y estructura del documento de arquitectura, más consistente y precisa será la evaluación del LLM en relación con los expertos humanos. Por el contrario, la baja densidad de información conduce a desviaciones significativas y alucinaciones.
• Rol de la IA: Los autores posicionan a los LLM no como un reemplazo de los expertos humanos, sino como un mecanismo para un "control de calidad inicial y ligero" que puede proporcionar una primera impresión de la calidad de la documentación, ahorrando así tiempo a los expertos.
• Limitaciones: Los autores declaran explícamente que el estudio está limitado por un tamaño de muestra pequeño (dos proyectos, dos expertos) y los modelos específicos utilizados. Advierten que no es posible la generalización basada en los resultados actuales y que las "inconsistencias" observadas en entradas de baja calidad requieren un análisis adicional antes de que la tecnología pueda ser ampliamente generalizada.
• Perspectiva Futura: Los autores sugieren que las iteraciones futuras deberían utilizar ventanas de contexto más amplias (por ejemplo, Google Gemini), Generación Aumentada por Recuperación (RAG) para preservar el contexto entre archivos, y ajuste fino (fine-tuning) para mejorar el conocimiento específico del dominio. También vislumbran la integración de estas capacidades directamente en las herramientas diarias de los arquitectos (por ejemplo, Enterprise Architect, draw.io) en lugar de como servicios independientes.