Где ИИ ошибается: галлюцинации, уверенный тон и тихие сбои

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

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

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

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

Почему более новая модель не снимает проблему

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

Типы ошибок модели: короткая классификация

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

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

Уверенный тон — не признак правоты

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

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

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

Вопрос с ложной предпосылкой

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

Выдуманные источники, цитаты и цифры

Источники и цитаты

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

Как быстро проверить ссылку

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

Цифры и расчёты

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

Пример: сводка по таблице

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

Обрыв ответа и другие тихие сбои

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

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

Пример: обрыв в пакетной обработке

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

Как выбрать уровень проверки: рамка решений

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

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

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

Когда от модели лучше отказаться

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

Как проверять ответы модели в работе

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

1. 01Давайте модели источник: документ, выгрузку, регламент — и просите отвечать только по нему, указывая место в тексте.
2. 02Открывайте каждую ссылку и находите цитируемое место; несуществующий источник — повод перепроверить весь ответ.
3. 03Пересчитывайте цифры кодом или в таблице на исходных данных.
4. 04Для важных вопросов задавайте тот же вопрос иначе или в новом диалоге и сравнивайте ответы; расхождение — сигнал к проверке.
5. 05Проверяйте модель на задачах, ответ на которые вы уже знаете, прежде чем доверять ей незнакомые.
6. 06В автоматических процессах проверяйте полноту ответа, формат и диапазоны значений, а сомнительные случаи отправляйте человеку.
7. 07Фиксируйте найденные ошибки: они показывают, где модели в вашей задаче доверять нельзя.

Почему источник в запросе не решает всё

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

Проверка в автоматических процессах

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

Пошаговый разбор: проверяем ответ на примере

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

1. 01Выделите в ответе всё проверяемое: ссылки на нормы, сроки, суммы, названия документов.
2. 02Откройте каждую упомянутую норму в официальном источнике и убедитесь, что она существует и говорит именно это.
3. 03Проверьте, действует ли норма в текущей редакции, а не только существовала когда-то.
4. 04Сравните перечень требований с исходным документом: не пропущено ли что-то важное и не добавлено ли лишнее.
5. 05Отметьте утверждения, которые не удалось подтвердить, и удалите их или пометьте как требующие проверки специалистом.
6. 06Если справка пойдёт клиенту или в договор, передайте её юристу вместе с найденными источниками.

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

Типичные ошибки при проверке и как их избежать

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

Чек-лист перед тем, как использовать ответ

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

Короткий словарь терминов

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

Итог

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