Коли fine-tuning має сенс (а коли достатньо RAG)

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

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

Fine-tuning змінює ваги моделі. Ви тренуєте її на власних прикладах вхід-вихід і зберігаєте отримані зміни в самій моделі. Після fine-tuningu модель інакше генерує текст навіть без додаткового контексту. Це постійно й не можна скасувати без повторного тренування.

Ключове речення: RAG змінює що модель знає, fine-tuning змінює як модель поводиться.

Нижче три конкретні випадки, в яких fine-tuning дає цінність, яку RAG не відтворить:

1. Стійкий стиль і формат виходу. Коли ваша система має генерувати звіти у суворо визначеному шаблоні (наприклад, певний XML, юридичний формат, галузева нотація) і жоден промпт не утримує це стабільно протягом тисяч викликів — fine-tuning фіксує формат у вагах. Приклад: система, що генерує технічні описи за стандартом ISO, де відхилення від шаблону викликають регуляторні проблеми.

2. Спеціалізований жаргон і термінологія домену. Загальна модель знає слово «декретація» лише в контексті бухгалтерії. Якщо ваш процес використовує скорочення, акроніми та термінологію, яку модель не бачила під час претренінгу, кількасот прикладів fine-tuningu навчать її правильно їх інтерпретувати та генерувати. RAG може надати визначення, але не змінить глибокого розуміння контексту використання.

3. Зниження вартості та латентності через спеціалізацію. Мала модель (7B-14B), натренована на конкретному завданні (наприклад, лише класифікація намірів обслуговування клієнтів), у рази дешевша в інференсі, ніж велика загальна модель. Якщо ваша система виконує мільйони викликів на місяць на одному вузькому завданні — fine-tuning меншої моделі може окупитися за кілька місяців. Порахуйте це в калькуляторі інференсу.

Корисно знати, коли НЕ обирати fine-tuning, бо це частіша помилка:

1. «Ми хочемо, щоб модель знала наші документи.» Це саме завдання RAG. Fine-tuning на документах не є фактографічною пам'яттю — модель все одно може галюцинувати факти, тільки тепер у специфічному для вас стилі. RAG з векторною базою даних та цитуванням джерел — правильне рішення.

2. Знання часто змінюються. Якщо ваші дані оновлюються щотижня (прайс-листи, регламенти, пропозиції), fine-tuning не підходить — кожна зміна вимагатиме перетренування. RAG оновлюється шляхом додавання нових документів до бази.

3. У вас мало тренувальних даних. Fine-tuning без достатньої кількості якісних прикладів призводить до перенавчання або регресії загальних здібностей моделі. Мінімум — кількасот пар вхід-вихід хорошої якості; реально кілька тисяч для відтворюваних результатів. Якщо у вас немає стільки даних — RAG плюс промпт-інжиніринг — дешевший старт.

4. Бюджет і час обмежені. Fine-tuning вимагає інфраструктури GPU, тренувальних даних, експериментів, оцінки та підтримки нових версій моделі. Це не разовий витрата. Пілот RAG можна запустити за тижні з часткою цих витрат.

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

Якщо після аналізу вище fine-tuning — правильне рішення, процес виглядає так:

1. Зберіть навчальні пари. Кожен приклад — це вхід (промпт, контекст) і вихід (правильна відповідь). Якість важливіша за кількість — триста точних прикладів перемагають три тисячі випадкових.
2. Оберіть базову модель. Менша модель (7B, 13B) тренується швидше й коштує менше. Великі моделі 70B+ для fine-tuningu — рідкість поза найбільшими організаціями.
3. Техніка LoRA / QLoRA. Повний fine-tuning усіх ваг — марнотратство. LoRA тренує лише невелику матрицю адаптерів, що знижує вартість GPU на порядок при збереженні більшої частини ефекту.
4. Оцінка. Тестовий набір (hold-out) має бути відокремлений від тренувальних даних з самого початку. Вимірюйте завданнєві метрики (F1 для класифікації, ROUGE для генерації), а не лише суб'єктивне враження.
5. Реєстрація версій. Кожен натренований чекпоінт — це нова версія моделі з датою, набором даних та результатами оцінки. Без цього ви не знатимете, яку модель впроваджувати, і як повернутися до попередньої.
6. Підтримка. Модель дрейфує відносно зростаючої бази фактів. Встановіть політику перетренування — наприклад, раз на квартал або коли результати оцінки впадуть нижче порогу.

Усе простіше спланувати після заповнення блюпринту агента — він дозволяє побачити, де в архітектурі опиняється fine-tuning, а де RAG.

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

• Fine-tuning відповідає за стиль, формат і голос (модель говорить як ваш бренд, генерує у вашому шаблоні).
• RAG вносить свіжі факти при кожному виклику (модель не галюцинує актуальний прайс, бо просто отримує його в контексті).

Гібрид вимагає ретельної архітектури роутера, який вирішує, коли збагачувати контекст, а коли покладатися на знання з fine-tuningu. Це один зі шаблонів, які ми будуємо в рамках власного асистента AI для клієнтів.

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

Якщо ви тренуєте модель на персональних даних, на вас поширюється RODO і, ймовірно, потрібна буде DPIA. Дані, використані для тренування, «входять» у ваги моделі у спосіб, важкий для аудиту — ви не можете так легко виконати право на видалення, як у випадку з RAG, де достатньо видалити документ з бази.

Згідно з AI Act, системи високого ризику повинні документувати тренувальні дані та методологію. Fine-tuning на даних клієнтів у системах класифікації (наприклад, кредитний скоринг, рекрутинг) вимагає додаткових перевірок та можливості аудиту.

Для чутливих даних ми віддаємо перевагу self-hosting — модель тренується та працює у вашій інфраструктурі, PII не залишає організації.

Опишіть свій випадок використання — модель допоможе оцінити, чи це завдання для RAG, fine-tuningu чи гібрида (playground: PII маскуються, нульове збереження):

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

Вартість залежить від розміру моделі, кількості прикладів та обраної техніки. Тренування малої моделі 7B методом LoRA на кількох сотнях прикладів — це питання годин на GPU та відносно низька вартість у хмарі. Великі моделі 70B+ та повний fine-tuning — це витрати на багато тижнів інженерної роботи плюс вартість інфраструктури. Порахуйте свій випадок у калькуляторі інференсу або обговоріть його в рамках пілоту.

Ні. Fine-tuning фіксує стиль і поведінку, але не забезпечує надійної фактографічної пам'яті. Модель може «засвоїти» факти з тренувальних даних, але все одно галюцинуватиме, коли її запитають про щось поза ними. Це RAG з цитуванням та порогом впевненості (ескалація до human-handoff, коли немає релевантного фрагмента) є основним захистом від галюцинацій у промислових системах.

Можете, але це вимагає юридичної обережності. Персональні дані у тренувальному наборі підпадають під дію RODO та вимагають правової підстави й, ймовірно, DPIA. Після тренування видалення конкретних даних з ваг моделі технічно складне, що ускладнює реалізацію права на забуття. Рекомендуємо перед стартом провести аудит даних з юристом та обрати архітектуру, в якій PII для тренування залишається у вашій інфраструктурі. Стаття AI Act та RODO 2026 детально описує обов'язки.

Почніть зі збору якісних навчальних пар, а не з вибору інфраструктури. Визначте 200-500 конкретних прикладів вхід-вихід, які ілюструють очікувану поведінку моделі. Відразу відокремте 10-20% як hold-out для оцінки. Лише з готовими даними плануйте інфраструктуру та графік. Корисним буде блюпринт агента, який дозволя