Ishigaki-IDS-Bench: A Benchmark for Generating Information Delivery Specification from BIM Information Requirements

Resumen Técnico: Ishigaki-IDS-Bench

Enunciado del Problema
Aunque los Modelos de Lenguaje Grandes (LLM) son cada vez más capaces de generar salidas estructuradas como JSON, SQL y código, los recursos públicos para evaluar la generación que debe satisfacer simultáneamente esquemas XML de estándares industriales y restricciones estrictas de vocabulario de dominio siguen siendo limitados. En el dominio de la Arquitectura, Ingeniería y Construcción (AEC), la Modelación de Información de Construcción (BIM) depende del estándar de Clases de Fundamentos de la Industria (IFC) para la representación de datos. La Especificación de Entrega de Información (IDS) es un estándar basado en XML utilizado para definir requisitos de información legibles por máquina para estos modelos IFC.

Generar IDS a partir de requisitos en lenguaje natural o listas de verificación tabulares es una tarea compleja de generación estructurada con restricciones. Requiere no solo validez sintáctica, sino también:

1. Conformidad con el Estándar: Adherencia al esquema y estándar IDS.
2. Mapeo de Vocabulario: Mapear correctamente los términos del lenguaje natural (por ejemplo, "muros") a clases específicas del estándar IFC.
3. Expresión de Restricciones: Definir con precisión las restricciones de valor (por ejemplo, clasificaciones de resistencia al fuego) dentro de las unidades de verificación IDS.
4. Correspondencia Semántica: Asegurar que el XML generado refleje la intención del documento de entrada sin ambigüedad.

Los métodos de evaluación actuales para la generación estructurada de propósito general no abordan adecuadamente estas capas de complejidad específicas del dominio, ni proporcionan un marco para analizar los fallos en la validez formal frente a la precisión del contenido.

Metodología
El artículo introduce Ishigaki-IDS-Bench, un punto de referencia diseñado para evaluar la capacidad de los LLM para generar XML IDS a partir de requisitos de información BIM.

• Construcción del Conjunto de Datos: El punto de referencia consta de 166 ejemplos derivados de 83 escenarios prácticos, expandidos tanto en japonés como en inglés. Estos ejemplos fueron redactados y verificados por expertos en BIM/IDS. El conjunto de datos incluye contextos de entrada (CSV o lenguaje natural), versiones objetivo de IFC y archivos IDS "dorados" correspondientes.

  • El proceso de construcción involucró la lluvia de ideas de casos de uso, la creación manual de entradas y salidas doradas, la revisión experta para la correspondencia semántica y la validación formal utilizando la IDSAuditTool.
  • Se proporciona metadatos para el formato de entrada, el idioma, la configuración de turno (único vs. múltiple), la versión de IFC y el dominio de construcción.
  • El conjunto de datos se centra en tres facetas principales: entidad (tipos de elementos IFC), atributo (campos básicos de IFC) y propiedad (información adicional con conjuntos de propiedades, nombres base, valores, tipos de datos y cardinalidad).

• Protocolo de Evaluación en Dos Etapas:

  1. Validez Formal (Etapa 1): Utiliza la IDSAuditTool para evaluar si la salida generada es procesable y cumple con los estándares. Informa tres métricas:
     • Procesabilidad: Si la auditoría alcanzó un estado completado (ok, error-estructura o error-contenido).
     • Estructura: Conformidad con la estructura XML y el esquema XSD IDS.
     • Contenido: Conformidad con el estándar IDS y las restricciones de vocabulario IFC.
  2. Acuerdo de Contenido (Etapa 2): Un puntuador de facetas compara el IDS generado con el IDS dorado. Normaliza los espacios de nombres, los espacios en blanco y las mayúsculas, y luego realiza una coincidencia exacta en los bloques de comparación (aplicabilidad/requisitos, tipos de facetas y restricciones). Esta etapa calcula las puntuaciones de Precisión, Recall y Macro F1, capturando fallos donde el XML es válido pero semánticamente incorrecto en relación con la entrada.

