Foxhunter X

ChatGPT оценивает тексты по красоте, а не по сути. Три добавки в промпт делают из него честного судью

2026-09-15T10:00:17.762Z

Просил когда-нибудь ChatGPT оценить свой текст — пост, письмо, ответ клиенту? Он почти всегда доволен: «структура чёткая, тон профессиональный». Проблема в том, что хвалит он гладкость формулировок, а не пользу. Seungheon Doh, Bruno Sguerra и коллеги (июль 2026) устроили LLM-судьям экзамен: 20 экспертов вручную оценили 80 ответов, и эти оценки сравнили с оценками моделей. Выяснилось: на прямую манипуляцию «поставь мне 5/5» судья не ведётся, а вот на красивые обороты — легко. И это чинится тремя добавками в промпт: контекст, критерии, примеры.

В чём проблема: у судьи нет определения «хорошо» — и он оценивает то, что видно

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

Решение: дай судье контекст, рубрику и примеры

Вместо «оцени текст» собери промпт из четырёх частей: контекст (что за задача и что человек просил — история переписки), рубрика — конкретные критерии по шкале 1–5, один-два контрастных примера «вот это 5, вот это 1» для калибровки и прямая инструкция «оценивай суть, игнорируй красивость». Самый большой прирост точности даёт история диалога: без неё судья не знает, что человек просил, поэтому оценка выходит почти случайной. Примеры-эталоны сильнее всего помогают, когда оцениваешь не «подходит ли ответ», а «убедительно ли он объяснён».

→ Что делать: оценивай тексты этим шаблоном:

Ты — эксперт-оценщик, который проверяет качество {тип_ответа}
по объективным критериям.

КОНТЕКСТ:
История переписки/диалога: {история}
Профиль/ситуация человека: {профиль}
Текущий запрос: {запрос}

ОТВЕТ ДЛЯ ОЦЕНКИ:
{текст_ответа}

КРИТЕРИИ (шкала 1–5):
1. {критерий_1} — {что_это_значит}
2. {критерий_2} — {что_это_значит}

ПРИМЕРЫ ДЛЯ КАЛИБРОВКИ:
Оценка 5: {пример_хорошего_ответа}
Оценка 1: {пример_плохого_ответа}

ВАЖНО: оценивай только суть и содержание. Игнорируй длину
текста и красивость формулировок.

Выведи оценку по каждому критерию и короткое пояснение.

Почему это работает

Вопрос «оцени» не задаёт, что мерить, поэтому модель мерит то, что видно, — стиль. Гладкие уверенные тексты в её обучающих данных чаще получали одобрение людей, поэтому без других опор она принимает форму за качество. Контекст, рубрика и примеры заменяют угадывание сверкой. История переписки показывает, что человек просил, рубрика — что именно мерить, примеры задают планку для каждого балла — поэтому судья сравнивает ответ с задачей, а не с эстетикой. Честная оговорка: даже настроенный судья совпадает с людьми умеренно, не идеально. Это быстрый фильтр для сравнения вариантов, а финальное решение по важным текстам оставляй за собой.

Пример

Поддержка интернет-магазина: клиент пишет, что куртка не подошла по размеру. Бот сгенерировал три варианта ответа, нужно выбрать лучший — не «на глаз». Прогоняешь каждый через судью:

Ты — эксперт-оценщик качества ответов службы поддержки.
Оцени ответ по критериям ниже.

КОНТЕКСТ:
История переписки с клиентом: "Здравствуйте, заказал куртку M,
а она узкая в плечах. Хочу обмен на L или возврат денег."
Профиль клиента: постоянный покупатель, 4 заказа за год,
без возвратов ранее.

ОТВЕТ ДЛЯ ОЦЕНКИ:
"Приносим извинения за неудобства! Мы можем оформить обмен
на размер L — курьер заберёт куртку M в удобное для вас время
и привезёт L в течение 2-3 дней. Также доступен возврат средств
в течение 5 рабочих дней, если обмен не подходит.
Что вам удобнее?"

КРИТЕРИИ (шкала 1–5):
1. Персонализация — учитывает ли ответ статус клиента
и суть его проблемы
2. Обоснование — понятно ли объяснены следующие шаги и сроки

ПРИМЕРЫ ДЛЯ КАЛИБРОВКИ:
Оценка 5: ответ предлагает конкретное решение с чёткими
сроками, обращается к сути жалобы.
Оценка 1: общий шаблонный ответ без конкретики
("напишите нам подробнее").

ВАЖНО: оценивай только суть, а не длину или красивость
формулировок.

Выведи:
Персонализация: [1-5]
Обоснование: [1-5]
Пояснение оценки.

Судья выдаст по каждому варианту две оценки с коротким пояснением — почему именно такой балл. Три ответа получат сопоставимые баллы по одной шкале, а не субъективное «этот звучит приятнее». Тот же шаблон без переделки ложится на посты для канала и описания товаров — поменяй контекст и критерии.

Где пригодится

Выбрать лучший из вариантов, которые сгенерировал ИИ: пост, письмо, описание товара — по одной шкале, а не на глаз
Проверять ответы поддержки и письма клиентам до отправки — судья ловит «вежливо, но не по делу»
Сравнивать свои промпты между собой: прогони их результаты через одного судью с одной рубрикой
Правило: не отправляй судье голый текст — сначала задача и история, потом критерии, потом примеры

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «LLM-as-a-Judge for Evaluating System Responses in Conversational Music Recommendation» (arXiv 2607.25640).

ChatGPT молча принимает 3–4 решения за тебя в каждой задаче. Узнаёшь о них, когда что-то сломается

2026-09-12T10:00:16.613Z

Попросил модель написать функцию логина — получил код, тесты зелёные, всё выглядит готовым. А через месяц выясняется: пароли она защищает через MD5 — устаревший способ, который давно научились взламывать. Ты этого не выбирал. Модель решила сама — и не сказала. Исследователь из Мичиганского технологического университета Jie Wu (июль 2026) посчитал: в среднем модель принимает 3–4 таких скрытых решения на каждую задачу. И показал приём, который заставляет её выложить весь список — до того, как одно из решений выстрелит.

В чём проблема: короткий запрос скрывает десятки вопросов — и модель отвечает на них молча

