Optimizing Revit Structural Intelligent Models with Large Language Models and Autodesk Platform Services

ABHISHEK SHINDE: Hello, everyone. Welcome to AU industry talk presentation, title, "Optimizing Revit Structural Intelligent BIM models using LLMs and Autodesk Platform Services." I'm Abhishek Shinde, and I'm going to be the speaker for this talk.

Before getting into these details, I would like to introduce myself and the company. I'm a former licensed architect with a bachelor's in architecture from India and a master's in architectural design research from the University of Michigan with a focus on computational design and digital fabrication. At TYLin Silman Structural Solutions, the three primary projects I'm working on are embodied carbon tool inside Revit using PyRevit, one computational beam data model for interop from Revit, two other softwares, and chatbot integration using a large language model for the building sector of TYLin for various use cases.

Since its inception in 1966 to rebranding in 2024, TYLin Silman Structural Solutions has expanded their service offerings more towards digital delivery and data analytics with advanced computational design and AI workflows for circular construction and for the builder environment.

Before introducing the use case of large language model and why Silman is exploring a large language model in their business case, I would like to introduce Silman Colab, which is a part of Silman, a structural design firm in Boston. From 2024 due to acquisition by TYLin, which is a leading North American engineering firm, we have rebranded ourselves as Silman Structural Solutions, as we know, along with several special IT firms, like Perkins&Will, Dar, and a network of firms, like Maffeis, Currie & Brown, and Penspen, and Introba.

The computational design group Silman Colab is a small group of expert computational designers and structural engineers, which are a part of a bigger collaborative group called Sidara. Within Sidara collaborative, we share computational tools, beam workflows, and AI tools. This collaborative space allows engineers to share their workflows and also develop their existing tools.

Before I begin my presentation, I would like to say that this is the mission statement for today's presentation. I want to empower all of my fellow attendees to augment their AC workflows by looking at the case study of Silman's proposed solution, where we are integrating computational design workflows using BIM-LLM pipeline, which is later fine-tuned by GraphRAG pipeline. So it leverages API offerings by APS, Revit API, Neo4jGraphRAG chatbot for augmenting your BIM-LLM pipelines. For those who are not aware of these concepts and this technical jargon, the resources are available in the handout.

So for today's agenda and the mission statement, which I just presented, I want to divide this into four subtopics. Each of these subtopics would have a questionnaire where you could ask me questions, but here are the four subtopics. The first is constructing your AEC business case, architectural engineering business case, using LLMs, where we will learn how Silvan is leveraging LLM, which is OpenAI for structural optimization and SE 2050 challenge, which is the embodied carbon challenge.

We will learn how to prepare our beam data from Revit using PyRevit and C# add-in, which connects to a graph database, which is Neo4j. We will learn about Rhino.Inside Revit workflow. We will learn about embodied carbon share, meta and parameter generation, optionally using one-click LCA, and Karamba and Galapagos. And then we will learn about querying the Revit model in APS using GraphQL via a text prompt from a user.

The last section which we will explore is CAD-LLM research, which is beyond optimization, kind of where we extend the LLMs with using API offerings from Autodesk, especially the Autodesk AEC Data Model Exchange API. And we will also look at what is GraphRAG and what is knowledge graph. So don't worry. We will get started with the presentation.

So for the first section, it is very important to understand before crafting your business case on what are the day to day workflows at TYLin Silman Structural Solution. There are four main things, which I am trying to understand before I craft my business case.

The first is the interoperability workflow, the embodied carbon workflow, the structure analysis workflow, and AI-driven communication in the builder environment. These four factors or parameters, I say, are very important to craft the business case, or the business challenge in the age of generative AI for Silman and TYLin's building sector.

The current workflow of interoperability between engineers and different stakeholders between the various department is not a linear process. Interoperability and data standardization is a big challenge. Everybody has their own workflows. And it's kind of we all are seeking within this plethora of multiple tools, one data model, a single source of truth, while yet having this customized workflow, and keeping the expertise within the system of these workflows.

We can see the similar pattern with the embodied carbon workflow we have at TYLin. When we work with our stakeholders and our partners, like Perkins & Wilson, Introba, we have our custom workflows with One Click LCA and Tally Cat, a custom program where we generate dashboards and Excel sheets, where we share the projects.

It seems to me that standardization for digital delivery is a key challenge we are looking at, and we are actively solving within different forms within the Sedaro group. And this is one of the big challenges. And the third one is the landscape of the optimization tools.

