Prompt Engineering Simplified with Dan Cleary at AIE 2024

Hey everyone, how's it going? This is Dan Cleary here today. Um, we're talking about everything related to prompt engineering and hopefully make things a little bit more simple for you, answer some basic questions.

Really leave you walking out of this with actionable tips, templates, and takeaways that you could start working on. And so, again, a little bit about me. I'm Dan, I'm the co-founder of Prompt Hub.

Prompt Hub is a platform to test version collaborate on prompts with your team. I'm a big time runner, um, and a huge Knicks fan, which I'm recording this before the game six tonight, so hopefully by the time this airs, the Knicks are in the Eastern Conference finals. And so a little bit about what we'll go over today.

Uh, first of we'll just talk about why prompt engineering, a little bit of the nuts and bolts of tokens and the different parameters that you can use when working with prompts. We'll talk about the different types of prompt messages including a system message versus just a normal prompt. We'll talk a little bit about the model landscape, the fact that different models requires different types of tech techniques.

We'll go over the most effective problem engineering methods that we've seen over the past, you know, year and a half general best practices regardless of any models that you're using. And then again, of course we'll be providing a bunch of free templates and actual takeaways that you can actually get started with today. And so a big question of is, you know, why prompt engineering don't you just write what you want the model to do and then it it goes and does it.

Um, and I think this is a naive statement 'cause anyone who has actually tried to get an LM to do exactly what you want it to do, well, no, that you can't just give it a five letter instruction or a five word instruction and get what you want. Um, it isn't just sending, you know, proper English grammar. It requires more nuance to that.

And that's because of something called the latent space of a model. The latent space is basically what you could think of as like the, the LMS brain. It's where it goes to search to get an answer for you.

It takes your input goes into the latent space that gets an output that thinks it's related to it. So topics will be grouped similarly in the same way that these cats are near each other. These dogs are near each other because they are both related to each other.

And so for that reason, little changes can send the model to different parts in the latent space, which might give you a better answer or a worse answer, which is why little changes make such a big difference. And so if we have a prompt that just says write code to render this image, we'll get something back. Probably be pretty typical, pretty just classic.

If we say write secure code to render this image, we'll probably get something, we'll probably get better code, we'll probably be more secure because it'll be pushing the model to a different part of that latent space that is more familiar with secure code. And if we go even further and say, write secure code as if you were John Carmack was one of the best graphics, uh, programmers ever, you'll probably even get something better back. And so again, and this is just a showing how these little changes will push it to different pieces.

Uh, push the model to different places in the latent space to get you a response. And that's why prompt engineering can be so fickle and could seem so, um, challenging at times. And so again, in terms of the question of why prompt engineering, can we just do like retrieval augmented generation or fine tuning?

Again, we think those are other really good methods to maximize the performance of LLMs. We just think prompt engineering is the best place to start. It's the quickest to get up and running.

Anyone can kind of do it. Um, you can start experimenting quickly, prototyping quickly, and then you could see kind of where you're falling short. If prompt engineering isn't getting you all the way to the outputs that you want, you know, if it's a context thing you might wanna have rag to be able to give the models more context.

If it's an output quality or consistency thing, then it might be fine tuning. But regardless, nonetheless, this is a very never really a linear journey. It's very iterative and it's very, uh, complex and that's why prompt engineering is a good place to start.

And then on top of that, to answer this question of why prompt engineering, unless the architecture of LMS change drastically, um, you know, you to get an output from an LLM, you will always have to send a prompt. You can almost think about everything supporting the prompt, right? Everything else around the pipeline, the architecture, you know, the UI of what you're building is really there to support the prompt and the output you're getting from the LLM.

That's really the special sauce here. And for businesses, prompt engineering can be a competitive advantage in the same way that having really good software engineers are really good coders can be a competitive advantage. The better outputs you can get, the better present, uh, presentation that you can give of these outputs to your users, the better chance that your product can do better.

And so it can be a competitive advantage, especially when users today are so attuned to things that sound like AI or feel like AI being able to have really great prompts can be a really big competitive advantage for you, your company, whatever product you are building. So we'll quickly touch on some nuts, bolts of LMS will be very brief here. Um, but it does relate to important fundamentals.

So when we send texts to an LLM, it's not reading it as English, it breaks it down into what are called tokens. Tokens can be a single word as we see with the word trees here. It could be split as we see with evergreen.

It could be a single um, character as we can see with the comma. Um, it's could be any of those and it's really not, um, distinct. So that's why if you've ever tried to have an LOM return a certain amount of words, it's actually quite bad at it.

'cause it doesn't, it doesn't read words. It reads tokens, changes those to those tokens to numbers. And that helps it better understand it when it's going through that latent space calculation.

