A How-to Guide: Prompt Engineering for Traditional Models

In a relatively short space of time, Large-Language Models (LLMs) seemingly took over everything. You can’t throw a rock without hitting a workflow that’s been altered by the ubiquity of chatbots - everything from coding with AI assistants to healthcare, energy, and even the service sector have been affected. In some cases, this has been a boon to workers and helped to remove manually intensive data tasks, in others, the results have not been so fruitful - take for example the recent (as of Feb 2024) case where a lawyer used ChatGPT to draft legal documents for a lawsuit against an airline, 

only for the LLM to hallucinate examples of case law

LLMs can be useful tools when used correctly, but it’s unsurprising that many are resentful and mistrustful of LLMs. But regardless of our personal views on the matter, they have already taken root in nearly every industry and are being embedded deep into our daily work lives. This article isn’t going to make a case for whether this is a good or bad thing - we’re simply going to focus on how to get the most out of these tools when using, and delve into one of the big buzzwords in the industry: Prompt Engineering.

In this article we’re going to cover the basics of prompt engineering, 

You probably already have an idea of what prompt engineering means, you might even have strong views about it not 

 being engineering at all (seeing as you don’t need to write code to interface with LLMs). But for the sake of completeness: prompt engineering is the practice of using more advanced prompts to get desired, specific outputs from an LLM. Most basic functions don’t require a huge amount of thought. If you ask, for example, “give me a date formatter in python”, you’ll likely get decent boilerplate code that you can use nine out of ten times.

But the output of LLMs is non-deterministic. Results aren’t consistent, nor necessarily repeatable, and small changes in how you prompt the tool can lead to pretty drastic changes in the output. In this article we’re going to cover both more basic and more complex tips for getting the type of output you need.

Before we get into prompting, let’s take a look at some basic features and parameters that govern how LLMs operate. Understanding these will help in crafting prompts.

Tokenisation is the way LLMs break down prompts into a format it can use to give an output. A natural language prompt given to an LLM is converted to a series of 

 Usually, but not necessarily, each word becomes a single token. Note that the cost of using mainline models generally scales with the number of input and output tokens processed.

 to see how words get broken up into tokens. In the example below you can see the phrase “How many miles to Babylon” (a book title) being turned into tokens with a one-to-one relationship of word to token. It’s worth noting that different models will tokenize inputs differently.

A type of context message that persists throughout the chat with an LLM model - most models offer this feature. Think of it as something that gets prepended or appended to every prompt you send during a conversation.

This refers to the number of input tokens a model can take as input. A larger context window means you can give more context for your prompt. It’s rare that you will run into a prompt that is too long for context windows of modern LLMs - but trying to input a whole codebase or a full-length novel might go over the bounds.

The opposite of the context window. This parameter determines how many tokens can be in the model’s output, i.e. how long and complex the answers that can be.

Below you can see the Context Window and Max Output Tokens for gpt-4o models. As you can see, they are quite large.

Temperature determines how ‘creative’ an LLM is. Lower temperatures lead to more consistent and deterministic results - ideal for coding - whereas a high temperature leads to less predictable and more creative output, useful for, say creative writing.

Zero-Shot prompts are simple prompts that don’t give a huge amount of context the the LLM - in other words, it’s a prompt that doesn’t use examples or demonstrations. This is not the most methodical way of interacting with LLMs, but works for many basic use cases - and even in cases where it doesn’t, ‘zero-shotting’ can give you a baseline to iterate from.

If you use a playground or a bespoke LLM, you may be able to configure these settings to change the kind of answers your LLM is able to give you.

These are some very basic guidelines for prompting - they may seem a little obvious, but keeping to these will help keep your output aligned to your goal.

Before we get into the weeds of prompt writing, we need to discuss the differences between reasoning and non-reasoning models, as these need to be prompted differently.

Traditional - or non-reasoning - LLMs effectively use statistical models to analyse an input string and determine what the next word should be - a form of very advanced linguistic pattern matching. A reasoning model will break up the customer’s goal into a series of sub-tasks and execute them in sequence, this is known as a “chain of thought”.

This is more analogous to how humans solve problems, but comes at a higher computational (and thus, financial) cost. Reasoning models perform better (albeit slower) on complex tasks, but the trade-off on computation cost and a propensity to “overthink” simple prompts means that traditional models still have a place for the time being. 

In short - reasoning models outperform non-reasoning models on tasks with more reasoning steps, i.e. tasks that are more complex like generating complex code. Traditional models work better (and generally cost less) for simpler tasks.

