RAG vs CAG vs Agentic RAG

Три способа дать LLM внешнее знание: RAG (retrieval на каждый запрос), CAG (предзагруженный KV-кэш без retrieval), Agentic RAG (итеративный retrieval-loop с planning/self-critique). Выбор — не «кто лучше», а под профиль данных и нагрузки: масштаб/изменяемость базы × latency/cost × сложность reasoning.

Содержит быстро устаревающие ориентиры (пороги, цифры бенчмарков) — status/volatile.

Суть

  • RAG — большой и/или часто меняющийся корпус: достаём только релевантное подмножество на запрос.
  • CAG — малый и стабильный корпус, критична latency: грузим всё в контекст один раз.
  • Agentic RAG — сложные multi-step / cross-source задачи: агент сам решает, что и сколько искать.

Матрица выбора

Критерий RAG CAG Agentic RAG
Объём базы без ограничений (10⁹+) строго < ~500K–1M токенов без ограничений (динамич. поиск)
Частота обновлений высокая крайне низкая (инвалидация кэша дорогая) высокая (живые API/web)
Latency / TTFT средняя (~1–2 c) низкая (субсекундный инференс по кэшу) высокая и вариативная (3–15+ c)
Предсказуемость затрат высокая (1-pass) высокая при cache-hit низкая (зависит от глубины циклов)
Multi-step синтез слабый (one-shot) хороший (видит всю базу) отличный (итеративно)
Аудит / цитирование высокий (ссылки на чанки) ограниченный (диффузное внимание) превосходный (верифицир. ссылки)
Сложность разработки средняя низкая крайне высокая (оркестрация, лимиты)

Как выбирать (эвристика)

  • CAG-first: знания < ~500K токенов, стабильные, общие, latency-critical (FAQ, регламент, мануал).
  • RAG-first: корпус больше окна, частые изменения, user-specific данные, нужна точная атрибуция.
  • Agentic: multi-step, cross-source, верификация, противоречивые источники — но не при жёстком SLA, ограниченном бюджете или требовании воспроизводимости.
  • Гибрид (Tiered Memory): L1 = CAG (стабильное ядро, ~80% запросов) → L2 = RAG (динамика) → L3 = Agentic RAG (сложное/противоречивое). Изолирует дорогие агентские циклы туда, где линейные подходы не справляются.

Когда НЕ использовать Agentic RAG

  • Жёсткий SLA (TTFT < 200 мс): поведение агента вариативно, p95 уходит в длинный хвост (каскад вызовов + рефлексия).
  • Ограниченный бюджет: без жёстких stop-criteria (max_steps, токен-лимит, см. Agent CostControl) агент может уйти в лавину самокоррекции.
  • Требование воспроизводимости (фин./мед.): автономные решения снижают детерминизм; детерминированные RAG/CAG надёжнее.
  • Эмпирика: на задаче верификации фактов (FEVER) у Agentic RAG recall падает до ~49% — агент рано решает, что данные не нужны, и останавливает поиск; детерминированный Enhanced RAG держит ~84% («Is Agentic RAG worth it?», ACL 2026).

Связано с

  • RAG · CAG · Agentic RAG — три сравниваемых подхода
  • Agent CostControl — stop-criteria и лимиты для безопасного Agentic RAG
  • Reasoning Effort — «какое усилие нужно задаче» — та же логика «не усложняй без нужды»

Открытые вопросы

  • свой бенчмарк выбора на доменной задаче (RAG vs CAG vs Agentic): latency / cost / quality?