Fine-tuning

Де це стоїть на драбині

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

• Промптинг

  Хвилини на зміну, нічого утримувати. Лагодить формат, тон і більшість поведінки. Коштує токенів входу на кожному виклику — назавжди.

• Пошук

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

• Fine-tuning

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

• Продовжене передтренування

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

Чим різняться методи

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

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

Набір даних і є проєктом

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

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

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

Як це виявляється в реальній поставці

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

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

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

Де це вироджується

• Fine-tuning до серйозної спроби промптингу й пошуку, яких зазвичай вистачило б.
• Навчання на документах, щоб дати факти: виходять плавні відповіді з тихо хибними деталями.
• Відсутність відкладеного набору: запамʼятаний набір не відрізнити від вивченої задачі.
• Порівняння налаштованої моделі ні з чим замість найкращого промпту на базовій моделі.
• Непослідовні мітки: вони вчать модель бути непослідовною саме в цих місцях.
• Чисті навчальні дані для неохайного бойового вводу: перший же кривий запит поводиться непередбачувано.
• Відсутність плану й власника перенавчання: модель лишається прикріпленою до бази, на якій ніхто не хоче бути.

Коли це застосовувати

Пов’язані сторінки

• РозробкаRAG-архітектураRetrieval-augmented generation (RAG) — це спосіб змусити модель відповідати про дані, на яких її не навчали: спершу знайти доречні фрагменти, покласти їх у промпт і вимагати, щоб відповідь походила саме з них. Тому RAG — це пошукова система з мовною моделлю на кінці, і тому майже кожна хибна відповідь є збоєм пошуку, а не генерації. На цій сторінці — обидва конвеєри, як вимірювати пошук окремо, і проблема прав доступу, що перетворює демо на інцидент.
• РозробкаПромпт-інженеріяПромпт-інженерія — це робота над інструкцією, за якою діє мовна модель. Промпт — це специфікація, а не замовляння. Фрази, якими обмінюються як трюками, працюють лише тому, що додають інформацію, якої модель інакше не мала; ті, що інформації не додають, не роблять нічого. На цій сторінці — з чого складається промпт, які прийоми справді змінюють результат, як зрозуміти, чи допомогла зміна, і чому недовірений текст у промпті — це межа безпеки, а не питання формулювання.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу, побудовану на мовній моделі, і вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що той самий ввід дає той самий вивід. LLM-функції це припущення ламають, тож практики доводиться перебудовувати навколо цього. На цій сторінці — що заступає набір тестів, чим насправді є артефакт розгортання, що записувати на кожному виклику і як поводяться вартість і затримка, коли приходить справжній трафік.