Промпт-инжиниринг

Такое понимание соединяет два положения документации: Google описывает последовательное уточнение запросов по ответам модели, а Anthropic предлагает сначала определить критерии успеха и способ проверки. Промпт — сам запрос; промпт-инжиниринг — работа над тем, чтобы он надёжнее решал задачу. ^{[1, 2]}

Кратко

До изменения запроса нужно определить, какой ответ считается правильным. ^[2]
Инструкция, исходный материал и образец ответа выполняют разные задачи. ^[3]
Примеры в запросе сами по себе не меняют веса — числовые параметры модели. ^[6]
Проверенный промпт не отменяет проверки фактов и ссылок в ответе. ^[5]

Происхождение и история термина

Один из этапов развития подхода представлен в исследовании Тома Брауна и соавторов Language Models are Few-Shot Learners, опубликованном на NeurIPS в 2020 году. Авторы сравнивали выполнение языковых задач без примеров, с одним примером и с несколькими примерами во входном тексте. Модель GPT-3 при этом не дообучали под каждое задание. Работа систематизировала различие между изменением обученной модели и заданием способа работы через её вход. Это исторический этап исследования метода, а не дата изобретения промпта или названия «промпт-инжиниринг». ^{[6, §1–2]}

В современной документации разработка запросов описывается уже как повторяющийся цикл: задать требования, испытать вариант, разобрать ответы, уточнить запрос. В таком подходе важен не отдельный приём, а связь изменения с измеряемым результатом. Эту сторону работы подчёркивают руководства Google и Anthropic. ^{[1, 2]}

Суть и механизм

Рассмотрим простую задачу: распределить письма читателей по темам. Инструкция сообщает модели, что нужно сделать. Само письмо — материал для обработки. Контекст — дополнительные сведения, например определения тем. Образцы показывают, как выглядит подходящий ответ. Такое разделение компонентов описывает Microsoft; оно помогает обсуждать запрос, хотя границы между компонентами иногда пересекаются. ^[3]

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

Затем нужны правила проверки. Anthropic предлагает делать критерии конкретными и измеримыми; для однозначных категорий в руководстве используется сравнение ответа с заранее заданной меткой. ^[2] В нашем примере успех означает, что модель выбрала нужную тему и вернула только её название. Если редакторы сами расходятся в оценке письма, сначала стоит уточнить правило, по которому они его распределяют.

Примеры работают иначе, чем дообучение. При дообучении меняются веса модели; при описанном Брауном и соавторами использовании примеров модель получает образцы во время решения задачи без обновления весов. ^{[6, §2]} Microsoft также различает влияние примеров на текущий ответ и постоянное изменение модели. ^[3] Поэтому отправить в чат пять образцов — не то же самое, что обучить новую версию модели.

Виды и классификации

По числу образцов во входе различают три режима, описанные в исследовании Брауна и соавторов. Речь идёт о количестве демонстраций нужного решения, а не о длине инструкции. ^[6]

Режим	Что получает модель	Учебный вариант
Zero-shot — без примеров	Описание задачи без готового образца решения	Правила категорий и новое письмо
One-shot — один пример	Один образец входа и правильного выхода	Разобранное письмо, затем новое
Few-shot — несколько примеров	Несколько таких образцов	Письма разных типов с метками, затем новое

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

Как применяется на практике

В российской документации GigaChat есть пример классификации обращений: запрос задаёт категории, образцы и требуемый вид ответа. Каталог также содержит задания на сокращение текста и подготовку вопросов. Это примеры разработчика, а не независимые измерения точности сервиса. ^[4]

Учебный пример. Интернет-издание принимает письма о доступе к сайту, содержании публикаций и других вопросах. Первая версия запроса звучит так: «Выбери тему письма: доступ, содержание или прочее». Она не объясняет границы категорий и не решает случай, когда тем несколько.

Вторая версия задаёт явные правила:

Отнеси письмо к одной категории. «Доступ» — не удаётся войти на сайт или открыть материал. «Содержание» — вопрос, замечание или предложение о тексте публикации. «Прочее» — остальные случаи. Если одновременно описаны сбой доступа и замечание к тексту, выбери «доступ». Ответ: только название категории.

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

Учебное письмо	Ожидаемая категория	Основание
«Не могу войти в личный кабинет»	доступ	Описан сбой входа
«В статье неверно указана дата открытия выставки»	содержание	Замечание к факту публикации
«Хочу предложить рекламное сотрудничество»	прочее	Нет вопроса о доступе или тексте
«Нашёл опечатку, но теперь статья не открывается»	доступ	Срабатывает заданный приоритет

Таблица показывает ожидаемые ответы, а не результаты запуска модели. Её можно использовать при обсуждении правил. Для итоговой оценки понадобятся другие письма, которые не использовали при подборе формулировки: проверять запомнившийся набор и проверять новые случаи — разные задачи. В руководстве Anthropic примеры критериев также относятся к отдельно отложенному тестовому набору. ^[2]

Как измерить или проверить

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

Правильная категория	Всего писем	Версия 1: верно	Версия 2: верно
Доступ	20	12	18
Содержание	20	18	16
Прочее	10	5	6
Всего	50	35	40

Доля правильных ответов равна числу совпадений с эталонной меткой, делённому на число всех проверенных случаев. Такой способ оценки категорий приведён в руководстве Anthropic. ^[2] Обозначим количество верных ответов буквой C, количество писем — N. Для нашего протокола ответ с лишним пояснением тоже считается ошибочным, потому что нарушает заданный формат.

text Доля правильных ответов = C / N × 100%. Версия 1: 35 / 50 × 100% = 70%. Версия 2: 40 / 50 × 100% = 80%. Разница: 80% − 70% = 10 процентных пунктов.

Общий результат улучшился на пять писем. Однако для темы «содержание» доля верных ответов снизилась с 18/20 = 90% до 16/20 = 80%. Поэтому выбор версии зависит и от того, насколько важны эти ошибки для редакции. Если неверно направленная жалоба задерживает исправление публикации, одного общего процента недостаточно для решения.

В предлагаемом протоколе сравнения сохраняют обе инструкции, модель, настройки, одинаковые входные письма и ответы. Меняют только проверяемую часть запроса. Неполученный ответ учитывают как ошибку, а не убирают письмо из знаменателя. При N = 0 процент не определён. Результат 80% относится только к указанным условиям; он не доказывает ту же точность на будущей почте или статистическую значимость улучшения.

Ошибки, ограничения и спорные вопросы

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

Другой предел связан с достоверностью. NIST называет конфабуляцией уверенное предъявление ошибочного или ложного содержания и рекомендует проверять источники и цитаты в ответах генеративных систем. ^{[5, §2.2; MS-2.5-003]} Поэтому просьба «приведи источник» ещё не доказывает, что ссылка существует и подтверждает написанное.

Наконец, не вся проблема решается переписыванием запроса. Anthropic отмечает, что задержку ответа и стоимость иногда проще улучшить выбором другой модели. ^[2] Рекомендации поставщика следует проверять в нужной системе: Microsoft прямо предупреждает, что поведение моделей различается. ^[3]

Частые вопросы