Cartographie sémantique des demandes d’information (QRT) vers les éléments BIM à l’aide de grands modèles de langage

Une QRT est une question formelle au sujet de quelque chose que l’auteur suppose que vous pouvez identifier, une porte, un parapet, un type de fenêtre à un niveau précis. Le modèle BIM détient déjà cette chose sous forme de dossier typé. Rien dans les données ne relie les deux, alors répondre à une QRT oblige une personne à fouiller les plans et les devis à la main. L’article cite une estimation de 17 heures-personnes pour traiter une seule QRT, et des retards liés aux QRT qui comptent pour jusqu’à 10 % de la durée du projet.

La plupart des tentatives de combler cet écart confient toute la question au modèle de langage. Voici le texte, voici le catalogue, dis-moi de quel élément il s’agit. Ça fonctionne assez souvent pour faire une démo et ça échoue exactement là où ça compte, parce qu’il n’y a aucun moyen de montrer pourquoi tel élément a été retenu.

Le modèle propose des indices. Les règles décident.

Le prototype est un module d’extension Revit relié à un service Python. Le modèle de langage lit la QRT et retourne un objet JSON strictement formaté d’indices d’intention, discipline, objet principal, mots-clés, références spatiales, dimensions. Il lui est explicitement interdit de nommer des identifiants BIM, des catégories Revit ou des instances d’éléments. La sélection passe ensuite par cinq étapes ordonnées appliquées aux métadonnées du modèle lui-même, chacune apportant un pointage interprétable, une correspondance d’identifiant direct, le contexte spatial, le contexte de système pour la mécanique, l’électricité et la plomberie, un préscore lexical et par mots-clés, et enfin la similarité d’embeddings pour le classement. Une personne confirme le résultat avant que le lien soit réécrit dans le modèle.

Parce que le modèle ne peut pas introduire un élément qui n’est pas déjà au catalogue, une hallucination n’a nulle part où aller. C’est la véritable prétention de cette conception, et elle est structurelle plutôt qu’affaire de qualité d’invite.

Le constat le plus important est un constat négatif

Sur le projet réel, GPT-4.1 a obtenu 60,27 % avec extraction d’intention et 60,27 % sans. Le plus petit GPT-4.1-mini a même fait légèrement moins bien avec les indices d’intention que sans, 56,16 % contre 58,9 %. Les auteurs concluent que la performance tient d’abord à l’appariement fondé sur des règles et à la qualité des métadonnées BIM, pas à l’apport du modèle de langage.

Pour un article qui porte sur l’application des LLM, c’est un résultat d’une honnêteté inhabituelle, et c’est la raison pour laquelle nous avons suivi celui-ci. Il dit que la partie utile du système est celle que vous pouvez auditer.

L’autre contrainte relève des données, pas de la méthode. Les deux échecs sur le modèle expérimental venaient de QRT renvoyant à des pièces sans association de pièce au niveau de l’instance dans le modèle. Sur le projet réel, la plupart des QRT circulaient par courriel, le contexte véritable se trouvant dans des plans annotés en pièce jointe, ce qui explique que seulement 74 des 524 aient comporté assez de texte pour qu’on puisse même tenter le rattachement.