Твой запрос короткий: «напиши функцию логина», «сделай парсер отзывов». Но внутри задачи спрятаны вопросы, которые ты не оговорил: как защищать пароль, что вернуть при ошибке, что делать с дублями. Модель не останавливается переспросить — она обучена выдавать готовый результат по любому запросу, поэтому каждый пробел заполняет самым вероятным вариантом из обучения. И делает это молча: объяснять выбор её не просили, из-за этого решения остаются внутри кода, а не в тексте ответа. Тесты тут не спасают — они проверяют, ЧТО код делает, а не КАК: код с MD5 проходит их так же зелёно, как код с нормальной защитой. Как строитель, которому сказали «сделай красиво»: он молча клеит обои в цветочек, работа формально сделана — а сюрприз ты обнаружишь после ремонта. По замерам исследования (180 задач, 676 размеченных решений) на одну задачу приходится 3–4 таких молчаливых выбора — и без специального запроса их не видно.

Решение: сначала список скрытых решений, потом правки

Не вычитывай код строчка за строчкой и не проси «перепиши получше». Покажи модели её же результат и потребуй отчёт: какие решения в нём не были в моём запросе. Она разложит их по категориям — безопасность, обработка ошибок, формат данных — с альтернативой и оценкой критичности для каждого. Ты читаешь список как чек-лист, отмечаешь спорное — и просишь переписать только тот кусок, который зависит от изменённого решения. Остальной код не трогается.

→ Что делать: получил код — прогони его через аудит скрытых решений:

Ты — опытный разработчик, который аудирует код на скрытые решения.

Исходный запрос:
{твой_первоначальный_запрос}

Сгенерированный код:
{код}

Задача:
1. РАССУЖДЕНИЕ: перечисли каждое решение в коде, которое явно
   НЕ требовалось запросом. Для каждого назови реалистичную альтернативу.
2. ФОРМАТ: верни список в виде:
   - Категория: {валидация входных данных / формат данных /
     обработка ошибок / хранение данных / производительность / безопасность}
   - Что решено:
   - Альтернатива:
   - Критичность: {низкая/средняя/высокая}

После списка — жди моих правок. Когда я укажу, какое решение изменить,
перепиши ТОЛЬКО тот участок кода, который зависит от этого решения,
остальной код оставь без изменений.

Почему это работает

Модель не планирует решения заранее — но отлично объясняет их пост-фактум. Код рождается как самая вероятная последовательность слов, промежуточные выборы никто не проговаривает. А вот разобрать уже готовый код и назвать, зачем выбран каждый вариант, модель умеет хорошо — это тот же навык, что объяснение чужого кода. Поэтому запрос «посмотри на свой код и найди, что ты решила сама» превращает молчаливые выборы в текст, который можно прочитать и оспорить. Точечная регенерация сужает зону риска. Команда «перепиши весь код» заставляет модель заново принимать все решения — из-за этого она может поменять и то, что тебя устраивало. Поэтому проси переписать только участок, зависящий от одного изменённого решения. Честные границы: редкие категории — безопасность и долговременное хранение — модель находит хуже всего, а они самые критичные; и если от одного решения зависело несколько кусков кода, правка может захватить не все. Список ускоряет проверку, но не отменяет её.

Пример

Приём работает не только с кодом. Просишь ChatGPT: «составь ТЗ на сайт для мастерской по ремонту обуви». Получаешь стройный документ — а внутри модель молча решила: движок WordPress, форма заявки без онлайн-оплаты, про мобильную версию — одна строчка. Разворачиваешь так:

Ты — опытный подрядчик, который проверяет ТЗ на скрытые решения.

Исходный запрос:
"Составь ТЗ на сайт для мастерской по ремонту обуви"

Готовое ТЗ:
[вставь ТЗ, которое выдала модель]

Перечисли каждое решение в ТЗ, которое я явно не просил.
Для каждого: категория, что решено, альтернатива,
критичность (низкая/средняя/высокая).
После списка жди моих правок — и переписывай только тот раздел,
который зависит от изменённого решения.

Модель выдаст список: выбрала WordPress (альтернатива — конструктор, дешевле в поддержке), не заложила онлайн-запись (критичность высокая — клиенты пишут вечером, когда мастерская закрыта), цены на сайте решила не показывать. Ты правишь одно — «онлайн-запись нужна» — и она переписывает только раздел про функциональность, не перетряхивая остальной документ.

Где пригодится

Любой код от ИИ длиннее 10–15 строк — особенно там, где есть пароли, деньги и чужие данные
ТЗ, договоры, планы, стратегии — любой документ, где модель заполняет пробелы за тебя
Правки без эффекта домино: точечная регенерация вместо «перепиши всё»
Правило: получил результат — сначала спроси «что ты решила сама?», потом внедряй

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «AssumptionMiner: Extracting, Tracing, and Revising Implicit Assumptions in LLM Code Generation» (arXiv 2607.22898).

ChatGPT никогда не скажет «мне не хватает данных» — он придумает ответ. Чинится четырьмя блоками в промпте

2026-09-09T10:00:16.319Z

Спроси ChatGPT «какой ноутбук взять» — и он назовёт конкретную модель, не зная ни твоего бюджета, ни задач. Спроси «что делать с продуктом» без единой цифры — получишь уверенную стратегию. Фразу «мне не хватает данных» модель не говорит почти никогда: недостающее она молча придумывает. Врач-исследователь Koyar Afrasyab из шведской Kinvectum AB (июль 2026) прогнал 1200 клинических вопросов через четыре топ-модели и показал: четыре блока в промпте заставляют модель сначала проверить, хватает ли данных, — и честно останавливаться, когда не хватает. Проверил на бытовых вопросах — работает.

В чём проблема: модель оптимизирует «полезный ответ», а не честный

Модель подбирает каждое следующее слово так, чтобы ответ выглядел полезным продолжением разговора. В обучении на человеческих оценках конкретный уверенный ответ стабильно получал балл выше, чем «мне не хватает информации», — из-за этого паттерн «остановись и переспроси» у модели почти выбит. Поэтому, когда в твоём вопросе дыра, она не тормозит: молча достраивает недостающие факты — бюджет, контекст, анамнез — и отвечает так, будто ты всё это ей дал. Снаружи подделку не видно: ответ структурный, уверенный, полный. В исследовании это называют уверенностью без оснований — галлюцинация, замаскированная под экспертизу. Как студент на экзамене, который не знает билет, но отвечает бодро: за уверенную чушь иногда ставят зачёт, за молчание — никогда.

Решение: инвентаризация данных перед ответом

Не проси ответ сразу — заставь модель сначала провести инвентаризацию. Приём называется Evidence-Sufficiency Wrapper — обёртка, проверяющая достаточность данных. Это один промпт с четырьмя блоками: что известно → чего не хватает → хватает ли для ответа → и только потом сам ответ. Перед блоком «ОТВЕТ» модель обязана вынести вердикт «достаточно ли», и если нет — вместо совета выдаёт список: что собрать и почему это меняет решение. Всё в одном сообщении, без цепочек и повторных запросов.

→ Что делать: оборачивай запрос в четыре блока:

