Почему LLM «придумывает» факты: механика галлюцинаций без магии

MAATRIX

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

Что модель на самом деле делает, когда «отвечает»

Языковая модель — это функция, которая на входе получает последовательность токенов (кусочков слов) и на выходе выдаёт распределение вероятностей: какой токен должен идти следующим. Дальше из этого распределения выбирается один токен (самый вероятный при низкой temperature, или один из нескольких вероятных при более высокой), он приклеивается к тексту, и процесс повторяется — снова считается распределение вероятностей уже для нового, более длинного текста. Весь ответ — это цепочка таких локальных решений «что вероятнее всего идёт дальше», а не единый акт «вспомнил и сказал».

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

Отсюда ключевой вывод: с точки зрения самого механизма генерации у модели нет разницы между «я это точно знаю» и «я сейчас это придумываю». И то и другое — один и тот же процесс предсказания токена. Разница только в том, насколько уверенно (с какой вероятностью) конкретный токен выбирается — но высокая уверенность не гарантирует фактическую правильность, она лишь показывает, что похожий паттерн часто встречался при обучении.

Почему нет кнопки «я не знаю» по умолчанию

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

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

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

Почему галлюцинации сильнее там, где данных было мало

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

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

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

RAG: опора на документы вместо памяти модели

Раз проблема в том, что модель полагается на «размазанную» статистическую память вместо проверяемого источника, самый прямой способ снизить риск — вообще не заставлять её вспоминать факт из весов, а подать ей нужный текст прямо в промпт. Это и есть идея RAG (retrieval-augmented generation): перед тем как модель отвечает, система находит релевантные фрагменты из ваших реальных документов (базы знаний, документации, отчётов) и подставляет их в контекст запроса. Модели остаётся не «вспоминать», а пересказывать и обобщать то, что прямо перед ней — а с этой задачей она справляется заметно надёжнее, чем с извлечением факта из глубин обучающих данных.

Упрощённая схема запроса с RAG выглядит так:

Вопрос пользователя → поиск релевантных фрагментов в векторной базе
  → подстановка найденных фрагментов в промпт
  → генерация ответа с явной инструкцией опираться только на них

Пример системной инструкции для такого промпта:

Отвечай на вопрос пользователя, используя ТОЛЬКО информацию
из раздела "Контекст" ниже. Если в контексте нет ответа —
так и скажи: "В предоставленных документах нет информации
по этому вопросу". Не добавляй факты из общих знаний.

Контекст:
{найденные фрагменты документов}

Вопрос: {вопрос пользователя}

RAG снижает риск галлюцинаций, но не убирает его полностью — модель всё ещё может домыслить деталь, которой нет в переданном фрагменте, особенно если фрагмент неполный или найден неточно (проблема качества поиска — отдельная тема). Если вы разворачиваете такую схему на своём сервере, дальше нужна векторная база для поиска фрагментов и сам пайплайн подготовки документов — это описано подробнее в материале о том, как поднять RAG по своим документам на сервере. Отдельный практический вопрос — стоит ли вместо RAG дообучать модель под свою предметную область; короткий разбор компромиссов есть в статье fine-tuning против RAG.

Явные инструкции в промпте: разрешите модели не знать

Второй практический рычаг проще технически, но не всегда работает так же надёжно, как RAG — явно прописать в промпте (обычно в системной инструкции), что модель должна признавать незнание, а не выдумывать правдоподобный ответ. Раз склонность отвечать «во что бы то ни стало» — следствие обучения на текстах, где отказы редки, прямая инструкция сдвигает поведение модели в сторону более осторожных ответов там, где она действительно не уверена.

Рабочий пример такой инструкции:

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

Эта техника не «включает у модели рефлексию» в человеческом смысле — она лишь смещает статистику генерации: после такой инструкции модель чаще выбирает продолжения в духе осторожной оговорки, потому что промпт делает такие продолжения более вероятными в конкретном контексте разговора. Работает это неидеально и по-разному в зависимости от модели: крупные современные модели реагируют на такую инструкцию заметно лучше, чем маленькие открытые модели на 7–8B параметров, которые хуже удерживают абстрактное правило на протяжении всего ответа (подробнее о том, почему маленькие модели требуют более конкретных и коротких инструкций, — в материале про промпт-инжиниринг для своих моделей). Дублирование инструкции ближе к концу промпта, перед самим вопросом, обычно повышает шанс, что модель её действительно учтёт.

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

Temperature и другие параметры генерации

Третий рычаг — не промпт, а параметры самого запроса к модели. Temperature управляет тем, насколько «плоско» или «остро» модель выбирает токен из распределения вероятностей: при temperature, близкой к 0, модель почти всегда берёт самый вероятный токен — генерация становится детерминированной и предсказуемой (для одного и того же промпта ответы почти не различаются между запусками). При более высокой temperature (обычно в районе 0.7–1.0 в большинстве API) модель чаще выбирает не самый вероятный, а один из вероятных токенов — ответы становятся разнообразнее и «творческее», но и риск случайного отклонения от факта выше.

Пример параметра в запросе (формат близок к большинству API, включая OpenAI-совместимые и локальные через Ollama):

{
  "model": "...",
  "messages": [...],
  "temperature": 0.2
}

Для задач, где важна фактическая точность (ответы по документации, извлечение конкретных данных, юридические или технические справки), низкая temperature (0.0–0.3) — разумная настройка по умолчанию: она не устраняет галлюцинации (они возникают и при жадном выборе самого вероятного токена, если само распределение вероятностей ошибочно смещено), но убирает дополнительный источник случайности поверх и без того рискованной генерации. Для творческих задач (черновики текстов, брейншторм формулировок) высокая temperature, наоборот, уместна и даже полезна.

Здесь стоит сделать честную оговорку: конкретный выигрыш в точности от понижения temperature сильно зависит от модели, задачи и того, насколько уверенно (или неуверенно) она вообще «знает» нужный факт — универсальной цифры вроде «на N% меньше ошибок» здесь дать нельзя, это стоит проверять на своих реальных запросах, а не полагаться на общие ориентиры из статей. Похожим образом работает параметр top_p (nucleus sampling) — он ограничивает выбор верхним по вероятности подмножеством токенов и в паре с низкой temperature даёт ещё более предсказуемую генерацию.

Частые вопросы