RAG-системи простою мовою: як навчити AI на ваших документах

Проблема: ChatGPT не знає вашого бізнесу

Ви відкрили ChatGPT і запитали про вашу продукцію, внутрішні процедури або умови договору. У відповідь — загальні слова або вигадані деталі (галюцинації). Це не дивно: модель навчена на публічних даних до певної дати і нічого не знає про вашу компанію.

Перша думка: "Треба навчити AI на наших документах." І тут починається плутанина між двома різними підходами — fine-tuning і RAG. Давайте розберемось раз і назавжди.

Fine-tuning vs RAG: у чому різниця

Fine-tuning (донавчання)

Ви берете базову модель (наприклад, GPT-4 або Llama 3) і додатково навчаєте її на своїх даних. Модель "запам'ятовує" ваші документи в своїх вагах.

Коли підходить: зміна стилю відповідей, навчання специфічному формату виводу, адаптація під галузеву термінологію.

Проблеми для більшості бізнесів:

• Дорого: $1000–50 000+ залежно від розміру моделі і даних

• Повільно: процес займає дні або тижні

• Негнучко: коли документи змінились — треба перенавчати знову

• Галюцинації залишаються: модель "думає що знає" але може плутати деталі

• Складно верифікувати: важко простежити звідки конкретна відповідь

RAG (Retrieval-Augmented Generation)

Модель залишається незмінною. Замість цього: при кожному запиті система знаходить релевантні фрагменти з ваших документів і передає їх моделі як контекст. Модель відповідає спираючись на ці конкретні фрагменти.

Переваги для бізнесу:

• Оновлення бази знань без перенавчання — просто додайте новий документ

• Джерела відповіді перевіряємо — знаємо з якого документа взята інформація

• Значно дешевше у впровадженні

• Менше галюцинацій — модель спирається на реальні документи

• Запускається за тижні, а не місяці

Висновок: для 90% бізнес-завдань (чат-бот підтримки, пошук по документах, асистент для команди) — RAG є кращим вибором ніж fine-tuning.

Як працює RAG: покрокове пояснення

Крок 1: Підготовка документів (Ingestion)

Збираєте всі документи які повинна "знати" система: PDF договори, Word-інструкції, HTML-сторінки, Notion-записи, таблиці Excel, відповіді в Zendesk тощо.

Крок 2: Чанкінг (Chunking)

Документи ріжуться на менші фрагменти — "чанки". Це критично важливий крок що сильно впливає на якість відповідей.

Стратегії чанкінгу:

• Fixed size — фіксована кількість токенів (наприклад 512) з перекриттям (overlap) 50–100 токенів. Простий але "рве" контекст посередині речення.

• Semantic chunking — розбиття за змістовими межами: абзаци, заголовки, параграфи. Краща якість, складніша реалізація.

• Hierarchical chunking — зберігає ієрархію: документ → розділ → параграф. Дозволяє знаходити як загальний контекст так і деталі.

• Sentence window — індексується одне речення, але в контекст передається кілька речень навколо. Баланс між точністю пошуку і повнотою контексту.

Практична порада: починайте з semantic chunking по абзацах, розмір 300–600 токенів, overlap 10–20%. Тестуйте на реальних запитах і коригуйте.

Крок 3: Ембединг (Embedding)

Кожен чанк перетворюється у вектор — числовий масив що представляє смисловий зміст тексту. Семантично схожі тексти мають близькі вектори у векторному просторі.

Моделі для ембедингу:

• OpenAI text-embedding-3-small — $0.02 за 1M токенів, висока якість, підтримує 100+ мов включно з українською

• OpenAI text-embedding-3-large — краща якість, дорожче ($0.13/1M токенів)

• Cohere Embed v3 — конкурентна альтернатива, хороша для багатомовних завдань

• nomic-embed-text — безкоштовна open-source модель, запускається локально

Крок 4: Векторна база даних

Вектори зберігаються у спеціалізованій базі що вміє швидко знаходити найближчі вектори (ANN — Approximate Nearest Neighbor search).

Варіанти для різних потреб:

• pgvector — розширення для PostgreSQL. Безкоштовне, знайомий SQL, підходить для більшості проектів до кількох мільйонів векторів. Якщо вже є PostgreSQL — почніть з нього.

