Тонке налаштування GPT-4 і GPT-4o: кастомізація LLM під бізнес-завдання

Fine-tuning GPT-4: чому базова модель не вирішує завдання

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

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

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

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

Дообучення мовної моделі тут — не «покращення заради покращення», а спосіб перенести правила з підказки у ваги.

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

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

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

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

Що дає fine-tuning: точність і керованість

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

Ефект видно на відкладеній частині даних, яку модель не бачила під час навчання: частка правильних відповідей зростає з 70–75% до 90–95%, а розкид між запусками скорочується до одиниць відсотків.

Fine-tuning GPT-4 на боці OpenAI дає точність на вашій предметній області, а не на усередненому наборі з відкритих джерел.

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

Розмітка на 300–1000 реальних діалогів це закриває — модель відтворює вашу лексику й однаково відповідає на перефразування одного питання: розходження між п’ятьма формулюваннями падає з 20–30% до 5%.

Єдиний формат виведення — окремий вимірюваний ефект.

Жорстка схема відповіді (поля, їхній порядок, значення з довідників, відсутність вступів) знімає шар постобробки: відповіді розбираються кодом напряму, а частка звернень, які співробітник перевіряє вручну, падає з 30–40% до 5–10%.

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

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

Режими адаптації моделі: порівняння підходів

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

Це не взаємовиключні опції, а різні за ресурсами й ризиком способи дообучити GPT-4 — від правки поведінки до перебудови самої моделі.

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

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

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

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

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

1. Аудит даних. Дивимося, що вже накопичено: листування, звернення, внутрішні документи, готові пари «питання — еталонна відповідь». Оцінюємо обсяг за цільовими сценаріями, знаходимо дублі, суперечності в розмітці та персональні дані, які потрібно знеособити.
2. Постановка метрики якості. До навчання фіксуємо, що вважаємо успіхом: точність на цільовому класі запитів, частка відповідей у потрібному форматі, частка коректних відмов «даних немає». Метрика узгоджується з вами — інакше приймання перетворюється на суперечку про смаки.
3. Підготовка й розмітка набору. Пишемо інструкцію для розмітників, розбираємо спірні випадки, ділимо дані на навчальну, валідаційну та відкладену вибірки. Відкладена збирається окремо й до самого кінця не бере участі в навчанні.
4. Дообучення й підбір режиму. Порівнюємо дообучення з базовою моделлю та з налаштуванням через підказки, стежимо за перенавчанням: зростання на навчальних прикладах при падінні на валідації — сигнал зупинитися.
5. Перевірка на відкладеній вибірці. Проганяємо модель на прикладах, яких вона не бачила. Це єдина чесна оцінка: усе, що бачив процес навчання, показує якість запам’ятовування, а не роботи.
6. Впровадження. Підключаємо модель до вашого контуру, задаємо обмеження за форматом виведення, журналювання запитів і відкат на базову версію при деградації.
7. Приймання результату й передача. Прогін за узгодженими сценаріями, звірка з метрикою, потім документація, доступи й навчання вашої команди — підтримка далі можлива власними силами.

Артефакти впровадження: ваги, схеми, регламенти

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

• Ваги моделі та адаптери дообучення. За кожним сценарієм — окремий набір, щоб дообучення під одне завдання не погіршувало поведінку в іншому. Поруч фіксуються контрольна сума набору й версія базової моделі, на якій він навчався.
• Конфігурації запуску. Параметри генерації, системні підказки, ліміти довжини відповіді та правила фільтрації — у вигляді файлів у репозиторії, а не налаштувань у чужій панелі. Зміна конфігурації проходить той самий шлях перевірки, що й код.
• Набір перевірок якості. Тестові запити з очікуваними відповідями та прогін за ними: метрика до й після для кожної нової версії, щоб деградація ловилася до викату.
• Схема контуру. Де розміщені ваги, які сервіси з ними працюють, як ходить трафік, хто має доступ до даних і як улаштоване журналювання запитів.
• Регламент оновлення й відкату версії. Хто ініціює випуск, які перевірки обов’язкові, скільки версій зберігається і як повернутися на попередній набір. Відкат — за хвилини, без повторного навчання.
• Документація на контур. Карта компонентів, порядок розгортання з нуля, точки інтеграції з вашими системами та дії при деградації якості.
• Доступи й права. Репозиторій, реєстр артефактів та інфраструктурні облікові записи оформлюються на ваші акаунти, щоб супровід не залежав від однієї команди.

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

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

Точка старту

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

Частка правильних маршрутів трималася близько 71%: змішані теми в одному листі, складні формулювання й різні назви однієї й тієї самої послуги збивали сортування за правилами.

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

Що змінили і що стало

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

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

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

Частка правильних маршрутів зросла з 71% до 93%, час до передачі у відділ скоротився до десятків секунд, ручного сортування в потоці не залишилося.

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

Чим дообучення відрізняється від підказок у промпті?

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

Друге змінює ваги на ваших прикладах, і потрібна поведінка стає для моделі її власною, а не підказаною.

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

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

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

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

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

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

Технічні сумніви перед стартом робіт

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

Чи можна навчати модель у закритому контурі?

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

Модель не втратить загальні навички?

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

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

Як часто потрібне повторне навчання?

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

Обговоримо завдання: що потрібно з вашого боку

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

• Постановку завдання — який процес автоматизуємо, хто ним користується і як виглядає успішна відповідь.
• Приклади «вхід → правильна відповідь»: навіть 50–100 розмічених випадків показують, чи потрібне дообучення GPT-4 на ваших даних або достатньо точного налаштування інструкцій.
• Критерії приймання — частка правильних відповідей на відкладеній вибірці, допустима затримка відповіді, формат виведення.
• Обмеження щодо даних: що можна виносити за периметр, що залишається на вашому боці, які вимоги безпеки діють.
• Поточні напрацювання — промпти, раніше дообучені моделі, логи звернень: часто частина роботи вже зроблена.
• Контакт інженера з вашого боку для уточнень щодо розмітки та спірних прикладів.

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

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