Галлюцинации ИИ: что это такое, почему возникают и как избежать ошибок моделей

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

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

Что такое галлюцинация ИИ простыми словами

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

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

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

Природа предсказания токенов

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

Пробелы в обучающих данных

Если у модели нет информации или доступа к данным, она может попытаться самостоятельно заполнить пробел. Она дает ответ, который звучит логично и уверенно, но не соответствует реальности. Например, без подключения корпоративной базы знаний ИИ не имеет доступа к внутренним документам, регламентам и процессам компании, поэтому может заменить отсутствующие данные общими сведениями или сделать неверные предположения.

Устаревшие знания

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

Неструктурированный или перегруженный промпт

Если в промпте не хватает деталей, условий или контекста, ИИ-модель может неправильно понять задачу и сформировать ответ не в том направлении. Чем точнее сформулирован запрос и чем больше в нем исходных данных, тем ниже риск, что ИИ начнет самостоятельно заполнять пробелы предположениями.

Давление на ответ

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

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

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

Если подключить RAG (Retrieval Augmented Generation), галлюцинации не исчезнут. RAG дает модели правильные документы, но не гарантирует, что она правильно их поймет и перескажет — на этапе интерпретации фактов все еще могут появляться искажения и додумывания. 

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

Поэтому для RAG-систем ключевой метрикой становится достоверность привязки ответа к источнику (faithfulness, также используется термин groundedness — «обоснованность» или «привязка к источнику»). 

• Высокий показатель обоснованности (groundedness) означает, что утверждения модели подтверждаются нужным контекстом и источниками. 

• Низкий показатель говорит о том, что ответ может содержать выводы или детали, которых нет в найденных данных. Низкий показатель говорит о риске того, что модель смешала данные из источников с собственными предположениями.

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

Оценка с помощью другой языковой модели (LLM-as-a-judge)

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

Метод отличается гибкостью: критерии оценки можно менять под конкретную задачу с помощью настройки запроса для модели-судьи (prompt). Такой подход используют для универсальной оценки качества ответов в продакшене.

Проверка привязки ответа к источникам для RAG-систем (Groundedness-проверки)

В системах с RAG важно проверить, насколько ответ модели соответствует найденным документам. Специальные инструменты сравнивают ответ модели с исходным контекстом. Для этого могут использоваться:

• LLM-as-a-judge — другая языковая модель оценивает соответствие ответа контексту;

• модели entailment — используются специальные модели, которые обучены проверять, логичен ли ответ проверяемой модели;

• семантическое сравнение — вычисляются меры семантической близости между утверждениями модели и фрагментами контекста.

Для такой проверки используют несколько метрик:

• достоверность привязки к источнику (Faithfulness) — показывает, насколько ответ опирается на найденные документы;

• точность найденного контекста (Context Precision) — оценивает, какая доля извлеченных фрагментов действительно релевантна запросу пользователя;

• полноту найденного контекста (Context Recall) — показывает, какая доля всех релевантных документов (из доступных в системе) была успешно найдена поисковым компонентом;

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

Self-Consistency — проверка стабильности ответов 

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

Дообученные классификаторы (Fine-tuned classifiers)

Дообученные классификаторы — специализированные модели для выявления признаков недостоверных ответов. Их заранее обучают выявлять признаки недостоверных ответов в конкретной области. Такие классификаторы работают быстрее больших языковых моделей и подходят для систем с высокой нагрузкой.

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

Таблица: выбор метода под задачу

Компании комбинируют сразу несколько подходов: LLM-as-a-judge для общей проверки качества, groundedness-метрики для RAG-систем, автоматический мониторинг через специализированные платформы и классификаторы для массовых сценариев. Выбор зависит от требований к скорости, стоимости и критичности ошибок.

Обнаружение галлюцинаций — только первый этап. Чтобы уменьшить количество ошибок, нужно правильно настроить архитектуру ИИ-системы, правила генерации ответов и процессы контроля качества.

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

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

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

Настройте параметры генерации под задачу. Для задач, где важна точность фактов, обычно используют более низкое значение температуры (temperature). Она влияет на то, насколько свободно модель выбирает варианты ответа.

Если простыми словами:

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

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

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

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

Борьба с галлюцинациями — это связка из трех слоев: обоснованность на фактах (привязка к источникам), мониторинг поведения в продакшен и контроль над данными. Платформа Evolution AI Factory от Cloud.ru помогает закрыть эти задачи за счет работы с данными, инструментов контроля качества и механизмов безопасного использования ИИ.

Evolution Managed RAG — обоснованность на фактах (привязка ответов к источникам). Сервис подключает корпоративную базу знаний к языковой модели через протокол взаимодействия с источниками данных (Model Context Protocol, MCP). Ответы формируются с учетом данных из корпоративных источников, которые модель получает через RAG, что снижает зависимость от внутренних знаний, полученных во время обучения.

Evolution AI Agents + Arize Phoenix — мониторинг и трейсинг. Сервис Evolution AI Agents интегрирован с платформой наблюдаемости Arize Phoenix, которая работает на основе протокола OpenTelemetry. Трассировка показывает путь каждого запроса внутри агента: к каким документам обращалась модель, какие документы нашла, на основе чего формировался финальный ответ. Система помогает отслеживать работу агента: какие данные использовались, какие шаги выполнялись и где возникло расхождение между источниками и ответом модели.

Механизмы безопасности в Evolution Foundation Models. Облако Cloud.ru предоставляет защитные механизмы (guardrails), которые работают между приложением и ИИ-моделью и обеспечивают:

• фильтрацию входящих запросов — проверку на наличие чувствительных данных и потенциально опасного контента;

• защиту от промпт-инъекций — предотвращение попыток злоумышленников изменить инструкции модели через входные данные;

• контроль исходящих ответов — проверку генерируемого контента на соответствие политикам безопасности.

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

Представим финтех-компанию, которая запустила ИИ-агента для ответов клиентам по условиям продуктов. Через две недели пользователи начали получать ответы со ссылками на неактуальные условия. Команда не понимала, в чем проблема галлюцинаций ИИ: поиске документов или генерации ответа.

После подключения Arize Phoenix через Evolution AI Agents специалисты получили трассировку запросов: какие документы нашла система, насколько они подходили и как модель использовала их в ответе. Выяснилось, что в базе знаний оставались старые версии документов. После обновления индекса источник ошибок был устранен без ручного анализа тысяч логов.

Три слоя защиты от галлюцинаций в Cloud.ru

Часто задаваемые вопросы

Можно ли полностью убрать галлюцинации?

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

Помогает ли RAG от галлюцинаций?

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

Как измерить уровень галлюцинаций?

Для оценки галлюцинаций используют автоматические методы проверки качества ответов: оценку другой языковой моделью (LLM-as-a-judge), проверки привязки ответа к источникам в RAG-системах (groundedness-проверки) и проверку стабильности ответов (Self-Consistency) — метод, при котором модель многократно генерирует ответ на один запрос, а расхождения в смысле указывают на низкую уверенность и риск галлюцинаций. 

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

Какой метод обнаружения выбрать для продакшен?

Зависит от задачи. Для универсальной оценки качества подходит LLM-as-a-judge. Для RAG-систем лучше использовать groundedness-проверки с метриками достоверности привязки к источнику (Faithfulness) и точности найденного контекста (Context precision). Если система работает с большим количеством однотипных запросов, можно применять дообученный классификатор (Fine-tuned classifier) с минимальной задержкой обработки.