Semantic Mapping of Request for Information (RFI) to BIM Elements with Large Language Models
RFIs cause a lot of headaches. They're written in ordinary language, they carry no structure, and despite years of tooling around them the process is still slow, still manual, and still open to being gamed. This study looks at whether LLMs can help by automatically matching RFIs to elements of the BIM model. The approach keeps the language model out of the decision: it reads the RFI for intent cues, then a five-stage pipeline of identifier, spatial, and system checks ranks the candidate elements, and a person confirms the link. Where the prototype failed, it failed on metadata; missing room associations, absent identifiers, thin model detail. That's a data problem, and it's the one worth solving first.
EC3 2026: European Conference on Computing in Construction
Corfu, Greece
Artificial Intelligence in AEC
Supported by Mitacs, NSERC, CREO Solutions
The session, as delivered
Preliminary work, full paper forthcoming
As published
Requests for Information (RFIs) remain a critical yet poorly integrated component of construction workflows, typically managed as unstructured text disconnected from Building Information Modeling (BIM) data.
Existing studies primarily focus on reducing RFI frequency or response time, with limited focus on linking RFI content to specific BIM elements.
This study presents a data-driven framework that combines large language model (LLM)-based intent extraction with BIM metadata reasoning through a staged matching pipeline.
By separating semantic cue extraction from rule-based element selection, the framework enhances interpretability and robustness.
Validation on experimental and real-world datasets demonstrates reliable element and family-level retrieval.
Preliminary work, full paper forthcoming
The model proposes. The rules decide.
An RFI is a formal question about something the writer assumes you can identify: a door, a parapet, a window type on a particular level. The BIM model already holds that thing as a typed record. Nothing in the data connects the two, so answering an RFI means a person searching drawings and specifications by hand. The paper cites an estimate of 17 person-hours to process a single RFI, and RFI-related delays accounting for up to 10% of project duration.
Most attempts at closing that gap hand the whole question to a language model: here is the text, here is the catalogue, tell me which element it means. That works often enough to demo and fails where it matters, because there is no way to show why a given element was chosen.
The model proposes cues. The rules decide.
The prototype is a Revit add-in bridged to a Python service. The language model reads the RFI and returns a strictly formatted JSON object of intent cues, discipline, primary object, keywords, spatial references, dimensions. It is explicitly forbidden from naming BIM identifiers, Revit categories or element instances. Selection then runs through five ordered stages against the model's own metadata, each contributing an interpretable score: a direct identifier match, spatial context, system context for MEP, a lexical and keyword prescore, and finally embedding similarity for ranking. A person confirms the result before the link is written back.
Because the model cannot introduce an element that is not already in the catalogue, a hallucination has nowhere to go. That is the design's real claim, and it is a structural one rather than a matter of prompt quality.
What the study measured
Two environments: one authored model, one live project
The finding that matters most is a negative one
On the real project, GPT-4.1 scored 60.27% with intent extraction and 60.27% without it. The smaller GPT-4.1-mini actually did slightly worse with intent cues than without, 56.16% against 58.9%. The authors conclude that performance is driven primarily by the rule-based matching and the quality of the BIM metadata, not by what the language model contributed.
For a paper about applying LLMs, that is an unusually honest result, and it is the reason we followed this one. It says the useful part of the system is the part you can audit.
The other constraint is data, not method. The two failures on the experimental model both came from RFIs referring to rooms that had no instance-level room associations in the model. On the real project, most RFIs were communicated by email with the actual context in marked-up drawing attachments, which is why only 74 of 524 had enough text to work with at all.
How it generalises : the study's terms, and the pattern underneath them
Nothing in the pipeline assumes a particular industry
A message, ticket, notice, filing or report, written in natural language, about something the writer assumes you can identify.
An asset registry, contract schedule, product master or case file: the system that already holds the entity as a typed record.
The record joined to the entity it governs, with the reasoning shown, which is what makes the graph usable as evidence.
The team behind the record

Prof. Mazdak Nik-Bakht, PhD, PEng
Associate Professor & Associate Dean of Research & Innovation, Gina Cody School of Engineering & Computer Science, Concordia University
Cite this record
Joy, L. P., Zarei, F., & Nik-Bakht, M. (2026). Semantic Mapping of Request for Information (RFI) to BIM Elements with Large Language Models. Proceedings of the 2026 European Conference on Computing in Construction (EC3), Corfu, Greece, July 12-15, 2026. https://doi.org/10.35490/EC3.2026.337
Cite the source, not this page. This record is Storia's summary of work published by the authors. The paper at the DOI above is authoritative: where our reading and the paper differ, the paper is right.
Open to collaboration
Working on the same problem somewhere else?
We're open to collaborations with groups working on knowledge graphs, semantic retrieval, and evidence you can defend, in any domain where unstructured records have to be tied back to the entities they govern. We can bring real problem statements and anonymised datasets.
Contact the research team


