Почему LLM галлюцинирует и как это измерить

LLM галлюцинирует, потому что она не ищет ответ, а продолжает текст. На каждом шаге модель выбирает правдоподобный следующий токен, и правдоподобное не обязано быть правдой. Убрать это свойство нельзя — его можно измерить и обойти архитектурой системы.

Модель — не база данных

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

Представление «LLM хранит факты как БД» в нашей программе считается фундаментальной ошибкой — из тех, что закрывают гейт уровня L4 при любых баллах. Из него растут почти все неверные решения: доверять ответам без проверки, дообучать модель, «чтобы она запомнила документы», удивляться, что модель выдумала ссылку на несуществующую статью.

Где галлюцинации появляются чаще

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

Отдельная история — RAG. Там у модели есть документы в контексте, и галлюцинацией считается ответ, который на них не опирается. Это измеряемо: метрика называется faithfulness. Но часто «галлюцинация» в RAG — вовсе не вина модели: нужного фрагмента просто не было в контексте, поиск его не нашёл. Подробно — в статье про RAG.

Не поможет ли температура 0?

Нет. Температура управляет случайностью выбора токенов. При нулевой модель каждый раз выдаёт самый вероятный вариант — ответ становится стабильным, но не становится верным. Если самое вероятное продолжение ошибочно, вы получите одну и ту же ошибку при каждом запросе.

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

Как это измерить

Фраза «модель стала меньше галлюцинировать» без числа ничего не значит. Измерение строится по нарастающей — так же оно устроено и в программе.

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

Эталонный набор. 15–20 реальных вопросов с известными правильными ответами и скрипт, который прогоняет систему и выдаёт число. Там, где ответ можно проверить детерминированно — поле извлечено, значение совпало, формат валиден, — проверка делается кодом, без участия модели.

Метрики генерации. Для RAG и похожих систем — faithfulness (опирается ли ответ на контекст), доля ответов с утверждениями, которых нет в источниках, релевантность ответа вопросу. Считаются отдельно от качества поиска, иначе не понять, что именно сломалось.

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

Регрессия. Набор прогоняется при каждом изменении промпта, модели или данных. Иначе исправление одной галлюцинации незаметно порождает две новые.

Что снижает галлюцинации на практике

Не одна волшебная настройка, а несколько решений в архитектуре:

• давать модели факты в контекст — через RAG или инструменты — и требовать ссылки на источник;
• явно разрешить ответ «в документах этого нет» и проверять, что модель им пользуется;
• для машиночитаемых ответов — схема и валидация: невалидный ответ отклоняется, а не уходит дальше;
• проверять цитаты кодом: есть ли такой фрагмент в документе на самом деле;
• не отдавать вывод модели без проверки в SQL, shell или HTML — ошибка модели не должна становиться ошибкой системы.

Последний пункт уже про безопасность, но граница здесь тонкая: и галлюцинация, и атака выглядят как «модель уверенно сделала не то».

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

Новые модели галлюцинируют меньше? В целом да, но свойство остаётся у всех. Сравнивать модели нужно на своём эталонном наборе, а не по общим рейтингам: на ваших данных картина может быть другой.

Можно ли попросить модель саму сказать, когда она не уверена? Можно, и это иногда полезно, но уверенный тон модели не равен её правоте. Самооценку модели тоже стоит проверить на наборе, прежде чем на неё полагаться.

Если модель ссылается на источник, значит, ответ верный? Нет. Ссылку тоже можно выдумать. Проверяется, что источник существует и что в нём действительно написано то, что утверждается.

Где это в программе

Проверка ответов ИИ начинается уже на L1, без кода. На L3 появляется эталонный набор со скриптом и числом на выходе, на L4 — раздельная оценка поиска и генерации в RAG и faithfulness, на L6 — модель-судья с калибровкой по человеческой разметке и eval-гейт в CI, который не пропускает изменение, ухудшившее качество.