What you need to know
The exam guide names three techniques: zero-shot, few-shot and chain-of-thought. The skill being tested is choosing between them for a given task, and knowing what each one cannot do.
Zero-shot: clear instructions, no examples
You describe the task, the inputs and the expected output, and give no worked examples. It is the right starting point for well-defined tasks: classifying into clearly separated categories, summarizing to a stated length, extracting named fields. Most quality problems at this stage are fixed by being clearer and more specific, not by adding techniques.
Few-shot: show, do not just tell
You include a handful of input and output pairs. Examples work best when the desired behaviour is easier to show than to describe: a house style, a subtle boundary between categories, a judgment pattern.
Good example sets are:
- Representative of the real input mix, not only the easy cases.
- Diverse, so the model learns the pattern rather than copying one surface feature.
- Strong on boundaries, including the cases people also argue about.
- Consistent, with no two examples that contradict each other.
- Clearly marked, for example inside
<example>tags, so they are not confused with the real input.
Chain-of-thought: reason before answering
For multi-step problems, asking the model to work through the problem before giving its answer, or enabling extended thinking, often improves quality. Structured prompts help: "first list the relevant policy clauses, then compare each to the claim, then give the recommendation." Separating the reasoning from the final answer (for example in different tags or fields) keeps the output clean for downstream code.
Reasoning costs tokens and time, so use it where the task genuinely has several steps, not everywhere.
| Technique | Examples? | Best for | Cost |
|---|---|---|---|
| Zero-shot | No | Clear, well-specified tasks | Lowest |
| Few-shot | Yes | Formats, styles and boundaries that are easier to demonstrate | More input tokens |
| Chain-of-thought | Not needed | Multi-step analysis and judgment | More output tokens and latency |
What these techniques cannot do
Reasoning makes a calculation more likely to be right; it does not make it right. Exact arithmetic, dates and policy rules still belong in code or authoritative systems. Likewise, examples cannot supply facts the model does not have.
Long documents need their own care
When a prompt contains long documents, put the documents before the instructions and the question, wrap each one in tags with its source, and ask the model to quote the relevant passages before answering. Quote-first answers are easier to verify and less likely to drift from the source.
Prompts do not transfer blindly
The same prompt can behave differently on another model tier or generation. A capable model may need less scaffolding; a smaller one may need more examples. Re-evaluate prompts on the model that will actually run them.
In the exam
Technique questions describe a task and a symptom: inconsistent format, wrong category on borderline inputs, shallow analysis, or wrong numbers. Match the symptom to the technique. Inconsistency or subtle categories point to few-shot; shallow multi-step analysis points to reasoning; wrong numbers point to code or tools, not prompting. Answers that pile on every technique at once, or skip measurement, are usually wrong.
Check your understanding
A summarizer's outputs are accurate but follow no consistent house style, which is hard to describe in words. What should be tried first?
Show answer
Answer: B. Style is easier to show than describe, which is exactly where few-shot examples help. Reasoning addresses multi-step problems, not style.
An assistant computes pro-rated subscription refunds and is wrong about 4% of the time. Which change fixes this?
Show answer
Answer: A. Exact figures belong in deterministic code. Reasoning and examples lower the error rate but cannot guarantee a correct number every time.
A prompt asks questions about three 40-page contracts. Which TWO practices improve accuracy?
Show answer
Answer: A, B. With long documents, putting them first and asking for supporting quotes before the answer improves accuracy and makes the answer verifiable. Tags with titles help the model keep the sources apart.
Apply it: Choose techniques for claim triage
Larkfield wants Claude to label each new claim with one of six types (motor collision, motor theft, home water damage, home fire, home theft, liability) and to write a three-line "adjuster note". A first zero-shot test labels 91% correctly; most errors are home water damage versus liability (a neighbour's flat flooded by the customer), and motor theft versus home theft (a car stolen from a garage).
- Decide the next step for the labels and explain why it targets these errors.
- Design the example set: how many examples, which ones, and how they are marked.
Done when: your set includes the confusing cases from the test. - Decide whether the adjuster note needs reasoning, and what must not be left to the model.
- Say how you will know the change worked.
Show model answer
1. Next step. Few-shot. The errors sit on two specific boundaries that are easier to show than to describe; the instructions are not the problem.
2. Example set. Twelve examples in <example> tags: two of each type, with the second of each pair chosen from the confusing zone. Specifically: two water-damage claims where only the customer's home is affected, two liability claims where the customer's leak damaged a neighbour's property, two thefts of a car from a garage (labelled motor theft) and two burglaries where car keys were taken but the car was not (home theft). Each example shows the label and a one-line reason, so the boundary rule is visible.
3. Adjuster note. Light structured reasoning helps: ask for the facts first (what happened, when, what is damaged), then the note. But cover, excess and policy limits are not inferred by the model; they come from Policy Admin and are inserted by code if the note mentions them.
4. Measuring. Re-run the same labelled test set, with the confusing cases kept as their own slice. The change is accepted if overall accuracy rises and the two boundary slices improve, with no other type getting worse.