Long context проти CAG: як ШІ «пам’ятає» зовнішні дані

У сучасних LLM-системах (великих мовних моделях) головна проблема давно вже не в тому, щоб «вигадати» відповідь, а в тому, як дати моделі доступ до актуальних зовнішніх знань. Канал IBM Technology розбирає два підходи, які стають альтернативою (або доповненням) до популярного RAG: long context і Cache Augmented Generation (CAG). Обидва спираються на те, як саме модель читає й запам’ятовує текст — і від цього безпосередньо залежать вартість, швидкість і точність реальних AI-сервісів.

Що таке long context і чому це не просто «більший промпт»

Long context — це найпрямолінійніший спосіб дати моделі доступ до зовнішніх даних: просто покласти все потрібне в контекстне вікно (prompt) разом із запитом користувача.

Як зростали контекстні вікна

Розмір контексту за останні роки зріс на порядки:

• GPT‑3 (2020) — близько 1 000 токенів (орієнтовно 10 сторінок тексту).
• GPT‑4 Turbo (2023) — 128 000 токенів (приблизно 300 сторінок).
• Google Gemini 1.5 Pro (2024) — до 2 млн токенів (умовно до 20 повноцінних романів).

Це створює спокусу взагалі відмовитися від складних retrieval-пайплайнів (як у RAG) і просто «залити» всі документи в один гігантський промпт.

Плюси підходу

• Максимальна простота: не потрібні векторні бази, ембеддинги чи окремі сервіси пошуку.
• Повний доступ до даних: модель «бачить» усі документи одразу, немає ризику, що retrieval-етап пропустить щось важливе або витягне не ті фрагменти.
• Прозора логіка: усе, що може використати модель, явно знаходиться в одному контексті.

Мінуси, які швидко стають критичними

1. Вартість токенів
   Більшість API LLM тарифікують запити за кількістю токенів. Якщо в контексті, наприклад, 200 000 токенів, ви платите за них на кожен запит, навіть якщо питання стосується лише маленького фрагмента.

2. Затримка (latency)
   Чим більший контекст, тим довше модель його обробляє. Для інтерактивних застосунків це може бути неприйнятно.

3. Ефект «lost in the middle»
   У довгих контекстах моделі краще працюють з інформацією:

4. на початку вікна,

5. та в кінці,
   а от дані посередині обробляються гірше — точність помітно падає. Це структурна особливість уваги в трансформерах.

6. Повторне читання тих самих документів
   Якщо користувач ставить 10 запитань до одного й того ж набору документів, модель 10 разів перечитує весь контекст. Обчислювальні витрати множаться без жодної «пам’яті» між запитами.

У підсумку long context добре працює там, де:

• потрібно разово проаналізувати документ або невеликий набір файлів;
• кількість запитів до цих даних невелика;
• важлива простота, а не оптимізація витрат.

CAG: коли модель читає один раз, а потім працює з «пам’яттю»

Cache Augmented Generation (CAG) пропонує інший підхід: замість того, щоб змушувати модель знову й знову читати ті самі документи, змусити її прочитати їх один раз, зберегти внутрішнє представлення — і надалі просто використовувати цей кеш.

Ключ до цього — Key-Value Cache (KV cache).

Що таке KV cache у трансформерах

Коли LLM обробляє текст, кожен шар трансформера обчислює матриці ключів (key) та значень (value). Це свого роду робоча пам’ять, яка відображає, як модель «зрозуміла» все, що прочитала до цього моменту.

У звичайному режимі:

• ці матриці обчислюються наново для кожного запиту;
• після відповіді вони не зберігаються.

CAG змінює це: обчислити один раз — і зберегти, щоб потім підвантажувати при наступних запитах.

Три фази CAG

1. Підготовка знань (knowledge preparation)
2. Вибираються релевантні документи (політики компанії, документація продукту, база знань тощо).

3. Вони форматуються так, щоб поміститися в контекстне вікно моделі.

4. Попереднє обчислення (pre-computation)

5. Модель проганяє всі ці документи через себе.
6. На виході формується KV cache — внутрішнє представлення прочитаного.

