Промпт, который оценивает звонки менеджеров тысячу раз в день, по одной расплывчатой фразе ставит одному «хорошо», а другому за такой же разговор «плохо» — и по этим оценкам потом делят премии. Промпт для бизнес-задачи — это инструкция нейросети, встроенная в повторяемый процесс: от её формулировки зависит, будет ли результат воспроизводимым и можно ли на него опираться без ручной проверки каждого ответа. Разовый запрос в чате и промпт для процесса — разные жанры, и ниже разберу, из чего собирается второй, как его проверять и где формулировкой ничего не исправить.
Разовый запрос и промпт для процесса — разные жанры
В разовом запросе достаточно объяснить своими словами, что нужно: результат тут же читает человек, и если что-то не так, он переспросит. В процессе переспрашивать некому. Промпт выполняется сотни и тысячи раз без надзора, его ответы попадают в CRM, отчёт или сообщение клиенту, и ошибка тиражируется раньше, чем её кто-то заметит.
Отсюда другое требование к качеству. Для разового запроса хорош ответ, который полезен. Для процесса хорош ответ, который на одинаковом входе одинаков, на спорном входе предсказуем, а на входе без данных честно говорит «не могу оценить». Вся дальнейшая инженерия — про эти три свойства.
Пять частей, без которых результат плавает
Рабочий промпт для повторяемой задачи почти всегда содержит одни и те же блоки. Пропуск любого из них проявляется одинаково: результат «в среднем нормальный», но нестабильный от запуска к запуску.
1. Роль и контекст. Кто отвечает и в какой ситуации. Не «ты эксперт мирового уровня», а конкретно: «ты разбираешь обращения в поддержку интернет-магазина бытовой техники».
2. Что подаётся на вход. Явно назовите, что именно будет передано: текст обращения, расшифровка звонка, выдержка из договора. Модель должна понимать границы данных.
3. Правила и границы. Что делать нельзя, что считать сомнительным случаем, как поступать при нехватке информации. Этот блок забывают чаще всех — и получают уверенные ответы там, где данных не было. Почему модель в таком случае не молчит, а достраивает, разобрано в статье о том, почему нейросеть выдумывает.
4. Формат ответа. Для процесса ответ должен быть машиночитаемым: перечисленные поля, допустимые значения, что писать, если значение определить нельзя. Свободный текст в автоматизации — источник постоянных сбоев на разборе.
5. Примеры. Два-три разобранных случая, включая один пограничный. Примеры работают лучше любых объяснений: они показывают решение, а не описывают его.
Пример: от расплывчатого к рабочему
Расплывчато: «Проанализируй звонок и скажи, хорошо ли отработал менеджер».
Рабочий вариант: «Ты специалист отдела контроля качества в компании, которая продаёт бухгалтерское ПО. На входе — расшифровка телефонного разговора менеджера с клиентом. Оцени разговор по четырём критериям: выявлена ли потребность, названа ли цена, обработано ли возражение, назначен ли следующий шаг с конкретной датой. По каждому критерию ответь "да", "нет" или "не применимо" и приведи цитату из разговора как обоснование. Если критерий невозможно оценить по расшифровке — ставь "не применимо" и не додумывай. Ответ верни полями: критерий, оценка, цитата».
Разница не в длине, а в том, что второй вариант можно применить тысячу раз и получить сравнимые между собой результаты. Требование цитаты тут не украшение: оно заставляет модель искать опору в тексте и даёт человеку способ проверить оценку за секунды. Как формулировать сами критерии, чтобы их вообще можно было проверить по расшифровке, — в статье о скрипте, который может проверить AI.
Вежливость, склейка задач и ещё две ошибки формулировки
Вежливость вместо точности. «Пожалуйста, постарайся учесть» — модель не понимает степень настойчивости. Требование должно быть требованием: «оцени только по расшифровке, внешние данные не используй».
Несколько задач в одном промпте. «Оцени звонок, составь резюме и предложи скрипт» — качество проседает на всех трёх. Разделите на шаги, каждый со своим промптом и своим форматом ответа.
Нет инструкции на случай нехватки данных. Без явного «пиши: недостаточно данных» модель почти всегда придумает правдоподобный ответ. Это не дефект модели, это дефект инструкции.
Нет проверки после правок. Промпт меняют «чуть-чуть», и незаметно ломается то, что работало. Об этом — два раздела ниже.
Что делать, когда ответы «плавают»
Типичная жалоба после запуска: на одном и том же входе система выдаёт то один результат, то другой. Причин обычно три, и лечатся они по-разному.
Расплывчатая формулировка требования. Если инструкция допускает два прочтения, модель будет выбирать между ними случайным образом. Лечится не длиной текста, а однозначностью: вместо «оцени качество разговора» — список критериев с фиксированными вариантами оценки.
Настройка случайности. У большинства моделей есть параметр, отвечающий за разнообразие ответов. Для творческих задач он полезен, для классификации и извлечения данных его ставят в минимум — и разброс сразу падает.
Пограничные случаи без правила. Когда вход не подходит ни под один описанный вариант, модель импровизирует. Добавьте явную ветку «если ни один вариант не подходит» — и импровизация прекратится.
Диагностику я бы начинал с простого теста: прогнать один и тот же вход пять раз подряд. Если ответы расходятся на одном и том же критерии, дело в формулировке этого критерия, а не в модели целиком.
Почему длинный промпт работает хуже короткого
Естественная реакция на ошибку — дописать ещё одно уточнение. Через полгода промпт занимает три страницы, а качество не растёт и часто падает. Это закономерность, а не невезение.
Причин две. Первая: чем больше инструкций, тем слабее каждая из них влияет на результат — внимание распределяется, и требование из середины длинного текста выполняется хуже, чем то же требование в коротком. Механика та же, что у длинных документов, она разобрана в статье о контекстном окне. Вторая: накопленные уточнения начинают противоречить друг другу, и модель разрешает противоречие по-своему, каждый раз непредсказуемо.
Практический приём — периодическая чистка. Раз в квартал пройдите по промпту и по каждому требованию спросите: помню ли я, зачем это добавлено, и сломается ли что-нибудь, если убрать. Многие строки не проходят уже первый вопрос. Убирать их надо по одной, с прогоном эталонов после каждой.
Когда правка чинит одно и ломает другое
Типичная ситуация: добавили уточнение, чтобы исправить конкретную ошибку, — она исчезла, а через неделю выяснилось, что перестало работать что-то другое. Без набора эталонов это обнаруживается случайно и через месяцы.
Механизм понятен: инструкции влияют не только на тот случай, ради которого добавлены. Требование «отвечай кратко» чинит многословие и одновременно обрезает нужные детали в сложных ответах.
Отсюда правило работы: любая правка прогоняется на полном наборе эталонов, а не только на том случае, который чинили. И правки вносятся по одной. Две одновременные правки, ухудшившие результат, невозможно разделить — придётся откатывать обе и начинать заново.
Те же принципы работают и в повседневных задачах одного сотрудника, где промпт пишется в чате, а не хранится в системе: материал на вход, ограничения по формату, проверка результата. Как это выглядит в работе продавца — от выжимки о компании клиента до письма после звонка, — в статье о нейросетях для менеджера по продажам.
Где живут формулировки и кто за них отвечает
Промпт для процесса — часть системы, а не заметка. Пока он живёт в переписке или в интерфейсе сервиса, у него нет ни истории, ни автора, ни возможности вернуться к прошлой версии.
Минимальные требования те же, что к любому рабочему документу. Хранение в одном месте с историей изменений. Отметка, кто, когда и зачем менял, — одна строка на правку. Возможность вернуть предыдущую версию за минуту, а не восстанавливать по памяти. В Эхо, например, промпты скоринга звонков настраиваются под скрипт отдела без программиста и хранятся версиями.
Отдельно — вопрос авторства, и здесь у меня твёрдая позиция. Формулировки, описывающие содержание работы, пишет тот, кто в этой работе разбирается: специалист по контролю качества, юрист, руководитель поддержки, а не разработчик. Разработчик отвечает за то, как это встроено, и за проверки. Смешение ролей даёт промпт, который технически исправен и содержательно не о том.
Чего промптом добиться нельзя
Часть проблем формулировкой не решается, и попытки их так решить съедают недели. Полезно знать границу заранее.
Промпт не добавит знаний, которых у системы нет. Если нужный факт не передан в запросе и не найден в документах, никакая инструкция не заставит модель его узнать — она либо признает незнание, либо достроит. Промпт не сделает результат строго воспроизводимым: разброс уменьшается, но не исчезает.
И промпт не заменит проверку там, где цена ошибки высока. Формулировка «будь особенно внимателен» не является механизмом контроля. Если ошибка стоит дорого, нужен отдельный шаг проверки — сверка с источником, второй проход, подтверждение человеком, — а не более настойчивая просьба.
Когда хватит запроса своими словами
Честно о границах. Вся описанная инженерия — эталоны, версии, прогоны — окупается только там, где промпт выполняется много раз и его результат идёт в работу без человека. Если сотрудник раз в неделю просит нейросеть сократить письмо или набросать план встречи, строить для этого набор эталонов не нужно: он сам прочитает ответ и поправит. Время на формализацию здесь дороже любой ошибки.
Не стоит начинать с промпта и там, где процесс ещё не описан словами. Если руководитель отдела не может сформулировать, чем хороший звонок отличается от плохого, модель тоже не сможет: промпт лишь закрепит неопределённость в виде уверенных оценок. Сначала договориться о критериях между людьми, потом переводить их в инструкцию. Мы в 404ai именно с этого начинаем разбор задачи: какой результат нужен и по какой метрике его проверять, — а формулировки появляются потом.
Как проверять промпт как код
Как только промпт становится частью процесса, к нему применимы обычные инженерные практики. Минимальный набор такой.
- Набор эталонов. 30–50 реальных случаев с ответами, размеченными руками. Это ваш тест.
- Прогон после каждой правки. Изменили формулировку — прогнали набор, сравнили долю совпадений. Стало хуже — откатили.
- Отдельное внимание пограничным случаям. Именно на них проявляется разница между «работает» и «работает надёжно».
- Версионирование. Промпт хранится рядом с кодом и меняется через ту же процедуру, что и код: с историей и возможностью откатиться.
Как такая проверка выглядит перед выпуском агента к клиентам, разбирали в статье про тестирование агента перед запуском.
С чего начать промпт для бизнес-задачи на своих данных
Главное, что меняет этот подход: качество промпта для процесса оценивается не на глаз по трём удачным ответам, а долей совпадений с разметкой человека на наборе реальных случаев. Начать можно за один день. Возьмите тридцать реальных случаев, разметьте правильные ответы руками, прогоните текущий промпт и посчитайте долю совпадений. Эта цифра — ваша точка отсчёта: любая правка, которая её не поднимает, не нужна, а любая, которая её роняет, откатывается. Если после нескольких правок доля совпадений не растёт, проблема не в формулировке, а в том, что у самой задачи нет однозначного правильного ответа, — и её сначала нужно решить между людьми.
