Почему обычного uptime недостаточно для ИИ
Сервис может отвечать с HTTP 200 и при этом давать устаревшие сведения, выбирать неверный инструмент, пропускать обязательную проверку или тратить в несколько раз больше токенов. Традиционный мониторинг видит доступность API, но не всегда видит качество решения.
Наблюдаемость ИИ соединяет логи, метрики, traces, оценки качества и обратную связь пользователя. Она должна позволить ответить: какой workflow сломался, на каком шаге, для какого сегмента, после какого изменения и с каким риском.
Логи, метрики и traces отвечают на разные вопросы
| Сигнал | Вопрос | Пример |
|---|---|---|
| Метрика | Что меняется во времени? | Error rate, p95 latency, tokens per task |
| Лог | Какое событие произошло? | Validator отклонил поле date |
| Trace | Где прошёл конкретный запрос? | Retrieval → model → tool → approval |
| Eval | Насколько результат соответствует критерию? | Grounding, correctness, policy pass |
| Feedback | Что произошло с пользователем? | Исправление, эскалация, отказ |
Не пытайтесь заменить один сигнал другим. Trace объясняет конкретный сбой, метрики показывают масштаб, а eval проверяет смысл результата.
Начните с карты workflow и границ ответственности
Нарисуйте путь от пользовательского действия до бизнес-результата. Для RAG это подготовка запроса, поиск, reranking, сбор контекста, генерация, citation validation и выдача. Для агента добавляются планирование, tools, approvals, handoffs и внешние побочные эффекты.
- Название workflow и владелец.
- Начало и успешный бизнес-результат.
- Все внешние зависимости.
- Модель, prompt, retrieval и tools.
- Guardrails и точки подтверждения.
- Критические ошибки каждого шага.
- Безопасный fallback и откат.
- Данные, которые запрещено сохранять.
- SLO и канал реагирования.
Trace и spans: скелет расследования
Trace представляет одну сквозную операцию, spans - отдельные шаги со временем начала, окончания, статусом и связью parent-child. OpenAI Agents SDK, например, трассирует генерации, function calls, handoffs, guardrails и custom events. OpenTelemetry задаёт общие семантические атрибуты для GenAI-операций.
Какие атрибуты сохранять на каждом запуске
Минимум: trace ID, workflow, environment, tenant или сегмент в безопасном виде, версии приложения, prompt, модели, схемы и индекса, provider request ID, статус, длительность, usage, число попыток и код результата.
Для агента добавьте имя tool, результат approval, error category и признак побочного эффекта. Для RAG - data source, retrieval count, версию корпуса и результат citation check. Не помещайте user ID и полный текст в labels метрик: высокая cardinality делает систему дорогой и неудобной.
Спроектируй telemetry schema для ИИ-workflow. Шаги: [перечень]. Риски данных: [классы]. Нужные расследования: [вопросы]. Раздели поля на metric labels, trace attributes, structured logs и запрещённый content. Для каждого укажи тип, cardinality, необходимость redaction, срок хранения и пример запроса, который это поле помогает расследовать.
Метрики надёжности: отделите провайдера от приложения
| Слой | Метрики | Причина |
|---|---|---|
| API модели | Timeout, rate limit, provider error | Внешняя зависимость |
| Parsing | Invalid JSON, schema mismatch | Контракт ответа |
| Retrieval | Empty result, denied source, stale index | Контекст |
| Tools | Call error, invalid args, duplicate action | Интеграция |
| Workflow | Success, fallback, handoff, abandonment | Пользовательский результат |
Одна метрика errors смешивает причины и затрудняет реакцию. Используйте стабильную таксономию error_code и храните исходное сообщение отдельно с фильтрацией секретов.
Latency: смотрите путь и percentiles
Среднее время ответа скрывает длинный хвост. Отслеживайте p50, p95 и p99 по workflow и сегменту, time to first token для streaming, полное время, очередь, retrieval, каждую генерацию и tools.
Большая задержка может появиться не в модели: медленный поиск, последовательные вызовы, повтор после schema error или зависший внешний API. Waterfall trace показывает вклад каждого span. Устанавливайте timeout на шаг и общий deadline workflow.
Токены и стоимость: считайте на полезный результат
Собирайте input, output и доступные cache-token категории по каждому вызову, затем агрегируйте стоимость на workflow, пользователя, сегмент и успешный бизнес-результат. OpenTelemetry GenAI attributes предусматривают usage для input, output и cache.
- Стоимость успешной операции.
- Стоимость failed и abandoned runs.
- Доля повторов и лишних agent turns.
- Контекст на один retrieval result.
- Изменение после версии prompt или модели.
Тарифы меняются: храните использованную таблицу цен с датой или рассчитывайте стоимость в аналитическом слое, не превращая старые traces задним числом в новые расходы.
Качество в production: proxy-сигналы и проверенные оценки
Клики, повторный запрос и thumbs up - полезные, но шумные proxy. Пользователь может принять убедительную ошибку. Комбинируйте их с автоматическими validators, выборочным human review и calibrated LLM graders.
Мониторинг RAG: где теряется доказательство
Записывайте версию индекса, фильтры доступа, query rewrite, идентификаторы найденных документов, scores, reranking и citation validation. Содержимое документа по умолчанию не обязательно сохранять: часто достаточно ID и разрешённого excerpt либо hash.
- Доля пустых retrieval results.
- Количество найденных и использованных фрагментов.
- Версия корпуса и время последнего обновления.
- Отказы фильтра прав доступа.
- Ответы без проверяемой citation.
- Утверждения, не поддержанные контекстом.
- Сегменты с низкой retrieval relevance.
- Вопросы без ответа в базе.
Мониторинг агентов: tools, loops и побочные эффекты
Агент может получить хороший финальный ответ неэффективным или опасным путём. Считайте turns, tool calls, повторные вызовы, handoffs, guardrail triggers, approvals и фактические side effects.
| Сигнал | Что может означать |
|---|---|
| Резкий рост turns | Loop, плохая инструкция или недоступный tool |
| Повтор tool с теми же args | Нет идемпотентности или потерян результат |
| Tool call после отказа approval | Нарушена граница контроля |
| Много handoffs | Неясная маршрутизация |
| Финал без результата tool | Возможна выдумка об успешном действии |
Безопасность traces и логов
OpenTelemetry предупреждает, что retrieval query, system instructions, tool arguments и tool results могут содержать чувствительную информацию. OpenAI Agents SDK также позволяет управлять включением потенциально чувствительных входов и выходов в trace.
- Не писать полный content без утверждённой цели.
- Редактировать токены, пароли, контакты и идентификаторы.
- Разделить доступ к метаданным и содержимому.
- Шифровать transport и storage.
- Ограничить retention по классу данных.
- Аудировать доступ к traces.
- Не использовать production content в тестах автоматически.
- Поддерживать удаление данных субъекта, если применимо.
- Проверить политику стороннего tracing-провайдера.
Версии: без них график не объясняет причину
Каждый trace связывайте с версиями приложения, prompt, модели, tool definitions, guardrails, output schema, retrieval index и evaluator. Provider может вернуть фактически обслужившую модель - сохраняйте request и response model отдельно, когда API это поддерживает.
При rollout добавляйте cohort: control, canary или candidate. Тогда рост ошибок можно сопоставить с изменением, а не гадать по времени deploy.
SLO и алерты: сигнал должен требовать действия
SLO описывает допустимый уровень сервиса за окно времени. Для ИИ нужны не только availability и latency, но и критические бизнес-нарушения. Не ставьте alert на каждую отдельную плохую оценку: используйте severity, burn rate и минимальный объём, а опасные действия ловите немедленно.
Составь черновик SLO и alert policy для ИИ-workflow. Пользовательский результат: [описание]. Критические нарушения: [список]. Метрики и сегменты: [список]. Рабочее время и on-call: [условия]. Для каждого сигнала предложи SLI, окно, severity, минимальный объём, владельца, ссылку на dashboard и первое безопасное действие. Пороги оставь параметрами для согласования на baseline, не придумывай цифры.
Dashboard: от руководителя к trace
Первый уровень показывает бизнес-результат, объём, success/fallback/handoff, стоимость и критические инциденты. Второй - breakdown по workflow, версии, сегменту и error class. Третий ведёт к конкретным traces и безопасным логам.
Не помещайте десятки графиков на один экран. У каждой панели должен быть вопрос: «ухудшилось ли качество после релиза», «где растёт стоимость», «какой tool создаёт ошибки».
Incident response для ИИ
- Обнаружить. Подтвердить сигнал и затронутый workflow.
- Ограничить. Отключить tool, перейти на fallback, остановить rollout или потребовать human approval.
- Сохранить доказательства. Trace IDs, версии и безопасные образцы.
- Оценить влияние. Пользователи, данные, действия и временной диапазон.
- Исправить. Prompt, validator, index, model или integration.
- Проверить. Воспроизвести на regression case и canary.
- Предотвратить. Добавить eval, alert и обновить playbook.
NIST AI RMF включает operation and monitoring в жизненный цикл AI и рекомендует документировать показатели, наблюдаемые в production. Пост-инцидентный разбор должен улучшать не только код, но и eval-набор.
План внедрения за четыре недели
Финальный чек-лист production observability
- Определён пользовательский результат workflow.
- Есть end-to-end trace и spans важных шагов.
- Trace ID проходит через все сервисы.
- Ошибки имеют стабильную таксономию.
- Latency измеряется по percentiles и шагам.
- Usage и стоимость связаны с результатом.
- Quality оценивается по сегментам.
- RAG хранит версии корпуса и retrieval metadata.
- Агент логирует tools, approvals и side effects.
- Все компоненты имеют версии.
- Чувствительный content исключён или редактируется.
- Доступ и retention утверждены.
- SLO и алерты имеют владельца.
- Каждый alert ведёт к dashboard, traces и playbook.
- Есть безопасный fallback и rollback.
- Инциденты превращаются в regression evals.
Хороший мониторинг не пытается сохранить всё. Он собирает минимально достаточные доказательства, чтобы быстро увидеть влияние, найти причину и безопасно восстановить пользовательский результат.