Нейросеть редко выдаёт лучший ответ с первого раза. Если попросить её отдельным сообщением проверить и раскритиковать собственный результат, а затем доработать его по замечаниям, качество заметно растёт. Ниже — как это делать по шагам.
Зачем просить модель проверять себя, если она и так старается
Первый ответ модель строит как наиболее вероятное продолжение запроса, а не как результат вдумчивой работы над задачей. Она не знает, что именно для вас важно: точность формулировки, полнота аргументов или соответствие формату. Поэтому черновик почти всегда содержит пропуски, обобщения и места, где уверенный тон скрывает слабую опору на факты.
Отдельный запрос на проверку меняет саму рамку работы. Когда модель просят оценить готовый текст по заданным критериям, она переключается с порождения на разбор и замечает то, что при генерации пропустила. Разделение создания и оценки на два шага даёт прирост даже без смены модели и без дополнительных данных.
- Черновик закрывает запрос формально, а проверка выявляет, где ответ расходится с задачей.
- Критика вытаскивает на поверхность допущения, которые модель не проговорила.
- Повторное обращение к тому же материалу позволяет найти противоречия между частями ответа.
- Явные критерии проверки заставляют модель сверяться с ними, а не с общими представлениями о хорошем тексте.
Практическая выгода не в том, что модель «старается сильнее», а в том, что вы получаете список конкретных правок. С ним доработка идёт быстрее, чем при попытке переписать всё с нуля. Проверка также показывает, каких сведений не хватает, и вы успеваете добавить их до финальной версии.
Базовый цикл: ответ, критика, правка, повторная проверка
Итеративное улучшение строится на повторяющемся цикле из четырёх шагов, и каждый следующий виток опирается на результат предыдущего. Сначала модель выдаёт черновой ответ на исходную задачу. Затем вы просите её оценить этот ответ по заданным критериям и указать слабые места. После этого она переписывает проблемные фрагменты с учётом замечаний. Завершает цикл повторная проверка уже исправленного текста.
- Ответ. Модель решает задачу так, как поняла её с первого раза. Это исходная точка, от которой дальше строится вся работа.
- Критика. Отдельным сообщением вы просите найти ошибки, пробелы и места, где ответ не соответствует требованиям. На этом шаге важно получить конкретные замечания, а не общую оценку «всё хорошо».
- Правка. Модель дорабатывает ответ по списку замечаний, сохраняя то, что уже было верно. Цель — точечные изменения, а не новый текст с нуля.
- Повторная проверка. Исправленный вариант снова оценивается по тем же критериям. Это показывает, закрыты ли замечания и не появились ли новые.
Смысл каждого шага в том, что он отделяет поиск проблем от их устранения. Когда модель критикует и правит одновременно, она склонна защищать собственный текст и пропускает слабые места. Разнесённые по разным сообщениям этапы заставляют её смотреть на результат со стороны.
Повторная проверка нужна не для формальности. Правка часто вносит новые неточности или ломает то, что раньше работало, поэтому финальный просмотр по тем же критериям отсекает регрессии. Цикл можно повторять, пока замечания не станут несущественными.
Как формулировать запрос на критику: роли, критерии, ограничения
Роль ревьюера и почему она меняет тон ответа
Если попросить модель «проверь ответ», она часто отвечает в духе «всё в порядке». Другое дело — заранее назначить ей роль строгого ревьюера, который ищет слабые места. Формулировка роли задаёт установку: не подтверждать, а оспаривать.
Работают такие начала запроса:
- «Выступи в роли редактора, который обязан найти минимум три слабых места в тексте выше».
- «Представь, что ты рецензент и твоя задача — отклонить этот ответ, если найдёшь ошибки».
- «Ты проверяющий: не переписывай, а перечисли претензии по пунктам».
Роль задаёт и тон, и структуру: ревьюер говорит замечаниями, а не готовым текстом. Это удерживает модель от соблазна сразу выдать новый вариант.
Критерии проверки: что именно просить искать
Без критериев критика расплывается. Перечисляйте в запросе, что проверять: факты, логику, полноту, соответствие ограничениям. Чем конкретнее список, тем полезнее замечания.
Проверь ответ выше по пунктам:
1. Есть ли фактические ошибки или неподтверждённые утверждения?
2. Не пропущены ли важные шаги или условия задачи?
3. Соблюдены ли ограничения: объём, формат, тон?
По каждому пункту — конкретная претензия и цитата из ответа.Добавляйте ограничения на формат критики: «только список замечаний», «без похвалы», «не более пяти пунктов». Так ответ ревьюера остаётся рабочим материалом, а не размышлением о качестве.
Критерии проверки под разные задачи: текст, код, расчёты, план
Одна и та же просьба «проверь себя» даёт разный результат в зависимости от того, что именно проверяется. Для связного текста важна логика и точность формулировок, для кода — работоспособность и обработка краевых случаев, для расчётов — сходимость цифр и единицы измерения, для плана — реалистичность шагов и зависимостей между ними. Если критерии не заданы, модель проверяет то, что ей удобнее, и часто пропускает слабые места.
Практический приём — заранее выписать 3-5 пунктов, по которым вы сами будете принимать результат, и передать их как рамку проверки. Ниже — ориентировочный набор критериев по типам задач; его можно сокращать или дополнять под конкретный случай.
| Тип задачи | Что проверять в первую очередь | Частая слабость ответа |
|---|---|---|
| Текст | Логика абзацев, соответствие фактов, отсутствие повторов | Общие фразы вместо конкретики |
| Код | Работоспособность, краевые случаи, читаемость | Необработанные исключения и пустые входные данные |
| Расчёты | Единицы измерения, порядок величин, сходимость | Потерянные допущения и округления |
| План | Последовательность шагов, зависимости, сроки | Пропущенные подготовительные этапы |
Критерии стоит формулировать как проверяемые утверждения, а не как пожелания: «в ответе нет чисел без единиц измерения» проверить проще, чем «ответ должен быть аккуратным». Для смешанных задач (например, отчёт с таблицей и выводами) берите по два-три пункта из каждой категории.
Если критериев слишком много, модель распределяет внимание поверхностно и подтверждает всё подряд. Три-пять конкретных пунктов работают надёжнее длинного списка общих требований.
Как просить доработать ответ по замечаниям, а не переписать заново
Правка — это отдельный запрос, в котором модель получает свой прежний ответ и список замечаний к нему. Переписывать всё заново не нужно: задача в том, чтобы исправить конкретные места и сохранить то, что уже работает. Такой подход экономит контекст и не даёт модели потерять удачные формулировки или рабочие фрагменты.
Соберите критику в один блок и передайте её вместе с исходным текстом. Полезно явно указать, какие замечания принимаются, а какие вы решили отклонить, — иначе модель начнёт править всё подряд.
- Вставьте исходный ответ целиком, чтобы модель видела контекст правок.
- Перечислите замечания по пунктам, каждое — с указанием места, к которому оно относится.
- Отдельно отметьте, что менять не нужно, даже если критика это затрагивала.
- Попросите показать только изменённые фрагменты и коротко объяснить каждую правку.
Формулировка запроса может звучать так: «Ниже мой ответ и список замечаний. Исправь только те места, которых касаются принятые пункты, остальное оставь без изменений. Покажи, что именно поменял и почему».
Точечная правка удобнее полной переписки: видно, что изменилось, и легче откатить неудачное исправление. Если замечаний много и они затрагивают разные части текста, разумнее разбить правку на несколько проходов.
Типичные ошибки при самопроверке и как их обойти
Даже при аккуратно выстроенном цикле итерация часто пробуксовывает из-за нескольких повторяющихся промахов. Они не связаны с моделью напрямую — их легко допустить в формулировках запроса.
- Слишком общая критика. Просьба «найди недостатки» возвращает расплывчатые замечания вроде «можно точнее». Модель не знает, что именно проверять, и выдаёт поверхностный разбор. Помогает сузить фокус до конкретного фрагмента или аспекта.
- Согласие со всем. На вопрос «всё ли верно?» модель склонна подтверждать собственный ответ. Чтобы сдвинуть её с этой позиции, стоит заранее допустить наличие ошибки и попросить её найти, а не оценивать общее качество.
- Потеря исходной задачи. К третьему кругу правок модель начинает оптимизировать текст под замечания и забывает первоначальную цель. Исходный запрос и требования нужно возвращать в каждом сообщении.
- Правка вместо переработки. Если критика касается сути, а не формулировок, косметические изменения не помогут — нужно пересобрать аргумент, а не подшлифовать фразы.
- Раздувание объёма. Каждая итерация добавляет оговорки и уточнения, и ответ расползается. Полезно держать ограничение по длине и явно просить сокращать, а не дополнять.
Обойти эти ловушки проще, если задавать критику как конкретную задачу с чётким объектом проверки. Тогда замечания становятся пригодными для правки, а не превращаются в вежливое одобрение.
Короткий чек-лист итерации промпта для начинающих
Перед каждой задачей пройдитесь по одному и тому же короткому списку — он экономит время и убирает хаос из диалога с моделью.
- Сформулируйте задачу и критерии заранее. Скажите, что именно считаете хорошим результатом: длину, формат, точность, стиль.
- Попросите первый ответ. Не правьте его сразу — дайте модели выдать черновик целиком.
- Отдельным сообщением закажите критику. Укажите роль (редактор, проверяющий) и ограничения: что нельзя менять, что обязательно проверить.
- Сверьте замечания со своими критериями. Отбросьте придирки, которые не относятся к делу, оставьте то, что действительно влияет на результат.
- Попросите доработку по списку замечаний. Явно скажите: правь пункты, а не переписывай всё заново.
- Проверьте правку повторно. Задайте тот же вопрос о слабых местах — так видно, что исправлено, а что осталось.
- Остановитесь, когда замечания повторяются. Если критика ходит по кругу, дальше итерации не улучшают ответ, а только тратят время.
Держите этот порядок под рукой и не пропускайте шаг с критикой: именно он чаще всего выпадает, когда хочется побыстрее получить готовый текст.
Один и тот же короткий цикл — черновик, разбор, правка, повторная проверка — работает надёжнее, чем попытки угадать идеальную формулировку с первого раза.
Частые вопросы
Сколько раз подряд стоит просить модель проверить себя?
Обычно хватает двух-трёх циклов. После третьего правки прирост становится небольшим, а модель начинает переписывать текст без пользы. Если задача сложная, лучше уточнить исходные данные, чем гонять цикл дальше.
Модель всегда говорит, что её ответ хороший. Что делать?
Дайте ей роль строгого ревьюера и явно попросите найти минимум три слабых места. Можно также попросить оценить ответ по конкретным критериям и указать, что именно не соответствует каждому из них.
Можно ли совместить критику и правку в одном сообщении?
Можно, но результат обычно хуже: модель смешивает анализ и переписывание. Разделение на два шага — сначала критика, потом правка по списку замечаний — даёт более предсказуемый результат.
Что делать, если после правки ответ стал хуже?
Вернитесь к предыдущей версии и уточните замечания: какие именно правки нужно внести, а что оставить без изменений. Полезно явно указать, какие части ответа менять не надо.
Помогает ли самопроверка, если задача простая?
Для коротких фактических вопросов прирост небольшой. Техника заметнее работает там, где ответ длинный или многосоставный: тексты, планы, разборы, инструкции.
Нужно ли сохранять промежуточные версии ответа?
Да, это помогает сравнивать и откатываться. Если интерфейс не хранит историю, копируйте версии в отдельный документ — так видно, что именно изменилось после каждой итерации.