RAG vs fine-tuning vs long context: що вибрати для клієнтського бота

Клієнти часто приходять із запитом «доучіть модель на наших даних» — і майже завжди це не те, що їм технічно потрібно. Розберемо три живі підходи: RAG, long context і fine-tuning — і коли який обирати, з конкретикою по стеку.

TL;DR

• RAG — векторна база поряд із моделлю, відповідь збирається зі знайдених шматків.
• Long context — кидаємо всю базу прямо в промпт, без векторів і інфраструктури.
• Fine-tuning — донавчаємо модель на ваших прикладах, знання «вшиваються» у ваги.

У переважній більшості бізнес-задач старт правильний з RAG або long context. Fine-tuning — інструмент пізньої оптимізації, не першого кроку.

Long context — найчастіше недооцінений варіант

Сучасні моделі тримають у вікні 200k–2M токенів — це 500–5 000 сторінок документа за один запит. У звʼязці з prompt caching повторні токени тарифікуються зі знижкою до 90%: повну ставку платите лише один раз, далі — кешований префікс.

Коли вистачає long context’у технічно:

• Уся база знань вміщується в ~200k токенів (∼500 стор. PDF після очищення).
• До одного й того ж набору даних багато запитів → cache TTL не встигає протухнути.
• База апдейтиться рідше за TTL кешу (інакше префікс інвалідується щоразу — і знижка не працює).
• Можна обійтися без selective retrieval і реранкінгу.

Технічні підводні камені:

• Cache TTL у провайдерів від 5 хв до 1 год — мала база, що міняється рідко, грає вам на руку. Велика, що міняється щохвилини, — ні.
• Якість падає на «голці у стозі сіна» при ~128k+ токенів — навіть якщо модель формально тримає 1M. Тести needle-in-haystack дають правдиву картину.
• Token cost все одно лінійний за обсягом контексту в кожному запиті, навіть з cache (просто з нижчою ставкою). Для високого QPS — не оптимально.

Long context — це часто простіший і швидший старт для невеликих баз: немає інфраструктури, нема embeddings, нема реранкера. Якщо не впевнені, що ваш кейс — long context чи RAG, напишіть нам, розберемо архітектуру.

Де RAG все ще виграє

1. Велика база — десятки тисяч сторінок, гігабайти тексту, фізично не влізе в промпт.
2. Часті оновлення — переіндексувати один чанк у Qdrant швидше, ніж перебудовувати весь кеш-префікс.
3. Потрібні цитати з джерела — RAG повертає shard + посилання на документ, long context — суцільну відповідь, доводиться додатково шукати, звідки модель взяла.
4. Контроль витрат на токени при високому QPS — long context оплачує контекст у кожному запиті (нехай і кешований), RAG — лише знайдені k шматків.

Технічний мінімум RAG’у-2026:

• Chunk: 400–800 токенів, overlap 50–100. Один розмір не підходить усім — для FAQ менше, для довгої документації більше.
• Hybrid retrieval: dense (embeddings) + sparse (BM25). Один dense пропускає точні збіги по термінах, один sparse — пропускає синоніми.
• Reranker поверх top-k=20→6. Найчастіше саме реранкер витягує якість, а не зміна embedding-моделі.
• Eval suite з golden-set’ом запитів, інакше регресії будуть непомітні до жалоби клієнта.

GraphRAG — коли звʼязки важливіші за тексти

Звичайний RAG ріже документи на плоскі чанки і шукає за схожістю. Це програє там, де питання вимагає обходу звʼязків між сутностями:

«Які з наших клієнтів з юр.особами в ЄС працювали з підрядником X у 2024 і скаржилися на затримки?»

Один чанк цього не дасть — відповідь розкидана по CRM, договорах, листуванні й логах. GraphRAG будує граф сутностей (клієнт → договір → підрядник → юрисдикція → інцидент) і обходить його у відповідь на запит.

Технічна структура:

• Extract сутностей — LLM на доках витягує іменовані сутності та звʼязки. Виходять трійки (entity, relation, entity). Кращі результати — на specialized prompting + перевірка структурованого виходу (Pydantic / JSON schema).
• Граф-БД — Neo4j або Memgraph. Neo4j зрілий, Memgraph швидший і простіший у деплої.
• Гібрид graph + vector — для повноти. На етапі retrieval ходимо по графу, на етапі генерації — підмішуємо vector-чанки для деталей.
• Eval окремо — традиційна метрика RAGAS на GraphRAG не дуже валідна, бо «правильна відповідь» — це обхід графу, а не фрагмент тексту.

Де технічно виграє:

• Юристи — звʼязки між статтями закону, прецедентами, посиланнями.
• Медицина — симптом → діагноз → препарат → протипоказання → взаємодії.
• Enterprise-KB — «хто відповідає за модуль X, з ким він обговорював зміну Y».

Налаштування складніше за плоский RAG: extract-пайплайн, граф-БД, окремий eval — більше рухомих деталей. Беремо тільки коли стандартний RAG явно ламається на даних клієнта. Якщо здається, що ваш кейс — про звʼязки, а не пошук тексту — пишіть, розберемо разом.

Fine-tuning — коли реально треба

• Свій стиль або термінологія, яку не виводиш few-shot’ом у промпті. Перевірка: 5–8 прикладів у системному промпті не дають потрібного результату → можливо, fine-tune.
• Високе навантаження, де токени стали окремою статтею витрат — донавчена модель може давати ту саму якість на меншому контексті, плюс відповідати коротше.
• Структурований вивід із жорсткою схемою, де few-shot роздуває промпт до непристойності.

Технічні нюанси:

• LoRA / QLoRA — у 95% бізнес-кейсів достатньо, дешевше повного fine-tune і не «забуває» базові навички.
• Розмір датасету — не 100 прикладів, як часто думають клієнти, а 500–5 000 пар «запит → ідеальна відповідь» з нормальним розподілом.
• DPO — поверх SFT, коли треба прибрати конкретні поведінки. Складніше, потрібен сигнал «краще/гірше», не «правильно/неправильно».

В інших випадках починаємо з RAG / long context, збираємо 3 місяці реальних запитів — і тільки тоді вирішуємо, чи треба fine-tune поверх.

Як вибрати — чек-лист

• База < 500 сторінок і запити повторюються? → long context + cache.
• База велика, оновлюється щодня, потрібні цитати? → RAG.
• Питання вимагають обходу звʼязків між сутностями? → GraphRAG.
• Свій стиль/термінологія + високе навантаження? → fine-tune поверх RAG.
• Сумніваєтесь? → почати з long context, мігрувати на RAG коли впреться у ліміт.

---

Бот на власних даних і не впевнені у виборі — напишіть у @smai_agency або через /contact, розберемо архітектуру під ваш кейс.