Few-Shot Chain-of-Thought Prompting

What Is Few-Shot Chain-of-Thought? Few-shot chain-of-thought (few-shot CoT) combines two techniques:

Few-shot prompting (Lesson 26): the prompt contains examples of inputs and outputs. Chain-of-thought prompting (Lesson 39): the output includes step-by-step reasoning. In few-shot CoT, each example shows not only the correct answer but the reasoning that leads to it. The model then reasons about the new input in the same way.

This is the original form of chain-of-thought prompting, introduced by Wei et al. (2022). Their prompts for math problems contained eight examples, each with a worked solution followed by the answer.

Example Q: A batch has 40 students. 25% are from Chennai, and half of the rest are from Coimbatore. How many students are from Coimbatore? A: 25% of 40 is 10, so 10 students are from Chennai. The rest is 40 − 10 = 30. Half of 30 is 15. The answer is 15.

Q: A course has 12 modules. A student finished 3 modules in week 1 and twice as many in week 2. How many modules are left? A: In week 2 the student finished 2 × 3 = 6 modules. Total finished: 3 + 6 = 9. Left: 12 − 9 = 3. The answer is 3.

Q: A workshop has 80 seats. 60% are booked online and 12 are booked at the venue. How many seats are still available? A: Expected output:

60% of 80 is 48, so 48 seats are booked online. Total booked: 48 + 12 = 60. Available: 80 − 60 = 20. The answer is 20. Example Explanation The examples demonstrate:

The reasoning style: short sentences, each computing one value. The level of detail: every intermediate result is written, nothing more. The answer format: every solution ends with "The answer is N." The model reproduces all three for the new problem.

Why Add Examples to Chain of Thought? Zero-shot CoT (Lesson 40) produces reasoning, but you have little control over its form. Few-shot CoT adds that control.

What Examples Control Why It Matters Which steps to take The model follows the method shown, such as checking every rule in order How detailed the steps are Avoids both skipped steps and excessive verbosity How to handle tricky cases An example can show how to treat a boundary value or an exception The final answer format Consistent, easy to extract Domain-specific reasoning Shows how your business applies its rules, which generic CoT cannot know When Zero-Shot CoT Is Not Enough The model's reasoning skips a step your process requires. It applies a rule incorrectly at a boundary, such as treating "at least 75%" as "more than 75%". Reasoning style varies widely between runs. The final answer format is inconsistent. Designing Good Reasoning Examples The quality rules for few-shot examples (Lesson 28) all apply. Reasoning examples have additional requirements.

1. The Reasoning Must Be Correct at Every Step An example with a correct final answer but a flawed step teaches the flawed step. The model copies the method, not only the answer.

2. Show the Method You Want Used If your process is "check each condition in order, then decide", every example should do exactly that. Mixed methods across examples produce mixed reasoning.

3. Keep Steps at the Right Size Too Coarse Appropriate Too Fine "The total is 60, so 20 are left." "48 online + 12 at the venue = 60 booked. 80 − 60 = 20 available." Explaining what percentages are, then multiplication, then subtraction... Coarse steps hide the calculations where errors happen. Overly fine steps waste tokens and can lead the model to over-explain.

4. Include a Boundary or Exception Case Show at least one example where a rule is applied at its edge, or where an obvious approach would be wrong.

5. Use a Consistent Answer Marker End every example with the same phrase or tag, such as The answer is N. or ..., so the answer is easy to extract.

6. Vary the Problems Examples should differ in structure and outcome so the model learns the method, not a template. For decisions, include examples with different outcomes.

A Practical Example: Eligibility From Free-Text Records When rules can be checked directly from structured data, code is the best tool. Few-shot CoT becomes valuable when the information arrives as free text that the model must read and interpret, and then apply rules to.

The Rules A student is eligible for a certificate only if:

Attendance is at least 75%. All 5 assignments are submitted. The project score is at least 60. The Prompt Decide whether each student is eligible for a certificate.

Rules:

1. Attendance must be at least 75%.
2. All 5 assignments must be submitted.
3. The project score must be at least 60. A student is eligible only if all three rules are met.

Record: Arun attended 27 of 30 classes, submitted all 5 assignments, and scored 71 on the project. Reasoning:

• Attendance: 27 / 30 = 90%, which is at least 75% → met.
• Assignments: 5 of 5 submitted → met.
• Project: 71 is at least 60 → met. Decision: Eligible

Record: Meena attended 20 of 30 classes, submitted all 5 assignments, and scored 88 on the project. Reasoning:

• Attendance: 20 / 30 = 66.7%, which is below 75% → not met.
• Assignments: 5 of 5 submitted → met.
• Project: 88 is at least 60 → met. Decision: Not eligible

