RAG, CAG и причем тут контекстное окно
Щас расскажу про тааакую штуку, но начну с исторической справки: долгое время мы все сидели в парадигме RAG. Почему? Да потому мой любознательный друг, что контекстные окна у нейронок были размером с почтовую марку.
Приходилось резать данные в мелкую лапшу, превращать их в векторы и надеяться, что поисковый алгоритм вытянет именно тот кусок, который нужен. Но в 2026 году, когда контекст измеряется миллионами токенов, этот подход начинает выглядеть как костыль. На смену (или скорее в дополнение) приходит CAG — Cache-Augmented Generation.
Как работает магия?
Суть простая: вместо того чтобы каждый раз судорожно искать фрагменты в базе, я загружаю всю базу знаний целиком прямо в контекстное окно модели и замораживаю её там. Это стало возможным благодаря KV-кэшированию. Модель один раз обрабатывает массив данных, сохраняет промежуточные вычисления и при каждом новом вопросе обращается к этому «горячему» кэшу. Больше никакого ожидания, пока идет поиск нужных данных. Ответ прилетает мгновенно, как будто я общаюсь с коротким промптом, хотя за спиной у модели висят сотни мегабайт документации.
Почему это точнее и быстрее?
Тут все просто то безумия. В классической схеме точность всегда упирается в качество поиска: если алгоритм не нашел нужный кусок, модель его просто не увидит и начнет лукавить на голубом глазу. В CAG поискового этапа просто нет — модель видит всю картину сразу. Это дает практически стопроцентную точность и позволяет сопоставлять факты из разных концов огромного архива. Для RAG это часто была непосильная задача, а для нас — теперь база.
А как эту вундервафлю применить?
Возьмем конкретный пример из нашей жизни. Когда нужно провести полный аудит сложной дизайн-системы, мы кэшируем все гайды и кейсы за последние годы. Теперь я могу спросить о противоречиях в логике отступов между проектами разных лет, и модель не просто найдет упоминания, а проведет сквозной анализ всего объема данных.
Другой вот кейс — работа с легаси. Можно засунуть в кэш весь репозиторий проекта, который писали пять лет разные команды. Если спросить, как изменение одной функции аутентификации повлияет на логику инвойсов в другом модуле, модель увидит все зависимости. Поисковый алгоритм RAG мог бы это пропустить из-за низкой семантической схожести запроса, а CAG — нет.
Про страх потери середины
Мне накидали в панамку по поводу потери данных или снижения внимания в середине огромного контекста. Ребят, это все хуйня. Современные архитектуры давно решили проблему потери середины. В тестах на извлечение информации модели показывают идеальные результаты даже на объемах в два миллиона токенов. Единственное реальное ограничение — это объем. Если ваша база весит терабайты, RAG все еще неизбежен. Но для локальных баз до 200 мегабайт CAG — это абсолютная киллер-фича.
Че по бабкам?
Конечно, за кэш нужно платить как и за все в жизни. Хранение активного контекста стоит денег, и если обращаться к нему раз в месяц, это выйдет дороже классической векторной базы. Но если вам нужен глубокий, быстрый и точный анализ в режиме рилтайма, CAG окупает себя за счет экономии на разработке и отсутствия ошибок поиска. Лично для меня выбор очевиден: там, где важна глубина понимания, я выбираю кэш.