And so this will come back in a moment here as we touch on some of the parameters. There's five, there's more than five parameters. These are, these are the most important ones, um, in our eyes, what we see from our, our users and our customers.

Temperature max tokens, um, top B frequency penalty, presence, penalty and stop sequences. And today we'll focus mostly on temperature just 'cause it is the most common and it's, you know, usually defined as how creative you want the model to be. So in high temperature situations, it'll be more creative and low, it'll be less creative.

And so what that actually means, going back to the that token, the tokens we were talking about before, when a model is outputting text, it's doing just a probabilistic search for the next most likely token. And so in a low temperature environment, you're most likely to get just the most likely token. Next, this distribution of the percentages isn't very flat.

Um, it'll just give you the most likely token to come next. If you, the higher you increase the temperature, the more it flattens that out. As you can see it reduced the percentage chance of the word in being next by over, you know, 8% here or something along those lines.

And so you're more likely to get things that are just a little bit more creative, a little less, um, like stale I would say. And we could do a quick comparison of this. And so this is just a prompt and prompt up I here and the prompter just says, says, tell me I factor out skydiving and I've set this up to run three times with the bearing levels of temperature.

So a low temperature medium and a higher one. So we'll run that. All right, there we go.

And so we can see on the low end gives a pretty straightforward fact. This was the first jump, it was by this person. If it was this much in the medium one we we already see, instead of just one fact, it says one interesting fact.

So it's injecting something a little bit different there. Um, he descended safely. That sounded a little bit different, you know, like this, you wouldn't normally see that and you don't see that in here, right?

It just says he went safely to the bottom using this type of parachute. So you're seeing these kind of keyword differences. And then on the very high end, you start to get a bunch of gibberish and like random characters.

'cause again, it flattens that prob probabilistic distribution. In this case we're getting, you know, stuff that normally wouldn't have any chance of appearing is getting a higher chance. And so, you know, you run the those probabilities enough, you're gonna get some weird stuff.

So that's a little bit about temperature and how that relates to um, the outputs that you get. So now we'll talk about the two, the two major roles. Um, when sending a prompt, there's the system message and then um, you know, just a typical user message.

The system message is what essentially like sets the context. It's optional, you don't have to send it. Um, but if you've ever used like chat GBT or any chat bot, there's almost always a system message behind it that kind of sets the scene.

It tells the chat chat bot how to act. It tells it, you know, do these types of things, pretend to be this type of, you know, persona. Um, here are the rules to follow.

It kind of just sets the, the stage for the rest of the conversation. It can be very powerful in guiding the model too. It's very good for like high level as kind of overview type stuff.

So like setting the role context, rules, instructions, general behavior patterns, um, that's where the system messages really can shine versus the actual prompt. That's where you wanna have the specific question, any of the contextual info. Um, it just really on a much like kind of lower, more granular level essentially.

And that's kind of how you can kind of think about the difference between the two. And so a question we get a lot is around, hey, which model should I use? There's so many models, there's a lot of different providers.

Some of them are open source, some of them are closed sourced and it's a moving target, right? 0 being launched and we might get a new model from and we get a new model from jam from Google the next day. And then this stuff kind of just keeps coming.

So it is a moving target. And so if you, you have any models that you like, um, that you use, feel free to drop them in the, in the chat here. Um, but to just talk about a little bit, some general rules is that first of all, it really comes down to your use case.

Um, so any budget constraints will, will make a play latency matters. Um, so being able to test this stuff is really important. Um, some things that we have found from the various esta we've run is that if you are using OpenAI models in production, you know, we always tell teams to test test them by toasting 'em on Azure 'cause you'll probably just get a faster um, result and reduce our reduction in in latency.

Something that we've commonly seen also is that we've heard that people really like philanthropics models for any kind of creative writing type of function. Um, you know, we haven't used GPT-4 oh a lot for that. That's generally what we've seen as well.

And the rest of it really comes down to testing what you're doing, the type of task. Um, and it really comes down to the context of which you are using the prompts in your applications. So on the note of testing these different models, something that is important to know and we're actually seeing a lot now that GBT four oh has come out is that different models require different prompts and prompt strategies.

So for example, chain of thought is a very common um, rule of prompt engineering where you basically tell the model to, you know, think step by step. You're kind of prompting it to do some more reasoning than it might do out of the box. But in the PO two technical report, they basically found that adding this type of reasoning led to a degradation in performance.

And so what was basically seen as the most, you know, undisputed and like good prompt engineering technique was actually not true for what is a pretty large model, which just points to the fact that each model is very different and everything needs to kinda be tailored and tested for those specific models. There are a lot of overlapping best practices, but something some specific can make a huge difference. And so there was this great paper out of VMware relatively recently where essentially they tested a bunch of different positive thinking type messages or, you know, um, directives in their prompts.

