Large Language Models for Analyzing Enterprise Architecture Debt in Unstructured Documentation

Título: Modelos de Lenguaje Grande para Analizar la Deuda de Arquitectura Empresarial en Documentación No Estructurada

1. Planteamiento del Problema

La Deuda de Arquitectura Empresarial (EA Debt) surge de decisiones de diseño subóptimas y componentes desalineados que degradan el paisaje de TI de una organización con el tiempo. Los indicadores tempranos de esta deuda se denominan "Olores de Arquitectura Empresarial" (EA Smells).

• Limitación actual: La detección de estos olores se realiza principalmente de forma manual (talleres, entrevistas) o mediante el análisis de artefactos estructurados (modelos, grafos de conocimiento).
• El vacío: Gran parte del conocimiento arquitectónico reside en documentación no estructurada (descripciones de procesos, políticas, notas de reuniones, estrategias). Estos documentos contienen información crítica sobre decisiones de diseño y restricciones heredadas, pero las herramientas actuales no las analizan eficazmente, lo que impide la detección temprana de problemas y aumenta los costos y la rigidez operativa.
• Objetivo: Investigar si los Modelos de Lenguaje Grande (LLM) pueden automatizar la detección y cuantificación de estos olores en texto no estructurado, abordando restricciones de protección de datos y hardware limitado.

2. Metodología

El estudio sigue un enfoque de Investigación de Ciencia del Diseño (DSR) para diseñar, implementar y evaluar un prototipo.

• Alcance: Se centró en la capa de negocio de la arquitectura empresarial (procesos, objetivos, roles). Se seleccionaron 12 olores específicos (de un catálogo de 63) que presentan firmas textuales claras y alta viabilidad de detección automática (ej. "Contradicción en la entrada", "Solución temporal", "Falta de documentación").
• Desarrollo del Artefacto (Modelo A - On-Premise):
  • Modelo Base: Se seleccionó LLaMA-3.2-3B-Instruct debido a sus limitaciones de hardware (solo CPU, 16 GB de RAM) y requisitos de privacidad (despliegue local sin APIs externas).
  • Técnica de Entrenamiento: Se utilizó una combinación de aprendizaje con pocos ejemplos (few-shot learning) y Ajuste Fino Eficiente de Parámetros (PEFT) mediante LoRA (Low-Rank Adaptation). Esto permitió entrenar el modelo con recursos limitados, manteniendo los pesos base congelados y entrenando solo capas adaptadoras pequeñas.
  • Dataset: Se construyó un conjunto de datos sintético pero realista con 960 instancias (80 ejemplos por olor, 50% positivos/50% negativos) cubriendo 8 dominios de negocio (ej. Pedido a Cobro, Compra a Pago).
  • Pipeline: Ingestión de documentos (.docx, .pdf) -> Preprocesamiento (tokenización, fragmentación con superposición) -> Detección de olores por LLM -> Generación de informes con trazabilidad.
• Línea Base de Comparación (Modelo B):
  • Se creó un GPT personalizado (propiedad de OpenAI) utilizando la misma configuración de instrucciones y datos de entrenamiento (vía in-context learning sin ajuste de parámetros) para servir como referencia de precisión y velocidad.
• Evaluación: Se utilizó un caso de estudio con una empresa ficticia ("NextTech") y 30 documentos de negocio sintéticos. Se probaron tres protocolos: procesamiento individual, lotes de 10 documentos y un lote de 30 documentos.

3. Contribuciones Clave

1. Análisis de Requisitos: Definición de requisitos funcionales y no funcionales para herramientas de detección de olores basadas en LLM en entornos corporativos.
2. Artefacto Funcional: Diseño e implementación de un prototipo de detección de olores ejecutable localmente en hardware restringido (CPU), utilizando un modelo de 3B parámetros ajustado finamente.
3. Evaluación Empírica Comparativa: Un análisis riguroso que contrasta un modelo local de recursos limitados frente a un modelo propietario de vanguardia, evaluando precisión, velocidad, escalabilidad y adaptabilidad.
4. Identificación de Patrones de Error: Clasificación detallada de los modos de fallo específicos en la detección de olores arquitectónicos (omisiones, falsos positivos, fugas de contexto en lotes).

4. Resultados

• Precisión y Falsos Positivos:
  • Modelo B (GPT): Logró una precisión muy alta (0.88 - 0.89) y una tasa de falsos positivos muy baja (0.09). Sin embargo, tuvo una recall modesta (0.22 - 0.25), omitiendo algunos olores implantados.
  • Modelo A (LLaMA Local): Mostró una precisión muy baja (0.19 - 0.26) y una tasa de falsos positivos extremadamente alta (0.95 - 1.00). El modelo detectó muchos olores que no existían (sobre-detección) y a menudo proporcionó explicaciones genéricas.
• Tiempo de Procesamiento y Escalabilidad:
  • El modelo GPT fue significativamente más rápido (~2 segundos por documento) y capaz de manejar lotes de 10 documentos casi instantáneamente.
  • El modelo local fue mucho más lento (~120 segundos por documento en CPU) y tardó ~50 minutos en procesar un lote de 30 documentos.
• Adaptabilidad: El modelo GPT mostró cierta capacidad para revisar hallazgos anteriores cuando se proporcionaba nuevo contexto, mientras que el modelo local no actualizó sus conclusiones dinámicamente.
• Errores Comunes: Se identificaron cinco tipos de errores: omisión de olores, mala clasificación, fugas de contexto entre documentos en un lote (en el modelo GPT), falsos positivos y citas fabricadas (hallucinaciones).

5. Significado e Implicaciones

• Viabilidad Técnica: Demuestra que es técnicamente posible ejecutar detección de olores de arquitectura en hardware limitado y local, cumpliendo con estrictas normas de protección de datos, aunque con un rendimiento de precisión inferior al de los modelos en la nube.
• Rol en la Práctica de EA: Los resultados sugieren que los LLMs no deben usarse como diagnósticos definitivos, sino como herramientas de triaje para priorizar la revisión humana.
• Compromiso (Trade-off): Existe un equilibrio claro entre la privacidad/seguridad (modelo local) y la precisión/velocidad (modelo en la nube). Las organizaciones deben decidir basándose en la sensibilidad de sus datos.
• Futuro: El estudio subraya la necesidad de mejorar la "anclaje" (grounding) de las respuestas, utilizar protocolos de etiquetado más robustos y explorar arquitecturas híbridas que combinen el análisis de texto no estructurado con repositorios estructurados (como grafos de conocimiento) para reducir los falsos positivos y mejorar la interpretabilidad.

En conclusión, aunque el modelo local actual no está listo para su uso productivo directo debido a la alta tasa de falsos positivos, establece una base fundamental para el desarrollo de herramientas de gobernanza de arquitectura empresarial que respeten la soberanía de los datos.