RAG і база знань: щоб бот відповідав за вашими даними, а не вигадував

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

RAG що це: пояснення без академізму

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

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

Чому бот без RAG вигадує

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

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

Як влаштована база знань для чат-бота

Під капотом RAG — конвеєр з чотирьох етапів:

1. Підготовка документів. Прайси, FAQ, регламенти, сторінки сайту конвертуються в чистий текст. Сміття на вході — сміття у відповідях, тому це не формальність: биті таблиці й скани без розпізнавання вбивають якість ще до старту.
2. Нарізка (chunking). Документи ріжуться на фрагменти по 200–800 токенів — не механічно по довжині, а за змістом: щоб умова і її виняток не роз'їхалися по різних шматках.
3. Векторизація (embeddings). Кожен фрагмент перетворюється на числовий вектор, який відображає зміст. Близькі за сенсом тексти отримують близькі вектори — саме тому пошук знаходить «скільки коштує доставка», навіть якщо клієнт спитав «а за привезти платити треба?».
4. Пошук і відповідь. Питання клієнта векторизується, система дістає 3–10 найрелевантніших фрагментів (часто з дореранжуванням для точності), і модель формує відповідь строго на їхній основі — з посиланням на джерело.

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

Що покласти в базу знань: чеклист

Практичний мінімум для бота служби підтримки чи продажів:

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

Що класти НЕ треба: застарілі версії документів поруч з чинними (бот не знає, яка правильна — конфлікти версій дають найпідступніші помилки), внутрішні документи з даними, які не можна показувати клієнтам, і «все підряд про всяк випадок» — зайвий обсяг погіршує точність пошуку. Хороший орієнтир обсягу для старту — 30–100 сторінок чинних документів: цього достатньо для 80% питань клієнтів, і такий обсяг реально підтримувати в актуальному стані.

Як перевірити, що бот не вигадує: тести і метрики

«Поклікали — наче відповідає нормально» — не приймання. Робочий процес виглядає так:

• Golden set. 50–100 реальних питань з еталонними відповідями, включно з каверзними: питання поза базою, питання з подвійним змістом, провокації на знижку, якої немає.
• Groundedness. Метрика обґрунтованості: чи кожне твердження відповіді підкріплене фрагментом з бази. Перевіряється автоматично другою моделлю-суддею на всьому golden set після кожної зміни.
• «Не знаю» як правильна відповідь. Бот, який на питання поза базою чесно каже «уточню в менеджера» і передає діалог людині, — це успіх, а не недоробка. Найгірший результат — впевнена відповідь з нізвідки.
• Цитати джерел. У адмінському режимі кожна відповідь показує, з яких фрагментів зібрана. Це прискорює розбір помилок у рази: одразу видно, проблема в пошуку чи в самому документі.

Цільові показники, з якими ми випускаємо ботів у прод: 95%+ groundedness на golden set і нуль впевнених відповідей на питання, відповіді на які в базі немає. Golden set при цьому живе разом з ботом: кожна знайдена в проді помилка перетворюється на новий тестовий кейс, і наступні зміни вже не можуть зламати те, що одного разу полагодили.

Типові помилки впровадження RAG

• Звалити документи в купу і чекати дива. База знань — це продукт зі структурою, власником і циклом оновлення, а не папка з PDF.
• Скани без розпізнавання. PDF-скан прайса для системи — картинка. Без OCR цих даних просто не існує.
• Базу наповнили і забули. Ціни змінилися — бот відповідає за старими. Потрібен процес: хто і як оновлює базу при кожній зміні прайса чи умов. Технічно оновлення — хвилини, організаційно — це найчастіша точка відмови.
• Немає передачі на людину. Навіть ідеальний RAG покриває не все. Шлях «бот → жива людина» з контекстом розмови має бути спроєктований з першого дня.

RAG чи донавчання моделі: що обрати

Часте питання від клієнтів: може, простіше «навчити модель на наших даних»? Для бізнес-ботів відповідь майже завжди — RAG, і ось чому:

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

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

Скільки коштує бот на власних даних

Чат-бот з RAG під ключ — від $1000–2500 разово: підготовка і нарізка документів, налаштування пошуку, промпти, golden set, інтеграція з сайтом чи месенджером. Операційні витрати — $30–150 на місяць залежно від трафіку. Терміни — 3–5 тижнів з тестуванням, з яких добра третина йде на роботу з вашими документами, і це нормально: якість бази визначає якість бота.

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

Хочете оцінити, чи готові ваші документи для бази знань, і скільки коштуватиме бот під вашу задачу? Запишіться на безкоштовний 30-хвилинний AI-аудит — розберемо ваші джерела даних, накидаємо архітектуру і дамо чесну оцінку бюджету: maxicolabs.com/contact.