• Experimentos de Línea Base: Los autores evaluaron 10 LLM (incluyendo modelos propietarios cerrados como GPT-5.5 y modelos de pesos abiertos como Qwen3 y Kimi) en un entorno de zero-shot. Los prompts incluyeron instrucciones de tarea y requisitos de entrada, pero no ejemplos few-shot ni referencias a IDS dorados.

Contribuciones Clave

1. Conjunto de Datos Ishigaki-IDS-Bench: Un punto de referencia de alta calidad, verificado por expertos, que contiene 166 ejemplos con archivos IDS dorados y metadatos multifacéticos, abordando la falta de recursos públicos para la generación de XML con estándares de dominio en AEC.
2. Marco de Evaluación en Dos Etapas: Un protocolo que combina verificaciones de validez formal (mediante IDSAuditTool) con puntuación de acuerdo de contenido a nivel de facetas, permitiendo un análisis matizado de dónde falla la generación (sintaxis vs. semántica).
3. Líneas Base Zero-Shot y Análisis: Evaluación exhaustiva de 10 LLM, proporcionando una visión diagnóstica de las capacidades actuales de los modelos y los modos de fallo en la generación de IDS.

Resultados
La evaluación de 10 LLM reveló desafíos significativos en la generación estable de IDS:

• Brecha de Rendimiento: El modelo de mejor rendimiento, GPT-5.5, logró un Macro F1 del 65.6% para el acuerdo de contenido, pero solo una tasa de aprobación del 27.7% para la auditoría de Contenido (conformidad con el estándar IDS y vocabularios IFC).
• Procesabilidad vs. Contenido: Muchos modelos exhibieron altas tasas de Procesabilidad (por ejemplo, 99.4% para Kimi K2.6) pero bajas tasas de aprobación de Contenido, lo que indica que pueden generar XML sintácticamente procesable pero luchan por adherirse a restricciones específicas del dominio.
• Escalado de Modelos: Entre los modelos Qwen de pesos abiertos, aumentar el tamaño de los parámetros mejoró las puntuaciones F1 (de 20.2% para 8B a 26.8% para 397B), pero no mejoró significativamente las tasas de aprobación de Contenido (permaneciendo entre 10.2% y 19.3%), lo que sugiere que la escala por sí sola es insuficiente para dominar los estándares de dominio.
• Efectos de Entrada y Configuración:
  • Las configuraciones de múltiples turnos (actualizar IDS existentes) produjeron un rendimiento significativamente mayor (84.8% F1 para GPT-5.5) en comparación con la generación de un solo turno desde cero (58.6% F1).
  • Las entradas CSV resultaron en puntuaciones F1 más altas que las entradas de lenguaje natural, probablemente debido a un mapeo más claro de los requisitos a las facetas.
• Modos de Fallo: Los errores comunes incluyeron violaciones formales de las restricciones XSD/IFC, nombres de conjuntos de propiedades incorrectos y ambigüedad en el mapeo de objetivos de lenguaje natural a restricciones de valor.

Significado
El artículo posiciona a Ishigaki-IDS-Bench como un recurso diagnóstico en lugar de un corpus de entrenamiento a gran escala. Su significado radica en:

• Destacar que los LLM actuales pueden expresar requisitos parciales de información como IDS, pero luchan por generar salidas estables que satisfagan las restricciones rigurosas del estándar IDS y el vocabulario IFC.
• Proporcionar un marco para la evaluación comparativa y el análisis de fallos que puede guiar el desarrollo de métodos de generación estructurada con restricciones que cumplan con los estándares de dominio.
• Ofrecer una plantilla para evaluar otras tareas de generación estructurada específicas del dominio (por ejemplo, HL7/FHIR médico, XBRL financiero) que requieren conformidad con estándares y validación externa.

Los autores declaran explícitamente que el punto de referencia se publica bajo la licencia CC BY 4.0 en GitHub y Hugging Face, con scripts de evaluación y documentación de reproducibilidad proporcionados. Señalan limitaciones, como la exclusión de ciertas facetas (clasificación, material) y la dependencia de la evaluación zero-shot, enmarcando el trabajo futuro en la extensión de estos alcances y la exploración de enfoques few-shot o ajustados (fine-tuned).