Ты — {роль}.

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

ЕСТЬ ДАННЫЕ: перечисли всё, что предоставлено в запросе
и что ты знаешь о ситуации

НЕТ ДАННЫХ: перечисли ключевые данные, которых не хватает
для обоснованного ответа на {тип задачи}

ДОСТАТОЧНО ЛИ: вынеси вердикт — можно ли дать обоснованный
ответ с тем, что есть? Обоснуй одним предложением.

ОТВЕТ: если данных достаточно — {что сделать}.
Если недостаточно — перечисли в порядке приоритета,
что нужно выяснить и почему это критично для решения.

{задача}

Почему это работает

Модель по умолчанию тянется к «полезному продолжению», а не к честности. В обучении уверенные ответы оценивались выше оговорок, поэтому при дыре в данных она достраивает картину сама, а не останавливается. Четыре блока меняют задачу: не «ответь», а «сначала перечисли». Перечислять и классифицировать — сильная сторона модели, поэтому пробелы становятся видны ей самой ещё до ответа: в исследовании одна только структура, без всяких запретов, дала 38% эффекта. Явная инструкция «если данных недостаточно — не отвечай, а скажи, чего не хватает» добавила остальные 62%: у модели появляется легальная точка остановки, и «полезным» становится не совет, а список недостающего. Границы приёма честно: на полных данных обёртка почти ничего не меняет — она работает именно на дырах. И следи за перегибом: часть моделей уходит в сверхосторожность и требует уточнений даже там, где всё есть, — у одной из протестированных точность упала с 75% до 17%. Лечится мягкой формулировкой: вместо «не отвечай» пиши «отвечай с явной оговоркой, чего не хватает».

Пример

Классика жанра — «какой ноутбук купить?». Обычный ChatGPT назовёт конкретную модель, не зная ни бюджета, ни задач. С обёрткой тот же вопрос выглядит так:

Ты — консультант по выбору техники.

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

ЕСТЬ ДАННЫЕ: перечисли всё, что предоставлено в запросе.

НЕТ ДАННЫХ: перечисли ключевые данные, которых не хватает
для обоснованной рекомендации.

ДОСТАТОЧНО ЛИ: вынеси вердикт — можно ли рекомендовать
конкретную модель с тем, что есть? Обоснуй одним предложением.

ОТВЕТ: если данных достаточно — назови 2–3 модели с обоснованием.
Если недостаточно — перечисли в порядке приоритета, что нужно
выяснить и почему это критично для выбора.

Вопрос: какой ноутбук купить?

В «НЕТ ДАННЫХ» модель выпишет бюджет, задачи, вес, автономность, привязку к операционке. В «ДОСТАТОЧНО ЛИ» честно скажет: нет, рекомендовать рано. А в «ОТВЕТЕ» вместо случайной модели даст список вопросов в порядке важности — и объяснит, как каждый ответ меняет выбор. Тот же приём работает с договором, где не хватает ключевых условий, со справкой без контекста и с вопросом «что со мной, если болит бок».

Где пригодится

Разбор документов — договор без ключевых условий, справка, выписка: модель сначала скажет, чего в них не хватает
Здоровье — «что со мной по двум симптомам»: вместо диагноза из воздуха получишь список, что уточнить у врача
Бизнес-решения без цифр — стратегия, запуск, выбор рынка: модель потребует выручку и данные о клиентах, а не нальёт воды
Правило: если сам не уверен, что дал модели всё нужное, — оборачивай запрос в четыре блока

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Judge-dependent safety gains and model-specific helpfulness costs of evidence-sufficiency prompting in clinical LLMs» (arXiv 2607.18086).

Все пишут «думай пошагово». Для договоров и ТЗ это вредный совет: модель должна думать молча

2026-09-06T10:00:16.694Z

Первое, чему учат в промптинге: добавь «думай пошагово» — и ответ станет лучше. В математике так и есть. Но команда из Кембриджа (Lekang Jiang, Wenjun Sun, Stephan Goetz, июль 2026) проверила этот совет на текстах, где важна каждая деталь, — патентных формулах — и получила обратное: когда модель выписывает рассуждения в чат, она теряет конкретику. Причём оценивали не метрики, а лицензированные патентные поверенные: та же модель с теми же шагами, но молча, писала точнее. Весь приём — одна строчка запрета в промпте.

В чём проблема: рассуждая вслух, модель подменяет конкретику общими словами

Когда ты просишь модель показать ход рассуждений, она переключается в режим объяснения. А связный рассказ о своих шагах удобнее строить из обобщений — поэтому конкретное «отверстия диаметром 0,5 мм» превращается в «систему распределения воды», а точная сумма штрафа — в «финансовую ответственность». Это не сбой: модель так помогает себе рассуждать. В экспериментах видно, где всё ломается: уже на первом шаге, при извлечении деталей из источника, точность падала до 62–72%, и каждая потеря тянулась во второй и третий шаг. Самое показательное — модель знала правильный ответ: молча она воспроизводила те же детали, которые вслух теряла. Как хирург, которого заставили комментировать каждое движение: руки умеют, но пока он рассказывает — точность уходит.

Решение: дай модели план шагов — и запрети его показывать

Приём называется Implicit CoT — скрытые рассуждения. Ты по-прежнему даёшь модели структуру мышления: извлеки детали → сгруппируй → сформулируй. Но добавляешь запрет: «думай внутри, не выводя рассуждения» и «выведи ТОЛЬКО финальный текст». Все три шага происходят внутри одного запроса, в чате появляется только результат. В исследовании (693 патента, модели от Llama до GPT-4o) GPT-4o с этим приёмом получила у экспертов на 5,2 балла больше, чем с обычным промптом, а «думай вслух» с теми же самыми шагами — на 2,2 балла меньше, чем молча.

→ Что делать: строй промпт по этому шаблону — и описывай шаги конкретно под свою задачу:

Ты — {роль с экспертизой в нужной области}.

Твоя задача: составить {тип текста: раздел договора / ТЗ / спецификация}
на основе следующего источника:

{источник — черновик, бриф, описание, данные}

Думай внутри, не выводя рассуждения:
— Шаг 1: извлеки все конкретные {ключевые элементы: для договора —
  условия и суммы; для ТЗ — требования и ограничения}
— Шаг 2: сгруппируй по {принципу: функциональным блокам /
  приоритетам / логическим зависимостям}
— Шаг 3: сформулируй в {стиле: формальном юридическом / техническом}
  с соблюдением {формата: нумерации / иерархии разделов}

Выведи ТОЛЬКО финальный {тип текста} — без пояснений,
без промежуточных шагов рассуждений.

Почему это работает

