Habr: 6 причин, почему память RAG-агента сбоит, и как проверить retrieval

Когда агент на RAG отвечает мимо, первой под подозрение попадает языковая модель. Практика чаще указывает на поиск: если нужный фрагмент не попал в контекст, даже сильная LLM либо выдумает ответ, либо сообщит, что данных нет. Разбор на Habr посвящён шести причинам таких сбоев и способу диагностики retrieval. В анонсе публикации приведено только определение технологии, сам список причин скрыт под катом. Поэтому ниже карта типовых отказов, которую инженеры обычно проверяют в таком порядке.

RAG (Retrieval-Augmented Generation) связывает модель с внешней базой знаний. Агент не опирается только на заученное при обучении, а сначала ищет сведения в корпоративных документах, справочниках или интернете и пишет ответ на их основе. У конвейера минимум пять стадий: нарезка документов, векторизация, индексация, поиск и сборка контекста. Ошибка на любой из них выглядит одинаково: агент «забыл».

Где обычно ломается поиск

Первая зона риска — нарезка на чанки. Слишком мелкие куски теряют контекст, слишком крупные размывают смысл вектора. Таблица, разрезанная пополам, или определение, оторванное от термина, не найдутся ни по одному запросу.

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

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

Четвёртая — формулировка запроса. Пользователь пишет «как оформить отпуск?», а в базе документ называется «Порядок предоставления ежегодного оплачиваемого отпуска». Помогают переписывание запроса и разбиение сложного вопроса на подзапросы.

Пятая — ранжирование. Чистый векторный поиск плохо находит артикулы, имена и аббревиатуры. Гибридная схема с BM25 и реранкер на верхних кандидатах обычно дают заметный прирост точности.

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

Как диагностировать retrieval

Главный принцип: проверять поиск отдельно от генерации. Для этого собирают эталонный набор вопросов, к каждому из которых заранее привязан фрагмент-источник. Хватает нескольких десятков или пары сотен примеров, но они должны отражать реальные запросы пользователей, а не придуманные разработчиками.

Дальше считают метрики:

• recall@k: доля вопросов, для которых нужный фрагмент попал в топ-k результатов. Если здесь провал, дальше можно не смотреть;
• precision@k: сколько из найденного действительно полезно, то есть сколько шума уходит в промпт;
• MRR: на какой позиции в среднем стоит первый верный результат;
• nDCG: качество порядка выдачи при нескольких релевантных фрагментах;
• задержка поиска и реранкинга, потому что точность, купленная секундами ожидания, для агента часто неприемлема.

Если recall высокий, а ответы плохие, проблема лежит ниже по конвейеру: в сборке контекста или в самой модели. Если recall низкий, начинают с чанков и эмбеддингов.

Практический порядок действий

Сначала соберите эталонный набор и зафиксируйте базовые цифры. Затем меняйте по одному параметру: размер чанка, модель эмбеддингов, добавление BM25, реранкер, число передаваемых фрагментов. Каждое изменение сверяйте с метриками, а не с впечатлением от нескольких удачных диалогов.

Отдельно настройте мониторинг: логируйте запрос, найденные фрагменты и их оценки. Когда пользователь жалуется на неверный ответ, первым делом смотрите, был ли нужный документ в выдаче. Заведите регулярную переиндексацию и проверку, что обновлённые документы действительно попали в индекс. И не лечите retrieval промптом: просьба «отвечай точнее» не вернёт факт, которого в контексте нет.