Что такое LLMOps-мониторинг
Обычный сервис мониторят по метрикам доступности и ошибок. С ИИ-сервисом этого мало: сервис может формально отвечать «200 OK», но молча деградировать — отвечать не на то, терять факты после смены промпта, дорожать после перехода на новую модель, замедляться на длинных контекстах. LLMOps-мониторинг — это слой наблюдаемости именно за ИИ-частью: что пришло на вход (промпт, найденный контекст), что модель ответила, сколько это стоило и заняло, и как всё это меняется во времени.
Отдельно подчеркнём границу с безопасностью: журналы для SIEM и детекты атак на LLM — соседний, но другой контур, он разобран в нашем материале про логи LLM в SIEM. LLMOps-мониторинг отвечает за качество и эксплуатационные показатели; на практике оба контура живут рядом и обмениваются событиями.
Что измеряем
- Трейсы генераций: полный путь запроса — промпт, retrieved-фрагменты, ответ, промежуточные вызовы инструментов; без трейсов разбор инцидента превращается в гадание.
- Латентность: перцентили p50/p95, отдельно — время поиска по базе знаний и время генерации.
- Токены и стоимость: расход по сценариям и пользователям; внезапный рост среднего числа токенов — ранний признак деградации промптов.
- Ошибки и отказы: сбои вызовов, таймауты, срабатывания guardrails — из материала про guardrails-фреймворки.
- Качество: оценки пользователей (плюс/минус), результаты автоматических проверок на контрольных запросах, дрейф распределений ответов.
- Утилизация инфраструктуры: для self-hosted моделей — GPU-пул и очередь, связка с материалом про GPU-кластеры.
Открытый стек и стандарт трассировки
Основа нашей независимости от вендоров — семантические конвенции GenAI в OpenTelemetry: открытый стандарт, описывающий, как трассировать вызовы генеративных моделей (промпты, параметры, токены, стоимость). Инструментация по OTel позволяет сменить бэкенд наблюдаемости, не переписывая приложение. Сам бэкенд — открытые решения, развёрнутые в контуре заказчика: Langfuse (ядро продукта распространяется под MIT, отдельные enterprise-функции — под коммерческой лицензией проекта) — трейсы, датасеты, метрики качества и управление промптами; Phoenix от Arize (лицензия Elastic License 2.0 — ограничение: решение нельзя предоставлять третьим лицам как управляемый сервис, для внутреннего использования препятствий нет) — трейсы и оценки с акцентом на интеграцию с аналитику в ноутбуках. Выбор инструмента — по задачам и ландшафту заказчика; трейсы при этом остаются в его контуре.
Как применяем: контур мониторинга
- Инструментация. Оборачиваем вызовы моделей и поиска OTel-спанами по конвенциям GenAI: каждый запрос получает сквозной трейс.
- Сбор и хранение. Разворачиваем бэкенд (Langfuse/Phoenix) в контуре заказчика; трейсы содержат чувствительные данные — поэтому self-hosted, а не SaaS.
- Маскирование на входе. Персональные данные в трейсах маскируются на ingest по методикам из материала про анонимизацию данных для LLM — наблюдаемость не должна становиться новым каналом утечки.
- Датасеты и автопроверки. Контрольный набор запросов прогоняется по расписанию; ответы оцениваются автоматическими метриками — методика в материале про оценку качества LLM.
- Алерты и дашборды. Пороги по латентности, стоимости, доле отказов и метрикам качества; владельцы процесса узнают о деградации раньше пользователей.
- Управление изменениями. Версионирование промптов и конфигураций; каждое изменение проходит регрессионный прогон на датасете до релиза.
Текстовая схема: запрос → OTel-спаны (вызов LLM, поиск, инструменты) → бэкенд трейсов (Langfuse/Phoenix, self-hosted) → метрики и алерты → дашборды владельцам → регрессионные прогоны при изменениях.
| Формат | Цена | Срок |
|---|---|---|
| Аудит ИИ-сервиса и карта метрик | от 90 000 ₽ | 1 неделя |
| Пилот: инструментация + бэкенд трейсов + алерты | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: датасеты, регрессии, SLA-отчётность | от 690 000 ₽ | 4–6 недель |
| Мульти сервисный контур с управлением промптами | 0,9–1,2 млн ₽ | 6–8 недель |
Дрейф качества и регрессии
Главная практическая ценность контура — ловля тихих деградаций. Причины разные: обновилась модель у провайдера (без вашего ведома), поменялось содержимое базы знаний и retrieval стал находить другое, «улучшили» промпт и сломали смежный сценарий, пользователи стали задавать вопросы нового типа. Без базовой линии и регрессионных прогонов всё это обнаруживается по жалобам — то есть постфактум и анекдотично. С контуром — графиком и таблицей: что изменилось, когда и после какого изменения. Правило эксплуатации: ни одно изменение промпта, модели или корпуса не уходит в бой без прогона контрольного датасета — это программная дисциплина, а не героизм.
Стоимость самого мониторинга
Наблюдаемость тоже стоит ресурсов: хранение трейсов, автопроверки на датасетах, обслуживание бэкенда. Мы управляем этим сэмплированием: полные трейсы — для инцидентов и выборки трафика, агрегаты — для всего потока; чувствительные поля маскируются или обрезаются, сроки хранения фиксируются политикой. Накладные расходы контура измеряются на нагрузочных испытаниях и включаются в общий расчёт стоимости обслуживания сервиса — сюрпризов в конце месяца не бывает. Отдельно смотрим долю автоматических проверок: каждая регулярная автопроверка на датасете — это расход токенов, и её периодичность должна соответствовать скорости изменений в сервисе.
Тонкости, которые всплывают в проектах
Первая — объём: трейсы с полными промптами и ответами тяжёлые; без сэмплирования и ротации хранения бэкенд распухает за недели. Вторая — чувствительное в трейсах: промпты несут персональные данные и коммерческие тайны; маскирование на входе — не опция, а требование. Третья — метрики качества «на автомате» обманчивы: автоматическая оценка — это screening, а не истина; калибровка по ручной разметке периодически обязательна. Четвёртая — организационная: у метрик должен быть владелец; алерт, на который никто не смотрит, — это не мониторинг, а самоуспокоение.
Каталог сценариев и управление промптами
Когда ИИ-сценариев становится больше трёх, встаёт вопрос учёта: что за сценарии, чьи они, какие модели и промпты используют, где их метрики. Мы ведём каталог: карточка сценария — владелец, цель, модель, версия промпта, SLA, ссылки на дашборды и датасеты. Это скучная гигиена, которая окупается в первый же инцидент: вместо «кажется, это бот клиентов, спросите кого-нибудь» — точный ответ, какая версия с каким промптом работала в момент проблемы.
Управление промптами — вторая половина дисциплины: версии промптов хранятся в системе (у того же Langfuse), изменения проходят через регрессионный прогон, откат на предыдущую версию — операция минут, а не вечера. Промпт — это код со всеми следствиями: ревью, история, тесты.
Инцидент-менеджмент ИИ-сервиса
Разбор инцидента с ИИ-сервисом без трейсов — гадание: «модель ответила странно» имеет десяток причин, от плохого поиска по базе знаний до обновления модели провайдером. С контуром мониторинга инцидент разбирается по схеме: трейс конкретного запроса → найденный контекст и промпт → метрики вокруг времени инцидента → последнее изменение (промпт, модель, корпус) из журнала релизов. По итогам — новый тест-кейс в контрольный набор и, при необходимости, пороговый алерт: инцидент должен случиться один раз, а не каждый квартал.
Как стартуем
- Покажите текущий ИИ-сервис (или архитектуру) — за неделю соберём карту метрик и целевой SLA.
- Пилот: инструментация, бэкенд трейсов в вашем контуре, первые алерты и базовая линия качества — от 480 000 ₽ за 4–6 недель.
- Дальше — регрессионный контур и управление промптами по мере роста парка сценариев.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.