Почему ИИ ошибается: как настроить мониторинг ИИ-ассистента после запуска

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

Ошибка ИИ не всегда возникает в модели

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

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

У неправильного результата есть как минимум семь возможных источников:

1. Входные данные. Пользователь не указал важное условие, объединил несколько задач или сформулировал запрос неоднозначно.
2. Корпоративные знания. В базе нет ответа, документы устарели или противоречат друг другу.
3. Поиск. Система нашла неподходящий фрагмент либо применила неверный фильтр доступа.
4. Модель и инструкция. Модель неверно интерпретировала контекст, пропустила ограничение или вернула неподходящую структуру.
5. Инструмент или интеграция. CRM, база данных или внешний API вернули неполные либо несвоевременные данные.
6. Бизнес-правило. Технически допустимый результат не соответствует реальному процессу.
7. Передача человеку. Ассистент продолжил работу там, где должен был остановиться и передать задачу сотруднику.

Неправильный ответ — это симптом. Исправлять нужно тот слой системы, в котором возникла причина.

Фраза «нейросеть опять придумала ответ» объединяет все причины в одну. После такого диагноза команда обычно меняет промпт и надеется, что следующая версия будет вести себя лучше. Это не управление качеством, а перебор гипотез без наблюдаемых данных.

Что должна показывать трасса ИИ-ассистента

Почему обычных технических логов недостаточно

В традиционном приложении команда следит за доступностью, задержкой, нагрузкой и исключениями. Эти показатели нужны и ИИ-системе, но они не показывают, правильно ли решена задача.

Microsoft выделяет три связанные части наблюдаемости генеративных систем: оценку качества, производственный мониторинг и распределённую трассировку.[1] Трассировка показывает вызовы модели, инструментов и зависимых сервисов; мониторинг — задержку, расход токенов, технические ошибки и оценки качества. Один запуск агента может включать несколько обращений к модели, поиск по документам, повторные попытки и последовательные действия. Ошибка верхнего уровня часто появляется внутри одного из вложенных шагов.[2]

Практически полезно разделять четыре сущности:

• лог фиксирует отдельное событие;
• метрика показывает, как часто и в каком объёме что-то происходит;
• трасса связывает события одного запуска в последовательность;
• оценка отвечает, насколько хорошо выполнена задача.

Один журнал сообщений не заменяет всё остальное.

Один запуск — одна связанная история

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

Этап	Что сохранять	Зачем
Начало	run_id, время, сценарий, среда, версия приложения	Найти запуск и связать события
Пользовательский контекст	роль, подразделение, канал, обезличенный идентификатор	Проверить доступ и область применения
Конфигурация	модель, версия инструкции, параметры сценария	Понять, после какого изменения появилась ошибка
Поиск	идентификаторы и версии документов, фильтры, оценки релевантности	Установить, какие знания получила модель
Вызов модели	длительность, токены, причина завершения, статус	Оценить стоимость и техническое поведение
Инструменты	операция, замаскированные параметры, результат, повторы	Восстановить фактические действия
Ограничения	проверки прав, валидация, подтверждение человеком	Увидеть, какие защитные правила сработали
Итог	статус задачи, эскалация, исправление сотрудником	Связать трассу с бизнес-результатом

OpenTelemetry развивает общие соглашения для телеметрии генеративных систем. Они охватывают сведения о модели, расход токенов, причины завершения, найденные документы, вызовы инструментов и результаты.[3] Общий формат упрощает сопоставление событий и уменьшает зависимость наблюдаемости от одного поставщика модели.

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

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

Полные промпты, ответы, документы и аргументы инструментов делают расследование удобнее, но могут содержать имена, контакты, условия договоров, содержимое заявок и служебные инструкции. OpenTelemetry отдельно помечает поисковые запросы, системные инструкции, аргументы и результаты инструментов как потенциально чувствительные данные.[3]

Безопасный порядок выглядит так:

1. По умолчанию сохранять метаданные и технические идентификаторы.
2. Маскировать секреты, контакты и персональные поля до отправки в систему наблюдаемости.
3. Включать полное содержимое только для ограниченной выборки или специального режима отладки.
4. Разделить доступ к техническим метрикам и содержимому обращений.
5. Установить срок хранения для разных классов данных.
6. Проверять, что удаление исходного документа распространяется на диагностические копии.

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

