Prompting Reasoning Models
This lesson preview is part of the The Basics of Prompt Engineering course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to The Basics of Prompt Engineering, plus 80+ \newline books, guides and courses with the \newline Pro subscription.

[00:00 - 00:08] Okay, we're gonna talk a little bit about reasoning models now. The main difference which we've already discussed is that it's more of a step-by-step process, right?
[00:09 - 00:20] So in this case, actually the way you format your prompts can be a little bit more important, I think. And again, I'm gonna use a list of things and I don't need a prompt for reasoning model.
[00:21 - 00:29] But again, this isn't thatactic, right? You can absolutely split them up different way or find competing lists of what makes a good prompt for reasoning model.
[00:30 - 00:45] But the point is that with a reasoning model, you're getting this kind of step-by-step, this chain of thought reasoning. So I like to think of prompts for reasoning model more as briefs.
[00:46 - 00:57] I know this kind of this with a traditional model. It's maybe even a little bit more conversational and with a reasoning model is more, yes, this is a set of instructions to achieve a specific goal.
[00:58 - 01:11] So I'm gonna just use one simple example, simple-ish example going through this. So the goal is like in your traditional model, it's your task and it's your detail, right?
[01:12 - 01:15] It's what you want, it's how you want it. Again, all of the same advice carries on.
[01:16 - 01:28] You want to be clear, you want to be detailed. So here, the example I'm using is write a Python program that takes the name of a Pokemon as an input, then prints some fun facts about a Pokemon on the screen.
[01:29 - 01:34] So that's very clear, it's very direct. I'm using unambiguous verbs here.
[01:35 - 01:48] Okay, fun facts is maybe a little bit ambiguous, right? Because I know I'm not gonna intrinsically understand what fun is, but it's the kind of thing that's been done enough often before that there's ample sources online.
[01:49 - 02:07] And I don't know if any of you guys are Pokemon fans, but that are easily available from many APIs and Pokedex entries. So again, like with a traditional model, we have format here and format is again very important.
[02:08 - 02:14] And here again, I have format and example lumped together. We did lumped them together in some of our previous examples.
[02:15 - 02:20] But here, I actually do put the headings in when I'm prompting you recently model, here's your goal. Does the output format I want?
[02:21 - 02:32] And maybe give an example. So, you know, we could say, for example, this is what the function should be called.
[02:33 - 02:37] This is what the program should be called. You should abide by the Pepe style guidelines.
[02:38 - 02:53] And one thing, if I'm doing like this kind of quick one-shot prompting for just like a silly little bit of code or something, I usually specify that, hey, I want to be able to run this code right away. Most of the code you get even without that is runnable, right?
[02:54 - 03:03] But making sure that it's consistently runnable, it doesn't hurt to add that. Now warnings is where it gets a little bit more interesting.
[03:04 - 03:30] Like obviously when you're using a traditional model, it doesn't hurt to say, hey, this is not what I want. But because of the way reasoning models process prompts, having a warning section and kind of free emptying mistakes it might make, it is actually gonna be quite a lot more successful because it's gonna take those warnings and it's gonna apply that in a kind of methodical way to each step that it's taking.
[03:31 - 03:46] Having these warnings actually really helps avoid hallucinations. I didn't put the full prompt I used initially for this, but I think I did specify that it should do stuff in JSON object, but stuff like make sure that, you know, you're producing a JSON object in the correct format.
[03:47 - 03:54] Make sure that we check that the input is a valid Pokemon name, stuff like this. And last but not least, same as traditional models, context.
[03:55 - 04:08] Again, I think if anything context is more important with reasoning models than with traditional models. So with traditional models, I mentioned that, hey, context and I have to say, you know, who your audience in and it blends in a little bit, wait, for example, tone and role.
[04:09 - 04:19] For reasoning models, I like the context to be more as specific, let's say. But again, we're still specifying our audience, right?
[04:20 - 04:27] So here I could say this code is for my son, 10 years old loves Pokemon, wants to learn a little bit of wet coding. So code should be easy to use and understand.
[04:28 - 04:57] And again, this kind of context is going to be bled into every step in the chain of thought reasoning that's going on, right? Thank you very much.