«RAG is dead»: где здесь кликбейт, а где правда

Каждое утро вижу кучу постов в стиле «RAG is dead». Сейчас вокруг RAG идет история, которая повторяется из раза в раз, когда технология становится привычным рабочим инструментом.

Собрал коротко, что на самом деле случилось с RAG, где здесь хайп, а где правда.

Что такое RAG

RAG — это когда перед ответом ИИ-модель получает контекст из внешней памяти. Внешняя память может быть чем угодно — базой документов, кодом, CRM, файловой системой.

Почему RAG важен

Потому что у пользователей LLM есть два желания. Они хотят, чтобы ИИ-модель была умной и свежей. Обучение дает ИИ-модели ум. А вот свежесть данных и проверяемость — доступ к источникам.

Почему пишут, что RAG — всё

Заголовки «RAG мертв» появляются регулярно и правда собирают просмотры. Но если разобраться, хоронят не саму технологию, а ее упрощенное понимание.

Первые реализации RAG выглядели красиво. Берем векторную базу, нашли несколько похожих кусков, скормили модели — и она отвечает по документам. Но когда такой подход пошел в совсем больших проектах, начались проблемы.

▪️Простое сравнение векторов без учета метаданных, без дополнительных фильтров часто давало не то, что нужно. Чем больше становится база знаний, тем больше лишней информации прилетало в ответ.

▪️Даже если среди найденных кусков был правильный ответ, модель могла его не заметить, если вокруг слишком много лишнего.

▪️Модель могла игнорировать правильный контекст и отвечать по-своему. Или вообще смешать факты из разных источников так, что получится правдоподобная, но ложная картина.

Три самых популярных тезиса про «RAG is dead»

Длинный контекст делает RAG ненужным. Якобы можно просто загрузить все документы в промпт и модель сама разберется. На практике пока это не работает. Модели теряют информацию из середины длинного контекста, снижается качество ответов. По сути это самый дорогой способ получить худший результат.

Вирусный пересказ исследований, что ученые доказали — RAG ломается после 10 тысяч документов. Простой поиск по векторам без дополнительных уточнений действительно теряет точность на больших объемах. Но это проблема не RAG, а его примитивной реализации.

RAG не спасает от выдумок. Даже с подобранными документами модель может ошибаться или додумывать. Но из этого делают неправильный вывод: «раз не спасает полностью, значит бесполезен». На самом деле RAG снижает долю выдумок, дает возможность проверять ответы по источникам и строить системы, где ошибки можно ловить и исправлять.

Что реально изменилось: RAG образца 2023 и 2026 годов

Эмбеддингов самих по себе недостаточно. Поэтому появились методы, которые добавляют контекст на этапе построения представления фрагмента и одновременно используют классический лексический поиск.

Раньше думали, что можно сделать хороший поиск и RAG заработает. Теперь стало понятно, что это только верхушка айсберга. Все решает то, как удастся собрать контекст из найденных кусков, как отсеять лишнее, в каком порядке разложить фрагменты, что делать со старыми данными, как не перекормить модель. Это называется контекстная инженерия.

Появился агентный поиск. Система может сама уточнить запрос, если результатов мало. Может попробовать другой инструмент, например вместо векторного поиска — текстовый, вместо поиска по кускам — чтение целого документа. Может выдвинуть гипотезу и проверить ее, найдя подтверждение или опровержение.

Графовый подход. Классический RAG хорош для вопросов вроде «что сказано в документе о таком-то?». Он находит нужный кусок и отвечает. Но это уже не так эффективно, когда спрашивают, о чем этот массив документов, какие темы там главные, как связаны разные сущности и прочее. Графовый подход, вместо того чтобы просто нарезать текст на куски, система строит граф знаний, потом отвечает на вопросы.

RAG ни в коем случае не умер. Просто вместо одного шаблонного решения появилось целое семейство подходов, которые выбирают под задачу.