Вывод рассуждений в текст включает режим обобщения. Рассказ о своих шагах модель строит из общих слов, из-за этого детали теряются уже при извлечении из источника — и каждая потеря переходит в следующий шаг, поэтому в финальном тексте вместо сумм и параметров остаются расплывчатые описания. Запрет на вывод убирает пересказ, но оставляет план. Структура «извлеки → сгруппируй → сформулируй» всё равно запускает пошаговое рассуждение, а раз модель не переключается из режима «думаю» в режим «объясняю», её устойчивые шаблоны — как строится договор, как звучит ТЗ — не прерываются, поэтому конкретика из источника доезжает до результата. Границы приёма: на слабых моделях разница минимальна, для творческих задач без источника с деталями преимущества нет, а если результат неточный — временно сними запрет и посмотри, на каком шаге теряются детали.

Пример

Клиент прислал бриф на две страницы: бюджет 450 000 ₽, запуск за 6 недель, три пакета работ, две интеграции и список того, что делать отказался. Попросишь «сначала проанализируй бриф, потом напиши КП» — и в тексте появится «гибкий бюджет» вместо суммы и «сжатые сроки» вместо шести недель. Вместо этого:

Ты — менеджер по продажам в digital-агентстве.

Твоя задача: составить коммерческое предложение
на основе брифа клиента:

[вставить бриф]

Думай внутри, не выводя рассуждения:
— Шаг 1: извлеки все конкретные цифры и условия: бюджет, сроки,
  состав работ, интеграции, что клиент исключил
— Шаг 2: сгруппируй по блокам: задача, решение, этапы,
  стоимость, что не входит в объём работ
— Шаг 3: сформулируй в деловом стиле с нумерацией разделов

Выведи ТОЛЬКО готовое коммерческое предложение — без пояснений,
без промежуточных шагов рассуждений.

На выходе — готовое КП, где бюджет так и остался «450 000 ₽», а сроки — «6 недель». Если что-то всё же потерялось, включи режим отладки из исследования: временно замени последнюю строку на «Покажи все три шага рассуждений и финальный текст», найди шаг, где конкретика превратилась в общие слова, уточни его формулировку — и верни запрет.

Где пригодится

Договоры, оферты, регламенты — суммы, сроки и исключения доезжают до текста без искажений
ТЗ и спецификации — требования и зависимости не размываются в «общий функционал»
КП, резюме, отчёты и таблицы из исходных данных — каждая цифра из брифа остаётся цифрой
Правило: есть источник, где важна каждая деталь, — запрещай вывод рассуждений; математика и мозговой штурм — оставь классическое «думай пошагово»

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «When Reasoning Hurts Legal Drafting: The Verbalization Bottleneck in Patent Claim Generation» (arXiv 2607.10480).

Просишь ChatGPT «проверь на ошибки» — получаешь «всё отлично». Ошибки при этом остаются

2026-09-03T10:00:16.408Z

Знакомая ситуация: скидываешь ChatGPT договор или текст, просишь «проверь на ошибки» — он хвалит структуру, цепляет пару мелочей, ты выдыхаешь. А главная дыра всплывает потом, когда документ уже отправлен. Amin Haeri и Mahdi Ghelichi из TD Bank (июль 2026) нашли причину: без явного списка требований модель находит примерно половину реальных проблем, а треть её замечаний — ложные тревоги. Стоит дать ей список и попросить проверить каждый пункт по очереди — и в их эксперименте она поймала все проблемы до одной, 30 из 30. Разница — один блок текста в промпте.

В чём проблема: без списка модель проверяет то, что сама считает важным

Когда ты пишешь «найди проблемы», модель не знает, что именно ты забыл, — твоих требований она не видела и угадать их не может. Из-за этого она проверяет то, что сама считает важным: типовые вещи, которые «обычно ломаются». Очевидное находит, а промахивается ровно там, где ты сам что-то упустил, — эти случаи никто явно не сформулировал, поэтому для неё их просто нет. Второй эффект — ложные тревоги: без правил модель судит «на глаз», и в исследовании треть её замечаний указывала на проблемы, которых не было. Количеством это не лечится: удвоение числа проверок дало почти ноль (+4 процентных пункта), а восемь независимых прогонов «проверь граничные случаи» вместе не дотянули до одного прохода по списку. Это как принимать квартиру у застройщика без чек-листа: посмотришь на ровные обои, скажешь «всё отлично» — а что розетки не работают, узнаешь через неделю.

Решение: список требований и проверка каждого по очереди

Не проси «проверить» — проси «проверить против списка». Составь 5–10 конкретных требований и попроси модель пройти по каждому отдельно: статус, что именно не так, цитата из материала. Если критериев под рукой нет, сначала попроси их составить: «Составь список из 7–10 конкретных, проверяемых критериев качества для [тип материала]. Каждый критерий должен быть объективным: можно ответить ДА или НЕТ» — и потом запускай проверку по этому списку. Формат вторичен: даже требования сплошным абзацем подняли результат с 2 до 27 пойманных проблем из 30, а нумерованный список добил до 30 из 30.

→ Что делать: проверяй по явному списку требований:

Проверь {что проверяем} против следующего списка требований.

Требования:
1. {требование_1}
2. {требование_2}
3. {требование_3}
[... все требования]

Для каждого требования по очереди:
- Статус: ✅ выполнено / ⚠️ частично / ❌ нарушено
- Конкретное объяснение: что именно не так (если не выполнено)
- Цитата из материала, которая демонстрирует проблему (если применимо)

В конце — краткий список правок: что именно переписать и как.

Вот материал для проверки:
{текст / план / документ}

Почему это работает

Без списка модель проверяет по собственному представлению о «важном». Она не знает, что именно ты пропустил, поэтому промахивается в тех самых неочевидных местах — и заодно выносит субъективные замечания «здесь слабовато», треть из которых оказывается ложной тревогой (33% против 0% при проверке по списку). Явный список превращает каждое требование в отдельное задание. Модель больше не выбирает, что проверять, — она обязана пройти всё по очереди, поэтому неочевидный случай перестаёт быть догадкой и становится пунктом, который нельзя пропустить. А формулировка «нарушено правило 4» даёт якорь: либо нарушено, либо нет — субъективность исчезает. Оптимум — 5–10 правил: больше 15 — внимание модели к каждому падает. Честная граница приёма: он работает там, где критерии в принципе существуют. Для творческих задач — «придумай, как лучше» — списка правил нет, и эффекта не будет.

Пример

Снимаешь квартиру, собственник прислал договор на четыре страницы. «Проверь, всё ли ок» вернёт «в целом стандартный договор». Вместо этого:

Проверь договор аренды квартиры против следующего списка требований.

