Ключові висновки

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

Знання ≠ поведінка ≠ інструменти ≠ зовнішня пам’ять. Базова модель володіє мовою; SFT змінює стиль і формат; RAG підставляє актуальні факти; агенти діють через системи.

LoRA — спосіб дешевої адаптації, а не окремий тип знань. Це техніка «як змінювати ваги дешевше», а не відповідь на питання «чому вчити».

RAG не навчає модель «пам’ятати PDF». Він підключає зовнішні джерела на час відповіді. Для регламентів, цін і версій документів це зазвичай правильніше, ніж донавчання корпусу.

Зріла система — гібрид. Попереднє навчання/SFT/вподобання задають здібності й поведінку; RAG — факти; інструменти — дії; оцінювання — перевірку якості.

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

Що насправді означає «навчити модель»

Поширена омана: «якщо LLM має знати наші документи, її треба донавчити на цих документах». Звідси з’являються проєкти «завантажити 100 000 PDF у донавчання» — дорогі, погано оновлювані й майже непрозорі.

Є принципово різні механізми:

1. Попереднє навчання (pretraining) — створення базової мовної моделі на величезному корпусі.
2. Продовжене попереднє навчання (continued pretraining) — доналаштування на спеціалізованому корпусі домену.
3. SFT (контрольоване донавчання) — навчання слідувати інструкціям і формату.
4. Оптимізація вподобань (RLHF, DPO і подібні методи) — надання переваги кращим відповідям.
5. LoRA / PEFT — технічний спосіб змінювати малу частку параметрів.
6. RAG — пошук у зовнішній базі без зміни ваг.
7. Використання інструментів / агенти — виклик API, SQL, файлів і бізнес-сервісів.

Коротко: навчання змінює параметри. RAG і інструменти зазвичай не змінюють параметри — вони змінюють контекст і можливості дії.

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

Практичний наслідок для бюджету: зміна ваг потребує датасету, обчислень, версіонування чекпойнтів і регресійного оцінювання. Підключення RAG потребує розбору документів, індексу, ACL і метрик пошуку. Підключення інструментів потребує контрактів API, ідемпотентності й журналювання. Це різні статті витрат і різні ризики — тому «просто навчимо модель» рідко буває точною постановкою задачі.

Рівень 1. Попереднє навчання — базова модель

Попереднє навчання (pretraining) — основне навчання на величезному масиві текстів. Спрощено:

тексти → токенізація → нейромережа → передбачення наступного токена → помилка → оновлення ваг

На кожному кроці модель бачить префікс («У 1863 році було видано …») і вчиться передбачати наступний токен. Після мільярдів таких кроків з’являються внутрішні уявлення мови, синтаксису, понять, стилів і великої кількості фактів. Але це не таблиця «факт → значення»: знання розподілені по параметрах.

Чому етап дорогий: обсяг токенів, розмір моделі, кластери GPU/TPU, час, зберігання чекпойнтів, розподілене навчання. Конкретні ціни й розміри швидко застарівають — важливіший принцип: створити нову базову LLM з нуля має сенс одиницям організацій, решті зазвичай вигідніше брати готову базу й адаптувати її рівнем нижче.

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

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

Що таке ваги моделі

Параметри (ваги) — числа всередині шарів мережі. Під час навчання вони зсуваються в бік меншої помилки передбачення. Інтуїтивно:

W_new ≈ W_old − learning_rate × gradient

Коли кажуть «ми навчили модель», майже завжди мають на увазі: змінили ці числа (усі або частину). Коли кажуть «підключили RAG», ваги зазвичай лишаються тими самими: змінюється лише текст, який модель бачить у контексті запиту.

Звідси практичний висновок: якщо інформація має оновлюватися щодня, зберігати її у вагах — як писати регламент на камені. Якщо потрібна стійка поведінка («завжди відповідай JSON-схемою X»), зміна ваг або сильний SFT/інструкції можуть бути доречними. Детальніше межу «знання vs поведінка» розібрано в матеріалі коли справді потрібне донавчання.

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

Рівень 2. Продовжене попереднє навчання — адаптація до домену

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

Base LLM → доменний корпус → continued pretraining → Domain-adapted LLM

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

Коли дивитися в цей бік: величезний закритий корпус, рідкісна термінологія, слабка нульова база на домені. Коли не дивитися: «у нас 500 регламентів» — це задача RAG і підготовки корпусу, а не повторного попереднього навчання.

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

Рівень 3. SFT — поведінка та інструкції

Після попереднього навчання модель уміє продовжувати текст, але не обов’язково стабільно виконує інструкції. SFT вчить на парах «інструкція → бажана відповідь»:

Питання: Поясни принцип роботи RAG.
Хороша відповідь: …

Типові застосування: корпоративний тон, структурований JSON, класифікація, генерація коду в прийнятому стилі, діалоги підтримки, дотримання шаблону висновку.

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

У корпоративних контурах SFT часто працює як «клей» між продуктом і моделлю: фіксований формат чернетки тікета, єдина структура резюме зустрічі, класифікатор наміру перед маршрутизацією до RAG чи інструментів. Це зменшує хаос у відповідях без потреби «запам’ятовувати» весь wiki у вагах.

Коротко: SFT каже моделі «роби так»; RAG каже «ось свіжі факти для цієї відповіді».

LoRA і PEFT — як дешевше змінювати ваги

LoRA та інші методи PEFT часто плутають з окремим «рівнем знань». Це передусім техніка: замість оновлення всіх параметрів навчають невеликі адаптерні матриці поверх замороженої бази.

Base model (заморожена)
        +
   LoRA adapter
        ↓
 Specialized model

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

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

Рівень 4. Оптимізація вподобань — «ця відповідь краща»

