ИИ-мониторинг, который врёт: 5 приёмов ловли тихих поломок в 2026

Разбор новинки простыми словами: что это, кому нужно и брать ли.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Тридцать статей каждое утро. Полгода подряд

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

Хуже, когда каждое утро приходит бодрое «статей к проверке: 30». Тридцать и тридцать, всё сходится. А внутри месяцами крутится чужая лента.

Об этом написал на Хабре автор медиапроекта на VPS под ником igbering52. Полгода наблюдений, 31 задача в кроне: дозоры за комментариями и статьями на чужих площадках, спрос в Вордстате, новые законы, бэкапы, напоминалки. Скрипты пишет и правит ИИ-агент, человек ставит задачу и смотрит на результат.

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

Упавший скрипт меня не пугает. Он падает, крон пишет в лог, в телеграм прилетает ошибка, я иду чинить. Неприятно, но честно.

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

Пять приёмов: что в наборе

Ни один приём не требует отдельного сервиса, денег или DevOps-команды. Три строки кода, привычка сверять, один надзиратель над дозорами.

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

Приём 1. Подставной ключ

Дозор следил за свежими комментариями в нескольких разделах большого медиасайта. Списки статей брал из RSS вида /rss/flows/<раздел>/, шёл по статьям, искал новое. В логе ежедневно тридцать статей. Сходится.

Пока автор не открыл глазами, что именно проверяется в разделе коротких заметок. Кроссворды. Материал про Выборг. Ни того, ни другого в разделе нет.

Сервер не смотрел на название раздела. На любой адрес отдавал общую ленту журнала. Ответ побайтово одинаковый, 38 156 байт, для security, short, avto и для потока, которого не существует. Двести, OK, вот вам лента. Тот же баг жил во втором дозоре: код скопировали из первого.

Лечится тремя строками. Запрос на настоящий адрес, запрос на заведомо несуществующий, сравнение. Совпали ответы, значит параметр игнорируется. Проверку ставят до того, как строить на источнике что-то серьёзное. Месяцы в кроссвордах не вернуть, следующие месяцы закрыты.

Вне HTTP приём тоже работает. Дозор за новыми законами: модель читает ленту документов и отбирает касающиеся тем проекта. Первый промпт просил «отбери только касающиеся» и стабильно отдавал пустой список. Ноль новых законов, красота. В ленту подложили пару документов, которые касаются заведомо. Ответ тот же: пусто. Фильтр слепой. Заработал, когда модель стала выносить решение по каждому документу отдельно, полем «касается: да/нет», а не выбирать из кучи.

Ноль надо проверять подставным ненулём. Иначе ты не знаешь, пусто там или ты не видишь.

Приём 2. Сверка двух источников

Один источник сверять не с чем. После истории с RSS списки статей раздела стали брать двумя путями: HTML-лента с пагинацией и карта сайта раздела.

Ждать логично, что официальная карта полнее. Вышло наоборот. Глубокая пагинация ленты дала 594 статьи, карта 387. «Пропавшие» живы, отвечают 200, в карте их нет. Обратное расхождение составило одну статью.

Вывод записали в код: полнота у ленты, карта годится для дат обновления и как страховка. Модуль сбора списков при расхождении сам пишет предупреждение в лог. Без сверки выбрали бы карту, она «официальная», и треть статей выпала бы незаметно.

Сюда же кодировка. Дозор по тегам развлекательной площадки фильтровал посты по ключевым словам и честно приносил ноль. Фильтр в порядке. Страницы тегов отдавались в windows-1251, скрипт слепо делал decode в utf-8. Русские слова превращались в кашу, ключевые в каше не находились. Ошибка сидела на два шага раньше места, где её искали.

Приём 3. Третье состояние

Пайплайн проверял, проиндексированы ли страницы проекта в поиске. Смысл один: выдать приоритетный список «в индексе точно нет, надо что-то делать». За семь отчётов список не наполнился ни разу.

Причин две. Проверка «в ответе поиска есть хоть один документ» засчитывала нестрогие совпадения и записывала в индекс всё подряд. А упавший запрос возвращал None, и дальше по коду он попадал в ту же ветку, что «да». Python не видит разницы между None и False в условии. «Не проверили» молча становилось утверждением.

Лечится явным третьим состоянием: приоритет, бэкап, неизвестно. Три значения вместо двух, и отчёт перестаёт врать.