На мой взгляд, Это самый важный раздел первой главы. Именно после него у читателя должна исчезнуть иллюзия, что RAG гарантирует правильные ответы. Большинство новичков думают:
«Если добавить поиск по документам, галлюцинации исчезнут.»
Это неверно.
RAG значительно снижает вероятность ошибок, но не устраняет их полностью. Более того, он создает новые классы ошибок, которых вообще не существовало у «голой» LLM.
Именно этому посвящен следующий раздел.
После знакомства с архитектурой Retrieval-Augmented Generation может возникнуть ощущение, что проблема качества ответов уже полностью решена.
Кажется, что логика очень проста.
- Пользователь задает вопрос.
- Система находит нужные документы.
- Документы передаются языковой модели.
- Модель отвечает.
Если каждый этап работает правильно, то и ответ должен быть правильным.
К сожалению, реальные системы работают значительно сложнее.
Даже если все компоненты RAG реализованы корректно, ответ все равно может оказаться неверным, неполным или вводящим пользователя в заблуждение.
Чтобы понять причины, необходимо рассматривать RAG не как один алгоритм, а как длинную цепочку независимых этапов.
Цепочка формирования ответа
Упростим архитектуру до последовательности основных действий.
Документы
│
▼
Разбиение (Chunking)
│
▼
Embedding
│
▼
Индекс
│
▼
Поиск
│
▼
Отбор результатов
│
▼
Формирование контекста
│
▼
LLM
│
▼
Ответ
Каждый блок получает данные от предыдущего.
И каждый блок способен внести собственную ошибку.
Очень важно понять одну мысль.
LLM отвечает только на основании той информации, которую получила.
Если ошибка произошла раньше, модель зачастую уже не может её исправить.
Именно поэтому инженеры, занимающиеся RAG, говорят:
Garbage In — Garbage Out.
Если на вход генератору поступил плохой контекст, хороший ответ становится практически невозможным.
Ошибка №1. Нужного документа вообще нет
Начнем с самого очевидного случая.
Предположим, пользователь спрашивает:
Как настроить двухфакторную аутентификацию?
Но документация компании вообще не содержит такой инструкции.
В этом случае происходит следующее.
Вопрос
↓
Поиск
↓
Ничего не найдено
↓
LLM пытается ответить самостоятельно
Если приложение никак не контролирует этот сценарий, модель начинает использовать собственные знания.
Иногда они совпадают с корпоративными правилами.
Иногда — нет.
В результате пользователь получает убедительный, но неверный ответ.
Почему это опасно
Представим внутреннюю документацию банка.
Вопрос:
Какой срок хранения резервных копий?
В документации такого раздела нет.
LLM может написать:
Обычно резервные копии хранятся 30 дней.
Хотя внутри компании используется правило:
180 дней.
Формально модель не соврала.
Она ответила на основе общих знаний.
Но для конкретной организации ответ оказался неправильным.
Как обнаружить проблему
Хорошая RAG-система должна понимать разницу между двумя ситуациями.
Первая:
Документ найден.
Вторая:
Документ отсутствует.
Это разные случаи.
Если ничего не найдено, система должна честно сообщить пользователю.
Например:
В доступной базе знаний отсутствует информация по этому вопросу.
Такой ответ намного полезнее красивой галлюцинации.
Ошибка №2. Документ существует, но поиск его не нашел
Это гораздо более интересная проблема.
Представим, что инструкция существует.
Но пользователь спрашивает:
Как отключить автоматическое архивирование?
Документ называется:
Storage Lifecycle Management Policy.
Ни слова «архивирование» в названии нет.
Если поиск реализован плохо, документ может вообще не попасть в результаты.
Получится следующая ситуация.
Документ существует
↓
Поиск его пропустил
↓
LLM его не увидела
↓
Ответ оказался неправильным
Очень важно понимать:
Модель не может использовать документ, которого она не получила.
Для неё этот документ просто не существует.
Почему это происходит
Причин может быть много.
Например:
- слабая embedding-модель;
- неудачная формулировка запроса;
- слишком маленький Top-K;
- плохой индекс;
- неверная фильтрация.
Все эти темы мы подробно рассмотрим в следующих главах.
Пока достаточно запомнить главное.
Отсутствие документа в контексте почти всегда означает отсутствие этой информации для модели.
Ошибка №3. Документ найден, но не попал в Top-K
Представим огромную базу знаний.
Поиск нашел двадцать подходящих документов.
Но система передает модели только пять.
Получается ситуация.
Найдено:
20 документов
↓
Передано:
5 документов
↓
Правильный оказался шестым
Он существует.
Поиск его обнаружил.
Но модель его не увидела.
Это одна из самых распространенных ошибок современных RAG.
Почему нельзя передать все документы
Кажется очевидным:
Раз найдено двадцать документов, давайте отправим все двадцать.
К сожалению, здесь возникает ограничение языковых моделей.
Контекстное окно конечно.
Каждая модель может обработать только определенное количество токенов за один запрос.
Поэтому приходится выбирать.
Именно отсюда появляется понятие:
Top-K Retrieval
Мы сознательно ограничиваем число документов.
Следовательно, возникает новая задача:
Какие именно документы являются наиболее полезными?
Ответ далеко не всегда очевиден.
Ошибка №4. Документ найден, но содержит слишком много лишней информации
Представим PDF объемом 600 страниц.
Поиск вернул именно его.
На первый взгляд всё отлично.
Но проблема в том, что нужный ответ находится на странице 487.
Если системе приходится передавать весь документ, возникают сразу несколько проблем.
Во-первых, он может просто не поместиться в контекстное окно.
Во-вторых, даже если поместится, языковой модели придется анализировать огромное количество нерелевантного текста.
Представьте, что вас попросили найти один абзац в книге объемом тысячу страниц, но не дали ни оглавления, ни номера страницы.
Это возможно.
Но значительно сложнее.
Именно поэтому современные RAG почти никогда не работают с целыми документами.
Они работают с фрагментами документов.
Мы называем их чанками (chunks).
Глава о чанкинге станет одной из самых больших в книге именно потому, что от него напрямую зависит качество поиска.
Ошибка №5. Найден правильный фрагмент, но он оказался вырван из контекста
Представим документ.
Шаг 1.
Создайте резервную копию базы данных.
Шаг 2.
Остановите сервер.
Шаг 3.
Установите обновление.
Шаг 4.
Запустите проверку целостности.
Шаг 5.
Перезапустите сервис.
Предположим, система разбила документ следующим образом.
Первый чанк:
Шаг 1.
Создайте резервную копию базы данных.
Шаг 2.
Остановите сервер.
Второй чанк:
Шаг 3.
Установите обновление.
Шаг 4.
Запустите проверку целостности.
Пользователь спрашивает:
Что нужно сделать перед установкой обновления?
Поиск может вернуть только второй чанк.
Но в нем отсутствует самая важная информация.
Создайте резервную копию.
Формально поиск сработал правильно.
Он действительно нашел раздел про установку обновления.
Но документ был разрезан настолько неудачно, что смысл оказался потерян.
Это одна из причин, по которой выбор стратегии чанкинга часто оказывает большее влияние на качество RAG, чем выбор конкретной LLM.
Инженерный взгляд
Из этого раздела следует очень важный вывод.
Когда пользователь говорит:
«RAG ответил неправильно.»
Это почти никогда не является достаточным описанием проблемы.
Инженер должен задать следующий вопрос:
На каком этапе цепочки возникла ошибка?
Именно это отличает инженерный подход от простого использования библиотек.
Вместо поиска «волшебной модели» мы анализируем всю систему целиком: от подготовки документов до формирования финального промпта.
В следующем разделе мы продолжим этот разбор и рассмотрим ошибки, возникающие после того, как нужный документ уже успешно найден. Как ни парадоксально, даже в этом случае модель все еще может дать неправильный ответ. Именно здесь появляются такие понятия, как reranking, context saturation и lost in the middle — эффекты, которые оказывают огромное влияние на качество современных RAG-систем.