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

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

Ограничения: вы прямо прописываете, что нельзя использовать штампы “команда профессионалов”, “индивидуальный подход”, “широкий спектр услуг”. Указываете желаемый объём: заголовок до 10–12 слов, подзаголовок до 20–25 слов, основной текст до 400–600 знаков. Обозначаете стиль: без канцелярита, конкретно, с фокусом на рисках и их снижении, без перегруженных юридических терминов.

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

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

Теперь перейдём к практике.

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

Сначала самостоятельно сформулируйте:

какую роль вы задаёте модели (например, “маркетолог, который пишет B2B‑тексты для юридических компаний”);

какую конкретную инструкцию вы даёте (какой именно блок сайта, какая цель – например, увеличение заявок);

какой контекст нужно добавить (тип юридических услуг, целевая аудитория, особенности рынка или компании);

какие ограничения по стилю, длине, словам стоит ввести;

какие 1–2 примера фраз вам нравятся и могут служить ориентирами.

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

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

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

{

"segment_name": "…",

"pain_points": ["…", "…"],

"desired_outcomes": ["…", "…"],

"decision_maker": "…",

"typical_objections": ["…", "…"]

}

Ваша задача – написать промт, который:

задаёт нужную роль (например, “вы – маркетолог, который помогает структурировать целевую аудиторию юридической компании в формате JSON”);

даёт чёткую инструкцию: “на основе описания компании ниже создайте ОДИН JSON‑объект по следующей схеме”;

приводит контекст (краткое описание юридической компании и её специализации);

задаёт ограничения: “никакого текста вокруг JSON, никаких комментариев, только один валидный JSON‑объект, поле pain_points – массив строк, поле desired_outcomes – массив строк и т.д.”

Когда вы получите ответ, внимательно проверьте:

добавила ли модель что‑то вроде “вот JSON‑структура”

соблюдена ли схема: нет ли лишних полей, все ли поля заполнены, нет ли пустых объектов

корректен ли JSON – парсится ли он без ошибок.

Если модель всё равно добавляет текст вокруг JSON, попробуйте усилить ограничения. Например, вы можете добавить формулировку: “если вы добавите хоть один символ вне JSON‑объекта, ответ считается неверным”, “начните ответ сразу с символа { и завершите только закрывающей фигурной скобкой }”. Иногда полезно добавить фразу: “не используйте тройные кавычки, не используйте Markdown, не добавляйте пояснений”.

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

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

ЧАСТЬ II. КЛЮЧЕВЫЕ ТЕХНИКИ ПРОМТ‑ИНЖИНИРИНГА

ГЛАВА 3. CHAIN‑OF‑THOUGHT И ПОЭТАПНОЕ МЫШЛЕНИЕ

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

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

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

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

Разница между “дай ответ” и “объясни ход рассуждений” критична.

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

Однако важно понимать, что Chain‑of‑Thought – не серебряная пуля. Бывают случаи, когда он действительно повышает качество, а бывают – когда только тормозит работу и засоряет ответ лишними словами.

Где CoT особенно полезен? В задачах, где есть несколько ограничений, пересекающиеся условия, trade‑off’ы и необходимость выбрать лучший вариант среди разных альтернатив. Например, когда вы подбираете маркетинговую стратегию с ограниченным бюджетом и несколькими целями; когда нужно приоритизировать фичи продукта; когда вы решаете логическую головоломку; когда разбираете сложные сценарии поведения пользователя. В таких случаях поэтапное мышление помогает модели не потерять условия, а вам – увидеть, где она исказила или забыла важную деталь.

Где CoT может только мешать? В простых, рутинных задачах, где вам нужен быстрый, короткий ответ: переписать абзац, сделать краткое резюме, предложить пару вариантов заголовков. Если каждый раз заставлять модель “думать по шагам” там, где достаточно одного шага, вы будете тратить контекст, время и своё внимание на лишние объяснения. Более того, иногда излишнее “рассуждение” провоцирует модель усложнять то, что можно решить просто.

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

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