Обслуживание ИИ-агента после запуска

Обслуживание ИИ-агента нельзя считать уборкой хвостов: это и есть сама работа. Агент, который прошёл все тесты на запуске, может заметно ухудшиться в продакшене, хотя никто не трогал ни промпт, ни защитное правило, ни строчку кода. Рецензируемое исследование в журнале Scientific Reports издательства Nature соединило четыре модели машинного обучения с 32 реальными наборами данных из здравоохранения, финансов, транспорта и метеорологии, а затем отследило, как каждое сочетание держится по мере того, как проходит время с момента последнего обучения. Качество падало в 91% из 128 сочетаний, и этот эффект авторы назвали старением ИИ. Лечение здесь не в более удачной модели. Лечение в цикле проверок, у которого есть хозяин.

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

Почему ИИ-агент становится хуже после запуска?

Деградируют четыре вещи, и деградируют они независимо друг от друга. Большинство команд следит только за одной.

Что деградирует	Как это выглядит	Как это поймать
Поведение модели	Тот же вопрос, тот же промпт, а ответ хуже, и звучит он так же уверенно, как правильный	Прогоняйте фиксированный набор тестов по расписанию и сравнивайте оценки
Ваши знания	Агент безошибочно цитирует правило, цену или часы работы, которые вы поменяли в прошлом месяце	Ставьте дату на записях в базе знаний и пересматривайте их с понятной периодичностью
Ваш бизнес	Новая услуга, новая точка, сезонные часы работы, закончившаяся акция	Привязывайте обновление знаний к тому изменению в работе, которое его вызвало
Границы задач	Агенту начинают поручать задачи длиннее и сложнее тех, под которые его задумывали	Следите за долей передач человеку и за тем, какие типы задач приходят

Первая строка обычно удивляет. Anwar Ali в колонке для HousingWire называет это поведенческим дрейфом и отделяет его от дрейфа данных, про который слышало большинство команд. Поведенческий дрейф поймать труднее, потому что в ухудшившемся ответе ничто не выглядит ухудшившимся.

Как дрейф выглядит в реальном внедрении?

Anwar Ali, старший вице-президент и глава продуктового направления в BSI Financial Services, описал ровно этот случай в сентябре 2026 года. Его команда запустила голосового и чат-агента, который отвечал на вопросы заёмщиков по живым данным счетов, за комплаенс-ограничителями, на настройку которых ушло немало времени. Это работало. Доля самостоятельно закрытых обращений, то есть клиентов, чей вопрос решился без участия человека, месяцами держалась выше среднего по отрасли.

Потом она упала примерно на восемь пунктов. Несколько недель этого никто не замечал.

Разбирательство сняло подозрения с ограничителей, со сценария разговора и с изменений в поведении клиентов. Причиной оказалась сама модель, зрелая модель ведущей лаборатории, которая тихо начала хуже отвечать на те же категории вопросов. Его вывод стоит позаимствовать: это был провал измерения, а не провал технологии. Эту долю проверяли раз в неделю, а недельный запаздывающий показатель не способен поймать медленное сползание, пока через него не пройдёт много клиентов.

За какими цифрами следить и как часто?

Возьмите небольшой набор, назначьте каждой метрике свою частоту и сделайте эту частоту короче окна, в котором копится ущерб. Метрика, которую смотрят раз в месяц, сначала подарит вам плохой месяц и только потом сигнал. Это операционные метрики, а не метрики отдачи; про финансовую сторону читайте в материале как измерять окупаемость ИИ, когда у большинства проектов её нет.

Метрика	Частота	Что означает плохое движение
Доля передач человеку	Ежедневно	Агент чаще отказывает или не справляется, либо изменились сами вопросы
Время первого ответа	Ежедневно	Проблема с доставкой или очередью, а не с качеством
Решение без передачи человеку	Ежедневно	Классический индикатор дрейфа. Смотрите на тренд, а не на день
Доля дизлайков на ответы ИИ	Еженедельно	Ваша команда видит то, что прячут сводные цифры
Доля записей или продаж из переписок	Еженедельно	Агент отвечает, но больше не доводит до сделки
Оценка на регрессионном наборе тестов	Ежемесячно и при каждой смене модели	Модель или конфигурация сдвинулись без вашего ведома

