Ограничения наивного RAG

У RAG (Retrieval-Augmented Generation) в его базовом виде - сделать эмбеддинг запроса, достать top-K наиболее похожих фрагментов и передать их модели - есть известные слабые места, которые проявляются при выходе за рамки простых вопросов и ответов.

Ответы, разбросанные по нескольким страницам. Когда ответ на вопрос распределён по нескольким документам, выборка top-K может вернуть лишь часть нужных фрагментов. Модель видит неполную картину и либо отвечает частично, либо додумывает недостающее.

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

Отсутствие навигации. Базовый RAG - это однопроходный конвейер "найти и сгенерировать". Модель не может продолжить поиск и решить: "в этом фрагменте упомянута связанная страница, посмотрю-ка и её". Здесь нет исследования или итераций.

Подобные ограничения подталкивают к тому, чтобы давать агентам более богатый доступ к исходным данным. Mintlify решила эту проблему, создав виртуальную файловую систему (ChromaFs): она позволяет агентам перемещаться по документации с помощью команд оболочки вместо поиска по фрагментам. Среди других подходов - рекурсивный поиск (когда первоначальная выборка используется для уточнения запроса), графовый RAG (переход по связям между сущностями во фрагментах) и агентный RAG (где модель сама решает, когда и как искать информацию).

Общая идея здесь в том, что поиск должен стать интерактивным, а не одноразовым: агенту нужна возможность исследовать данные, а не просто делать разовые запросы.