Few-Shot Learning with Examples

What is Few-Shot Learning?

Few-shot learning is the practice of providing examples in your prompt to demonstrate expected behavior. The model learns the pattern from these examples and applies it to new inputs.

The Spectrum

Why Examples Work

Examples are powerful because they:

• Show, don't tell - Concrete demonstration beats abstract description
• Handle ambiguity - Resolve unclear requirements
• Establish patterns - Model extracts the underlying logic
• Address edge cases - Show how to handle tricky situations

As Anthropic emphasizes:

> "Examples, or few-shots, is a mechanism that really is powerful in steering Claude. You can bake in concrete examples of situations that are tricky for Claude to get right."

Basic Few-Shot Structure

<examples>
  <example>
    <input>Customer says: "Your product is terrible!"</input>
    <output>
      <sentiment>negative</sentiment>
      <intensity>high</intensity>
      <action>escalate to manager</action>
    </output>
  </example>

  <example>
    <input>Customer says: "It works but could be better"</input>
    <output>
      <sentiment>mixed</sentiment>
      <intensity>low</intensity>
      <action>log feedback</action>
    </output>
  </example>

  <example>
    <input>Customer says: "I love this! Best purchase ever!"</input>
    <output>
      <sentiment>positive</sentiment>
      <intensity>high</intensity>
      <action>request review</action>
    </output>
  </example>
</examples>

Now analyze this:
<input>Customer says: "It's okay, nothing special"</input>

Designing Effective Examples

1. Cover the Range

Include examples that span the spectrum:

<examples>
  <!-- Clear positive case -->
  <example>...</example>

  <!-- Clear negative case -->
  <example>...</example>

  <!-- Edge case / ambiguous -->
  <example>...</example>
</examples>

2. Match Expected Input Format

If real inputs are messy, examples should be too:

<!-- Bad: Too clean -->
<example>
  <input>Product: Widget X, Color: Blue, Size: Large</input>
</example>

<!-- Good: Realistic -->
<example>
  <input>widget x blue L (large size) - customer wants expedited</input>
</example>

3. Handle Edge Cases

Use examples to address tricky situations:

<example>
  <scenario>Conflicting information in input</scenario>
  <input>Order: Red shirt, size M. Note: "Actually blue, size L"</input>
  <output>
    <color>blue</color>
    <size>L</size>
    <note>Corrected from original order based on customer note</note>
  </output>
</example>

Visual Examples

For vision tasks, you can include images in examples:

<examples>
  <example>
    <image>[base64 encoded image of form with box 1 checked]</image>
    <analysis>
      Vehicle A: Box 1 checked (was parked/standing still)
      Vehicle B: No boxes checked
      Fault: Vehicle B at fault for hitting parked vehicle
    </analysis>
  </example>
</examples>

The Car Accident Example

For the Swedish insurance forms, Anthropic suggests:

<system_prompt>
  <examples>
    <example id="rear-end-collision">
      <form_data>
        Vehicle A: Box 8 checked (was striking the rear)
        Vehicle B: Box 1 checked (was parked/standing)
      </form_data>
      <sketch>
        [Description or image of rear-end collision]
      </sketch>
      <analysis>
        Vehicle A struck Vehicle B from behind while B was stationary.
        Vehicle A is at fault (rear-end responsibility rule).
      </analysis>
    </example>

    <example id="intersection-collision">
      <form_data>
        Vehicle A: Box 16 checked (coming from the right)
        Vehicle B: Box 13 checked (turning left)
      </form_data>
      <sketch>
        [Description or image of intersection collision]
      </sketch>
      <analysis>
        Vehicle B was turning left, Vehicle A had right of way.
        Vehicle B is at fault (failure to yield to traffic from right).
      </analysis>
    </example>
  </examples>
</system_prompt>

Building Your Example Set

Step 1: Identify Common Cases

- What are the most frequent inputs?
- What are the expected outputs for each?

Step 2: Identify Edge Cases

- Where does the model fail without examples?
- What inputs are ambiguous?
- What requires domain knowledge?

Step 3: Create Examples

- Write realistic inputs
- Show correct outputs
- Add explanations if needed

Step 4: Test and Iterate

- Run new inputs through the prompt
- Find failure cases
- Add examples to address them

How Many Examples?

Few-Shot vs. Fine-Tuning

Use few-shot to prototype, fine-tune when you have stable requirements.

Common Mistakes

1. Examples Too Perfect

❌ Pristine, formatted examples
✓ Realistic, messy examples matching actual input

2. Missing Edge Cases

❌ Only happy-path examples
✓ Include failures, ambiguous cases, exceptions

3. Inconsistent Format

❌ Different output formats in examples
✓ Same structure in every example

4. Too Many Examples

❌ 50 examples (wastes tokens, confuses)
✓ 5-10 carefully chosen examples

Key Takeaways

• Examples show, don't tell - More powerful than descriptions
• Cover the spectrum - Positive, negative, and edge cases
• Match real inputs - Use realistic, messy examples
• Iterate on failures - Add examples for cases that fail
• Quality over quantity - 5 good examples beat 20 mediocre ones

Next Lesson

Next, we'll explore Step-by-Step Instructions - how to guide the model through complex reasoning tasks.