Automated Prompt Optimization

35.1 The Idea #

Given an eval set and a metric, prompt optimization treats the prompt as a parameter and searches over it. Variants include instruction rewriting, example selection, and joint optimization of both.

The approaches in practical use:

Provider tooling now exists for the first two on the major platforms, and open-source frameworks cover the rest.⁶⁷

35.2 What It Is Good At #

35.3 What It Is Bad At #

35.4 Doing It Safely #

import random

def split(cases, seed=42):
    """Three-way split. The test set is touched once, at the end."""
    rng = random.Random(seed)
    shuffled = cases[:]
    rng.shuffle(shuffled)
    n = len(shuffled)
    return (shuffled[:int(0.6*n)],                    # train — optimizer sees this
            shuffled[int(0.6*n):int(0.8*n)],          # dev   — model selection
            shuffled[int(0.8*n):])                    # test  — final only, once

def optimize(candidates, train, dev, evaluate, shortlist=5):
    scored = [(evaluate(c, train)["mean"], c) for c in candidates]
    scored.sort(reverse=True, key=lambda x: x[0])

    # Train narrows the field; dev picks the winner. Both steps earn their
    # place: taking the max over dev across every candidate overfits dev in
    # proportion to the number tried, which is the same failure one set later.
    best = max(scored[:shortlist], key=lambda sc: evaluate(sc[1], dev)["mean"])[1]
    return best

Report the test score, not the training score. A gap between dev and test is the signal to investigate, though “a few points” is not by itself a diagnosis: a 60/20/20 split of thirty to fifty cases leaves six to ten test cases, where a single outcome moves the score by ten to seventeen points. Size the gap against that arithmetic, check that the test set is representative rather than merely held out, and count how many candidates dev chose among—selection pressure on dev is the same failure one set later. Do not ship on a gap you cannot distinguish from sampling noise, and do not treat a small one as evidence that you are safe.

Three further disciplines: keep the human-written version as a baseline and require the optimized version to beat it on test; cap the search budget before you start, since the cost is unbounded and the returns are not; and check the optimized prompt for adversarial robustness separately because optimizers routinely discover phrasings that score well and are fragile.

35.5 The Narrow Productive Band #

Automated optimization is a useful tool, though it operates within a narrow productive band. It works when you have a well-defined metric, a genuinely representative eval set, and a prompt that has already been hand-tuned to a plateau.

Reaching for it before you hold those three merely automates your way past the thinking that would have produced the improvement. The foremost gains—supplying an oracle, fixing the context assembly, clearing context at the right moment—are not in the search space of a prompt optimizer, because they are changes to the harness rather than to the text it searches. Cutting the instruction file is the one item on that list that is reachable: once loaded, the file’s content is prompt instructions like any other, and optimizers do search instruction text rather than demonstrations alone—DSPy’s COPRO generates and refines instructions under coordinate ascent, and MIPROv2 proposes instructions and examples together. Whether yours can cut it is a question of whether that text is exposed to the optimizer as a parameter, not of what category the text belongs to.