Misha Ford – Мастерство промт-инжиниринга. Продвинутый уровень (страница 5)

Отдельная задача – как строить примеры так, чтобы модель верно обобщала, а не привязывалась к случайным деталям. Вы всегда должны помнить: модель не “понимает” смысл как человек, она ловит статистические паттерны. Если во всех негативных примерах у вас встречается слово “ужасно”, модель может начать ассоциировать негатив только с этим словом и хуже справляться с другими формами негатива. Если во всех позитивных примерах вы пишете, что‑то про “рекомендую друзьям”, модель может переоценить важность именно этой фразы.

Поэтому ваши примеры должны быть разнообразными внутри каждой категории, но при этом придерживаться общей логики. Для тональности: одни негативные отзывы могут быть грубыми, другие – холодно‑формальными, третьи – разочарованно‑спокойными, но все они должны очевидно туда относиться. Позитив может быть восторженным, сдержанным, благодарственным. Нейтральные – информационными, сухими, без эмоциональной окраски. Вы как куратор данных решаете, что считать “очевидным” представителем класса.

Теперь перейдём к конкретной задаче и практике.

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

Сначала вы делаете zero‑shot промт. Опишите задачу словами, без примеров. Допустим, вы просите: “Определите тон пользовательского отзыва: негативный, нейтральный или позитивный. В ответе укажите только одно слово: ‘негативный’, ‘нейтральный’ или ‘позитивный’.” Затем подаёте модели реальные отзывы и смотрите на её поведение.

На этом этапе вы быстро увидите типичную картину. В простых случаях модель попадает в нужный тон: откровенный негатив она называет негативом, однозначный позитив – позитивом. Но возникают ошибки на границе: в отзывах с лёгкой иронией, смешанными эмоциями, конструктивной критикой с благодарностью. Например, фраза “Приложение удобное, но баги уже достали” может быть классифицирована как нейтральная или даже позитивная, тогда как для ваших целей это, возможно, негатив: человек жалуется на баги. Или наоборот: “Поддержка ответила с задержкой, но в итоге всё решилось, спасибо” – модель может увести в негатив из‑за слова “задержкой”, хотя общий тон вы считаете скорее позитивным или смешанным.

Теперь вы переходите к few‑shot. В тот же промт вы добавляете несколько carefully picked примеров. Скажем, 3–5 пар “отзыв → правильная метка”. Вы не случайно берёте первые попавшиеся, а отбираете такие, которые:

очень чётко иллюстрируют каждую категорию;

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

явно демонстрируют, как вы хотите интерпретировать смешанные формулировки.

Например, вы можете взять один откровенно негативный отзыв (“Поддержка не отвечает, деньги зависли, очень недоволен”), один однозначно позитивный (“Отличное приложение, пользуюсь каждый день, всё удобно”), один нейтральный (“Установил вчера, пока разбираюсь, ничего особенного сказать не могу”), плюс два сложных: мягкая критика и смешанный тон, и явно указать, к каким классам вы их относите. Этими примерами вы как бы устанавливаете правила игры: “Вот это считается негативом, даже если есть благодарность”, “Вот это – позитив, даже если были мелкие неудобства”.

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

Дальше вы сравниваете точность zero‑shot и few‑shot. Вполне вероятно, что в простых случаях разницы почти не будет. Но именно на пограничных, сложных отзывах few‑shot начнёт выигрывать. Модель увидит, что вы относите “удобное приложение, но куча багов” к негативу, и начнёт чаще воспроизводить этот паттерн. Вы фактически “учите” её вашей внутренней политике интерпретации.

Отдельно полезно зафиксировать свои наблюдения: какие отзывы по‑прежнему классифицируются неверно? Может быть, модель всё ещё путается в сарказме, тонкой иронии, многослойных формулировках. Это подводит нас ко второй части практики – работе с контрпримером.

Контрпример – это специально выбранный сложный случай, который проверяет устойчивость вашей схемы. В нашей задаче это может быть отзыв с сарказмом или смешанным тоном. Например: “О, ещё одно ‘суперудобное’ обновление, после которого приложение вообще не открывается. Браво.” С точки зрения лексики здесь есть слова, которые могли бы намекать на позитив (“суперудобное”, “браво”), но общий смысл – откровенный негатив.

