The Art of Prompting AI: Inventor Rules

JOEL MAIA: Hello, everyone. Welcome to the art of prompting AI with focus on inventory rules. My name is Joel Maia. I'm a technical designer from Portugal. I have been working with Inventor for over 10 years now. Inventory is an amazing software for mechanical designing, and one of its biggest strengths is capability for automation. Now, not only through its built-in features, but also for the endless possibilities that it offers with the Inventor API.

To take full advantage of the Inventor API, we normally should some programming language like C sharp, our visual basic, and have a good understanding of the API itself. However, acquiring this knowledge can be time-consuming process, which can be an entry barrier for some users. And with the introduction of generative AI tools, this barrier has been lowered by allowing users to immediately tackle real-world problems, learn along the way, avoiding the typical learning path.

In this class, we will learn the framework that provides companies and individuals a structural approach for finding automating ideas and solutions. And we will also explore the basics of generative AI and learn about prompting components and techniques to enhance communication which will lead to better and more effective outcomes. Additionally, we will see a real-world example where these techniques are applied.

We will not cover, in this talk, how to work with effective rules and logic. And also, we will not discuss or learn how a programming language work and how to work with it. We are focusing on no-code approach. If you are interested in, learn a little bit more about this. I gathered these great talks, previous classes at AU, which can take you from the basic level to a more advanced. Even if you want to create your own [? add-in, ?] there's some great talks about it.

Yeah. So let's start with a framework for automation. Have a number of users who can develop contribution to contribute for automation solutions increase is a crucial, both for companies and individuals, to adopt a structured approach to the problems. In this chapter, we're going to introduce an adaptation of the [? design ?] [? council ?] double-diamond designing methodologies. This is a framework that encourages a systematic approach to problem-solving, innovation, and automation.

So this is the double-diamond process. This process starts with a challenge, which usually is a question like, how we get more efficient? What are the problems on our workflow? How we decrease the execution time? After that, we start-- we have the diamonds, which represent two phases. When we first diverge and explore, and the second phase is when we converge in a definition or a solution.

In the first diamond, we focus in discovery and define. And second diamond, we will focus in develop and delivery. And hopefully, in the end, reach the outcome. Now, let's take a look at these four phases. We start by discovery phase. Discovery phase is a divergent phase where we explore problems. We focus in gather insights, in exploring the problems in our organization or in our workflow, or the way we work.

We have some methods that can help us to explore better these problems, like workshops, brainstorms, brainstorm sessions, personal interviews, or even reflecting our own workflow in our professional experience. And it's also important, after finding some problems, try to gather some data points about it, like duration and occurrence.

The objective in the end of this phase is to get a set of problems that you think is worth exploring and analyze closer. Then we have defined phase where we converge. We're going to take the data that we gathered in the first phase and try to converge in a single problem definition that we want to tackle. Some methods to help us to reach out this very useful is process break down, identify decision, decision points, create, process flowcharts. This is a particularly important, the process flowcharts, because creating a visual representation of tracks of the task structure allows you to have an in-depth knowledge of the task itself.

And after gathering all these elements, we can make an informed argumentation about the process and why it's worth exploring this problem. And we will, hopefully in the end, we're going to converge to a single point to a single problem that makes sense for us to tackle. After this, let's go to the develop. Develop phase is once more divergent phase when we mostly focus on solution conceptualization.

The methods uses define objectives, create solution pathways, quantify resources, information steps, set timelines, action plans. And then finally, we start prototyping. As you can see, we are diverging. We are creating a lot of elements that is going to help us to reach an outcome in the next stage. After this phase, we should have a clear path to a solution, should be clear how we're going to solve the problem.

And finally, in deliver phase is the conversion phase. Is the phase that's going to take us to outcome and where are we going to reach a solution implementation. It should be straightforward. If you do all the previous phase correctly, this is where we're going to make our solution production, concept testing, user testing, and launch. I also would like to say that these steps and the methods that I've mentioned so far, it should be adapted to your industry. You should not just stay by the ones I mentioned here. Each industry might require a slight adaptation, and you should keep an open mind towards it.