Record: Rahul attended 45 of 60 classes, submitted 4 of the 5 assignments, and scored exactly 60 on the project. Reasoning:

• Attendance: 45 / 60 = 75%, which is at least 75% → met.
• Assignments: 4 of 5 submitted → not met.
• Project: 60 is at least 60 → met. Decision: Not eligible

Record: Priya attended 23 of 30 classes, submitted every assignment except the SQL one, and scored 64 on the project. Reasoning: Expected output:

• Attendance: 23 / 30 = 76.7%, which is at least 75% → met.
• Assignments: every assignment except one means 4 of 5 submitted → not met.
• Project: 64 is at least 60 → met. Decision: Not eligible Example Explanation Example 1 shows the standard method: compute attendance, check each rule, decide. Example 2 shows a failing case with a different outcome, so the model does not assume "Eligible" is the usual answer. Example 3 demonstrates two boundary cases: exactly 75% attendance and exactly 60 points both count as met, because the rules say "at least". It also shows that one failed rule makes the student ineligible even when others are met. The new record uses different wording ("every assignment except the SQL one"). The model must interpret this as 4 of 5, which the examples did not show directly. The reasoning format makes that interpretation visible, so you can verify it. Few-Shot CoT in Python The following implementation builds reasoning examples from data, extracts the decision, and checks it against expected results.

Requirements: pip install openai and an OPENAI_API_KEY environment variable.

import re

from openai import OpenAI

client = OpenAI() MODEL = "gpt-5.4" # Replace with a model available in your account

RULES = """Rules:

1. Attendance must be at least 75%.
2. All 5 assignments must be submitted.
3. The project score must be at least 60. A student is eligible only if all three rules are met."""

EXAMPLES = [ { "record": "Arun attended 27 of 30 classes, submitted all 5 assignments, " "and scored 71 on the project.", "reasoning": [ "Attendance: 27 / 30 = 90%, which is at least 75% → met.", "Assignments: 5 of 5 submitted → met.", "Project: 71 is at least 60 → met.", ], "decision": "Eligible", }, { "record": "Meena attended 20 of 30 classes, submitted all 5 assignments, " "and scored 88 on the project.", "reasoning": [ "Attendance: 20 / 30 = 66.7%, which is below 75% → not met.", "Assignments: 5 of 5 submitted → met.", "Project: 88 is at least 60 → met.", ], "decision": "Not eligible", }, { "record": "Rahul attended 45 of 60 classes, submitted 4 of the 5 assignments, " "and scored exactly 60 on the project.", "reasoning": [ "Attendance: 45 / 60 = 75%, which is at least 75% → met.", "Assignments: 4 of 5 submitted → not met.", "Project: 60 is at least 60 → met.", ], "decision": "Not eligible", }, ]

def format_example(example: dict) -> str: steps = "\n".join(f"- {step}" for step in example["reasoning"]) return ( f"Record: {example['record']}\n" f"Reasoning:\n{steps}\n" f"Decision: {example['decision']}" )

INSTRUCTIONS = ( "Decide whether the student is eligible for a certificate.\n\n" f"{RULES}\n\n" "Follow the reasoning format of the examples exactly, then write the decision.\n\n"

• "\n\n".join(format_example(ex) for ex in EXAMPLES) )

def decide(record: str) -> tuple[str, str]: response = client.responses.create( model=MODEL, instructions=INSTRUCTIONS, input=f"Record: {record}\nReasoning:", ) text = response.output_text match = re.search(r"Decision:\s*(Eligible|Not eligible)", text) if not match: raise ValueError(f"No valid decision found in: {text!r}") return text, match.group(1)

tests = [ ("Priya attended 23 of 30 classes, submitted every assignment except the SQL one, " "and scored 64 on the project.", "Not eligible"), ("Karthik attended 22 of 30 classes, submitted all 5 assignments, " "and scored 90 on the project.", "Not eligible"), ("Divya missed only 3 of 40 classes, submitted all five assignments, " "and got 75 on her project.", "Eligible"), ]

for record, expected in tests: reasoning, decision = decide(record) status = "OK" if decision == expected else f"WRONG (expected {expected})" print(f"{status}: {decision}\n{reasoning}\n") Code Explanation EXAMPLES as data Each example stores the record, a list of reasoning steps, and the decision. Generating the prompt from data guarantees that every example uses the identical format (Lesson 29).

format_example() Turns one example into the Record / Reasoning / Decision layout, with each step as a bullet.

INSTRUCTIONS Contains the task, the rules, an instruction to follow the reasoning format, and the examples. The rules are stated in words and demonstrated in the examples, which is the most reliable combination (Lesson 30).

decide()

