Что такое промпт-инжиниринг
Промпт-инжиниринг — это составление запросов к языковой модели так, чтобы полученный результат можно было использовать без переделки. Не «магические слова», а инженерная работа: у задачи есть вход, выход и критерий приёмки, и промпт — это описание всех трёх.
Слово «инжиниринг» здесь по делу. Разница между запросом, который приходится переписывать пять раз, и запросом, который сразу даёт годный ответ, обычно не в вежливости формулировки, а в том, что во втором заранее продуманы данные, формат и ограничения.
Ниже — принципы, структура и, что важнее, граница, за которой промпт перестаёт помогать.
Основные принципы
К основным принципам промпт-инжиниринга относится шесть правил. Приведены по убыванию влияния на результат, а не в порядке из учебников.
| Принцип | Что это значит | Что происходит без него |
|---|---|---|
| Одна задача на запрос | не «проанализируй и напиши», а сначала одно, потом второе | модель делает обе задачи наполовину |
| Данные, а не описание данных | вставить сам текст, таблицу, список — не пересказ | модель додумывает недостающее и выдаёт правдоподобное |
| Явный формат ответа | таблица с такими-то колонками, список из пяти пунктов, JSON с такими полями | каждый ответ приходит в новом виде, автоматизировать нельзя |
| Ограничения и запреты | чего быть не должно: длины, оборотов, тем | заполнение объёма общими словами |
| Критерий приёмки | по какому признаку вы поймёте, что ответ годный | спор о вкусах вместо проверки |
| Примеры | один-два образца желаемого результата | приходится объяснять словами то, что показывается за десять секунд |
Второй пункт нарушают чаще всего. «Проанализируй мою нишу» — это просьба к модели придумать нишу; «вот пятьдесят запросов с частотностью, сгруппируй по смыслу» — задача с данными. Первое даёт красивый текст ни о чём, второе — рабочий результат.
Структура рабочего промпта
Порядок частей значения почти не имеет, наличие — имеет.
- Роль и рамка. Кто отвечает и в каких границах. Одна строка, не абзац: длинные описания роли добавляют меньше, чем принято думать.
- Задача. Одно действие, глаголом. «Сгруппируй», «перепиши», «найди противоречия».
- Данные. Сам материал, отделённый от инструкции — например, тройными кавычками или разделителем. Модель должна видеть, где кончается указание и начинается текст для обработки.
- Формат. Как должен выглядеть ответ. Если результат пойдёт в программу — жёсткая схема; если человеку — количество пунктов и их длина.
- Ограничения. Чего не делать. Здесь же — что делать при нехватке данных: «если сведений недостаточно, напиши, чего не хватает, вместо предположения». Эта строка убирает большую часть выдуманного.
- Критерий приёмки. «Ответ годен, если каждая строка подтверждается фрагментом исходного текста».
Последний пункт добавляют реже всего, а он экономит больше всего времени: он превращает проверку из чтения по диагонали в сверку по списку.
Один запрос до и после
Живой пример из моей работы. Задача: собрать план статьи, которая должна конкурировать с теми, кто уже в топе.
Было:
Что приходило: восемь разделов, у всех правдоподобные названия, содержание — пересказ того же, что уже написано у сотни авторов. Использовать нельзя: статья по такому плану ничем не отличается от конкурентов, а значит, не имеет причины ранжироваться выше.
Стало:
Задача: собрать план статьи.
Данные: ниже — заголовки H2 из пяти страниц, занимающих топ по запросу «как собрать семантическое ядро», и объём каждой в словах. Дальше — список запросов кластера с точной частотностью. Дальше — мои собственные данные по теме: цифры сбора ядра для одного проекта.
Формат: таблица «раздел — что в нём — какой запрос закрывает — есть ли это у конкурентов».
Ограничения: не предлагать разделов, которых нет ни у кого из пяти и которые не закрывают ни одного запроса из списка. Отдельной строкой отметить, где у меня есть данные, которых у конкурентов нет.
Критерий приёмки: не меньше двух разделов, которых нет ни у кого из пяти, и оба опираются на мои данные.
Разница не в длине. В первом варианте модель работала по памяти о теме, во втором — по данным, которых до этого не видела. Причём главную ценность дала не сама модель, а строка про «мои данные»: она заставила поставить в план то, чего у конкурентов физически нет.
Чего от модели требовать нельзя
Здесь проходит граница, о которой в руководствах по промптам почти не пишут.
Промпт не заменяет данных, которых у модели нет. Никакой формулировкой не получить частотность запросов в Москве за прошлый месяц: этих цифр в модели нет, и на настойчивую просьбу она выдаст правдоподобные. Правдоподобные цифры хуже, чем никаких, потому что их не отличить на глаз.
Мой рабочий пример. Кластеризацию семантики — разбиение запросов на группы под будущие страницы — соблазнительно поручить модели: она отлично группирует «по смыслу». И это неверный ответ. Кластер определяется не смыслом, а тем, показывает ли поисковик по двум запросам одни и те же страницы. Модель выдачи не видит. Её группировка выглядит убедительно и разваливается на практике: разные по интенту запросы попадают на одну страницу, а страницы начинают конкурировать между собой.
Правильное решение — не улучшать промпт, а отдать модели ту часть, где она сильна, а данные о выдаче взять инструментом, который умеет их получать.
Отсюда общее правило: прежде чем улучшать формулировку, спросите, есть ли у модели то, из чего она может сделать ответ. Если нет — задача не про промпт, а про инструмент.
Второй случай той же природы — задачи, где нужна точность повторения. Расчёты, сверки, любая арифметика на больших объёмах. Модель ошибается редко, но незаметно, и проверять её приходится тем же трудом, который вы хотели сэкономить.
Разовый вопрос и повторяющаяся задача
Это разные жанры, и путать их дорого.
| Разовый вопрос | Повторяющаяся задача | |
|---|---|---|
| Цель | получить ответ сейчас | получить одинаковое качество сто раз |
| Как пишется | свободно, уточняется в диалоге | фиксированный шаблон с подстановкой данных |
| Формат ответа | любой | жёсткий, машиночитаемый |
| Как проверяется | глазами | выборкой на десяти прогонах |
| Что важно | полнота | предсказуемость |
Для повторяющейся задачи промпт становится частью программы, и к нему применимы обычные инженерные требования: он версионируется, у него есть тесты, его изменение — это изменение кода, а не правка текста. Промпт, который «вроде стал лучше», без замера на тех же входных данных — это не улучшение, а замена одного неизвестного на другое.
Промпт для повторяющейся задачи проверяется так же, как код, — на наборе примеров, а не на впечатлении.
Соберите десять типовых входов, включая два-три неудобных: пустые данные, слишком длинный текст, случай с противоречием внутри. Прогоните старый и новый вариант на одном и том же наборе. Считайте два числа: сколько ответов пригодны без правок и сколько содержат утверждения, которых нет во входных данных.
Второе число важнее первого. Промпт, который стал давать более красивые ответы и при этом начал добавлять от себя, стал хуже, а не лучше — просто это заметно не сразу.
Прогонять надо на одних и тех же входах: сравнение «вчера на одной задаче, сегодня на другой» не значит ничего.
Частые вопросы
Правда ли, что длинный промпт всегда лучше короткого?
Нет. Работает не длина, а наличие данных, формата и ограничений. Длинные описания роли и просьбы «подумай хорошенько» добавляют мало; вставленный в запрос реальный материал меняет результат радикально.
Нужно ли обещать модели вознаграждение или писать «это очень важно»?
Приёмы такого рода кочуют по руководствам с первых лет работы с моделями. На современных моделях они дают немного, а иногда мешают: эмоциональная накачка сдвигает ответ в сторону уверенного тона, а уверенный тон при нехватке данных — это ровно то, чего вы пытаетесь избежать.
Промпт-инжиниринг — это надолго, или модели скоро перестанут его требовать?
Формулировать простые запросы действительно приходится всё меньше: модели лучше достраивают недосказанное. Не исчезает другая половина работы — решить, какие данные модели дать, в каком виде принять ответ и как проверить, что он верен. Это не про формулировки и не устаревает.
Где промпт-инжиниринг применим в SEO?
Там, где есть свои данные и понятный критерий приёмки: разбор выгрузок из Вебмастера, поиск противоречий между страницами, черновики мета-описаний по заданному шаблону, план материала против конкретных конкурентов. И почти не применим там, где нужны внешние измерения — частотность, позиции, состав выдачи. Подробнее о том, где проходит эта граница в работе с агентами, — в разборе что такое ИИ-агент.
Стоит ли учиться промпт-инжинирингу отдельно?
Как отдельной профессии — вряд ли: это навык внутри чьей-то работы, а не работа сама по себе. Практическое руководство здесь заменяется практикой: возьмите одну свою повторяющуюся задачу, доведите промпт под неё до состояния «результат не требует правок в девяти случаях из десяти», и вы узнаете о принципах больше, чем из любого курса.