Now, let's talk about AI and the prompting components. Generally, we are refers to the type of artificial intelligence technology capable of generating content. It can be text, code, image, music, yeah. And it's called generative. AI learns from vast data sets and tries to mimic. This capability is not just about replicating what is learning or what it is in data set, but it's trying to generate new data in the creative way and with complex patterns.

In the left side, I mentioned some generative AI models most used by people. And if you never try it, I encourage you to a couple of these and try it and explore it. It will be fun, I'm sure. Now, let's go to the main subject of this class, that's prompting. Prompting is the way you communicate with the generative model. You can prompt with text, you can use image, you can use video, you can combine them. It's just a way that you write for a possible answer for your problem or for what you try to reach.

Today, we are going to look at six components of a prompt. It is important to keep these components in mind when writing a prompt. This will enable us to have a start with both [? stuies, ?] which is crucial. Crucial because it heavily impacts the quality of the output. Now, let's look at one-at-a-time of these components. We're going to start by directive. Directive is basically the task that you want the AI to make.

We can make a single directive prompt, which is where we just ask to write something, we can have more than one directive in the prompt. In this example, we have analyze, summarize, and write. And finally, we can also-- a directive cannot be direct, cannot be explicit in the prompt. It can be implicit. For example, we are having, the bottom here, is an example of a translation, where we don't have to explain to the model where it has to go. It comes from the example provided first. It can understand the directive.

Next, we have context. Context is very important to constrain the endless possibilities. Remember that AI is training a lot of data. And if you want a specific solution, you should constrain all the infinite possible answers. And this is really important. For example, in these two bottom prompts, we have an example of a male that wants to gain five kilograms of muscle mass and another that wants to lose five kilograms of fat.

And as you can imagine, the suggested training program is going to be very different for each case. So this is a good example of how context is very important. Then we have the examples. Examples serve to demonstrate to gen AI what you want to accomplish. We have here an example of a job description that, we want to create a new job description. But we already found a description that we really like and we enjoy how it's written. So we give it as an example. And you ask it to adapt to our case.

We also can use it in context learning. This means that you can teach AI a new logic, a new way of thinking, by the examples that you provide. We're going to talk a lot more about examples in the prompting techniques chapter because many of these based are based from examples. Then there is a role.

Role has a strong impact in the quality of your output. A good way of thinking when starting writing this component is to ask yourself what you want the AI to be. In this example, in this slide, we have an architectural historian and historical engineer. As we can imagine, they all have very different opinions of a building. So the approach and the analysis is going to be very different towards those two characters.

Then I have tone. Yeah, so tone is used by the output. It's stylistic, rather than structurally. And having a good vocabulary is essential to express correctly. Then we have format. Format is basically how we want our output, email, letter, code block, text, you name it. You should have a format ideal for your case use.

Then we are going to prompting techniques and strategies. Prompting is an art. You will likely need to try a few different approaches. This is from the Google Guide, Prompting 101.

And I find these expressions so true because, when we try to solve a more complex problem or write a complex text, you're going to need to try several prompts and approach the idea from different ways to get exactly what you want, to get the answer completely tailored to what you intend to express or demonstrate.

Here are some prompting techniques and strategies. We're going to discuss these five basic prompting techniques. There are more. There are hundreds of techniques. But they are mostly derivatives from these five. And I want you to keep in mind that these tactics are meant to provide ideas, things to try. They are not fully comprehensive. And you should feel free to try creative ideas and mix them together and try things, new things.

So we start with zero-shot prompting technique. Zero-shot prompting technique involves asking a direct question to the large language model without providing any examples. We might use the components that we learned. But we're not going to show an example of exactly what we want. It is just like, we hope that the AI model will give us a little bit about what we are talking about.

