Суть проблемы: модель не врёт, ей не дают правду
В индустрии принято считать, что галлюцинации Large Language Models (LLM) — это проблема «генерационного кирпича». Однако новое исследование из серии Enterprise Document Intelligence доказывает обратное: большинство галлюцинаций RAG (Retrieval-Augmented Generation) — это провалы поиска (retrieval failures). Модель честно отвечает на основе предоставленного контекста, но если этот контекст неверен или неполон, ответ будет ошибочным. Ключевой вывод: поиск решает, что модель может «придумать», потому что он определяет, что она видит.
Эксперимент: ответ оказался на 55-м месте
Авторы провели тест на реальном 55-страничном документе — NIST Cybersecurity Framework v1.1. Использовалась стандартная цепочка: эмбеддинг страниц через sentence-transformers (модель all-MiniLM-L6-v2), вопрос и ранжирование по косинусному сходству.
Вопрос: «Какие практики резервного копирования обеспечивают доступность данных после атаки ransomware?»
Результат: Правильный ответ (подкатегория PR.IP-4, стр. 41) оказался на 55-й позиции из 55. Более того, это была страница с наименьшим косинусным сходством. Слово «backup» присутствовало только в этой странице, но из-за усреднения векторов в эмбеддинге оно «потерялось» на фоне остальных слов вопроса.
Три сценария провала поиска
Исследование выделяет три конкретных типа ошибок, которые приводят к галлюцинациям. Ни одна из них не является ошибкой самой LLM:
- 1. Ответ не извлечен (Recall Failure): Правильный документ находится за пределами окна top-k. Модель, не видя ответа, генерирует правдоподобный, но вымышленный текст на основе своих весов. Это легко диагностировать: если ранг правильного документа > k, это провал поиска.
- 2. Извлечен неверный фрагмент: Страница, которая семантически близка, но не отвечает на вопрос, получает высокий рейтинг. В тесте первой оказалась категория PR.DS (защита данных), а не PR.IP-4 (резервное копирование). Модель цитирует реальный код NIST, но не по назначению, что создает иллюзию достоверности.
- 3. Ответ затерян в шумихе (Distractors): Правильный ответ есть в контексте, но рядом находятся похожие пункты (например, планы восстановления). Модель путает их, так как они делят общие слова. Увеличение количества извлеченных страниц (top-10 вместо top-5) усугубляет проблему, добавляя шум.
Почему это важно для инженеров
Попытки исправить галлюцинации через «генерационные ручки» (уменьшение temperature, ужесточение промптов, использование более крупных моделей) неэффективны, если корень проблемы в поиске. Увеличение размера эмбеддинг-модели не всегда помогает: более сложные модели могут даже хуже ранжировать «похожие, но неверные» контрольные точки на корпоративных текстах.
Ключевые метрики и инструменты
Для диагностики и исправления проблем с поиском авторы рекомендуют использовать следующие подходы и метрики:
| Параметр/Инструмент | Значение/Описание | Влияние на результат |
|---|---|---|
| Модель эмбеддинга | all-MiniLM-L6-v2 |
Базовая модель, показала уязвимость к усреднению ключевых слов. |
| Метрика ранжирования | Cosine Similarity | В данном случае провалилась, поставив правильный ответ на последнее место. |
| Альтернативный метод | Keyword Count (ключевые слова) | В тесте поднял правильный ответ на 1-е место, так как учитывает наличие слова «backup». |
| Объем документа | 55 страниц (NIST CSF v1.1) | Публичный стандарт, используемый как эталон для тестов. |
| Кодовая база | doc-intel/notebooks-vol1 | Открытый репозиторий с ноутбуками для воспроизведения эксперимента. |
Вывод: Чтобы устранить галлюцинации, нужно сначала убедиться, что система поиска (retrieval) доставляет модели именно тот фрагмент, который содержит ответ. Иначе модель будет «изобретать» правдоподобные ответы на основе неверных или неполных данных.
Источник: Towards Data Science ↗