Дообучення GigaChat: де базова модель ламається на даних
Дообучення GigaChat потрібне там, де базова модель впевнено відповідає на загальні питання й розсипається на внутрішніх даних компанії.
Номенклатура, скорочення підрозділів, назви тарифів і регламентів для неї — набір символів без сталих зв'язків: схожі слова вона бачила у відкритих текстах, але не бачила, як вони співвідносяться між собою саме у вашому контурі.
Звідси типові збої: модель плутає близькі за написанням позиції, підставляє загальне правило замість часткового, відповідає гладко й повз. Адаптація мовної моделі під домен не зводиться до однієї інструкції в підказці.
У підказці задають тон і формат відповіді, але не можна вкласти знання, якого немає: довідник у контексті модель перекаже, а зв'яже артикул із категорією, причину повернення з типом браку або пункт регламенту з конкретним кроком — уже ні.
Подовження інструкції проблему не знімає: чим більше в підказці довідкових даних, тим сильніше розсіюється увага до деталей, а весь довідник доводиться передавати на кожному запиті.
Саме на цьому ламається якість відповідей у чат-помічнику: фахівець переперевіряє кожен другий висновок, і інструмент замість прискорення роботи додає ще один крок.
Помилки базової моделі на внутрішніх даних при цьому виглядають правдоподібно — впевнене формулювання без опори на факт.
Дообучення переносить знання в саму модель: вона вчиться на ваших парах «питання — правильна відповідь», на номенклатурі, листуванні підтримки й внутрішніх регламентах, а не на їхньому описі.
Розбираємо, як це влаштовано і де проходить межа між тим, що закривається дообученням, і тим, що чесніше вирішувати пошуком по документах.
Що дає адаптація моделі під предметну область
Дообучення змінює не стиль відповідей, а їхній розподіл.
На пілотній вибірці з реальних звернень ми порівнюємо дві версії моделі на одних і тих самих питаннях: базова GigaChat на вузькій предметній області помітно «пливе», дообучена — тримає прийняту в галузі термінологію та структуру відповіді.
Ключова метрика адаптації — частка коректних відповідей на галузевих питаннях і її практичний наслідок: частка відповідей, прийнятих оператором без правок.
Рахуємо її не середнім балом по всьому набору, а зрізом за категоріями — нормативне питання, розрахунок, довідковий запит, розбір ситуації: усереднення приховує провали в окремих категоріях, а саме вони вирішують, чи увійде інструмент у робочий процес.
Відтворюваність формулювань важливіша за одиничну вдалу відповідь.
На близьких за змістом запитах адаптована модель тримає один шаблон викладу й не змінює трактування від прогону до прогону — розкид відповідей на контрольній вибірці падає, оператор перестає переперевіряти кожен другий рядок, а ручні правки звужуються до випадків, де потрібна свіжа ввідна.
Зникає й цілий клас відмов: вигадані пункти регламентів, неіснуючі реквізити, посилання на документи, яких немає.
Публічні дослідження з адаптації мовних моделей фіксують ту саму закономірність — вимірюваний приріст на вузькій області дає помірний обсяг акуратно розмічених пар «питання — відповідь», тоді як сире вивантаження документів скоріше розмиває результат.
Метрики якості генеративної моделі знімаємо на відкладеній вибірці, яку модель не бачила під час навчання: інакше зростання точності виявиться наслідком запам'ятовування прикладів, а не розуміння предметної області.
Способи адаптації моделі: порівняння підходів
Способи адаптації GigaChat вирішують різні завдання, і підміняти один одним — типова помилка. Підказки та інструкції змінюють поведінку моделі без правки ваг: результат видно відразу, відкат — одним рядком конфігурації.
Пошук у внутрішній базі знань підключає факти, яких у моделі немає, і оновлюється разом із документами. Дообучення на прикладах перебудовує стиль, формат відповіді й галузеву логіку там, де інструкціями вже не втримати.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Підказки та інструкції | Правила, тон і структура відповіді змінюються часто, потрібен швидкий старт | Довга інструкція займає вікно контексту, поведінка залишається ймовірнісною |
| Пошук у базі знань | Відповіді спираються на регламенти, договори, каталог, історію звернень | Потрібні підготовлені джерела та їхня розмітка, додається крок вилучення |
| Дообучення на прикладах | Потрібен сталий формат, своя термінологія, предметна логіка | Потрібен корпус пар «питання — зразкова відповідь», оновлення дорожче |
| Комбінація підходів | Знання живуть у базі, а стиль і формат — у моделі | Довша підготовка, потрібне одне джерело правди й контроль версій |
Вибір способу адаптації зводиться до трьох питань: де живе знання, як часто воно змінюється і наскільки жорстко заданий формат відповіді. Дані, що оновлюються щодня, витягує пошук у базі, а однакова за звучанням відповідь у тисячах звернень — дообучення.
Налаштування підказок та інструкцій залишається обов'язковим шаром у будь-якому варіанті: воно задає рамку, у якій працюють інші.
Дообучення GigaChat: етапи інженерної роботи
Дообучення GigaChat — це послідовність із контрольними точками, а не одиночний запуск навчання. Критерії приймання фіксуємо до першої правки даних: якщо метрику не можна порахувати на відкладеній вибірці, етап не закрито.
- Розбір завдання й критеріїв приймання — визначаємо, що модель має робити інакше за базову: формат відповіді, доменні терміни, коректні відмови. Одразу обираємо метрики й поріг, нижче якого результат не приймаємо.
- Аудит даних — дивимося логи звернень, регламенти, базу знань. Оцінюємо обсяг, дублі, персональні дані, розбіжності в термінах; зайве відсіюємо, решту приводимо до єдиного вигляду.
- Розмітка навчального набору — готуємо правила розмітки та еталонні пари «запит — відповідь», розмічаємо пілотний блок і перевіряємо узгодженість між розмітниками. Розходиться — правимо інструкцію, а не дані.
- Навчання — підбираємо режим і параметри за валідаційною частиною та стежимо, щоб модель не втрачала загальні навички заради доменних. Контрольні точки зберігаємо: потрібен шлях відкату.
- Перевірка на відкладеній вибірці — рахуємо метрики з першого кроку на прикладах, які не брали участі в навчанні, і порівнюємо з базовою моделлю.
- Приймання за метриками якості — зводимо результати у звіт: де приріст, де паритет, що йде в продуктив.
- Передача й навчання команди — віддаємо конфігурації, інструкцію з розмітки та порядок дообучення на нових даних.
Етапи впровадження моделі йдуть в одному порядку — від критеріїв приймання до передачі команді. Оновлення на нових даних проходить той самий цикл, а якість порівнюється з уже прийнятою версією.
Артефакти передачі: ваги, схеми, регламенти
Передача — це не «надіслали ваги й попрощалися». Дообучення GigaChat закінчується тим, що у вашої команди залишається комплект, достатній для самостійного запуску, оновлення й відкату моделі — без звернення до нас за кожним кроком.
- Ваги дообученої моделі та файли адаптерів — артефакт, який розгортається у вашому контурі відтворювано, за зафіксованою конфігурацією.
- Картка моделі та межі застосовності: базова модель, обсяг навчальної вибірки, метрики на відкладеному наборі та чесно описані межі — які теми й формати відповідей модель тримає впевнено, де починає помилятися.
- Схема контуру: де зберігаються ваги, де виконується виведення, як влаштовані препроцесинг запиту, логування й оцінювання якості відповідей.
- Політики доступу до даних: ролі та права, що маскується до запису в лог, термін зберігання, правила вивантаження вибірки для повторного навчання.
- Скрипти запуску й конфігурації середовища — розгортання та перевірка працездатності на чистій машині повторюються однією командою.
- Регламент оновлення й відкату: як накопичувати нові приклади, за якими метриками приймати версію, хто підписує випуск і як повернутися на попередній адаптер, якщо якість просіла.
- Протокол приймальних прогонів на вашому наборі запитів: що було до дообучення і що стало після.
Усе це лягає у ваш репозиторій і документацію, а не залишається в нашому листуванні. Якщо за якимось пунктом у вас уже є своя практика — наприклад, логування ведеться в загальному контурі — підлаштовуємо комплект під неї, а не навпаки.
Кейс: розбір звернень у підтримку після адаптації
Відділ підтримки розбирав звернення в загальній черзі: оператор сам визначав тему, шукав типову відповідь і переписував її під клієнта.
На кількох тисячах звернень на місяць це давало довгу першу реакцію й помітну частку листів, що пішли не тому фахівцю, — їх пересилали заново, і клієнт чекав двічі.
Що було до
Історичних звернень накопичилося достатньо, але єдиної розмітки не було: теми перетиналися, частина дублювалася формулюваннями, відповіді операторів розходилися в деталях. Навчати модель на такому зрізі напряму — означає отримати впевнені помилки на рідкісних, але дорогих темах.
Що змінили
Зібрали корпус закритих звернень, звели теми до фіксованого списку й вибірково переперевірили розмітку: спірні випадки розводили письмовим правилом, а не рішенням окремого оператора.
На цьому корпусі пройшло дообучення моделі на базі GigaChat — вона визначає тему й пропонує чернетку відповіді, яку оператор править перед надсиланням.
Що стало
Фінальне слово залишилося за людиною: на нетипових темах модель позначає відповідь як таку, що потребує перевірки, і сама його не надсилає. Метрики до й після впровадження рахували на одному й тому самому списку категорій — інакше порівняння роз'їжджається через перерозмітку.
| Метрика | До | Після |
|---|---|---|
| Точність маршрутизації звернень | 71% | 93% |
| Звернення без пересилання | 78% | 96% |
| Час першої реакції | базовий | приблизно вдвічі коротший |
Головний висновок кейсу дообучення моделі: результат дає не розмір моделі, а якість корпусу й заздалегідь записані правила на спірні випадки. Якщо розмітку не зводити до навчання, модель просто закріплює старі розбіжності черги.
Що робити, якщо модель уже розгорнута в контурі компанії
Якщо помічник уже працює в контурі, завдання не в тому, щоб його замінити, а в тому, щоб підмінити модель під ним — без зупинки сервісу.
Тому налаштовану версію розгортаємо поряд із чинною й перемикаємо трафік поступово: спочатку на внутрішні перевірки, потім на одну команду, далі на весь контур.
Попередня версія залишається робочою до останнього кроку, і відкат займає одну операцію, а не відновлення з резервних копій.
Поточні інструкції переносяться майже повністю: роль і тон, регламенти й заборони, словники термінів, шаблони типових відповідей, правила звернення до довідників.
Межа переробки проходить там, де старі правила були обхідними — дублювальні обмеження, ручне підганяння формату, багатослівні підказки.
Налаштована модель тримає стиль і структуру сама, тому довгі інструкції починають заважати: їх знімаємо, а місце, що звільнилося, іде в еталонні приклади.
План міграції помічника — це послідовність кроків: інвентаризація живих сценаріїв, фіксація еталонної вибірки запитів і правильних відповідей, складання налаштованої версії на цих даних, тіньовий прогін на реальному потоці з порівнянням за часткою збігів з еталоном, частками відмов і часом відповіді, потім поступове перемикання трафіку й закріплення результату — оновлені інструкції, описаний відкат, регламент супроводу у вашої команди.
Дообучення GigaChat у такому сценарії — керована заміна ядра: сервіс продовжує відповідати, а якість зростає на тих самих сценаріях.
Технічні сумніви: дані, обсяги, ризики, строки
Перед стартом дообучення GigaChat замовники ставлять одні й ті самі питання — вони стосуються не моделі, а керованості процесу: обсягу прикладів, якості розмітки, перевірки результату, ризику втратити загальні знання й роботи в закритому контурі.
Скільки даних потрібно для навчання?
Поріг задає завдання: для вилучення полів і класифікації звернень достатньо кількох сотень узгоджено розмічених пар «запит — еталонна відповідь», для стилю й тональності відповідей — однієї-двох тисяч.
Тисяча прикладів за одним правилом працює краще за три тисячі суперечливих, тому стартовий набір збираємо з накопиченого листування й добираємо рідкісні сценарії окремо.
Що робити, якщо розмітка слабка?
Якщо приклади розмічали різні люди без регламенту, модель вивчить шум і суперечності. Перед навчанням проганяємо набір через звірку: знаходимо конфліктні пари, спірні випадки віддаємо вашому експерту на рішення, залишок добираємо синтетичними прикладами під контролем людини.
Як перевіряється якість моделі?
На відкладеній вибірці, яку модель не бачила: дивимося частку правильних відповідей, повноту за рідкісними класами й стійкість до перефразувань. Приймання йде за метриками вашого завдання та порівнянням із базовою поведінкою, а не за загальним враженням від окремих відповідей.
Чи не втратить модель загальні знання?
Ризик є: навчання на вузькому наборі витісняє попередні навички. Тому змішуємо цільові приклади із загальними, обмежуємо вплив на ваги й перед випуском проганяємо контрольний список питань поза темою — на них відповіді не повинні деградувати.
Чи можна працювати в закритому контурі?
Так: навчання й виведення розгортаються у вашій інфраструктурі, дані не залишають периметр, доступи видаються за ролями, набори й отримані ваги зберігаються з журналом операцій. За потреби працюємо на ізольованому стенді без зовнішнього мережевого доступу.
Обговорімо завдання: з чого починається проєкт
Щоб обговорити завдання дообучення предметно, готовий технічний документ не потрібен — достатньо опису процесу. Розкажіть, які звернення модель має обробляти, на яких помиляється зараз і що вважається правильною відповіддю в спірних випадках.
- Де проходить межа: які запити модель закриває сама, а які зобов'язана передати оператору.
- Які дані вже є — листування підтримки, база знань, регламенти, вивантаження — і в якому вони вигляді.
- Що вважається помилкою: неточна відповідь, вигадане посилання на документ, відмова відповідати, зміна тону.
- Обмеження за відгуком: скільки секунд припустимо чекати на відповідь і який обсяг звернень потрібно витримати.
- Хто на вашому боці приймає результат і за якими прикладами перевірятиме якість.
- Куди рішення вбудовується — сайт, чат підтримки, внутрішня система — і як отримає доступ до даних.
У відповідь надсилаємо схему рішення, склад робіт і план етапів із точками контролю: де готуємо й розмічаємо дані, де навчаємо, де перевіряємо на відкладеній вибірці.
Оцінка проєкту адаптації моделі спирається на обсяг і якість даних, а не на загальні припущення, тому не розвалюється після першого уточнення.
Опишіть завдання у вільній формі та додайте кілька прикладів діалогів — повернемося з оцінкою й планом. Цього достатньо, щоб призначити старт проєкту й зафіксувати порядок робіт.