So they would have a, a normal prompt and then they would add on either an opener or a closer or a task description, um, in a various combos of these. So they tested all of these out. Sometimes they would say you're as smart as chat GBT.

Sometimes they would say you're an expert at math. Then it would give it a math equation and then it would close with some kind of text as well. So this was to see, you know, they tested these across a couple different models.

There was like misra model, a LAMA model. And so it's basically trying to test, hey, did any of these like particularly work well for the different models and how did that perform? And so for example, here's how those kind of look listed out, um, with the various options and they were able to essentially see some differences in the performance, um, when putting those together.

But the more interesting part of the paper came when they let the models create the prompts themselves. So they let the models say, Hey, write a prompt to do to do this following math problem. And for LAMA two, this was the prompt that the model made.

As you can see, it's kind of got this like Star Trek theme, right? It's like command, we're going through this turbulence, locate this, use your data captain's log star date. So this was completely generated by the model as the best performing prompt to solve this specific tax, which is extremely surprising, right?

Like a human would never think to write of a prompt like this thinking that it would get them the best output. And I think even more interestingly is how different that prompt was from even just the best prompt for the LAMA 13 B model. Um, this one's just pretty straightforward.

It basically just tells it, you know, gives it some kind of words of advice, you know, you've got it. Um, and then go step by step, yada yada, yada. And here's one more for the other 13 B model as well.

And it is just very straightforward and it's very different from that first one we saw where it was the kind of Star Trek style type of prompt. And so again, it just illustrates that you really need to test these things and that it's hard to know where in the latent space you want to go or where you will get the best output. And again, coming back to that idea here that different models require different types of instructions.

This is a another interesting paper that came out in the last year that made, got very kind of popular. Um, specifically this, you know, take a deep breath and work on this problem step by step. Um, this type of chain of thought thinking was a very, I would say common practice but important thing that most people miss was that this was for um, a specific type of palm two L model versus if you look at the top instruction that these researchers test for GBT four, it's much longer, right?

This is many sentences long versus just a single sentence. In other cases just a single like you have three words. And so every model can be very different, have it own it, its own intricacies when it comes to prompt engineering.

And so now we'll look at a couple of different methods to add to kind of your testing toolkit. And again, before diving into that one kind of number one rule of prompt engineering is to not overly con the model You wanna give room to think. You don't want it to make it too constrictive.

So in this example, rather than saying what's the best programming language for web development, you wanna, you know, of course that is a very like nuanced question. There's a lot of things you could build on the web, there's a lot of different languages could help you. Um, you'd wanna be able to basically give the model room to think saying Hey, tell me the pros and the cons for this specific situation when I'm building X on the web.

And so to set the context a little bit as we start to talk about some of these prompt engineering methods, a zero shot prompt if you hear that thrown around is basically just a straightforward prompt. Um, so special about it, you're just asking it. Then there are few shot prompts, which is where you basically send a few examples in the prompt itself or as different messages.

So in this one I'm sent, this is all a single prompt here I'm saying hey, this is awesome positive, this is bad negative. So we're classifying the sentiment of those, those pieces of text. And then I leave this last spot basically open kinda like a parking space where the model will then fill in the answer.

And so with this, I'm training the model on what I deem as positive or negative and also showing the model what I want as an output, right? We want a single word, we want it to be capitalized first letter. And so you can send that all in one prompt.

Or if you have access to a tool like prompt up other tools where you can mock many messages together, you can separate it by user, user and assistant message. So here we have a system prompt, we're sending a user prompt, we're mocking up this AI response by hard coding, this assistant response and then we're leaving it with a user prompt. So then the assistant would then reply here and the assistant is just the a i.

And so we think shoe shop prompting is arguably the best prompt engineering method that we've ever looked at. It's very straightforward, it's stood the test of time. Um, and it leverages the model's ability to learn in context and learn quickly about your use case.

And so use cases where it's helpful, specialized or technical domains, um, can be really helpful where you don't have enough data to fine tune. Um, maybe you just have one or two solid examples that can be really helpful. Content creation, it's really helpful to give the model an example or two of some piece of content that you like that you wanna mimic so it can get a better understanding of the structure or tone and style.

It's very good at picking that up. And this will help you make sure that your prompts and outputs, you know, don't produce stuff that sounds like ai. If you have strict output structure, whether that could be JSON bulleted list, um, you know, various paragraphs.

Again, the examples are really helpful for that and the customized user experiences. And so this would be an example of if you shot prompt for content creation where I'm basically saying, Hey, make content for our client. Here's some info on the client.

