RAG не сработал — но какой именно слой на самом деле отказал? Метод диагностики

Система RAG возвращает слабый, неверный, неполный или необоснованный ответ. Обычный диагноз — «поиск не сработал» или «модель галлюцинировала». Оба ярлыка слишком широки, чтобы быть полезными. Продакшн-конвейер RAG может дать сбой до поиска, во время поиска, при ранжировании, при сборке контекста, во время генерации или после генерации, когда проверяются доказательства и валидность.

Почему «RAG дал сбой» — это не диагноз

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

Поэтому неверный итоговый ответ не говорит, какой компонент дал сбой. Модель могла получить неверные доказательства. Она могла получить правильные доказательства в смеси с чрезмерным шумом. Доказательства могут быть корректными, но устаревшими. Источник мог вообще никогда не содержать ответ. Или модель могла проигнорировать вполне достаточный контекст.

Руководство OpenAI по RAG уже проводит фундаментальное различие между сбоем поиска и сбоем модели: система может предоставить неверный контекст или предоставить правильный контекст и всё равно сгенерировать неверный ответ. AWS аналогично разделяет оценку только поиска и оценку поиска с генерацией. Для диагностики в продакшне это различие следует развить дальше.

Стек сбоев RAG

Слой 1 — Покрытие источников: может ли система вообще ответить на это?

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

Метрика поиска не может восстановить информацию, которая никогда не была проиндексирована. Больший top-k не может извлечь документ, которого нет в конвейере. Если тест покрытия источников не проходит, правильное исправление — это приём данных, выбор источников, права доступа или явное поведение «невозможно ответить на основе доступных доказательств».

Слой 2 — Построение запроса: задала ли система корпусу правильный вопрос?

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

Запрос вроде «Применяется ли политика к подрядчикам в Германии после сентябрьского обновления?» содержит как минимум сущность, популяцию, юрисдикцию и временную границу. Переформулированный запрос, который становится «политика для подрядчиков», может извлечь семантически связанный текст, потеряв переменные, определяющие, действителен ли ответ.

Уровень 3 — Поиск кандидатов: попали ли релевантные доказательства в набор?

Поиск кандидатов — это прежде всего задача полноты. Диагностический вопрос пока не в том, оказался ли лучший результат на первом месте; а в том, появились ли релевантные доказательства где-либо в пуле кандидатов. Если известный правильный источник не появляется, следует исследовать индексацию, разбиение на фрагменты, эмбеддинги, лексическое сопоставление, метаданные, гибридный поиск, обработку языка, синонимы и расширение запроса.

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

Уровень 4 — Ранжирование и фильтрация: были ли правильные доказательства отброшены или погребены?

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

Поэтому отладка должна сохранять полный список кандидатов, а не только финальный top-k. Если эталонное доказательство было найдено на 18-м месте, а реранкер удалил его, исправление будет не таким же, как при промахе поиска.

Уровень 5 — Сборка контекста: стали ли полезные доказательства пригодным для использования контекстом?

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

Границы фрагментов особенно важны. Предложение может содержать правило, а следующее предложение — исключение. Если они индексируются отдельно и извлекается только первое, поисковик может выглядеть релевантным, тогда как собранный контекст становится вводящим в заблуждение.

Уровень 6 — Генерация: может ли модель правильно использовать правильные доказательства?

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

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

Уровень 7 — Атрибуция доказательств: действительно ли ответ подкреплён?

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

Поэтому оценка цитирования относится к этапу после генерации. AWS различает точность цитирования и покрытие цитирования: правильно ли цитируются процитированные отрывки и достаточно ли ответ подкреплён цитатами. В производстве поддержка на уровне утверждений полезнее, чем трактовка наличия любой цитаты как качества доказательств.

Уровень 8 — Актуальность и свежесть: были ли доказательства верны для этой версии реальности?

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

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

Самый быстрый метод изоляции: тест с оракульным контекстом

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

Последовательность диагностики в продакшене

Не меняйте три слоя одновременно

Распространённая ошибка отладки — менять эмбеддинги, размеры чанков, top-k, промпты и модель за одну итерацию. Если оценка улучшается, вы не знаете почему. Если ухудшается, вы не знаете, какое изменение вызвало регрессию.

Относитесь к отладке RAG как к экспериментальной диагностике: сохраняйте как можно большую часть конвейера неизменной и заменяйте один неопределённый компонент контролируемым входом. Эталонные документы изолируют поиск. Эталонные чанки изолируют выбор чанков. Фиксированный контекст изолирует генерацию. Фиксированная модель изолирует изменения поиска. Фиксированный корпус изолирует изменения приёма и индексации.

Матрица сбоев для типичных симптомов RAG

Измеряйте каждый слой метрикой, на которую он действительно может влиять

Правильный ответ всё ещё может скрывать дефект RAG

Обратная проблема также важна. Система RAG может выдавать правильный ответ, когда поиск сломан. Модель может уже знать ответ из обучения, вывести его из слабых доказательств или правильно угадать. Если оценка смотрит только на итоговый ответ, система может казаться здоровой, пока вопрос не дойдёт до информации, которая существует только в приватном корпусе.

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

Используйте конкурирующие гипотезы, а не любимое объяснение

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

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

Что изменило бы этот ответ?

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

Основной метод остаётся неизменным: определить компоненты, которые могут независимо изменить результат, построить контролируемые тесты, заменяющие неопределённые компоненты на заведомо исправные входные данные, и измерить каждый компонент с помощью доказательств, соответствующих этому слою.

Ограничения

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

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

Заключение

«RAG не сработал» должно быть началом расследования, а не выводом. Полезный диагноз определяет, не хватало ли системе доказательств, искала ли она неправильно, не смогла ли их извлечь, плохо ли их ранжировала, собрала ли непригодный контекст, сгенерировала ли неправильно, плохо ли атрибутировала утверждения или применила доказательства за пределами их границы применимости.

Практическое правило простое: заменяйте неопределённость контролируемыми доказательствами слой за слоем. Начните с теста с оракульным контекстом. Отделите оценку только поиска от оценки генерации. Сохраняйте полную трассировку. Затем исправьте компонент, который действительно дал сбой, вместо настройки всего стека RAG по интуиции.

Часто задаваемые вопросы

Глоссарий

Первоисточники и дополнительное чтение