RAG чи довгий контекст: як вибрати архітектуру для знань

Long-context підхід завантажує в prompt увесь релевантний робочий набір: документ, репозиторій, стенограму або пакет файлів. Модель може бачити зв’язки між віддаленими фрагментами без окремого retriever, але кожний запит має нести великий input або використовувати provider caching. Межа контекстного вікна є технічним лімітом, а не гарантією, що модель однаково добре використає кожен токен.

RAG спочатку індексує корпус, а на кожний запит знаходить невелику вибірку фрагментів. Це зменшує input і дозволяє фільтрувати документи за tenant, ACL, датою чи типом, проте додає власні failure modes: поганий chunking, невдалий query rewrite, низький recall, reranking noise та розрив важливого контексту між chunks. Отже, вибір відбувається між різними контурами помилок, а не між сучасною і застарілою технологією.

Long context природно підходить для одного bounded artifact, який треба прочитати цілісно: контракт із додатками, одна codebase snapshot, довга розмова або набір матеріалів конкретної справи. RAG сильніший для великого мінливого корпусу, повторюваних запитів, granular permissions і сценаріїв, де треба показати, які саме passages були отримані retriever перед генерацією.

Не приймайте рішення лише за максимальною кількістю токенів у model card. Порівнюйте реальний corpus size, частоту змін, query distribution, допустимий p95 latency, input cost, cache hit rate, permission model і вимоги до citation trace. Один продукт може використовувати long context для завантаженого dossier, а RAG — для пошуку по всій корпоративній базі знань.

• Один стабільний bounded пакет і cross-document synthesis → почніть із long context;
• Великий або часто оновлюваний корпус → почніть із RAG;
• Document-level або tenant-level ACL → retrieval filter застосовується до генерації;
• Повторюваний довгий префікс → перевірте provider caching і cache misses;
• Непередбачувані запити й змішаний корпус → тестуйте hybrid router;
• High-stakes відповіді → зберігайте passage provenance незалежно від архітектури.

Дослідження Li та співавторів 2024 року показало сильну середню якість long context за достатніх ресурсів і нижчу вартість RAG, а запропонований Self-Route направляв складні запити до повного контексту. LaRA у 2025 році дійшла обережнішого висновку: оптимальний варіант залежить від моделі, довжини й типу тексту, задачі та якості retrieved chunks. Це не суперечність, а нагадування, що benchmark design визначає відповідь.

Власний eval set має містити запити, які справді потребують зовнішніх даних: exact lookup, multi-hop synthesis, глобальне узагальнення, часові питання, conflicting sources, no-answer і permission-denied cases. Окремо вимірюйте retrieval recall, context precision, answer correctness, citation entailment, abstention і end-to-end latency. Якщо оцінювати лише фінальну відповідь, неможливо відрізнити failure retriever від failure generator.

Long context платить за великий input на кожний cache miss і може збільшувати time to first token. Caching здатен знизити повторну обробку стабільного префікса, але додає правила мінімального розміру, TTL, storage price та залежність від provider. RAG платить за ingestion, embeddings, vector storage, search, reranking і операційне обслуговування, зате generation input зазвичай менший.

Порівняйте cost per successful task, а не ціну тисячі токенів. До формули входять ingestion при кожній зміні, cache creation і hits, retrieval calls, reranker, generation, retries, observability та людський review. Для low-frequency аналізу одного dossier індексація може бути зайвою; для тисяч щоденних запитів по великому каталогу передавання всього корпусу часто нераціональне навіть тоді, коли він формально поміщається у window.

У long-context pipeline свіжість означає заново сформувати authoritative package і гарантувати, що старий cached prefix не пережив зміну документа. У RAG pipeline треба завершити ingestion, видалити або version stale chunks і не видавати змішаний snapshot. Обидва підходи потребують document ID, version, effective date та trace того, що реально потрапило до моделі.

ACL не можна делегувати prompt. Якщо користувач не має права на документ, він не повинен потрапити ані до retrieved set, ані до long-context package. Для citations зберігайте source ID і offsets до нормалізації, а після відповіді перевіряйте, що cited passage підтримує claim. Просте посилання на файл доводить походження контексту, але не істинність висновку.

Практичний hybrid не просить модель абстрактно вгадати, чи потрібен RAG. Спершу дешевий retrieval повертає passages і діагностику: score distribution, coverage ключових entities, кількість джерел і конфлікти. Router ескалює до ширшого document context, якщо recall proxy слабкий, питання вимагає global synthesis або retrieved fragments суперечать один одному.

Policy має бути deterministic там, де це можливо: document summarization завжди отримує повний bounded artifact; exact policy lookup використовує filtered RAG; legal comparison відкриває повні версії лише тих документів, які відібрав retrieval. Router version, причина маршруту, token budget і fallback записуються в trace. Так гібридність стає контрольованою системою, а не подвійною інфраструктурою без owner.

Побудуйте три однакові за моделлю й output contract варіанти: tuned RAG, long context і hybrid. Зафіксуйте corpus snapshot та проганяйте той самий eval set. Не оптимізуйте одну гілку після перегляду test answers, не даючи такого самого бюджету іншій: це створює упереджене порівняння. Результати сегментуйте за типом задачі й довжиною evidence, бо середнє приховує failure pockets.

Рішення приймайте через пороги: quality floor, citation correctness, unauthorized-context rate рівно нуль, p95 latency, cost per accepted answer і operational error budget. Якщо long context виграє global synthesis, а RAG — exact lookup, не обирайте одного переможця для всього продукту. Зафіксуйте routing table, rollback до простішої гілки і дату повторного тесту після зміни моделі, corpus або pricing.