Требования:
1. Указан размер депозита и условия его возврата
2. Прописано, кто платит за коммуналку, интернет и мелкий ремонт
3. Есть условия досрочного расторжения и срок предупреждения —
   для обеих сторон
4. Зафиксировано, что плата не меняется в течение срока договора
5. Есть акт приёма-передачи с состоянием квартиры и мебели
6. Прописаны условия визитов собственника — только по договорённости

Для каждого требования по очереди:
- Статус: ✅ выполнено / ⚠️ частично / ❌ нарушено
- Конкретное объяснение: что именно не так
- Цитата из договора, которая демонстрирует проблему

В конце — краткий список: что попросить изменить до подписи.

Вот договор:
[текст договора]

Вместо «в целом нормально» получишь построчный разбор: «правило 1 частично: депозит указан, но не написано, когда и как он возвращается» — и готовый список правок для разговора с собственником. Тот же шаблон работает для статьи перед публикацией, лендинга и важного письма — меняются только требования.

Где пригодится

Договоры и документы перед подписью — аренда, подряд, оферта: список условий вместо «глянь, всё ли ок»
Тексты перед отправкой — статья, лендинг, письмо клиенту: явные требования вместо «свежего взгляда»
КП и питчи — в роли списка возьми типичные возражения клиента или инвестора и проверь, закрыто ли каждое
Правило: нет списка — нет проверки; сначала попроси модель составить критерии, потом проверяй по ним

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Specification Grounding Drives Test Effectiveness for LLM Code» (arXiv 2607.06636).

Просишь ChatGPT разнести твой питч — он «критикует» его цитатами из твоего же текста

2026-08-18T10:00:16.421Z

Знакомая схема: просишь ChatGPT сыграть придирчивого инвестора или вредного клиента, получаешь солидный «разбор» — и идея кажется проверенной. Теперь перечитай его аргументы: это фразы из твоего же питча, переставленные местами. Написал «натуральные ингредиенты» — «клиент» покупает, потому что ингредиенты натуральные. Atharva Pandey и Gautam Jajoo (июль 2026) сравнили такие симуляции с ответами реальных людей: причины, которые сочиняет модель, предсказывают поведение хуже, чем настоящие человеческие причины, случайно перемешанные между людьми. Хорошая новость: подмена ловится и чинится тремя ограничениями в промпте. Разбираю приём и даю готовый шаблон.

В чём проблема: модель собирает «мнение» из твоего же текста

Модель обучали подстраиваться под контекст: ответ, который согласуется с показанным текстом, выглядит уместным и полезным — такие ответы в обучении оценивали выше. Из-за этого, когда ты просишь её сыграть скептика, она строит «мнение» из самого доступного материала — твоего же питча. Поэтому продающие пункты возвращаются к тебе в виде причин: питч говорит «рынок растёт на 40%» — «инвестор» вкладывается, потому что рынок растёт на 40%. Хотя настоящий скептик первым делом усомнился бы в самой цифре. Снаружи подмена неотличима от анализа: вердикт есть, обоснование есть. Но ты слышишь не мнение рынка, а эхо собственных слов. Исследователи измерили масштаб: 94 реальных покупателя оценили три продукта и написали, почему готовы или не готовы купить. Потом те же причины попросили сочинить LLM от их лица — и сгенерированные причины предсказывали реальные решения хуже, чем настоящие человеческие, даже случайно перемешанные между людьми. То есть модель не слегка промахивается — она вообще не заглядывает в чужую голову, а переупаковывает твой текст.

Решение: чек-лист причин, три голоса и запрет на цитаты

Подмена ломается тремя ограничениями в одном промпте. Первое: не давай модели объяснять решение свободным текстом — задай фиксированный чек-лист категорий (цена, доверие к цифрам, риск, привычка) и попроси отметить каждую «за», «против» или «не участвует». Второе: вместо одного усреднённого «клиента» запроси три контрастных голоса — скептик, нейтральный, энтузиаст — каждый отдельным блоком. Третье, ключевое: прямо запрети брать причины из твоего текста. Если в питче написано «рынок растёт на 40%», модель должна ответить не «рынок растёт», а верит ли персонаж этой цифре — и почему.

→ Что делать: подставь свой текст в шаблон из исследования:

Вот текст/концепция для оценки:
«{текст_концепции}»

Сыграй три роли человека, реагирующего на это. Роли:
- Скептик — ищет слабые места и сомневается
- Нейтральный — взвешивает плюсы и минусы поровну
- Энтузиаст — ищет, что могло бы убедить

Контекст персоны: {кто этот человек, его опыт и привычки в теме}

Для каждой роли:
1. Вердикт: согласится / откажется / нужно больше информации
2. Разбери причину строго по категориям (отметь «за», «против»
   или «не участвует»):
   - {категория_1}
   - {категория_2}
   - {категория_3}
   - {категория_4}

ВАЖНО: не бери причину прямо из текста концепции. Если там
написано «X», не пиши «нравится X» — напиши, ВЕРИТ ли персона
утверждению X и почему.

Выведи три роли отдельными блоками, без смешивания.

Почему это работает

Свободный ответ соскальзывает в пересказ, потому что твой текст — самый доступный материал. Модель подбирает правдоподобное объяснение, а не независимое суждение, поэтому без ограничений «мнение» складывается из готовых формулировок питча. Жёсткая структура разворачивает сильную сторону модели против этой привычки. Модель хорошо держит заданный формат: попроси разложить причину по категориям — и она честно оценит каждую, включая неудобные «против». Раздельные роли не дают усреднить ответ до нейтрально-положительного, поэтому у скептика появляется место для настоящих сомнений. А запрет на цитаты меняет саму задачу: не «повтори утверждение», а «оцени, веришь ли ты ему» — это уже рассуждение, а не эхо. Честные оговорки: запрет снижает пересказ, но не убирает его полностью, а проверяли метод на небольшой выборке — 94 человека и три концепции. Так что это детектор и страховка, а не гарантия честности.

Пример

Проверяешь резюме перед откликом на вакансию продакт-менеджера — хочешь увидеть его глазами нанимающего, который листает десятки таких в неделю:

Вот моё резюме на вакансию продакт-менеджера:
«5 лет в b2c-продуктах. Запустил 3 крупные фичи. Поднял retention
на 18%. Строил аналитику с нуля. Ищу команду с сильной продуктовой
культурой»

Сыграй три роли нанимающего менеджера, который читает это резюме:
- Скептик — ищет слабые места и сомневается
- Нейтральный — взвешивает плюсы и минусы поровну
- Энтузиаст — ищет, что могло бы убедить позвать на интервью

Контекст персоны: senior продакт-лид, смотрит 40 резюме в неделю,
не доверяет красивым цифрам без деталей.

