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

Resumo Técnico: Ishigaki-IDS-Bench

Declaração do Problema
Enquanto os Modelos de Linguagem de Grande Escala (LLMs) são cada vez mais capazes de gerar saídas estruturadas como JSON, SQL e código, os recursos públicos para avaliar a geração que deve satisfazer simultaneamente esquemas XML padrão da indústria e restrições estritas de vocabulário de domínio permanecem limitados. No domínio da Arquitetura, Engenharia e Construção (AEC), a Modelagem de Informação da Construção (BIM) depende do padrão Industry Foundation Classes (IFC) para representação de dados. A Especificação de Entrega de Informações (IDS) é um padrão baseado em XML usado para definir requisitos de informações legíveis por máquina para esses modelos IFC.

Gerar IDS a partir de requisitos em linguagem natural ou listas de verificação tabulares é uma tarefa complexa de geração estruturada com restrições. Requer não apenas validade sintática, mas também:

1. Conformidade com o Padrão: Adesão ao esquema e padrão IDS.
2. Mapeamento de Vocabulário: Mapear corretamente termos em linguagem natural (por exemplo, "paredes") para classes específicas do padrão IFC.
3. Expressão de Restrições: Definir com precisão restrições de valor (por exemplo, classificações de resistência ao fogo) dentro das unidades de verificação do IDS.
4. Correspondência Semântica: Garantir que o XML gerado reflita a intenção do documento de entrada sem ambiguidade.

Os métodos de avaliação atuais para geração estruturada de propósito geral não abordam adequadamente essas camadas de complexidade específicas do domínio, nem fornecem um quadro para analisar falhas na validade formal versus precisão do conteúdo.

Metodologia
O artigo apresenta o Ishigaki-IDS-Bench, um benchmark projetado para avaliar a capacidade de LLMs de gerar XML IDS a partir de requisitos de informação BIM.

• Construção do Conjunto de Dados: O benchmark consiste em 166 exemplos derivados de 83 cenários práticos, expandidos para japonês e inglês. Esses exemplos foram elaborados e verificados por especialistas em BIM/IDS. O conjunto de dados inclui contextos de entrada (CSV ou linguagem natural), versões IFC alvo e arquivos IDS "ouro" correspondentes.

  • O processo de construção envolveu brainstorming de casos de uso, criação manual de entradas e saídas ouro, revisão por especialistas para correspondência semântica e validação formal usando a IDSAuditTool.
  • Metadados são fornecidos para formato de entrada, idioma, configuração de turno (único vs. múltiplo), versão IFC e domínio de construção.
  • O conjunto de dados foca em três facetas principais: entidade (tipos de elementos IFC), atributo (campos básicos IFC) e propriedade (informações adicionais com conjuntos de propriedades, nomes base, valores, tipos de dados e cardinalidade).

• Protocolo de Avaliação em Duas Etapas:

  1. Validade Formal (Etapa 1): Utiliza a IDSAuditTool para avaliar se a saída gerada é processável e conforma-se aos padrões. Relata três métricas:
     • Processabilidade: Se a auditoria atingiu um estado concluído (ok, erro de estrutura ou erro de conteúdo).
     • Estrutura: Conformidade com a estrutura XML e o esquema XSD IDS.
     • Conteúdo: Conformidade com o padrão IDS e restrições de vocabulário IFC.
  2. Concordância de Conteúdo (Etapa 2): Um avaliador de facetas compara o IDS gerado com o IDS ouro. Normaliza namespaces, espaços em branco e capitalização, e realiza correspondência exata em blocos de comparação (aplicabilidade/requisitos, tipos de faceta e restrições). Esta etapa calcula as pontuações de Precisão, Recall e F1 Macro, capturando falhas onde o XML é válido, mas semanticamente incorreto em relação à entrada.