Reasoning models include DeepSeek-R1 and OpenAi’s o1/o3 mini, whereas GPT and other models that have been around for a while tend to be traditional models. Each type of model has its strengths and weaknesses, and perform best with different types of prompts. In this article, we will look at how to prompt reasoning vs non-reasoning models separately.

How to Write a Good Prompt for Traditional Models

There are seven components that can help you write a good prompt for traditional models, and a helpful structure to follow. You aren’t going to need every single one of these for every prompt - remember, you don’t always need to over-prompt - but knowing what all of these components do and when to use them will give you better results.

This is the most basic requirement for any prompt you give - a clear goal. Are you summarizing a longer text? Generating code? Checking for grammar issues in a document you wrote? Give the LLM a clear and concise goal.

Even simple zero-shot prompts should have a goal as a bare minimum. Even something as simple as “tell me a joke” or, to go back to our previous example, “give me a date formatter in python” meets the criteria of having a clear goal for the LLM to respond to.

If the goal is more complex, you should identify any specific constraints or requirements in your prompt. This is a way of adding colour to your goal and to fine-tune the type of response it should give you. 

For example, this could be something like giving the model an area to focus on when processing text: e.g. asking the model to focus on the key points and opposing interpretations of a legal document.

Specifying the perspective or background to adopt will change the tone and quality of your outputs. This usually takes the format “You are a X” were X represents the perceptive. Generally, you will want to use a persona that has authority in the domain you’re working in.

If you want the model to do something related to stock trading, you might prime it by saying “you are a world-class investment banker in one of the world’s leading financial institutions”. If you want something related to the human body explained simply, you could prime it by saying “You are an 8th grade biology teacher who can explain complex topics with simple words”.

If you’re just playing around with models, you can also have fun by doing the inverse. E.g. “You are a six year old who doesn’t know anything about science - explain quantum theory in your own terms.”

This one is fairly straightforward, and dovetails a little bit with role. You can specify that you want to receive an answer in a professional tone that doesn’t skimp on technical details, or a casual or conversational tone. You might have played around with this already, asking a model to reply in a specific dialect (e.g. Australian pirate).

Specifying a required output structure, if one exists, will generally give you much better results. For example if you’re asking a model to create a blog post, you can ask it to make sure it has an introduction, key takeaways, and conclusion section - you could also ask it to include code snippets if it’s a technical blog. You can specify other subtleties of formatting, such as asking it not to use bullet points or numbered lists, or ask for a table to be included.

You can also specify established output structures such as JSON or CSV formats.

If they are available, providing outputs or patterns to follow helps the model provide more accurate results.  E.g. If you want the model to run some kind of text processing, like swapping the lead character in each sentence from lower case to uppercase you could give these examples:

“we are never leaving the digital realm. this is our home forever” → “We are never leaving the digital realm. This is our home forever”

“A sign of the time. it is said that we should not discuss it. I disagree.” → “A sign of the time. It is said that we should not discuss it. I disagree.” 

The more examples you give, especially covering negative cases, the better the result. But again, be wary of over-prompting - one example is often enough.

This refers to any background information or source material to use. This could include the text you pass in for summarization, or your code base when asking the model to run coding tasks. Knowing this context informs how a model can reply to you, and is often crucial in achieving your goal.

Now let’s look at a specific example where we put these things into practice. Let’s use our first example.

Prompt: "give me a date formatter in python"

This prompt doesn’t include most of the components we listed above, and it’s rather on the vague side.

Here is an example output from a traditional model:

from datetime import datetime

# Function to format date
def format_date(date_str, input_format, output_format):
    try:
        # Convert string to datetime object based on input format
        date_obj = datetime.strptime(date_str, input_format)
        
        # Convert datetime object to desired output format
        formatted_date = date_obj.strftime(output_format)
        return formatted_date
    except ValueError as e:
        return f"Error: {e}"

# Example usage
date_string = "2025-02-19"
input_format = "%Y-%m-%d"  # Input format
output_format = "%B %d, %Y"  # Output format (e.g., "February 19, 2025")

formatted_date = format_date(date_string, input_format, output_format)
print(formatted_date)

The code above is simple and functional, and it certainly meets the criteria for the task we’ve given. In some cases this might be enough, so if this is all that was needed - happy days.

But you can see that our LLM had to make certain assumptions to be able to deliver this code, for example around the date format to use. But let’s say we wanted something a little more complex.

Let’s look at how we can fine-tune this prompt with the structure given above:

Prompt: 
"
You are a senior python developer working for google who writes clean, extensible code.

Write a date formatter function in Python called format_my_date. 