7. Цей кеш зберігається (на диск або в пам’ять).

8. Інференс (inference)

9. Надходить запит користувача.
10. Модель завантажує KV cache, додає до нього нове питання.
11. Генерує відповідь, не перечитуючи документи.

Обчислювально важка частина переноситься в фазу 2. Фаза 3 стає значно швидшою.

Прискорення та економія

Дослідження показують:

• на невеликих наборах даних у KV cache — прискорення близько 10×;
• на великих — до 40× порівняно з повним повторним читанням контексту.

Це означає:

• менші затримки для користувача;
• менші витрати на токени й обчислення при великій кількості запитів до однієї й тієї ж бази знань.

Обмеження CAG

CAG не є «магічним безмежним контекстом»:

• Увесь кешований корпус все одно має вміститися в контекстне вікно моделі.
  Якщо документи не влазять у контекст, проблему це не вирішує.

• Оновлення даних коштує дорого.
  Якщо джерельні документи змінюються:

• потрібно повністю перераховувати KV cache;
• часті оновлення з’їдають виграш у швидкості й вартості.

Отже, CAG найкраще працює там, де:

• база знань відносно стабільна;
• до неї надходить багато повторюваних запитів.

Типовий приклад — HR-чатбот для співробітників, який відповідає на питання про політики компанії. Дані змінюються нечасто, а запитів багато — кожен наступний запит після першого стає швидким і дешевим.

Long context vs CAG: де що доречніше

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

Long context

• Модель кожного разу:
• читає всі документи, покладені в контекст;
• обчислює всі внутрішні представлення з нуля.
• Плюси:
• простота впровадження;
• немає окремої інфраструктури кешування.
• Мінуси:
• висока вартість і затримка на кожен запит;
• ефект «lost in the middle» на дуже довгих контекстах;
• повна відсутність «пам’яті» між запитами.

Добре підходить для:

• разового аналізу документів;
• невеликої кількості запитів до конкретного набору даних.

CAG

• Модель один раз:
• читає всі документи;
• зберігає KV cache.
• Далі кожен запит:
• просто підвантажує кеш;
• додає питання;
• генерує відповідь.
• Плюси:
• значне прискорення при повторних запитах;
• суттєве зниження вартості при великих навантаженнях.
• Мінуси:
• потреба в керуванні кешем;
• необхідність повного перерахунку при зміні джерельних даних;
• обмеження розміром контекстного вікна.

Оптимальний варіант для:

• сервісів із частими повторними запитами до однієї й тієї ж бази знань;
• стабільних наборів документів (політики, довідники, документація, що рідко змінюється).

Prompt caching: CAG як сервіс від провайдерів LLM

Щоб зробити CAG практичним для масового використання, великі провайдери LLM додають у свої API prompt caching — по суті, реалізацію CAG «під капотом».

Як це працює:

• Розробник надсилає довгий системний промпт з усіма потрібними документами.
• Провайдер:
• один раз обробляє цей промпт;
• керує KV cache самостійно;
• для наступних запитів із тим самим префіксом промпта пропускає повторну обробку документів.

Економічний ефект:

• читання з кешу може тарифікуватися з великими знижками — до 90% дешевше, ніж повторна обробка тих самих токенів.

Фактично prompt caching:

• перетворює CAG із дослідницької концепції на готову функцію API;
• знімає з розробників необхідність будувати й підтримувати власну інфраструктуру KV cache.

Висновок

Long context і CAG — це не взаємовиключні, а комплементарні підходи до надання LLM-доступу до зовнішніх знань:

• long context виграє простотою й підходить для разових або рідкісних запитів;
• CAG (особливо в поєднанні з prompt caching) стає ключовим інструментом для масштабованих сервісів із великою кількістю повторних звернень до стабільної бази знань.

На цьому тлі класичний RAG не зникає, але отримує конкурентів і доповнення: там, де retrieval-пайплайн можна замінити великим контекстом або кешем, розробники отримують простіші й дешевші варіанти побудови AI-систем.

Джерело

YouTube: CAG vs Long Context: How AI Models Use and Remember Information