Разбор шести причин сбоев памяти RAG-агентов

RAG (Retrieval-Augmented Generation) объединяет большую языковую модель с внешней базой знаний: сначала система ищет информацию в корпоративных документах или интернете, а затем формирует ответ на её основе. В продакшне такие системы часто отвечают неверно, и инженеры по привычке пытаются лечить симптом — меняют эмбеддинг-модель, увеличивают top-k или обновляют LLM. Однако если в промпт изначально попал неподходящий контекст, сломан именно слой извлечения, а галлюцинация модели — лишь следствие.

Статистика подтверждает масштаб проблемы: 73% поломок RAG-систем связаны с плохим поиском, а в 40% случаев пайплайны вообще не могут достать нужные данные. Исследование RAGGED опровергло миф о том, что чем больше документов подать на вход, тем лучше. Современные модели вроде LLaMA и Claude показывают пик качества всего на 5 чанках, после чего результат резко падает. Более того, Claude с контекстом в 200 тысяч токенов выдал лучший ответ, когда получил лишь один максимально точный фрагмент.

Первая типовая точка отказа — некачественное разбиение документов на чанки. Фиксированное деление по 512 токенов разрывает сущность и её квалифицирующее предложение, лишает фрагмент заголовка раздела и превращает таблицы в шум. Маленькие чанки повышают точность поиска, но уничтожают контекст, большие — сохраняют смысл, но размывают точность. Решение — структурное разбиение по границам разделов и таблиц, перенос заголовков в дочерние чанки и отдельный конвейер для табличных данных.

Вторая проблема — разрыв между формулировкой запроса и языком документов. Запрос «Как отменить подписку?» не находит документ «Account Termination Policy», поскольку расстояние между векторами не передаёт намерение пользователя. Гибридный поиск, объединяющий плотные эмбеддинги с BM25 через Reciprocal Rank Fusion, помогает ловить точные ID и аббревиатуры. Переформулировка запроса через LLM и метод HyDE, при котором поиск идёт по эмбеддингу гипотетического ответа, дополнительно сокращают число неудачных извлечений.

Контекстные эмбеддинги, при которых модель генерирует для каждого чанка пояснение его места в документе, по данным Anthropic сокращают число неудачных извлечений на 35%, в связке с контекстным BM25 — на 49%, а с добавленным реранкингом — на 67%. При этом увеличение top-k не является универсальным решением: качество ответа достигает максимума на средней глубине выдачи и затем падает из-за разбавления сигнала. Работа «Lost in the Middle» показала, что модель лучше использует информацию в начале и конце контекста, а в середине качество заметно снижается.

Отдельный класс отказов — multi-hop-запросы, требующие цепочки рассуждений по нескольким документам. Стандартный RAG извлекает информацию независимо по каждому запросу и не умеет связывать промежуточные факты, разбросанные по разным источникам. Если retrieval не возвращает нужный фрагмент, качество генерации ограничено сверху, и сменой модели это не исправить: в инженерных руководствах фигурирует порог recall около 85%, ниже которого чинить нужно именно поиск.

Практический вывод: схема «нарезать по 512 токенов и забрать top-5» больше не работает. Надёжная архитектура требует структурного разбиения, гибридного поиска, реранкинга, динамического планирования запросов, фильтрации по метаданным и непрерывного мониторинга качества retrieval. В части случаев RAG вообще не нужен, поэтому диагностику по метрикам стоит проводить до того, как усложнять пайплайн.