Resumen Técnico: DKSE – Extracción Automatizada de Ontologías de Dominio Estructuradas
1. Declaración del Problema
Los documentos de requisitos de software sirven como los núcleos de conocimiento en el desarrollo de software empresarial, definiendo entidades del sistema, reglas, procesos e interfaces. Sin embargo, estos documentos existen como lenguaje natural no estructurado, lo que los hace inaccesibles para las cadenas de herramientas de ingeniería automatizadas. En consecuencia, las tareas posteriores como la generación de pruebas, el andamiaje de código (code scaffolding), la verificación de cumplimiento y el desarrollo asistido por IA no pueden procesar directamente el conocimiento específico del sistema contenido en estos documentos densos en prosa.
Los enfoques de automatización existentes, que van desde las heurísticas tempranas de coincidencia de patrones hasta los pipelines recientes de PLN, suelen producir extracciones superficiales (por ejemplo, listas simples de entidades) y luchan con la complejidad de los requisitos del mundo real, incluyendo tablas de múltiples páginas, reglas con referencias cruzadas, lógica de negocio incrustada y restricciones implícitas distribuidas a través de las secciones. Si bien los Modelos de Lenguaje de Gran Escala (LLM) ofrecen la capacidad de comprender y sintetizar tales documentos complejos, existe una falta de herramientas que conviertan este entendimiento en ontologías estructuradas exhaustivas y legibles por máquina, adecuadas para la automatización de la ingeniería de software.
2. Metodología: El Pipeline DKSE
El autor presenta DKSE (Domain Knowledge Structuring Engine), una herramienta diseñada para convertir automáticamente documentos de requisitos de múltiples formatos en ontologías de dominio estructuradas. El sistema está implementado en Rust (~8,000 líneas de código) y opera como un pipeline de tres etapas:
2.1 Entrada y Procesamiento (Etapa 1)
DKSE acepta entradas en formatos DOCX, PDF, HTML y Markdown.
- DOCX: Procesado mediante extracción ZIP/XML para preservar tablas, encabezados y estructuras de sección.
- PDF: Procesado mediante extracción de texto sensible al diseño (layout-aware).
- HTML: Procesado mediante el recorrido del DOM.
El resultado de esta etapa es texto estructurado normalizado.
2.2 Análisis Semántico Guiado por LLM (Etapa 2)
El texto normalizado es procesado por un LLM (a través de un endpoint compatible con OpenAI) utilizando prompts de extracción específicos del dominio. Crucialmente, la extracción está guiada por esquema: los prompts incluyen el esquema YAML objetivo para asegurar que la salida se ajuste estrictamente a la estructura de la ontología. El LLM identifica y estructura:
- Definiciones de entidades y esquemas de atributos.
- Reglas de negocio con condiciones formalizadas (tripletas de campo + operador + valor).
- Secuencias de pasos de procesos con roles asociados.
- Definiciones de endpoints de API.
- Enumeraciones de diccionarios.
2.3 Ensamblaje y Validación de la Ontología (Etapa 3)
Los activos extraídos se ensamblan en un directorio de seis tipos de ontología. DKSE realiza cuatro verificaciones específicas de validación de referencias cruzadas:
- Verificación de Tipo de Atributo: Asegura que las condiciones de las reglas hagan referencia a campos con tipos compatibles en los esquemas de las entidades.
- Validación de Cardinalidad de Relación: Verifica que las relaciones (por ejemplo, ONE_TO_MANY) vinculen entidades extraídas válidas.
- Integridad del Diccionario: Confirma que los códigos de diccionario referenciados por las reglas existan.
- Detección de Duplicados: Señala activos con nombres idénticos dentro de un dominio.
Los fallos se registran para revisión humana en lugar de descartarse silenciosamente, manteniendo un rastro de auditoría completo.
2.4 Esquema de la Ontología
La salida es una ontología codificada en YAML que comprende seis tipos distintos de activos:
- Entidades: Nombre, descripción y atributos (nombre, tipo, requerido).
- Relaciones: Entidades de origen/destino y cardinalidad.
- Reglas: Nombre, descripción, prioridad y condiciones formalizadas.
- Procesos: Nombre y pasos ordenados con roles.
- APIs: Ruta, método, solicitud y definiciones de respuesta.
- Diccionarios: Nombre y entradas de código-etiqueta.
Cada activo incluye un campo source_requirement que apunta a la sección del documento de origen para el seguimiento de la procedencia.
2.5 Garantía de Calidad y Herramientas
DKSE incluye una interfaz de línea de comandos (CLI) e interfaz web con comandos específicos:
dkse validate: Verifica la integridad de la ontología (tipos, cardinalidad, referencias).dkse diff: Compara versiones de la ontología para resaltar cambios incrementales (activos añadidos, modificados, eliminados).dkse probe: Genera sondas de evaluación calificadas por máquina (valor exacto, campo exacto, conjunto, ordenado) a partir de la ontología.dkse serve: Una interfaz web para navegar, buscar y comparar ontologías.
3. Caso de Estudio y Resultados
El autor evaluó DKSE en seis documentos de requisitos (aproximadamente 800,000 caracteres chinos) que abarcan cuatro subdominios bancarios: Gestión de Desembolsos, Gestión de Clientes, Gestión de Contratos de Crédito y Transacciones con Partes Relacionadas.
3.1 Estadísticas de Extracción
DKSE extrajo con éxito 3,439 activos estructurados:
- Entidades: 215
- Reglas: 1,227
- Relaciones: 739
- Procesos: 182
- APIs: 594 (trans-dominio)
- Diccionarios: 482
3.2 Métricas de Calidad
- Cobertura: DKSE logró una cobertura de módulo funcional del 100%, extrayendo al menos una entidad, regla y proceso para cada módulo declarado en las tablas de contenido de los documentos.
- Precisión: Un experto en el dominio (ingeniero de requisitos bancarios senior) revisó una muestra estratificada de 100 activos.
- 96% fueron calificados como totalmente precisos.
- 3 exhibieron variaciones menores de nomenclatura (semánticamente equivalentes) pero eran utilizables.
- 1 tuvo una omisión de condición capturada en una fase de refinamiento.
- 0 activos alucinados fueron encontrados.
- Procedencia: Los 100 activos muestreados tenían punteros de origen correctos a las secciones de los documentos originales.
4. Aplicaciones Posteriores
El artículo demuestra tres casos de uso específicos habilitados por la ontología extraída:
- Generación Automática de Benchmarks: El comando
dkse probe generó 1,214 sondas de evaluación calificadas por máquina para un benchmark institucional (FinBench) y 200 sondas para la evaluación de pre-entrenamiento continuo a través de cuatro dominios.
- Construcción de Corpus de Entrenamiento de LLM: La ontología y el texto de los requisitos se combinaron para crear un corpus de texto estructurado de aproximadamente 2 millones de tokens, adecuado para el ajuste fino supervisado (SFT) y el pre-entrenamiento continuo.
- Ingestión en Grafos de Conocimiento: La ontología fue ingerida en un sistema GraphRAG, resultando en 5,803 nodos y 6,261 aristas. Esto proporcionó una fuente de recuperación para consultas de valores precisos, ofreciendo una ventaja de seguridad sobre el entrenamiento con inyección de pesos al prevenir la fabricación de valores irrecuperables.
5. Significado y Reivindicaciones
El autor posiciona este trabajo como una prueba de concepto dentro de una única industria (banca china) más que como una validación de propósito general.
- Contribución Principal: DKSE demuestra que los documentos de requisitos pueden transformarse en conocimiento estructurado accionable por máquina (ontologías) que van más allá de simples grafos de entidad-relación para incluir reglas tipadas, procesos ordenados y esquemas de API.
- Valor Práctico: La herramienta cierra la brecha entre los requisitos legibles por humanos y la ingeniería de software automatizada, permitiendo tareas como la generación de benchmarks automáticos, la creación de corpus de entrenamiento y la generación de código impulsada por el conocimiento.
- Limitaciones y Alcance: El autor establece explícitamente que la evaluación cuantitativa a través de dominios, idiomas adicionales y frente a métodos de extracción base queda para trabajos futuros. Reconoce que, si bien la extracción por LLM logra una alta precisión (96%), la revisión experta sigue siendo necesaria para errores residuales, y el sistema depende de las capacidades del LLM subyacente (por ejemplo, modelos entrenados en chino para terminología china).
- Evolución: El artículo destaca la transición de la estructuración manual (que tomaba semanas para un dominio) a la extracción automatizada (minutos por dominio), señalando además que las tablas siguen siendo un formato desafiante que requiere un procesamiento especializado.
El trabajo concluye que, aunque existen otras afirmaciones que esperan mayor evaluación, DKSE valida con éxito la viabilidad de utilizar pipelines guiados por LLM para estructurar el conocimiento de dominio para la automatización de la ingeniería de software.