Эксплуатация ИИ-системы: что здесь другое

Обычный сервис падает, ИИ-система портится

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

ИИ-система устроена иначе. Она почти никогда не падает целиком. Она отвечает — вовремя, со статусом 200, в правильном формате JSON, — но отвечает хуже, чем месяц назад. Ни один технический график этого не покажет. Поэтому эксплуатация здесь начинается не с аптайма, а с вопроса «чем мы меряем, что ответы всё ещё хорошие».

Пять отличий, из которых растёт вся дисциплина

Нет единственно верного ответа. Сравнить строку с эталоном нельзя, значит нельзя написать обычный ассерт. Качество приходится описывать через свойства ответа и через долю случаев, где эти свойства выполнены.
Поведение меняется без вашего релиза. Провайдер обновил модель, изменил дефолты, поменял поведение на длинном контексте. Ваш коммит-лог пуст, а система другая.
Каждый запрос стоит денег. Не амортизированных денег за сервер, а прямых, пропорциональных трафику. Плохой релиз здесь бьёт не только по качеству, но и по счёту.
Вход — открытый текст. Пользователь может прислать что угодно, включая инструкции, адресованные вашей модели. Валидация по схеме от этого не спасает.
Ошибка мягкая. Обычный баг даёт неверный результат детерминированно. Здесь система права в 92 процентах случаев, и вся работа — про то, чтобы заметить сползание до 85.

Как это выглядит в календаре команды

Обычный сервис          ИИ-система
--------------------    ---------------------------
релиз -> тесты -> прод  релиз -> прогон набора -> канарейка -> прод
алерт на 5xx            алерт на 5xx + на долю отказов + на расход
инцидент = падение      инцидент = падение ИЛИ сползание качества
откат = откат кода      откат = откат кода, промпта, модели, конфига
дежурство: чинит сбой   дежурство: ещё и решает, откатывать ли качество

Отсюда состав курса: версии и окружения, непрерывное измерение качества, наблюдаемость и разбор инцидентов, деньги и безопасность. Модель, промпты, RAG и агентов мы отдельно не разбираем — для этого есть соседние курсы. Здесь речь о том, как жить с готовой системой месяцами.

Инсайт. Аптайм ИИ-системы почти всегда высокий. Он просто не отвечает на вопрос, работает ли система: 100 процентов успешных вызовов и 60 процентов полезных ответов сосуществуют спокойно.

Частая ошибка. Считать LLMOps набором инструментов. Это набор ответов на вопросы: как узнать, что стало хуже; как вернуться к вчерашнему состоянию; кто отвечает в три часа ночи. Инструменты меняются, вопросы нет.

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

С чего начинается работа над такой системой

Прежде чем ставить графики, ответьте на три вопроса и запишите ответы. Первый: какой ответ мы считаем удачным — не «полезный», а описанный через проверяемые признаки. Второй: какая доля неудачных ответов для нас терпима — 5 процентов, 15, ни одного в денежных сценариях. Третий: за какое время мы обязаны узнать, что вышли за эту долю. Три ответа занимают полстраницы и определяют всё остальное: состав набора оценки, частоту прогонов, пороги алертов и то, кого будят ночью. Команды, которые пропускают этот шаг, полгода спорят о графиках, потому что у чисел нет согласованного смысла.

Шпаргалка

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

1. Чем отказ ИИ-системы чаще всего отличается от отказа обычного сервиса?

2. Почему высокий аптайм не доказывает, что система работает?

3. Что стоит завести в системе раньше дашбордов?

🔒 Ответьте на вопрос верно, чтобы перейти к следующему уроку.