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

RAG (Retrieval-Augmented Generation) подзывает внешнюю базу знаний к ответам LLM, обещая избавить модель от галлюцинаций. На практике 73% поломок RAG-систем происходят из-за плохого поиска, 40% пайплайнов вообще не могут извлечь нужные данные. Инженеры часто пытаются лечить симптомы — менять эмбеддинг-модель, увеличивать top-k, обновлять LLM. Но если в промпт изначально попал неподходящий контекст, сломан слой retrieval, а галлюцинация — следствие этой ошибки.

Исследование RAGGED вскрыло: LLaMA и Claude пикуют на отметке всего в 5 чанков, дальше качество стремительно падает. Claude показала наилучший результат с одним максимально точным фрагментом. Раздувать контекст до предела вредно.

Шесть точек отказа

1. Чанкинг уничтожает контекст — фиксированное разбиение по 512 токенов отделяет сущность от квалифицирующего предложения, чанк без заголовка теряет смысл, таблица из 200 строк превращается в шум. Решение: разбиение по структуре документа, перенос заголовков в каждый чанк, контекстные эмбеддинги. По данным Anthropic, они сокращают ошибки на 35%, с контекстным BM25 — на 49%, с реранкингом — на 67%.

2. Семантический разрыв — эмбеддинги не ловят намерение. Пользователь спрашивает «Как отменить подписку?», документ называется «Account Termination Policy». Решение: гибридный поиск (эмбеддинги + BM25 через Reciprocal Rank Fusion с k=60), переформулировка запроса, HyDE (поиск по гипотетическому ответу).

3. Рассогласование retrieval и генерации — увеличение top-k улучшает Hit@k, но качество ответа затем падает. Исследование Liu и соавт. «Lost in the Middle» показало, что модель лучше использует информацию в начале и конце контекста. Оптимальное значение top-k подбирают экспериментально; RAGGED показал: оптимум от k ≤ 1 до k ≥ 10. Пороговое значение recall 85% — ниже нужно чинить retrieval.

4. Multi-hop — RAG не умеет рассуждать по цепочке. Вопрос «Кто генеральный директор компании, которую приобрёл поставщик конкурента?» требует четырёх шагов поиска. Решение: итеративный (агентный) RAG или графовая память (Neo4j, Cognee, Microsoft GraphRAG). Цена — задержка и стоимость.

5. Нет понимания времени — индекс не знает, что документ устарел. Решение: фильтрация по метаданным, версионирование, автоматическая переиндексация, мониторинг дрейфа качества.

6. Разрешение сущностей — «Apple» (компания или фрукт?), «Иванов А.В.» и «А. Иванов» выглядят разными объектами. Решение: выделять сущности при индексации, строить связанный индекс, искать через граф.

Когда RAG не нужен

Запрос «покажи всех клиентов с риском оттока выше 0,7» — это SQL, а не поиск. RAG не умеет агрегаций, сортировки, фильтрации по числам. Нужны Text-to-SQL или семантический слой над хранилищем. Универсальные детекторы пропускают 43% вычислительных ошибок.

Диагностика: три метрики

Context Relevance ловит ошибки чанкинга и retrieval (вернулись не те фрагменты). Context Recall ловит пропуски (чанк с ответом не вернулся). Groundedness ловит галлюцинации несмотря на правильный контекст. Ключевой вопрос: сломан retrieval или генерация? Это разные инженерные проблемы с разными решениями.