Skip to main content
These techniques aren’t recommended for reasoning models like gpt-5 and o-series models. Prompt construction can be difficult. In practice, the prompt acts to help the model complete the desired task, but it’s more of an art than a science, often requiring experience and intuition to craft a successful prompt. The goal of this article is to help get you started with this learning process. This article attempts to capture general concepts and patterns that apply to all GPT models. However, it’s important to understand that each model behaves differently, so the learnings might not apply equally to all models.
For current API guidance and examples, see Responses API and Azure OpenAI in Microsoft Foundry Models API reference.

​
Basics

This section covers the basic concepts and elements of GPT prompts. Text prompts are how users interact with GPT models. As with all generative language models, GPT models attempt to produce the next series of words that are most likely to follow from the previous text. It’s as if we’re saying What is the first thing that comes to your mind when I say <prompt>? The examples below demonstrate this behavior. Given the first words of famous content, the model is able to accurately continue the text. As you develop more complex prompts, it’s helpful to keep this fundamental behavior in mind. Regardless of the prompt that is provided, the model is simply responding with what it determines is most likely (given its training data and training targets). If you ask a question in your prompt, the model isn’t following a separate “Q&A” code path, but rather it appears to answer the question because an answer is the most likely sort of response for the given question as input.

​
Prompt components

When you use the Completion API and there’s no differentiation between different parts of the prompt, it can still be useful for learning and discussion to identify the underlying prompt components. With the Chat Completion API, distinct sections of the prompt are sent to the API as an array of dictionaries with associated roles: system, user, and assistant. This guidance focuses more generally on how to think about prompt construction rather than providing prescriptive guidance that is specific to one API over another. It’s also important to understand that while there could be other valid ways to dissect prompts, the goal of this breakdown is to provide a relatively simple way to think about prompt construction. With the Completion API, all the components are optional, but at least one must be present and most prompts include more than one component. There can be some grey area between components as well. The order presented in the following section roughly corresponds to how commonly each component is used, from most to least.

​
Instructions

Instructions are likely the most commonly used prompt component. Instructions are simply that: instructions to the model on what to do. While simple in concept, they can be complex in practice. The following table illustrates this complexity by showing both simple and more complex instructions, in two different forms.

​
Primary content

Primary content refers to text that the model processes or transforms. Typically, you use primary content with instructions. A simple example is language translation. In the following example, the English text is the primary content, and “Translate to French:” is an instruction. Primary content can also be much longer. In the following example, the primary content is the introduction section from the Wikipedia entry on time complexity, which is almost 300 words long. This content is abbreviated in the table for ease of display. GPT models can also handle primary content that is structured. In the following example, a TSV about beers in Belgium (abbreviated for display in this article) is part of the prompt. The model can properly interpret the content and answer questions about the data.

​
Examples

Successful prompts often rely on the practice of “one-shot” or “few-shot” learning. This practice involves including one or more examples of the desired behavior of the model, typically by including input and output pairs. This approach isn’t learning in the sense that the model is permanently changed, but rather that the examples better condition the model to respond as desired for only the current inference. The use of prompts with no examples is sometimes referred to as “zero-shot” learning. Note that with the Chat Completion API, you typically add few-shot learning examples to the messages array in the form of example user and assistant interactions after the initial system message. The preceding example illustrates the utility of few-shot learning. Without the examples, the model seems to be guessing at the desired behavior, while the examples cleanly show the model how to operate. This example also demonstrates the power of the model. It can infer the category of label that is wanted, even without a “basketball” label in the examples.

​
Cue

Cues act as the “jumpstart” for the output of the model, helping to direct the model to the desired output. They’re often a prefix that the model can build onto. In the following example, the cue directs the story to include key elements. You often use cues along with instructions, but not always. In the following examples, the model is being used to summarize a long announcement email. A cue is used in one case to help focus the output of the model and to suggest a specific output format (bullet points). In the context of the Chat Completion API, instructions take the form of the system message, and few-shot examples are indicated by providing a series of example user and assistant interactions to help prime the model.

​
Supporting content

Supporting content is information that the model can use to influence the output. It differs from primary content in that it’s not the main target of the task, but it’s typically used along with primary content. Common examples include contextual information such as the current date, the name of the user, user preferences, and so on. The following example uses supporting content to help organize a set of planned workshops for the user. Without the supporting content (important topics), the model simply lists the workshops (truncated for display). When informed of my important topics, the model accurately groups the meetings.

