AI-проект через год обычно не ломается — он тихо дешевеет в пользе, пока за него продолжают платить. Система понемногу отвечает хуже, сотрудники всё чаще правят её выводы вручную и не говорят об этом, а потом на планёрке звучит «раньше работало лучше» — и за внедрение приходится платить второй раз. Это не поломка, а нормальное поведение системы, которую не обслуживают: мир вокруг неё меняется, а настройки остаются прежними. Я разберу, что происходит с AI-проектом на первом году, по каким трём показателям это видно раньше жалоб и сколько стоит обслуживание, которое это предотвращает.
Качество падает по четырём причинам, и ни одна не похожа на поломку
Изменились входные данные. Клиенты стали спрашивать про новый продукт, поменялся тон общения, появился новый канал. Модель обучалась и настраивалась на прежнюю картину, а мир уехал.
Изменился процесс. Отдел перешёл на другой скрипт, добавился этап согласования, поменялись критерии оценки. Система продолжает мерить по-старому и формально работает верно — но измеряет уже не то.
Устарела база знаний. Цены изменились, условия акции закончились, регламент обновили — а агент отвечает по документам годичной давности. Самый частый источник жалоб клиентов, и самый обидный, потому что чинится обновлением файла.
Обновился поставщик модели. Модель за API меняется без вашего участия. Обычно в лучшую сторону, но поведение на пограничных случаях может измениться — а ваши промпты были настроены под прежнее.
Деградация выглядит как тишина, а не как ошибка
Проблема в том, что падение качества почти никогда не выглядит как ошибка. Оно выглядит так:
- Менеджеры всё чаще исправляют то, что предложила система, — но никому об этом не говорят.
- Растёт доля обращений, эскалированных на человека, хотя объём не менялся.
- Появляются повторные обращения клиентов по тому же вопросу.
- В разговорах звучит «да мы туда особо не смотрим».
Ни один из этих признаков не попадёт в отчёт об ошибках, потому что ошибок нет: система отвечает, интеграции работают, метрики доступности зелёные. С инфраструктурной стороны это самый неудобный класс проблем: мониторинг сервера показывает, что сервис жив, но ничего не говорит о том, полезен ли он.
Три показателя, которые ловят деградацию раньше жалоб
Достаточно трёх показателей, которые снимаются регулярно и сравниваются с первым месяцем работы. Я бы закладывал их в проект с первого дня, как закладывают резервное копирование: потом добавить можно, но точки отсчёта уже не будет.
Доля верных ответов на фиксированной выборке. Тот самый эталонный набор, собранный при внедрении. Раз в месяц прогнать и сравнить — работа на час-другой, которая показывает изменение на знакомых вопросах раньше, чем его заметят клиенты.
Доля правок за системой. Как часто человек меняет то, что она предложила. Растёт — качество падает, даже если жалоб нет.
Доля эскалаций. Как часто агент передаёт разговор человеку. Резкий рост означает, что он перестал справляться с тем, с чем справлялся.
Подробнее о наборе метрик — в статье про мониторинг агента после запуска.
График обслуживания AI-системы на первый год
Раз в месяц: прогон эталонного набора, разбор жалоб и спорных случаев, обновление базы знаний по изменившимся фактам — цены, условия, сроки.
Раз в квартал: сверка с процессом. Изменилось ли что-то в работе отдела, что система не учитывает. Здесь же — пересмотр критериев оценки, если поменялись приоритеты.
Раз в год: ревизия целиком. Актуальна ли исходная гипотеза, не появились ли новые задачи, не пора ли перевести систему на другую модель. Заодно — проверка, что эталонный набор ещё отражает реальность, а не позапрошлогоднюю.
Как отличить деградацию системы от смены запросов
Жалоба «стало хуже отвечать» описывает два разных явления, и лечатся они противоположным образом. В одном случае система отвечает хуже на те же вопросы — это деградация. В другом она отвечает так же, но вопросы стали другими — это изменение спроса.
Различить их без фиксированной выборки невозможно, и именно поэтому её и заводят в первый месяц: набор реальных вопросов с эталонными ответами, который дальше не меняется. Прогон по нему отвечает на первый вопрос однозначно: если результат тот же, а жалобы есть, значит изменились запросы.
Второй случай требует не настройки, а пополнения: в потоке появились темы, которых раньше не было, и системе просто нечем на них отвечать. Отличать их важно, потому что попытка чинить настройками то, что лечится добавлением фактов, обычно ухудшает ответы на всё остальное.
Что ломается первым при смене продукта или цен
Изменения на стороне бизнеса бьют по системе раньше и заметнее, чем что-либо ещё, и почти всегда об этом узнают последними. Порядок предсказуем.
Первыми устаревают цены и условия: они лежат в базе знаний, меняются приказом и никем не переносятся. Дальше — названия. Продукт переименовали, а система продолжает отвечать старым названием, и клиент не понимает, о чём речь. Затем — правила: изменился порядок возврата, появилось новое ограничение, а сценарий ведёт по-прежнему.
Дешёвая профилактика: включите обновление базы знаний в тот же список действий, что и обновление сайта. Тот, кто меняет цену на странице тарифов, тем же движением меняет её там, откуда берёт ответы система. Пока эти два действия не связаны, расхождение будет появляться каждый раз.
Кто отвечает за обслуживание и что будет, когда он уйдёт
Обслуживание почти целиком состоит из работы с фактами и формулировками — это работа владельца процесса, а не разработчика. Отсюда типичная ошибка: обслуживание записывают в зону ответственности подрядчика, у подрядчика нет доступа к изменениям в бизнесе, и система отстаёт от реальности при формально выполненном договоре.
Второй по частоте сценарий потери — уход человека, который всё это вёл. Обычно он один знает, где лежат промпты, какие правки делались и почему, какие случаи считаются спорными. После его ухода система работает по инерции несколько месяцев, а затем начинает отставать, и починить её оказывается дороже, чем внедрить заново.
Страховка занимает один документ на две страницы: где что лежит, кто имеет доступ, что делается ежемесячно, какие решения принимались и по какой причине. Этот документ обновляется вместе с системой — и он же единственное, что переживает смену людей.
Что делать, если год уже прошёл и всё плохо
Ситуация, в которой обслуживания не было, а качество упало, выглядит безнадёжно и обычно таковой не является. Разбор начинается не с настроек, а с измерения: без числа непонятно, стало хуже на десять процентов или на шестьдесят.
Первый шаг — собрать выборку из реальных обращений за последний месяц, штук пятьдесят, и разметить ответы вручную: верно, неверно, спорно. Это займёт несколько часов и даст точку отсчёта, которой сейчас нет. Второй — разобрать неверные по причинам: устаревший факт, отсутствующий факт, неверное понимание вопроса, ошибка формата.
Дальше почти всегда выясняется, что большинство ошибок относится к одной-двум причинам, и это хорошая новость: обновление устаревших фактов и добавление недостающих закрывается за несколько дней и возвращает основную часть качества. Полная перенастройка требуется реже, чем кажется в начале разбора.
Сколько это стоит и почему дешевле, чем кажется
Регулярное обслуживание занимает несколько часов в месяц и почти целиком состоит из работы владельца процесса, а не разработчиков. Альтернатива — раз в полтора года обнаруживать, что систему тихо перестали использовать, и оплачивать повторное внедрение.
Это та же логика, что с оборудованием: плановое обслуживание всегда дешевле аварийного ремонта, и разница тем больше, чем дольше вы её откладываете. Разница только в том, что сломавшийся станок останавливает цех, а «сломавшаяся» AI-система продолжает бодро выдавать ответы — просто неправильные.
Когда обслуживать не нужно, а проект пора закрыть
Обслуживание имеет смысл, пока система двигает ту метрику, ради которой её внедряли. Бывает, что через год честный ответ — нет, и тогда продолжать платить за поддержку не стоит.
Признаки такого случая другие, чем у деградации. Эталонный набор проходит так же, как в первый месяц, но показатель бизнеса — время ответа, доля закрытых обращений, число потерянных сделок — не изменился с момента запуска. Процесс, под который строилась система, перестроили или отменили. Объём, ради которого автоматизировали, упал настолько, что с ним снова справляется один сотрудник. В этих ситуациях обслуживание не поможет: чинить нечего, система делает то, что умеет, просто это больше не нужно.
Закрыть проект — нормальное решение, а не признание провала. Мы в пилотах 404ai договариваемся об условии остановки заранее, до запуска, именно для того, чтобы через год этот разговор не превращался в спор о вложенных деньгах. Если условие не записано, его стоит сформулировать сейчас: какая цифра должна держаться, чтобы система продолжала работать.
Что заложить в проект до запуска, а не через год
Почти всё, что спасает AI-проект на втором году, делается в первый месяц и стоит дёшево: фиксированная выборка с эталонными ответами, три показателя с точкой отсчёта, владелец процесса с часами на обслуживание в графике, документ на две страницы о том, где что лежит, и записанное условие остановки. Если у вашего проекта чего-то из этого нет, это и есть список работ на ближайшую неделю — независимо от того, кто систему внедрял.
Проверить, в каком состоянии проект сейчас, можно без подрядчика: разметить выборку реальных обращений за последний месяц и сравнить с тем, что система показывала при приёмке. Если разница заметная, дальше работает порядок из раздела выше, если нет — стоит спросить себя, двигает ли система ту цифру, ради которой её запускали. Что именно снимать после запуска и с какой периодичностью — в разборе мониторинга AI-агента; как устроены пилоты с метрикой и условием остановки — на странице о подходе.