Время первого ответа заслуживает места в этом списке, хотя дрейфует редко. Наше собственное исследование 32,581 переписки показало, что ответы в пределах 60 секунд конвертировались в 35.1%, против 7.1% у ответов, на которые уходило от часа до суток. Скорость это то, ради чего агента и покупают, поэтому именно её стоит регулярно подтверждать.

Как часто нужно перепроверять ИИ-агента?

Держите фиксированный регрессионный набор реальных переписок с заранее известными правильными исходами и прогоняйте его по трём поводам:

По расписанию, минимум раз в месяц. Именно это превращает дрейф в цифру, а не в догадку.
До и после любой смены модели, включая ту, которую начали не вы. Если ваша платформа переезжает на более новую модель, это изменение в вашей системе.
После любой заметной правки знаний или инструкций. Исправление под одну жалобу часто ломает ответ, с которым всё было в порядке.

Соберите набор из переписок, которые у вас уже есть. От двадцати до пятидесяти случаев: ваши частые вопросы, ваши неудобные пограничные ситуации и та горстка, на которые агент никогда не должен отвечать в одиночку. Достаточно большой, чтобы поймать настоящую регрессию, и достаточно маленький, чтобы вы правда его прогоняли.

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

Как выглядит еженедельный цикл обслуживания?

От тридцати до шестидесяти минут, каждую неделю в один и тот же слот:

Прочитайте десять реальных переписок целиком. Не сводки. Возьмите несколько помеченных и несколько случайных, потому что именно случайные показывают, как выглядит норма.
Разберите каждый дизлайк, который отметила ваша команда. Разложите их по трём корзинам: знание было неверным или его не было, инструкция была неверной, либо агент должен был передать разговор человеку.
Чините корзину, а не переписку. Разовая правка в одном чате ничему систему не учит. Обновите запись в базе знаний, инструкцию или правило передачи.
Перепрогоните регрессионный набор, если вы поменяли что-то несущее.
Запишите, что вы изменили и почему. Датированный журнал изменений это то, что позволит через шесть недель ответить на вопрос «когда это началось?».

Почему длинные задачи проваливаются, даже когда с моделью всё в порядке?

Это скорее ограничение проектирования, чем задача обслуживания, но выглядит оно как деградация.

Августовский препринт 2026 года на arXiv, How Fast Do Agents Rot?, измерил надёжность агентов на девяти моделях и 10,664 разобранных траекториях. Успех задачи подчиняется геометрическому закону, который задаётся надёжностью на каждом шаге: она растёт с масштабом модели, но выходит на плато заметно ниже 1 даже у самых сильных систем. На по-настоящему агентной задаче с использованием инструментов каждая протестированная модель, включая широко используемые проприетарные, падала с почти идеального результата до почти нулевого в пределах шестнадцати зависимых шагов. Деградация следовала за числом шагов, а не за длиной контекста.

Это препринт, и его задачи не похожи на разговоры клиентской поддержки. Практический вывод всё равно остаётся в силе: надёжность складывается вниз с каждым зависимым шагом, поэтому агент, которому поручено ответить, квалифицировать и записать, стоит на куда более твёрдой почве, чем агент, который без присмотра ведёт процесс из пятнадцати шагов. Если работа вашего агента незаметно разрослась с момента запуска, перед вами проблема границ, переодетая в проблему качества.

Кто на самом деле за это отвечает?

Обычно никто, и это главная находка в тексте Ali. Продуктовые команды выпускают, инженеры держат инфраструктуру на ходу, операционный отдел ведёт бизнес, и никто не отвечает за то, чтобы заметить, что ответы стали хуже.

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

Где здесь Entagl

Любой человек в вашей команде может пометить плохой ответ ИИ прямо из единого входящего ящика, добавив заметку о том, что было не так. Помеченные ответы попадают в очередь на разбор со статусом, поэтому у еженедельной разборки есть рабочий список вместо проверки на память. Знания живут в одном месте, поэтому исправление в FAQ, в услуге или в часах работы исправляет их сразу для WhatsApp, Instagram, Messenger, Telegram, веб-чата, почты и API. И поскольку у четырёх агентов один мозг, поправка, сделанная для чата, верна и на следующем звонке.

Две структурные вещи важнее любой отдельной функции. Маршрутизация моделей не привязана к одной лаборатории: модель за каждым этапом это настройка, а за ней можно прописать резервные модели, поэтому изменение в поведении у вендора превращается в решение о маршрутизации, а не в перестройку. И передача человеку здесь полноценный путь, а не состояние отказа, поэтому цифра, которая скажет вам о дрейфе, уже собирается сама собой.

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