As we know, Autodesk offers a wide range of AC building suite, yet there are-- yet the structural analysis tools have not been explored to the fullest, actually. We actually use several other tools, like ETABS, RISA, RAM, SAP2000, SOFiSTiK, Karamba, and Tekla.

Each of these tools have their own pros and cons, like ETABS is used for seismic design, building structures and dynamic analysis, while Tekla is used for more structural detail, drawing for RCC steel. All of these tools in combination are used for RCC steel and hybrid.

But however, due to most of the early stage design exploration from the architect side who are our stakeholders, use Rhino as a modeling environment. So it was very essential to understand this workflow between Revit and Rhino using Rhino.Inside. We tend to use the same environment as the stakeholders so that we kind of have the analysis software moved from other tools to more Revit-centric workflow.

The fourth business challenge. So I feel like in future how we communicate our structural BIM model for a full-click LCA and structural engineering will change a lot, especially in the age of large language model and generative AI. In my opinion, the information we communicate on site for handling deliverable information, RFIs and submittals, will significantly change from what we are giving for deliverables.

This will apply for different design processes, like architecture design, urban planning, climate consultancy, facade design, circular construction, et cetera. And to sum up all of these four business challenges, I will not craft it as one business challenge, which is SE 2050 optionality and structural optimization. How can we combine structural analysis and embodied carbon and do optimization of our Revit model?

While the choice of analysis tools can vary, but, however, how can this all be in a single data-centric format. As we said, we all are seeking one model, one data, one single source of truth in all of our workflows. So this is the proposed solution.

The proposed solution, which I'm proposing in my research, is a large language model plus structural optimization with one BIM graph data set. And I will explain about one BIM graph data set. What is that?

We know structural engineers and architects are constantly updating their models. Some of them are hosted on BIM 60, while some of them are coordinated with cloud sharing. In the early design phase, structural engineers do not have to model or the BIM engineers do not have to model in the LOD 400 stage.

So I believe if a user can just prompt in a user interface, which is like a ChatGPT, we can perform optioneering using structural analysis in the backend without having to run a structural analysis tool. And we save a lot of time. And this is why the proposed solution of the ideation of the solution looks like this.

So I want to introduce you to APS LLM-powered web app, which allows for querying your Revit models, Revit structural models via open API as a large language model. While creating, there is a GraphQL and Neo4j, which are the underlying technologies behind this data model.

And we store this graph data in a database, which we will explore in upcoming sessions. Before we get into the details of APS-LLM solution, let's look briefly into the breakthroughs of LLMs. What exactly are LLMs? What is natural language processing?

So natural language processing, which is a field from machine learning. And the subfield of natural language processing is called as language model. Language modeling is a fundamental approach of achieving cognitive intelligence in the field of natural language processing. And its progress has been recently-- has been notable within recent years.

In the above diagram, you can see the first paper for Eliza, the chatbot for therapy, was written in the year 1960, which was the first stepping stone for NLP. Also, deep learning methods in machine learning, like CNNs, RNNs, and ANNs. Also, word to vector have made significant contributions to natural language processing and the way we understand text.

The recent paper by Google researchers, like "Attention is all you need," led to the birth of transformers, which serves as the foundation for a language model, large language model. We know that OpenAI, which is based on GPT, which is a kind of a transformer, is one of the breakthroughs in the LLMs.

Let's now understand-- in the previous slide, we saw the breakthroughs. Now let's understand how LLMs work, what exactly happens below, beneath this, the hood. A language model takes a user prompt, converts that into text tokens as inputs from the user prompt, and returns a probability distribution for the next token. These tokens are basically the units of data processed by the model.

When a text is tokenized, each text is converted into a vector. So these user prompts are converted into tokens, and then vectors, which are also called as embeddings, capture the semantic meaning of a user prompt, and returns the same response to the user. The first famous, as I said, is OpenAI ChatGPT. You do not have to worry about the terms tokens, vector tokenization methods, and foundation models. You can find that in the handout.

Now, I have explained you the concepts of how the breakthroughs in LLMs are, what LLMs, and how they work. Let's see what LLMs can offer in ACO. I have just five important points which I feel are curious, which Silman is exploring. The rest of the use cases and application opportunities are in the handouts.

The first is easy query of your AC data model from ACC and N360, using API offerings from Autodesk. The second application is markup automation and data labeling using vision language model. The third is co-designing with your architects and consultants, which I was telling about early stage on design using simple prompts.