The function should take a string as input  in the format "MM/DD/YYYY". If the input date
matches the format, return a date in ISO format "YYYY-MM-DD". If the input doesn't match
the input format, return an error message.
Do not use any imported packages.

The code be fully functional, should follow PEP8 guidelines, and provide short comments 
as needed

Examples:
Input: "08/17/1993" -> Output: "1993-08-17"
Input: "01/01/1901" -> Output: "1901-01-01"
Input: "123/56/12000" -> Output: "Error"
"

And here is a sample output from a GPT model:

def format_my_date(date_str):
    """
    Converts a date string from MM/DD/YYYY format to ISO format (YYYY-MM-DD).
    
    Args:
    - date_str (str): The date string in MM/DD/YYYY format.
    
    Returns:
    - str: The date in ISO format (YYYY-MM-DD) if valid, or an error message if invalid.
    """
    # Check if the input string has the correct length
    if len(date_str) != 10:
        return "Error"
    
    # Extract the components of the date
    month, day, year = date_str.split('/')

    # Validate that month, day, and year are all digits
    if not (month.isdigit() and day.isdigit() and year.isdigit()):
        return "Error"
    
    # Convert to integers for further validation
    month, day, year = int(month), int(day), int(year)
    
    # Validate the month, day, and year ranges
    if not (1 <= month <= 12):
        return "Error"
    if not (1 <= day <= 31):
        return "Error"
    if not (1000 <= year <= 9999):
        return "Error"

    # Check for valid days in specific months (handling leap year for February)
    days_in_month = {
        1: 31, 2: 28, 3: 31, 4: 30, 5: 31, 6: 30, 7: 31, 8: 31, 9: 30,
        10: 31, 11: 30, 12: 31
    }

    # Check for leap year in February
    if (month == 2 and day > 28):
        if (year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)) and day > 29:
            return "Error"
        elif day > 28:
            return "Error"

    # Check for months with only 30 days
    if month in [4, 6, 9, 11] and day > 30:
        return "Error"
    
    # If all validations pass, return the date in ISO format
    return f"{year:04d}-{month:02d}-{day:02d}"

# Example usage:
print(format_my_date("08/17/1993"))  # Output: "1993-08-17"
print(format_my_date("01/01/1901"))  # Output: "1901-01-01"
print(format_my_date("123/56/12000"))  # Output: "Error"

You can see that the code above is much more specifically tuned to our requirements - in fact it’s very thorough (maybe even overzealous) in validating the input date is correct.  We can also see that we have a comment in Pep8 style at the top of the function and that the code is ready to run. Of course, in most cases we would want to use the 

 package when manipulating dates in Python, but not using it here was a good way of showing you how details shape the output of a prompt.

Now, just for fun, let’s change a few things about our prompt to underscore just how much our instructions prime the output.

Prompt: 
"
You are an inexperienced javascript coder who's never written python code before.

Write a date formatter function in Python called format_my_date. 

The function should take a string as input  in the format "MM/DD/YYYY" and return a date
in ISO format "YYYY-MM-DD". Don't import any packages & follow your heart when it comes
to input validation and error handling.
"

def format_my_date(date_str):
    # Let's hope the string is always in the format MM/DD/YYYY
    if len(date_str) != 10:
        return "Error"  # Just some random error if the length isn't right, who knows why!
    
    # Splitting the string
    parts = date_str.split("/")
    
    # Let's assume the parts are always there, no need to check that
    month = parts[0]
    day = parts[1]
    year = parts[2]
    
    # Not bothering to check if month, day, or year are numbers. It's fine, right?
    
    # Just converting it to "YYYY-MM-DD" format
    result = year + "-" + month + "-" + day
    
    # Some random error if the month is greater than 12 (but not doing much else)
    if int(month) > 12:
        return "Error"
    
    return result

# Test cases
print(format_my_date("08/17/1993"))  # Maybe works: "1993-08-17"
print(format_my_date("01/01/1901"))  # Maybe works: "1901-01-01"
print(format_my_date("123/56/12000"))  # "Error", but who knows?

It may go without saying, but “follow your heart” isn’t a particularly useful instruction for most LLMs! Clear and direct instructions lead to more uniform and useful outputs.

So there you have it - a quick guide on getting the most from your prompts with traditional models. Simple prompts are often the best way forward, but when they aren’t, giving details, output format, role, examples and the other components we discussed can drastically improve your results. We’ve included a list of resources for prompting below, and we’ll be publishing another article soon that deals with prompting reasoning models.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

A How-to Guide: Prompt Engineering for Traditional Models

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript