Пользовательский промпт

Пользовательский промпт — это роль сообщения в вызове LLM API, представляющая ввод от конечного пользователя (или, в автоматизированном пайплайне, от вызывающего приложения от имени пользователя), в отличие от системного промпта (который задаёт постоянное поведение) и собственных ответов модели/ассистента. В типичном вызове API для завершения чата массив сообщений чередуется система → пользователь → ассистент → пользователь → ассистент, и каждая запись «пользователь» является пользовательским промптом. Понимание этого различия важно для разработчиков SaaS, потому что эти два типа промптов имеют разный уровень доверия и разные цели проектирования: системный промпт создаётся и контролируется разработчиком и должен содержать стабильные правила продукта; пользовательский промпт часто частично или полностью получен из недоверенного внешнего ввода (сообщение клиента, спарсенная веб-страница, загруженный документ) и должен обрабатываться с большей осторожностью, особенно в отношении риска prompt injection. В многоходовых разговорах полная история пользовательских и ассистентских промптов («контекст») обычно повторно отправляется с каждым новым вызовом, поскольку большинство API LLM не сохраняют состояние между запросами — приложение отвечает за поддержание и усечение истории разговора в пределах контекстного окна. Хорошо спроектированные продукты часто формируют пользовательский промпт программно, а не берут сырой пользовательский ввод дословно, оборачивая его разделителями или лёгкими инструкциями (например, «Пользователь спросил: <<{{raw_input}}>>. Отвечай, используя только контекст FAQ выше»), чтобы удержать модель на её задаче, даже если исходный человеческий ввод беспорядочен, не по теме или враждебен. Конкретный пример: чат-бот документации получает сырой вопрос пользователя «как мне отменить подписку???» — приложение оборачивает его перед отправкой: системный промпт определяет охват и тон ассистента; пользовательский промпт становится таким: «Ответь на следующий вопрос пользователя, используя только предоставленный контекст документации. Если ответа нет в контексте, скажи, что не знаешь.\n\nКонтекст: {{retrieved_docs}}\n\nВопрос пользователя: как мне отменить подписку???» Сырой, неформально сформулированный пользовательский ввод встраивается как данные внутри структурированного пользовательского промпта — это распространённый паттерн RAG (retrieval-augmented generation, генерация с дополнением поиском). Такое оборачивание важно и для логирования с аналитикой: поскольку пользовательский промпт, реально отправленный модели, отличается от сырого текста, набранного человеком, зрелые ИИ-продукты логируют оба варианта — сырой человеческий ввод для UX и анализа поддержки, и полностью сформированный пользовательский промпт для отладки поведения модели и воспроизведения проблем — поскольку запутанный ответ модели часто можно объяснить тем, как шаблон обёртки в тот конкретный день скомпоновал определённый срез контекста и инструкций вокруг иначе идентичного пользовательского ввода.