Как контролировать галлюцинации ИИ. Часть I

При работе с нейросетью в первую очередь нужно запомнить одно: она ошибается — и ошибается нередко. Даже современные модели далеки от полной фактической надежности. Например, на бенчмарке SimpleQA модель GPT-4.1 показывала около 40% точности, а более новые reasoning-модели OpenAI в отдельных тестах галлюцинировали в 30–50% случаев. То есть даже сильная модель допускает ошибки чаще, чем интуитивно ожидает пользователь, если вопрос требует точного факта, а не «в целом разумного» ответа.

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

Что такое галлюцинации и какими они бывают

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

Можно выделить несколько типов галлюцинаций:

• Выдуманные факты. Модель добавляет детали, которых не было в исходных данных или которые не подтверждаются внешними источниками. Например, придумывает цифры, даты или события, чтобы «завершить» ответ.
• Ложные ссылки и источники. Генерируются несуществующие статьи, документы или URL. Особенно часто это происходит при запросах «приведи источники» или «дай ссылки».
• Неверная атрибуция. Реальные факты приписываются не тем авторам, компаниям или исследованиям. Формально информация может существовать, но связь искажена.
• Излишняя уверенность. Даже при неполной или сомнительной информации модель формулирует ответ как однозначный, без указания на неопределённость или ограничения.

Неточность и критичная ошибка — одно и то же?

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

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

Как бизнес решает проблему галлюцинаций прямо сейчас

Некоторые техники верификации из описанных выше активно используют в работе крупные компании как на русском, так и на зарубежном рынке.

• AWS применяет RAG через базы знаний Amazon Bedrock, чтобы ответ опирался на внешние проверенные источники, а не на «память» модели. Система защиты Bedrock устанавливает такие ограничения, чтобы ИИ каждый раз сверял ответ с эталонным источником.
• Представители Сбера рассказали, как усиливают агентный контур через структурированный вывод на Pydantic-схемах: так модели меньше галлюцинируют и строже придерживаются заданного формата.
• В security-рекомендациях Microsoft Azure выделены фильтрация входа, экраны защиты промпта для выявления попыток манипулировать поведением модели, проверка формата данных и проверка по схеме на API-слое.
• У Gramax описан любопытный кейс, в котором модель галлюцинировала API, страницы документации и фичи продуктов. Решение — двухслойная верификация: в промпте прописывались жесткие инструкции плюс в роли проверяющего выступила вторая LLM. Она анализировала результат, чтобы выявить логические противоречия до того, как их увидит человек.
• В Альфе пришли к тому, что для необратимых действий обязательно нужен человек в контуре. Это не значит «специалист просто посмотрит, все ли ИИ сделал правильно» — речь идет об оформленном слое эскалации для высокорисковых кейсов.

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

Практические техники верификации

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

Черные и белые списки, регулярки, шаблоны запретов

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

Конкретные kill-switch правила

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

Анти-галлюцинационные подсказки

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

Авторитетные базы как источник правды

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

Политика свежести и приоритета источников

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

Трассировка и цитирование 

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

Self-check и сравнение нескольких прогонов

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

Round-trip test и детекция противоречий

Полезно не только получить ответ, но и проверить, можно ли из него восстановить исходный смысл без искажений. Для этого используют схему «вопрос → ответ → обратный вопрос по ответу» и смотрят, не появилось ли противоречий. Дополнительно сюда хорошо ложатся NLI-проверки (Natural Language Inference): система отдельно оценивает, подтверждается ли ответ исходными данными или модель начала интерпретировать информацию слишком свободно. где отдельный модуль оценивает, действительно ли ответ следует из контекста.

Юнит-тесты промптов и регрессионные наборы

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

Порог уверенности

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

Категории вне компетенции

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

Откаты вместо догадок

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

«Не знаю» как обязательный результат

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

UX-паттерн для отказа

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

Логирование отказов и обучение на них

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

KPI на отказы в зонах высокого риска

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

Выбираем технику верификации: как понять, что подходит бизнесу

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

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

Также важно осознавать, дорого ли обойдется промах:

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

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

Что в итоге?

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

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