And then you can rank your designs with assigning a ranking system to these tokens or these prompts, where in which you can also do optioneering. And the last is LLMs for RFIs and submittals. You can basically connect all of these documents to your BIM model, and then do a summarization task.

So these are the key takeaways, which we saw. We basically want to have this takeaway for everyone, if they want to use a large language model, is identify your business case. Identify your data strategy, define what kind of LLM are you using. Is it OpenAI? Is it going to be something by Google, or Facebook?

What is-- and how are these LLM frameworks really feeding your AEC business case. Then you should look at testing early on with your beam workflows in SEC. You should also look at developing your apps on APIs using different API offerings, and do early on experimentation.

And lastly, I feel to pretrain your LLM for your business case, you have to continuously iterate this process between different departments and stakeholders, like BIM and computational design. I hope you have understood this subject. I would like to move to the next section, the second section.

For our second section, we will describe the process of optioneering and optimization. We'll basically prepare our BIM data using PyRevit, and also look at different interoperability workflows. I will also talk about my internal tools in Revit and C#. And we also talk about Neo4j RRDB, where I'm storing my Revit model, metadata model.

I came across this interesting quote by Jeff Hawkins to start with this section. "Knowledge in the brain is distributed. Nothing we know is stored in one place, such as one cell or one column." As computational design architects and structural engineers, or any role you have within the AEC business, we make our design and team choices based on experts we have within our department.

We rank our design based on a ranking system. That's how genetic algorithms work. Also, as social animals, we constantly seek connections, inspiration, and references to our past design, and also look at our bylaws for design and engineering application. It is also evident from how our brain works.

For the same reason I'm exploring BIM data models as a distributed, yet connected system, where the granular metadata of every Revit element is connected and yet distributed. But then, again, one single, one model, one single source of truth.

Graphs everywhere-- that's where I want to come into. This distributed connected system not only connects different semantic information from different stakeholders, but also structural engineering, mathematical modeling strategies, like graphics statics, which are used for designing cell structure. But it also marries with machine learning methods, detective graphs, like classification, GANs, graph databases like Neo4j, and also knowledge graph, which is an active subject of research in a large language model.

That's why I say intelligent structural BIM data model as a graph serve as an underlying data structure for representing AC data at Silman, where each data set is connected to several semantic information. Do not worry. We will encounter the whole process.

Looking at-- this is what I want to say. As I said, intelligence structure will be modeled as a graph. This is what I want to represent through a diagram. This BIM data model as a graph, when combined with LLMs, can augment your workflows, especially using API offerings from Autodesk Platform Services.

The first image is a research project from Autodesk Research Group, where a building was represented as a graph. And it was done within Autodesk. And drawing inspiration, I took an inspiration to design a truss, where I'm connecting all of these elements via nodes.

In the diagram on your left, the orange and blue nodes represent columns and beams, and their edges represent the connectivity. This is more like a complex graph with multiple nodes. On the other hand, for truss, it's more like a primary graph where there is a node of a single type, which represents the truss nodes. And the connection is represented by blue nodes.

To represent the structural model as a graph, we look at a case study of Pratt truss design, designing, basically, a Pratt truss for a parking roof structure. Since our client's data is priority, it was very essential to test some of the sample models which Autodesk provides. And I'm exploring the parking structure, designing the structure, a simple structure with parking, a roof truss, and wanted to explore our optioneering and the day to day workflow with optimization, and then curating with the LLM works.

So I use Rhino.Inside Revit for this process. I send the model from Revit to Rhino. Then using Karamba, we optimize the truss for the height design, and also, this enabled us to choose the family, which is there from the Silman's BIM family.

And also, this family of the steel in Revit has the embodied carbon information, which I will explore, which is linked to our existing workflows with EPDs at Silman. This is the Grasshopper script for the same in Karamba. These are the different sections. The first section is where you use Rhino.Inside to import the Revit geometry. The second is you generate the loading conditions and define loads and supports. The third is where you analyze the model. The fourth is where you use Galapagos for optimization for your business strategy.

For this use case, I'm optimizing my structure for minimizing the displacement and the input parameters for this are the height of the structure, and also the size of the steel, as its the W sections as per North American Standard.

The fifth is you visualize your model. The sixth part, you take the analyzed model, and use one-click LCA to understand how do you reduce the carbon. And then in seventh, I use the Galapagos. So I'm optimizing in 4 and 7 two times. And then the eighth section, it's all about generating database to Neo4j.

