Grab против монолита: 5 агентов вместо одной модели работают медленнее, но точнее — 6 июля 2026 г. в 08:00:07.797
Grab против монолита: 5 агентов вместо одной модели работают медленнее, но точнее Команда Grab, отвечающая за аналитическое хранилище данных, при проектировании агентной системы сделала выбор против привычной логики: вместо одной мощной модели на все случаи она собрала несколько узких агентов — и сознательно приняла проигрыш по скорости. Контекст: 15 000 таблиц, 1000 пользователей, 40% времени — на рутину Хранилище обслуживает: ▪️ свыше 1000 пользователей; ▪️ более 15 000 таблиц — на них приходится около половины всех запросов в data lake; ▪️ порядка 40% инженерного времени (примерно два дня в неделю) уходило на повторяющиеся обращения: уточнение определений данных, трассировку источников, проверки качества, мелкие доработки. Проблемы у всех разные, но процесс их решения оказался одинаковым — именно он и стал кандидатом на автоматизацию. Архитектура: 5 специализированных агентов, 2 маршрута Очевидный путь — обучить единую «супер-модель» под все сценарии. Но команда пошла по другому пути: ➡ система из пяти специализированных агентов ➡ разделение на два маршрута — обработка запросов на доработку и расследование проблем с данными Как это работает: ▪ Классификатор разбирает обращение ▪ Профильные агенты (по данным, по коду, по дежурствам) собирают контекст ▪ Агент-суммаризатор сводит ответы воедино Инженерный размен: монолит vs мультиагент За этим стоит прямой инженерный размен. Монолитная модель — это один объект сопровождения и один вызов инференса. Но ее тяжело отлаживать, любое изменение задевает все сразу, а точность остается уровня генералиста. Мультиагентная схема дает сфокусированную экспертизу, модульные обновления и точность специалиста — ценой последовательного исполнения, которое добавляет задержку, и сложности координации. Ключевой принцип: разделение «мозга» и «рук» ➡ Языковая модель отвечает за рассуждение ➡ Специализированные агенты с инструментами — за действия Такая развязка делает систему одновременно дееспособной и пригодной для отладки. Переоценка приоритетов: скорость инференса — ложная метрика Здесь же лежит переоценка приоритетов, которую стоит зафиксировать отдельно. Индустрия привыкла мерить ИИ-системы секундами отклика. Но когда система заменяет не другую систему, а многочасовое ручное расследование, несколько минут на точный ответ — это не замедление, а скачок операционной пропускной способности. Скорость инференса оказалась ложной метрикой: оптимизировать имело смысл сопровождаемость и точность, а не латентность. Результат: порядок сокращения времени и эквивалент нескольких инженеров Результат подтверждает логику размена: ▪️ время разрешения типовых обращений сократилось на порядок ▪️ бэклог поддержки практически исчез ▪️ команда вернула эквивалент нескольких штатных инженеров переход от реактивной поддержки к разработке Что выносим из кейса Grab Случай Grab — напоминание, что архитектурный выбор в агентных системах определяется не тем, что технически эффектнее, а тем, какую метрику система реально должна улучшать. Иногда правильный ответ — осознанно выбрать более медленное решение. #кейс