​
Scenario-specific guidance

The techniques in this section teach you strategies for increasing the accuracy and grounding of responses you generate with a large language model (LLM). However, it’s important to remember that even when you use prompt engineering effectively, you still need to validate the responses the models generate. Just because a carefully crafted prompt worked well for a particular scenario doesn’t necessarily mean it will generalize more broadly to certain use cases. Understanding the limitations of LLMs is just as important as understanding how to leverage their strengths. This guide doesn’t go in-depth into the mechanics behind the message structure for Chat Completions. If you aren’t familiar with interacting with Chat Completions models programmatically, we recommend reading our how-to guide on the Chat Completion API first.
All of the examples in this section of the guide were tested against a base GPT-4 model in English. Some techniques may produce different results with newer models like gpt-4.1, and gpt-4.5. If you’re reading a localized version of this article in another language, these responses represent a localized translation of the English results. To learn more about potential limitations depending on what language you’re using to prompt a model, consult our Responsible AI transparency note.

​
Few-shot learning

A common way to adapt language models to new tasks is to use few-shot learning. In few-shot learning, a set of training examples is provided as part of the prompt to give additional context to the model. When using the Chat Completions API, a series of messages between the User and Assistant (written in the new prompt format), can serve as examples for few-shot learning. These examples can be used to prime the model to respond in a certain way, emulate particular behaviors, and seed answers to common questions. The table above describes the basic prompt structure, but for a detailed explanation of the exact prompt format you’ll need to refer to the Chat Completion guide.

​
Non chat scenarios

While the Chat Completion API is optimized to work with multi-turn conversations, it also can be used for non chat scenarios. For example, for a sentiment analysis scenario, you might use the following prompt:

​
Start with clear instructions

The sequence information appears in the prompt matters. This is because GPT style models are built in a certain way that defines how they process the input. Our research suggests that telling the model the task you want it to do at the beginning of the prompt, before sharing additional contextual information or examples, can help produce higher-quality outputs.
Although following this technique is still generally recommended, in contrast to previous model versions (GPT-3 and prior), our testing showed that the model response with ChatGPT and GPT-4 models was the same regardless of whether the technique is utilized. In this example, we see that adding the statement “Several sources … eruption” at the beginning or the end of the prompt didn’t cause any change in the final model response.

​
Repeat instructions at the end

Models can be susceptible to recency bias, which in this context means that information at the end of the prompt might have more significant influence over the output than information at the beginning of the prompt. Therefore, it’s worth experimenting with repeating the instructions at the end of the prompt and evaluating the impact on the generated response.

​
Prime the output

This refers to including a few words or phrases at the end of the prompt to obtain a model response that follows the desired form. For example, using a cue such as “Here’s a bulleted list of key points:\n- ” can help make sure the output is formatted as a list of bullet points. In the above prompt, the text One possible search query is: primes the model to produce a single output. Without this cue the model produces several search queries as output.

​
Add clear syntax

Use clear syntax for your prompt to communicate intent and make outputs easier to parse. In the example below, separators (--- in this case) have been added between different sources of information or steps. This allows the use of --- as a stopping condition for generation. In addition, section headings or special variables are presented in uppercase to differentiate them. If you’re not sure what syntax to use, consider using Markdown or XML. The models have been trained on a large quantity web content in XML and Markdown, which might provide better results.

​
Break the task down

Large language models (LLMs) often perform better if the task is broken down into smaller steps. For example, in the search query prompt referenced earlier, the prompt can be restructured so that the model is first instructed to extract relevant facts, and then instructed to generate search queries that can be used to verify those facts. Notice the use of clear syntax to differentiate the sections and prime the output. In this simple example, breaking the task down from one to two steps isn’t very dramatic, but when trying to do this for a larger piece of text with many factual claims, breaking the task down can make a significant difference.

​
Use of affordances

Sometimes we can get the model to use an affordance instead of relying on its own parameters for information and answers. Search, for example, can be an affordance to help mitigate against fabricated answers, and to get up-to-date information. One simple way to use an affordance is to stop generation once the affordance calls are generated by the model, then paste the outcomes back into the prompt. Below is an example of what the follow-up call could be after doing the SEARCH calls above. Notice how we pasted the search results into the prompt and replaced the previous SEARCH calls.

