Галлюцинации нейросетей: почему ИИ выдумывает факты и как снизить риск

Бот поддержки не должен выдумывать исключение из правил. Помощник по отчётности — брать итоговую сумму с потолка. Агент — программа, которая с помощью модели выбирает действия и вызывает инструменты, — не должен угадывать, запись какого клиента нужно изменить. Практическая задача — не дать неподтверждённому ответу или действию выйти за пределы приложения.

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

Что такое галлюцинации нейросетей и откуда они берутся

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

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

Правдоподобный текст ещё не означает проверенный факт

В исследовательской статье о причинах галлюцинаций языковых моделей, опубликованной 5 сентября 2025 года, OpenAI объясняет: при предобучении модель учится предсказывать текст, но не получает для каждого утверждения отметку «истина» или «ложь». Редкие факты, которые нельзя вывести из закономерностей, особенно трудно восстановить по текстовым шаблонам. Дальнейшее обучение улучшает поведение модели, однако гладкий текст не становится гарантией достоверности.

Для разработчика вывод прост: правила работы с продуктом, статус аккаунта и остатки товаров должны храниться в достоверных источниках, доступных приложению. Если использовать ответ «по памяти» модели вместо базы данных, вы сами создаёте лишнюю возможность для ошибки.

Неполный или устаревший контекст оставляет пробелы

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

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

Требование отвечать любой ценой поощряет ошибки

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

Клиенту, который просит гарантировать дату доставки, нужна официальная оценка срока от перевозчика. Если перевозчик её не предоставил, полезным результатом будет конкретное объяснение того, каких данных не хватает. Учитывайте такой исход как полезный в тестах и на рабочем дашборде.

Примеры галлюцинаций LLM: четыре типа ошибок, которые нужно выявлять

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

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

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

Фиктивные ссылки на источники. В судебном решении от 20 марта 2024 года по делу United States v. Cohen описаны три несуществующих дела, полученных из Google Bard — так тогда назывался генеративный помощник Google. Одно из них было указано как United States v. Figueroa-Florez. Правдоподобное название дела и корректное оформление ссылки не сделали источник реальным.

Неверные аргументы инструментов. Авторы Berkeley Function Calling Leaderboard приводят вызов с annual_interest_rate: 5 для запрошенной ставки 5% и рядом показывают правильную запись десятичной дробью — 0.05. Оба значения имеют числовой тип. Проверка типа сама по себе не позволяет их различить. Это ошибка в смысле переданного аргумента: не каждый неверный вызов инструмента содержит выдуманный факт, но проверять его нужно на том же этапе, до выполнения.

Как сократить галлюцинации до того, как их увидит клиент

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

Стройте ответы на актуальных и подходящих источниках

Генерация с поиском по внешним источникам, или RAG, находит внешние материалы и передаёт модели подходящие фрагменты. Так у «автора» появляется материал для работы. В объяснении Contextual Retrieval Anthropic показывает, почему найденному фрагменту нужен окружающий контекст: из отдельной выдержки может быть непонятно, о какой компании, периоде или предмете идёт речь.

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

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

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

Главный диагностический вопрос — дошли ли до модели нужные подтверждающие данные. Сохраняйте идентификаторы и версии источников вместе с ответом: это поможет сотруднику отличить неудачный поиск от неподтверждённого дополнения модели.

Сделайте «не знаю» отдельным состоянием приложения

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

Предусмотрите явные исходы, например answered, needs_clarification и insufficient_evidence. Не заставляйте модель выдумывать ответ ради обязательного поля, если ответа нет. Для каждого исхода интерфейс должен предлагать полезный следующий шаг: конкретный уточняющий вопрос, объяснение того, какой записи не хватает, или передачу вопроса сотруднику вместе с найденным контекстом.

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

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

Проверяйте ссылки на источники программно

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

Проверяйте три отдельных свойства:

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

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

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

Задавайте структуру ответа, а затем проверяйте значения

Структурированный вывод ограничивает ответ схемой — описанием допустимых полей и типов значений. Так проще писать проверки в приложении. В руководстве OpenAI по Structured Outputs прямо сказано, что ответы по-прежнему могут содержать ошибки. Если входные данные не подходят для заданного формата, а правила ответа не предусматривают подходящего запасного исхода, модель может начать галлюцинировать.

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

Даже после успешного вызова инструмента ответ клиенту должен точно отражать результат. Не сообщайте, что отмена завершена, если инструмент вернул состояние ожидания или ошибку. Формируйте итоговое сообщение на основе возвращённого статуса. Другие ограничения действий разобраны в руководстве по защитным ограничениям ИИ-агентов.

Как выявлять галлюцинации LLM: проверка, которую можно запустить

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

Следующий пример на Python использует условные тестовые данные о правилах поддержки, а не реальные правила компании. Сохраните его как verify_answer.py и запустите командой python3 verify_answer.py. Он использует только стандартную библиотеку и не обращается к API.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

Предложенный ответ chat не проходит проверку, хотя цитата подлинная. Если заменить значение на email, эта узкая проверка завершится успешно. Ответ подтверждает достоверное поле, а не одно лишь совпадение цитаты.

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

Как оценивать и правильные ответы, и обоснованные остановки

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

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

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

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

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

Какие способы борьбы с галлюцинациями переоценивают?

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

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

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

Корректный JSON не гарантирует верного ответа. Схема может требовать идентификатор источника и числовой аргумент, но приложению всё равно нужно установить, что источник существует, а число имеет нужный смысл.

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

План на неделю для небольшой команды

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

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

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

Частые вопросы о галлюцинациях LLM

За практическими руководствами по созданию надёжных рабочих процессов с ИИ подписывайтесь на рассылку.