Then we have few shot prompting, where we focus to give the large language model LLM examples and try to teach a logic on how to answer. We can see, in this example, when we are trying to classify a phrase as positive and negative, the large language model will analyze your previous question and answer and, in the end, will try to reply accordingly with a sentiment, accordingly.

Then we have chain of thought. Chain of thought, it's focused on making the large language model to rethink step by step. Large language models have some difficulty in resolving some logic problems. For example, it's really hard for them to count letters, the number of letters in a word, or sometimes resolve some equations. And if we show how we solve the problem step by step, it can be a similar problem, and show it how it was solved step by step, we are going to have a much bigger [INAUDIBLE] in our output.

Now, we have decomposition. Decomposing involves taking a task and decomposing it in several smaller tasks, and then tackle each chapter at a time. It's basically a way to break down problems and then tackle these problems individually, the basic divide and conquer. Here's an example. In here, we want to write a comprehensive article about cooking eggs.

So we have a list of topics that we should include in this article. And then we start to tackle each topic, one by one. Now, this is the last technique. This is ensembling. Ensembling is a process of using multiple prompts to solve the same problem. This is particularly useful because we can ask the model to see the problem from different perspectives, and then gather all those perspectives in the single reply. That will reduce hallucinations, make the model think, and can be a great way to write text and to get great text, our model.

In this chapter, we have some tips and tricks. Remember to keep it simple. Usually, the most simple approach is the one you should try first. Try a different approach. Mix them together. Break it up. Don't try to solve everything at once. Take it step by step. That's very good advice. Give constraints. Yeah, you need to limit. Technically, AI knows everything. You need to constrain what exactly, what you want. Be a little bit specific about what you want as a result and an answer.

A final rule, don't forget, that is very important, ask for feedback. Sometimes, when you get an answer, just be prompting the model by asking, OK, can you think about this again? It's a good way to approach. And it can improve or give you alternative, different answers. And consider tone. Don't forget about that. Sometimes, it's overlooked. But it's very, very important.

So, now, let's go to practical application using Inventor rules. Here's a little bit of context. I work in an aquaculture company. And this was a process that we went through to find out new automation and innovation ideas. We started to find out a problem and a challenge to tackle. This challenge was identified mostly by talks and brainstorming sessions with our colleagues to find out where they spend most of their time. And also, what are their pain points? What are the most tedious tasks?

We reached out to the following set of problems, a, pipe placing is too much time-consuming. The pipe pressure quality checks are tedious and lengthy. And c, excessive time spent on designing custom pump brackets. And we gathered some data. We take some measurements of how much time per task it takes, weekly occurrence. How many times does these tasks happen per week? And also, the user pain level, this is an extremely important point to have.

From this, we can jump to the define stage, when we take the data already gathered and we make a logic out of it. We try to make an argumentation. So the problem A, problem A, the pipe placing, occurs 100 times per week. But it has a minimal impact. Impact is just one minute per task-- and a low level of pain for A. So it's something that, it is in the flow. It's a task that happens fast and doesn't bother that much, the user.

The problem B, pipe pressure quality checks, are less frequent, only two times per week, but are highly time-consuming. About 60 minutes, one hour, that it takes, this task. This indicates that it's a big inefficiency and frustration, making it a high priority issue. C is the custom pump brackets-- are time-consuming, 10 minutes per task, and occurs with some regularity. But it has a minimal pain level. It's a 4 out of 10. It's a modeling task. Usually, technical designers like to model. So they don't mind that much.

This issue, it seems to present a good opportunity for improvement but is not as critical as problem B. We can take, from this analysis, that problem B is probably going to be the problem to tackle. We further, since we see that problem B is probably the best problem to tackle, we take further action. And we decompose it in a task breakdown structure.

