Почему ИИ врёт: 4 реальные ошибки и как проверять ответы

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

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

Мы это ловили у себя не один раз. Поэтому в ИИ-Станции пришли к простому правилу: ответ модели — ещё не результат. Результат появляется только после проверки источника, фактического выполнения, теста и сохранённого доказательства.

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

1. Агент «увидел» 15 участков, которых система ему не передавала

Внутренний журнал сессии от 12.08.2026 фиксирует расхождение между документацией OpenClaw и реальной config schema нашей версии.

Документация описывала параметр bundleMcp. Логика выглядела нормально: подключаем MCP, агент получает инструменты и работает с объектами.

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

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

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

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

Если они расходятся, верим фактическому состоянию.

Внутренняя трассируемость: журнал сессии 2026-08-12.

2. Модель не видела скриншот — и придумала техническую причину

Внутренний журнал от 18.08.2026 начинается с простой жалобы: Тех-агент просил пользователя показать скриншот бага.

Файл действительно сохранялся на диск, но модель работала через текстовый claude -p без функции распознавания изображений. В модель уходила только ссылка на файл. Саму картинку она физически не видела.

Первый фикс был очевидным: запретили переспрашивать изображение, которое модель всё равно не сможет обработать.

Повторный живой тест дал второй баг.

На прямой вопрос о том, видит ли она картинку, модель уже не просила прислать её снова, но в журнале зафиксирована придуманная причина:

«браузер требует разрешения».

Никаких данных об этом не было.

Это важнее первой ошибки. Мы убрали неправильную реплику, но не сам механизм: модель по-прежнему стремилась закрыть пробел правдоподобным объяснением.

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

Только после повторного воспроизведения дефект закрыли.

Внутренняя трассируемость: журнал сессии 2026-08-18 «фикс галлюцинации Тех-агента про скриншоты…».

3. «Исследование» выглядело убедительно, но один плагин оказался выдуманным

В той же серии работ мы проверяли документы-исследования, подготовленные разными ИИ.

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

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

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

Второй и третий документы, наоборот, подтвердились почти полностью.

Именно это делает проблему опасной: нормальное исследование и галлюцинация могут выглядеть одинаково уверенно.

Так у нас закрепилось правило:

«нашёл» без реального поиска — не факт; «проверил» без доказательства — не проверка.

Внутренняя трассируемость: журнал 2026-08-12 и реестр TOOLS_RESEARCH.

4. ИИ может не придумать факт, но предложить неправильное решение

27 сентября мы дорабатывали быстрый маршрут Контент-завода.

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

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

То есть локальный сбой одного компонента чуть не превратился в изменение всей схемы работы.

Во внутреннем отчёте о сессии от 27.09.2026 это прямо зафиксировано как ошибочный вывод ассистента и последующая коррекция роли.

Это тоже ИИ-ошибка. Не обязательно выдумывать цифру. Иногда достаточно слишком быстро решить: «раз здесь сломалось — значит, надо перестроить процесс».

Для системных задач после этой истории закрепили порядок:

ИСТОЧНИК → ФАКТ → РАЗНИЦА → ДЕЙСТВИЕ → ПРОВЕРКА → СТОП.

Сначала источник. Потом доказанный факт. Потом разница между ожидаемым и реальным состоянием. И только затем изменение.

Внутренняя трассируемость: отчёт о быстром маршруте Контент-завода от 2026-09-27.

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

Если модель уже построила объяснение, просьба «проверь себя» может пройти внутри той же исходной логики.

Поэтому у нас проверка разделена.

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

Не потому, что второй ИИ всегда умнее первого.

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

Шесть правил, которые мы теперь применяем к работе ИИ

1. Слова модели не считаем фактом.
Факт должен иметь источник: файл, код, API, лог, БД, расчёт или живой тест.

2. Не пишем «проверено», если проверки не было.
Если поиск не запускался — ничего не «нашли». Если браузер не открывался — интерфейс не «проверили».

3. Разделяем факт, вывод и гипотезу.
«Сервис вернул 500» — факт. «Причина в авторизации» — гипотеза, пока это не подтверждено.

4. Чиним причину, а не формулировку.
Первый фикс Тех-агента убрал просьбу прислать скриншот. Только повторный живой тест обнаружил вторую галлюцинацию.

5. Для опасных изменений нужен независимый разбор.
Автор и проверяющий — разные контуры. Спор решает доказательство, а не уверенность одной модели.

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

Что это меняет для бизнеса

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

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

Нужен процесс, в котором видно:

• какую задачу поставили;
• на какие источники опирался ИИ;
• что он реально выполнил;
• где возникла ошибка;
• кто проверил результат;
• какой файл или статус считается финальным;
• можно ли воспроизвести результат ещё раз.

Именно из этой практики у нас и выросла ИИ-Станция.

Не как «ИИ, который не ошибается». Такого обещать нельзя.

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

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

Вопросы по теме

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

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

Зачем нужен независимый критик, если модель может проверить себя?

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

Когда такой контроль действительно нужен бизнесу?

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

Хотите посмотреть, как это устроено в ИИ-Станции?

На демо за 20–25 минут можно взять вашу задачу и посмотреть, как она превращается в процесс с этапами, статусами, файлами и проверяемым результатом.

Написать: @stasnesupurgu.