Чего обслуживание не исправляет

Оно не сделает точным агента, который изначально не был как следует привязан к вашим данным. Мониторинг плохо очерченного агента даёт вам точное измерение не той вещи.

Оно не устраняет галлюцинации. Средства, которые их снижают, это отдельный набор, и он разобран в статье как не дать ИИ-агенту галлюцинировать.

И движение цифры это ещё не диагноз. Доля передач человеку может вырасти потому, что агент стал хуже, или потому, что вы запустили рекламную кампанию, которая привела вопросы другого рода. Прочитайте переписки, прежде чем что-то менять. Именно поэтому первый шаг еженедельного цикла это чтение, а не измерение.

FAQ

Как часто проверять работу ИИ-агента?

Долю передач человеку, время первого ответа и долю решённых обращений смотрите ежедневно, потому что это опережающие индикаторы сползания. Помеченные ответы и конверсию разбирайте раз в неделю. Регрессионный набор тестов прогоняйте раз в месяц и при каждой смене модели. Именно проверка только раз в неделю привела к тому, что падение на восемь пунктов в одном внедрении в финансовых услугах несколько недель оставалось незамеченным.

Может ли ИИ-агент стать хуже, если ничего не менялось?

Да, по двум разным причинам, и их стоит держать порознь. Поведенческий дрейф большинство команд упускает: размещённая у вендора модель может начать хуже отвечать на те же вопросы без единой правки в ваших промптах и настройках, и именно это Anwar Ali задокументировал в BSI Financial Services, когда доля самостоятельно закрытых обращений упала примерно на восемь пунктов. Вторая причина это старение ИИ: фиксированная модель становится менее точной просто потому, что с момента обучения прошло больше времени, и журнал Scientific Reports издательства Nature наблюдал это в 91% из 128 протестированных сочетаний модели и набора данных. Механизмы разные, симптом один. Фиксированный регрессионный набор тестов ловит оба.

Как понять, дело в модели или в базе знаний?

Прогоните свой фиксированный регрессионный набор тестов. Если случаи, которые раньше проходили, теперь падают, а лежащие под ними знания не менялись, значит, сдвинулась модель. Если агент уверенно отвечает по информации, которая просто устарела, значит, сдвинулись ваши знания. Разделяет эти два случая именно набор тестов, и поэтому он должен быть фиксированным и многоразовым, а не переписываться каждый раз.

Кто должен отвечать за обслуживание ИИ-агента в небольшом бизнесе?

Один названный по имени человек, обычно тот, кто отвечает за клиентский опыт, а не тот, кто лучше всех разбирается в технике. Работа состоит из чтения переписок, разбора помеченных ответов и обновления бизнес-знаний. Ничего из этого не требует инженеров, и всё это требует человека, у которого есть право урезать задачи агента, когда цифры об этом говорят.

Снимает ли более сильная модель необходимость в мониторинге?

Нет. Надёжность на каждом шаге растёт с масштабом модели, но не доходит до 1, поэтому длинные цепочки задач всё равно деградируют, а более сильная модель всё так же может поменять поведение у вас под ногами. Лучшие модели поднимают пол. Они не отменяют необходимость за этим полом следить.

Начните с цифры, которую вы не собираете

Вы почти наверняка где-то ещё в этом бизнесе проводите еженедельный разбор цифр, ведёте журнал изменений для какой-то другой системы и умеете выборочно проверять качество работы. Ali приходит к тому же выводу в конце своей колонки: способность обычно уже есть, и почти никто не направил её на тот ИИ, который разговаривает с его клиентами.

Выберите один опережающий индикатор, за которым вы не следите ежедневно, назначьте ему ответственного и поставьте в календарь тридцать минут на еженедельное чтение. Одного этого хватило бы, чтобы поймать описанный здесь дрейф.

Чтобы посмотреть, как очередь помеченных ответов, общие знания и управление передачей человеку работают на живом рабочем пространстве, запишитесь на 30-минутную демонстрацию, и мы прогоним через неё ваши собственные переписки.

Источники: Nature Scientific Reports, «Temporal quality degradation in AI models» (2022); HousingWire, Anwar Ali, «The silent failure mode: what happens when your AI model quietly gets worse» (сентябрь 2026); arXiv:2609.01660, «How Fast Do Agents Rot?» (август 2026); Entagl Response Velocity Study (2026). Данные проверены по состоянию на сентябрь 2026 года.