hh.ru a expliqué comment concevoir des prompts de production pour des services d'AI sans mauvaises surprises

hh.ru поделился практикой, как пишет промпты для своих AI-сервисов в продакшене. Главная мысль простая: промпт в продукте — это не разговор с чат-ботом, а инженерная система с ограничениями, тестами и постоянной отладкой.

Продакшен не чат В обычном использовании LLM всё устроено довольно

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

Поэтому промпт для продакшена — это не одна фраза в стиле «сделай красиво», а набор связанных инструкций, данных, правил и вызовов инструментов, иногда на сотни строк. Автор статьи называет это борьбой инженера со «стохастическим попугаем». Модель не понимает смысл так, как человек, а предсказывает следующий токен на основе вероятностей.

Задача команды — максимально сузить пространство случайности: дать модели ясную роль, контекст, ограничения и ожидаемый формат ответа. Чем лучше спроектирован этот контур, тем выше шанс получить предсказуемый, безопасный и полезный результат для реального бизнеса. Именно поэтому работа с промптами всё больше напоминает обычную разработку, а не творческий эксперимент.

Каркас хорошего промпта В hh.ru рекомендуют писать сами инструкции на

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

Дополнительно помогают шаблоны и разметка: markdown или XML делают длинную инструкцию более структурированной и уменьшают двусмысленность. В типовом каркасе обычно есть роль модели, цель, контекст, шаги решения и формат ответа. роль модели цель и конкретная задача контекст входных данных алгоритм действий или шаги проверки * ограничения и формат ответа Особенно опасны few-shot примеры.

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

«Готовы ли вы к командировкам в Рязань?»

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

Как это тестируют Даже хороший промпт нельзя считать готовым после пары удачных прогонов.

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

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

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

Что это значит

Материал hh.ru хорошо показывает, что промпт-инжиниринг быстро превращается в обычную продуктовую инженерию. Здесь побеждает не самый креативный запрос, а связка из структуры, ограничений, evals, логов и итеративной доработки. Для команд, которые строят AI-функции в продакшене, это сигнал: промпты уже нужно версионировать, тестировать, отслеживать по метрикам, связывать с реальными сценариями пользователей и адаптировать под конкретные модели так же серьёзно, как код.