🤖 AI

Brick-DICL: Dynamic In-Context Learning for Automated Brick Schema Classification

This paper introduces Brick-DICL, a novel two-stage dynamic in-context learning framework that leverages metadata-RAG, class-RAG, and multi-LLM filtering to automate and significantly improve the accuracy of mapping diverse Building Management System points to the standardized Brick schema, thereby overcoming challenges related to extensive class numbers, limited domain knowledge, and manual verification efforts.

Original authors: Yiyue Qian, Shinan Zhang, Huan Song, Negin Sokhandan, Hannah Marlowe, Diego Socolinsky

Published 2026-06-17

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Yiyue Qian, Shinan Zhang, Huan Song, Negin Sokhandan, Hannah Marlowe, Diego Socolinsky

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a massive library of building data, but every building speaks a different language. One building calls a sensor "Temp_Sensor_01," another calls it "AHU_Room_Temp," and a third just writes "Zone 4 Heat." This is the problem with Building Management Systems (BMS). They are the brains of modern buildings, but because different manufacturers use their own messy, non-standard labels, it's incredibly hard to connect them all together to save energy or analyze performance.

To fix this, experts created a "universal dictionary" called the Brick Schema. It has nearly 1,000 specific categories (like "Air Handling Unit" or "Discharge Air Temperature Sensor") that every building should use. The goal is to take those messy, unique labels and automatically translate them into the correct Brick category.

The paper introduces Brick-DICL, a smart system that acts like a super-intelligent translator to do this job automatically. Here is how it works, broken down into simple concepts:

1. The Problem: Too Many Choices and Not Enough Knowledge

Imagine you are trying to guess a word in a game of "20 Questions," but instead of 20 questions, you have to pick the right word out of 936 options all at once. That's the challenge the computer faces. Also, standard AI models (Large Language Models) are like general knowledge experts; they know a lot about the world but don't know the specific, technical rules of building engineering. They might guess "Temperature Sensor" but miss the specific "Discharge Air" part.

Checking the AI's work by hand is like proofreading a 1,000-page book; it takes forever and is boring.

2. The Solution: A Two-Stage Detective Process

Brick-DICL solves this using a "Two-Stage Dynamic In-Context Learning" approach. Think of it as a detective solving a case in two steps, using a special filing cabinet of past cases to help.

Stage 1: The "Similar Case" Search (Metadata RAG)

The Analogy: Imagine you have a new mystery (a messy building label). Instead of guessing from scratch, the system looks through a giant database of previous solved cases to find ones that look very similar.
What it does: It finds 15 past examples that are most like the current label. It shows these examples to the AI, saying, "Look, this past label was called 'Temp_01' and we decided it was a 'Room Sensor.' Since your new label looks just like that, you should probably guess 'Room Sensor' too."
The Result: This gives the AI the specific "building engineering" knowledge it was missing, helping it make a good first guess.

Stage 2: The "Narrowing Down" Search (Class RAG)

The Analogy: Even with a good first guess, the AI might still be confused between 936 options. Imagine the AI guessed "Temperature Sensor." Now, instead of asking it to pick from all 936 options, the system says, "Okay, let's ignore everything else. Let's only look at the 20 types of temperature sensors that are most similar to your guess."
What it does: It takes the AI's first guess and finds the 20 most relevant categories in the Brick dictionary. It then asks the AI to choose the best one only from those 20.
The Result: This makes the job much easier. It's like asking someone to pick the best apple from a basket of 20, rather than picking the best fruit from a whole grocery store.

3. The Safety Net: The "Panel of Judges" (Multi-LLM Filtering)

Even smart detectives make mistakes. To avoid sending bad translations to humans to fix, Brick-DICL uses a Multi-LLM mechanism.

The Analogy: Imagine you have three different expert judges. They all look at the same case independently.
- If all three judges agree on the answer, the system is confident and accepts it automatically.
- If the judges disagree (e.g., Judge A says "Room Sensor," Judge B says "Outdoor Sensor"), the system flags this as "Low Confidence."
The Result: Humans only have to step in to fix the cases where the AI judges are arguing. This saves a massive amount of time because the system handles the easy, obvious cases on its own.

The Bottom Line

The paper claims that this Brick-DICL system is:

General: It works on any building, no matter who built it or what weird labels they used.
Powerful: It is the first system to use this "dynamic" two-step search method for this specific problem, and it got much higher accuracy scores than other methods (like standard AI models or simple guessing).
Efficient: By using the "Panel of Judges" to filter out uncertain answers, it drastically reduces the amount of manual work humans need to do to get buildings "digitally onboarded."

In short, Brick-DICL is a smart, two-step translator that uses past examples to learn the rules, narrows down the choices to make the job easier, and uses a team of AI judges to ensure humans only have to fix the tricky mistakes.

Technical Summary: Brick-DICL

Problem Statement

