Как научиться работать с нейросетями: три навыка вместо курса по промптам

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

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

Почему курс по промптам учит не тому

Лучшее известное мне свидетельство — полевой эксперимент Гарвардской школы бизнеса и Бостонской консалтинговой группы. В нём участвовали 758 консультантов. Одни работали без модели, другие получили доступ к GPT-4, третьи — доступ плюс вводные материалы по составлению запросов: видео и документы с приёмами.

На задачах, с которыми модель справляется, результат ожидаемый: с моделью консультанты выполняли на 12,2% больше задач, на 25,1% быстрее и с качеством выше более чем на 40%. Авторы попутно заметили, что после вводных материалов участники чаще переносили текст модели в ответ без изменений, и на этой задаче такие ответы оценивались выше. Внутри границы привычка доверять тексту модели окупалась.

Интересное началось на задаче, которую специально подобрали за границей возможностей модели. Там надо было заметить в интервью деталь, переворачивающую очевидный вывод из таблицы. Без модели верное решение нашли 84,5% участников, с моделью — 70% и 60%.

Хуже справилась как раз группа, получившая вводные материалы по запросам: минус 24 процентных пункта против минус 13 у тех, кому просто дали доступ. Разница между этими двумя группами статистически слабая, и строить на ней всё я бы не стал. Направление всё же показательное: на этой задаче материалы ускорили людей, но не сделали их внимательнее.

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

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

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

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

Задача «выпиши все сроки и штрафы, у каждого — номер пункта; если пункта нет, пустая строка» проваливается очевидно. Пропущен срок — провал. Номер пункта не тот — провал. Штраф придуман — тоже провал, и виден сразу: пункта с таким номером в договоре нет.

Разница не в длине запроса и не в словах. Во втором случае до запуска известны три вещи: что на входе, как выглядит готовое и как выглядит брак. Без третьей постановка не закончена. Я проверяю себя одним вопросом: могу ли я описать неправильный ответ, ещё не видя ответа? Если нет, запускать рано.

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

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

Навык второй: проверка, а не впечатление

Этот навык самый трудный, потому что его отсутствие не ощущается. Когда проверка слабая, работа с моделью кажется особенно удачной.

Хорошо это видно по исследованию METR. Шестнадцать опытных разработчиков выполнили 246 реальных задач в своих же проектах: часть — с помощником на основе модели, часть — без. До начала они ждали ускорения на 24%, после окончания считали, что ускорились на 20%. Замер показал, что с помощником задачи занимали на 19% больше времени.

Авторы сами ограничивают вывод: небольшая группа, одна область, модели начала 2025 года. Замедление меня здесь интересует меньше, чем то, что ощущение и секундомер разошлись в знаке, причём у людей, которые хорошо знают свою работу.

Третий кусок картины — опрос исследователей Microsoft: 319 работников умственного труда описали 936 случаев, когда пользовались генеративными моделями. Чем выше человек ставил надёжность модели, тем меньше критического осмысления результата он за собой отмечал; уверенность в собственной компетенции, наоборот, была связана с более внимательной работой. Это самоотчёт и корреляция, без эксперимента, но с двумя предыдущими результатами он согласуется.

На практике навык собирается из трёх привычек.

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

Запускать спорное трижды. Если три ответа разошлись в выводе, править формулировку бесполезно: задача для модели недоопределена, и хороший первый ответ был удачей.

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

Навык третий: устройство — ровно на предсказание ошибок

Изучать архитектуру, чтобы пользоваться моделью, не нужно. Нужна одна мысль и её следствия: модель предсказывает продолжение текста, и в ней нет ни базы фактов, ни проверки, ни состояния «не знаю».

Из этого выводится большинство ошибок, которые встретятся в первые недели.

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

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

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

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

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

Порядок на первые недели

Всё это делается на одной операции из обычной работы. Условия выбора: вы умеете выполнять её сами, она повторяется каждую неделю, и её результат вы в состоянии проверить. Задача, в которой вы не разбираетесь, для обучения не годится — проверять нечем, и тренируется только доверие.

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

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

Третья — проверка вместо выполнения. Операцию вы больше не делаете: делает модель, вы проверяете по свойствам из журнала и засекаете время. Входы, на которых модель ошиблась, откладываете в набор. Двух десятков хватает, если сравнивать до и после правки на одних и тех же входах.

Четвёртая — вторая операция другого типа. Если первая была извлечением фактов, берёте черновик текста или разбор таблицы. Здесь станет видно, что граница проходит иначе, а три навыка переносятся — в отличие от конкретных приёмов.

Журнал ведётся всё это время, и он важнее любого из шагов. Из колонки расхождений через месяц получаются и хорошие запросы, и набор для проверки, и список задач, которые модели лучше не отдавать.

Условие несогласия

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

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

Чего я делать не стал бы

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

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

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

Открытый вопрос

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

Я не знаю, какая часть наработанного чутья переносится на следующую версию, а какая становится вредной привычкой — перепроверять то, что больше не ломается, и доверять тому, что сломалось заново. Журнал расхождений позволяет заметить сдвиг, но только если его продолжают вести после того, как обучение вроде бы закончилось. Этого почти никто не делает, и я в том числе.