• Experimentos de Linha de Base: Os autores avaliaram 10 LLMs (incluindo modelos proprietários fechados como GPT-5.5 e modelos de pesos abertos como Qwen3 e Kimi) em um cenário de zero-shot. Os prompts incluíam instruções de tarefa e requisitos de entrada, mas nenhum exemplo few-shot ou referências de IDS ouro.

Principais Contribuições

1. Conjunto de Dados Ishigaki-IDS-Bench: Um benchmark de alta qualidade, verificado por especialistas, contendo 166 exemplos com arquivos IDS ouro e metadados multifacetados, abordando a falta de recursos públicos para geração de XML padrão de domínio em AEC.
2. Quadro de Avaliação em Duas Etapas: Um protocolo que combina verificações de validade formal (via IDSAuditTool) com pontuação de concordância de conteúdo em nível de faceta, permitindo uma análise matizada de onde a geração falha (sintaxe versus semântica).
3. Linhas de Base Zero-Shot e Análise: Avaliação abrangente de 10 LLMs, fornecendo uma visão diagnóstica das capacidades atuais dos modelos e modos de falha na geração de IDS.

Resultados
A avaliação de 10 LLMs revelou desafios significativos na geração estável de IDS:

• Lacuna de Desempenho: O modelo de melhor desempenho, GPT-5.5, alcançou um F1 Macro de 65,6% para concordância de conteúdo, mas apenas uma taxa de aprovação de 27,7% para a auditoria de Conteúdo (conformidade com o padrão IDS e vocabulários IFC).
• Processabilidade versus Conteúdo: Muitos modelos exibiram altas taxas de Processabilidade (por exemplo, 99,4% para Kimi K2.6), mas baixas taxas de aprovação de Conteúdo, indicando que conseguem gerar XML sintaticamente processável, mas lutam para aderir a restrições específicas do domínio.
• Escalonamento de Modelos: Entre os modelos Qwen de pesos abertos, o aumento do tamanho dos parâmetros melhorou as pontuações F1 (de 20,2% para 8B até 26,8% para 397B), mas não melhorou significativamente as taxas de aprovação de Conteúdo (permanecendo entre 10,2% e 19,3%), sugerindo que a escala sozinha é insuficiente para dominar padrões de domínio.
• Efeitos de Entrada e Configuração:
  • Configurações de múltiplos turnos (atualizando IDS existentes) produziram desempenho significativamente maior (84,8% F1 para GPT-5.5) em comparação com a geração de único turno do zero (58,6% F1).
  • Entradas CSV resultaram em pontuações F1 mais altas do que entradas em linguagem natural, provavelmente devido a um mapeamento mais claro de requisitos para facetas.
• Modos de Falha: Erros comuns incluíram violações formais de restrições XSD/IFC, nomes de conjuntos de propriedades incorretos e ambiguidade no mapeamento de alvos em linguagem natural para restrições de valor.

Significado
O artigo posiciona o Ishigaki-IDS-Bench como um recurso diagnóstico, e não como um corpus de treinamento em grande escala. Seu significado reside em:

• Destacar que os LLMs atuais podem expressar requisitos parciais de informação como IDS, mas lutam para gerar saídas estáveis que satisfaçam as restrições rigorosas do padrão IDS e do vocabulário IFC.
• Fornecer um quadro para avaliação comparativa e análise de falhas que pode orientar o desenvolvimento de métodos de geração estruturada com restrições conformes a padrões de domínio.
• Oferecer um modelo para avaliar outras tarefas de geração estruturada específicas de domínio (por exemplo, HL7/FHIR médico, XBRL financeiro) que exigem conformidade com padrões e validação externa.

Os autores afirmam explicitamente que o benchmark foi lançado sob a licença CC BY 4.0 no GitHub e Hugging Face, com scripts de avaliação e documentação de reprodutibilidade fornecidos. Eles notam limitações, como a exclusão de certas facetas (classificação, material) e a dependência de avaliação zero-shot, estruturando o trabalho futuro em torno da extensão desses escopos e da exploração de abordagens few-shot ou ajustadas (fine-tuned).