RAG vs Fine-tuning: як навчити ШІ працювати з вашими даними

Великі мовні моделі (LLMs) навчаються на публічних даних. Модель, яка “прочитала” більшу частину текстів і даних в інтернеті, все одно нічого не знає про вашу внутрішню документацію, технічні характеристики продукту, комплаєнс-політику або тікет, який ваша служба підтримки закрила минулого вівторка. Подолання цього розриву є головним інженерним викликом при впровадженні ШІ, і практикуючі фахівці вирішують його переважно за допомогою таких двох підходів: генерація з доповненою вибіркою інформації (Retrieval-Augmented Generation, RAG) та тонке налаштування (fine-tuning).

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

Проблема знань

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

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

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

Однак перш ніж вдаватися до будь-якого з цих методів, варто запитати себе, чи не можна вирішити проблему простішим способом. Напрочуд великий обсяг “знань” можна передати за допомогою добре структурованого системного запиту (system prompt) – визначення ролі, обмеження поведінки, кілька готових прикладів, ключові факти, які ніколи не змінюються. Промпт інжиніринг (prompt engineering) часто недооцінюють як перший крок, частково через його дешевизну та швидкість, а частково тому, що процес написання запиту змушує чітко розібратися в тому, що саме модель повинна знати, а не в тому, як вона повинна поводитися. Момент, коли системний промпт стає занадто громіздким – занадто довгим, нестабільним або перевантаженим рідкісними випадками – зазвичай є сигналом, що RAG або fine-tuning справді потрібні. Контекстні вікна моделей стали настільки великими, що деякі команди просто “запихують” цілі бази знань у промпт. Це працює лише до певного моменту. Розуміння того, чому це перестає працювати (затримка, вартість, погіршення уваги при дуже довгому контексті), є корисним підґрунтям для подальших архітектурних рішень.

Як працює RAG

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

Базова інфраструктура досить проста: конвеєр для завантаження даних, модель вбудовування (embedding), векторне сховище, рівень пошуку та сама мовна модель. На практиці це зазвичай означає використання LangChain або LlamaIndex для оркестрації процесів. Ланцюжок RetrievalQA від LangChain поєднує пошук і генерацію тексту всього в декількох рядках коду. VectorStoreIndex від LlamaIndex забезпечує фрагментацію, вбудовування та пошук за вашими документами з розумними налаштуваннями за замовчуванням. Вибір векторного сховища залежить від стадії проєкту. Chroma та Qdrant популярні для локальної розробки та ранніх прототипів: не потребують облікового запису, легко налаштовуються та інтегруються з LangChain і LlamaIndex. Якщо ваша команда вже використовує PostgreSQL, розширення pgvector додає векторний пошук без впровадження нової інфраструктури. Для масштабного виробництва Pinecone та Weaviate є найбільш поширеними хостинговими варіантами. Weaviate особливо корисний, якщо вам потрібен гібридний пошук (поєднання векторної схожості та фільтрування за ключовими словами), що часто важливо для реальних корпоративних даних. У крайньому разі (мільярди векторів і вимоги до затримки на рівні мілісекунд) стандартним вибором є FAISS – бібліотека з відкритим кодом від Meta.

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

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

Як працює fine-tuning

Fine-tuning змінює саму модель. Ви берете попередньо навчено модель: Llama 3, Mistral, DeepSeek або модель на кшталт Claude чи GPT-5.4, яка надає API для тонкого налаштування, і продовжуєте її навчання на прикладах із конкретної галузі. Ваги моделі оновлюються відповідно до патернів у ваших даних: термінології, стилю міркування, формату відповідей, галузевих стандартів.

Для моделей із відкритими вагами інструментарій суттєво покращився. Бібліотека trl від Hugging Face з SFTTrainer дозволяє виконувати контрольоване тонке налаштування з мінімальною кількістю шаблонного коду. Методи з ефективною кількістю параметрів, такі як LoRA та його квантований варіант QLoRA – обидва реалізовані в бібліотеці peft – дозволяють донавчати великі моделі навіть на обмеженому обладнанні, оновлюючи лише невелику частину ваг. Зокрема, при використанні QLoRA базова модель стискається до 4-бітної точності перед навчанням, що значно зменшує вимоги до пам’яті. Наприклад, модель Llama 3 70B, яка зазвичай потребує кластера з кількох графічних процесорів, може бути адаптована навіть на одному вузлі A100. Для розробників, які не хочуть керувати інфраструктурою навчання, OpenAI та Anthropic пропонують API для тонкого налаштування своїх хмарних моделей: ви надаєте датасет, вони виконують обчислення, і ви отримуєте ідентифікатор моделі, який викликаєте як будь-який інший.

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

Втім, витрати суттєві. Обчислювальні ресурси для навчання великих моделей залишаються дорогими навіть із використанням LoRA. Підготовка датасету – складне завдання: неякісні дані погіршують результати і це важко діагностувати. Оновлення знань потребує повторного навчання або додаткових циклів fine-tuning. І навіть донавчені моделі можуть “галюцинувати”, оскільки генерують відповіді на основі ваг, а не перевірених джерел.

Коли і що краще використовувати

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

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

Є також аспект вартості, який легко пропустити на етапі проєктування, але важко ігнорувати на етапі виробництва. RAG-пайплайн зазвичай передбачає виклик embedding-моделі, пошук у векторній базі та генерацію відповіді великою моделлю – це створює значну затримку та вартість на кожен запит, яка швидко зростає при масштабуванні. Натомість добре налагоджена менша модель, наприклад, варіант Mistral або Llama з 7 або 13 млрд параметрів, може обслуговувати сценарії використання з великим обсягом даних значно дешевше та зі значно меншою затримкою на виході (найгірший час відгуку, який має найбільше значення в користувацьких застосунках). Якщо ваше завдання чітко визначене, а навчальні дані якісні, налагоджена невелика модель часто перевершуватиме більшу загальну модель із RAG, і робитиме це швидше та дешевше. Компроміси очевидні: вразливість до оновлень знань, накладні витрати на обслуговування наборів даних та відсутність прив’язки до джерел.

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

