RAG, фін-налаштування чи агенти: вибір правильного шару та порядку його створення
RAG проти фін-тюнінгу проти AI-агентів: що робить кожен з них, витрати, затримки та способи збоїв, орієнтовні правила, а також асистент з управління персоналом, який показує послідовність їх створення.
Джерела: RAG vs Fine-Tuning vs AI Agents: When to Use What in Real-World AI Systems
У майже кожному проекті з ШІ рано чи пізно виникають два запитання. Перше — чи варто отримувати документи чи налаштовувати модель. Друге — чи потрібен продукту агент чи достатньо просто розумнішого запиту. Дивно, але на них часто дають погані відповіді, і не лише початківці. Досвідчені інженери витрачали тижні на налаштування моделі, щоб вона запам’ятовувала факти, які б за один день можна було отримати за допомогою пошуку документів. Інші команди обгортали те, що насправді було просто кінцевою точкою для відповідей на запитання, фреймворком агентів лише тому, що агенти були темою кожних нарад того кварталу.
Менш захоплюючою реальністю є те, що механізми отримання інформації, її доопрацювання та агенти не є конкурентами за одну й ту саму роботу. Кожен з них вирішує окрему проблему, а системи, які працюють перед справжніми користувачами, зазвичай поєднують два з них або всі три, причому кожен елемент виконує те, у чому він найкраще справляється. У наступному розглядається те, як кожен з них працює внутрішньо, які витрати він забезпечує, як команди його зловживають, як елементи взаємодіють між собою, а також невеликий проект, який демонструє послідовність їх створення.
Що насправді робить кожен з них
Генерація з підсиленням через отримання інформації
Механізм отримання інформації не впливає на саму модель. Він лише змінює те, що модель отримує для читання перед тим, як дати відповідь.
Коли надходить запит, система перетворює його на ембеддинг — числове представлення його значення — та шукає у векторній базі даних, такій як Pinecone, Qdrant, FAISS чи Azure AI Search, збережені фрагменти, які найбільш схожі за значенням. Ці фрагменти додаються до запиту як контекст, і модель відповідає на основі цього матеріалу, а не на основі того, що вона засвоїла під час попереднього навчання.
Цінність полягає у проблемах, яких це запобігає. Моделі найлегше вигадують деталі, коли змушені відповідати, спираючись на внутрішню пам’ять, особливо щодо актуальних, неочевидних тем чи тем, специфічних для певної компанії. Надання моделі посилального тексту при кожному запиті означає, що вона обмірковує поточний матеріал та не здогадується.
Цей конвеєр має фіксовану структуру: отримання документів, їх розділення на частини, вбудовування цих частин, зберігання векторів, виконання пошуку схожості (часто у поєднанні з пошуком за ключовими словами), за бажанням переурочування рейтингу кандидатів, формування запиту та генерація результату.
Тонке налаштування
Тонке налаштування відрізняється за характером, а не лише за ступенем. Уже попередньо навчений модель продовжує навчання на підібраній вами колекції прикладів, зазвичай це пари вхідних даних та бажаного вихідного результату, які демонструють саме ту поведінку, що потрібна. Змінюються ваги, або за допомогою LoRA та QLoRA змінюється невеликий набір ваг адаптера на основі замороженого базового моделювання.
Це добре підходить для навчання правил поведінки: тону голосу, суворому формату вихідних даних, певному способу розв’язання певного типу задач чи роботи з крайніми випадками у галузі, де існують тисячі позначених прикладів. Мета — змінити стандартну поведінку так, щоб однакові інструкції не потрібно було повторювати в кожному запиті, а не додавати нові факти.
Це погано підходить для всього, що постійно змінюється. Каталог продуктів, який оновлюється щотижня, не може розумно зберігатися у вагах моделі, оскільки знання замерзають після завершення навчання, а кожне оновлення вимагає нового запуску.
Агенти
Агент розміщує модель у циклі: спостерігати, міркувати, діяти, спостерігати за результатом, знову міркувати та продовжувати, поки не буде досягнуто мети або не спрацює правило зупинки. Модель більше не дає єдиної відповіді. Вона вирішує, що робити далі, часто шляхом виклику інструментів таких як API, функції, бази даних та інші сервіси, та використовує їхні результати для наступного рішення.
Саме цей цикл перетворює систему, яка відповідає на запитання, на систему, яка виконує завдання. LangGraph, CrewAI та ручно написаний цикл ReAct — усі вони реалізують його версію: модель формулює думку, обирає інструмент, інструмент виконується, результат повертається до контексту, і цикл повторюється, поки агент не вирішить, що все завершено, або не досягне ліміту кроків. Ліміт кроків завжди слід встановлювати.
Компактний спосіб розрізнити ці три елементи:
- Отримання інформації забезпечує необхідні дані.
- Тонке налаштування забезпечує правильну поведінку.
- Агенти надають належний рівень автономії.
Порівняння
Різниці проявляються у кількох аспектах:
- Оновлення знань. Отримання інформації відбувається в реальному часі, оскільки достатньо оновити базу векторів. Налаштовані знання залишаються незмінними до наступного процесу навчання. Для агентів це залежить від того, що вони отримують або використовують.
- Витрати. Отримання інформації має помірні витрати: ембеддинги, зберігання та додаткові токени вхідних даних. Тонке налаштування є дорогим через необхідність підбору даних, обчислень, використання GPU та оцінку результатів. Витрати на агентів коливаються від помірних до високих, оскільки кожне завдання вимагає кількох викликів моделі плюс оплати за використання інструментів.
- Складність. Для отримання даних потрібне їх розділення на частини, вбудовування та налаштування процесу пошуку. Для детальної налаштуваності потрібна підготовка даних, інфраструктура навчання, цикли оцінки та захист від перенавчення. Агентам потрібне планування, інтеграція інструментів, обробка помилок та керування циклами.
- Час на налаштування. Дні для отримання даних, тижні для детальної налаштуваності, а для агентів — від днів до тижнів залежно від робочого процесу.
- Найкраще підходить для. Відповідей на запитання, пошуку документів та підтримки процесу отримання даних. Для детальної налаштуваності — тон, форматування та логіка в роботі з конкретною галуззю. Для агентів — багатоетапні завдання, автоматизація та використання інструментів.
- Затримка. Отримання даних додає один етап обробки, зазвичай від 50 до 300 мілісекунд. Детальна налаштуваність не впливає на час обробки порівняно з базовою моделлю. Агенти часто виконують кілька етапів обробки та можуть потребувати кількох секунд на кожне завдання.
- Технічне обслуговування. Завдання зі збору інформації полягає у підтримці актуальності бази знань. Налаштування означає періодичну перепідготовку моделі у міру зміни потреб. Робота з агентами передбачає оновлення робочих процесів, інструментів та інструкцій.
- Типові проблеми. Поганий збір інформації призводить до нерелевантного контексту та некоректної відповіді. Надмірна налаштованість робить модель крихкою при роботі з незнайомими даними. Агенти можуть застрягати у циклах, викликати неправильні інструменти чи спричиняти необмежені витрати.
Три ситуації, по одній для кожної
Чат-бот підтримки, який працює з документацією до продукту, дозволяє ефективно знаходити потрібну інформацію. Програмна компанія з 400 сторінками документації, журналів змін та правил могла б налаштувати модель на цьому тексті, але налаштована модель вже буде застарілою до наступного випуску. Вбудовування кожного фрагмента в базу векторів уникає цієї проблеми. Коли клієнт запитує, чи підтримує API пакетні запити, система бере три найбільш релевантні розділи, модель відповідає на основі них та вказує відповідну сторінку. Після змін у документації під час наступного циклу розробки повторне вбудовування оновлює відповіді без необхідності повторної налаштування моделі.
Асистент для написання у стилі статті ідеально підходить для доробки тексту. Медіакомпанія хоче отримувати резюме у точно визначеному стилі: певний ритм речень, відсутність першої особи та певна кількість ключових моментів у верхній частині. Використання запитів дозволяє наблизитися до бажаного результату, але протягом тривалих сеансів виникають відхилення. Навчання на приблизно 2 000 парах резюме, відредагованих людьми, дозволяє моделі надійно створювати текст у відповідності з брендовим стилем, без необхідності вставляти посібник зі стилю в кожен запит.
Відбір кандидатів — це робота агента. Стартап з найму хоче, щоб було можливо перевірити кандидата та домовитися про дзвінок, якщо він відповідає вимогам, а решта відбувається автоматично. Агент читає резюме, порівнює його з вимогами до посади за допомогою внутрішнього API для оцінки, перевіряє календарь керівника відділу найму, пише та надсилає електронний лист із запрошенням та фіксує результат у системі відстеження кандидатів. Одна інструкція охоплює все це, і ніхто не втручається у окремі кроки.
У практиці постійно спостерігається такий розподіл обов’язків. Дизайни, що орієнтовані на отримання даних, відповідають за базові операції, агенти — за координацію, а додаткова налаштування використовуються лише тоді, коли промпти не можуть стабільно контролювати поведінку.
Як вони взаємодіють
Ці три етапи не є взаємовиключними. Найбільш потужні системи поєднують їх у ланцюжок: запит починається в агенті, який планує, проходить через процес пошуку фактів та потім потрапляє до налаштованої моделі, яка сформулює результат.
User Query
↓
Agent (decides what needs to happen — plan the steps)
↓
RAG (retrieves relevant knowledge, if the step needs facts)
↓
LLM (fine-tuned, if tone/format/behavior consistency matters)
↓
Action (respond to user, call a tool, trigger a downstream workflow)
↓
Agent (evaluates result → loop again or stop)
У режимі підтримки все відбувається наступним чином. Надходить повідомлення, і агент класифікує його мету, роблячи висновок, що потрібна інформація про продукт. Система пошуку отримує відповідні фрагменти документації. Налаштована модель складає відповідь у стилі бренду. Потім агент оцінює, чи достатньо рівень впевненості для автоматичної відповіді, чи потрібно, щоб цим зайнявся людина, і нарешті фіксує обмін у CRM.
Якщо видалити будь-яку з цих складових, з’являється прогалина. Система пошуку без агента не може вирішити, коли шукати інформацію, а коли діяти. Агент без системи пошуку не має уявлення про ніщо поза межами своїх даних навчання. Налаштована модель без системи пошуку створює впевнені, гарно сформатовані відповіді, які можуть бути застарілими.
Скільки коштує кожен елемент
Наведені нижче цифри вказують лише приблизні значення, оскільки реальні показники залежать від масштабу та постачальника.
Для отримання інформації початковими витратами є вбудовування корпусу даних — або один раз, або поступово зі зростанням обсягу документів. Постійні витрати становлять хостинг векторної бази даних за певною тарифною схемою та додаткові токени для отриманого контексту за кожен запит. Це найдешевший спосіб отримати бажану користь, тому більшість команд повинні починати саме з цього.
Для тонкої налаштуваності основною початковою витратою часто є дані: збір та міткування якісних прикладів для навчання є дорогим процесом. Далі йдуть витрати на обчислення під час циклів навчання та оцінки. Після цього потрібне повторне навчання, коли необхідно змінити поведінку моделі, а також хостинг індивідуальної моделі, якщо не використовується LoRA на спільній основі. Цей підхід вимагає найбільших початкових інвестицій та найменше толерує помилки, оскільки погані дані для навчання безпосередньо впливають на якість моделі.
Для агентів налаштування включає проектування робочого процесу, інтеграцію інструментів та тестування сценаріїв збоїв. Постійні витрати є прихованою проблемою, адже кожен крок агента — це ще один виклик моделі. Завдання з п’ятьма кроками може коштувати від п’яти до десяти разів більше, ніж один запит на отримання інформації, а цикл без обмеження кількості ітерацій може стати неконтрольованим. Витрати відображають складність завдання, а не лише обсяг його використання.
На практиці отримання інформації зазвичай є найдешевшим способом мінімізувати галюцинації. Доопрацювання моделі окупається лише тоді, коли послідовна поведінка є справжньою вимогою продукту, а не просто додатковою перевагою. Агенти виправдовують вартість за завдання лише тоді, коли робота вимагає кількох рішень та дій, а не тоді, коли достатньо одного обґрунтованого виклику.
Орієнтовні правила для вибору
- Обирайте метод отримання інформації, коли дані часто змінюються. Документи, політики, каталоги, ціни та запаси, які оновлюються щотижня чи щодня, добре підходять для цього методу, але погано — для доробки моделі.
- Обирайте метод доробки моделі, коли поведінка важливіша за знання. Якщо модель знає сферу діяльності, але продовжує використовувати неправильний тон, формат чи шаблон міркувань попри правильні вказівки, проблема полягає у поведінці.
- Обирайте агента, коли завдання вимагає кількох кроків чи дій у реальному світі. Відповідь на запитання не вимагає цього. Однак визначення того, що потрібно зробити, та подальші дії через різні системи, ймовірно, потребують агента.
- Поєднуйте метод отримання інформації та доробку моделі, коли потрібні як достовірні факти, так і послідовний тон, що дуже поширено у продуктах, орієнтованих на клієнтів.
- Поєднуйте метод отримання інформації та агента, коли завдання вимагає як фактів, так і рішень, причому агент вибирає, що шукати та коли діяти на основі цих даних.
Та сама логіка може бути представлена у двох коротких діаграмах потоків. У першій перевіряється, чи залежить відповідь від інформації, яка часто змінюється.
Does the answer depend on information that changes often?
YES → RAG
NO ↓
Друге запитання стосується послідовності поведінки та того, чи включає завдання кілька кроків чи реальні дії.
Does the model need to consistently behave/sound a certain way,
and prompting alone isn't holding that consistency?
YES → Fine-tuning
NO ↓Does the task require multiple steps, tool calls, or real actions
(not just answering a question)?
YES → Agent (likely combined with RAG, and fine-tuning if voice matters)
NO → A single well-prompted LLM call is probably enough
Невеликий проект, який демонструє принцип роботи
Візьмемо внутрішнього асистента з питань HR.
- Почніть з пошуку інформації. Збережіть посібник для співробітників, правила відпусток та документи про соціальні виплати у векторному сховищі. Тоді співробітники зможуть запитати, скільки у них днів хвороби, і отримати обґрунтовану, посиланою на документи відповідь. Це вирішує приблизно 70 відсотків сценаріїв використання та займає кілька днів.
- Додавайте додаткову налаштування лише у разі виникнення проблем. Припустимо, HR хоче, щоб кожна відповідь мала певний емпатичний тон та сувору структуру: «Ось правило, ось що це означає для вас», але формулювання запитань постійно відхиляються від цього. Невелика модель, налаштована на кілька сотень підібраних пар запитань та відповідей у такому стилі, допомагає усунути цю проблему.
Порядок є навмисним. Спочатку виконується отримання даних, оскільки це найдешевше та охоплює найбільшу кількість завдань. Налаштування моделі відбувається лише тоді, коли проявляється реальна різниця у поведінці. Агенти використовуються востаннє, і лише тоді, коли завдання справді потребує багатоетапних дій.
Часті помилки
- Тонке налаштування там, де потрібне отримання інформації. Команди намагаються вбудувати знання у параметри моделі, коли у реальній ситуації відсутній доступ до актуальної інформації. Це призводить до повільнішої роботи, значно вищих витрат та до того, що рішення вже стає застарілим одразу після впровадження.
- Агенти без чітко визначеної процедури роботи. Нечітка мета та необмежені інструменти змушують агента блукати, повторювати дії та поводитися непередбачувано. Вузький спектр інструментів, чіткі умови зупинки та обмеження кількості кроків міркувань допомагають тримати його в рамках, тоді як просте прохання розібратися не може замінити чітко визначений процес.
- Ігнорування затримок та витрат. Кожен крок отримання інформації та кожен крок агента потребують додаткових операцій та коштів. Демонстраційна версія може виглядати чудово, але в реальних умовах для отримання однієї відповіді може знадобитися 12 секунд та шість викликів моделі.
Напрямок розвитку
Індустрія явно рухається у бік агентських робочих процесів, тобто систем, які планують, діють та контролюють результати без постійних підказок. Наступним кроком є гібридний підхід: пошук інформації для отримання відповідей, налаштування для стабілізації поведінки та довготривала пам’ять, щоб агент міг згадувати попередні діалоги замість того, щоб починати кожну сесію з нуля.
Відбувається помітний перехід від чат-ботів до того, що деякі зараз називають штучними інтелектуальними працівниками — системами, які виконують постійну роботу через різні інструменти протягом часу, замість того щоб чекати на запитання. Досягнення цього етапу мало пов’язано з вибором найбільш привабливої технології. Це залежить від розуміння того, що кожна частина робить добре, та їх свідомого об’єднання, починаючи з найпростішого рівня, який вирішує проблему.
Вибір ніколи не полягав у виборі між отриманням даних, їх доробкою чи використанням агентів. Справжнє питання полягає у тому, яка комбінація потрібна певній системі та в якій послідовності її будувати.
Пов’язана література
- Chroma Context-1: 20B-модель-підагент для пошуку, яка робить RAG дешевшим та ефективнішим — як Chroma Context-1 на основі 20B моделей функціонує як підагент, призначений лише для пошуку та відсіву контексту, як він був навчений, що бракує без його використання та в чому полягають його обмеження.
- Практичні нотатки: три рівні Google Cloud RAG – векторний пошук, двигун RAG та відновлення даних агентом — детальний огляд практичних нотаток щодо трьох рівнів Google Cloud RAG: векторного пошуку, двигуна RAG та механізмів відновлення даних агентом, включаючи контракти, перевірки та готові фрагменти коду.