I would explain more of the details of it in my handouts, but just a snapshot, if anybody is curious, like how the optimization process has done for displacement. This is a screenshot. This is the optimized model of the truss. You can see the cross sections are on the bottom from W4X13 to W5X16. The vertical and the bracing are the same size. The top members are of different size. And you can see the uniform distributed load.

And then what I do is once we are satisfied with this thing, we go back to Revit, and we change these member sizes based on what Karamba is suggesting us. So that's the round tripping, which we do.

So once again, to conclude, the step one is analyze. Send your model from Revit to Rhino.Inside, analyzing Karamba and Galapagos, and then do a round tripping, and bake your parameters in Revit using share parameters. And I will explain how the share parameters work with One Click, and also with Karamba.

This is how it works. So I have developed-- I have spent the last six months developing this Silman Analytics, which is a toolkit for embodied carbon. It is basically comprised of three buttons. Excel to JSON, which generates a schema for embodied carbon, which can be used for further processing web application, or maybe for GraphQL.

The second it generates is the user selects the database name of the structure elements, which One Click LCA tells us. And then the last is just generating a normal take off of the Revit elements.

To give you a rough overview, this is how the process looks. We have an Excel sheet from our internal workflows with [INAUDIBLE]. We generate a schema. We generate-- we have a shared parameter table, which serves as a foundation for generating the Revit share parameters. You can see on the right side the share parameters generated.

And then we can export it as a CSV or Excel, or to a graph database. The step two is this one. You use PyRevit to generate this toolkit of embodied carbon. And we generate the CSV.

The alternative step, what I'm exploring is in my first step, which you saw was basically I'm using CSV, and then uploading manually in Neo4j. But then the recent development in C# add-ins allowed me to-- which is still a work in progress, allow me to develop a tool which does a live connection with Neo4j. And this is, again, a C# add-in. I will give you the details more in the handouts on how I have developed this, and then I generate the one BIM graph DB.

This is the screenshot. This is how the knowledge graph looks like in Neo4j or a database, where TG1, TG2 are all the node sizes and relationships. And then we have two CSV files. One is a relationship and member.

Now you can compare the way the graph looks is similar to how a truss would look. And the connection represents whether it's a top cord, or a bottom cord, or a diagonal web, or a vertical cord. And that's the matching cipher query, which I will talk about in a further slide. This is just a screenshot of the Neo4j Aura DB.

What are the key takeaways? So we saw we analyzed and optimized the model using Karamba. We brought the data back in Revit. We used PyRevit and C# to send and generate the data in Neo4j Aura DB.

So I hope you have any questions, but I'm going to move to my third section. For the third section, we will talk about how we are creating this graph data, which we have stored in our Neo4jGraph DB, or how we can use the APS to directly query our model. We will also look at fine-tuning strategies using graph RAG chatbot pipeline.

So let's look at this slide. We saw this slide in the first section. The grayed out portion, which is in white, this is what we explored. Now this is the other part, which we will explore, which is how does APS understand Neo4j? How does it understand GraphQL?

The step one for achieving this process is we saw the compute and all of the portion [INAUDIBLE] then they query the data using Autodesk platform, serverless, full-stack application. And for that, we use two APIs, viewer model API for visualizing our model, and AC data model API. And then the GraphQL, which Autodesk offers.

This is a screenshot of the working application, which I am developing right now. It's a full stack application, where I have developed a small custom button called [INAUDIBLE] in one chatbot UI. When you click on it, you get a ChatGPT interface, where you can enter your data. And then you can get a result from it.

But I want to show how I was able to achieve this. What is the underlying thing? So this was my first experiment. I wrote a GraphQL query, which AC data model API offers. And then this is basically getting elements from-- with highest embodied carbon. And then the variables are your ID and your category. And this is the response, which I'm expecting.

So this is the experiment number two, where I'm not only identifying elements by category for highest embodied carbon, but also grouping them based on their subcategories, like foundation, structural columns, et cetera. You can see in the first two experiments, we always have to define queries, prompts, and the queries which relate to that.

I think this process is very limited. It's not sophisticated. We need a new method where the APS can remember and retain its knowledge. It doesn't have biases. It doesn't have ethical issues. Also, I have learned GraphQL queries can be complex. And you need a team to maintain this application. Also, if you are not updating your model on ACC and other databases, you might get hallucinations, which is one of the important problems of a large language model.

