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.

This video is available to students only
Unlock This Course

Get unlimited access to The Basics of Prompt Engineering, plus 80+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course The Basics of Prompt Engineering
  • [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.