AI-агенти з RAG для бази знань 2026: гайд із впровадження

AI-агент з RAG — це бот, який перед відповіддю шукає факти у вашій базі знань і відповідає лише за ними, без вигадування. Впровадження у 2026: 2–6 тижнів, вартість 200–800 тис. ₴, окупність на підтримці від 500 звернень/міс — 3–6 місяців. Стек: Claude або GPT-4 для генерації, векторна БД (Qdrant, Pinecone, pgvector), ембединги від OpenAI або Voyage, оркестрація через LangChain або LlamaIndex. Джерела: 100–10 000 документів (PDF, DOCX, вебсторінки, Confluence, Notion). Точність відповідей на закритому домені — 85–95% проти 40–60% у «голої» LLM. Типові задачі: підтримка першої лінії, внутрішній пошук за регламентами, онбординг співробітників, асистент менеджера з продажів. Де RAG не працює: задачі з розрахунками, багатокрокова логіка, актуальні курси й ціни без інтеграції з API. У статті — архітектура, чек-лист впровадження і 6 помилок.

Що таке RAG і навіщо

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

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

• Не знає про ваш продукт. ChatGPT не читав вашу документацію, не знає специфіки, вигадає «правдоподібне», але неточне.
• Cut-off дата. Навіть Claude чи GPT-4 навчені на даних до певної дати. Зміни в продукті після неї – невідомі.
• Немає посилань на джерела. Користувач не може перевірити, звідки відповідь – довіри менше.
• Дорого передавати все в контекст. Контекстне вікно 200K токенів – але 1000 PDF не влізе, і вартість кожного запиту буде величезною.

RAG розв'язує всі чотири проблеми. Перед відповіддю система шукає 3-7 найрелевантніших фрагментів у вашій базі і передає їх LLM як контекст. LLM формує відповідь на основі саме цих фрагментів, із цитуванням джерел.

5 типових застосувань

1. Підтримка за продуктовою документацією

Клієнт ставить запитання в чаті на сайті або в Telegram-боті. RAG шукає відповідь у документації, FAQ, раніше розв'язаних тікетах. Закриває 60-80% типових запитань без людини. Складні випадки передає оператору зі зібраною довідкою.

2. Внутрішній пошук за корпоративним wiki

Новий співробітник не пам'ятає «як у нас оформлюється відрядження» чи «де регламент роботи з клієнтами». Запитує в RAG-агента. Той знаходить у Notion/Confluence/Google Docs потрібний документ, цитує частину, дає посилання на повний.

3. Sales-помічник за продуктами

Менеджер на зустрічі з клієнтом. Клієнт ставить складне технічне запитання. Менеджер відкриває RAG-чат, запитує, отримує відповідь із посиланнями на технічні специфікації, договори, кейси. Швидкість відповіді клієнту – ×3-5.

4. Аналіз юридичних документів

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

5. Освітній асистент

Студент онлайн-курсу ставить запитання. RAG шукає відповідь у матеріалах курсу, презентаціях, розшифровках лекцій. Знімає 70% типових запитань із тьютора, підвищує completion rate курсу.

Це не повний список. Реально RAG застосовний усюди, де є велика база напівструктурованого тексту і регулярні запитання за нею.

Компоненти RAG-системи

RAG – не «один сервіс», а pipeline із 6-7 компонентів. Кожен треба підібрати під задачу.

• Джерело даних – PDF, вебсторінки, Notion, Confluence, Google Docs, SharePoint, CSV/Excel, бази даних. Від джерела залежить, як видобувати текст.
• Парсер і чанкер – розбиває документи на фрагменти 300-800 токенів. Від розміру чанка сильно залежить якість пошуку.
• Embeddings-модель – конвертує текст у вектори. OpenAI text-embedding-3-small (універсальний), Voyage-large (точніше на коді), Cohere embed-multilingual (мультимовні).
• Vector database – зберігає вектори і швидко знаходить «схожі». Pinecone, Qdrant, Weaviate, pgvector у Postgres.
• Retrieval-логіка – шукає top-K фрагментів, опційно re-ranking (Cohere Rerank, Voyage Rerank) для підвищення точності.
• LLM – формує фінальну відповідь на основі знайдених фрагментів. Claude Sonnet (довгі контексти), GPT-4 (універсальний), Mistral/Llama (локальні).
• Prompt-шаблон – інструкція моделі: «відповідай лише на основі документів нижче, обов'язково цитуй джерела, якщо не знаєш – скажи прямо».
• UI або API – чат на сайті, Telegram-бот, віджет у Notion, або REST API для інтеграції у свій продукт.