Для каждой роли:
1. Вердикт: позвать на интервью / отказать / нужно больше информации
2. Разбери причину строго по категориям (отметь «за», «против»
   или «не участвует»):
   - доверие к цифрам (retention +18% — верю или нет?)
   - релевантность опыта под вакансию
   - риски (пробелы, размытые формулировки)
   - ясность и конкретика текста

ВАЖНО: не бери причину прямо из текста резюме. Если написано
«поднял retention на 18%» — не пиши «поднял retention», а напиши,
ВЕРИТ ли менеджер этой цифре и почему.

Выведи три роли отдельными блоками, без смешивания.

Настоящая критика выглядит так: скептик пишет «цифре +18% не верю — не сказано, на какой базе и за какой срок считали». Этого в резюме нет — значит, модель рассуждает. Плохой знак: все три роли повторяют твои формулировки («сильный кандидат — поднял retention на 18%»). Это пересказ; ужесточи запрет: «не используй ни одного слова из текста как аргумент».

Где пригодится

Питчи и презентации — прогон через «скептика-инвестора» до реальной встречи
Резюме и сопроводительные письма — проверка глазами уставшего HR до отклика
Лендинги, посты, коммерческие предложения — реакция трёх типов аудитории до публикации
Быстрый детектор: все роли цитируют твой текст как причину — это эхо, а не мнение

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Reason-Mediated Behavioral Models for Auditing LLM Social Simulators» (arXiv 2607.24649).

Просишь ChatGPT «добавь эмоций» — он молча выкидывает лимит длины из начала чата. Так ломается до 73% длинных диалогов

2026-08-15T10:00:16.010Z

Знакомая история: дорабатываешь с ChatGPT письмо или план в несколько заходов — и к пятой правке текст выполняет последнюю просьбу, но растерял всё, о чём договаривались в начале: тон, длину, запреты. Исследователи (Yonghui Huang, июль 2026) прогнали 26 016 таких многошаговых сессий и показали: модель не забывает ранние требования — она молча решает, что новое важнее, и жертвует старыми. И есть промпт-приём, который стабильно возвращает контроль всем моделям — Verification Gate. Проверил на письме клиенту — работает.

В чём проблема: последняя правка перевешивает всё, что ты задал раньше

Модель генерирует ответ, опираясь на ближайший контекст: последнее сообщение статистически весит больше, чем то, что написано пятью-шестью репликами раньше. Ранние требования не исчезают из истории — падает их вес. Из-за этого, когда новая просьба конфликтует со старым правилом («добавь эмоций» против «деловой тон»), модель тихо решает конфликт в пользу нового — и не предупреждает. Исследователи собрали 542 задачи, где к результату восемь раз подряд добавляли новые требования, и прогнали через них шесть моделей — от GPT-4o до Llama. К концу диалога от 40% до 73% задач потеряли хотя бы одно требование, которое раньше выполнялось. Все модели, без исключений. Причём когда вручную разобрали 384 поломки, выяснилось: главная причина — не «потеряла контекст», а конфликт нового со старым, который модель разрешила не в твою пользу. Как стажёр, который живёт последним поручением: попросил подать кофе в большой кружке — подал, но с сахаром, хотя «без сахара» было самым первым условием.

Решение: сверка всех требований перед каждой правкой

Не кидай правку одной строкой. Перед каждым изменением давай модели явный список всех активных требований и требуй сверку после правки: каждый пункт — статус, конфликт — назвать вслух, а не исправлять молча. Приём называется Verification Gate — «проверочные ворота»: результат выходит наружу только после проверки. Это переключает модель из режима «выполни последнее» в режим «выполни новое, сохранив всё предыдущее». В исследовании это единственная стратегия, которая улучшила все шесть моделей: у DeepSeek-V3 доля задач без поломок выросла с 75,8% до 87,9%, у слабой Llama-3.1-8B — с 31,6% до 47,3%.

→ Что делать: начиная со второй правки вставляй перед изменением этот шаблон:

Список активных требований:
{требование_1}
{требование_2}
{требование_3}
[добавь столько, сколько нужно]

Новое требование: {новое_требование}

Текущая версия:
{текущий_контент}

Порядок работы:
1. Внеси новое требование в текущую версию
2. Проверь каждый пункт из списка: статус ✅ выполнено / ❌ нарушено
3. Если есть ❌ — назови конкретный конфликт и предложи версию без него
4. Если конфликт неразрешим — сообщи явно, не жертвуй старыми
   требованиями ради нового
5. Итоговый результат выдай только если все ✅

Почему это работает

Модель не хранит приоритеты — она читает ближайший контекст. Последняя просьба весит больше правила из начала чата, поэтому при конфликте модель молча жертвует старым: сигнала «это всё ещё обязательно» у неё нет. Явный список возвращает старым требованиям вес, а условие «выдай только если все ✅» запрещает тихий компромисс. Сверять текст с чеклистом модель умеет отлично — ей нужно лишь дать, что с чем сравнивать, поэтому вместо тихой поломки ты получаешь либо результат, где всё цело, либо честное «эти два требования несовместимы». Критична фраза «не жертвуй старыми требованиями молча»: без неё модель попробует «выполнить оба», размыв оба. И честно про границы: приём снижает регрессию, но не убирает совсем, а размытые пункты вроде «сохрани лёгкость» модель отметит ✅ там, где ты увидишь ❌ — формулируй требования конкретно.

Пример

Пишешь клиенту письмо о повышении цен. В начале договорились: не больше 7 предложений, без извинений, деловой тон. После четвёртой правки письмо расползлось на 15 предложений и обросло «мы понимаем, что это неудобно». Пятую правку отправляешь уже так:

Список активных требований к тексту:
1. Не более 7 предложений
2. Без извинений и оправданий
3. Деловой, прямой тон
4. Партнёрская интонация, не директивная
5. Обоснование — через ценность, не через издержки

Новое требование: добавь абзац про расширенные условия поддержки

Текущая версия текста:
{текущее письмо}

Инструкция:
1. Внеси новое требование
2. Проверь каждый пункт из списка: статус ✅/❌
3. Если есть ❌ — назови конфликт явно и предложи версию без него
4. Если конфликт неразрешим — скажи об этом, не жертвуй старыми
   требованиями молча
5. Выдай финальный текст только если все пункты ✅

Модель сначала покажет сверку по всем пяти пунктам и только потом текст. А если новая просьба несовместима со старой — например «добавь эмоций» против «деловой тон» — конфликт всплывёт явным сообщением, а не потерей тона, которую заметишь через три правки.

Где пригодится

