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

Misha Ford

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

ЧАСТЬ I. ФУНДАМЕНТ ПРОДВИНУТОГО ПРОМТ‑ИНЖИНИРИНГА

ГЛАВА 1. КАК РЕАЛЬНО РАБОТАЕТ LLM И ПОЧЕМУ ЭТО ВАЖНО ПРОМТ‑ИНЖЕНЕРУ

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

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

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

Начнём с самого главного вопроса: что же такое LLM в человеческом понимании.

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

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

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

Чтобы управлять этим поведением, нужно понимать ещё одну ключевую вещь: LLM работает на уровне токенов. Токен – это не обязательно слово, а кусочек текста. Иногда это целое слово, иногда часть слова, иногда пробел или знак препинания. Модель на вход получает последовательность токенов, а на выходе генерирует новый токен за токеном.

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

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

Ещё два параметра, которые вы обязаны ощущать на практике, – это температура и top‑p. Они отвечают за степень “хаотичности” и креативности генерации.

Температура – это коэффициент, который влияет на то, насколько модель будет склонна выбирать менее вероятные продолжения текста. При низкой температуре (например, 0–0,2) модель будет очень “консервативной”: она выбирает наиболее предсказуемые варианты. Это хорошо для задач, где нужна стабильность, однообразие и максимальная точность. При высокой температуре (0,7–1,0) модель становится более творческой и непредсказуемой. Она больше готова “рисковать” с выбором слов, структуры, идей. Это полезно для генерации креативных концепций, сторителлинга, необычных формулировок.

Top‑p – это другой способ управлять разнообразием ответов. Вместо того чтобы просто “разогревать” всю вероятность, модель берёт только верхнюю часть распределения: например, выбирает токены, которые в сумме дают 90% вероятности, и игнорирует всё остальное. Комбинация температуры и top‑p даёт вам тонкую настройку того, как именно будет писать модель: строгим, скучным, но точным языком или живым, интересным, но иногда чрезмерно свободным.

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

Теперь вернёмся к “галлюцинациям”. В контексте LLM под этим подразумевают ситуации, когда модель выдаёт неправду, но делает это уверенно, логично и красиво. Причины у этого явления вполне понятные.

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

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

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

Как промт‑инженер вы должны относиться к галлюцинациям не как к случайным “глюкам”, а как к предсказуемой части поведения модели. Управлять этим можно несколькими способами.

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

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

Третье: использовать дополнительные шаги проверки. Например, сначала попросить модель выделить, какие части ответа основаны на общих знаниях, а какие – на предположениях. Или попросить её “покритиковать” собственный ответ, как если бы она искала в нём возможные ошибки.

Наконец, вам нужно понимать, что разные LLM ведут себя по‑разному. GPT‑4/4o, Claude, Llama, Gemini – это не просто разные бренды, а разные архитектуры, обученные на разных данных, с разными приоритетами.

GPT‑4/4o, как правило, сильны в универсальности: хорошо держат структуру, умеют рассуждать, комбинировать разные навыки. Claude часто показывает себя очень сильным в длинных текстах, литературном стиле, анализе больших контекстов. Модели семейства Llama – открытые и гибко настраиваемые, но их качество сильно зависит от конкретной версии и дообучения. Gemini делает акцент на интеграции с экосистемой Google и мультимодальности.

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

Теперь перейдём к практике. Теория без практики в промт‑инжиниринге превращается в бесполезное знание.

Ваше первое практическое задание – почувствовать, как на самом деле влияет температура. Возьмите один и тот же промт. Наилучший тип – задача, где есть место как структуре, так и креативу. Например, можно использовать такой запрос:

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

С этим же текстом выполните четыре прогона: с температурой 0, 0.3, 0.7 и 1.0. Все остальные параметры оставьте неизменными. Ваша задача – не просто посмотреть на ответы, а проанализировать, как меняется их характер.

При температуре 0 вы, скорее всего, увидите очень предсказуемые, иногда даже скучные формулировки. Заголовки будут типовыми, без рискованных идей. При 0.3 текст останется структурным, но появится чуть больше разнообразия. При 0.7 появятся более смелые формулировки, неожиданные обороты. При 1.0 модель может начать выдавать что‑то чрезмерно креативное, иногда граничащее с бессмыслицей или слишком “маркетинговой водой”.

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

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

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

“Проанализируйте этот текст и сделайте подробное структурированное резюме, выделив главные разделы, тезисы и выводы. Отвечайте на русском языке, в формате иерархического списка.”

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

После этого сделайте то, что делает промт‑инженер: разбейте текст на части. Сформулируйте стратегию “chunking” – деления на блоки. Например, вы можете:

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

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

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

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

ГЛАВА 2. СТРУКТУРА СИЛЬНОГО ПРОМТА

На предыдущем уровне вы увидели, как модель думает в токенах, как на неё влияют температура и контекстное окно. Теперь нам нужно перейти от “понимать модель” к “управлять моделью”. И здесь всё начинается со структуры промта.

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

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

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

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

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

Следующий слой – различие между инструкцией, контекстом и примерами. Большинство промтов всё это смешивают в кашу. Ваша задача как промт‑инженера – разделять эти компоненты в голове, а иногда и явно в тексте.

Инструкция – это то, что вы хотите получить: действие и формат. “Составьте текст”, “проанализируйте”, “сравните”, “создайте структуру”. Это команда.

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

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

Наконец, в сильном промте всегда присутствуют явные ограничения и критерии качества. Это то, что отделяет “примерно то, что я хотел” от “ровно то, что нужно”.

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

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

Всё это можно собрать в простой, но мощный фреймворк RICCE: Role, Instruction, Context, Constraints, Examples – Роль, Инструкция, Контекст, Ограничения, Примеры.

Роль задаёт, “кто сейчас говорит”.

Инструкция определяет, “что нужно сделать”.

Контекст объясняет, “в какой ситуации это делается”.

Ограничения устанавливают, “что нельзя и что обязательно”.

Примеры показывают, “как выглядит хороший результат”.

Сначала вы будете держать RICCE в голове, постепенно вы начнёте автоматически писать промты так, чтобы все эти элементы присутствовали – иногда в явном виде, иногда встроенными в текст.

Отдельного разговора заслуживает формат ответа.

Для промт‑инженера формат – это не косметика, а инструмент интеграции. Чем более сложные и автоматизируемые задачи вы решаете, тем важнее становиться управлять формой вывода.

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

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

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

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

Возьмём этот промт и перепишем по RICCE.

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

Инструкция: нужно не просто “написать текст”, а, например, “написать текст главного блока для сайта юридической компании, который должен мотивировать B2B‑клиента оставить заявку на консультацию”.

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

Ограничения: вы прямо прописываете, что нельзя использовать штампы “команда профессионалов”, “индивидуальный подход”, “широкий спектр услуг”. Указываете желаемый объём: заголовок до 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 – поэтапное, цепочечное мышление.