So how do we solve this? I want to solve this thing using a rack. We need a rack framework for knowledge, retention, and fine tuning our LLM response from APS, and then also combined with AP offerings by Autodesk. This is a screenshot from Meta's research blog, where the word Hemingway is being searched from different documents. They are converted into tokens using decoder-encoder logic. And then the user responds back the list of the documents, which it tries to find out.

So there is a question encoder and a doc encoder. And it returns what documents [INAUDIBLE]. A RAG is a process for optimizing the output of a large language models. So it references an authoritative knowledge base. And it has this exhaustive training.

And that's why I believe you're training APS to understand your docs on ACC is the key to prevent hallucinations. How do we achieve this RAG? I'm proposing-- I'm using Langchain as a framework. Why Langchain? Because it can connect to several large language models, like Ollama, Gemini, et cetera.

Also, the thing is they use the concept of chaining, which I found very interesting. The same way you must have information on chaining, we connect our ideas with different-- it's the same thing which knowledge graph was doing-- connecting ideas, right?

Langchain offers several chains. I'm not going to speak about all of them. I'm going to speak about only two, which is slang chain, simple chain, and sequential chain. Langchain simple chain is a straightforward LLM, which you can see an LLM and a prompt are tied together to a chain.

And the prompt is basically just a word. In my case, it's the first EPD product. And what I'm expecting is to return the first description. Now, this is the format I would like my BIM model or the trust to have the data connected. This is the underlying way how I'm using Langchain within my [INAUDIBLE]. This is a small screenshot of a simple chain.

Now, if I advance my EPD description to include the biocarbon values and embodied carbon, this can be in any EPD report. I can use something called a simple sequential chain, where the first prompt is about description about the product, which is tied to the truss.

And then the second prompt is basically about the values of the biocarbon. And the way sequential chain works, you can see I am asking the prompt. The prompt is, give me the description of the EPD product.

And then the description is fed to the second prompt in the chain, where I'm extracting, saying what are the values of embodied carbon and biocarbon? And the user will-- the large language model will respond as 12.56 kilo-- kgs CO2 per ton-- tonnage.

I want to conclude this section by saying-- by this very interesting graph. At some point in the future, we will accept that any system that learns a model of the world continuously remembers the state of the model, and recalls the remembered state will be conscious. I believe large language models are not there yet. But however, with new machine learning models, if we design them, if we have a machine learning system, which remembers the state of your BIM 360 model, there is a lot of potentials for using-- exploring APS and LLM extension.

So I hope you have any questions. But I'm going to move to the next slide, which is exploring potentials for beyond optimization. Here I would like to explain how this RAG can be integrated inside APS LLM extension for use cases which are not just structural optimization, but for the attendees' use case.

Before I begin, I got really inspired by this quote. "Learning is not just about acquiring knowledge, but about creating connections." It also ties with my previous quotes, which included. Connection is how we remember ideas as humans.

From the key takeaway from last section, we know that BIM data model is generated in Neo4j graph DB. And then we visualized our model about our embodied carbon data. But how we can add more meaningful information? How we can integrate that Langchain, which I just showed you inside a truss model?

So this is a diagrammatic explanation. To understand the different connections an LLM makes with your graph database or ACC, you need to understand how machines or algorithms understand a truss.

This is a truss. A human views it as a truss. And then how does a graph database view it, or a structural engineer view it? That's a graph DB view. But however, the transform architecture behind LLMs, understand the word Pratt truss as a vector embedding through user prompt. That's why we need to extend just the Pratt truss to something much more bigger.

In order to expand our vector search space, this we achieve using knowledge graphs. And the knowledge graph is where we connect our Pratt truss BIM model, not only to our data from our cloud or to a Revit model, but also the documents. So if I want to know when was this truss designed, who were the architects? What was the sustainability report at different stages? What is the scope of the work. Through a chatbot interface, I can easily get it without waiting for an engineer to email me the second day. Or if we are working in different time zones.

It can also get the geometry topology information, which is very interesting. But how do we achieve this in an LLM application, the RAG, the knowledge graph? This is how we are going to achieve it. The solution is a progression from vector embeddings with RAG to a GraphRAG. We connect our Neo4j graph with our vector embeddings to augment our workflow.

