Match each DSPy optimizer to its core search strategy

Match pairs·Hard·4.0 · 0·~2 min·Asked atBraintrust Redis Servicenow

Attempt it

Drag each answer to line up with its matching prompt

Bootstraps few-shot examples from a stronger teacher model and selects the ones that pass the metric

MIPROv2

Jointly optimises instructions and demonstrations via Bayesian search over a candidate space

BootstrapFinetune

Refines instructions through coordinate ascent, perturbing one prompt component at a time and keeping winners

COPRO

Bootstraps demonstrations with random search over a finite candidate set, the cheap baseline

BootstrapFewShotWithRandomSearch

Fine-tunes the underlying LM weights against the metric instead of editing the prompt

BootstrapFewShot

DSPy is a framework that treats prompts as something a compiler should construct, not something humans hand-tune. The piece that does the constructing is called an **optimizer** (sometimes 'teleprompter' in older docs). Each optimizer is a search strategy over some part of a prompt program. They differ along two axes: **what they edit** (the few-shot demonstrations, the instruction string, or the model weights themselves) and **how they search** (greedy bootstrap, random sampling, Bayesian optimization, coordinate ascent, fine-tuning). The five in this question span the design space. `BootstrapFewShot` greedily collects demos from a teacher model that score well on your metric. `BootstrapFewShotWithRandomSearch` does the same with random search over candidate sets. It is the cheap and cheerful baseline. `COPRO` perturbs the instruction string one slot at a time, keeping changes that improve the metric. `MIPROv2` is the most sophisticated of the prompt-editing optimizers. It runs Bayesian search jointly over instructions and demonstrations. `BootstrapFinetune` skips prompt search entirely and fine-tunes the model weights. Learning the names is half the battle; the names actually telegraph what each does once you know the conventions.

DSPy compiles prompt programs the way a compiler compiles code: optimizers search over the program's tunable parts to maximize a user-supplied metric. The five in the question cover most of the active design space. `BootstrapFewShot` runs your program with a teacher LM, collects traces, keeps the demonstrations that scored on the metric, and uses them as few-shot examples for the student. Cheap, effective, the most-used optimizer in early DSPy work. `BootstrapFewShotWithRandomSearch` extends that: instead of one set of bootstrapped demos, it samples many candidate sets and picks the best by validation score. Random search is the honest baseline. `COPRO` (Coordinate-ascent Prompt Optimization) edits the instruction string. It generates several candidate instructions, evaluates them, keeps the winner, and iterates. One component changes at a time. Classic coordinate ascent. `MIPROv2` is the most ambitious prompt optimizer: it builds a candidate space over both instructions and demonstrations, uses Bayesian optimization with a surrogate model to pick promising combinations, and converges faster than random search at higher cost per round. The current default for serious DSPy work. `BootstrapFinetune` leaves prompts alone and fine-tunes the LM weights against your metric using the bootstrapped traces as training data. Useful when prompt search has hit a ceiling and you have a model you can fine-tune.

TL;DR

DSPy optimizers vary by what they edit (demos vs instructions vs weights) and how they search (greedy bootstrap, random, Bayesian, coordinate ascent, gradient).

Memory aid

Easy to grasp

Picture a chef trying to nail a dish for a critic. BootstrapFewShot watches a master chef make it five times and copies the bites the critic liked. RandomSearch tries random combinations of plates and keeps the best. COPRO tweaks one ingredient at a time, keeping the change if the critic smiles. MIPROv2 is the data-driven chef who runs a smart trial and error plan over both the recipe and the plating. BootstrapFinetune sends the apprentice back to culinary school to actually learn new techniques.

Key concepts

LLM frameworks

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

DSPy frames prompt engineering as a compilation problem. You write a program declaratively (signatures, modules), supply a metric, and let an optimizer search over the tunable parts to maximize that metric. Each optimizer is a search strategy with its own assumptions about what to perturb and how to evaluate. Knowing the menu, and the cost versus power trade for each item, is the senior-level skill the question is testing.