Ваша задача – включить один такой контрпример в набор примеров few‑shot и посмотреть, что произойдёт с остальными ответами. Если вы просто добавите его как “негативный”, модель может начать резче реагировать на сарказм – это хорошо. Но иногда один плохо сформулированный контрпример способен “сломать” баланс: модель начнёт видеть негатив там, где его нет, или, наоборот, станет слишком осторожной.

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

Если вы видите, что добавление контрпримера ухудшило результаты по большей части отзывов, нужно доработать формулировки. Возможно, вам стоит сделать два контрпримера: один с сарказмом, другой с более прямой критикой, и более явно задать критерий: “если общий смысл – недовольство, даже при наличии иронии или благодарности, классифицируйте как негативный”. Либо стоит перенести часть логики в отдельную инструкцию перед примерами: “если в отзыве используется сарказм, оценивайте реальный смысл, а не буквальный текст”.

Смысл этого упражнения в том, чтобы вы на практике почувствовали хрупкость и силу few‑shot. Небольшой набор примеров может радикально улучшить поведение модели, но также легко может ввести систематическую ошибку, если примеры подобраны невнимательно.

Few‑shot‑промты – это по сути микро‑обучающие выборки, которые вы строите вручную. Вы выступаете в роли и заказчика, и дата‑сайентиста, и учителя. Вы решаете, какие паттерны нужно закрепить, а какие – нет. И чем осознаннее вы это делаете, тем ближе ваш промт становится к настоящей модели “под задачу”, только построенной не кодом, а текстом.

Когда вы несколько раз пройдёте полный цикл – zero‑shot → few‑shot с примерами → оценка точности → добавление контрпримера → корректировка формулировок – у вас появится новый тип мышления. Вы перестанете воспринимать промт как разовую команду и начнёте видеть в нём маленький обучающий набор. А это уже серьёзный шаг до “продвинутого пользователя”, а то и настоящему промт‑инженеру, который может подстраивать поведение модели под конкретные бизнес‑задачи и критерии.

ГЛАВА 5. PROMPT CHAINING: СЛОЖНЫЕ ЗАДАЧИ ЧЕРЕЗ ЦЕПОЧКИ ПРОМТОВ

В какой‑то момент вы упираетесь в естественный предел: даже самый сильный, тщательно прописанный промт перестаёт вытягивать сложные задачи “за один присест”. Вы просите модель: “Разработай полноценный курс, продумай структуру, напиши материалы, придумай задания, сделай чек‑листы” – и получаете или поверхностную солянку, или перегруженный, плохо организованный текст. Проблема здесь не в модели и не в вас, а в самой постановке: вы пытаетесь решить многошаговую задачу одним запросом.

Сложные задачи в промт‑инжиниринге нужно разбивать на цепочки. Вы переходите от парадигмы “один запрос – один результат” к парадигме “пайплайн из шагов”. Каждый шаг решает узкую, чётко ограниченную подзадачу, а его результат становится входом для следующего шага. Это и есть prompt chaining – работа с цепочками промтов.

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

В цепочном подходе каждый промт должен быть максимально “узким” и целевым. Ошибка многих пользователей в том, что они делают промежуточные шаги слишком общими и расплывчатыми. В результате каждый шаг превращается в мини‑хаос, и качество итогового решения страдает. Ваша задача – превращать каждый шаг в точную микрозадачу: “только проанализируй аудиторию”, “только предложи структуру”, “только детализируй этот урок”.

Удобная метафора – три типа промтов в цепочке: фильтры, сумматоры и проверяющие.

Промты‑фильтры отбрасывают лишнее и выбирают главное. Они берут необработанный материал – идеи, сырые данные, разрозненные мысли – и превращают их в очищенный, отфильтрованный набор. Например, вы генерируете много идей уроков, а затем отдельным промтом просите: “выбери только те, которые подходят для начинающих”, или “оставь только 5 самых важных тем, убрав дубли и слишком узкие”.