OPRO (Optimization by PROmpting)

Суть в двух словах

OPRO особенно полезен там, где:

• есть фиксированная задача;
• есть eval-набор;
• качество можно измерить автоматически;
• хочется искать improvements системно, а не "на глаз".

Сгенерируй новый вариант prompt для классификации support tickets, учитывая историю предыдущих prompt -> score результатов.

Из чего состоит OPRO-loop

Практически useful OPRO почти всегда выглядит так:

1. candidate generation
2. scoring
3. history conditioning
4. selection
5. repeat

То есть prompt engineering превращается в search problem, а не в ручную редактуру по интуиции.

Что OPRO даёт на практике

Почему OPRO важен не как paper-trick, а как process discipline

В командах prompt iteration часто происходит так:

• кто-то меняет wording;
• все смотрят на 3-5 примеров;
• делается вывод "кажется стало лучше".

OPRO важен тем, что переводит эту работу в нормальный optimization loop с историей кандидатов, score и воспроизводимостью. Даже если сама модель-оптимизатор не идеальна, процесс становится заметно дисциплинированнее.

Почему OPRO важен именно как процесс

Главная ценность OPRO сегодня не в paper-style novelty, а в дисциплине:

prompt candidate -> eval -> score -> mutate -> re-eval

Если у вас нет:

• стабильного eval set;
• понятного scorer;
• критерия успеха;
• holdout-проверки,

то OPRO быстро превращается в шумный перебор красивых формулировок.

Где техника особенно уместна

Хорошие кейсы:

• классификация;
• extraction;
• rubric-driven judging;
• повторяющиеся internal tasks;
• prompt registry optimization;
• benchmark-style task families.

Менее полезен OPRO:

• в уникальных open-ended workflows;
• в единичных ad hoc prompts;
• там, где score нельзя формализовать;
• там, где problem definition ещё не стабилизирована.

Когда OPRO особенно полезен команде

Техника окупается, если:

• один и тот же prompt влияет на большой объём трафика;
• есть повторяемый eval workload;
• ручная iteration уже стала бутылочным горлышком;
• есть желание хранить prompt R&D как историю экспериментов, а не как набор случайных правок.

Что именно можно оптимизировать

Полезно помнить, что OPRO не обязан менять весь prompt целиком. Часто выгоднее ограничить search space:

• только system instruction;
• только rubric section;
• только examples block;
• только formatting constraints;
• только refusal / abstain guidance.

Чем уже и понятнее область мутаций, тем легче интерпретировать результат. Если разрешить оптимизатору переписывать всё подряд, хорошие кандидаты сложнее объяснить, а плохие труднее отладить.

Что чаще всего ломает OPRO

Самые типичные проблемы:

• overfitting под маленький eval set;
• один шумный scorer;
• использование только одной метрики;
• отсутствие holdout;
• генерация кандидатов без history constraints;
• выбор prompt only by score without robustness check.

Практический anti-pattern

Сравнение с соседними техниками

Псевдокод

def opro_loop(seed_prompt, optimizer_model, scorer, iterations=10):
    history = []
    best = seed_prompt
    best_score = scorer(best)

    for _ in range(iterations):
        candidate = optimizer_model.generate(best, history)
        score = scorer(candidate)
        history.append({"prompt": candidate, "score": score})

        if score > best_score:
            best = candidate
            best_score = score

    return best, history

Practical guardrails

• держите отдельный holdout eval set;
• не доверяйте одному scorer;
• проверяйте prompt не только на score, но и на robustness;
• смотрите на latency и cost, а не только на качество;
• сохраняйте историю кандидатов как experiment artifact.

Когда iteration loop пора остановить

def should_stop(best_gain, rounds_without_gain, robustness_drop):
    if robustness_drop:
        return True
    if best_gain < 0.01 and rounds_without_gain >= 3:
        return True
    return False

Stop rule в OPRO нужен не меньше, чем сам optimizer. Без него цикл легко продолжает шлифовать wording уже после того, как полезный signal закончился.

Что хранить как experiment artifact

Полезно сохранять:

• seed prompt;
• все candidate prompts;
• scorer outputs;
• holdout results;
• winner prompt with rationale;
• дату и версию модели-оптимизатора.

Так OPRO становится не магией, а обычным инженерным экспериментом.

Как использовать в 2026 разумно

Лучший practical use:

• seed prompt уже более-менее рабочий;
• есть понятная метрика;
• есть стабильный набор задач;
• optimization loop запускается offline;
• человек всё равно ревьюит победивший prompt.

То есть OPRO чаще нужен не в runtime, а в prompt R&D loop.

Как понять, что OPRO уже пора выключать

Если iteration loop даёт:

• минимальные улучшения;
• нестабильные победители;
• рост token cost без business gain;
• prompts, которые хуже переносятся на holdout,

значит текущий prompt-space почти исчерпан и стоит менять не wording, а architecture: examples, retrieval, tool use или routing.