Промпт-инжиниринг — как получать от модели нужный ответ

Зачем это знать

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

Что такое промпт-инжиниринг простыми словами

Новому менеджеру дают инструкцию по разбору заявок. В первой версии там написано «обработать обращение» — и половина заявок уходит не в тот отдел. Инструкцию переписывают: перечисляют отделы, дают три примера спорных случаев, добавляют правило «если не подходит ни один — в общую очередь».

Ошибки исчезают не потому, что менеджер стал умнее. Изменилась формулировка задачи.

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

Разница с человеком одна, зато решающая. Проверить новую версию инструкции на ста случаях занимает минуты, а не квартал.

Как это работает

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

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

Пример из практики

Компания разбирает входящие письма и раскладывает их по семи типам обращений. Поток — около 3 000 писем в месяц. Первая формулировка описывает типы одной строкой каждый и просит «определить категорию».

Цифры ниже — расчётные ориентиры для процесса такого профиля, а не отчёт по конкретному внедрению. Методика замера указана, чтобы её можно было повторить на своих данных.

Замер: 100 писем, размеченных вручную двумя сотрудниками, спорные случаи разобраны отдельно. Доля верных категорий на первой формулировке — около 70%. Разбор ошибок показывает: почти все они на двух смежных типах и на письмах, где обращений сразу два.

Дальше три правки по одной. Жёсткий формат ответа с фиксированным списком значений. Три примера тех самых смежных случаев прямо в тексте инструкции. Правило: если типов больше одного — вернуть основной и пометку «требуется человек».

Модель ни разу не менялась. Изменился текст задачи и порядок проверки. Оставшиеся 9% уходят человеку по метке — и это заложено в процесс заранее, а не обнаруживается по жалобам.

Что это даёт бизнесу

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

Когда без этого можно обойтись

Разовые задачи выверенной инструкции не требуют. Написать письмо, сократить текст, накидать варианты заголовка — здесь достаточно обычного запроса, а результат человек видит сразу и правит руками.

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

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

Что важно проверить

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

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

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