Prompt engineering tips to improve your workflows with zero-shot, few-shot, and chain of thought promptings

In this article, we are going to talk about the best practices of prompt engineering. But before we dive into it, we should have to clear and understand the basics of prompt engineering and some Generative AI (GenAI) topics.

Prompt engineering is not just about making your current workflow better; it is a strategic way to make your work with Small Language Models (SLMs) much more efficient, which will improve all of your operational processes. Mastering prompt engineering enables the full utilization of these powerful tools, resulting in more precise, pertinent, and efficient outputs across various applications.

Think of prompt engineering as speaking with a clever assistant who listens well and understands explicit instructions. The clearer and more direct the words are, the better and quickest the assistant is, as when providing a full street address to a delivery guy along with a landmark and house colour. Begin with a gentle request, try it, then refine it, adding details or illustrations until the answer appears satisfactory, as adjusting a recipe ingredient by ingredient.

Basic Concepts of Prompt Engineering:

Tokens: Tokens are small units of text, similar to pieces of a puzzle that together form words and punctuation. Models are used for reading and writing as opposed to full words. The token could be a whole word, a piece of a long word, a comma, a special symbol, and different models may divide text in different ways to achieve optimal efficiency in processing. Since models place a constraint in terms of the number of tokens, input as well as output applies to this constraint when constructing a prompt.

Context: Context is the knowledge a model is required to have in order to do a task well, i.e., describing a document to a friend before asking for its summary. Having a concise, relevant context in the prompt reduces confusion and allows a model to answer in terms of the right details or structure. If you do not give any context, responses might be too general or not related to the specific question. So, only provide sufficient information as is needed to help with the task.

Context window: The context window is a model's short-term memory limit, in terms of tokens, which controls how much text it is able to view at once. If a prompt and its likely response are longer than a window, a model must retard or discount earlier tokens, which could destroy coherence or formatting. Larger windows enable a model to view larger sets of data at once, although this could increase cost and latency, so right-sizing inputs is required.

Inference and speed: Inference is how a prompt is processed by a model and a response is generated, and speed is dynamic based on input length, output length, and decoding properties such as temperature and sampling. The temperature near zero generates more stable, predictable output, while higher temperatures allow diversity at the cost of consistency. The controls, such as topK and topP, control how many possible tokens are considered at each step, which determines that step's style as well as its effectiveness.

In simple terms: Speed of the AI model Where which provides rapid response in example tokens per second. For your kind information, use the smallest models to get faster responses.

Zero-shot prompting: Zero-shot prompting involves requesting a result without examples, which is worth a shot and is effective for easy tasks. If zero-shot output is inconsistent or out of format, then move to few-shot prompting by including a few examples to demonstrate to the model. As a general rule, begin with zero-shot and only move higher if necessary, in order to keep prompts brief and efficient.

In simple terms, we usually ask something from an AI Model without providing any examples and directly question from AI.

Advanced Prompt Engineering Techniques:

Few-shot prompting: It is like educating by instance, where you show a few examples of the framework or layout you want. The framework must stay the same, and the examples used must be very similar to the goals and expected outcome. This stops mismatch results from happening. The usual rule is to include a good number of examples, which is enough to help people remember what to do without making the prompt too long or fitting it too closely to very specific trends.

In simple terms, we ask something from an AI Model by providing some context, like (PDF or other resources) from an AI.

Chain of Thought prompting: A model that offers a sequential framework for reasoning, similar to the methodology used in mathematical problem-solving before reaching a result. This works very well for hard activities like logical issues and command operations that demand a series of stages.

In simple terms, we make Small Language Model (SLM), AI models to provide us with deeper answers by making deep reasoning functionalities. I meant to say where we make the smallest AI models to provide us with accurate responses.

Best practices of prompt engineering:

Let's begin with a simple, basic mandate, then check the results before adding more rules or information. It is like making a rough draft before filling in the details. Change things in small steps so you can easily tell which parts of the work make it better or worse. Do not ask too many questions at once or mix up your goals in the same question.

To see how the foundation works, start with: "Summarize the article in three bullet points about what caused it, what happened, and what to do next."

If the original answer is too long or hard to understand, say, "Use simple language and keep bullets short."

Instructions that are easy to follow

First, write the main instruction. Then, write the limits. Finally, write the context. To keep the parts separate, use things like ### or three quotes. To show the model what the structure is, label parts with words like "Instruction:", "Context:", and "Output format:". A well-defined structure makes it easier to get the right output programmatically and lessens confusion. The top part has instructions, the middle part has three quotes that give context, and the bottom part has "Output format," which shows the basic structure of the target output. Use headings like "Task:" and "Constraints:" to make sure the model knows what to do and what not to do.

Give me some examples.

If there are issues with the tone, format, or scope of the content in a model, give a few examples to show the target patterns, such as a sample answer key. Make sure your examples are short, related to the task, and look like the output you want. You should not have to guess too much with the best examples, and you should be able to repeat your answers, especially for very structured outputs, like CSV or JSON. Without an example, "Extract specs as JSON" often makes keys that do not match or do not have the right case. After: Give the model one example with lowercase keys and arrays, and it will use that format for new input.

Instead of telling the model what you do not want it to do, tell it what you do want it to do.

This is clearer and does not mix things up. Say "Do not ask for PII" instead of "Do not ask for passwords" and link to a help page instead. Commands that say "yes" are less likely to make the model repeat content that is not allowed by mistake. In an emergency, it is easy to misinterpret or ignore the instruction "do not give any sensitive information." "Skip PII and give a help link for account access issues" is a safe way to go after.

