Few-shot — это приём, когда вы показываете модели несколько готовых примеров «вход → ответ» прямо в запросе, и дальше она работает по образцу. Для разметки заявок это самый дешёвый способ получить стабильный результат: вы собираете 5-10 реальных обращений с проставленными категориями, вставляете их в промпт, и модель размечает новый поток так же. Под капотом это та же языковая модель, просто с понятным образцом перед глазами.
Зачем это нужно
Few-shot — это несколько примеров «заявка → категория» внутри запроса. Модель смотрит на образцы и размечает новые обращения по той же логике. Это заменяет дорогое дообучение: вы получаете стабильную классификацию за один промпт, без программистов и без выгрузки тысяч размеченных данных. Главное — подобрать примеры, которые покрывают ваши реальные пограничные случаи.
Поток заявок в любом отделе продаж или поддержки выглядит однотипно: часть обращений про цену, часть про сроки, часть жалобы, часть спам. Раньше эти заявки руками раскладывал оператор, и на сотне обращений в день уходила половина смены. Языковая модель закрывает эту рутину, если объяснить ей правила игры.
Объяснять правила удобнее всего примерами. Вместо длинной инструкции «жалоба — это когда клиент недоволен, но без угрозы вернуть деньги» вы показываете модели три реальные жалобы с проставленной категорией. Дальше она держит вашу логику и применяет её к новым заявкам. Этот приём и называют few-shot: модель учится с нескольких выстрелов, прямо в окне запроса, без отдельного обучения.
Сила few-shot в том, что он работает на ваших данных и вашем языке категорий. Один бизнес делит заявки на «горячий лид», «тёплый», «сервис» и «мимо», другой — на десяток продуктовых направлений. Модель подстраивается под вашу схему, потому что видит её в примерах, а догадывается о ней сама.
- Классификация входящих обращений: продажи, поддержка, претензия, спам
- Маршрутизация заявок на нужный отдел без участия оператора
- Оценка приоритета: срочное обращение против обычного вопроса
- Извлечение из заявки полей — продукт, город, бюджет — по образцу
Сбор примеров
Качество разметки держится на примерах, а длине промпта. Пять точных образцов работают лучше двадцати случайных. Берите реальные заявки из своей переписки, а придумывайте искусственные — модель чувствует разницу и на живых данных ведёт себя точнее. Главное правило: примеры должны покрывать ваши пограничные случаи, те самые заявки, на которых ошибается даже оператор.
- Выгрузите 30-50 реальных заявок за последнюю неделю в таблицу
- Проставьте категорию каждой вручную, как сделал бы ваш лучший оператор
- Отберите 5-8 примеров так, чтобы каждая категория встретилась хотя бы раз
- Добавьте 2-3 спорных случая, на которых легко ошибиться, с пояснением выбора
- Соберите примеры в промпт в формате «заявка → категория», по одному на строку
- Прогоните 20 новых заявок и сверьте разметку модели с вашей ручной
Избегайте набора из одних лёгких заявок. Если все примеры очевидные, модель отлично размечает очевидное и сыплется на спорном. Сила few-shot именно в пограничных случаях: покажите модели заявку, которую сами разметили с трудом, и объясните логику выбора прямо в примере.
Структура промпта
Промпт для разметки состоит из трёх частей: список допустимых категорий, блок примеров и новая заявка для разметки. Категории перечисляйте явно и закрытым списком, иначе модель придумает свою. Примеры идут единым блоком, в одинаковом формате. Новую заявку подаёте в том же виде, что и образцы, и просите вернуть только категорию без рассуждений — так ответ остаётся машиночитаемым и его легко подставить в таблицу.
| Часть промпта | Что в ней | Частая ошибка |
|---|---|---|
| Список категорий | Закрытый перечень меток с коротким определением каждой | Открытый список — модель плодит лишние ярлыки |
| Блок примеров | 5-8 пар «заявка → категория», включая спорные | Только лёгкие случаи без пограничных |
| Формат ответа | Просьба вернуть строго одну метку из списка | Модель отвечает абзацем вместо метки |
| Новая заявка | Текст обращения в том же виде, что примеры | Разный формат входа путает модель |
Когда заявки длинные и разнородные, помогает добавить в промпт правило для непонятного случая: если обращение подходит ни под одну категорию, модель ставит метку «другое» и передаёт заявку человеку. Это снимает соблазн выдумать ответ и оставляет спорные обращения под контролем оператора. Чем уже коридор для разметки, тем меньше пространства для выдумки.
Покажите ваш реальный поток заявок и текущую схему категорий — на бесплатном часовом разборе я соберу под него промпт с примерами и проверю разметку на живых данных. Записаться можно через раздел с программами.
Границы приёма
Few-shot закрывает классификацию и извлечение полей, но остаётся подсказкой, а гарантией. Модель ошибается уверенно: она способна отнести явную жалобу к продажам или придумать категорию, которой нет в вашем списке. Это свойство языковых моделей называют галлюцинациями, и оно сохраняется даже у сильных версий. Поэтому разметку важно проверять на старте и держать процент совпадения с ручной работой под наблюдением.
Спорные заявки, претензии и всё, что влияет на деньги и репутацию, проходит через оператора. Модель размечает поток и снимает рутину, а финальное решение по сложному обращению держит человек. Метка «другое» — это сигнал передать заявку живому сотруднику.
Когда категорий становится много, а заявки путаются между собой, одних примеров перестаёт хватать. На этом этапе переходят к более тяжёлым связкам: автоматическая выгрузка заявок, разметка через интеграцию на n8n, регулярная сверка качества. Стартовать же стоит с обычного чата и промпта — это дёшево и показывает, работает ли подход на вашем потоке, прежде чем вкладываться в автоматизацию.
- Персональные данные в заявках отдавайте модели с осторожностью, через корректный доступ
- Метку «другое» заводите всегда — она ловит случаи вне вашей схемы
- Процент совпадения с ручной разметкой держите под наблюдением первые недели
- Спорные и денежные обращения проходят через оператора целиком
Куда расти
Когда разметка на промпте стабильно совпадает с ручной работой, заявки начинают раскладываться сами, и оператор подключается лишь к спорным. Дальше тот же приём расширяют: модель извлекает из обращения бюджет и продукт, ставит приоритет, маршрутизирует заявку в нужный отдел. Каждый новый шаг проверяют на живом потоке, прежде чем доверить ему работу без присмотра.
Заодно команда учится обновлять примеры сама. Появилась новая категория заявок — оператор добавляет пару образцов в промпт, и модель подхватывает логику без переписывания всего процесса. Этот навык остаётся с компанией: даже когда выйдут новые версии моделей, готовый набор примеров переносится на них почти без правок.
Сложность здесь в подборе правильных примеров и в честной проверке качества на старте. Частый провал — компания собирает промпт из удобных лёгких заявок, видит красивые цифры на тесте и удивляется, почему на боевом потоке всё сыплется. На разборе процессов я смотрю на ваш реальный поток и помогаю собрать набор примеров, который держит именно ваши пограничные случаи.