Головна претензія до AI звучить так: «він упевнено вигадує». І це справедливо — мовна модель сама по собі не знає ні вашого прайсу, ні умов доставки, ні того, що позицію зняли з виробництва торік. Технологія, яка це виправляє, називається RAG, і саме вона перетворює загальну модель на агента, який знає вашу компанію. У SUDUS·TEAM ми будуємо RAG-системи в кожному проекті розробки AI-агентів, тож пояснимо без академічності.
Ця стаття — про те, як AI-агент вчиться на документах вашої компанії: що таке RAG, чому він працює краще за донавчання моделі, як виглядає підготовка бази знань з боку клієнта і які помилки роблять найчастіше.
Що таке RAG простими словами
RAG розшифровується як Retrieval-Augmented Generation — «генерація, доповнена пошуком». Ідея проста: перш ніж відповідати, агент іде й читає ваші документи.
Порівняння, яке пояснює все. Уявіть нового співробітника з чудовою освітою, який щойно вийшов на роботу. Він розумний, грамотно говорить, але нічого не знає про вашу компанію. Є два шляхи:
- Змусити його вивчити напам'ять усі внутрішні документи — довго, дорого, і при кожній зміні прайсу треба вчити заново. Це аналог fine-tuning, донавчання моделі.
- Дати доступ до корпоративної бази і навчити швидко в ній шукати — миттєво, дешево, а оновлення прайсу підхоплюється автоматично. Це RAG.
У 95% бізнес-задач правильна відповідь — другий варіант.
Як це працює всередині
Крок 1. Розбиття документів на фрагменти
Ваші документи ріжуться на шматки по кількасот слів — їх називають чанками. Різати треба розумно: не посеред речення й не посеред таблиці, а по смислових межах — розділах, пунктах, питаннях FAQ. Від якості цього кроку залежить половина результату.
Крок 2. Перетворення на вектори
Кожен фрагмент проганяється через окрему модель-ембеддер, яка перетворює текст на довгий список чисел — вектор. Ключова властивість: тексти з близьким змістом отримують близькі вектори, навіть якщо в них немає жодного спільного слова. Тому запит «скільки чекати посилку» знайде фрагмент про «терміни доставки».
Крок 3. Зберігання у векторній базі
Вектори складаються у спеціальну базу даних, оптимізовану під пошук за схожістю. Саме вона дозволяє знайти потрібні три фрагменти серед п'яти тисяч за десяті частки секунди.
Крок 4. Пошук під час діалогу
Клієнт пише питання. Питання так само перетворюється на вектор, база повертає найближчі фрагменти. Хороші системи використовують гібридний пошук — семантичний плюс класичний за ключовими словами, бо артикули, номери моделей і назви документів краще шукаються буквально.
Крок 5. Формування відповіді
Знайдені фрагменти підставляються в контекст разом із питанням і системною інструкцією виду «відповідай лише на основі наведених матеріалів, якщо відповіді немає — так і скажи». Модель формулює відповідь. Саме ця інструкція і є головним запобіжником проти вигадок.
Чому RAG кращий за донавчання моделі
- Оновлення за хвилини, а не за тижні. Змінився прайс — замінили один документ у базі. Fine-tuning вимагав би повного циклу перенавчання.
- Дешевше на порядок. Індексація бази знань коштує тисячі гривень, донавчання моделі — десятки й сотні тисяч.
- Можна показати джерело. Агент здатний послатися на конкретний документ і пункт. Донавчена модель просто «знає» і не може пояснити звідки.
- Менше вигадок. Модель відповідає з наданого тексту, а не з пам'яті про мільярди прочитаних сторінок.
- Легко розмежувати доступ. Різні відділи бачать різні частини бази — на рівні пошуку це елементарно, на рівні донавченої моделі майже неможливо.
Fine-tuning лишається корисним, але для іншого: навчити модель специфічному стилю, тону або формату відповіді. Знання фактів — задача RAG.
Що треба від вас: підготовка бази знань
Це та частина, де проекти найчастіше буксують. Розробник не знає ваш бізнес, тому зібрати правильні матеріали може лише ваша команда.
Що входить у базу знань
- Прайси й тарифи з датою актуальності
- Опис послуг і товарів, технічні характеристики
- Умови доставки, оплати, повернення, гарантії
- Внутрішні регламенти й інструкції для співробітників
- Історія типових звернень із правильними відповідями
- Шаблони документів і договорів
- Питання й відповіді, які вже накопичились у підтримці
Три вимоги, які економлять тижні
- Один факт — одне джерело. Якщо ціна вказана в трьох файлах по-різному, агент видаватиме випадкову з трьох. Суперечності треба прибрати до індексації, а не після скарг клієнтів.
- Текст, а не картинки. Прайс, зісканований у PDF як зображення, треба спершу розпізнати. Це робиться, але це окремий етап і окремий час.
- Актуальність із датою. Кожен документ має мати позначку, коли він востаннє переглядався. Інакше через рік ніхто не згадає, чи діє ще та акція.
За нашим досвідом, розчищення бази знань займає у клієнта 10–40 годин. Це реальна робота, і краще закласти її в план від початку — саме на цьому етапі найчастіше зсуваються терміни всього проекту. Як виглядає повний графік впровадження, ми описали в розділі процесу роботи над AI-агентами.
Як це виглядає на конкретному прикладі
Абстракції погано запам'ятовуються, тому візьмімо реальний тип документа — прайс сервісного центру — і подивімось, що з ним відбувається.
Було: один файл на 40 сторінок
Прайс містить розділи по типах пристроїв, у кожному — таблиця з послугами, цінами й термінами, а внизу дрібним шрифтом умови гарантії, які стосуються всього документа.
Наївне розбиття, яке не працює
Якщо порізати файл механічно по 1 000 слів, вийде так: один фрагмент обривається посеред таблиці, гарантійні умови потрапляють в окремий шматок без прив'язки до послуг, а назва розділу «Ремонт ноутбуків» залишається у попередньому фрагменті. На питання «скільки коштує заміна матриці й яка гарантія» агент знайде ціну без гарантії або гарантію без ціни.
Правильне розбиття
Ріжемо по смислових межах — один фрагмент на одну послугу — і до кожного дописуємо контекст, який у вихідному файлі був неявним:
- Заголовок розділу дублюється в кожен фрагмент: «Ремонт ноутбуків → Заміна матриці».
- Спільні умови (гарантія, терміни, чи входить діагностика) додаються до кожного фрагмента, а не лежать окремо.
- Синоніми клієнтською мовою дописуються поруч із технічною назвою: «матриця, екран, дисплей, розбитий екран».
- Дата актуальності ставиться в сам текст фрагмента, щоб агент міг сказати «станом на червень».
Той самий документ, та сама модель — але тепер на питання про матрицю приходить один точний фрагмент замість трьох приблизних. Саме ця робота і є основною частиною налаштування RAG, і саме її найчастіше пропускають.
Гібридний пошук: чому одного семантичного мало
Семантичний пошук чудово розуміє зміст, але має сліпу зону — точні позначення. Три приклади, на яких він провалюється:
- Артикули й моделі. Запит «є NP-BX1?» семантично ні на що не схожий. Вектор такого рядка майже випадковий.
- Посилання на пункти. «Що каже пункт 4.2» — потрібен буквальний збіг, а не схожість за змістом.
- Рідкісні власні назви. Назва вашого тарифу чи внутрішньої програми модель бачить уперше.
Тому в бойових системах пошук завжди подвійний: класичний за словами плюс семантичний, а результати обох потім зводяться в один список і переоцінюються. Коштує це копійки, а різницю у якості видно одразу на технічних каталогах і договорах.
Розмежування доступу: хто що бачить
Питання, яке виникає, щойно агента пробують застосувати всередині компанії. Відповідь у RAG елегантна: доступ фільтрується на етапі пошуку, ще до того, як модель щось побачила.
Кожен фрагмент у базі має мітки — відділ, рівень доступу, тип документа. Коли співробітник ставить питання, пошук іде лише по тих фрагментах, які йому дозволені. Менеджер із продажів фізично не може отримати відповідь із кадрових документів: вони просто не потрапляють у вибірку.
Для клієнтських агентів працює той самий механізм — назовні відкривається лише публічна частина бази, а внутрішні регламенти й собівартість залишаються невидимими. Це набагато надійніше, ніж просити модель «не розповідати зайвого» в промпті.
П'ять помилок, через які RAG працює погано
1. Занадто великі фрагменти
Ріжуть документи по 2 000 слів, «щоб контексту було більше». Результат: у знайденому фрагменті потрібна одна фраза й 1 950 слів шуму, модель губиться, а ви платите за всі токени. Оптимум зазвичай 200–500 слів із невеликим перекриттям між сусідніми фрагментами.
2. Тільки семантичний пошук
Без класичного пошуку за словами агент не знайде товар за артикулом і не зрозуміє запит «пункт 4.2 договору». Гібридний пошук обов'язковий скрізь, де є коди, номери й назви.
3. Немає reranking
Векторний пошук повертає десять кандидатів, серед яких релевантні три. Якщо віддати моделі всі десять, якість падає. Окремий етап переоцінки, який залишає найкращі три, помітно покращує відповіді за копійки.
4. Немає відповіді «не знаю»
Якщо в інструкції не прописано, що робити за відсутності інформації, модель почне добудовувати правдоподібне. Явна вказівка визнавати незнання і пропонувати з'єднати з менеджером — обов'язковий елемент.
5. Базу проіндексували один раз
Через півроку прайс змінився тричі, а в базі лежить перша версія. Індексація має бути процесом, а не подією: або автоматичне оновлення з вашої системи, або регламент із відповідальною людиною.
Як зрозуміти, що RAG налаштований добре
Три метрики, які варто питати у підрядника й дивитись самому:
- Точність відповідей на контрольному наборі. Береться 50–100 реальних питань з відомими правильними відповідями, і рахується частка влучань. Нижче 85% — систему рано випускати до клієнтів.
- Частка «не знаю» замість вигадки. Спеціально ставляться питання, відповіді на які в базі немає. Агент має чесно зізнатися у всіх випадках.
- Середня кількість токенів на відповідь. Прямо переводиться в гроші. Якщо на просте питання йде 40 000 вхідних токенів — база порізана неправильно.
Часті питання
Скільки документів потрібно для RAG?
Працює навіть на десяти сторінках якісного тексту. У стартовий пакет розробки входить база до 100 сторінок, у розширений — до 5 000. Важливіша не кількість, а несуперечливість: 30 вивірених сторінок дають кращий результат, ніж 500 з дублями й застарілими даними.
Чи потрапляють наші документи в навчання моделі?
Ні. При RAG документи лежать у вашій векторній базі й передаються моделі лише як контекст конкретного запиту. Провідні комерційні провайдери не використовують дані бізнес-клієнтів для тренування. Для найчутливіших даних розгортаємо локальну модель на вашій інфраструктурі — назовні не йде нічого.
Чи може агент помилитися навіть із RAG?
Може, але помилки стають іншого типу: не вигадка, а неправильно знайдений фрагмент. Це діагностується по логах і виправляється налаштуванням пошуку — на відміну від вигадок «з голови», які виправити майже неможливо.
Як часто треба оновлювати базу знань?
За фактом змін. Прайс і акції — одразу; регламенти й описи послуг — раз на квартал з ревізією. Для систем, підключених до CRM або облікової системи, частину даних агент бере наживо і оновлювати вручну не треба взагалі.
Чи можна підключити RAG до наявного чат-бота?
Так, якщо є доступ до коду. Це поширений сценарій: сценарна частина залишається, а вільні питання йдуть в AI-шар. Порівняння підходів — у статті AI-агент чи Telegram-бот.
Підсумок
RAG — це не екзотика, а стандартний спосіб зробити так, щоб AI-агент говорив фактами вашої компанії, а не загальними словами з інтернету. Технічна частина давно відпрацьована; вирішальним фактором майже завжди виявляється якість ваших документів.
Тому найкорисніше, що можна зробити ще до старту проекту — зібрати в одному місці актуальний прайс, умови роботи й топ-50 питань клієнтів із правильними відповідями. З цим матеріалом перший робочий агент з'являється за два тижні. Хочете обговорити свій випадок — напишіть нам.