Over time, it grew

Begin with zero-shot and work your way up to few-shot, adding new limits in small steps and only after checking each one. If examples do not work to fix problems, make the instructions clearer or change the order of the prompts so that patterns come before user input. This careful method keeps prompts short and makes it easier to keep up with them over time.

Step 1: Do a zero-shot with a clear task and format.
Step 2: Use one example to fix the way it looks.
Step 3: Change the tone or scope by giving a second example.

Take out words that are not necessary.

Remove unnecessary words and fluff from sentences so that the model only pays attention to what matters. For example, make a shopping list of only the things you need. Change "fairly short" to "3–5 sentences" and "detailed" to "specific fields or sections needed." Exact numbers, fields, and limits. Make sure the results are always the same and do not let things drift. "Provide a concise and articulate product description" is not clear or consistent. "Write 3 sentences about features, 1 sentence about benefits, and end with a 5-word tag" is clear and can be measured.

Programming tools

To help the model find the right syntax, use prompting words that are in the right programming language. For example, "import" for Python and "SELECT" for SQL. Include only the most basic structure, like function signs or table schemas, so that the output from a model is in the right format for the environment it will be used in. Please only ask for output, not a comment, so it is easier to copy and paste. Python prompt: "Make a function that changes kilometers into miles." The command "import ..." does open the code block where it should be. The SQL command "SELECT ... FROM sales WHERE ..." tells the model to make a valid query.

Use labels and breaks.

To separate instructions, examples, and input, use triple quotes, XML-style markup, or clear labels. This makes things more uniform and easier to read. Make sure that the formatting is the same in all of the examples so that the model can learn a clear pattern. To make sure the model fits the right roles, use labels like, Input:, and Output:. For example, put instance values in brackets and keep the output in the same order. For instance, Put sections in context and tell the model to "Use only text below provided" when it needs to find answers that are based on something.

Place context in the right spot

Keep the context short and only include what the model needs. This way, it will not add too much extra information and will stay in the context window. Put instructions before context and make it clear how to use context, like "Answer only by the provided text," to try to control sources. This method cuts down on generic answers and makes sure that the answers are in the right area. Before: Most of the time, asking for help with troubleshooting without a manual is just good advice. After: The answer is a very short part of a manual that says, "Answer using only this text," and then the model does what it says.

Please tell me what format you want the output to be in.

For example, JSON keys, bullet points, and headings should show exactly what the target structure should look like in the prompt. The model copies this structure, which makes the outputs more reliable and lets scripts check them. Put formatting criteria for positions next to instructions instead of in the input so that they come from the early years of the generation. " Format you want: Names of companies, names of people, and topics: 'Themes' makes lists that are split up into groups. "Return only valid JSON with lowercase keys for these keys" is an example that makes it less likely that there will be parsing errors.

Control Style and length

Use numbers to say things like "Grade 8 reading level" and "2–3 sentences per section" to show tone, reading level, and length. To prevent dilution, maintain the style advice short and nearest to the primary instruction. If the approach is still off, add an instance that demonstrates precisely which voice you need. Before: "Write in an approachable manner" is too general and changes with each run. After: Apply an approachable, authoritative manner and stay away from jargon," limit outcomes for a reliable approach.

Iterate and test

When your outcome doesn't match what you want, attempt to make minor modifications, like changing the structure of the commands, rephrasing them, or making your input easier. Provide an additional version alongside examples, or change the instances to correct problems with edges. Maintain a track of which options worked better so that the request can be used again and again. Try Versions 1, 2, and 3 using distinct wording and put the results next to each other to determine which one performs most effectively. To prevent the model from adding extra information, set an ending pattern or ask for "Final answer only" at the end of the output.

Stability tips for parameters

Maintain the temperature low for tasks that require facts or strict structures to make things less random and more consistent. Set a limit on the number of generated tokens to preserve answers quickly and make sure they do not go over the required length or the context window. For tasks that are creative, raise the temperature a little and give examples to help find a balance between newness and control. When consistency is important, predictable configurations are ideal for obtaining and sorting. Higher temperatures can help brainstorming be more creative, but you might need examples to keep things organized.

Common mistakes and easy ways to fix them

Do not ask for both the analysis and the final version in the same prompt. Rather, break the task down into steps. Do not put too much text in the context window, because that forces the important parts out and makes the outcomes weaker. Do not just use negative rules like "don't." Write beneficial choices to show the right way to go. Multiple goals: To help you focus, break them down into two prompts: "Extract facts" and "Write summary from facts." Too much context: Cut it down to just the parts you need to fit in the window and cut down on noise.

A straightforward list to help you write more effective prompts

initially, enter the instruction, afterwards the structure, and then the context, and finally the input. For identifying breaks, use things like ### or three quotes. Choose particular numbers, areas, and boundaries in unclear sentences. If the tone or structure is wrong, add a couple of examples. Rather than saying "do not do X," say "do Y." Keep prompts in the context window and cut out any extra text. Set the temperature to be stable or creative, depending on what you need to do. Make small changes, test them, and keep what works.

Conclusion

To be good at prompt engineering, you need to have clear goals, a simple structure, and make small, steady changes that make things better over time. Start with a short instruction, show the desired format, add some context, and then go from zero-shot to few-shot when you need to have more control over the results. For stability, use clear words, short examples, and a low temperature. Always test one change at a time to find out what works best for the job.