Письма клиентам, офферы, посты — всё, что дорабатываешь в несколько заходов и где тон с длиной задал в начале
Сметы, ТЗ, планы — где новая правка тихо задевает соседние пункты
Код с ИИ-ассистентом: «добавь функцию» часто ломает то, что уже работало (исследование именно об этом)
Правило: со второй правки в любом длинном чате — сначала список активных требований, потом изменение

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Regression Accumulation in Multi-Turn LLM Programming Conversations» (arXiv 2607.01855).

80 правил в промпте — и модель ломается. Красивый маркдаун не спасёт: у LLM нашли числовой порог отказа

2026-08-11T10:00:18.155Z

Собираешь системный промпт для бота — тон, запреты, обязательные фразы — и список разрастается до сотни пунктов? Есть плохая новость с точной цифрой. Netanel Eliav из Machine Human Intelligence Lab (июль 2026) прогнал через пять моделей одни и те же наборы правил — от 10 до 160 штук, в четырёх форматах: маркдаун, обычный текст, сплошной рассказ, таблица. До 40 правил модели держат почти всё. На 80 — вероятность выполнить все правила сразу падает до нуля. У каждой модели. В каждом формате. Оформление не спасает вообще.

В чём проблема: правила теряются из-за количества, а не оформления

Модель не ведёт список «выполнено / не выполнено». Пока она пишет ответ, все твои правила лежат в контексте разом, и каждое она соблюдает с высокой вероятностью, но не гарантированно. Из-за этого включается простая математика: одно правило выполняется, скажем, в 98% случаев, но чем больше правил одновременно, тем выше шанс, что при генерации хотя бы одно выпадет. Поэтому при 10–40 правилах всё выглядит прилично, на 80 идеальное соблюдение обнуляется, а на 120–160 наступает полный провал. Как жонглёр: каждый отдельный мяч он держит легко, но с каждым новым растёт шанс уронить любой из них — и цвет мячей ничего не меняет. Исследование это прямо показало: маркдаун, таблица, список и сплошной текст ломаются одинаково. Формат отвечает за то, КАК показать правила, а не за то, СКОЛЬКО модель удержит.

Решение: 10–15 критичных правил в промпте, остальное — отдельно

Не вылизывай формат — режь количество. Раздели правила на два уровня: 10–15 критичных, без которых ответ провалится, — в системный промпт; остальные — отдельными сообщениями по ходу диалога, не больше 15–20 за раз, с проверкой результата после каждого. Так модель на каждом шаге удерживает посильное число условий, а не всю сотню сразу. Если не знаешь, что критично, — попроси саму модель разбить твой список на критичные и вторичные: она уточнит, что важнее для задачи, потому что без приоритетов все правила выглядят равнозначными.

→ Что делать: дели правила на уровни по шаблону из исследования:

СИСТЕМНЫЙ ПРОМПТ (не больше 10-15 критичных правил):
{правило 1}
{правило 2}
{правило 3}

СООБЩЕНИЕ ПОЛЬЗОВАТЕЛЯ (доп. правила для конкретной задачи,
максимум 15-20):
{правило А}
{правило Б}

Если правил больше — раздели их на несколько последовательных
запросов и проверяй результат после каждого.

Почему это работает

Правила теряются комбинаторно, а не из-за формата. Модель удерживает их все одновременно, без счётчика выполнения, поэтому каждое новое правило умножает шанс потерять любое из предыдущих — и на 80 штуках идеальное соблюдение падает до нуля независимо от оформления. Короткое ядро критичных правил возвращает надёжность. Ты снижаешь число одновременных условий до 10–15, поэтому шанс удержать их все разом снова становится высоким, а вторичные правила уходят в отдельные шаги — там они не конкурируют с критичными. Границы приёма: где размещать правила — в системном промпте или в сообщении — зависит от модели, единого ответа нет, тестируй на своей. Таблицы съедают примерно на треть больше токенов, чем текст, без надёжного выигрыша. И бонус-находка: у предела контекста модель не выдумывает факты (0 случаев из 5760 проверок), а честно отказывается отвечать — доля отказов подскакивает с 0% до 80–90%. Отказ — не каприз, а сигнал: режь документ на части.

Пример

Настраиваешь ИИ-консультанта для магазина одежды на маркетплейсе. Хочется заложить всё сразу: тон, запреты, форматирование, обязательные фразы — набралось 90 пунктов. Свалишь их в один системный промпт — часть потеряется гарантированно: порог в 80 уже пройден. Вместо этого оставляешь критичное ядро:

Ты — консультант интернет-магазина одежды. Вот КРИТИЧНЫЕ правила,
соблюдай их всегда:

1. Не используй слово "гарантия" — юридически чувствительно
2. Обращайся на "вы"
3. Не используй восклицательные знаки
4. Ответ не длиннее 3 предложений
5. Заканчивай ответ фразой "Если нужна помощь — я на связи"

Дополнительные правила для этого диалога (не более 15 за раз)
добавлю отдельным сообщением.

Такое ядро из 5–6 правил модель держит стабильно. Остальные 85 пунктов уходят пачками по 15 в следующие сообщения — или превращаются в чек-лист, по которому ты проверяешь готовые ответы.

Где пригодится

Системные промпты ботов поддержки и консультантов — где требования к тону и запретам множатся десятками
Регламенты для рабочих ИИ-ассистентов: критичное — в промпт, остальное — чек-листом по готовому ответу
Брифы нейросети-копирайтеру: 10 главных требований работают лучше простыни из 60
Правило на каждый день: считай правила, а не вылизывай формат — порог один для маркдауна, таблицы и текста

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models» (arXiv 2607.19257).

Почему нейросети выдают пресные игровые тексты — и 3 рычага, которые это чинят

2026-08-08T10:00:18.416Z

Гладко, но пресно: описания предметов, реплики NPC и лор от нейросети выходят безжизненными, и вставлять их в игру стыдно. Оказалось, дело не в кривом запросе — так модель работает по умолчанию. Учёные из Knowledge Lab Чикагского университета (Zehan Li и коллеги, 27 мая 2026) разобрали, почему так, и выделили три рычага, которые возвращают тексту живость. Проверил на своих игровых текстах — работает. Делюсь.

Почему по умолчанию выходит пресно

Представьте повара, которому сказали приготовить блюдо, которое понравится тысяче случайных людей. Чтобы никого не обидеть, он убирает специи, соль и текстуру — и подаёт безвкусную овсянку. Формально еда, радости ноль. Нейросеть ровно так и обучена: на дообучении её натаскивали нравиться большинству, поэтому она тянется к «среднему по палате». Всё острое — конфликт, неожиданный поворот, дерзкий стиль — внутренний фильтр выкидывает как «нетипичный шум». В статье даже цифра есть: доля конфликта и удивления в тексте падает примерно с 47% до 7,5%. Вот тебе и «легендарный клинок героев» в каждом описании.

