Self-Refine

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

Self-Refine лучше всего работает там, где черновик действительно поддаётся улучшению:

• тексты;
• письма;
• статьи и memo;
• код;
• аналитические ответы;
• summaries и plans.

Шаг 1: напиши черновик executive summary.
Шаг 2: покритикуй его по критериям clarity, missing risks, actionability.
Шаг 3: перепиши итоговую версию.

Self-Refine особенно полезен тогда, когда проблема не в нехватке знаний, а в качестве первой формулировки.

Почему техника работает

Single-pass generation часто страдает от типовых проблем:

• ответ слишком общий;
• модель забывает ограничение по длине;
• пропускает один важный аспект;
• плохо структурирует вывод;
• пишет приемлемо, но не наилучшим образом.

Self-Refine полезен тем, что даёт модели второй шанс, но не в режиме "просто попробуй ещё раз", а через явную критику по критериям.

Главная сила техники в разделении ролей:

• author генерирует draft;
• critic ищет слабые места;
• editor делает controlled revision.

Это заметно лучше, чем единая расплывчатая инструкция "улучши ответ", потому что она делает improvement targeted, а не косметическим.

Главный принцип: critique должен быть rubric-based

Плохой вариант:

• "проверь и улучши ответ".

Хороший вариант:

• "оцени ответ по критериям: factuality, clarity, missing assumptions, actionable next step, tone".

Чем конкретнее рамка критики, тем полезнее и стабильнее refinement.

Когда Self-Refine особенно полезен

Лучшие сценарии:

• customer emails;
• product memos;
• code review comments;
• docs rewriting;
• SQL / code cleanup;
• structured plans and summaries.

Где техника слабее

Self-Refine не лучший выбор, если:

• проблема в нехватке знаний, а не в качестве формулировки;
• ответ должен опираться на внешние данные -> нужен RAG или CoVe;
• нужен строгий schema output -> нужен structured outputs;
• ошибка не в самом тексте, а в underlying reasoning path -> лучше Factored Verification или Self-Consistency.

Проще говоря: Self-Refine отлично шлифует ответ, но плохо исправляет фундаментально неверную epistemic base.

Полезный production-паттерн

Обычно лучший режим — это не бесконечный refine-loop, а всего 1-2 прохода:

В большинстве практических систем один critique-pass уже даёт основную пользу. Третий и четвёртый проходы обычно приносят мало качества и много cost.

Примеры

Self-Refine для письма

Напиши письмо клиенту о переносе релиза.

Потом оцени письмо по критериям: ясность, ответственность, отсутствие лишней обороны, конкретный next step.

Перепиши финальную версию.

Self-Refine для кода

Шаг 1: предложи исправление race condition.
Шаг 2: сам проверь решение по критериям correctness, simplicity, side effects.
Шаг 3: перепиши исправленную версию.

Self-Refine для анализа

Сделай product memo. Затем покритикуй его по критериям: missing risks, unsupported assumptions, weak next step. Потом перепиши финальную версию.

Anti-patterns

Частые ошибки:

1. Слишком общий critique prompt.
2. Слишком много refine-итераций.
3. Отсутствие stop rule.
4. Попытка через refinement исправить knowledge gap.
5. Переписывание удачного ответа просто ради "второго прохода".

Отдельный риск — over-editing. Модель начинает шлифовать стиль и теряет полезную конкретику, которая была в draft.

Как понять, что refine-pass действительно полезен

Self-Refine хорошо измеряется не по ощущению "текст стал глаже", а по более прикладным сигналам:

• уменьшается число human edits после первого черновика;
• растёт rubric score по clarity / completeness / actionability;
• снижается доля missed constraints;
• финальный ответ реже уходит на ручной rewrite.

Если после refine-pass ответы становятся только длиннее, но не уменьшают число правок, значит цикл либо плохо спроектирован, либо в этой задаче он просто не нужен.

Когда revision лучше отклонить

Иногда лучшая стратегия — сохранить draft и не принимать revised version. Это особенно важно, когда:

• revision добавил неподтверждённые детали;
• текст стал менее конкретным;
• исчезли полезные ограничения или disclaimers;
• стиль улучшился, но factual safety просела.

В production полезно сравнивать draft и revision отдельным lightweight judge или human spot-check. Self-Refine не обязан автоматически принимать вторую версию только потому, что она "финальная".

Техническая реализация

draft = model(task)
critique = model(
    "Оцени черновик по rubric: clarity, correctness, completeness, constraint adherence\n\n"
    + draft
)
revision = model(
    "Перепиши ответ с учётом критики ниже. Не теряй сильные части черновика.\n\n"
    + critique
)

Хороший critique prompt

critique_prompt = """
Оцени черновик по критериям:
1. factual correctness
2. missing key points
3. clarity
4. constraint adherence
5. actionability

Для каждого критерия:
- verdict
- issue
- concrete fix
"""

Чем более actionable critique, тем качественнее revision.

Stop rule

def should_refine_more(score_delta: float, iterations: int) -> bool:
    return score_delta > 0.05 and iterations < 2

Даже грубая stop logic лучше бесконечного "улучши ещё раз".

Что логировать

• draft;
• critique;
• revised answer;
• delta between versions;
• human preference or evaluator score.

Это помогает понять, где refinement действительно работает, а где просто тратит токены.

Практические улучшения

• задавайте явный rubric;
• ограничивайте число refine-проходов;
• храните draft и critique в traces для отладки;
• на high-stakes задачах не полагайтесь только на self-critique, добавляйте внешний evaluator.
• если revision идёт в прод, отдельно меряйте accept rate revised vs original.

Частая ошибка