1.7 Галлюцинации: когда модель уверенно врёт

Мы разобрали, как модель генерирует текст: шаг за шагом, выбирая следующее слово на основе вероятностей. Но из этого механизма вытекает фундаментальная особенность, о которой нельзя молчать.

Что такое галлюцинация?

Галлюцинация

это когда модель генерирует утверждение, которое звучит правдоподобно, но не соответствует фактам, не следует из контекста или даже противоречит здравому смыслу.

Модель может

· Придумать несуществующую цитату из книги, которой вы её спросили.

· Назвать неверную дату исторического события с полной уверенностью.

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

· Описать функциональность API, которого никогда не существовало.

Почему это происходит?

Не потому, что модель «врет» в человеческом смысле. У неё нет намерения обманывать. У неё вообще нет намерений.

Причина - в самой природе генеративного трансформера:

Вероятностная природа

Модель не хранит «базу фактов». Она хранит статистику - какие последовательности токенов с какой вероятностью встречались в обучающих данных. Когда она предсказывает следующее слово, она выбирает вариант, который статистически правдоподобен. Но «правдоподобно» не равно «истинно».

Отсутствие референции

Модель не имеет доступа к «источнику истины». Она не может «посмотреть в энциклопедию» во время генерации (если только вы не добавили RAG - Retrieval-Augmented Generation – Поиск и генерация). Она работает только с тем, что у неё есть в весах и в контекстном окне. Если нужной информации нет, она не скажет «я не знаю», а сгенерирует наиболее вероятное продолжение - которое может оказаться вымыслом.

Компрессия знаний

Обучение модели

это сжатие триллионов токенов в миллиарды параметров. Как в любом сжатии, часть информации теряется. Модель «запоминает» общие закономерности, но может забыть (или смешать) редкие детали. Когда её спрашивают о таком редком факте, она «восстанавливает» его по аналогии - и часто ошибается.

Соблазн угодить

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

Как снижать галлюцинации по степени надёжности

Инженерный взгляд: это не баг, это особенность архитектуры

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

Их можно снижать, но нельзя устранить полностью:

Увеличением контекста

Чем больше релевантной информации вы дадите модели в промте, тем меньше ей придется «додумывать».

RAG (Retrieval-Augmented Generation)

Подставляйте в контекст факты из надёжных источников (баз знаний, документов) перед генерацией.

Дообучением

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

Температурой и Top-P

Снижение «креативности» (температура → 0) уменьшает вероятность выбора неожиданных, а значит, потенциально ложных вариантов.

Ансамблями

Спросить одну и ту же модель несколько раз с разными настройками или несколько разных моделей - и сравнить ответы.

Что это значит для вас

Если вы строите систему, где фактические ошибки недопустимы (медицина, юриспруденция, финансы), вы не можете полагаться на одну LLM в чистом виде. Вам нужны дополнительные слои: проверка фактов, RAG, контрольные модели-критики, человеческая валидация.

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

1.8 RAG: как модель не выдумывает факты

В разделе 1.7 мы выяснили, что галлюцинации - фундаментальное свойство генеративных моделей. Но их можно снижать. Самый эффективный способ - RAG (Retrieval-Augmented Generation). Однако RAG не устраняет галлюцинации полностью - он лишь заменяет одни их источники на другие: вместо выдумывания из памяти модель начинает ошибаться в извлечении, ранжировании или игнорировании найденных документов.

Проблема

Модель знает только то, что выучила во время обучения (данные 2024–2025). Она не знает ваш договор, переписку или свежие новости.

Идея RAG

Перед тем как ответить, модель идёт в базу знаний (векторную БД), находит там релевантные документы и подставляет их в контекст. Ответ строится не на памяти модели, а на фактах из ваших документов. Однако важно понимать: RAG не переучивает модель - он лишь временно докладывает документы в окно контекста, поэтому после ответа модель «забывает» эти данные.

Как именно модель ищет документы? Каждый документ (или его фрагмент) превращается в вектор - эмбеддинг. Эмбеддинги устроены так, что семантически похожие тексты оказываются рядом в пространстве. Запрос пользователя тоже превращается в вектор, и база данных найдет документы с самыми близкими векторами. Для этого используют специальные эмбеддинг-модели (например, intfloat/multilingual-e5-large), которые обучаются максимально точно отражать смысл текста в векторе.

Семантический поиск

это как раз то, что здесь описано. Поиск по смыслу, а не по словам («автомобиль» найдёт «машина», «транспортное средство» и «железный конь»). В отличие от лексического поиска (как Ctrl+F), он работает через эмбеддинги. Именно благодаря ему RAG понимает, какие документы реально релевантны запросу, даже если слова не совпадают буквально.

Критический нюанс

размер фрагмента (chunk size) при индексации сильно влияет на качество - слишком короткие чанки теряют контекст, слишком длинные размывают релевантность.

Как это работает (метафора)

Представьте, что вы сдаёте экзамен по открытой книге. Модель без RAG - это студент, который учил билеты год назад и всё забыл. Модель с RAG - это студент, который открывает книгу, находит нужную страницу и читает ответ с неё. Но даже с открытой книгой студент может прочитать не тот параграф - поэтому критически важна гигиена данных: мусор в базе знаний ведёт к мусору в ответе. Качество индексации и чанкинга важнее самой модели.

Почему RAG не заменяет память модели

· RAG требует хорошего поиска. Если поиск нашёл не тот документ - ответ будет неверным.

· RAG не добавляет «понимания». Модель может прочитать правильный документ, но интерпретировать его неправильно.

· RAG медленнее (поиск в БД + генерация). На практике латентность RAG-пайплайна часто складывается из трёх этапов: эмбеддинг запроса (десятки мс), поиск по индексу (единицы-сотни мс) и генерация LLM (секунды).

