Advanced prompting techniques

Few-shot: teach by example

A zero-shot prompt asks for a result with no examples. A few-shot prompt adds a handful of solved cases first, and the model infers the pattern: format, length, tone and level of detail. It is the fastest way to get a consistent output style.

In a chat API, the cleanest way to give examples is as message pairs. Each example becomes a user message with an input and an assistant message with the ideal reply, followed by the real request. The model then treats your examples as earlier turns it should continue in the same way.

Choose examples that differ from each other. If all of them are about biology and three sentences long, the model may push every answer towards biology and three sentences. Vary topic and difficulty while keeping the format identical.

Examples are also tokens you pay for on every call. Start with one or two, add more only if the test set shows a gain, and remove any example that teaches something you did not intend.

Make sure every example is actually correct. The model copies mistakes as faithfully as good habits, so a wrong answer letter in one example can teach it that the answer line does not have to match the options.

Step-by-step reasoning

On problems with several steps, such as arithmetic word problems or logic puzzles, models make fewer errors when they write out the intermediate steps before the answer. This is often called chain-of-thought prompting. You can ask for it directly or show one worked example that lays out each step.

Reasoning makes the reply longer, so ask for the final result on a labelled line such as Answer: 1. Your code can then read that line and ignore the working, and you can still inspect the steps when something goes wrong.

A related method is least-to-most prompting: first ask the model to break a big problem into smaller sub-questions, then solve them in order. It helps when a task is too large to handle in one go, such as planning a revision timetable for several subjects.

Reasoning models already do this kind of thinking internally before they answer. With them, an explicit request to think step by step adds little and can even get in the way; check your provider's guidance and test both versions on your set.

Reasoning text is not a faithful record of how the model reached its answer. It is useful for spotting where a reply went wrong, but a tidy chain of steps can still end in a wrong result, so check the final answer on its own.

Self-check and critique

A model's first draft can often be improved by a second pass that criticises it. Ask the model to compare its answer against explicit criteria, list concrete problems and then write a corrected version. This loop is sometimes called self-refine.

Another variant asks the model to explain each part of its answer in more depth. When an explanation contradicts the original claim, that part is suspect and should be dropped or checked. The goal is to expose inconsistencies rather than to trust any single reply.

Self-checks have a clear limit: the checker shares the blind spots of the writer, especially when it is the same model. Use code for anything code can verify, such as the number of options, the presence of an answer line or a valid calculation, and keep human review for facts that matter.

Make the criteria concrete. Check that exactly one option is correct, that the answer letter matches it, and that the question can be answered from the notes gives the checker something to test, while check if this is good invites a vague approval.

Prompt chaining

Instead of one huge prompt, split the job into steps and make one call per step, feeding each output into the next. For Study Buddy's quiz that might be: write a question, check it, and rewrite it if the check fails.

Chains are easier to debug because each step has a narrow job and a visible output. You can test steps separately, use a cheaper model for simple ones and put ordinary code between them, for example to validate a format before the next call.

Another useful pattern is to generate knowledge first. Ask for the key facts about a topic, or better, supply them from the learner's notes, and only then ask for the quiz question. Separating facts from wording makes errors easier to see.

Every extra step adds latency and cost, so chain only where it buys reliability. Two or three well-defined steps usually beat a long pipeline that is hard to follow.

Log the input and output of every step while you develop a chain. When the final result is wrong, the logs show at a glance whether the first step produced bad material or a later step damaged good material.

Temperature and sampling

Temperature controls how adventurous token choices are. Use a low value for extraction, grading, checking and factual answers, where you want the most likely output. Use a higher value for brainstorming, varied practice questions and creative writing.

Even at zero, outputs are not guaranteed to be identical on every provider, so never build logic that depends on an exact string. Another setting, top_p, limits choices to the most probable tokens; adjust temperature or top_p, not both at once.

Some reasoning models ignore or reject a custom temperature. If a request fails on that parameter, remove it for that model and rely on the prompt to control style instead.

Pick the temperature per step, not per app. In a chain, the creative step can run warm while the checking and formatting steps run cold, which gives you variety where it helps and stability where it matters.