Чому два AI-асистенти з однаковими документами дають абсолютно різну якість відповідей? Відповідь — в архітектурі. Спойлер: якість визначається не моделлю, а п'ятьма етапами обробки до того як LLM побачить ваше питання.
⚡ Коротко
- 🔬 RAG — це не "завантажити PDF і запитати ChatGPT". Це п'ятиетапний конвеєр де кожен крок впливає на точність
- 📄 Chunking — розмір і спосіб нарізки документів: неправильний розмір = втрачений контекст або нерелевантні відповіді
- 🔢 Embedding — перетворення тексту на числа де схожий сенс = схожі числа
- 🔍 Гібридний пошук — BM25 + vector одночасно: точність по ключових словах + розуміння сенсу
- ⚖️ RRF — алгоритм злиття результатів двох пошуків в один ранжований список
- 🤖 LLM — генерує відповідь тільки на основі знайдених фрагментів, не вигадує
- ⚙️ Всі параметри — chunk size, top-k, similarity threshold, модель — налаштовуються індивідуально під кожного клієнта
📚 Зміст
- Що таке RAG — технічне визначення
- Етап 1: парсинг і chunking документів
- Етап 2: embedding і векторизація
- Етап 3: vector search і BM25
- Етап 4: reranking і RRF
- Етап 5: генерація відповіді через LLM
- Де можуть бути помилки в кожному етапі
- Часті питання
- Хочете побачити архітектуру в дії?
⸻
Що таке RAG — технічне визначення
RAG (Retrieval-Augmented Generation) — архітектура де AI спочатку знаходить релевантні фрагменти з ваших документів, а потім генерує відповідь виключно на їхній основі. Не вигадує — цитує.
Уявіть різницю між двома студентами на іспиті. Перший — ChatGPT без документів: відповідає з пам'яті, впевнено, але може помилитись або вигадати деталь. Другий — RAG-система: отримує дозвіл принести шпаргалку (ваші документи), відкриває потрібну сторінку і відповідає строго по тексту. Другий студент не розумніший — але значно точніший там де важлива конкретика.
За даними Next Move Strategy Consulting, ринок RAG досяг $3.33 млрд у 2026 і зростатиме до $81.5 млрд до 2035. За даними Techment, понад 70% enterprise GenAI-ініціатив у 2026 вимагають structured retrieval pipeline для запобігання галюцинаціям — саме тому RAG став стандартом, а не опцією.
AskYourDocs побудований на RAG-архітектурі з п'ятьма послідовними етапами. Розберемо кожен.
⸻
Етап 1: парсинг і chunking документів
Перш ніж AI зможе відповідати на питання — документи потрібно прочитати, очистити і нарізати на керовані фрагменти (chunks). Саме від розміру і якості цих фрагментів залежить точність всього що буде далі.
Парсинг: що відбувається з вашим PDF перш ніж AI його побачить
Коли ви завантажуєте документ у AskYourDocs — система спочатку витягує
чистий текст. PDF може містити таблиці, зображення, колонтитули, нумерацію сторінок —
все це потрібно відокремити від корисного контенту. Для HTML-документів
система витягує основний зміст з тегів <main> і <article>,
автоматично прибираючи навігацію, рекламу і футер.
FAQ-документи розпізнаються окремо: вони розбиваються по парах
питання/відповідь, а не по довільних вікнах токенів — це зберігає логічну цілісність.
Chunking: чому розмір фрагмента критично важливий
Після парсингу документ нарізається на фрагменти — chunks. Аналогія: уявіть що ви вирізаєте статтю з газети. Якщо вирізати по одному реченню — втрачається контекст. Якщо вирізати цілу сторінку — при пошуку буде забагато зайвого. Оптимальний розмір — абзац або логічний блок.
В AskYourDocs розмір chunk налаштовується параметром CHUNK_SIZE (за замовчуванням 1000 символів) і підбирається індивідуально під кожного клієнта:
| Тип контенту | Оптимальний CHUNK_SIZE | Чому |
|---|---|---|
| Юридичні договори | 500–700 | Кожен пункт — окрема норма, не можна змішувати |
| Медичні протоколи | 1000–1500 | Процедура потребує повного контексту підготовки |
| FAQ документи | Пара Q/A | Семантична розбивка по парах питання/відповідь |
| Технічні специфікації | 800–1000 | Характеристики продукту — один блок |
| HR-документи | 600–800 | Правило або процедура — окрема одиниця |
Дослідження NVIDIA підтверджує: для точних фактологічних запитів оптимальні chunk розміром 256–512 токенів, для аналітичних запитів що вимагають ширшого контексту — 1024 токени і більше. Різниця між правильною і неправильною стратегією chunking — до 40% точності retrieval.
Помилка яку роблять більшість "коробкових" рішень — один розмір chunk для всіх клієнтів. У AskYourDocs CHUNK_SIZE — це перший параметр який ми обговорюємо при онбордингу.
Підсумок етапу 1: якість chunking — фундамент всієї системи. Неправильний розмір фрагмента не виправить жодна LLM.
⸻
Етап 2: embedding і векторизація
Кожен chunk перетворюється на список чисел — вектор. Числа кодують сенс тексту так, що схожі за змістом фрагменти отримують схожі числа. Саме це дозволяє знаходити відповідь навіть якщо клієнт формулює питання інакше ніж написано в документі.
Після chunking кожен фрагмент "перекладається" на математичну мову — вектор
з 1536 чисел (при використанні text-embedding-3-small від OpenAI).
Це не просто кодування слів — це кодування сенсу.
Проста аналогія: уявіть карту міста де кожне поняття — точка у просторі. "Договір оренди" і "угода про найм" стоять майже поруч на цій карті. "Договір оренди" і "рецепт борщу" — на протилежних кінцях. Коли клієнт задає питання — воно теж перетворюється на точку на цій карті, і система шукає найближчі до неї документи.
Детальне пояснення як embedding-моделі кодують сенс тексту, що таке cosine similarity і чому розмірність вектора важлива — Embeddings простими словами →
Яку модель використовує AskYourDocs
AskYourDocs підтримує два режими роботи з embeddings — залежно від вимог клієнта:
| Параметр | Продакшен (OpenRouter API) | Закритий периметр (Ollama) |
|---|---|---|
| Модель | text-embedding-3-small | nomic-embed-text |
| Розмірність | 1536 вимірів | 768 вимірів |
| Де виконується | Сервери OpenAI через OpenRouter | Ваш сервер, нікуди не виходить |
| GDPR | ⚠️ Текст chunks передається назовні для векторизації | ✅ Повний закритий контур |
| Якість пошуку | ✅ Вища — більше вимірів = тонші семантичні відмінності | ⚠️ Дещо нижча на складних запитах |
| Вартість | $0.02 / 1M токенів (разова при індексації) | $0 — локальні обчислення |
| Швидкість індексації | ⚠️ Залежить від швидкості API + rate limits | ✅ Залежить тільки від вашого заліза |
| Мови | UK, EN, DE, ES — висока якість | UK, EN, DE, ES — хороша якість |
В чому різниця між 1536 і 768 вимірами на практиці
Розмірність — це кількість числових координат у векторі. Чим більше вимірів, тим більше нюансів сенсу модель може закодувати.
1536 вимірів (text-embedding-3-small) краще розрізняє тонкі семантичні відмінності: наприклад, "дострокове розірвання договору" і "закінчення терміну дії контракту" — для 768-вимірної моделі це схожі поняття, для 1536-вимірної — різні. Це критично для юридичних і медичних документів де деталі мають значення.
768 вимірів (nomic-embed-text) займає вдвічі менше місця в базі, швидше індексується і не потребує зовнішніх API-викликів. Для більшості бізнес-кейсів — FAQ, каталоги, HR-документи — різниця в якості пошуку мінімальна і непомітна кінцевому користувачу.
Мінуси кожного підходу
- ⚠️ 1536 (OpenRouter): текст ваших документів проходить через API OpenAI при індексації. Для GDPR-чутливих даних — юридичні справи, медичні записи, фінансові документи — це потребує окремого Data Processing Agreement з провайдером. Детальніше: GDPR та AI на документах →
- ⚠️ 768 (Ollama): якість трохи нижча на складних семантичних запитах. Також потребує достатнього RAM на сервері клієнта (мінімум 4–8 GB для nomic-embed-text).
Важливо: при зміні embedding-моделі необхідна повна переіндексація бази — вектори від різних моделей несумісні між собою. Саме тому вибір моделі фіксується на етапі онбордингу і змінюється тільки якщо є конкретна бізнес-причина.
Після векторизації кожен chunk зберігається в PostgreSQL з розширенням pgvector: текст, вектор і метадані (назва документа, дата, колекція). Саме ці вектори будуть використовуватись при кожному пошуковому запиті.
Підсумок етапу 2: embedding перетворює текст на математику. Вибір моделі — це баланс між якістю пошуку, безпекою даних і вартістю інфраструктури.
⸻
Етап 3: vector search і BM25 — чому одного пошуку недостатньо
Тільки семантичний пошук — не вистачає. Тільки пошук по ключових словах — теж. AskYourDocs запускає обидва паралельно і об'єднує результати. Це гібридний пошук — стандарт де факто для production RAG-систем у 2026.
Проблема чистого векторного пошуку — на реальному прикладі
Менеджер дистриб'ютора запитує: "Артикул AB-4521, ціна?" Векторний пошук шукає семантично схожі фрагменти — "щось про товари і ціни". Але артикул AB-4521 — це точний ідентифікатор. Семантично він нічим не відрізняється від AB-4522 або AB-9999. Векторний пошук може повернути не той товар.
Або юрист питає: "Пункт 4.3.2 договору №187". Векторний пошук знайде "щось про договори" — але конкретний номер пункту він не "розуміє" математично.
Проблема чистого BM25 — на тому ж прикладі
BM25 (Best Matching 25) — класичний алгоритм пошуку по ключових словах, той самий що лежить в основі пошуку Google до епохи нейромереж. Він блискуче знаходить точні збіги: артикул, номер пункту, назву продукту.
Але якщо клієнт питає "як підготуватись до операції на серці", а в протоколі написано "підготовка пацієнта до кардіохірургічного втручання" — BM25 не знайде нічого. Жодного спільного слова.
Гібридний пошук: обидва методи паралельно
AskYourDocs запускає vector search і BM25 одночасно, незалежно одне від одного. Vector search знаходить семантично близькі фрагменти — там де важливий сенс. BM25 знаходить точні текстові збіги — там де важливі конкретні терміни, номери, артикули.
За даними реального production-кейсу опублікованого на Medium, перехід з чистого vector search на гібридний підхід підняв точність retrieval з 62% до 91% — приріст 48% на реальних мультимовних документах.
| Метод пошуку | Добре знаходить | Погано знаходить |
|---|---|---|
| Vector search | Семантично схожий зміст, синоніми, перефразування | Точні артикули, номери, ідентифікатори |
| BM25 | Точні ключові слова, номери, артикули | Синоніми, інша мова, перефразування |
| Гібридний (AskYourDocs) | І те і інше одночасно | Мінімальні сліпі зони |
Додатково AskYourDocs автоматично визначає мову запиту і застосовує відповідну конфігурацію BM25 — українська, англійська, німецька або іспанська. Це важливо: BM25 для кирилиці і латиниці потребує різних налаштувань токенізації.
Підсумок етапу 3: гібридний пошук — це не ускладнення, це необхідність для будь-якої бізнес-бази знань де є і семантичні запити і точні ідентифікатори.
⸻