Few-Shot промптінг: класифікація, вилучення та корпоративний стиль

Чому few-shot промптинг ламається на реальних даних

На демонстраційному наборі few-shot промптинг виглядає надійно: десяток розмічених прикладів у системному повідомленні, і модель впевнено розкладає звернення за класами.

У робочому потоці вхідні дані надходять з різних каналів, формулювання змінюються, і набір прикладів перестає покривати реальність. Розберемо, де саме ламається — той самий набір поводиться по-різному на OpenAI і на локальній моделі, але класи відмов збігаються.

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

Ціна цих відмов вимірюється не в «якості відповідей загалом», а в частці звернень, що пішли на ручний розбір, і у відсотку запитів, де не надійшло жодного обов'язкового поля.

Збої класифікації небезпечні тим, що проявляються не одразу: тиждень метрики рівні, потім частка правок зростає — і незрозуміло, що саме зламалося.

Далі розбираємо, як це закривається: стійкими наборами прикладів, розміткою під конфліктні випадки та перевіркою формату на боці сервісу.

Що дає керована генерація на прикладах

Налагоджений набір прикладів працює як специфікація поведінки моделі: тридцять-п'ятдесят пар «вхід — правильна відповідь», зібраних за реальними зверненнями, задають межі класів точніше, ніж довга інструкція.

Модель бачить, де проходить межа між «претензією щодо якості» та «питанням щодо гарантії», і не вгадує за назвою категорії. На відкладеній перевірочній вибірці точність класифікації піднімається з 0,7 до 0,9 і вище — на тих самих даних, без дообучення.

Приклади задають і форму відповіді. Якщо в наборі кожна відповідь — той самий набір полів, модель повертає його і на нових входах: той самий вхід дає той самий результат при повторному запуску, а не «схожий за змістом».

Це й знімає ручну правку — відповідь уже розібрана на поля і йде в облікову систему без переписування оператором, а частка записів, які людина править руками, падає з третини до одиниць відсотків.

Стійкість до нових даних — наслідок того, як зібраний набір. Ми тримаємо приклади й перевірочну вибірку в Hugging Face з версіонуванням, тому новий клас звернень або зміна формулювань закривається додаванням двох-трьох прикладів, а не перезбиранням рішення.

Кожна зміна набору проганяється через замір на відкладеній вибірці: якщо точність не зростає, приклад іде з набору.

Підходи до налаштування: приклади, інструкції, дообучення

Режим налаштування вибирають не за загальною рекомендацією, а за властивостями потоку: скільки категорій у задачі, як часто змінюється розмітка, чи є приклади потрібної якості.

Той самий запит на десяти класах і на двохстах поводиться по-різному — порівнюємо підходи за застосовністю та межами, а не за середньою якістю.

Інструкції в запиті та few-shot промптинг не конкурують: правила фіксують формат відповіді, порядок полів і заборони, приклади показують межу між близькими класами. Дообучення моделі підключають, коли таксономія стабільна і накопичених прикладів вистачає для стійкого розділення.

Порівняння підходів

Обсяг набору прикладів підбираємо за найгіршим класом, а не за середнім: 5–15 прикладів на клас для запиту, від сотні для дообучення.

Якщо категорій більше, спочатку перевіряємо ієрархію або двоступеневу схему — плоский список на 50+ класів втрачає точність незалежно від обраного режиму.

Етапи впровадження: від аудиту даних до передачі

Перш ніж писати формулювання, ми розбираємо корпус: скільки розмічених прикладів припадає на кожен клас, як вони розподілені, чи є дублі та перехресні формулювання.

Від цього залежить, чи спрацює few-shot взагалі — якщо на рідкісний клас є два-три зразки, жодна інструкція не дасть стійкого результату. Порядок роботи нижче однаковий і для класифікації, і для вилучення полів.

