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

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

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

Главный вывод: чинить нужно retrieval

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

Чтобы построить надежную систему, нужно уметь распознавать шесть типовых точек отказа: 

• некорректный чанкинг

• семантический разрыв

• рассогласование между поиском и генерацией

• сложные multi-hop запросы

• устаревшие данные в базе и ошибки разрешения сущностей. 

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

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

Вторая проблема — слепая вера в то, что «продвинутый поиск решит все беды». Да, если заменить классический поиск по ключевым словам (BM25) на умный векторный ColBERT, точность поиска (recall) подскочит на 15–19 пунктов. Но вот итоговый ответ модели на сложных вопросах улучшится всего на 4 пункта. Почему? Потому что поиск сработал отлично, но модель просто «не осилила» сложную логику и запуталась в рассуждениях. Улучшение поиска помогает, но упирается в потолок возможностей самой LLM.

Отказ 1. Чанкинг уничтожает контекст

Это первопричина большинства сломанных RAG-систем. Три механизма:

• Разрыв границы. Фиксированное разбиение по 512 токенов отделяет сущность от предложения, которое её квалифицирует. Условие контракта попадает на стык двух чанков: retrieval возвращает оба, а модель видит половину факта в каждом.

• Потеря контекста. Чанк без заголовка раздела теряет смысл. Фраза «Он составляет 12%» не говорит, о чём речь, если заголовок остался в предыдущем чанке.

• Сплющивание таблиц. Таблица на 200 строк, разрезанная посреди строки, превращается из структурированных данных в шум. На финансовых документах это классический способ сломать систему.

Маленькие чанки дают лучшую точность retrieval, но уничтожают контекст; большие сохраняют контекст, но размывают точность.

Что работает.

• Разбиение по структуре документа: границы заголовков разделов, абзацев и таблиц, даже если чанки получаются разной длины.

• Перенос заголовков родительских разделов в каждый дочерний чанк.

• Отдельный конвейер извлечения таблиц, а не обычный текстовый сплит.

Перед индексацией модель генерирует для каждого чанка короткое пояснение его места в документе, например название компании и период, о котором идёт речь. По данным Anthropic, контекстные эмбеддинги сокращают число неудачных извлечений на 35%; вместе с контекстным BM25 — на 49%; с добавленным реранкингом — на 67%. 

Отказ 2. Семантический разрыв: близость эмбеддингов не равна релевантности

Пользователь спрашивает: «Как отменить подписку?» В базе знаний документ называется «Account Termination Policy». Между вопросом на действие и регламентом нет смысловой близости в пространстве эмбеддингов, хотя ответ в этом документе. Расстояние между векторами не передаёт намерение.

Типичные признаки:

• По запросу с конкретным ID клиента возвращается смысловой парафраз, а не документ с этим ID.

• На запрос «Не работает X» приходит «Возможности X», а не раздел с диагностикой.

• Технический запрос с аббревиатурами теряет смысл, если эмбеддинг-модель не дообучена на домене.

Что работает:

Гибридный поиск. Плотный поиск (эмбеддинги) комбинируется с разреженным (BM25, ключевые слова), а результаты объединяются через Reciprocal Rank Fusion. В RRF каждый документ получает сумму 1 / (k + rank) по всем спискам, где k — константа, обычно 60 (значение из исходной работы Cormack и соавт., 2009). Точные ID и аббревиатуры ловит BM25, перефразированные запросы — эмбеддинги.

Переформулировка запроса перед поиском. LLM переписывает вопрос пользователя на язык документов: «Как отменить подписку» превращается в запрос про расторжение и прекращение обслуживания.

HyDE (Hypothetical Document Embeddings). Модель сначала генерирует гипотетический ответ, и поиск идёт по эмбеддингу этого ответа, а не вопроса: ответ стилистически ближе к документам, чем вопрос.

Отказ 3. Рассогласование retrieval и генерации

Качество retrieval и качество ответа связаны немонотонно. Увеличение top-k улучшает Hit@k, но качество ответа достигает максимума на средней глубине выдачи и затем падает. Причина в том, что при десяти чанках вместо двух нужных сигнал разбавляется: модель усредняет по всему контексту и выдаёт посредственный ответ.

К этому добавляется проблема позиции. В работе Liu и соавт. «Lost in the Middle» показано, что качество работы модели зависит от положения релевантной информации в длинном входе: лучше всего она используется в начале и конце контекста, а в середине качество заметно падает даже у моделей с длинным контекстом. Значит, порядок чанков в промпте важен, и реранкинг решает не только точность, но и размещение.

