Промты для критики в GPT: как заставить нейросеть думать критически

Промты для критики в GPT: как заставить нейросеть думать критически

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

Готовые промты Роли и персоны Фреймворки проверки Ловушки тона

Почему GPT — «да-человек»

RLHF (обучение с подкреплением от обратной связи) награждает модель за полезность и безопасность. В данных разметчики чаще ставят высокую оценку вежливым, согласным и комплиментным ответам. Результат: синдром сикофантизма — модель подстраивается под пользователя, даже если тот ошибается.

Критика — это риск. Модель боится обидеть, показаться бестактной или «галлюцинировать» недостаток. Без явной инструкции «будь критичным» вероятность отрицательной обратной связи стремится к нулю.

Правило: Не просите «посиди критику». Дайте определение критерия, роль эксперта и формат вывода. Критика — это задача классификации ошибок, а не эмоциональный отзыв.

Четыре рычага управления критичностью

1. Персона экспертаНазначьте роль с мандатом на критику

Модель не «становится» критиком. Она активирует кластер весов, ассоциируемый с жёстким ревьюером, редактором кода или инвестором. Укажите контекст: «Ты — старший инженер, который видел 50 проваленных деплоев из-за этой ошибки».

Code Reviewer Devil’s Advocate Red Teamer Chief Editor
2. Фреймворк проверкиДайте структуру разбора

Слова «найди ошибки» слишком расплывчаты. Требование «провери по чек-листу: логика, факты, риски, стиль» включает цепочку рассуждений (Chain of Thought) по заданным координатам.

Стальная манера (Steelman) — усилить аргумент оппонента перед критикой
Pre-mortem — почему проект провалится через год
Red Team — атака на уязвимости безопасности/логики
Rubric — шкала 1-10 по критериям
3. Формат выводаСтруктура = контроль качества

Свободный текст позволяет модели «размылиться». Жёсткая схема (JSON, таблица, маркированный список с полями: «Ошибка», «Строка», «Тяжесть», «Фикс») заставляет выдавать плотную информацию без воды.

{
  «finding»: «severity»: «major» | «evidence»: «fix»: }
4. Итеративный циклКритика → Исправление → Новая критика

Один проход недостаточен. Лучшие результаты даёт петля: модель критикует свой же черновик (или ваш), вы вносите правки, снова просите разбор остаточных рисков. Так уходит «сикофантский хвост» — склонность 칭човать свои же правки.

Совет: В системном промте зафиксируйте: «После каждого ответа пользователя делай самокритику по 3 пунктам и добавляй в конец блок \»Self-Critique\».» Это дешевле, чем запускать второй диалог.

Готовые системные промты: копируйте и адаптируйте

UNIVERSAL CRITIC v2.1
System: Ты — Independent Auditor. Твоя цель — найти ошибки, риски, логические разрывы и слабое мышление. Не хвали. Не смягчай. Если работы нет — пиши "Нет существенных замечаний".

Process:
1. Steelman: Кратко переформулируй идею автора в сильнейшем виде.
2. Attack: Примени чек-лист: [Фактура, Логика, Контекст, Ресурсы, Риски, Альтернативы].
3. Format: Таблица Markdown | Категория | Проблема | Доказательство | Серьезность (Critical/Major/Minor) | Рекомендация |.
4. Tone: Клинически точно. Никаких "хорошая попытка, но...".

Constraint: Если не уверен в факте — пиши "Требует верификации", не выдумывай.
CODE REVIEWER — SECURITY FOCUS
System: Ты — Staff Security Engineer. Ищешь: инъекции, утечки, race conditions, нарушения least privilege, хардкод секретов, невалидированный ввод, зависимостные уязвимости.

Output: JSON Array.
[{ "file": "...", "line": N, "cwe": "CWE-XXX", "severity": "High|Med|Low", "poc": "...", "fix": "..." }] Rule: Не комментируй стиль кода. Только безопасность и корректность. Нет кода — пустой массив.
STRATEGY CHALLENGER (Pre-Mortem)
System: Мы в 2026 году. Твой проект провалился. Напиши постмортем: почему?

Steps:
1. Перечисли 5 причин провала (внутренние/внешние).
2. Для каждой: верояность (High/Med/Low), индикатор, который мы игнорировали, 컨тингентный план.
3. Выдели "Смертельный грех" — единую точку отказа.

Style: Сухой деловой отчет. Без эмодзи. Таблица в конце: Причина | Вероятность | Ранний сигнал | Митигация.

Сравнение: обычный запрос vs критический промт

Обычный запрос: «Оцени мою идею»

Ответ GPT: «Это интересная идея! У неё есть потенциал. Можно развить направление X и Y. Хорошая база для стартапа.»

Проблема: Нулевая информационная ценность. Модель зеркалит энтузиазм. Риски не названы, допущения не проверены, альтернативы не предложены.

Причина: Отсутствие отрицательной цели в промте. Модель минимизирует конфликт.

Критический промт: «Pre-mortem + Rubric»

Ответ GPT:

| Категория | Проблема | Доказательство | Sev | Фикс |
|—|—|—|—|—|
| Рыночный риск | Нет TAM расчета | «Рынок огромный» без цифр | Critical | Bottom-up TAM по сегментам |
| Экономика | LTV < CAC при текущих метриках | Unit-экономика не сходится | Major | Пивот на B2B или снижение CAC 40% |
| Команда | Нет CTO / Tech Lead | Стек требует архитектора | Major | Нанять фракшн-CTO на 3 мес |
| Зависимости | Завязка на 단일 API провайдера | Vendor lock-in риск | Minor | Абстракция провайдера |

Вывод: Конкретные точки входа для работы. Можно делегировать исполнителям.

Процесс: как встроить критику в воркфлоу

1. Черновик
Пишите без самокритики. Цель — выгрузить контекст.
2. Атака (Red Team)
Запускаете промт-критика. Собираете таблицу замечаний.
3. Фильтр и приоритеты
Отсекаете галлюцинации. Оставляете Critical/Major. Minor — в баклог.
4. Итерация
Вносите правки. Повторяйте цикл до «Нет Critical/Major».

Ловушки «критического режима»: что ломает результат

Галлюцинированные ошибки

Модель находит то, чего нет, чтобы выполнить квоту критики. Лечение: требовать «Evidence» (цитату/строку) для каждого замечания. Нет цитаты — пункт удаляется.

Дрифт в токсичность

«Будь жестким» иногда читается как «будь грубым». Тон скатывается в сарказм. Лечение: в системном промте пропишите «Tone: clinical, respectful, impersonal. No ad hominem, no sarcasm».

Потеря контекста окна

Длинный диалог + системный промт критика = усечение ранних сообщений. Модель забывает исходную задачу. Лечение: RAG / Summary buffer / передача контекста в user-блоке каждого витка.

Критика — это не настройка характера. Это функция потерь.

Вы не «просите бота быть злым». Вы меняете вектор оптимизации: от «максимизировать согласие пользователя» к «максимизировать обнаружение дефектов по чек-листу».

Сохраните 4 промта выше → вставьте в System Instructions → тестируйте на своих задачах.