And upon further review of the task, we found that comparing design standards can be omitted, as designers [INAUDIBLE] and don't frequently look at it. And the primary challenge in identifying this workflow is the repetitive back and forth between the 3D model and the [? ID. ?] Since the pipe pressure is a property listed in the BOM, it's difficult to maintain a sequential view of the pipe pressures.

Also, when checking the pressure for one pipe, it becomes unclear what the pressure class for the subsequent pipe is. And working with these three elements simultaneously is cumbersome, especially since most of our designers are limited to one dual screen setup. And we need to have three elements open.

Taking this, we have a well-defined problem. So, now, let's develop a solution. Let's think about the solution. We can start by setting objectives. In this case, we set the objective that, you want to reduce the time for at least 50%. This means that the task right now takes 60 minutes now. But we want to shorten it for half an hour and reduce the pain level for a score of 4 or below.

We'll create a solution pathway. After some brainstorming, we find out that the best solution is to display the pipe pressure directly in the 3D model via color grading. And we focus on the SDR 26, 17, and 11. These are pressure classes. And it should be implemented to an inventory rule because we already use it in our workflow, some inventory rules, and is in inside inventory. So we don't need to acquire new software.

We further envision the solution. So we envision that this inventory rule will create a new [INAUDIBLE] representation [INAUDIBLE] representation. This is to-- don't make changes to representation that can be used. It might affect some drawings, for example. Then we need this rule to read the property name class for each part being assembled. And then, assign a color to that part according to the class.

And in the bottom, we have the rules that we want. We want the SDR to be green, SDR26, green, SDR17, yellow, SDR11, red. And other classes, we're going to just leave them gray. We quantify resources. In this case, we don't need that much extra resources because we're only going to use Inventor. And the large language models that we're going to use are available for free.

And this is a solution that just one individual can take forward and will not have major impact on our workflow. We define some implementation steps, too. Then we set timelines. Yeah, this is important to do. We set something between two and four weeks. The time frame includes rule development, testing, feedback, incorporation, and final deployment. And then we have the action plan, how we're going to really tackle, what are our next actions?

And then, we start prototyping. This is how it looks, our first prototype. This doesn't have any render rules. We just manually give a different material to each pipe. And this is how we envision our rule to do. We envision our rule. We can see it in the left side of the browser, in the folder representations, that it was created. And your visual representation called [INAUDIBLE] is activated. And the pipes are classified by SDR11, SDR17, and SDR26, with its respective colors.

And this is what we intended. So at this stage, we have a solution pathway well-defined. And we are ready to start the delivery phase, to develop the solution. We're going to use vendor rules. This is just a quick note. This is the vendor rules [? IDE. ?] This is where we're going to pay for our code. And this is how we envision our solution, at the right side.

So let's start by the most laziest solution possible. We're going to copy. I simply copy the handout, the definition of the DevOps stage for this project. And if we define it correctly, we must be able to get some sort of result. AI must be able to understand what we aim to achieve and get some base points from this.

And this is the code. We are not going to look at code in this talk. But we can see, when we run the rule, when we're going to paste the code given by the assistant in the Inventor [? IDE. ?] And we're going to get an error, but not just the error. We're going to see that the AI was able to make some tasks correctly. We were able to create a new representation.

We are able to activate the view representation. But then, the Inventor says that we have an error on line 23. That is this line, marked by the first red rectangle. And by the comments, we can interpret that this role stopped when was reading custom property class. If we see, the AI made a comment, iterated through all occurrences in assembly, which pretty much corresponds to our third point. So we know that this application, this rule, starts running here.

Our first approach when we have an error like this, it should be the prompt [INAUDIBLE] with the error. The code has some error. Fix it. And we just copy and paste the error to it. This approach is successful many times. And this time, we were not able. I think this is one of the cases that, the prompt, we were expecting the model to do too much. We should've broken down the tasks. But it was a good starting point. And we [INAUDIBLE] retained these first two parts of code because they are good. And they work. So let's just tackle the points 3 and 4 in the following prompts. So let's tackle the problem number three.