Here are a few examples of stuff that we've done in the past for that client where we have a brief and then the content created from that brief. Another brief content created from that brief. So these would be examples of piece of content that worked well in some capacity for that client.

And so the model is learning more and more about the context that we're working in. Then I sent the brief description that we're working on now and I leave the content open so then they can fill in that with um, the next piece of content we need to create in terms of how many examples do you need to include? The short answer that we tell teams is try to get at least two in there.

Um, and you, once you get beyond that, it's kind of plateaus out as you can see from this example here. Um, and then also you could see in some cases it actually begins to degrade performance a little bit. So I'd say anywhere from two to five is helpful and you want those examples to be as diverse as possible and you don't want to send like very similar examples 'cause the model might overfit and think, oh, I should just produce something that looks exactly like this.

You want a wide range of examples in terms of the ordering. It's something worth testing. Um, there has been re research to show that it can have a material impact as we see kind of from this chart here, showing that basically the different permutations of the ordering can have, you know, wide effects from what is like a what 60% accuracy all the way up to an average of almost 90.

This was for a dumber, you know, dumber model. This was for GBT three. Um, and so as the models get smarter, I think the example order will matter less, but it's again, something worth testing and thinking about.

And we have a whole guide on this for freeing on our site if you want to kind of dive a little bit more deeper there. Next up, um, according to prompting, again, this I think is a very powerful and easy method to incorporate. And it basically, again, is just pushing the model to a certain part in that latent space in its brain that you want to get to pull the answer from.

So in this case, the user is saying, Hey, what part of the digestive tube do you expect the initial digestion of star? It gives some answers, but then you just add according to Wikipedia and it gives a much more in-depth answer where it's going to that, to that Wikipedia part of its brain and pulling it out. So if you know where the info is, if you fine tune the model on your certain data or files or if you know that you wanna pull from, you know, a trusted source type Wikipedia, adding this, just couple of words that that end of your prompt can be really helpful in accomplishing that.

And this would be a pretty straightforward way to actually write out the full prompt. Next up is emotion prompt. That was a paper that came out last year, but basically adding a little bit of an emotional stimuli onto the end of your prompt can help increase the output.

So as we see here from the original prompt to the new one that they just added, this is very important to my career. And you know, you're looking at like anywhere from like a 10% to a 20% bump in performance, which is pretty crazy. Um, but it makes sense, right?

The these models are trained on data from the internet. A lot of that is a reflection. You know, a lot of the stuff on the internet of course was created by humans.

It's a reflection of ourselves. So these models will act like us. And so if your boss tells you that hey, this project's really important, you'll probably take that a little bit more, more seriously and the models kind of act the same way and again, super easy to put into place and to try out.

Um, so we recommend testing that. One next step is step back prompting. Um, and so this goes back to the idea of giving the model room to think broadly.

So you break it out into steps basically. Hey, here's the question or task first before even jumping into solving it. Think about the key concepts and principles.

So think kind of broadly and widely and then use that information to reason through the question. And so this is great for logical, um, or complex like coding related tasks. Anything where you're dealing with stuff that has like key abstractions or principles that could be applied to help guide the model.

And again, these are all available for free, um, in the prompt up templates template section. So if you go to, um, prompt up us and log in, um, you can use this code to get in if you don't have access already and you can copy and paste 'em, add 'em to your library, test 'em out, um, all free of use and we will wrap up with just a couple other, you know, very quick best practices. So delimiters and structuring your prompts can be really helpful.

Um, so in this case we just wrap the text in, you know, three Bs. Um, this helps structure the prompt such that the model can better understand where the different pieces of the prompt are. And we have a couple of examples of seeing this kind of either markdown or some type of delimiters used, um, in some of the AppSec that we use today.

So in the chat GBT system message, they use a lot of markdown, um, to del eliminate the different parts of the prompt. And we wrote about that, um, on our blog as well from both the for OpenAI perplexity and a couple other, uh, major AI players to be able to see, hey, what are the, the best people in the space doing? What do their prompts look like and what can we learn from it?

And so, you know, to wrap up here, four things you can kind of get started today. If you wanted to learn more about prompt engineering or take what you're currently doing to the next level, um, is, you know, using those ERs and headers in kind of markdown format as we talked about more, being more specific in your instructions, will will always help using examples, few shop prompting or some of the other, um, prompt engineering methods we looked at today are certainly worth testing out. And don't overly constrain the model, give it room to think and reason in the same way that you would a like senior, you know, engineer on your team.

And that is it from here. Thanks for spending the time today. If you have any questions, feel free to drop 'em in the chat.