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

Сначала сформулируйте “простой” промт без Chain‑of‑Thought. Например: “Предложите маркетинговую стратегию для нашего финтех‑приложения для молодёжи с ограниченным бюджетом. Укажите основные каналы, примерное распределение бюджета и ожидаемый эффект”. Модель, скорее всего, выдаст вам приличный, но поверхностный ответ: перечислит соцсети, блог, таргет, блогеров, возможно, упомянет партнёрства с вузами. Что обычно происходит в таком сценарии?

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

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

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

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

Теперь важно научиться формулировать Chain‑of‑Thought не в одном‑двух шаблонных вариантах, а гибко. Вам не нужно всегда писать одно и то же “подумай шаг за шагом”. Иногда эффективнее задавать более содержательные подсказки: “подумай как…”, “пошагово проанализируй…”, “сначала сформулируй критерии, затем выбери…”. Каждая из этих конструкций задаёт немного разный стиль мышления модели.

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

Вторая формулировка – “пошагово проанализируй…”. Здесь вы прямо указываете, что хотите видеть анализ в виде последовательных шагов. Например: “Пошагово проанализируйте возможные маркетинговые каналы для нашего продукта: сначала перечислите все релевантные каналы, затем оцените каждый по критериям ‘стоимость’, ‘скорость результата’, ‘точность попадания в целевую аудиторию’, затем сделайте вывод о том, какие 2–3 канала стоит выбрать в первую очередь и почему”. Вы не только просите пошаговый анализ, но и даёте структуру этого анализа. Это уже более строгий CoT.

Третья формулировка – “сначала сформулируй критерии, затем выбери…”. Это особенно мощный приём. Он заставляет модель сначала зафиксировать “правила игры”, а уже потом совершать выбор по этим правилам. Например: “Сначала сформулируйте критерии, по которым следует выбирать маркетинговые каналы для нашего финтех‑приложения с ограниченным бюджетом. Затем, используя только эти критерии, выберите 3 приоритетных канала и объясните, как каждый из них удовлетворяет сформулированным критериям”. Здесь вы вводите важный принцип: модель не просто выбирает что‑то “из головы”, а якобы опирается на явные критерии, отражённые в тексте.

Ваше практическое задание в этой главе состоит из двух частей.

Сначала возьмите задачу с несколькими ограничениями. Хороший пример – тот же выбор маркетинговой стратегии с бюджетными лимитами. Сформулируйте простой промт без Chain‑of‑Thought: дайте модели описание продукта, аудитории, бюджета и попросите “предложить маркетинговую стратегию”. Получите ответ и сохраните его. Затем перепишите промт, добавив явное требование мыслить поэтапно: опишите, какие шаги вы хотите видеть – анализ, критерии, набор вариантов, оценка, итоговое решение. Получите второй ответ. Сравните их не глазами “понравилось – не понравилось”, а с точки зрения логики: где модель лучше учитывает ограничения, где яснее приоритизирует, где меньше внутренних противоречий.

Во второй части задания придумайте три собственные формулировки CoT, которые вы будете использовать в работе. Например, одна – в стиле “подумайте как [роль] и по шагам разберите…”, вторая – “пошагово проанализируйте…”, третья – “сначала сформулируйте критерии, затем выберите…”. Протестируйте их на разных задачах: не только в маркетинге, но и, скажем, в продуктовой аналитике, планировании обучения, выборе архитектуры решения. Сравните, как разные фразы влияют на структуру ответа.

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

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

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

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

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

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

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

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

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

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

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

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