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