Как обнаружить деградацию функции ИИ?

Функция ИИ деградировала, если пользователь получает меньше пользы от каждой попытки, даже когда все запросы к модели возвращают HTTP 200. Это важное определение. Функция может оставаться технически доступной, хотя ответы стали менее полезными, задержка выросла, вместо нужного результата срабатывает резервный сценарий, расход токенов удвоился, а пользователи молча уходят.

Я видел, как команды объявляли исправление успешным, потому что график ошибок снова стал зеленым, хотя доля завершенных задач продолжала падать. Они измеряли вызов провайдера, а не результат пользователя. Для проверки в продакшене нужна одна запись на запрос, которая связывает весь путь: что хотел сделать пользователь, какие версии приложения и модели обработали запрос, сколько занял каждый этап, что выдала модель, сработал ли резервный сценарий, сколько это стоило и что пользователь сделал дальше.

Шесть групп сигналов отвечают на разные вопросы. Задержка показывает, успевает ли функция ответить, пока результат еще полезен. Доля ошибок находит явные и скрытые сбои. Проверки качества определяют, годится ли ответ для задачи. Частота резервного сценария раскрывает скрытую потерю возможностей. Расход токенов находит неэффективные промпты и циклы. Уход пользователей показывает, когда они перестают ждать или доверять результату. Исправление подтверждено лишь тогда, когда нужные сигналы улучшаются в пострадавшей когорте, а остальные не ухудшаются.

Начните с одного события на попытку пользователя

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

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

Конечное событие может выглядеть так:

{"request_id":"req_7f2c","feature":"support_reply","task":"draft","app_version":"2026.07.4","prompt_version":"p18","model":"model-a","region":"eu-west","input_band":"1k-4k","status":"success","retry_count":1,"fallback":"none","latency_ms":4820,"first_token_ms":910,"input_tokens":1824,"output_tokens":436,"quality":{"policy_pass":true,"schema_pass":true,"grounded":"unknown"},"user_action":"accepted","action_delay_ms":6400}

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

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

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

Хвост задержки раскрывает сбой под нагрузкой

Деградация задержки обычно появляется в хвосте раньше, чем меняет среднее. Следите за медианой, p90, p95 и p99 полной задержки, а для потоковых ответов еще и за временем до первого токена. Медиана описывает обычный запрос. Верхние процентили показывают очереди, лимиты, холодный запуск, длинный контекст, повторы и небольшой регион или класс клиентов, который скрывает среднее.

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

Определяйте цель обслуживания по терпению пользователей, а не по удобному круглому числу. Для подготовки текста можно потребовать, чтобы 95% подходящих попыток показывали первый полезный токен в пределах измеренного окна терпения. Для фонового извлечения важнее полное время. Берите пороги из базового поведения и продуктовых исследований, не копируйте их у другой функции.

Гистограммы Prometheus позволяют агрегировать процентили, если границы корзин соответствуют решению. Документация Prometheus предупреждает, что клиентские summaries и серверные гистограммы агрегируются по-разному. Для классической гистограммы подойдет такой запрос по версии:

histogram_quantile(0.95,
  sum by (le, app_version) (
    rate(ai_feature_duration_seconds_bucket{feature="support_reply",status="success"}[10m])
  )
)

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

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

После исправления сравните распределения пострадавшего сегмента и неизменного контроля. Для хвоста нужно достаточно наблюдений: p99 из нескольких попыток ничего не доказывает. Одновременно проверьте рост повторов и глубину очереди. Снижение p95 за счет более короткого тайм-аута и большего числа брошенных запросов, это обмен, а не исправление.

Считайте скрытые сбои вместе с исключениями

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

Используйте взаимоисключающие конечные статусы, чтобы знаменатель оставался честным. Начните с success, user_error, system_error, policy_block и abandoned, а ниже храните точную причину. Письменно решите, считается ли частичный результат успехом. Отчет без обязательного раздела может быть частичным успехом в редакторе и системной ошибкой при автоматическом экспорте.

Базовая проверка: неудачные подходящие попытки / все подходящие попытки. Ошибки пользователя, например неподдерживаемый файл, отклоненный до инференса, не включайте в числитель надежности, но показывайте отдельно. Их рост может означать непонятный интерфейс или новую смесь входов. Показывайте долю и количество вместе. Один сбой из двух и пятьсот из миллиона создают противоположные проблемы, которые один процент описывает плохо.

