Проблема: RAG отвечает на неправильный контекст
Стандартный подход к RAG (Retrieval-Augmented Generation) часто терпит неудачу не из-за плохих промптов, а из-за того, что модель получает неверный контекст. Автор статьи демонстрирует, что «наивный» RAG-конвейер ломается на четырех конкретных этапах, названных «кирпичами» (bricks). Каждый сбой приводит к уверенному, но неверному ответу, который можно исправить только на уровне архитектуры конвейера, а не через оптимизацию запроса.
1. Парсинг: таблица, превращенная в шум
При работе с отчетами, содержащими таблицы (например, World Bank Commodity Markets Outlook), стандартный парсинг в плоский текст разрушает структуру. Если строка с меткой (например, Henry Hub) и значением (например, 3.5) попадают в разные чанки из-за фиксированного размера, модель не может связать их.
- Результат наивного RAG: «not stated in these lines» (уверенность 0.00).
- Решение: Реляционный парсинг, возвращающий
line_dfс координатами bounding box. Это сохраняет связь между меткой и значением. - Результат улучшенного RAG: «$3.5 per mmbtu» (уверенность 0.99).
2. Вопрос: лексический разрыв
Пользовательские запросы часто используют термины, отсутствующие в документе. В примере с NIST SP 800-207 пользователь спрашивает о «pillars» (опорах), но документ использует термин «tenets» (принципы). Наивный поиск по ключевым словам не находит совпадений.
- Результат наивного RAG: «the specific pillars are not listed» (уверенность 0.20).
- Решение: Предварительная обработка вопроса (question parsing) для нормализации и расширения синонимов (pillars → tenets/principles).
- Результат улучшенного RAG: Перечисление всех семи принципов (уверенность 0.95).
3. Поиск: ответ ниже порога отсечки
В больших документах, таких как NIST Cybersecurity Framework 2.0, термин может встречаться часто, но определение находится в одном конкретном разделе. Наивный поиск по косинусному сходству или частоте ключевых слов возвращает релевантные, но не определяющие страницы, которые выбиваются из топ-k.
- Результат наивного RAG: «not defined in these lines» (уверенность 0.10).
- Решение: Маршрутизация на основе структуры документа (оглавления). LLM анализирует оглавление, чтобы направить поиск в нужный раздел (например,
CSF Profiles). - Результат улучшенного RAG: Полное определение с цитированием (уверенность 0.95). На каталогах из 400+ страниц этот метод сохраняет точность, в то время как частотный поиск деградирует.
4. Генерация: отсутствие самопроверки
Последний этап — генерация ответа. Наивные модели часто выдают уверенные ответы, даже если контекст неполный или противоречивый. Улучшенный конвейер требует от модели не просто ответа, а структурированного вывода с проверкой фактов и указанием источников.
Сравнение результатов
| Этап (Кирпич) | Проблема наивного RAG | Решение (Context Engineering) | Результат (Уверенность) |
|---|---|---|---|
| Парсинг | Разрыв связи в таблицах | Реляционный парсинг (bounding boxes) | 0.99 (верно) |
| Вопрос | Лексический разрыв (синонимы) | Расширение запроса (synonym expansion) | 0.95 (верно) |
| Поиск | Ответ ниже top-k cutoff | Рутинг по оглавлению/структуре | 0.95 (верно) |
| Генерация | Уверенная галлюцинация | Структурированный вывод с проверкой | Высокая точность |
Ключевой вывод: чтобы устранить галлюцинации в RAG, необходимо внедрять «кирпичи» контекстной инженерии на каждом этапе конвейера, а не полагаться только на оптимизацию промптов.
Источник: Towards Data Science ↗