Сложные задачи: дай место работе

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

Хочется прочитать это как потолок способностей. Обычно дело в другом: работе негде было произойти.

Листок для черновика

Попроси человека умножить 47 на 83 в уме — скорее всего, промахнётся. Дай листок — посчитает. Тот же человек, та же арифметика. Листок не добавляет ума, он добавляет места: куда положить промежуточные результаты вместо того, чтобы жонглировать всем сразу.

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

Текст ответа — это черновик модели. Не отбирай листок.

Отсюда растёт самый растиражированный результат во всей теме промптов. В 2022 году Джейсон Вэй с коллегами из Google показали, что просьба разложить решение на промежуточные шаги — chain-of-thought, «цепочка рассуждений» — резко улучшает результат на многошаговых задачах, а группа Такэси Кодзимы обнаружила, что тот же эффект включается одной добавленной строкой, знаменитым «давай подумаем шаг за шагом».

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

Принцип пережил приём. Место для работы по-прежнему надо оставлять — а забрать его можно несколькими способами, сам того не заметив.

Никогда не проси вывод первым

Этот пункт стоит дороже всех шаблонов промптов вместе взятых и прямо следует из механики.

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

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

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

Разбивай

Большая задача в один ход получает один проход внимания по всему сразу. Та же задача в четыре хода получает четыре.

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

Один шаг за ход там, где шаги реально зависят друг от друга: вытащить данные, потом проверить, потом проанализировать, потом описать. Каждый ход видит чистый результат, а не собственную недоделанную работу.

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

Дай ей то, с чем можно сверяться

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

Числа внутри текста порождаются так же, как всё остальное: правдоподобно и шатко ровно там, где важна точность (вторая статья: цифры она толком и не видит). С кодом иначе — он либо запускается, либо нет, и результат берётся из выполнения, а не из предсказания. «Напиши скрипт, который считает это по таблице, потом истолкуй вывод» превращает непроверяемый ответ в проверяемый.

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

Где размышление перестаёт помогать

Честная граница, чтобы не переусердствовать.

Долгое рассуждение чинит проблемы обработки: несколько шагов, ограничения, сравнения, логика. И ничего не делает с проблемами отсутствующего знания. Если факта нет — он за границей знаний, он про твою компанию, он в документе, который ты не вставил, — расширенное размышление его не найдёт. Оно выдаст более длинную, более связную и более убедительную выдумку. Уверенный вывод на пять абзацев про число, которого у модели никогда не было, хуже короткого неверного ответа: в него труднее не поверить.

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

На практике

Включай расширенное размышление на реально многошаговом. Выключай на справках и лёгких правках.

Разбор сначала, вердикт в конце. Не позволяй выводу породиться раньше рассуждения — ни её выводу, ни твоему.

План, правка плана, потом исполнение. Самый дешёвый круг обратной связи из возможных.

Один зависимый шаг за ход. Не проси в одном сообщении и вытащить, и проанализировать, и написать.

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

Спрашивай себя: думать или знать? Если знать — рассуждение не поможет, нужен материал или поиск.

Проверь себя

Закрой статью и ответь своими словами:

Почему выписанные шаги реально улучшают ответ, а не просто документируют его?
Что показали работы по цепочке рассуждений и что изменилось в современных моделях?
Почему «сначала да или нет, потом объяснение» — самоподрывающая просьба?
Чем упоминание собственного предпочтительного вывода портит разбор?
Почему разбить задачу по ходам лучше, чем один большой ход?
Почему «напиши код, который посчитает» сильнее, чем «посчитай»?
Когда дополнительное рассуждение делает хуже и как распознать этот случай?

Коротко

Модель считает по ходу письма: видимый текст и есть черновик. Требование немедленного ответа отбирает место, нужное работе.
Цепочка рассуждений (Вэй и др., 2022; Кодзима и др., 2022) сделала это явным; современные модели делают это сами, а режимы расширенного размышления узаконивают черновик.
Никогда не проси вывод первым — всё, что после него, становится защитой, а не разбором. То же самое, если ты сам называешь своё мнение заранее.
Сначала план, потом исполнение. Один зависимый шаг за ход. Сгенерировать, раскритиковать по критериям, переписать — разными ходами.
Цепляй внешний сигнал везде, где можно: запускаемый код, тест, документ для цитат. Проверка лучше доверия.
Рассуждение решает проблемы обработки, а не пробелы в знании: без фактов долгое размышление даёт лишь более убедительную выдумку. Спроси, задаче нужно думать или знать.
Текст ответа — это черновик модели. Не отбирай листок.