Re-Reading (Re2)

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

Re-Reading особенно полезен, когда:

• вопрос длинный или шумный;
• есть числа, даты, лимиты, исключения;
• модель часто цепляется за первый поверхностный паттерн;
• ошибка возникает не из-за незнания, а из-за misread.

Типичные кейсы:

• pricing и финрасчёты;
• judge prompts;
• eval pipelines;
• длинные инструкции;
• QA по документам;
• compliance/ops prompts с множеством ограничений.

Сначала перечитай вопрос ещё раз и отдельно проверь числа, единицы и ограничения. Потом ответь.

Вопрос: у продукта 12 000 MAU, churn 4% в месяц и нет новых пользователей. Сколько MAU останется примерно через 2 месяца?

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

Многие ошибки модели не являются "глубокими". Они возникают потому, что модель:

• слишком рано решила, о чём вопрос;
• не заметила одно ограничение;
• пропустила отрицание;
• перепутала числа, единицы или даты;
• не учла второе условие в длинном вводе.

Re-Reading не лечит reasoning целиком, но полезен там, где проблема именно во вторичном внимании к входу.

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

Хорошие кандидаты:

• judge prompts с длинными rubric;
• legal / compliance summaries;
• pricing calculators;
• support triage по большому описанию кейса;
• аналитические промпты, где важны точные формулировки ограничений;
• prompts с "не делай X, кроме случаев Y".

Почему техника полезна именно как дешёвый second-pass

Re-Reading интересен тем, что закрывает очень частую, но скучную проблему: модель уже умеет решать задачу, но не дочитывает её до конца. Это не вопрос знаний и не вопрос сложного reasoning, а вопрос prompt attention hygiene.

Именно поэтому техника часто даёт хороший ROI:

• почти ничего не стоит;
• не требует orchestration;
• особенно заметна там, где много условий, исключений и numeric details.

Менее полезна техника:

• в brainstorming;
• в creative writing;
• в коротких бытовых вопросах;
• там, где ошибка идёт от фактического незнания.

Практически это значит: Re-Reading полезен там, где downstream already competent, но регулярно спотыкается о wording and constraints.

Хорошая формулировка техники

Полезный Re-Reading почти всегда конкретен. Не просто:

Ещё раз перечитай.

А скорее:

Сначала внимательно перечитай условие.
Отдельно проверь:
- числа
- даты
- единицы измерения
- ограничения
- исключения
Только потом отвечай.

Это важно, потому что техника лучше работает не как ритуал, а как короткий checklist.

Что особенно стоит перечитывать

Наиболее полезные зоны повторной проверки:

• отрицания;
• временные ограничения;
• units и currencies;
• "только если / кроме / не ранее чем";
• границы задачи и requested output.

Именно на этих местах модель чаще всего делает surface-level errors, которые выглядят как reasoning failure, хотя по сути это просто misread.

Как сочетать с другими техниками

Re-Reading хорошо комбинируется с:

• CoT, если модель часто пропускает одно условие в начале;
• RaR, если вопрос двусмысленный;
• Structured Output, если перед финальным JSON надо ещё раз проверить ограничения;
• Self-Consistency, если хотите снизить шум до запуска более дорогой verification.

Но он не заменяет:

• retrieval;
• tool use;
• explicit decomposition;
• app-side validation.

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

Ещё частые проблемы:

• модель перечитывает, но не проверяет, что именно важно;
• Re-Reading используется вместо нормальной task framing;
• его включают там, где нужно было бы сделать tool-based validation;
• финальный answer всё равно не отделён от reasoning.

Когда лучше выбрать другую технику

Если проблема не в reading, а в:

• двусмысленности вопроса -> Rephrase and Respond;
• noisy emotional input -> System 2 Attention;
• нехватке фактов -> retrieval or tools;
• слабом reasoning path -> CoT / decomposition / verification,

то один Re-Reading ситуацию почти не изменит.

Practical use

Базовый prompt pattern

def reread_prompt(task: str) -> str:
    return (
        "Сначала перечитай условие ещё раз. "
        "Отдельно проверь числа, даты, ограничения и исключения. "
        "Только после этого дай финальный answer.\n\n"
        f"{task}"
    )

Где добавлять технику

Имеет смысл включать её:

• в judge/eval pipelines;
• в prompts с numeric constraints;
• в workflows, где модель читает длинный rubric;
• в pre-final step перед выдачей structured answer.

Когда не надо

Не стоит blindly включать Re-Reading:

• в каждый чат;
• в каждый short answer;
• в automation, где уже есть кодовая валидация чисел и ограничений.

Что мерить

Если вы тестируете технику, полезно смотреть:

• constraint violation rate;
• numeric error rate;
• missed-condition rate;
• overall accuracy на long/complex prompts.

Именно эти метрики чаще всего и показывают, есть ли у Re-Reading реальный ROI.

Production pattern

Техника особенно хорошо работает как pre-final check:

• solve -> reread constraints -> final answer

Это полезно в judge pipelines, structured extraction перед финальным JSON и задачах с business rules, где важно не пропустить одно короткое исключение.