Три рычага, которыми это лечится

Ключевая мысль: модель куда лучше слушается конкретных координат, чем абстрактного «сделай интересно». Дай ей три — эмоции по этапам, ритм смены тем и стилевой якорь (имя реального автора/вселенной). И отдельно — прямо запрещай скучное: запрет работает сильнее разрешения.

Вот шаблон, который я допиливаю под каждую задачу:

{Что написать: тема, объём}

ЭМОЦИОНАЛЬНЫЙ РИСУНОК:
— Начало: {эмоция / состояние}
— Середина: {момент конфликта / удивления}
— Финал: {чем заканчивается — честно, не обязательно хорошо}

РИТМ СМЕНЫ ТЕМ:
— {где задержаться: деталь / образ}
— {где резкий поворот: без подготовки}

СТИЛЬ: {конкретный автор / вселенная}

ЗАПРЕЩЕНО: нейтральное повествование / пафосный финал /
плавные переходы

Почему рычаги вообще работают

Запрет сильнее разрешения. «Пиши атмосферно» оставляет модели тысячу вариантов, и она выберет самый средний. «Без плавных переходов, без пафосного финала» прямо блокирует скучный путь. Стилевой якорь смещает центр притяжения: назвал конкретную вселенную или автора — и текст утаскивает от безликого среднего в нужную сторону, чем известнее ориентир, тем чётче. Модель не «станет Мартином», но перестанет быть никем.

Как это выглядит на деле

Ставлю задачу — флейвор-текст для предмета в тёмном фэнтези. Обычный запрос выдаёт «древний меч, хранящий силу забытых героев» (зевок). А с рычагами:

Напиши описание предмета для тёмного фэнтези-RPG: старый меч,
найденный в затопленном склепе. ~400 знаков, флейвор-текст.

ЭМОЦИОНАЛЬНЫЙ РИСУНОК:
— Начало: не пафос, а брезгливость — ржавчина, тина, чей-то палец на рукояти
— Середина: короткий укол — этим мечом убили не врага, а своего
— Финал: без морали, просто факт, от которого не по себе

РИТМ:
— Первая фраза медленно, деталь
— Потом резкий обрыв в другую сцену

СТИЛЬ: в духе флейвора Dark Souls / Elden Ring — скупо, мрачно, недосказанно

ЗАПРЕЩЕНО: пафос, «клинок героев», плавные переходы

На выходе — не музейная табличка, а текст, который хочется прочитать вслух. Тот же приём я гоняю на репликах NPC, описаниях локаций и постах в сообщество проекта — везде оживает.

Где пригодится

Флейвор-тексты, описания предметов, локаций, лор
Реплики и диалоги NPC — чтобы не звучали как автоответчик
Посты для сообщества проекта, девлоги, анонсы
Любой текст, который должен цеплять, а не усыплять

Важная оговорка: это для художественных и «живых» текстов. Для документации, патчноутов и деловых писем нейтральность — наоборот плюс, туда рычаги не тащим. А если хочешь получать такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «Narrative Flattening: How Post-Training Compresses Thematic, Affective, and Stylistic Variation in LLM Fiction» (arXiv 2605.27878).

ChatGPT ищет подвох там, где его нет — и портит ответ. Виновата форма вопроса

2026-08-04T10:00:15.110Z

Заметил странное: задаёшь ChatGPT нормальный рабочий вопрос, а он вместо ответа уходит в философию и ищет какой-то скрытый смысл. Оказалось, дело не в вопросе, а в его ФОРМЕ. Психологи и айтишники из Принстонского университета (Bella Fascendini и коллеги, июнь 2026) показали: если запрос хоть немного похож на загадку, модель включает «режим подвоха» и промахивается — точность падает до 50,7%. Разобрался, как это выключать.

В чём проблема: модель реагирует на форму вопроса раньше, чем на смысл

Прежде чем вникнуть в суть, модель определяет «жанр» вопроса по его форме. Увидела знакомую конструкцию «X произошло, но Y — как такое возможно?» — и сопоставила её с обучающими данными, где такие фразы почти всегда оказывались загадками с подвохом, а не прямыми вопросами. Дальше она отвечает не на твой вопрос, а на угаданный жанр: ищет скрытый смысл, которого нет. Форма перебивает содержание — так человек, услышав первые аккорды, затягивает знакомый припев, даже когда играют другую песню.

Решение: назови режим в первой строке

Одна фраза в начале запроса перебивает этот автоматизм — до того, как он сработает. Нужен прямой ответ — прямо скажи «отвечай буквально». Нужен креатив — наоборот, попроси искать нестандартную трактовку. Главное — не оставлять выбор режима на волю формы вопроса.

→ Что делать: для прямого ответа добавь в начало:

Ответь на вопрос буквально. Не ищи скрытых смыслов, уловок
или нестандартных интерпретаций. Прими вопрос за чистую монету
и дай прямой ответ.

Вопрос: {твой вопрос}

Почему это работает

Режим ответа выбирает форма вопроса, а не его смысл. Знакомая структура «как такое возможно?» сама по себе переводит модель в поиск подвоха — поэтому она философствует даже там, где подвоха нет. Инструкция в первой строке задаёт режим раньше, чем сработает этот автоматизм. Ты называешь жанр сам — «отвечай буквально», — поэтому модель разбирает вопрос по факту, а не ищет второе дно. Оговорка: если модель видела этот вопрос дословно в обучении, она выдаст запомненный ответ, что бы ты ни дописал.

Пример

Спрашиваешь иронично про сорванный дедлайн — и вместо разбора получаешь эссе о бренности бытия и хрупкости доверия. С явным режимом:

Ответь буквально, не ищи скрытых смыслов. Прими за чистую монету.

Вопрос: подрядчик обещал сдать работу за 10 дней, взял предоплату
50%, но пропал и не берёт трубку. Как такое возможно?

Вместо философии про доверие — прямой разбор: реальные причины и что делать дальше. Ровно то, что спрашивал.

Где пригодится

Рабочие вопросы, заданные иронично или витиевато — чтобы получить разбор, а не эссе
Логические и бытовые задачи в форме «как так вышло»
Отладка и анализ ситуаций — ставь «режим: буквальный»
И наоборот: когда нужен креатив — включай «изобретательный режим» осознанно, а не случайно

Если хочешь такие находки из свежих исследований каждый день — их присылает бот @NovaPaperAlert_bot.

Опирался на исследование «The Riddle Riddle: Testing Flexible Reasoning in Large Language Models and Humans» (arXiv 2606.27103).