Коли GPT-4o або Claude дають впевнену, але хибну відповідь про ваш внутрішній продукт — це не баг моделі. Це архітектурна проблема: модель не знає того, чого не було в тренувальних даних. RAG (Retrieval-Augmented Generation) — перевірений спосіб дати LLM доступ до актуальних приватних знань без дорогого fine-tuning.
Ідея проста: замість того щоб «вшивати» знання у ваги моделі, ви зберігаєте їх окремо у векторній базі й динамічно підтягуєте релевантні фрагменти прямо в контекст запиту. Модель бачить і запит користувача, і відповідні документи — і генерує відповідь на основі реальних, верифікованих даних.
Але між «ідея проста» та «система в продакшні» — значна відстань. Нижче — конкретний робочий процес, який реально працює.
Що таке RAG і яку проблему він вирішує
LLM мають два фундаментальні обмеження: знання зафіксовані на дату тренування, а контекстне вікно скінченне. RAG обходить обидва: він підтягує лише ті фрагменти, що релевантні поточному запиту, і кладе їх у контекст «на льоту».
Порівняно з fine-tuning, RAG має очевидні переваги:
- Дані можна оновлювати незалежно від моделі — без повторного тренування
- Вартість на порядок нижча: embeddings дешевші за GPU-годину fine-tuning
- Джерела відповіді можна трасувати та верифікувати — кожна відповідь посилається на конкретний фрагмент
- Система працює з будь-якою базою моделей: GPT-4o, Claude, Llama, Mistral, Qwen
П'ять компонентів RAG-пайплайну
Будь-яка RAG-система складається з п'яти ключових блоків.
1. Завантаження та нормалізація (Ingestion). Беремо сирі дані: PDF, Notion-сторінки, Confluence, Slack-треди, markdown-файли. Очищаємо, стандартизуємо формат, видаляємо шум — повторювані заголовки, навігаційні блоки, підвали. Якість на цьому кроці визначає якість усього пайплайну.
2. Чанкінг (Chunking). Документи нарізаємо на фрагменти. Класичний підхід — фіксований розмір із перекриттям (наприклад, 512 токенів, overlap 128). Кращий підхід — семантичний чанкінг: межі між фрагментами проходять по логічних блоках тексту, а не по байтах. Розмір чанку безпосередньо впливає на точність ретрівалу: занадто малий — губиться контекст, занадто великий — шум перекриває сигнал.
3. Векторизація (Embedding). Кожен фрагмент перетворюється на числовий вектор embedding-моделлю. Популярні варіанти: text-embedding-3-small від OpenAI, embed-multilingual-v3 від Cohere, або локальні моделі через Ollama. Вектори зберігаються у векторній базі — Pinecone, Weaviate, Qdrant або pgvector.
4. Ретрівал (Retrieval). На запит користувача виконується той самий embedding, потім семантичний пошук у базі: k найближчих векторів за косинусною схожістю. Зазвичай k від 3 до 10 фрагментів. Гібридний ретрівал (BM25 + семантика) дає кращі результати для точних термінів і власних назв — варто розглянути як дефолт.
5. Генерація (Generation). Знайдені фрагменти разом з оригінальним запитом упаковуються в system/user prompt і надсилаються до LLM. Модель генерує відповідь, спираючись виключно на наданий контекст. Явна інструкція «відповідай лише на основі контексту» суттєво знижує галюцинації.
Практичний пайплайн: від файлів до продакшну
Ось мінімальний стек для реального проекту:
- LangChain або LlamaIndex — оркестрація всього пайплайну
- Qdrant або pgvector — векторне сховище
- OpenAI або Mistral — embedding і генерація
- n8n або Python-скрипт — автоматичне перезавантаження індексу при зміні даних
Кроки запуску:
- Напишіть ingestion-скрипт: читає джерела, очищає, нарізає, векторизує, зберігає у Qdrant
- Налаштуйте scheduler — cron або n8n — для регулярного оновлення індексу
- Реалізуйте retriever: embedding запиту → top-k пошук → повернення фрагментів
- Зберіть prompt-шаблон із явним інструктажем спиратись виключно на контекст
- Увімкніть логування з першого дня: запит, знайдені фрагменти, відповідь, latency
Критична деталь: логуйте весь пайплайн із першого дня. Без трасування ви не зможете зрозуміти, чому система відповіла неправильно — через поганий чанкінг, незадовільний ретрівал чи слабкий prompt. Дебагінг RAG без логів — це гадання.
Висновок AiiN
RAG — це не срібна куля, але наразі це найпрактичніший спосіб дати LLM доступ до ваших власних даних. Ключ до успіху — якість даних на вході, правильний чанкінг і постійний моніторинг ретрівалу.
Якщо RAG дає погані відповіді, перевіряйте в першу чергу не модель, а те, що вона «бачить»: які саме фрагменти потрапляють у контекст. У більшості випадків проблема саме там — не в інтелекті моделі, а в якості поданих їй даних.
Для складніших сценаріїв — мультикрокового reasoning, перехресних посилань між документами, динамічного планування пошуку — варто дивитися в бік Agentic RAG: коли LLM сам вирішує, скільки разів і як шукати. Але це вже тема для окремого матеріалу.