Практический вывод: ставить top-k = 10 по умолчанию не нужно. Оптимальное значение подбирают экспериментально на своих данных и своей модели, как показал RAGGED: у разных моделей оптимум различается от k ≤ 1 до k ≥ 10.

Если retrieval не возвращает нужный фрагмент, качество генерации ограничено сверху, и сменой модели это не исправить. В инженерных руководствах встречается порог recall около 85%, ниже которого чинить нужно retrieval.

Отказ 4. Multi-hop: RAG структурно не умеет рассуждать по цепочке

Стандартный RAG извлекает информацию независимо по каждому запросу. Он не умеет выстраивать цепочку рассуждений по нескольким документам.

Пример вопроса: «Кто генеральный директор компании, которую приобрёл поставщик нашего основного конкурента?» Для ответа нужно:

1. Найти основного конкурента.

2. Найти его поставщика.

3. Найти факт приобретения.

4. Найти директора приобретённой компании.

Каждый промежуточный факт лежит в разных документах, а связь между ними в эмбеддингах не записана. За один проход «разрезать и векторизовать» такой вопрос не решает. Даже лучший retriever на многошаговых вопросах даёт лишь 4 пункта F1 при 15 пунктах recall, потому что узким местом остаётся рассуждение.

Что работает.

• Итеративный (агентный) RAG. Несколько шагов retrieval, на каждом из которых LLM планирует следующий запрос, исходя из найденного.

• Графовая память. Сущности и связи индексируются как граф (Neo4j, Cognee, Microsoft GraphRAG), и многошаговый вопрос превращается в обход графа.

Цена такого решения — задержка и стоимость: каждый шаг цепочки это отдельный вызов модели и отдельный поиск, а ошибка на раннем шаге искажает все последующие.

Отказ 5. Нет понимания времени

Индекс RAG не знает, что документ устарел. Он живёт своей жизнью, и типичные последствия такие:

• Обновился тариф, старый документ остался в индексе, и пользователь получает прежнюю цену.

• Появился новый продукт, его нет в эмбеддингах, и запросы уходят на похожий старый.

• Изменилась политика, retrieval возвращает обе версии, и модель либо усредняет, либо выбирает произвольно.

Что работает.

• Фильтрация по метаданным: дата обновления, источник, тип документа.

• Версионирование документов в индексе.

• Автоматическая переиндексация при изменении документа.

• Мониторинг качества с сигналами о дрейфе retrieval при обновлении корпуса.

Эта проблема напрямую связана с ценой ошибки: инструкционная галлюцинация в поддержке может юридически обязывать компанию. В деле Air Canada чат-бот сообщил пассажиру условия, расходящиеся со страницей правил, и трибунал присудил компенсацию; причина там была иной, чем устаревший индекс, но механизм последствий тот же. 

Отказ 6. Разрешение сущностей: одна сущность, разные слова

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

«Apple» в финансовом контексте — компания, в продуктовом — фрукт, и BM25 без контекста возвращает оба значения; эмбеддинг-модель без дообучения — тоже. Записи «Клиент Иванов А.В.», «Иванов Алексей» и «А. Иванов» для RAG выглядят тремя разными объектами, хотя это один человек.

Что работает. Выделять сущности при индексации, строить связанный индекс сущностей, искать через сущность и агрегировать по графу. Это дороже обычного векторного поиска, но на задачах «всё, что мы знаем о клиенте X» альтернативы нет.

Структурированные запросы: когда RAG не тот инструмент

Запрос «покажи всех клиентов в третьем квартале с риском оттока выше 0,7» — это SQL, а не поиск по документам. RAG не умеет агрегаций, сортировки, фильтрации по числовым полям и соединений между источниками.

Типичная ошибка: команда строит RAG поверх структурированных данных и удивляется, почему «простые» вопросы ломаются. Ответ: инструмент выбран неверно. Для числовых запросов нужны Text-to-SQL или семантический слой над хранилищем. Заодно это снимает целый класс вычислительных галлюцинаций, которые ловятся хуже всего: универсальные детекторы пропускают 43% вычислительных ошибок, потому что для их поиска нужна арифметическая проверка по таблицам. Эта цифра подкреплена небольшой проверкой на 200 утверждениях, поэтому используйте её как ориентир порядка величины.

Диагностика: как измерить, что именно сломано

Без метрик невозможно определить, где ломается конвейер. Три метрики разделяют отказы по слоям:

• Context Relevance ловит отказы чанкинга и retrieval: вернулись не те фрагменты или граница чанка проходит не там.

• Context Recall ловит пропуски: чанк, содержащий ответ, вообще не вернулся.

• Groundedness ловит отказы генерации: модель галлюцинирует, несмотря на правильный контекст.