1. Аудит корпусу даних. Оцінюємо обсяг, якість розмітки, частку рідкісних класів і розходження між розмітниками. На виході — карта даних: які категорії справді розрізняються за текстом, а які доведеться об'єднати.
2. Схема рішення. Фіксуємо, де саме працює few-shot — класифікація, вилучення сутностей або приведення тексту до корпоративного стилю. Визначаємо формат відповіді, обов'язкові поля та поведінку моделі за невпевненості.
3. Складання прикладів. Відбираємо зразки на кожен клас: короткі, однозначні, без перетинів між категоріями. Балансуємо склад і порядок — модель чутлива і до кількості прикладів, і до того, у якому порядку вони подані.
4. Стенд перевірки. Формуємо відкладену вибірку, яка не бере участі в налаштуванні, і проганяємо на ній кожну версію набору прикладів. Так видно, де покращення реальне, а де підгонка під переглянуті дані.
5. Узгодження метрик. Домовляємося заздалегідь, що вважаємо успіхом: точність за класами, повнота вилучення, частка відмов і спірних випадків на ручну перевірку. Поріг приймання фіксуємо до замірів, а не після.
6. Передача документації. Віддаємо опис набору прикладів і правил відбору, інструкцію з розширення корпусу, схему прогонів і порядок перенавчання при появі нових категорій. Команда замовника може вести доналаштування сама.

Бібліотека прикладів, шаблони запитів, регламент

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

• Бібліотека прикладів — розмічені пари «запит — еталонна відповідь» за кожним класом, окремою полицею складні та прикордонні випадки, на яких модель помилялася найчастіше.
• Шаблони запитів — заготовки під класифікацію, вилучення полів і приведення тексту до корпоративного стилю: фіксована структура, місце під приклади, правила на випадок неоднозначного входу.
• Правила версіонування — кожна правка прикладів або шаблону йде окремою зміною з поясненням, що і чому змінили; попередня версія залишається для порівняння результатів.
• Регламент перевірки — набір тестових випадків з очікуваними відповідями та порядок прогону: що вважається погіршенням і за якого розходження правка відкочується.
• Документація рішення — схема обробки запиту, вимоги до вхідних даних, відомі обмеження та перелік випадків, де обов'язкова людина.
• Порядок ескалації — хто володіє бібліотекою прикладів на вашому боці і як передати задачу нам, якщо правки перестали давати приріст якості.

Комплект розрахований на інженера, який раніше з цим не працював: за ним можна додати новий клас запитів, не перезбираючи рішення повністю.

Кейс: класифікація звернень на потоці заявок

Служба підтримки з потоком у кілька тисяч звернень на добу: кожну заявку потрібно віднести до однієї з 40 категорій, щоб передати потрібній групі та запустити регламентну відповідь.

Розмітку вели оператори вручну, і саме цей крок став вузьким місцем — на піку чергу не встигали розбирати, а помилка маршрутизації поверталася другою лінією.

Що було до впровадження

Четверо операторів розмічали чергу й розходилися в трактуванні: збіг між ними тримався на рівні 80%, тобто кожне п'яте звернення при повторній розмітці від'їжджало в іншу категорію.

Середній час від надходження заявки до призначення відповідального сягав 6–8 хвилин, а спірні категорії розбирали на загальній зустрічі — це з'їдало частину зміни.

Що змінили і що вийшло

Налаштували few-shot промптинг: у запит передавали 5–8 еталонних прикладів на категорію плюс правило низької впевненості — модель не вирішує сама, а позначає звернення флагом для оператора.

Довідник категорій і регламенти залишилися попередніми, дообучення не знадобилося, якість додатково звірили на публічному наборі Banking77.

Спірні випадки перестали розбирати масово: модель віддає оператору лише шар із низькою впевненістю — близько 6% черги, решта йде автоматично. Нова категорія додається парою еталонних прикладів, без перезбирання довідника та повторної розмітки архіву.

Чим few-shot відрізняється від дообучення моделі?

Few-shot підхід не змінює ваги моделі: ви описуєте задачу словами й додаєте кілька розмічених прикладів прямо в запиті. Поведінка змінюється на наступному ж виклику — правка формулювання або заміна одного прикладу дає новий результат без перезбирання моделі.

Дообучення моделі працює інакше: приклади йдуть у датасет, за ним оновлюються ваги, і на виході з'являється окремий артефакт, який потрібно версіонувати й супроводжувати.