Як зрозуміти, що це працює

Саме цю частину більшість команд пропускає, і зрештою це створює проблеми. Побудувати RAG-пайплайн або виконати fine-tuning моделі – цілком досяжне завдання. Натомість перевірити, чи система дійсно працює ефективно в виробничому середовищі, набагато складніше і менш привабливо.

Для RAG-систем практичним стандартом стала система Retrieval-Augmented Generation Assessment (RAGAS). Це фреймворк, який призначений для оцінки якості конвеєрів RAG без необхідності повного ручного анотування. RAGAS оцінює ефективність за чотирма критеріями:

1. достовірність (чи дійсно відповідь відображає знайдений контент, чи модель вигадує щось?);
2. релевантність відповіді (чи відповідає модель на поставлене запитання?);
3. точність контексту (чи знайдені фрагменти є релевантними, чи є там шум?);
4. відтворення контексту (чи знайдені всі важливі фрагменти, чи щось пропущено?).

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

Для донавчених моделей все більшого поширення набуває підхід “LLM як суддя” (LLM-as-judge): використання потужної моделі для оцінки результатів вашої налаштованої моделі за певною шкалою. Цей метод не є досконалим і має власні упередження, але він масштабується набагато краще, ніж оцінка людиною, і є достатньо швидким для використання в конвеєрах безперервної інтеграції. Поєднання спеціалізованих тестових наборів, автоматизованого оцінювання на основі LLM та періодичного перегляду людиною приблизно відображає сучасний стан справ для команд, які серйозно займаються цим питанням.

Обидва підходи виграють від інфраструктури логування та відстеження з самого початку. Такі інструменти, як LangSmith (рівень спостереження LangChain) або Arize, дають змогу перевіряти окремі запити, виявляти закономірності в збоях та виявляти регресії раніше, ніж це зроблять користувачі. Інструментарій дешево додати на початку, але дорого модернізувати пізніше.

З чого почати: фреймворки, які варто знати

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

Для RAG-пайплайнів варто почати з LlamaIndex. Він спеціально створений для підключення LLM до зовнішніх даних, і його абстракції добре відповідають реальній логіці RAG – документи, індекси, запити. Базовий пайплайн для роботи з вашими власними файлами можна зібрати за один день. LangChain покриває подібну функціональність і частіше використовується у продакшені, але його універсальність ускладнює навчання: він може робити багато речей, а це означає, що існує багато способів зробити ту саму задачу. Як тільки ви зрозумієте, що насправді робить RAG-конвеєр, гнучкість LangChain стане вашою перевагою. Почніть з LlamaIndex, щоб освоїти концепції, а потім перейдіть до LangChain, коли вам знадобиться більше контролю або ви будете створювати щось на зразок агента.

Для векторних баз даних хорошим стартом є Chroma. Ця платформа працює локально, не вимагає створення облікового запису чи API-ключа та інтегрується з LlamaIndex і LangChain за допомогою всього кількох рядків коду. Коли ви будете готові до запуску в виробничому середовищі, Pinecone стане найпростішим варіантом із хостингом – це керована інфраструктура, якісна документація та SDK, які практично не заважають у роботі. Про Weaviate варто знати, якщо вам потрібен гібридний пошук з реальними корпоративними даними, що, як виявляється, має більше значення, ніж ви очікували.

Для fine-tuning найкращим вибором є екосистема Hugging Face. Бібліотека transformers містить більшість моделей з відкритими вагами; trl надає клас SFTTrainer, який керує циклом навчання для контрольованого тонкого налаштування; а peft пропонує LoRA та QLoRA – способи тонкого налаштування великих моделей без цілої стійки графічних процесорів. Ці три бібліотеки розроблені для спільної роботи, а документація Hugging Face справді якісна. Якщо управління інфраструктурою навчання здається занадто складним на початковому етапі, компанії OpenAI та Anthropic пропонують точне налаштування через свої API: ви завантажуєте набір даних – вони займаються рештою. Як результат, ви отримуєте ідентифікатор моделі, який можна викликати, як і будь-який інший.

Для оцінювання варто додати RAGAS на ранній стадії. Хоча й існує спокуса відкласти оцінку доти, доки не виникнуть проблеми, але впроваджувати її згодом буде складно. Для загальної якості відповідей (особливо fine-tuned моделей) варто звернути увагу на promptfoo – легкий інструмент з відкритим кодом для виконання наборів тестів на результатах LLM, який досить просто інтегрувати в конвеєр безперервної інтеграції.

Для спостережуваності шлях найменшого опору це LangSmith (особливо якщо ви вже використовуєте LangChain). Він дозволяє відстежувати кожен етап: пошук, побудову промпту, генерацію – і дає змогу перевіряти помилки, а не гадати про них. Arize та Weights & Biases варто знати під час масштабування, але LangSmith достатньо для більшості команд початківців.

Рекомендована послідовність навчання:

• побудуйте локальний RAG-пайплайн з LlamaIndex і Chroma;
• додайте RAGAS, щоб зрозуміти слабкі місця;
• спробуйте fine-tuning невеликої моделі з відкритими вагами за допомогою інструментів Hugging Face, щоб побачити, що зміниться.

Після цього у вас буде достатньо інтуїції для прийняття архітектурних рішень.

Примітка щодо відкритості

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

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

Команда розробників QuData