LLM знає світ станом на дату навчання і нічого не знає про ваші документи. RAG не змінює модель — він щоразу знаходить потрібний фрагмент тексту й підкладає його перед відповіддю.
Знання LLM «запечені» у вагах під час навчання. Звідси чотири обмеження, які й породили RAG.
Усе, що сталося після cutoff, для моделі не існує: ціни, регламенти, версії API.
Внутрішні документи, тікети, договори ніколи не були в навчальній вибірці.
Модель оптимізована на правдоподібність, а не на істинність — і не дає посилання, яке можна перевірити.
Три способи це виправити
| Підхід | Що дає | Ціна |
|---|---|---|
| Донавчанняfine-tuning | Стиль, формат, доменну поведінку | Дні й гроші на кожне оновлення даних; не вміє цитувати джерела |
| Довгий контекст | Знання рівно одного набору документів | Платите за всі токени в кожному запиті; обмежений розмір вікна |
| RAG | Свіжі приватні факти + посилання на джерело | Треба побудувати й підтримувати пошук |
Це не взаємовиключні підходи: типова зріла система — RAG для фактів плюс промпт чи донавчання для тону відповіді.
Retrieval-Augmented Generation (Lewis et al., 2020) · Retriever + Generator · «іспит з відкритою книжкою»
RAG не змінює ваги моделі. Він змінює те, що модель бачить у момент відповіді: до питання користувача додається знайдений фрагмент документа.
Крок 1 · Retriever
Пошук
За запитом знаходимо k найрелевантніших фрагментів у базі знань.
Крок 2 · Augmentation
Збагачення промпту
Фрагменти вставляються в шаблон разом із питанням та інструкціями.
Крок 3 · Generator
Генерація
LLM відповідає лише на основі наданого контексту й посилається на джерела.
З «енциклопедії» модель перетворюється на читача з логікою: зрозуміти питання, прочитати надані фрагменти, коректно їх переказати.
Якість системи впирається у пошук, а не в модель. Якщо потрібного фрагмента немає в контексті, найрозумніша LLM не врятує.
Indexing (offline, періодично) · Querying (online, на кожен запит користувача)
Головне правило: запит і документи кодуються однією й тією ж embedding-моделлю. Заміна моделі означає повну переіндексацію бази.
Embedding — щільний вектор із 384–3072 чисел · близькість = косинусна схожість (cosine similarity)
Метрику диктує модель, а не смак: у картці embedding-моделі завжди вказано, з чим її навчали
Головне: якщо вектори L2-нормалізовані, косинус, скалярний добуток і L2 дають однакове ранжування — різниця лише у швидкості. Тому багато систем нормалізують вектори на індексації й далі рахують найдешевший скалярний добуток.
| Оператор | Коли доречний | Нюанс |
|---|---|---|
| <=>cosine | Дефолт для тексту. Коли не впевнені в нормалізації або в базі вектори з різних джерел | Значення 0…2; схожість = 1 − відстань |
| <#>inner product | Вектори гарантовано нормалізовані і потрібна максимальна швидкість. Або рекомендації, де довжина кодує популярність | Повертає від'ємне значення: Postgres сортує за зростанням |
| <->L2 / euclidean | Зображення, обличчя, аудіо. Обов'язкова для k-means і DBSCAN — вони визначені через L2 | Для нормалізованих векторів зводиться до косинуса |
| <+>L1 / manhattan | Рідкісний випадок: незалежні інтерпретовані ознаки (ціна, вага, розмір), а не embeddings | Менш чутлива до викидів в окремих координатах |
| <~>hamming | Тип bit після бінарної квантизації: швидко відібрати ~200 кандидатів на базах від десятків мільйонів. Дедуплікація за хешами | У 32 рази менше пам'яті; далі переранжування float-векторами |
Індекс створено з vector_l2_ops, а запит іде через <=>. Індекс мовчки ігнорується — і ви отримуєте повний перебір бази без жодної помилки в логах.
Повертає вже нормалізовані вектори на 1536 вимірів, тож коректний вибір — косинус. Але після скорочення розмірності (Matryoshka, dimensions=512) вектор перестає бути одиничним і потребує ручної нормалізації.
Vector database · ANN — Approximate Nearest Neighbour · HNSW · pgvector · Qdrant · Elasticsearch
Компроміс ANN: трохи точності в обмін на швидкість. Ручки M та ef_search регулюють баланс «повнота пошуку ↔ затримка».
Chunking · chunk size · overlap · Parent Document Retrieval
Чанк — це одиниця пошуку. Замалий втрачає контекст і робить відповідь неповною; завеликий розмиває вектор і тягне в промпт зайвий шум.
| Стратегія | Як працює | Коли доречно |
|---|---|---|
| Рекурсивнийrecursive split | Ділить за абзацами, потім реченнями, потім символами | Дефолт для більшості текстів: не рве речення посередині |
| За структуроюdocument-based | За заголовками й розділами документа | Регламенти, документація, Markdown, код — найкраща якість |
| Батьківський документsmall-to-big | Шукаємо по малих чанках, у контекст даємо великий батьківський блок | Найкращий компроміс: точний пошук + повний контекст |
512 токенів, перекриття 50–80, поділ за заголовками. Далі — вимірювати, а не вгадувати: змініть один параметр і подивіться на recall@k.
Чанк без «шапки»: фрагмент «строк становить 14 днів» без назви розділу й документа. Додавайте заголовки розділу в текст самого чанка.
Dense retrieval · BM25 · Hybrid · RRF — Reciprocal Rank Fusion · Cross-encoder reranking
Головна цінність — не порядок, а скорочення контексту: 5 точних чанків замість 30 приблизних дають кращу відповідь і дешевший запит.
Модель гірше помічає інформацію в середині довгого контексту. Найрелевантніше ставте на початок і в кінець промпту.
«А що з тим договором?» — у векторному просторі майже шум. Перед пошуком LLM розгортає запит у самодостатнє питання з історії діалогу.
Систему міряють у двох точках окремо: чи знайшли потрібне і чи правильно переказали знайдене. Без такого поділу неможливо зрозуміти, що саме лагодити.
| Метрика | Що показує | Що робити, якщо низька |
|---|---|---|
| Recall@kпошук | Чи потрапив потрібний чанк у top-k взагалі | Чанкінг, embedding-модель, гібридний пошук, більше k |
| MRR / NDCGпошук | Наскільки високо він у списку | Додати реранкер, підкрутити ваги гібриду |
| Faithfulnessгенерація | Чи кожне твердження підтверджене контекстом | Жорсткіший промпт, менше чанків, дозвіл на «не знаю» |
| Answer relevancyгенерація | Чи відповідає текст саме на поставлене питання | Переписування запиту, інша модель, інший шаблон |
50–200 реальних питань із перевіреними відповідями та документами-джерелами. Найцінніший артефакт проєкту — збирайте з першого тижня.
RAGAS, DeepEval, LangSmith, Langfuse. Оцінка здебільшого через LLM-as-a-judge — звіряйте її з людською вибіркою.
Кожна зміна промпту, моделі чи чанкінгу — прогін по golden set у CI. Інакше покращення одного сценарію тихо ламає п'ять інших.
| Симптом | Справжня причина | Лікування |
|---|---|---|
| «Не знаю» на очевидне питання | Потрібного чанка немає в top-k: невдалий поділ або інша лексика | Гібридний пошук, більший k + реранкер, контекст у чанку |
| Відповідь неповна | Інформація розкидана по кількох чанках, у контекст потрапив один | Parent document retrieval, більший чанк, перекриття |
| Цитує застарілий документ | Стара й нова версія лежать в індексі поруч | Дедуплікація, версіонування, видалення при оновленні |
| Плутає таблиці й цифри | Таблиця розрізана або перетворилася на плоский текст | Окремий парсер таблиць, зберігати як Markdown |
| Працює в демо, падає в проді | Тестували на 10 документах, а в базі 100 тисяч — шуму на порядки більше | Оцінка на реальному обсязі, фільтри за метаданими |
Правило діагностики: спершу подивіться, які саме чанки потрапили в контекст. У 8 випадках із 10 винен пошук, а не модель.
RAG — це інженерія пошуку, а не магія моделі. Якість визначає те, що потрапило в контекст.
Найбільший приріст дають нудні речі: чистий парсинг, розумний чанкінг, метадані, гібрид, реранкер.
Без golden set і метрик будь-яке «стало краще» — це відчуття, а не факт.
Дякую за увагу. Питання?