Вимоги до розмітки тут на порядок вищі — сотні й тисячі узгоджених прикладів, окрема вибірка для перевірки, контроль розходжень між розмітниками. Помилка в розмітці не видна одразу: вона спливає вже в поведінці готової моделі.

Трудомісткість підтримки розходиться при першій же зміні постановки. У few-shot достатньо поправити приклади й прогнати той самий набір перевірок, щоб переконатися: сусідні сценарії не зламалися.

У дообученні кожна зміна класу — це новий прохід: збір даних, навчання, порівняння з попередньою версією та перевірка на регресіях.

Перенесення на нові категорії теж влаштоване по-різному. Few-shot заводить нову категорію двома-трьома прикладами й одразу показує, де модель плутається, — це швидкий спосіб перевірити саму постановку задачі. Дообучення дає більш стабільну поведінку, коли класів багато, а вимоги до стилю й формату жорсткі.

Межа проходить за частотою змін. Якщо правила й категорії живуть тижнями, виграє few-shot; якщо задача стабільна, а потік однотипних запитів великий, окупається дообучення.

Часто беруть обидва інструменти: дообучення закриває базову якість на масових класах, few-shot — рідкісні випадки та швидкі правки поверх.

Технічні сумніви: якість, обсяг, підтримка

Заперечення в інженерів і техлідів зазвичай одні й ті самі: скільки прикладів реально потрібно, що робити з рідкісними класами і як оновлювати рішення, не зупиняючи сервіс. Відповідаємо по пунктах — з тією конкретикою, яку бачимо в проєктах.

Що робити з рідкісними категоріями, де прикладів майже немає?

Рідкісний клас не витягується прикладами самотужки, тому збираємо його з кількох джерел: накопичені логи звернень, розмітка прикордонних випадків аналітиком, ієрархія — спочатку велика група, потім уточнення всередині неї.

Поки даних мало, такі випадки йдуть на ручну перевірку з явною міткою «потребує уточнення»: загальна точність не просідає, а ми отримуємо матеріал для наступної ітерації.

Як змінювати формулювання та набори прикладів без простою?

Промпти, набори прикладів і правила версіонуються як звичайний код. Нова версія спочатку йде тіньовим прогоном на живому трафіку: рахуємо розходження з поточною, дивимося поведінку на золотому наборі.

Перемикання — кероване, а попередня версія залишається піднятою, тому повернення до неї займає хвилини, а не години узгоджень.

Обговоримо задачу й повернемося з планом робіт

Щоб розмова була предметною, а не загальною, нам достатньо кількох вступних — за ними видно, де few-shot промптинг справді закриває задачу, а де дешевше обійтися правилами або дообученням. Надішліть те, що вже накопичено: чернетки промптів, спірні приклади, чинні правила фільтрації.

Що допомагає на вході:

• 30–50 обезболених прикладів вхідних даних із зазначенням очікуваної відповіді — з них збирається набір для few-shot.
• Список цільових класів або полів вилучення та рішення щодо неоднозначних випадків: відносити до класу чи віддавати на перевірку.
• Поточний промпт або правила, якщо вже пробували, і в чому саме помилялися — повтори помилок показують, де потрібен інший підхід.
• Обмеження щодо даних: де вони лежать, чи можна надсилати їх у зовнішні сервіси, хто має доступ.
• Профіль навантаження: скільки запитів на годину, яке пікове навантаження та середня довжина тексту.
• Вимоги до формату відповіді — схема, обов'язкові поля, що вважається критичною помилкою.
• Критерій приймання: яка частка правильних відповідей на вашому наборі вважається робочою.

У відповідь ми надсилаємо розбір задачі та схему рішення: які приклади потраплять у промпт, як будується розмітка, де залишається перевірка людиною.

Окремим блоком — етапи й строки, включно з пілотом на ваших даних: на ньому фіксуємо метрику якості до впровадження в робочий контур.

Опишіть задачу в двох-трьох абзацах — повернемося з оцінкою та планом робіт.