Возьмите выборку реальных запросов, пусть люди отметят, содержат ли извлечённые чанки информацию для ответа. Доля положительных ответов и есть retrieval recall на вашей выборке.

Ключевой диагностический вопрос: отсутствие правильного ответа (EM = 0) вызвано сбоем retrieval или сбоем генерации при правильном retrieval? Это принципиально разные инженерные проблемы с разными решениями. Если нужного фрагмента нет в контексте, менять модель бессмысленно.

Метрики на основе LLM-судьи требуют многих вызовов модели на каждый запрос выборки. Если для прогонов оценки нужно сравнивать несколько моделей, удобен единый доступ: API Спешу АИ — это один ключ к трём сотням моделей вместо отдельных договорённостей с каждым вендором, без настройки прокси, с рублёвыми счетами и закрывающими документами. 

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

Что работает в 2026 году: производственный стек

Чанкинг.

• Разбиение по семантическим границам, а не по числу токенов.

• Заголовки родительских разделов в каждом дочернем чанке.

• Таблицы извлекаются отдельным конвейером, а не сплющиваются.

• Чанки переменной длины допустимы.

Retrieval.

• Гибридный поиск: плотный + BM25 + слияние RRF.

• Переформулировка запроса или HyDE.

• Реранкинг кросс-энкодером после первичной выдачи.

• Фильтрация по метаданным: дата, источник, тип документа.

Многошаговые вопросы.

• Итеративный RAG с планированием следующего запроса.

• GraphRAG для связанных сущностей (Microsoft GraphRAG, Cognee).

Оценка.

• Тройка метрик: Context Relevance, Context Recall, Groundedness.

• Логирование retrieval в продакшне: какие чанки возвращались на какой запрос.

• Оповещения о дрейфе retrieval при обновлении документов.

Структурированные данные.

• Text-to-SQL для числовых запросов вместо RAG.

Так все же — RAG умер?

RAG остаётся доминирующей архитектурой для опоры LLM на внешние знания. Устарел наивный конвейер из туториалов 2023 года.

Разница между ними такая:

• Наивный RAG 2023. Разбиение по 512 токенов, эмбеддинги, косинусная близость, top-5 в промпт.

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

Между ними — годы итераций в продакшне и множество разборов отказов, главный итог которых: узкое место в retrieval, а не в генерации.

Частые ошибки при отладке RAG

• Менять модель до замера retrieval. Если нужный чанк не вернулся, более сильная LLM ответит так же неверно, только увереннее.

• Увеличивать top-k «на всякий случай». По данным RAGGED, у ряда моделей качество после небольшого k падает, а позиционный эффект «потерянной середины» усугубляет проблему.

• Строить RAG поверх таблиц и метрик. Агрегации и фильтры по числам решает SQL; поиск по документам даёт для них непредсказуемые результаты.

• Оценивать только итоговый ответ. Метрика обоснованности проходит, если ответ опирается на устаревший или неверный чанк; регрессию retrieval она не покажет.

Частые вопросы

Почему RAG выдаёт неверные ответы, хотя нужный документ есть в базе? Чаще всего нужный фрагмент не попал в контекст: чанк разрезан по границе, лишён заголовка или не найден из-за семантического разрыва между вопросом и текстом документа. Проверьте Context Recall на выборке реальных запросов: если нужный чанк не возвращается, причина в retrieval, а не в модели.

Как выбрать оптимальный top-k для RAG? Подбирайте экспериментально на своих данных и своей модели. В исследовании RAGGED оптимум у разных моделей различался от k ≤ 1 до k ≥ 10, а у части моделей качество после небольшого k падало. Значение 10 по умолчанию — не гарантия качества.

Чем гибридный поиск лучше векторного? Плотный поиск находит перефразированные запросы, но может терять точные идентификаторы и аббревиатуры. BM25 точно находит ключевые слова, но не понимает парафраз. Слияние через RRF объединяет сильные стороны обоих подходов и обычно повышает recall.

Нужен ли RAG для запросов к таблицам и метрикам? Нет. Агрегации, сортировки и фильтры по числовым полям решает SQL, поэтому для таких вопросов используют Text-to-SQL или семантический слой. RAG остаётся инструментом для вопросов по текстовым документам.

Заключение

Отказы RAG диагностируются по слоям: сначала измерьте, возвращает ли retrieval нужный фрагмент, и только потом решайте, нужна ли другая модель. Начните с структурного чанкинга, гибридного поиска и реранкинга, добавьте фильтрацию по дате и логирование извлечённых чанков. Для прогонов оценки с несколькими моделями используйте единый доступ через API.