Компания разворачивает ИИ-агента как обычную программу: покупает подписку, подключает к нужным системам, ждёт результата. А потом удивляется, почему он то зависает без объяснений, то работает нестабильно, то выдаёт результат через 40 секунд вместо привычных двух. Первая мысль — модель слабая, надо брать другую. Проблема почти никогда не в этом.
Агент — не программа с ровной нагрузкой
У MIT Technology Review — авторитетного технологического издания при Массачусетском технологическом институте — недавно вышел разбор именно этой проблемы, и логика там ровно про это: обычное корпоративное ПО работает предсказуемо, запрос — ответ, нагрузка более-менее ровная. Агент устроен иначе. Он то ждёт ответа от языковой модели, то резко бросается выполнять несколько действий подряд — сходить в базу знаний, вызвать внешний сервис, обработать результат. По-английски это называют «impulsive» нагрузкой — рывками, а не потоком. Если инфраструктура настроена как под обычную программу, эти рывки она просто не выдерживает: то простаивает, то захлёбывается.
Почему обычные метрики тут не работают
Айтишники привыкли следить за средней загрузкой процессора — она хорошо описывает ровную нагрузку. Для агента это бесполезная цифра: она усредняет паузы и рывки в одно число, которое ничего не говорит о реальной проблеме. Полезнее смотреть на задержку в худших 5% случаев, а не в среднем — condition, которую техническим языком называют P95. Разница простая: если у вас сто клиентов и у 95 из них всё быстро, а у пяти агент зависает на минуту, среднее время всё равно покажет «отлично». Клиенты из этих пяти случаев так не думают, и именно они первыми напишут в поддержку, что «ваш ИИ не работает».
Масштабировать в ширину, а не в высоту
Ещё одна вещь, которую компании делают по привычке: пытаются нарастить мощность одной системы, вместо того чтобы добавить несколько параллельных. Для агентов это ошибка — рывковая нагрузка гораздо лучше распределяется между несколькими системами поменьше, чем держится одной большой. Это ещё и дешевле, и надёжнее: если один узел падает, работу подхватывают остальные, а не встаёт всё разом.
Вот почему проекты закрывают, не разобравшись
Аналитическое агентство Gartner прогнозирует, что к 2027 году отменят 40% агентских проектов. Осторожно предположу, что немалая часть этих отмен — не про то, что модель оказалась «недостаточно умной», а про то, что никто не настроил инфраструктуру вокруг неё правильно. Компания честно попробовала, увидела нестабильность, списала это на технологию и закрыла проект — хотя чинить нужно было не модель.
У нас в AllSee эта часть работы — как раз то, чем занимается команда на этапе внедрения: не просто подключить агента к API, а настроить мониторинг, разложить нагрузку, продумать, что произойдёт, если один из узлов откажет. Это не увлекательная часть проекта — про неё не пишут в рекламных материалах моделей, — но именно она решает, доживёт ли агент до продуктивной эксплуатации.
Что в итоге
Если ваш ИИ-агент работает нестабильно, первый вопрос — не «какую модель нам взять получше», а «кто и как следит за P95-задержкой и умеет разложить нагрузку». Если на этот вопрос у подрядчика нет внятного ответа, вы, скорее всего, купили не решение, а полуфабрикат.