Мастерство промт-инжиниринга. Продвинутый уровень

ГЛАВА 4. FEW‑SHOT, МНОГОПРИМЕРНОЕ ОБУЧЕНИЕ В ПРОМТАХ

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

В машинном обучении обычно говорят о трёх режимах: zero‑shot, one‑shot и few‑shot. Эти термины важны и для промт‑инженера, потому что напрямую описывают, как вы будете объяснять задачу модели.

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

One‑shot – когда вы даёте один пример выполнения задачи. Вы показываете модели пару “вход → желаемый выход” и просите по аналогии обрабатывать новые данные. Этот один пример уже сильно сужает пространство интерпретаций. Вы как будто говорите: “делай так, только для других случаев”.

Few‑shot – это когда вы даёте несколько (обычно от 2–3 до 5–10) примеров. Модель смотрит на них как на мини‑обучающую выборку внутри промта. Она пытается уловить закономерность: что общего у входов, что общего у выходов, как именно вы формулируете ответы, какая структура, какой уровень детализации. И уже на этой основе генерирует ответ для нового входа.

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

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

Во‑первых, примеры должны покрывать типичные, базовые случаи. Если вы обучаете модель классифицировать отзывы по тону, логично дать по одному‑двум понятным, “чистым” примерам для негативного, нейтрального и позитивного тонов. Без иронии, без двусмысленности, без сложных подтекстов. Пусть модель сначала поймёт ядро категорий.

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

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

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

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

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

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

Сначала вы делаете 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 с примерами → оценка точности → добавление контрпримера → корректировка формулировок – у вас появится новый тип мышления. Вы перестанете воспринимать промт как разовую команду и начнёте видеть в нём маленький обучающий набор. А это уже серьёзный шаг до “продвинутого пользователя”, а то и настоящему промт‑инженеру, который может подстраивать поведение модели под конкретные бизнес‑задачи и критерии.