Галлюцинации LLM: почему они возникают и что это стоит бизнесу
Понятное объяснение того, почему языковые модели уверенно говорят неправду - и как решить, приемлем ли этот риск в вашем конкретном случае.
В прошлом месяце клиент показал мне демо внутреннего бота для ответов на вопросы. Он отвечал гладко, ссылался на внутренние регламенты по названию и давал пошаговые инструкции уверенным тоном. Примерно треть упомянутых регламентов не существовала. Модель заполнила пробелы так аккуратно, что никто в команде не заметил этого во время тестирования.
Это не баг, который исправят в следующей версии. Это структурное свойство того, как устроены такие модели. Понять его можно за десять минут - и это понимание меняет то, как вы формулируете задачи для ИИ-проектов.
Что происходит внутри модели
Языковая модель обучена предсказывать наиболее статистически вероятный следующий токен, исходя из всего, что было до него. Она не «ищет» информацию так, как работает запрос к базе данных. Она сжала огромное количество текста в веса - паттерны того, что обычно следует за чем - и на этапе генерации восстанавливает правдоподобное продолжение.
Когда запрос требует чего-то, чего модель не видела чётко в обучении, или точного фактического воспроизведения, она не говорит «я не знаю». Она продолжает генерировать правдоподобный текст - потому что это единственное, что она умеет делать. Результат - уверенное, грамматически безупречное утверждение, которое оказывается ложным.
Почему уверенность делает это хуже
Эксперт, который не уверен в чём-то, обычно оговаривается. Модель, обученная на уверенном тексте, по умолчанию генерирует уверенный текст. Пользователи, которые не ожидают ошибок, не будут ничего проверять. В этом и состоит реальный операционный риск: не в том, что ошибки есть, а в том, что они невидимы.
В контексте с низкими ставками - брейнсторм, черновик, обобщение собственных документов - риск управляем. В контексте, где кто-то действует по результату без проверки - юридическом, медицинском, финансовом, комплаенс - цена незамеченной галлюцинации может быть вполне конкретной.
Где риск наиболее высок
По моему опыту галлюцинации причиняют наибольший ущерб в трёх сценариях:
- Ссылки на конкретные источники. Модель называет реальный документ, но описывает содержание, которого в нём нет, или полностью изобретает ссылку.
- Числовая точность. Даты, цифры, ставки, пороги - модель берёт примерный порядок величины и ошибается в детали.
- Граничные случаи в процессных вопросах. «Что будет, если я пропущу срок?» - модель описывает правдоподобный, но выдуманный путь.
Что реально снижает риск
RAG (генерация с поиском по контексту) существенно помогает в первом сценарии, потому что модель привязана к реально найденному тексту. Но это не полное решение - модель всё равно может неверно прочитать или представить то, что она получила.
Практические меры, которые я рекомендую для любого продакшн-использования:
- Привязывайте модель к определённому корпусу. Не давайте ей отвечать из общих знаний там, где доступны доменные знания.
- Показывайте пользователю ссылки на источники, чтобы он мог проверить. Не прячьте шаг поиска.
- До деплоя определите цену незамеченной ошибки в вашем конкретном случае.
- Встраивайте ревью человеком в процессы с высокой ценой ошибки - не как запасной вариант, а как спроектированный шаг.
Вопрос, который нужно задавать перед каждой ИИ-функцией
Для каждой ИИ-функции в продукте или внутреннем инструменте спросите: «Если этот результат окажется неверным и никто не заметит - что произойдёт?» Если ответ «ничего серьёзного» - действуйте осторожно, но действуйте. Если ответ включает регулятора, пациента или договорное обязательство - архитектура нуждается в слое верификации до того, как результат дойдёт до человека, который будет на нём действовать.
Технология действительно полезна. Риск действительно управляем. Но управление им начинается с точного называния, а не с надежды на то, что следующая версия модели всё исправит.