Після SFT можна вчити модель віддавати перевагу одним відповідям над іншими. Класична схема RLHF: людина (або політика вподобань) обирає між варіантами A і B; модель зсувається до поведінки B. Сучасні альтернативи на кшталт DPO спрощують пайплайн, але ідея та сама:

SFT каже «роби так», оптимізація вподобань вчить на порівнянні «ця відповідь краща за ту».

Де доречно: безпека, ввічливість, дотримання політики продукту, зниження токсичності, надання переваги коротким/структурованим відповідям. Де не доречно як заміна: актуальні ціни, версії регламентів, персональні дані з внутрішніх систем — це знову зона RAG і ACL, а не вподобань.

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

Рівень 5. RAG — знання поза моделлю

RAG (генерація з доповненням із пошуку, retrieval-augmented generation) — ключовий шар для прикладних систем. Модель не зобов’язана «пам’ятати» корпоративні документи у вагах. Натомість:

питання → пошук → релевантні фрагменти → контекст → LLM → відповідь (+ посилання)

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

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

Зрілий RAG також враховує життєвий цикл документів: хто власник джерела, коли документ втрачає чинність, як обробляти таблиці й скани, як захищатися від впровадження шкідливих інструкцій (prompt injection) у вмісті файлів. Без цього шар виглядає як «чат із базою», а працює як генератор переконливих, але неперевірюваних відповідей.

Коротко: донавчання змінює ваги; RAG підключає зовнішню пам’ять на час відповіді.

Рівень 6. Інструменти та агенти

Наступний шар — не лише читати знання, а й діяти:

LLM ├── RAG ├── SQL ├── REST API ├── файли ├── розрахунки └── бізнес-сервіси

Запит «покажи продажі за минулий місяць і поясни падіння» може потребувати SQL, розрахунку, документів із RAG і лише потім тексту. Це вже LLM + інструменти + оркестрація + права + стан, а не «чат із моделлю». Помилки тут частіше в правах, ідемпотентності й спостережуваності, ніж у «недонавченості».

Зв’язані теми на сайті: MCP і API для LLM, маршрутизація й шлюзи в матеріалах про таксономію маршрутизації LLM.

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

Порівняння рівнів

Таблиця навмисно ставить LoRA поруч із методами навчання: це як, а не навіщо. RAG і інструменти стоять окремо: вони розширюють систему без переписування параметрів.

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

Практичний сценарій: корпоративний помічник

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

Робоча архітектура частіше виглядає так:

                 ┌─────────┐
                 │   LLM   │
                 └────┬────┘
          ┌───────────┼───────────┐
          ↓           ↓           ↓
         RAG        Tools       SQL/API
          │           │           │
   Knowledge Base  Internal    Databases

• RAG — чинні регламенти й wiki з фільтрацією за ролями.
• SFT / LoRA — стабільний формат чернетки або класифікатор намірів.
• Інструменти — створення тікета, розрахунок, читання метрик.
• Оцінювання — регресія на ваших сценаріях, а не лише публічний рейтинг (перевірка якості LLM).

У такому контурі модель лишається «мозком мови», а не єдиним сховищем правди. Знання живуть у джерелах із власниками. Дії проходять через інструменти з контрактами. Поведінка відповіді стабілізується інструкціями або вузьким SFT. Оцінювання фіксує, чи не зламалася якість після зміни індексу чи версії моделі.

Як обрати підхід

Просте дерево рішень:

Головна помилка — намагатися розв’язати все донавчанням: «у нас 100 000 PDF, давайте навчимо модель на них». Документи змінюються; застаріле знання з ваг не вилучити кнопкою; цитування й доступ погано контролюються; оновлення дороге. Альтернатива: LLM + RAG + ACL + повторне ранжування + цитування + оцінювання.

І зворотна помилка: чекати від RAG чудес без інженерії корпусу. Поганий розбір документів, нарізка, пошук, таблиці в PDF, впровадження шкідливих інструкцій у документах — усе це ламає відповідь ще до генерації. Глибина цього шару — у вже опублікованих RAG-гайдах вище; тут важливо пам’ятати межу відповідальності.

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

Оцінювання — рівень зрілості системи

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

• Пошук (retrieval): повнота й точність видачі (Recall@K, Precision@K, MRR, NDCG — як орієнтири, не як універсальні нормативи).
• Генерація: фактичність, опора на контекст, коректність цитат, релевантність відповіді.
• Система: затримка, вартість токенів, частка відмов, регресії після зміни моделі чи індексу.

Публічний рейтинг моделі — чужа вибірка. Для продукту потрібен власний набір сценаріїв. Мапа видів перевірок — у перевірці якості мовних моделей; контур регресії — у контурі оцінювання ШІ.

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

Архітектура зрілої ШІ-системи

Фінальна формула не «RAG кращий за донавчання», а:

Вибір між навчанням моделі й зовнішньою базою знань — архітектурне рішення, а не змагання технологій.

                  AI SYSTEM
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Model          Knowledge       Tools
  pretraining         RAG        APIs / SQL
  SFT / LoRA        Search        Agents
  DPO/RLHF         Sources

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

Якщо потрібен продакшен-зріз — RAG, агенти, MCP або LLM-шлюз із бюджетами — див. послугу впровадження ШІ.

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

Часті запитання

Висновок

Навчання LLM — не один важіль, а стек рішень. Попереднє навчання і пост-навчання формують здібності й поведінку; RAG тримає факти зовні; інструменти дають дію; оцінювання тримає систему чесною. У лабораторії коду це виглядає як акуратна збірка контуру, а не магічне «залити PDF у ваги».

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

Далі за кластером: чому з’явилися LLM, чому підприємствам потрібен RAG, коли потрібне донавчання, промислова інженерія RAG, перевірка якості LLM.