Какие метрики и оповещения действительно нужны

Большая панель с десятками графиков не делает ИИ управляемым. Метрики должны отвечать на три разных вопроса.

Работает ли технический контур

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

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

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

Для оценки качества нужны показатели, связанные с поведением сценария:

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

Одна средняя оценка опасна. Критическая операция без подтверждения не должна растворяться среди сотен хороших справочных ответов.

Улучшился ли бизнес-процесс

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

Google предлагает близкое разделение производственных KPI: операционная надёжность, встраивание в рабочий процесс и измеримая бизнес-ценность.[4] Пороговые значения нельзя копировать из чужого кейса: они зависят от стоимости ошибки. Для внутреннего поиска по справочным материалам подходит один режим, для отправки коммерческого предложения или изменения данных клиента — другой.

Когда отправлять срочное оповещение

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

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

Как расследовать ошибку и не повторить её

Когда пользователь сообщает о неправильном результате, разбор удобно вести в шесть шагов.

1. Найдите полный запуск. Нужны run_id, время, пользовательский контекст и версия системы, а не только скриншот ответа.
2. Определите ожидаемый результат. Зафиксируйте, что ассистент должен был сделать: ответить, уточнить, отказаться, создать задачу или передать обращение человеку.
3. Пройдите трассу от данных к действию. Проверьте исходный запрос, доступный контекст, найденные документы, версию инструкции, структурированный ответ модели, инструменты, внешние системы и программные проверки.
4. Назовите класс ошибки. Например: нет данных, устаревший источник, ошибка поиска, неверный инструмент, повторная операция, нарушение доступа или пропущенная эскалация.
5. Исправьте нужный слой. Старый документ требует изменения жизненного цикла базы знаний; недопустимая категория — проверки структуры; дубль в CRM после повтора — идемпотентности операции, а не нового промпта.
6. Добавьте случай в регрессию. После исправления сценарий должен проверяться перед следующим выпуском.

Мониторинг должен пополнять тестовый набор

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

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

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

Когда достаточно обычного мониторинга

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

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

Для RAG-систем отдельно измеряют качество поиска и итогового ответа — подробнее об этом в руководстве по тестированию RAG-чат-бота. Если агент выполняет действия в CRM, трассировку дополняют минимальными правами, программным шлюзом и подтверждением опасных операций. Эти меры описаны в статье о безопасности ИИ-агента в CRM.

С чего начать мониторинг на пилоте

Не начинайте с выбора платформы наблюдаемости. Возьмите один сценарий и ответьте на семь вопросов:

1. Как выглядит успешное завершение задачи?
2. Какие ошибки недопустимы независимо от среднего качества?
3. Какие данные и версии влияют на результат?
4. Какие инструменты может вызвать система?
5. Где обычный код проверяет решение модели?
6. В какой момент задача передаётся человеку?
7. Какие события потребуются для расследования?

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

ИИ ошибается не в одном месте. Ошибку может создать весь контур: данные, поиск, модель, инструменты, правила и передача человеку. Поэтому контролировать нужно путь выполнения бизнес-задачи, а не только доступность API и красивый финальный ответ.

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

Почему ИИ иногда ошибается при одинаковом запросе?

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

Можно ли сделать чат-бота без ошибок?

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

Нужно ли сохранять все промпты и ответы?

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

Какая метрика качества ИИ самая важная?

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

Источники

1. Observability in generative AI — Microsoft Learn, обновлено 3 апреля 2026 года.
2. Agent tracing in Microsoft Foundry — Microsoft Learn, обновлено 27 марта 2026 года.
3. Generative AI semantic conventions — OpenTelemetry, проверено 31 июля 2026 года.
4. The KPIs that actually matter for production AI agents — Google Cloud, 26 февраля 2026 года.
5. From “Vibe Checks” to Continuous Evaluation — Google Cloud, 27 февраля 2026 года.
6. AgentOps: Operationalize agentic AI at scale with Amazon Bedrock AgentCore — AWS, 1 июня 2026 года.