Rephrase and Respond (RaR)

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

RaR особенно полезен, когда:

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

Сначала коротко перефразируй задачу, чтобы убедиться, что ты понял её правильно. Потом ответь.

Вопрос: «Как нам сократить отток, не снижая цены и не нанимая новую команду поддержки?»

Что именно улучшает RaR

У модели есть типичная слабость: она может:

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

RaR вводит короткий промежуточный шаг:

1. Что именно меня просят сделать?
2. Какие есть ограничения?
3. Только потом — answer.

Этот дополнительный шаг особенно полезен на messy user inputs.

Два режима использования

На практике у RaR есть два нормальных режима:

1. visible rephrase
2. hidden rephrase

Visible rephrase

Модель показывает пользователю, как поняла задачу. Это полезно:

• в консультативных сценариях;
• в совместной работе;
• в support;
• в аналитических workflow.

Hidden rephrase

Модель делает internal paraphrase step и потом отдаёт только финальный answer. Это удобно:

• в automation;
• в latency-sensitive flows;
• в customer-facing UX, где лишний шаг мешает.

Почему техника часто полезнее, чем кажется

RaR выглядит слишком простой, поэтому её легко недооценить. Но в реальных системах много ошибок происходит не на reasoning-слое, а раньше:

• модель неверно поняла объект вопроса;
• потеряла отрицание;
• схлопнула два ограничения в одно;
• ответила на "похожий" intent.

В таких сценариях даже сильная reasoning-модель может работать плохо, потому что решает уже неправильно сформулированную задачу. RaR полезен именно как дешёвый guardrail на уровне понимания входа.

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

• support tickets;
• messy business requests;
• prompts с несколькими ограничениями;
• due diligence questions;
• internal ops prompts;
• tasks, где вопрос сформулирован человеком, а не машиной.

Практически это хороший route для human-written messy inputs и заметно менее полезный route для already structured machine inputs.

Где с техникой надо быть осторожным

Не стоит blindly использовать RaR, если:

• wording itself legally sensitive;
• нужно строго отвечать по оригинальной формулировке;
• у задачи already precise schema input;
• перефразировка может потерять терминологические нюансы.

Тогда лучше не paraphrase, а extract constraints явно.

Когда лучше эскалировать дальше

Если одного rephrase недостаточно, следующий шаг обычно такой:

• Re-Reading, если проблема в пропущенной формулировке;
• Step-Back, если вопрос требует сначала общих принципов;
• Structured extraction, если нужно не paraphrase, а формально собрать constraints;
• clarifying question, если неоднозначность нельзя снять внутренней перефразировкой.

Когда нужно задавать вопрос пользователю, а не делать RaR

У RaR есть важное ограничение: он не устраняет реальную неопределённость, а только помогает аккуратно интерпретировать уже имеющийся input. Поэтому технику не стоит путать с настоящим clarification flow.

Лучше задавать уточняющий вопрос, если:

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

Хорошее practical правило: если ambiguity можно снять одной короткой faithful rephrase, RaR уместен. Если ambiguity требует выбора между вариантами мира, нужен уже не paraphrase, а clarifying question.

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

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

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

• rephrase становится длиннее исходного вопроса;
• техника используется на любой задаче подряд;
• rephrase смешивается с answer;
• paraphrase теряет одно из ограничений.

Что считать хорошей переформулировкой

Хорошая rephrase:

• короче исходного запроса;
• сохраняет objective;
• явно перечисляет ограничения;
• не добавляет новых смыслов.

Плохая rephrase:

• интерпретирует вопрос вместо уточнения;
• заменяет термины на более общие;
• уже подталкивает к конкретному ответу;
• теряет важную оговорку.

Practical implementation

prompt = """
Сначала сформулируй задачу в одном предложении:
- что нужно сделать
- какие есть ограничения

Затем дай ответ.
"""

Хорошие guardrails

• ограничьте rephrase одной строкой;
• не просите переписывать весь ввод;
• в structured workflows отделяйте rephrased_task от final_answer;
• не давайте rephrase менять objective задачи.

Что полезно мерить

На eval можно смотреть:

• intent mismatch rate;
• missed-constraint rate;
• overall answer correctness;
• paraphrase fidelity.

Так видно, помогает ли техника реально, а не просто удлиняет ответы.

Production-pattern

В проде RaR особенно хорошо работает как лёгкий pre-processing layer:

• input -> short rephrase -> main answer route

Это полезно тем, что route уже получает более чистую постановку задачи, а не noisy raw prompt.

Простая routing-эвристика

def should_use_rar(message: str) -> bool:
    signals = [
        len(message) > 180,
        "не" in message,
        "без" in message,
        message.count(",") >= 3,
        "но" in message or "однако" in message,
    ]
    return sum(bool(x) for x in signals) >= 2

Это не академическая логика, а практический фильтр: RaR особенно полезен на шумных human-written inputs, но не нужен на коротких и already structured запросах.