Повторам нужна своя доля и распределение числа попыток. Amazon Builders' Library объясняет, что повторы нагружают уже перегруженную зависимость, а повторы на нескольких уровнях умножают работу. Для медленных и дорогих вызовов ИИ это особенно болезненно. Записывайте уровень повтора, ограничивайте попытки, применяйте задержку со случайным разбросом и сохраняйте исходную ошибку, даже если следующий вызов успешен.

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

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

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

Качеству нужны поздняя истина и живые косвенные сигналы

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

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

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

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

Рекомендации Google по ML в продакшене проводят важное различие: фактическая метка часто приходит поздно или не приходит, поэтому нужны косвенные метрики, а их изменение полезнее отдельного значения. Для генерации подходят доля валидной схемы, подтвержденных цитат, объем правок до принятия, повторная генерация, копирование или принятие, жалобы и завершение следующей задачи. Ни одна метрика не универсальна. Частое копирование может означать отличный черновик или перенос текста в другое место для ремонта.

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

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

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

Резервный сценарий скрывает потерю возможностей

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

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

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

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

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

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

Расход токенов должен следовать за завершенным результатом

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

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

Соглашения GenAI от OpenTelemetry определяют атрибуты токенов и длительности с разделением входа и выхода. Это хороший транспортный словарь. Приложение все равно должно связать расход с accepted, edited, regenerated, abandoned или другим ценным результатом.

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

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

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

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

Уход связывает здоровье системы с терпением

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

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

Инструментируйте браузер и сервер одним ID. Записывайте отправку, первый видимый токен, полезный результат, отмену, переход, повтор, принятие, правку и следующее завершение. Клиентские события теряются при закрытии вкладки, поэтому при необходимости используйте heartbeat или доставку типа sendBeacon и отмечайте неопределенность. Не называйте каждое пропавшее событие потерянным пользователем.

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

Измеряйте повторную генерацию и исправления. Пользователь может дождаться плохого ответа и повторить, а не уйти. Объединяйте abandoned, cancelled и regenerated_before_use в широкий вид неудачных попыток, сохраняя компоненты. Принятие без правки полезно, но обязательный процесс и случайный клик искажают его.

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

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

Сначала сегментируйте, потом агрегируйте

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

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

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

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

Парадокс Симпсона встречается часто. Каждая задача может замедлиться, а общая средняя улучшиться из-за перехода трафика к быстрой задаче. Обратная ситуация осудит хороший релиз, которому достались сложные входы. Сначала смотрите изменения внутри задач.

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

Малые срезы требуют осторожности. Показывайте интервалы или неопределенность, задавайте минимум наблюдений и объединяйте соседние окна. Не игнорируйте серьезный сбой из-за малой выборки: изучите примеры и примените жесткое правило безопасности. Статистическая уверенность и операционная тяжесть отвечают на разные вопросы.

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

Исправление проходит только по письменному критерию

Исправление завершено, когда заранее заданное сравнение показывает восстановление сломанного сигнала, защищает остальные и выдерживает реальный трафик достаточно долго для воспроизведения сбоя. «График выглядит лучше» не критерий приемки. Запишите правило до выпуска, чтобы команда не выбрала удобное окно позже.

Используйте такую последовательность:

1. Зафиксируйте когорту инцидента. Запишите функцию, задачу, версии, маршрут модели, регионы, диапазоны входа и окно. Сохраните характерные ID без чувствительных данных.
2. Опишите сбой измеримо. Укажите главную метрику, базу, наблюдаемое значение, порог и минимальную выборку. Добавьте ограничения ошибок, качества, резерва, стоимости результата и ухода.
3. Выпустите детерминированную канарейку. Проверьте полноту телеметрии до оценки кода. Кандидат и контроль должны получать сходный трафик, каждая попытка, конечный статус.
4. Сравните распределения и примеры. Сначала кандидат и контроль, затем оба с историей. Проверьте парные проблемные задачи или фиксированный набор, чтобы агрегат не скрыл исходный дефект.
5. Продвигайте, удерживайте или откатывайте по записанному правилу. Наблюдайте следующий значимый цикл трафика, затем сохраните результаты запросов, версии и решение.

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

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

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

При высоком риске выполните теневую оценку или replay, но не называйте это доказательством продакшена. Replay не воспроизводит живые очереди, лимиты, браузер, меняющийся поиск и реакции пользователей. Он снижает неопределенность до канарейки, но не заменяет ее.

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