RAG-системи для бізнесу: як зробити AI-агента, який знає вашу документацію

RAG (retrieval-augmented generation) — це найшвидший спосіб дати LLM знання вашої компанії без донавчання моделі. Замість fine-tuning ви будуєте пайплайн: при кожному запиті агент шукає релевантні фрагменти у вашій базі і передає їх у контекст. Звучить просто — але між «працює на демо» і «витримує 10 000 користувачів» дистанція велика.

Архітектура мінімально життєздатної RAG-системи

Базовий контур складається з чотирьох шарів: підготовка даних (chunking, очистка, метадані), векторне сховище, retrieval-логіка з reranker'ом і LLM-обгортка з контролем якості відповіді.

1. 01Парсер документів: PDF, DOCX, HTML, тікети з Jira/Zendesk, повідомлення Slack
2. 02Chunker з overlap 10–15% і збереженням заголовків як метаданих
3. 03Embedding-модель (text-embedding-3-large або open-source bge-m3)
4. 04Векторна БД — Pinecone, Qdrant або pgvector, якщо ви вже на Postgres
5. 05Reranker (Cohere Rerank або bge-reranker-v2) — критичний для якості
6. 06LLM з system-prompt'ом, що забороняє галюцинації поза контекстом

5 помилок, які вбивають проєкт на пілоті

1. Поганий chunking

Розбиття документів за фіксованою довжиною — найгірше рішення для технічної документації. Заголовок розділу опиняється в одному chunk'у, а відповідний код — в іншому. Використовуйте semantic chunking або chunking за структурою документа.

2. Відсутність reranker'а

Embedding-схожість дає top-50 релевантних фрагментів, але саме reranker вибирає ті 5–7, які реально стосуються запиту. Без нього якість відповідей падає на 30–40% — це найдешевше покращення у всьому пайплайні.

3. Ігнорування метаданих

Версія документа, дата оновлення, відділ, мова — без фільтрів за метаданими агент рекомендуватиме застарілі регламенти. Завжди зберігайте «свіжість» і зважуйте її при retrieval.

4. Один великий індекс

Не складайте всю компанію в один індекс. Окремі namespace для HR, юридичних, продуктових і клієнтських даних — це і безпека, і якість.

5. Відсутність evaluations

Без набору з 100–200 еталонних запитів ви не знатимете, чи покращення промпту реально працює. Інвестуйте в evals від першого дня.

RAG — це 80% data engineering і 20% prompt engineering. Команди, які думають навпаки, застрягають на пілотах.

Коли RAG — не ваше рішення

• Якщо знання вашої компанії — у головах людей, а не в документах
• Якщо документи оновлюються щогодини і ви не готові до real-time індексації
• Якщо потрібна нумерована точність (фінансові розрахунки, юридичні висновки) — тут краще structured retrieval з SQL-агентом