Когда RAG обязателен

· Работа с вашими документами (двойник, корпоративный чат-бот)

· Актуальные данные (новости, курс валют)

· Ситуации, где галлюцинации недопустимы (юриспруденция, медицина)

Есть и обратная сторона

RAG бесполезен для задач, требующих обобщения знаний со всего корпуса документов (например, «какие основные тренды были во всех наших договорах за 5 лет?») - здесь поиск по отдельным чанкам принципиально не работает, нужны другие подходы.

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

С точки зрения бизнеса, RAG - это единственный способ сделать LLM аудитируемой: вы всегда можете посмотреть, на какой документ ссылалась модель, и проверить факт, тогда как при дообучении (fine-tuning) факты «вшиваются» в веса и становятся непроверяемыми.

Для регуляторики (GDPR, HIPAA, персональные данные) RAG безопаснее дообучения, потому что документы не покидают вашу базу знаний - модель только читает их в рантайме, а не запоминает навсегда.

Самый недооценённый факт

RAG резко снижает стоимость эксплуатации - обновить документы в векторной БД стоит копейки и не требует переобучения модели за десятки тысяч долларов, как в случае с fine-tuning.

Инженерный вывод

Чистая LLM без RAG - это экзамен без книг. Хорошо для творчества, плохо для фактов. RAG - это открытая книга. Медленнее, но честнее. На практике гибридные системы (RAG + дообучение на фактах) дают лучший результат, но стоят дороже.

Чек-лист: когда RAG работает (а когда - нет)

RAG - не панацея. Есть задачи, где он обязателен, есть - где бесполезен, а есть - где даже вреден.

Главное ограничение

RAG не добавляет «понимания». Если поиск нашёл не те документы, модель сгенерирует ответ на их основе - и это может быть хуже, чем галлюцинация. Потому что у модели будет ложное чувство опоры.

Правило

RAG - это не «улучшатель модели». Это архитектура. Если у вас нет качественного поиска - не будет и качественного RAG.

Что делать, если RAG не помог (три следующих шага)

Вы настроили RAG, но модель всё равно галлюцинирует или отвечает невпопад. Что проверять?

Шаг 1. Диагностика поиска (самое частое узкое место)

Вывод RAG

«Я нашёл 5 фрагментов». Откройте их вручную. Релевантны ли они? Если нет - проблема не в модели, а в эмбеддерах или чанкинге.

Чанки (фрагменты текста) слишком большие → модель не удерживает внимание, теряет факты в длинном тексте.

Чанки слишком маленькие → потерян контекст, фрагмент вырван из общего смысла.

Эмбеддер не понимает язык/домен → берите multilingual-e5-large или дообучайте свой.

Шаг 2. Reranking (двухпроходный поиск)

Сначала находим 20–50 фрагментов быстрым векторным поиском. Потом пропускаем их через модель-кросс-энкодер (медленную, но точную), которая переранжирует и оставляет 3–5 самых релевантных. Это стандарт для серьёзных RAG-систем (например, Cohere Rerank, BGE-reranker).

Шаг 3. Порог уверенности и fallback

Если максимальное сходство найденного фрагмента ниже порога (например, 0.7) - модель должна сказать «не знаю», а не пытаться ответить. Добавьте в промпт:

«Если в найденных документах нет прямого ответа на вопрос - скажи: "Информация не найдена. Уточните запрос". Не додумывай.»

Это снизит галлюцинации ценой увеличения отказов. Но в юридических, медицинских, финансовых сценариях отказ лучше, чем ложь.

Эволюция RAG: графы и гибридный поиск

Классический RAG (векторный поиск + LLM) хорошо работает, когда запрос можно закрыть одним-двумя фрагментами документа. Но есть задачи, где важны не просто похожие куски текста, а цепочки связей.

Примеры таких запросов

«Какие компоненты нашей системы зависят от сервиса платежей?»

«Кто тестировал модуль, который упал вчера на проде?»

«Какие контракты связывают поставщика X с нашей компанией через других юрлиц?»

Векторный поиск ответит на них плохо. Потому что нужные факты разбросаны по разным документам, а связь между ними не выражена явно в тексте.

Паровозик знаний ( GraphRAG )

Идея

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

Пример:

запрос «Кому писать, если упал платёжный шлюз?»

Стартуем от сущности «платёжный шлюз».

Идём по связи «используется в» → «модуль оплаты».

От модуля по связи «отвечает за» → «тимлид Иванов».

От Иванова по связи «подписан на» → канал оповещений.

LLM получает не разрозненные цитаты, а связный подграф - и может дать точный, обоснованный ответ.

GraphRAG даёт выигрыш в точности на сложных, многозвеньевых запросах (multi-hop) до 50–70% по сравнению с классическим RAG. Но требует значительно больших усилий на внедрение (строить граф, поддерживать его актуальность, настраивать обход).

Гибридный поиск и реранкинг (без графов, но проще)

Если строить граф пока не нужно, но точности векторного поиска не хватает - можно усилить классический RAG без перехода к графу.

Гибридный поиск

комбинация BM25 (точный поиск по словам, как в старых поисковиках) и векторного (похожий смысл). BM25 ищет «инвойс AС-457», векторный - «документ про задержку оплаты». Выбор лучшего из двух или их взвешенная сумма дают более стабильный результат.

Ретривер

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

Реранкинг (переранжирование)

сначала ретривер быстро находит 20–50 кандидатов (дешёво, неточно), а маленькая модель-кросс-энкодер (медленно, дорого) пересортировывает и оставляет топ-3–5 самых релевантных.