​
Chain of thought prompting

This technique is only applicable non-reasoning models. Attempting to extract model reasoning through methods other than the reasoning summary parameter aren’t supported, may violate the Acceptable Use Policy, and may result in throttling or suspension when detected.
This is a variation on the break the task down technique. Instead of splitting a task into smaller steps, in this approach, the model response is instructed to proceed step-by-step and present all the steps involved. Doing so reduces the possibility of inaccuracy of outcomes and makes assessing the model response easier.

​
Specifying the output structure

Using your prompt to specify the structure of the output can have a significant effect on the nature and quality of the results. Sometimes system message inputs as “only write true facts” or “don’t fabricate information” might not be adequate mitigations. Instead, asking for the model response to also include citations can help result in a reduction of the prevalence of incorrect responses. If you instruct the model to cite the source material when it makes statements, those statements are much more likely to be grounded. Asking for citations makes it so that the model must make two errors every time it generates a response: the first error is the fabricated response, and the second is the bad citation. Note that the closer the citation is to the text it supports, the shorter the distance ahead the model needs to anticipate the citation, which suggests that inline citations are better mitigations for false content generation than citations at the end of the content. Similarly, if you ask the model to extract factual statements from a paragraph, it might extract compound statements such as ‘X is doing Y AND Z’ (which can be harder to verify). This can be avoided by specifying an output structure such as (entity1, relationship, entity2). This example shows the use of citations and directing the model response to fit a defined structure.

​
Temperature and Top_p parameters

Changing the temperature parameter changes the output of the model. The temperature parameter can be set between 0 and 2. A higher value, for example 0.7 makes the output more random and produce more divergent responses, while a lower value, like. 0.2, makes the output more focused and concrete. A fictional story could be generated using a higher temperature. Whereas to generate a legal document it’s recommended to use a much lower temperature. Top_probability is another parameter and is similar to Temperature in that it also controls the randomness of the model response, but it does so in a different way. The general recommendation is to alter one of these two parameters at a time, not both.

​
Provide grounding context

One of the most effective ways to provide reliable answers is to give the model data to draw its responses from (grounding data). If your use case relies on up-to-date, reliable information and isn’t purely a creative scenario, we strongly recommend providing grounding data. In general, the closer you can get your source material to the final form of the answer you want, the less work the model needs to do, which means there’s less opportunity for error. Here’s an example where the system is provided a blog describing the launch of GPT-4 in Azure OpenAI in Microsoft Foundry Models, and asked to name some of its early customers. 1 Text from Azure OpenAI GPT-4 launch blog.

​
Best practices

  • Be specific. Leave as little to interpretation as possible. Restrict the operational space.
  • Be descriptive. Use analogies.
  • Double down. Sometimes you might need to repeat yourself to the model. Give instructions before and after your primary content, use an instruction and a cue, and so on.
  • Order matters. The order in which you present information to the model might impact the output. Whether you put instructions before your content (“summarize the following…”) or after (“summarize the above…”) can make a difference in output. Even the order of few-shot examples can matter. This difference is referred to as recency bias.
  • Give the model an “out”. It can sometimes be helpful to give the model an alternative path if it’s unable to complete the assigned task. For example, when asking a question over a piece of text, you might include something like “respond with ‘not found’ if the answer isn’t present.” This addition can help the model avoid generating false responses.

​
Space efficiency

While the input size increases with each new generation of GPT models, you can still encounter scenarios that provide more data than the model can handle. GPT models break words into “tokens.” While common multisyllable words are often a single token, less common words are broken into syllables. Tokens can sometimes be counterintuitive, as shown by the following example, which demonstrates token boundaries for different date formats. In this case, spelling out the entire month is more space efficient than a fully numeric date.
Screenshot of a string of text with highlighted colors delineating token boundaries.
Given this limited space, it’s important to use it as efficiently as possible.
  • Tables – As shown in the examples in the previous section, GPT models can easily understand tabular formatted data. This format can be a space-efficient way to include data, rather than preceding every field with a name (such as with JSON).
  • White space – Consecutive white spaces are treated as separate tokens, which can waste space. Spaces preceding a word, on the other hand, are typically treated as part of the same token as the word. Carefully watch your usage of white space and don’t use punctuation when a space alone will do.