Бот ответил, а клиент получил ерунду: как следить за AI в работе

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

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

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

Как выглядит тихий отказ

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

Сбор без доступа «ничего не нашёл». Отзывы с карт бот собирает через прокси. Если файл с его настройками не попал на сервер, сбор не падает, а честно отвечает «компания не найдена». Для программы это нормальный результат, для клиента — пустой отчёт.

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

Модель нарушала формат. В JSON-ответе модель иногда клала в текстовое поле не строку, а список или число. Отчёт мог сломаться уже на сборке страницы. Теперь типы приводятся перед сборкой.

Защита от дублей съела настоящий клик. Бот не отправляет одно и то же уведомление дважды за короткий срок. Тестовое нажатие заняло это окно, и следующий — уже настоящий — клик человека остался без подтверждения.

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

Смотреть надо на сессию, а не на запрос

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

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

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

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

flowchart LR
    A["Запрос<br/>в боте"] --> B["Сбор данных:<br/>сайт, карты"]
    B --> C["Основная<br/>модель"]
    C -->|ошибка| D["Запасная<br/>модель"]
    C -->|ответ| E["Приведение<br/>формата"]
    D --> E
    E --> F["Отчёт<br/>клиенту"]
    B -.-> L["Журнал сессии:<br/>шаги, модели, токены,<br/>цена, ошибки"]
    C -.-> L
    D -.-> L
    E -.-> L

Что записывать про каждый вызов модели

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

Что	Зачем	Как это устроено в боте
Провайдер и модель	Понять, кто на самом деле ответил	Запросы идут по цепочке Gemini → OpenAI → Claude, поэтому ответить может не первая
Токены на входе и выходе	Видеть, где раздувается контекст	Пишутся с каждого вызова
Стоимость	Знать цену задачи, а не общий счёт	Считается по прайсу, в панели пересчитывается в рубли по курсу ЦБ
Время ответа	Заметить деградацию раньше клиента	Секунды на вызов
Успех или ошибка	Найти тихие отказы	Флаг и начало текста ошибки
Ради какой задачи	Собрать вызовы в сессию	Привязка к виду отчёта, конкретному отчёту и пользователю

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

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

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

Записывать целиком, что ушло в модель и что вернулось, очень удобно для отладки. Но это дорого по объёму, а главное — там могут оказаться персональные данные клиентов.

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

Четыре числа, которые смотрят вместе

Из записей складываются показатели. Для небольшого бота или агента достаточно четырёх:

1. Доля ошибок — сколько вызовов закончилось сбоем.
2. Время самых медленных ответов — не среднее, а худшие 5%: именно их ждёт раздражённый клиент.
3. Стоимость одной сессии — одного отчёта, одного диалога.
4. Доля успешных обращений к внешним сервисам — сайтам, картам, CRM, всему, что агент вызывает.

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

Проверка качества — отдельный слой

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

Автоматические проверки структуры. Разобрался ли JSON, на месте ли обязательные поля, не пустые ли разделы отчёта, есть ли в отзывах хоть одна цитата. Это дёшево, мгновенно и ловит самые частые тихие отказы — вроде «компания не найдена» там, где компания точно есть.

Оценка по смыслу. Опирается ли ответ на данные или модель додумала, остановился ли агент там, где следовало. Это делает человек на выборке или отдельная модель-судья.

Два правила, которые отличают рабочую проверку от формальной:

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

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

Тревога — только о том, что требует действия

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

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

• Всплеск расходов. Траты за сутки втрое выше среднего за прошлую неделю — но только если сумма больше доллара. Рост с десяти центов до тридцати ничего не значит и не должен никого будить.
• Сертификат истекает через 14 дней. Автопродление должно было сработать раньше, раз не сработало — нужен человек.
• Упал важный сайт. Сайты низкой важности тревогу не поднимают вовсе.
• Одна тревога — не чаще раза в 12 часов. Если проблему уже увидели, повторять её каждые полчаса бессмысленно.

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

Минимум на один вечер

Если у вас есть бот, агент или автоматизация на моделях и никакого наблюдения за ними, начните с пяти шагов:

1. Заведите таблицу вызовов: модель, токены, стоимость, время, успех или ошибка, ради какой задачи.
2. Привяжите вызовы к сессии — к отчёту, диалогу или заказу.
3. Добавьте три структурные проверки результата: формат разобрался, обязательные поля на месте, разделы не пустые.
4. Настройте одну тревогу на расходы: сутки против среднего за неделю, с минимальным порогом суммы.
5. Раз в неделю открывайте пять случайных сессий и читайте, что получил клиент. Это самый дешёвый способ найти тихий отказ, который не ловит ни одна проверка.

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

Вывод

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

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

Читайте также

Хотите настроить учёт и тревоги для своего бота или агента — напишите мне в Telegram.