Как «уволить» устаревшего ИИ-агента и передать его задачи

Компании, которые запустили ИИ-агентов в 2023 году, сейчас массово столкнулись с одинаковой задачей: агент на старой модели работает хуже, чем свежая версия того же вендора, а иногда и дешевле обходится замена, чем поддержка. OpenAI в течение 2024 года переводила пользователей API с gpt-3.5-turbo на gpt-4o-mini, Anthropic выпустила семейство Claude 3.5, и разрыв в качестве между поколениями стал заметен даже на простых сценариях поддержки. «Уволить» агента — это не нажать одну кнопку. Это миграция: перенос промптов, инструментов, памяти и логов на новую основу так, чтобы клиент не заметил разницы, а команда не потеряла историю.

Что значит «уволить» агента

ИИ-агент^* — это не просто модель, а связка: базовая LLM, системный промпт, набор инструментов (доступ к базе, API, поиску), память диалогов и логика оркестрации. Когда говорят «агент устарел», обычно имеют в виду одно из трёх:

• Устарела модель — вендор выпустил новое поколение, а старое переводит в статус deprecated или поднимает на него цену.
• Устарел стек — фреймворк оркестрации (ранние версии LangChain, самописные цепочки) стало тяжело поддерживать.
• Изменились задачи — агент делал одно, а бизнесу нужно другое, и проще собрать заново, чем переучивать.

В первом случае миграция почти механическая. В третьем — это фактически новый проект, и «увольнение» старого агента сводится к аккуратному выводу из эксплуатации.

^* Агент — программа поверх языковой модели, которая не только отвечает текстом, но и вызывает внешние инструменты (поиск, базы, API) и выполняет многошаговые задачи по заданной цели.

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

Соблазн понятен: поменять строку model: "gpt-3.5-turbo" на model: "gpt-4o" и закрыть тикет. На практике так почти не работает по нескольким причинам.

Новые модели иначе реагируют на старые промпты. Промпт, который годами держал агента в узде на GPT-3.5, на более способной модели может давать многословные ответы или, наоборот, слишком буквально следовать инструкции, написанной под слабую модель. Инструменты вызываются по другой схеме: формат function calling у OpenAI менялся, а между вендорами он вообще разный. Контекстное окно^** у новой модели больше, и та логика, что резала историю диалога под 4k токенов, теперь работает вслепую и теряет данные там, где могла бы их сохранить.

^** Контекстное окно — максимальный объём текста (в токенах), который модель удерживает за один запрос: и ваш промпт, и история диалога, и ответ.

Что переносить, а что переписывать

Разделите активы агента на три группы. Данные (логи, база знаний, история обращений) переносятся как есть. Промпты и инструкции переписываются под новую модель. Логика оркестрации проверяется заново, потому что новые модели часто позволяют упростить то, что раньше собирали костылями.

Пошаговый вывод из эксплуатации

1. Зафиксируйте поведение старого агента. Соберите набор из 30–100 реальных диалогов с разными типами запросов. Это ваш эталон — на нём вы будете сверять нового агента.
2. Соберите нового агента параллельно. Не трогая продакшн, разверните версию на новой модели с переписанными промптами.
3. Прогоните эталонные диалоги через обоих. Сравните ответы вручную или через LLM-судью. Ищите регрессии: где новый агент стал хуже, а не только где лучше.
4. Запустите теневой режим. Новый агент получает те же запросы, что и старый, но его ответы не показывают клиенту — только логируют для сравнения.
5. Переведите часть трафика (canary). Например, 10% диалогов на нового агента, с быстрым откатом при росте жалоб или ошибок.
6. Полностью переключитесь и заморозьте старого. Не удаляйте сразу: держите старую конфигурацию и логи хотя бы несколько недель на случай отката.

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

Куда мигрировать: сравнение вариантов

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

Кому это пригодится, а кому нет

Стоит мигрировать сейчас, если:

• Ваш агент работает на модели, которую вендор пометил как deprecated с конкретной датой отключения — тут выбора нет, отложите и рискуете обвалом сервиса.
• Жалобы на качество ответов растут, а новое поколение модели решает те же задачи заметно точнее на ваших эталонных диалогах.
• Вы упираетесь в короткое контекстное окно и режете важную историю диалога.

Можно повременить, если:

• Старая модель ещё поддерживается, а агент решает узкую предсказуемую задачу (классификация, шаблонные ответы), где разница поколений почти не видна.
• У вас нет набора эталонных диалогов и метрик — тогда сначала соберите их, иначе вы не поймёте, стало ли лучше.
• Миграция затронет интеграции, на переделку которых нет ресурса в ближайший квартал, а риска отключения нет.

Что не потерять при «увольнении»

Логи старого агента — это не мусор, а размеченный на реальных клиентах датасет. По ним видно, где агент ошибался, какие запросы приходили чаще, где клиенты переспрашивали. Эти данные пригодятся, чтобы настроить нового агента и, при необходимости, собрать базу для RAG^*** вместо дообучения.

^*** RAG (retrieval-augmented generation) — подход, когда модель перед ответом подтягивает релевантные документы из вашей базы, а не полагается только на то, что «помнит». Часто дешевле и гибче, чем дообучение модели.

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