We have this prompt. When we are designing networks with Autodesk Inventor, this is our role. And then we have the directive, create Autodesk Inventor with text for each part in the assembly with the custom property, "Class," and show a text message with a value. So, here, we are adding a text message so we have a visual confirmation that the rule is really reading the property that we want.

And also, we reply only with the call based on an event, or this is [? a format. ?] If we don't put this line, we're going to get a lot of explanations, how the code is working, which might be good if you are a beginner. But if you are just trying to streamline the process and copy/paste, you can write this. You'll get faster and smaller answers.

And it doesn't work. We try to run it. It doesn't work. So what do we do? We prompt it with [INAUDIBLE]. And voila. We were lucky this time. And the code ran. And we got a text message with the pipe class for each one of the pipes.

If you are wondering, these kind of errors, it happens, because, right now, the AI language model doesn't have a way to run the code in the vendor and process it if it has errors. So we have to manually debug the code for the large language model. I believe this will be solved in the future. But for now, this is the best process that we have.

So we have the class. And, now, let's try to solve the fourth problem. So we're going to pick up in the prompt that we used for the first problem. And we're going to add our logic. And, fortunately, we might be able to get the working code. But unfortunately, we were not successful with this approach. It seems that this task of getting the material appearance and attributes to the part is a little bit too much complicated for the AI.

It seems that its knowledge is not based in-- it doesn't have the right code on it. So we're going to have another approach. And we're going to try to find an online solution for the problem four, to give as an example to the AI model.

Some good places to search for answers is the Autodesk Inventor Programming forum, the Autodesk Inventor API Help, and Autodesk dev blog, like bug machines, [INAUDIBLE] bugs. And, also, try to Google search. There is others sites like GitHub that have a lot of Inventor code, Inventor [? IDE ?] codes that might be useful for you.

So we were lucky. We found an Autodesk user that was asking the same question that we are in problem four, how to attribute the previous material to a part. And some user gave this answer. And the user that made the question marked that it has a good solution. And that's a good indicative that this is a code that works.

So what we're going to do, we're going to copy the code of this solution and join into a single [? plant. ?] As you can see, in the bottom, we have the code. Use the following code to set the material to the part. And, yeah, we have the right solution. But if we try to plant with an error, we're going to get a good code. And we have these color grading pipes that's exactly what we want from the model.

After that, if you notice, we have all our four items solved, so the first prompt into this last one. So we're just going to merge them in a prompt. We're just going to ask the large language model to merge everything into a single prompt. Merge this event URL with this one. And we get this. We are lucky at the first time. And it went perfectly. It created the [? pressure, ?] the [? pressure ?] view.

It calibrated the pipes. And, yeah, it made everything that we want. After this is the final. So we were successful. We were [INAUDIBLE]. Application [INAUDIBLE] that works. Now, the further steps would be testing correct documentation for the user manuals, for example. Deploy, we probably would deploy to our external folder, rules folder, that all the designers have access. Then gather feedback and make the adjustments as necessary.

I would like to notice that this code is not perfect. But it demonstrates how, with just a few prompts and without knowing anything about code, we can immediately have-- in a very fast way, we can have a code that works and solves the problem that we're having. And as a final demonstration, I'm going to show our rule in action.

This is our facility, our [INAUDIBLE] aquaculture facility. As you can see, it has, I would say, hundreds of pipes. And you can understand now how it could be hard to quality check them. We're going to hide concrete to have a more easy view of the pipes. We're going to run our rule. And we can see, it's running. It takes a little bit because there are so many pipes.

And as you can see, it's slightly changed [INAUDIBLE] pipe. And we successfully color-graded all the pipes in our assembly. And this is now in production, in use, in our workflow. And we reached the objectives. We got about 80% reduction time in the task. And the pain level is reduced from an 8 for around 3. So it was a success. Thank you. Thank you, everyone, for coming and for the time.