This section walks the five optimizers in the question along the two axes that organize them (what they edit, how they search), then connects the strategy to the operational decision: when to use which, in what order, and what failure mode to watch for at each step.

The two axes that organize the menu

Every DSPy optimizer perturbs something and runs some search procedure over the perturbations. Those two axes, the what and the how, let you map any optimizer in the library to a slot in the design space.

The what axis has three positions: few-shot demonstrations (the examples shown to the model), the instruction string (the task description), or the model weights themselves. Demonstrations are the cheapest thing to edit because you can generate them with a teacher LM. Instructions are mid-cost because each edit needs evaluation but the candidate space is small. Weights are expensive because gradient updates need a full fine-tuning loop.

The how axis ranges from greedy bootstrap (collect candidates from a teacher, keep what scores) through random search (sample candidates uniformly), coordinate ascent (change one component at a time, keep wins), Bayesian optimization (model the response surface and propose promising candidates), to gradient descent (the fine-tune end of the spectrum). Each strategy trades sample efficiency for compute per round.

The two bootstrap optimizers. Demonstrations from a teacher

COPRO and MIPROv2. Instruction-aware optimizers

BootstrapFinetune. The outlier

Practical escalation order and failure modes to watch

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

import dspy
from dspy.teleprompt import BootstrapFewShot, BootstrapFewShotWithRandomSearch, COPRO, MIPROv2

class QA(dspy.Signature):
    """Answer the question concisely."""
    question: str = dspy.InputField()
    answer: str = dspy.OutputField()

program = dspy.ChainOfThought(QA)

def metric(example, pred, trace=None):
    return example.answer.lower() in pred.answer.lower()

# Cheap baseline: bootstrap a few demos from a teacher
compiled = BootstrapFewShot(metric=metric, max_bootstrapped_demos=4).compile(
    program, trainset=trainset
)

# Broader sweep: random search over candidate demo sets
compiled = BootstrapFewShotWithRandomSearch(metric=metric, num_candidate_programs=10).compile(
    program, trainset=trainset, valset=valset
)

# Instruction tuning: coordinate ascent
compiled = COPRO(metric=metric).compile(program, trainset=trainset, eval_kwargs={})

# Joint search: Bayesian over instructions and demos
compiled = MIPROv2(metric=metric, auto='medium').compile(
    program, trainset=trainset, valset=valset
)

Optimizer	What it edits	Search strategy	Cost
BootstrapFewShot	Few-shot demos	Greedy bootstrap from teacher	Low
BootstrapFewShotWithRandomSearch	Few-shot demos	Random search over candidate sets	Low to medium
COPRO	Instruction string	Coordinate ascent	Medium
MIPROv2	Instructions plus demos	Bayesian optimization	Medium to high
BootstrapFinetune	Model weights	Gradient updates on bootstrapped traces	High plus GPU time

Real products, models, and research that use this idea.

Stanford's STORM Wikipedia-generation system uses DSPy with MIPROv2 to tune its multi-stage pipeline
The DSPy documentation's benchmark notebooks consistently rank MIPROv2 above plain BootstrapFewShot on HotpotQA and MATH

What an interviewer would ask next. Try answering before peeking at the approach.

QWhen does using a stronger teacher than student matter most in BootstrapFewShot?

Whenever the student lacks a capability the teacher has. Multi-hop reasoning, structured output discipline, domain knowledge. The demos demonstrate the capability and the student learns the pattern. A weaker teacher caps what bootstrap can teach.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Conflating 'optimizer' in DSPy with 'optimizer' in deep learning. DSPy optimizers search over prompts and demos, not gradient updates (except BootstrapFinetune).

60 second bullets to scan on the way to the call.

The two axes that distinguish DSPy optimizers: what they edit and how they search
BootstrapFewShot mechanism and its dependence on a teacher LM

Primary sources. Browse if you want the original framing.