Промпт-инжиниринг: как писать запросы, которые дают проверяемый результат
Хороший промпт не содержит магических слов: он переводит рабочую задачу в однозначные входные данные, ограничения, формат и критерии приёмки. Разберём, как собрать такой запрос, проверить ответ на фактах и улучшить его без бесконечного переписывания.
- Промпт-инжиниринг начинается с постановки задачи
- Соберите паспорт задачи из семи элементов
- Отделите инструкцию от данных
- Покажите формат и дайте только полезные примеры
- Пример: от слабого запроса к проверяемому
- Улучшайте по журналу ошибок, а не на глаз
- Проверяйте ответ по типу задачи
- Типовые ошибки промпта
- На какие руководства опираться
- Вопросы и ответы
Промпт-инжиниринг начинается с постановки задачи
Промпт — это ввод, который запускает ответ модели; промпт-инжиниринг — процесс проектирования и улучшения этого ввода. Официальное руководство OpenAI подчёркивает ясность, конкретность и итеративное уточнение, а документация Sber рекомендует заранее определить задачу, входные данные, ограничения и формат. Это не означает, что одна формула гарантирует истинный ответ: результат зависит от модели, её текущей версии, переданного контекста и способа проверки.
Начните не с роли вроде «ты лучший эксперт», а с решения, которое нужно принять после ответа. «Напиши текст о продукте» оставляет неизвестными аудиторию, цель, факты и критерий готовности. «Подготовь черновик письма для действующих клиентов, используя только приложенную карточку продукта; сохрани три обязательных факта, не добавляй скидок и верни тему плюс основной текст» уже задаёт проверяемую работу.
Если человек не может объяснить, как отличит хороший результат от плохого, модели тоже неоткуда узнать критерий. Сначала опишите приёмку, затем просите генерацию.
Соберите паспорт задачи из семи элементов
| Элемент | Что зафиксировать | Контрольный вопрос |
|---|---|---|
| Цель | Какое решение или действие поддержит ответ | Зачем нужен результат? |
| Аудитория | Знания, ситуация и ожидания читателя | Что уже известно адресату? |
| Контекст | Продукт, процесс, период и терминология | Какой фон нельзя угадывать? |
| Данные | Разрешённые документы, поля и факты | На чём строить вывод? |
| Ограничения | Что исключить, какие риски учитывать | Где граница задания? |
| Формат | Поля, порядок, объём и язык | Как использовать ответ дальше? |
| Проверка | Точность, полнота, ссылки и тесты | Как принять результат? |
Не каждый запрос требует всех семи пунктов в развёрнутом виде. Для простого преобразования достаточно действия, входа и формата. Для финансового анализа, клиентской коммуникации или работы с документами понадобятся источник каждого утверждения, ограничения по данным и явная процедура проверки.
Отделите инструкцию от данных
Модель должна различать то, что ей поручено, и то, что она должна обработать. Поместите инструкцию первой, затем обозначьте границы входного материала. Для длинного текста используйте понятные секции: «Задача», «Входные данные», «Ограничения», «Формат», «Критерии». Кавычки, тройные разделители или XML-подобные метки — лишь способы обозначить границы; важна однозначность, а не конкретный знак.
Каркас рабочего запроса
Задача: сравнить два варианта регламента и перечислить изменения. Данные: тексты версий A и B с датами. Ограничения: не использовать внешние сведения и не предполагать причины правок. Формат: таблица «раздел — было — стало — практическое следствие». Проверка: каждая строка содержит ссылку на раздел обеих версий; если соответствия нет, указать это явно.
Не передавайте в общедоступный сервис пароли, платёжные реквизиты, персональные данные и внутренние материалы без проверки прав, настроек хранения и политики организации. Обезличивание — отдельная операция: удалить имя недостаточно, если человека можно восстановить по сочетанию должности, даты и описания события.
Покажите формат и дайте только полезные примеры
Если результат должен поступить в таблицу или систему, перечислите поля и допустимые значения. Пример ответа помогает показать структуру, терминологию и уровень детализации. Он не должен подменять задачу: модель может начать копировать случайные особенности образца, поэтому отделяйте обязательное правило от иллюстрации.
Начните без примера, когда задача очевидна и ошибка недорога. Добавьте один или несколько примеров, если нужна стабильная классификация, особый формат либо трудно объяснимая граница категорий. Примеры должны покрывать не только обычный случай, но и важное исключение. Не выдавайте синтетический пример за реальную запись клиента или подтверждённый факт.
Пример: от слабого запроса к проверяемому
Слабый вариант: «Проанализируй продажи и дай советы». Не указаны период, единица строки, цель, метрики и источник. Улучшенный запрос начинается так: «По приложенной таблице заказов за второй квартал найди отклонения валовой маржи по товарным группам. Используй только строки со статусом “завершён”, не считай пустую себестоимость нулём и верни контроль количества включённых и исключённых строк».
Затем добавьте формулы и приёмку: «Валовая прибыль = выручка минус себестоимость; маржа = валовая прибыль, делённая на выручку. Для каждой группы верни выручку, прибыль, маржу, изменение к первому кварталу и номера строк с тремя крупнейшими отклонениями. Не объясняй причину без данных; вместо этого сформулируй гипотезу и укажи, что нужно проверить».
Такой промпт всё ещё не заменяет расчёт. Суммы и проценты следует пересчитать таблицей или кодом, проверить пропуски и дубли, а текст модели использовать для структурирования наблюдений. Ответ «похож на правду» не является контрольной процедурой.
Улучшайте по журналу ошибок, а не на глаз
- Сохраните исходный запрос, модель, дату и тестовый набор.
- Запустите несколько типичных и пограничных случаев.
- Классифицируйте ошибки: пропуск факта, неверный вывод, формат, лишнее допущение, отказ или нестабильность.
- Меняйте один существенный элемент промпта за итерацию.
- Повторите тот же набор и сравните по заранее заданной рубрике.
- Проверьте, что улучшение одного случая не ухудшило остальные.
Рубрика может включать точность, полноту, трассируемость к источнику, соблюдение формата и безопасное поведение при нехватке данных. Для творческого варианта добавьте соответствие тону и разнообразие, но не смешивайте их с фактической точностью. Обновление модели способно изменить результат, поэтому важные промпты периодически прогоняют по сохранённому набору.
Проверяйте ответ по типу задачи
- Факты: открыть первичный источник и проверить применимый период.
- Расчёты: воспроизвести формулой или скриптом независимо от текста модели.
- Извлечение: сопоставить каждое поле с фрагментом входного документа.
- Классификация: проверить размеченную контрольную выборку и пограничные случаи.
- Код: выполнить тесты, статический анализ и проверку безопасности.
- Коммуникация: сверить обязательные факты, обещания, тон и правовые ограничения.
Просьба «не галлюцинировать» не создаёт недостающих знаний. Полезнее потребовать обозначать недостаточность данных, приводить точные основания и разделять факт, вывод и гипотезу. Для ответов по собственным документам может подойти отдельный процесс RAG с извлечением релевантного контекста, но и он требует контроля доступа и оценки качества поиска.
Типовые ошибки промпта
- Несколько несовместимых задач в одном запросе.
- Роль вместо реального контекста и критериев.
- Требование точного числа без источника или расчёта.
- Скрытые определения: «лучший», «эффективный», «качественный» без шкалы.
- Противоречие между краткостью и полной детализацией.
- Запрет без безопасной альтернативы действия.
- Слепое копирование чужого шаблона в другую модель и задачу.
- Передача конфиденциальных данных без проверки режима обработки.
Подборки готовых запросов полезны как сырьё, но их нужно привязывать к собственной задаче. Для узкой рекламной работы можно использовать отдельный разбор промптов для рекламных объявлений; общий рабочий навык остаётся тем же: задать данные, границы и приёмку.
На какие руководства опираться
Определение и базовые рекомендации сверены 27 июля 2026 года с руководством OpenAI для ChatGPT, руководством OpenAI для API и документацией Sber по промпт-инжинирингу. Конкретные возможности, параметры и интерфейс всегда проверяйте в документации выбранного продукта на дату работы.
Освойте постановку задач, проверку ответов и рабочие сценарии с нейросетями.
Курс «Нейросети с 0 до PRO» помогает выстроить практическую работу с текстовыми и визуальными ИИ-инструментами. Тему ведёт Анна Степанова — преподаватель курса и специалист по промпт-инжинирингу.
Рабочий промпт — это компактная спецификация задачи. Он становится надёжнее, когда входные данные отделены от инструкции, формат описан заранее, а результат проходит независимую проверку.
Вопросы и ответы
- Нужно ли всегда задавать нейросети роль?
Нет. Роль полезна, если она действительно уточняет перспективу, терминологию или ограничения, но не заменяет цель, входные данные, формат и критерии проверки.
- Чем хороший промпт отличается от длинного промпта?
Хороший промпт содержит только информацию, которая помогает выполнить и проверить задачу. Длина сама по себе не улучшает результат: лишние правила могут противоречить друг другу и скрывать главное.
- Когда стоит добавлять пример ответа?
Когда формат, границы категории или стиль трудно описать одними правилами. Пример должен быть явно обозначен и не содержать вымышленных данных, которые модель может принять за факты.
- Можно ли одним промптом гарантировать достоверность?
Нет. Промпт снижает неоднозначность, но факты, расчёты, ссылки и выполнение ограничений всё равно нужно проверять независимым способом, подходящим к типу задачи.
- Почему старый рабочий промпт начал давать другой результат?
Могли измениться модель, системные настройки, входные данные или контекст. Сохранённый тестовый набор и журнал версий помогают отделить изменение промпта от изменения продукта.