Меня зовут Полина Белокрыс, я промпт-инженер в hh.ru. Моя команда развивает ИИ-ассистента для работодателей, который берёт на себя рутинные задачи и помогает бизнесу сосредоточиться на главном — внимательной работе с подходящими кандидатами. В этой статье расскажу, как на самом деле устроен промптинг в продакшене — и почему написать промпт сложнее, чем просто поболтать с ChatGPT*.
Название статьи — «Инженер против попугая» — выбрано не случайно. Это отсылка к метафоре «стохастический попугай», которая используется ИИ-скептиками. Термин подчёркивает стохастическую природу генеративных моделей: они предсказывают следующий токен и генерируют грамматически правильный текст, но не понимают его истинный смысл. Именно поэтому хороший промпт-инженер должен не просто описать задачу модели, а схлопнуть её вероятностную природу с помощью ограничений, тестирования и структурирования промптов — так делаем и мы в hh. При продумывании промпт-систем важно попытаться выстроить пространство с детерминированным контекстом, чтобы модель с его помощью генерировала предсказуемые, безопасные ответы.
Эта статья будет полезна промпт-инженерам, начинающим ML-инженерам и инженерам GenAI, которые работают с языковыми моделями и хотят лучше понимать, как пишутся промпты для продуктовых систем.
Разница между промптами в быту и в продакшене
Когда мы используем языковые модели в повседневной жизни, взаимодействие устроено достаточно просто. Мы задаём в диалоговом окне вопрос, получаем ответ, уточняем формулировки и просим модель что-то изменить или дополнить. Если результат нас не устраивает, мы можем сразу же переформулировать запрос или вовсе начать новый диалог.
В продакшене всё работает иначе. Здесь промптинг — это разветвлённые схемы из нескольких (иногда десятков) промптов, каждый из которых может содержать сотни строк инструкций, структурированные данные, tool calling и и многое другое. Можно сказать, в промптинге есть что-то от алхимии — в нём есть место для вариативности и экспериментов. Но в продуктах масштаба hh.ru такие промпты пишутся согласно строгим требованиям, поскольку модель должна выдавать качественный, предсказуемый и безопасный результат для тысяч разнообразных пользовательских сценариев.
Именно поэтому работа промпт-инженера напоминает программирование: мы не просто формулируем запрос, а проектируем системы взаимодействия между моделью, данными и пользователями.
Поделюсь опытом hh.ru, как мы пишем и тестируем промпты для продакшена.
Пишем хороший промпт: что нужно учесть
Пишите инструкции на английском, а примеры приводите на русском
Хорошая практика — писать инструкцию для модели на английском, а примеры пользовательских данных или диалогов оставлять на русском. Значительная часть обучающих данных языковых моделей — англоязычная, поэтому инструкции на английском языке интерпретируются ими точнее и стабильнее.
Есть и сугубо экономический аспект: английский текст часто занимает меньше токенов. А, значит, промпт становится дешевле и быстрее в обработке. В продакшене, где модель может вызываться тысячи или даже миллионы раз в день, даже небольшая разница в размере промпта начинает ощутимо влиять на стоимость и производительность системы.
При этом примеры пользовательских сообщений лучше приводить на языке продукта, поскольку именно так модель сможет корректнее сопоставлять инструкцию и реальные пользовательские данные.
Используйте фреймворки
При написании промптов удобно использовать фреймворки, которые помогают систематизировать инструкцию для модели. Их названия могут отличаться, но логика обычно остаётся схожей: необходимо задать роль модели, описать контекст задачи и сформулировать ожидаемый результат.
Правильный промпт содержит несколько ключевых элементов: роль модели, цель, задача, контекст задачи, алгоритм действий для её решения, ограничения, формат ответа.
Размечайте текст инструкции
Не забывайте про разметку (markdown или xml). Она делает промпты эффективнее, особенно когда промпт обрабатывает сложные многошаговые задачи. Языковые модели обучаются на огромных массивах размеченных данных и воспринимают синтаксис разметки (заголовки, списки, выделение жирным) как структурные сигналы, которые снижают неоднозначность и улучшают понимание инструкции.
Приводите примеры (но осторожно)
Примеры — один из самых эффективных инструментов при написании промптов. Вы можете приводить не только примеры нужного аутпута, но и примеры того, какие шаги размышлений должна предпринять модель, чтобы прийти к нужному результату.
Однако, с примерами нужно быть крайне осторожными. Модель может либо начать дословно воспроизводить формулировки из примеров, либо смотреть на весь входящий контекст через их призму, бездумно подгоняя всё под показанный шаблон.
Когда-то в системном промпте нашего диалогового агента мы привели пример, как можно задавать кандидату уточняющие вопросы. Один из этих вопросов звучал так: «Готовы ли вы к командировкам в Рязань?». После этого модель начала периодически задавать вопрос про Рязань кандидатам даже в тех вакансиях, где о командировках вообще ничего не говорилось. Работодатели закономерно недоумевали, получая вопрос про Рязань, поэтому промпт пришлось оперативно переписать.
Этот случай хорошо показывает, что модель может начать буквально воспроизводить приведённые примеры, поэтому к их формулировке нужно относиться очень внимательно. Мы быстро нашли ошибку и исправили её, и ИИ-ассистент больше не обсуждает командировки там, где это неуместно.
Запрещайте и ограничивайте
Рассчитывать на то, что модель самостоятельно разберётся с незнакомой ситуацией, не стоит: всё, что не прописано явно, потенциально может быть обработано неверно. Поэтому заранее подумайте об ограничениях.
Если этого не сделать, пользователи могут легко увести диалог в сторону. В логах нашего агента мы регулярно встречали ситуации, когда кандидаты пытались использовать бота не по назначению: просили написать код на Java, спрашивали его мнение о других компаниях или пытались завести разговор на отвлечённые темы.
В одном из таких случаев пользователь спросил бота, что он думает о работе в известной российской компании. Модель ответила, что не хотела бы туда устраиваться, потому что не желает быть «винтиком большой корпорации». С точки зрения продукта такой ответ очевидно рискованный, поэтому нам пришлось прямо прописать в промпте ограничения: бот не должен высказывать собственное мнение о других компаниях (да и вообще о чём-либо) и выполнять ассистентские действия, если об этом просит пользователь.
Не бойтесь писать большой промпт
При написании промпта могут возникнуть опасения, что длинный текст, изобилующий правилами и примерами, запутает модель. На самом деле, длинный промпт сам по себе не проблема: современные модели справляются с большими объёмами инструкций.
Проблема возникает тогда, когда в промпте путается сам его автор: правила начинают противоречить друг другу, структура размывается. Запутанная инструкция рождает непредсказуемое поведение. Поэтому главный критерий хорошего промпта — это не краткость, а внутренняя согласованность и ясный запрос.
Используйте «размышления» модели
Просить модель рассуждать вслух полезно по двум причинам.
Во-первых, это помогает при отладке и калибровке промпта: анализ внутренней «логики» модели (не забываем, что на самом деле человеческой «логики» у моделей нет) позволяет понять, как она интерпретирует задачу, где ошибается и что стоит скорректировать в инструкции.
Во-вторых, рассуждения улучшают качество самого ответа. Если перед финальным ответом попросить модель проанализировать контекст и пошагово обдумать задачу, она с гораздо большей вероятностью придёт к правильному результату.
Помните про cut-off date
У каждой языковой модели есть дата отсечения знаний — момент, до которого она обучалась. Всё, что произошло позже, модель не знает.
Это важно учитывать, когда модель работает с чем-то, что зависит от актуального контекста. Например, если промпт просит оценить опыт кандидата, а модель считает, что сейчас всё ещё 2025 год, она может некорректно рассчитать стаж или оценить релевантность опыта.
Поэтому, если задача требует привязки к текущему моменту, явно передавайте модели нужный контекст: нынешнюю дату, актуальные данные, свежую информацию о предметной области. Рассчитывать на то, что модель «и так знает», не стоит.
Расположение частей инструкции
Порядок блоков внутри промпта тоже может влиять на результат. Иногда модель лучше выполняет инструкции, если важные правила находятся в начале текста или наоборот, в самом конце. Согласно исследованиям, внимание модели может снижаться в середине промпта. Это явление называют U-shaped attention bias: LLM лучше воспринимает начало и конец инструкции и может «потерять» середину.
Экспериментируйте с параметрами
Помимо текста промпта, на поведение модели сильно влияют параметры генерации: температура, top-p, top-k, repetition penalty.
Допустим, ваш агент для рекрутинга рассылает кандидатам первое сообщение — краткий питч вакансии с условиями и требованиями. Если команда решила не персонализировать его под каждого кандидата, но хочет избежать одинакового текста в рассылке, можно заранее сгенерировать несколько вариантов при повышенной температуре и случайно выбирать один из них при каждой отправке.
Важно не забывать о балансе: высокая температура увеличивает разнообразие ответов, но одновременно повышает вероятность галлюцинаций.
Разные модели — разные промпты
Каждая модель имеет свою специфику — и промпт, который отлично работает с одной, может совсем не подойти другой. Иногда приходится переписывать промпт практически с нуля: менять язык инструкции, порядок блоков, количество примеров. Там, где одна модель справляется без лишних подсказок, другой может понадобиться инструкция в три раза больше и с подробными примерами.
При выборе или смене модели всегда закладывайте время на переработку промптов — переносить их as is почти никогда не получается. И это нормально: разные модели хорошо справляются с разными задачами, и под каждую стоит искать свой подход.
Тестируем промпт: полезные советы
Результаты работы модели может быть сложно воспроизвести
При тестировании LLM важно учитывать: их поведение не полностью детерминировано. Даже если использовать один и тот же запрос и одинаковые параметры генерации, ответы модели могут немного различаться, поскольку мы никогда до конца не контролируем генеративную составляющую. Но тестирование на больших датасетах и постоянный мониторинг сводят риски к приемлемому минимуму, и они не влияют на качество продукта.
Для проверки качества нужно много прогонов
Из-за этой особенности пары тестовых запусков недостаточно. Чтобы понять, насколько хорошо работает промпт, необходимо запускать его много раз на большом количестве примеров. Если протестировать систему только на паре-тройке кейсов, можно получить лишь ложное ощущение стабильности.
Подобно юнит-тестам в классическом тестировании, для оценки качества промпта важно постараться покрыть разнообразные пользовательские сценарии и подобрать на каждый из них по несколько кейсов. И каждый из кейсов прогнать неоднократно.
Датасет должен регулярно пополняться
Один из самых ценных источников данных для тестирования — пользовательские логи. Реальные пользователи взаимодействуют с моделью гораздо более разнообразно, чем может предусмотреть инженер. Поэтому нужно регулярно мониторить пользовательское поведение и ошибки модели, обогащая датасеты для проверки качества промптов, их связок, качества работы LLM на разных сценариях пользовательского поведения.
Тестировать нужно в условиях, максимально приближенных к продовым
Языковые модели очень чувствительны к формату входных данных, и даже небольшие изменения могут повлиять на результат. Поэтому не стоит усложнять себе и без того непростую задачу, пытаясь воспроизвести поведение модели в отличающемся окружении.
Вывод
Если вы дошли до этого места в статье в надежде увидеть один универсальный рецепт «идеального промпта на все случаи жизни», спешу разочаровать: его не существует. Модели, бизнес-логика и задачи везде разные. Однако принципы и советы, о которых я рассказала — это отличный рабочий фундамент, который вы можете адаптировать под свои проекты и сэкономить время и нервы.
С LMM легко обмануться: кажется, что достаточно правильно спросить — и всё заработает. Но чтобы получить стабильный, качественный и безопасный результат, с промптами нужно проводить долгую, кропотливую и местами откровенно нудную инженерную работу. В этом аспекте работа над промптом действительно схожа с классическим программированием: здесь тоже нужно продумать общую логику, корнер-кейсы, ограничения, делать тесты, итерации и версионирование. Надо помнить: ни одна LLM в мире не даёт 100% гарантии, что не будет сюрпризов — но наш процесс тестирования и постоянного контроля снижает вероятность сбоев до статистически незначимого уровня.
Более того, работа над промптом не заканчивается и в момент, когда он «заработал». Она продолжается всё время, пока работает и развивается продукт. Хорошая новость: это всё равно инженерия. Со своей логикой, инструментами и методами, которыми можно овладеть. Просто иногда модель всё равно найдёт способ вас удивить.
*Мнение автора может не совпадать с официальной позицией hh.ru. Приведённые кейсы описывают опыт команды.
Автор: polina_belokrys
