Почему few-shot промптинг ломается на реальных данных
На демонстрационном наборе few-shot промптинг выглядит надёжно: десяток размеченных примеров в системном сообщении, и модель уверенно раскладывает обращения по классам. В рабочем потоке входные данные приходят из разных каналов, формулировки меняются, и набор примеров перестаёт покрывать реальность. Разберём, где именно ломается — один и тот же набор ведёт себя по-разному на OpenAI и на локальной модели, но классы отказов совпадают.
Мы собрали четыре режима, которые встречаются почти в каждом внедрении — от размытых границ категорий до расползания формата ответа.
| Класс сбоя | Как проявляется | Чем оборачивается |
|---|---|---|
| Размытые границы классов | Пограничное обращение модель относит то к одной категории, то к соседней | Часть потока уходит не в тот маршрут, растёт доля ручных правок |
| Противоречивая разметка примеров | Два похожих примера размечены разными метками | Нестабильный вывод модели: один и тот же текст получает разные метки при повторном прогоне |
| Дрейф формулировок | В потоке появляются формулировки, которых не было в примерах | Точность падает постепенно, без явной ошибки на конкретном запросе |
| Расползание формата | Модель добавляет пояснения, меняет ключи, оборачивает ответ в текст | Контроль формата ответа теряется, парсер получает пустые поля |
Цена этих отказов считается не в «качестве ответов вообще», а в доле обращений, ушедших на ручной разбор, и в проценте запросов, где не пришло ни одного обязательного поля. Сбои классификации опасны тем, что проявляются не сразу: неделю метрики ровные, потом доля правок растёт — и непонятно, что именно сломалось.
Дальше разбираем, как это закрывается: устойчивыми наборами примеров, разметкой под конфликтные случаи и проверкой формата на стороне сервиса.
Что даёт управляемая генерация на примерах
Отлаженный набор примеров работает как спецификация поведения модели: тридцать-пятьдесят пар «вход — верный ответ», собранных по реальным обращениям, задают границы классов точнее, чем длинная инструкция. Модель видит, где проходит грань между «претензией по качеству» и «вопросом по гарантии», и не угадывает по названию категории. На отложенной проверочной выборке точность классификации поднимается с 0,7 до 0,9 и выше — на тех же данных, без дообучения.
Примеры задают и форму ответа. Если в наборе каждый ответ — один и тот же набор полей, модель возвращает его и на новых входах: один и тот же вход даёт один и тот же результат при повторном запуске, а не «похожий по смыслу». Это и снимает ручную правку — ответ уже разобран на поля и уходит в учётную систему без переписывания оператором, а доля записей, которые человек правит руками, падает с трети до единиц процентов.
Устойчивость к новым данным — следствие того, как собран набор. Мы держим примеры и проверочную выборку в Hugging Face с версионированием, поэтому новый класс обращений или смена формулировок закрывается добавлением двух-трёх примеров, а не пересборкой решения. Каждое изменение набора прогоняется через замер на отложенной выборке: если точность не растёт, пример уходит из набора.
Подходы к настройке: примеры, инструкции, дообучение
Режим настройки выбирают не по общей рекомендации, а по свойствам потока: сколько категорий в задаче, как часто меняется разметка, есть ли примеры нужного качества. Один и тот же запрос на десяти классах и на двухстах ведёт себя по-разному — сравниваем подходы по применимости и пределам, а не по среднему качеству.
Инструкции в запросе и few-shot промптинг не конкурируют: правила фиксируют формат ответа, порядок полей и запреты, примеры показывают границу между близкими классами. Дообучение модели подключают, когда таксономия стабильна и накопленных примеров хватает для устойчивого разделения.
Сравнение подходов
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Примеры в запросе | 5–20 категорий, разметка меняется, нужен запуск без пересборки | растёт объём запроса, качество проседает на 30+ категориях и на редких классах |
| Инструкции в запросе | правила выражаются словами: формат, тон, что считать ошибкой | плохо держит неявные признаки, конфликт правил ломает ответ |
| Дообучение модели | стабильная таксономия, сотни однородных примеров на класс | нужна разметка, смена таксономии тянет пересборку и заново собранный набор |
Объём набора примеров подбираем по худшему классу, а не по среднему: 5–15 примеров на класс для запроса, от сотни для дообучения. Если категорий больше, сначала проверяем иерархию или двухступенчатую схему — плоский список на 50+ классов теряет точность независимо от выбранного режима.
Этапы внедрения: от аудита данных до передачи
Прежде чем писать формулировки, мы разбираем корпус: сколько размеченных примеров приходится на каждый класс, как они распределены, есть ли дубли и пересекающиеся формулировки. От этого зависит, сработает ли few-shot вообще — если на редкий класс есть два-три образца, никакая инструкция не даст устойчивого результата. Порядок работы ниже одинаков и для классификации, и для извлечения полей.
- Аудит корпуса данных. Оцениваем объём, качество разметки, долю редких классов и расхождения между разметчиками. На выходе — карта данных: какие категории действительно различимы по тексту, а какие придётся объединить.
- Схема решения. Фиксируем, где именно работает few-shot — классификация, извлечение сущностей или приведение текста к корпоративному стилю. Определяем формат ответа, обязательные поля и поведение модели при неуверенности.
- Сборка примеров. Отбираем образцы на каждый класс: короткие, однозначные, без пересечений между категориями. Балансируем состав и порядок — модель чувствительна и к числу примеров, и к тому, в каком порядке они поданы.
- Стенд проверки. Формируем отложенную выборку, которая не участвует в настройке, и прогоняем на ней каждую версию набора примеров. Так видно, где улучшение реальное, а где подгонка под просмотренные данные.
- Согласование метрик. Договариваемся заранее, что считаем успехом: точность по классам, полнота извлечения, доля отказов и спорных случаев на ручную проверку. Порог приёмки фиксируем до замеров, а не после.
- Передача документации. Отдаём описание набора примеров и правил отбора, инструкцию по расширению корпуса, схему прогонов и порядок переобучения при появлении новых категорий. Команда заказчика может вести донастройку сама.
Библиотека примеров, шаблоны запросов, регламент
После запуска решения у команды остаётся комплект, который определяет, удержит ли она качество без нас: библиотека примеров, шаблоны обращений к модели и регламент, по которому всё это обновляется. Передаём его в вашем хранилище кода — с историей изменений, а не как архив документов.
- Библиотека примеров — размеченные пары «запрос — эталонный ответ» по каждому классу, отдельной полкой сложные и пограничные случаи, на которых модель ошибалась чаще всего.
- Шаблоны запросов — заготовки под классификацию, извлечение полей и приведение текста к корпоративному стилю: фиксированная структура, место под примеры, правила на случай неоднозначного входа.
- Правила версионирования — каждая правка примеров или шаблона идёт отдельным изменением с пояснением, что и почему поменяли; предыдущая версия остаётся для сравнения результатов.
- Регламент проверки — набор тестовых случаев с ожидаемыми ответами и порядок прогона: что считается ухудшением и при каком расхождении правка откатывается.
- Документация решения — схема обработки запроса, требования к входным данным, известные ограничения и перечень случаев, где обязателен человек.
- Порядок эскалации — кто владеет библиотекой примеров на вашей стороне и как передать задачу нам, если правки перестали давать прирост качества.
Комплект рассчитан на инженера, который раньше с этим не работал: по нему можно добавить новый класс запросов, не пересобирая решение целиком.
Кейс: классификация обращений на потоке заявок
Служба поддержки с потоком в несколько тысяч обращений в сутки: каждую заявку нужно отнести к одной из 40 категорий, чтобы передать нужной группе и запустить регламентный ответ. Разметку вели операторы вручную, и именно этот шаг стал узким местом — на пике очередь не успевали разбирать, а ошибка маршрутизации возвращалась второй линией.
Что было до внедрения
Четверо операторов размечали очередь и расходились в трактовке: совпадение между ними держалось на уровне 80%, то есть каждое пятое обращение при повторной разметке уезжало в другую категорию. Среднее время от поступления заявки до назначения ответственного доходило до 6–8 минут, а спорные категории разбирали на общей встрече — это съедало часть смены.
Что изменили и что получилось
Настроили few-shot промптинг: в запрос передавали 5–8 эталонных примеров на категорию плюс правило низкой уверенности — модель не решает сама, а помечает обращение флагом для оператора. Справочник категорий и регламенты остались прежними, дообучение не потребовалось, качество дополнительно сверили на публичном наборе Banking77.
Спорные случаи перестали разбирать массово: модель отдаёт оператору только слой с низкой уверенностью — около 6% очереди, остальное уходит автоматически. Новая категория добавляется парой эталонных примеров, без пересборки справочника и повторной разметки архива.
Чем few-shot отличается от дообучения модели?
Few-shot подход не меняет веса модели: вы описываете задачу словами и прикладываете несколько размеченных примеров прямо в запросе. Поведение меняется на следующем же вызове — правка формулировки или замена одного примера даёт новый результат без пересборки модели.
Дообучение модели работает иначе: примеры уходят в датасет, по нему обновляются веса, и на выходе появляется отдельный артефакт, который нужно версионировать и сопровождать. Требования к разметке здесь на порядок выше — сотни и тысячи согласованных примеров, отдельная выборка для проверки, контроль расхождений между разметчиками. Ошибка в разметке не видна сразу: она всплывает уже в поведении готовой модели.
Трудоёмкость поддержки расходится при первом же изменении постановки. В few-shot достаточно поправить примеры и прогнать тот же набор проверок, чтобы убедиться: соседние сценарии не сломались. В дообучении каждое изменение класса — это новый проход: сбор данных, обучение, сравнение с прошлой версией и проверка на регрессиях.
Перенос на новые категории тоже устроен по-разному. Few-shot заводит новую категорию двумя-тремя примерами и сразу показывает, где модель путается, — это быстрый способ проверить саму постановку задачи. Дообучение даёт более стабильное поведение, когда классов много, а требования к стилю и формату жёсткие.
Граница проходит по частоте изменений. Если правила и категории живут неделями, выигрывает few-shot; если задача стабильна, а поток однотипных запросов велик, окупается дообучение. Часто берут оба инструмента: дообучение закрывает базовое качество на массовых классах, few-shot — редкие случаи и быстрые правки поверх.
Технические сомнения: качество, объём, поддержка
Возражения у инженеров и техлидов обычно одни и те же: сколько примеров реально нужно, что делать с редкими классами и как обновлять решение, не останавливая сервис. Отвечаем по пунктам — с той конкретикой, которую видим в проектах.
Сколько размеченных примеров нужно на класс?
Для классификации и извлечения сущностей устойчивый результат обычно дают 8–30 примеров на класс — при условии, что они покрывают разные формулировки, длины и краевые случаи, а не перефразируют один шаблон. Дальше объём наращивать бессмысленно: запрос растёт, а точность стоит на месте. Поэтому нужное число подбираем экспериментально — прогоняем варианты на отложенной выборке и фиксируем, где метрики перестают улучшаться.
Что делать с редкими категориями, где примеров почти нет?
Редкий класс не вытягивается примерами в одиночку, поэтому собираем его из нескольких источников: накопленные логи обращений, разметка пограничных случаев аналитиком, иерархия — сначала крупная группа, потом уточнение внутри неё. Пока данных мало, такие случаи уходят на ручную проверку с явной меткой «требует уточнения»: общая точность не проседает, а мы получаем материал для следующей итерации.
Как менять формулировки и наборы примеров без простоя?
Промпты, наборы примеров и правила версионируются как обычный код. Новая версия сначала идёт теневым прогоном на живом трафике: считаем расхождения с текущей, смотрим поведение на золотом наборе. Переключение — управляемое, а предыдущая версия остаётся поднятой, поэтому возврат к ней занимает минуты, а не часы согласований.
Обсудим задачу и вернёмся с планом работ
Чтобы разговор был предметным, а не общим, нам достаточно нескольких вводных — по ним видно, где few-shot промптинг действительно закрывает задачу, а где дешевле обойтись правилами или дообучением. Пришлите то, что уже накоплено: черновики промптов, спорные примеры, действующие правила фильтрации.
Что помогает на входе:
- 30–50 обезличенных примеров входных данных с указанием ожидаемого ответа — из них собирается набор для few-shot.
- Список целевых классов или полей извлечения и решение по неоднозначным случаям: относить к классу или отдавать на проверку.
- Текущий промпт или правила, если уже пробовали, и в чём именно ошибались — повторы ошибок показывают, где нужен другой подход.
- Ограничения по данным: где они лежат, можно ли отправлять их во внешние сервисы, кто имеет доступ.
- Профиль нагрузки: сколько запросов в час, какая пиковая нагрузка и средняя длина текста.
- Требования к формату ответа — схема, обязательные поля, что считается критичной ошибкой.
- Критерий приёмки: какая доля верных ответов на вашем наборе считается рабочей.
В ответ мы присылаем разбор задачи и схему решения: какие примеры попадут в промпт, как строится разметка, где остаётся проверка человеком. Отдельным блоком — этапы и сроки, включая пилот на ваших данных: на нём фиксируем метрику качества до внедрения в рабочий контур.
Опишите задачу в двух-трёх абзацах — вернёмся с оценкой и планом работ.