Building Management Systems (BMS) are critical for optimizing energy efficiency and operational performance in modern buildings. However, a significant barrier to integration and data utilization is the lack of standardization in BMS point metadata across different manufacturers. While the Brick schema offers a standardized, open-source ontology to represent building assets, systems, and their relationships, mapping raw BMS points to the appropriate Brick classes remains a complex task. The authors identify three primary challenges:

Scale: The latest Brick schema contains 936 distinct classes, creating a massive multi-class classification problem.
Domain Knowledge Gap: Large Language Models (LLMs), despite their general capabilities, often lack the specific domain knowledge required to accurately classify BMS points due to insufficient exposure to specialized datasets.
Verification Burden: Manually verifying the classification results generated by LLMs is labor-intensive and time-consuming, particularly when processing thousands of points across multiple buildings.

Methodology: Brick-DICL

To address these challenges, the authors propose Brick-DICL, a two-stage Dynamic In-Context Learning (DICL) framework enhanced by Retrieval-Augmented Generation (RAG) and a multi-LLM filtering mechanism.

1. Two-Stage Dynamic In-Context Learning

Unlike traditional In-Context Learning (ICL) which uses a fixed set of examples, Brick-DICL dynamically retrieves relevant context to guide the LLM.

Stage One: Metadata Dynamic ICL (Metadata RAG)
- Goal: Generate an initial prediction for the Brick class based on the BMS point's metadata attributes.
- Mechanism: A vector database is constructed from training examples. For a new BMS point, the system computes an embedding of its attributes and retrieves the top- $k$ most similar examples using cosine similarity.
- Process: These retrieved examples, which demonstrate how similar attribute combinations map to specific classes, are concatenated with the new input to form a dynamic prompt. The LLM generates an initial class prediction ( $c^{(1)}_{brick}$ ), a justification ( $j$ ), and a confidence score ( $s$ ).
Stage Two: Class Dynamic ICL (Class RAG)
- Goal: Refine the initial prediction by narrowing the classification space from 936 classes to a semantically relevant subset.
- Mechanism: Using the Stage One prediction, the system retrieves the top- $m$ (e.g., 20) most similar Brick classes from the full schema.
- Two-Step Generation:
  1. The LLM evaluates all retrieved classes and selects 5 preliminary candidates.
  2. The LLM performs a focused evaluation on these 5 candidates to select the top 3 most likely classes with normalized probabilities.
- Output: The final output includes the top 3 predicted classes, their probabilities, justifications, and confidence scores.

2. Multi-LLM Filtering Mechanism

To reduce manual verification efforts, the framework employs multiple LLMs to generate predictions for both stages. A filtering strategy is applied to identify low-confidence generations that require human review. The authors propose four strategies to assess consensus:

All Agreement: Flags low confidence if any prediction (Stage 1 or Stage 2 top-3) differs across models.
Top-3 Consensus: Flags low confidence if there is no complete overlap in the top-3 classes across all models.
Top-1 Agreement: Flags low confidence if the single top prediction differs across models.
Any-2 Consensus: Flags low confidence if fewer than two common classes exist among the top-3 predictions of the models.

Flagged cases are routed to a human validation interface, while high-confidence cases are accepted automatically.

Key Contributions

The paper claims three primary innovations:

Generalizability: Brick-DICL is a general framework applicable to any BMS regardless of manufacturer or metadata format, utilizing metadata and class RAG to map points to Brick classes.
Novelty and Power: It is the first approach to design dynamic in-context learning specifically for handling the large number of Brick classes and the lack of domain knowledge in LLMs. It outperforms existing methods on building datasets.
Efficiency: The multi-LLM filtering strategy significantly reduces manual verification effort by automatically flagging only ambiguous or low-confidence classifications for human review.

Experimental Results

The framework was evaluated on two building datasets (B1 and B2) containing BMS metadata and ground-truth Brick labels.

Performance vs. Baselines: Brick-DICL consistently outperformed eight baseline models, including prompting-based methods (standard, static, random, and dynamic ICL) and fine-tuned pre-trained language models (BERT, DistilBERT, RoBERTa, SciBert). Specifically, it achieved superior Hits@1 and Hits@3 accuracy on both buildings.
Hyperparameter Impact:
- Shots (Stage 1): Performance generally improved with more shots, with 15-shot ICL achieving the best results.
- Retrieved Classes (Stage 2): Retrieving 20 classes yielded optimal performance; increasing beyond this introduced noise.
Filtering Strategies: The Any-2 Consensus strategy was found to offer the optimal balance, achieving the lowest disagreement ratio (minimizing manual review) while maintaining strong classification accuracy.
Ablation Study: Removing either the Metadata DICL or Class DICL components led to moderate performance drops, while removing both resulted in a significant decline, confirming that all modules are essential for optimal accuracy.

Significance

The paper concludes that Brick-DICL effectively addresses the challenges of standardizing diverse BMS points. By combining dynamic retrieval with multi-LLM consensus, the framework accelerates the path toward standardized, interoperable building management systems. It enables rapid digital building onboarding by achieving high classification accuracy with minimal human intervention, thereby facilitating better data access for building commissioning and energy management.