Промпт, RAG чи дообучення: що насправді потрібно вашому ШІ-рішенню

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

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

Яку помилку ви виправляєте

Фраза «ШІ відповідає погано» нічого не говорить про причину. Для вибору методу корисно розкласти помилки хоча б на чотири групи.

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

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

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

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

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

Коли достатньо промпта

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

Що зазвичай входить у хороший промпт для бізнес-задачі:

• Мета і межі. Що саме має зробити модель, для кого, чого робити не можна.
• Формат результату. Перелік полів, допустимі значення, правило для відсутніх даних.
• Кілька прикладів. Два-п'ять пар «вхід і правильний вихід», бажано з різними складними випадками, а не лише з очевидними.
• Потрібний контекст. Якщо даних небагато і вони стабільні, їх можна просто вставити в інструкцію.

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

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

Коли потрібен RAG

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

Цей підхід доречний, коли інформація:

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

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

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

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

Коли має сенс дообучення

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

Ознаки, що дообучення варто розглянути:

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

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

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

Коли методи поєднуються

На практиці складні задачі часто мають обидва типи проблем. Модель потребує свіжих даних і водночас стабільної поведінки. Тоді методи доповнюють один одного.

Типовий шлях може виглядати так:

1. Базовий промпт і контрольна вибірка. Фіксуємо стартову якість.
2. Статичні приклади в промпті. Перевіряємо, чи зросла стабільність.
3. Пошук релевантних фрагментів або прикладів під кожен запит. Якість залежить від того, наскільки контекст справді стосується питання.
4. Якщо поведінка все ще нестабільна і є якісні приклади, розглядаємо дообучення, причому на прикладах, які вже містять знайдені фрагменти.
5. Додаємо перевірку фактів у відповіді й повертаємося до оцінювання.

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

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

Як ухвалити рішення за даними

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

Навчальна матриця вибору

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

Під час порівняння варіантів враховуйте не лише якість:

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

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

Висновок

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

Що можна зробити на власному процесі вже зараз:

1. Зберіть 30-50 реальних запитів і запишіть для кожного правильну відповідь. Відкладіть цю вибірку як контрольну.
2. Прогоніть поточне рішення і позначте тип кожної помилки: відсутній факт, неправильний формат, непослідовна класифікація, хибне використання знайденого фрагмента.
3. Для домінантного типу помилки зробіть найпростіший відповідний крок: контекст для фактів, приклади й схему для формату.
4. Повторно виміряйте якість на тій самій контрольній вибірці. Не додавайте її приклади в інструкцію.
5. Оцінюйте дообучення лише тоді, коли простіші кроки вичерпані, є окрема навчальна вибірка і ви перевірили актуальну доступність навчання для своєї моделі.
6. Запишіть вартість помилки, впровадження і супроводу для кожного варіанта, щоб рішення ухвалювалося за цифрами.

Якщо ви обираєте спосіб покращити якість ШІ для конкретного процесу, команда BotLabs може розібрати його з вами на 15-хвилинній консультації. Обговоримо, які помилки дає поточне рішення, які документи й приклади вже є і з якої контрольної вибірки варто почати перевірку. Наступним кроком визначимо, що саме варто перевірити на ваших даних.

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