• Chroma — open-source, простий у налаштуванні, ідеальний для прототипу та розробки. Python-перш.

• Pinecone — managed cloud-сервіс, масштабується до мільярдів векторів, serverless план від $0. Найпростіший у production.

• Qdrant — open-source, rust-based, дуже швидкий, можна self-host. Гарний вибір якщо важлива повна контроль над даними.

• Weaviate — open-source з hybrid search (вектор + BM25 keyword). Підходить для складних пошукових завдань.

Крок 5: Пошук (Retrieval)

Запит користувача теж перетворюється у вектор тією самою embedding-моделлю. Система знаходить top-K найближчих векторів у базі (зазвичай 3–10 чанків).

Типи пошуку:

• Semantic search — пошук за змістом через косинусну подібність векторів

• Keyword search (BM25) — класичний повнотекстовий пошук

• Hybrid search — комбінація обох. Краща точність для більшості завдань.

Крок 6: Генерація відповіді

Знайдені чанки + запит користувача передаються до LLM (Claude, GPT-4, Gemini) у вигляді промпту:

Використовуй наступні фрагменти документів для відповіді на запитання.
Якщо відповідь відсутня у наданих документах — повідом про це.

Документи:
[фрагмент 1]
[фрагмент 2]
[фрагмент 3]

Запитання: {user_query}
Відповідь:

Модель відповідає спираючись на ці конкретні фрагменти. Якщо інформації немає — добре налаштований промпт змусить модель сказати "не знаю" замість вигадувати.

Реальний кейс: бот корпоративної бази знань

Завдання: IT-компанія з 25 співробітниками. Нові члени команди постійно ставили одні й ті самі запитання: "Як налаштувати VPN?", "Який процес code review?", "Де шаблон комерційної пропозиції?". HR і тімліди витрачали 2–3 години на день на відповіді.

Що зробили:

• Зібрали 120 документів: Notion-записи, PDF-інструкції, FAQ-документи, Confluence-сторінки

• Чанкінг: semantic за заголовками H1/H2, середній розмір 400 токенів

• Ембединг: OpenAI text-embedding-3-small (~$2 на весь датасет)

• Векторна БД: pgvector на існуючому PostgreSQL сервері

• LLM: Claude 3.5 Sonnet через API (баланс якість/ціна)

• Інтерфейс: Slack бот + веб-інтерфейс на Streamlit

Результати через 2 місяці:

• 78% запитань нових співробітників обробляє бот без участі людини

• Середній час відповіді: 3 секунди проти 20–40 хвилин раніше

• Вартість API за місяць: $45–80 залежно від активності

• Час впровадження: 2 тижні (1 розробник, part-time)

Точність і обмеження RAG

Як покращити точність:

• Якість документів — garbage in, garbage out. Структуровані документи з чіткими заголовками дають кращі результати.

• Reranking — після першого пошуку застосовуйте cross-encoder модель (Cohere Rerank, BGE-reranker) для переоцінки релевантності знайдених чанків

• Query expansion — перефразуйте запит кількома варіантами і шукайте за кожним

• Metadata filtering — фільтруйте за датою, типом документа, відділом перед векторним пошуком

• Eval framework — систематично оцінюйте якість через RAGAS або інший фреймворк

Обмеження RAG:

• Контекстне вікно — є ліміт на кількість чанків що можна передати в один запит

• Числові таблиці — складні Excel-таблиці важко обробляти без спеціальної підготовки

• Мультимодальність — зображення і графіки в PDF потребують OCR або vision-моделей

• Актуальність — потрібен процес оновлення бази при зміні документів

• Конфіденційність — якщо дані не можна відправляти в cloud — потрібні local LLM (Ollama + Llama 3)

Вартість RAG-системи

Типова RAG-система для команди 20–50 людей: $50–150/місяць операційних витрат + одноразова розробка.

Висновок

RAG — найпрактичніший спосіб зробити AI корисним для вашого конкретного бізнесу без мільйонних бюджетів на fine-tuning. Якщо у вас є документи, інструкції, FAQ або будь-яка структурована база знань — RAG може перетворити їх на розумного асистента за 2–4 тижні розробки.

Готові спробувати? Розкажіть нам про ваш use case — оцінимо складність і запропонуємо архітектуру рішення.