Запуск за 2-4 тижні

Реалістичний графік запуску базового RAG-агента з нуля:

1. Данідн 1-3
2. Чанкінгдн 4-6
3. Embeddingsдн 7-10
4. Retrievalдн 11-16
5. UI+тестидн 17-21

Дні 1-3 – дані. Збираємо всі джерела: що хочемо, щоб агент знав. Чистимо: прибираємо застаріле, дублікати, сміттєві документи. На цьому етапі зазвичай з'ясовується, що «нашу документацію востаннє оновлювали 3 роки тому» – частина роботи на боці клієнта.

Дні 4-6 – чанкінг. Парсимо документи, розбиваємо на фрагменти. Тут багато нюансів: PDF із таблицями вимагає особливої обробки, code blocks не можна різати посередині, заголовки треба зберігати з контекстом. Не «один універсальний чанкер на все», а адаптований.

Дні 7-10 – embeddings. Підключаємо OpenAI або Voyage API, проганяємо всі чанки через embeddings-модель. Зберігаємо у vector-DB. Для українсько-англійського контенту беру multilingual моделі; для суто англійського – text-embedding-3-small достатньо.

Дні 11-16 – retrieval. Налаштовуємо пошук: top-K (зазвичай 5-10), threshold за схожістю, опційно re-ranking. Тестуємо на 20-30 типових запитаннях: чи повертаються релевантні фрагменти? Якщо ні – тюнимо: змінюємо розмір чанка, embeddings, prompt.

Дні 17-21 – UI і тести. Робимо інтерфейс: чат на сайті через iframe, Telegram-бот, віджет у Notion, або REST API. Підключаємо моніторинг: логи запитів, оцінки користувачів (👍/👎), метрики точності. Фінальне тестування з реальними користувачами.

Порівняння vector-баз

Від вибору vector-DB залежить вартість, швидкість, зручність масштабування. Три популярні варіанти:

Мої рекомендації:

• Прототип / MVP – Pinecone free tier або Qdrant локально. Швидкий старт, не треба думати про інфраструктуру.
• Production до 1M векторів – Qdrant self-hosted на VPS ($10-30 на місяць) або Pinecone starter ($70 на місяць).
• Уже є Postgres – pgvector, жодної нової інфраструктури, зручність для команди.
• Enterprise з 10M+ векторів – Pinecone enterprise або Qdrant Cloud з replicas.

7 типових помилок

За 2 роки активної роботи з RAG-системами – ось рекордсмени за проблемами.

1. Завантажувати все підряд. Сміття на вхід = сміття на вихід. 80% часу йде на підготовку даних: чистка, нормалізація, видалення застарілого. Це не «технічна дрібниця», а половина успіху.
2. Завеликі чанки. Якщо чанк – ціла сторінка, модель знаходить «цю сторінку» замість «конкретного абзацу». Точність падає. Оптимально – 300-800 токенів з overlap 50-100.
3. Замалі чанки. Якщо чанк – 1 речення, втрачається контекст: «він» незрозуміло про що. Надто короткі – теж погано.
4. Одна embedding-модель для всіх мов. Якщо у вас українсько-англійський контент – потрібні multilingual embeddings (Cohere multilingual, OpenAI text-embedding-3-large). Інакше крос-мовний пошук не працює.
5. Немає re-ranking. Top-K із vector-search часто містить «схожі, але не точні». Re-ranking модель пересортовує результати за релевантністю до запиту – підвищення точності на 15-30%.
6. Ігнорувати citation. Відповідь без посилань на джерела = недовіра. Промпт має явно вимагати цитування: «наводь джерело у квадратних дужках після кожного факту». Користувач бачить посилання → клікає → перевіряє → довіряє.
7. Не оновлювати базу. Через 3-6 місяців документація застаріває, відповіді стають хибними. Потрібен процес регулярного re-indexing: автоматичний при зміні в Notion/Confluence або за cron раз на тиждень.

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