And there is an interesting project which I would recommend everyone is to look at Project GraphRAG by Microsoft Research, which I have mentioned that in our notes, about how they are using GraphRAG for understanding text data sets from diff-- and making network analyses, and prompting-- doing prompt engineering end-to-end systems.

I'm not going to speak about GraphRAG. It's available in the resources, in your handouts.

APS meets Graph-- This is what I propose. We know that graph has a semantic information of your BIM model. We also know APS has underlying GraphQL queries, and also have-- that's a perfect match made in heaven.

Both these technologies GraphRAG with Autodesk Platform Services, and using Langchain as a Neo4j as the underlying structure is what's going to be helpful. Please refer to the handouts for detail LLM RAG fine-tuning strategies for your equal business case in your handouts.

Let's dive into the terms. There's too many terms, right? APS, GraphRAG, Neo4j, Langchain. What exactly is-- how exactly we are going to achieve it? So there is something which I said about Autodesk Data Exchange Graph QL API, which is the AC Data Exchange API, which allows you to retrieve and access data from data exchanges on ACC for your Revit model.

We also know that we use Neo4j, which is a native graph open source database, which shows data in a graph structure. And it is a natural fit for GraphQL query, which can map directly to the data graph. That's a fundamental goal of Neo4j GraphQL library.

And we know GraphQL returns the data structure only requested. That's why GraphQL is the most interested technology, because you do not need a lot of information to be queried from your LLM prompt. You just need what the user prompts. And that's why it's a very low key data intensive application behind technology.

I want to introduce an advanced application, a Neo4j GraphRAG chatbot, which kind of connects to your ACC. And this is just a small user interface. Here, you can see I have prompted the engineer to say-- the client or the stakeholder to say, can you provide me all of the RFI documents which are related to the embodied carbon for this Revit project XYZ? And it gives all of the documents. This is what I imagine the chat interface would do.

And I want to use Langchain and Neo4j, along with AC Data Exchange API, GraphQL API to achieve this. This is currently a work in progress, a full stack application which is work in progress, which will be-- which I will explain in detail.

How does it work internally? We saw a user prompt previously, but how does GraphQL and Cypher [INAUDIBLE]? So here is one of the experiments. Can you provide the embodied carbon for all elements in project XYZ? And these are the RFI documents.

This prompt does an API call to a GraphQL query, which looks like that. And then there is a Cypher query, which runs, which basically calls the Neo4j graph DB, which generates another response, a GraphQL response, and then responded in a human understandable text response.

This is what I have built. It's still a work in progress. The nodes, you can see, LLM material nodes, the document nodes. And based on the date, you can also tie the dates.

So I think this-- I can want to connect this graph, overlay this graph with a [INAUDIBLE] BIM graph to create a rich knowledge graph information. And then I believe this workflow will not hallucinate.

So let's look at the key takeaways. The key takeaways till now, we saw the optimization in the first section. We saw a generated DB in second section. We saw the LLM extension there. And now we also saw how Neo4j and GraphRAG is being fine tuned.

With the hope for LLMs to aid, this is my final workflow chart, or a diagram, which I say, eventually, I want to integrate the Langchain GraphRAG within APS itself, like a full stack, single, running application, which connects to different API offerings. I just have used Viewer API and Data Exchange API, GraphQL API. But I also want to connect different API offerings from Autodesk right now.

Also, you also have Rhino.Inside Karamba workflow and PyRevit, which is being integrated. But I want to say something how I can expand this [INAUDIBLE] workflow is by having key integration technologies in future. The first is test and try out different API offerings, which I said, expand the knowledge graph, like chatbot with [INAUDIBLE] workflows, like Azure, Cognitive Search, Services, and Autogen.

Also, connect to computational design platforms and graphing technologies, like Topologicpy. These key developments are beyond the scope of today's presentation, but I am actively investigating these workflows and [INAUDIBLE] workflows with the GraphRAG for APS extension.

And before I end my presentation, I came across a very interesting quote from Yann LeCun, who is very skeptical about LLMs. He says that we should use them as writing aids, but do not plan on rea-- [INAUDIBLE] not plan on reason. He says that we should not be working on LLMs, but we should be working on the AI systems which power these LLMs. I believe that there is a truth in that, but I also believe that when LLMs understand the physics of a BIM model, or the physical world, or how architects and engineers interact, apart from the CC, or how we collaborate, that's when we have the true conscious LLM, which can power APS.

Thank you all for attending the industry talk. I appreciate everybody's patience and participation.