Ошибки ИИ-агентов в отчётах: пять цифр за один день, и четыре — не про то, что мы думали

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

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

Общий механизм: число записали раньше, чем определили, что оно измеряет

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

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

Случай 1. Рост CTR, который дал бренд

Мы проверяли, поднимут ли новые заголовки страниц кликабельность в поиске Яндекса. Критерий записали заранее: CTR тридцати самых показываемых запросов должен вырасти на 1 процентный пункт от недели к неделе. Заголовки поменяли на трёх страницах услуг.

Через две недели расчёт показал +1,25 процентного пункта. Формально порог пройден.

Агент, который считал итог, не остановился на этом числе и разложил его по запросам. Весь прирост дали два брендовых запроса — те, где люди ищут студию по названию: 41 показ и 3 клика в первую неделю, 43 показа и 8 кликов во вторую. Эти запросы ведут на главную страницу, а заголовки меняли совсем на других. По остальным 28 запросам CTR упал с 0,15% до 0,00%: был один клик, не стало ни одного. Следующие семь дней развернули знак: тот же расчёт дал минус 1,03 пункта.

Итог: эксперимент признан неудачным. Число +1,25 посчитано верно, но измеряло интерес к названию студии, а не действие новых заголовков. Это единственный из пяти случаев, где цифру правильно объяснили сразу: агент разложил прирост на части до того, как записать вывод.

Случай 2. Строки, которые стали категориями

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

Мы открыли отчёт, на который он опирался. Число 14 там действительно было, но означало другое: 14 пустых строк в блоке характеристик на страницах опубликованных товаров. Категорий в магазине 19, а не 15, и в том же отчёте прямо сказано, что блок характеристик есть у товаров всех категорий.

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

Случай 3. Ссылки в тексте вместо страниц на сайте

Утром мы обсуждали с ассистентом цели на квартал, и он сказал, что из тринадцати учебных курсов на сайте выложен только один. Цифра звучала убедительно и сразу просилась в план: значит, надо срочно выкладывать остальные.

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

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

Случай 4. Последняя запись об успехе вместо первой записи об отказе

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

Руководитель студии сверил это с уведомлением другой проверки: там сбой начинался 2 октября. Мы подняли отчёты о безопасности сервера. В отчётах за 22 и 27 сентября ночной бэкап отмечен как успешный, с временем и размером архива. Отказ начался 2 октября: накануне при плановой чистке отозвали доступ к хранилищу, и следующий ночной запуск уже не прошёл. Копий не было за три ночи, а не за две недели.

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

Случай 5. «Задачу обновили» вместо «задачу сделали»

На общей доске задач с 3 июля висела задача про устаревшие страницы внутренней базы знаний. Автоматическая проверка регулярно находила такие страницы и обновляла задачу: меняла число в заголовке, добавляла комментарий со свежим списком. Летом в списке было три страницы, к октябрю в заголовке стояло «22 страницы». На доске это выглядело как живая работа: задача обновлялась, цифры менялись. Когда мы готовили этот текст, то пересчитали список и попались на ту же ошибку, о которой пишем: 22 — это число строк, а разных страниц в них 15, некоторые повторяются по два-три раза.

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

Итог: число в заголовке измеряло, сколько строк набрала проверка, а не сколько страниц устарело и тем более не сколько работы сделано. Частые обновления создавали ощущение, что проблема под контролем.

Один вопрос перед любой цифрой

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

• Что именно измерено? Строки или категории, упоминания или страницы, обновления или выполненная работа.
• В каких единицах? Проценты от чего, клики по каким запросам.
• За какой период? Последняя найденная запись — ещё не начало события.
• Как это проверить? Где лежит источник и можно ли открыть его за минуту.

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

Чек-лист из трёх пунктов

1. У каждой цифры, по которой принимается решение, должен быть источник. Не «по данным системы», а конкретный отчёт, выгрузка или адрес, который можно открыть. В случае 4 источник был, но цифру записали, не открыв его; в случае 2 источник открыли, но прочитали в нём не ту единицу.
2. Проверяйте единицу, а не только число. Перечитайте рядом с цифрой слово, которое стоит после неё: «категорий», «курсов», «недель». Сравните с тем, что написано в источнике. Большинство наших ошибок — подмена единицы при верном числе.
3. Разбирайте хорошую новость так же строго, как плохую. Рост CTR в случае 1 разложили на части и нашли, что эксперимент тут ни при чём. Тревожную дату в случае 4 и «один курс» в случае 3 проверили только потому, что человек засомневался. Проверка не должна зависеть от того, понравилась ли цифра.

Что почитать дальше

Когда ИИ ошибается не в цифре, а в фактах, помогает другой набор проверок — о нём в материале «Как проверить ответ нейросети». Близкий по механизму случай, когда система рапортует об успехе при пустом результате, разобран в статье «Silent No-Op: почему софт и ИИ рапортуют об успехе при мёртвых данных». А если агент то справляется, то нет, начните с материала о дрейфе ИИ-агента.

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

Если вы поручаете ИИ-агентам отчёты и хотите встроить такие проверки в работу, напишите нам — обсудим вашу задачу.