The input ends with Reasoning: as an output cue, so the model starts writing reasoning immediately. A regular expression finds Decision: followed by one of the two allowed values. If neither appears, an error is raised. Test cases

Priya requires interpreting "every assignment except the SQL one". Karthik's attendance is 22 / 30 = 73.3%, just below the threshold. Divya's record is phrased differently ("missed only 3 of 40"), so attendance must be calculated as 37 / 40 = 92.5%. All rules are met. These tests target interpretation and boundary handling, which is exactly where few-shot CoT should show its value.

Few-Shot CoT vs Zero-Shot CoT Aspect Zero-Shot CoT Few-Shot CoT Effort One instruction Correct, varied reasoning examples Reasoning method Chosen by the model Demonstrated by you Boundary handling Depends on interpretation of the rules Shown explicitly Output consistency Varies more High Prompt length Short Long Risk Unstructured or incomplete reasoning Copying flawed or inappropriate reasoning patterns Choosing Start with zero-shot CoT, ideally with domain-specific steps (Lesson 40). If reasoning skips steps, mishandles boundaries, or varies too much, add a small number of reasoning examples that target those problems. Compare both on the same test set (Lesson 33), including accuracy and token cost. Common Problems in Few-Shot CoT Problem 1: Copying the Reasoning Path If all examples follow an identical path, the model may apply that path to problems that need a different approach, for example always computing a percentage first even when the problem does not involve percentages.

Fix: Vary the problems so the shared element is the method of careful, explicit steps, not a fixed sequence of operations.

Problem 2: Errors Inside Examples A subtle error in an example, such as treating "at least 75%" as "more than 75%", or rounding 74.6% up to 75% and marking the rule as met, is learned and repeated on similar inputs.

Fix: Verify every step of every example, ideally by computing the values in code.

Problem 3: Overly Long Reasoning Examples with long explanations produce long outputs for every request, increasing cost and latency.

Fix: Keep example reasoning as short as possible while showing every necessary step.

Problem 4: Reasoning and Decision Disagree Sometimes the reasoning says a rule is not met, but the decision says "Eligible".

Fix: In code, check the reasoning lines for "not met" and compare with the decision; flag mismatches for review. In prompts, state explicitly: "If any rule is not met, the decision must be Not eligible."

Common Mistakes Mistake 1: Using Few-Shot CoT When Code Would Be Better What it is: Using a model to apply exact rules to structured data, such as numbers already in a database.

Why it happens: The prompt-based approach is already built.

What it causes: Unnecessary cost and small risk of errors on a task code can do perfectly.

How to fix it: Use code for structured data. Use few-shot CoT when the information must first be interpreted from text.

Mistake 2: Only Demonstrating Positive Outcomes What it is: Every example ends with the same decision.

Why it happens: The first examples that come to mind are typical successes.

What it causes: A bias toward that decision.

How to fix it: Include examples with each possible outcome.

Mistake 3: Examples Without Boundary Cases What it is: All example values are far from rule thresholds.

Why it happens: Clear examples are easier to write.

What it causes: Inclusive and exclusive boundaries ("at least" vs "more than") are applied inconsistently.

How to fix it: Include examples with values exactly at the thresholds.

Mistake 4: Inconsistent Reasoning Formats What it is: One example uses bullets, another uses paragraphs, another uses numbered steps.

Why it happens: Examples are written at different times.

What it causes: Unpredictable output formats that are harder to parse and check.

How to fix it: Generate examples from data with one formatting function.

Best Practices Make every reasoning step correct. The model copies the method, including its mistakes.

Demonstrate the method your process requires. Every example should follow the same procedure.

Include boundaries and different outcomes. These cases teach the most.

Keep reasoning concise. Show each necessary step, nothing more.

End with a consistent decision marker. Extract and validate it in code.

Check that reasoning and decision agree. Flag contradictions.

Use few-shot CoT for interpretation plus rules. Use plain code when the data is already structured.

Try It Yourself Exercise 1: Build Reasoning Examples Choose a decision with three rules from your own context, such as scholarship eligibility or internship selection. Write three reasoning examples: one where all rules are met, one where one rule fails, and one with a value exactly at a threshold. Verify every step manually or in Python.

Exercise 2: Test Interpretation Run the Python example with five new records phrased in unusual ways, such as "was absent for 8 of the 30 sessions", "submitted assignments 1 through 4", or "got a project score of fifty-nine". Check whether the reasoning interprets each phrase correctly.

Exercise 3: Detect Contradictions Extend decide() so that it counts how many reasoning lines contain "not met". If at least one does and the decision is "Eligible", raise a warning. Test it by temporarily editing an example to contain a contradiction and observing whether the model's outputs start to show the same pattern.