52-минутное выступление Аарона Эриксона, основателя Applied AI Lab for DGX Cloud в NVIDIA, свелось к неприятной, но полезной мысли: надежные AI-платформы не получаются из одного большого LLM и хороших намерений. Для русскоязычных команд, которые уже тащат в прод ассистентов, copilot-фичи и агентные сценарии, вывод простой: если не встроить в систему детерминированные правила, тесты и узкую специализацию, агент быстро превращается в дорогой генератор «ну вроде похоже».
Эриксон, сообщает InfoQ, разбирал это не в жанре футуристического стендапа, хотя иронии в докладе хватало. В качестве антипримера он вспомнил свой стартап Orgspace, где в 2023 году команда пыталась прикрутить ChatGPT к болезненной корпоративной теме реорганизаций. Идея выглядела как типичный продуктовый соблазн той эпохи: пользователь описывает, как хочет «уплощить» структуру, модель подтягивает данные из системы, предлагает план и даже пишет письмо сотрудникам о реорганизации хоть в виде хайку, хоть в духе гомеровского эпоса. Демка звучит эффектно, но именно на таких историях хорошо видно, где заканчивается вау-эффект и начинается инженерия. По словам Эриксона, из этого не выросло «будущее HR», а сам проект стал хорошим уроком о том, что автоматизация решений с размытыми последствиями без надежной архитектуры быстро упирается в потолок.
Следующий кейс уже из NVIDIA и куда ближе к реальной эксплуатации. Его команда строила систему управления GPU-ресурсами для внутренних исследовательских инициатив. Там запрос на 1000 ускорителей H100 он оценил в диапазоне от 20 до 40 миллионов долларов в месяц, так что ошибка оркестрации стоит заметно дороже, чем неудачный чат-бот в саппорте. Для этой среды команда собрала систему Llo11yPop: retrieval agents переводили вопросы в API-запросы, analyst agents понимали, какие данные нужны для проверки гипотезы, а task agents поднимали Jira-тикеты, Slack-алерты и в перспективе должны были запускать автоматическое remediation. По сути, это ранний вариант того, что сейчас принято называть multi-agent или deep-agent framework, только без красивого маркетингового лака.
Самое интересное началось в разделе про то, что в таких системах ломается первым. Один из примеров Эриксона — редкий контекст вроде «zombie nodes» в GPU-кластерах, когда группа из восьми GPU теряет нормальную сетевую связность. Без примеров, RAG, дополнительного обучения или хотя бы внятного семантического слоя модель такие термины понимает плохо. Второй урок еще приземленнее: text-to-SQL красиво выглядит на слайде, но плохо переносит сложные join’ы. Команда заметила, что если упростить схему, свести генерацию к простым select, where, group by и шаблонам, точность может вырасти примерно с 70% до верхних 90%. Это неприятная новость для любителей универсальных агентов, зато хорошая для тех, кто отвечает за SLA: чем уже задача, тем меньше галлюцинаций и выше воспроизводимость.
Отсюда и главный тезис доклада: у агента должны быть off-ramps to determinism, то есть заранее подготовленные выходы из «стохастического режима» в обычное программное обеспечение. Если запрос совпадает с известным паттерном, не надо каждый раз заставлять LLM изобретать SQL или бизнес-логику заново. Надо дернуть проверенный шаблон, ограничить бюджет действий, встроить жесткие guardrails и дать агенту только тот уровень свободы, где она действительно полезна. Эриксон сравнил это с обычной эксплуатацией инфраструктуры: никто не чинит DNS каждый раз как философскую задачу, для этого существуют runbook’и. Та же логика работает и в AI-системах. Модель хороша там, где нужно разобрать нечеткий ввод, классифицировать, найти подозрительный паттерн или предложить гипотезу. Все, что связано с транзакциями, лимитами, правилами компенсаций, вызовами критичных API и повторяемыми операциями, лучше оставлять детерминированным инструментам.
Отдельно Эриксон прошелся по модной идее «чем больше агентов, тем умнее система». По его наблюдению, это не так. Если дать модели слишком много похожих инструментов или десятки агентов с пересекающимися ролями, качество выбора заметно падает. В докладе он упомянул, что при 50 агентах с похожим назначением частота ошибок росла, потому что система начинала путаться в меню возможностей не хуже человека, впервые открывшего меню Cheesecake Factory. Решение — не раздувать каталог способностей, а строить внятные иерархии: условный VP-agent держит широкий контекст, manager-agent умеет декомпозировать задачу и распределять ее дальше, а настоящую работу делают узкоспециализированные исполнители. Если убрать корпоративную метафорику, мысль полезная: для production-агентов важнее не масштаб амбиций, а понятная топология ответственности.
Вторая важная часть — проверка качества. Эриксон довольно жестко сформулировал мысль, которая многим командам еще испортит квартальные планы: «на вайбе» такие системы не тестируются. Для multi-agent-архитектур нужна пирамида evals по аналогии с классической test pyramid. Наверху — редкие и дорогие end-to-end проверки, где участвует вся цепочка LLM-компонентов. Ниже — более частые тесты отдельных агентов, еще ниже — проверки инструментов, шаблонов и маршрутизации. Если этого нет, любая демонстрация работает ровно до первого сложного кейса из реальной эксплуатации. Для разработчиков это означает возвращение к почти забытой дисциплине: меньше восторга по поводу «само получилось», больше метрик ошибок, регрессий и наблюдаемости по каждому слою.
Наконец, Эриксон напомнил, что AI в платформе — это не только LLM. Его команда в NVIDIA занимается time-series foundation models, в том числе моделью Tesseract, которая учится на временных рядах и используется для anomaly detection и forecasting. Здесь логика та же: если задача экономически ценная и повторяется в большом масштабе, не обязательно решать ее текстовым агентом. Иногда правильнее взять специализированную модель для временных рядов и уже поверх нее строить агентный слой, который будет интерпретировать сигналы, поднимать расследование или запускать нужный runbook. Для бизнеса это, пожалуй, самый трезвый вывод из всего выступления: надежные AI-платформы собираются не вокруг одного «универсального мозга», а вокруг набора моделей и инструментов, каждый из которых делает свою работу.
Открытый вопрос здесь не в том, заменят ли агенты привычное ПО, а в том, сколько свободы компании вообще готовы им дать. Пока что лучший ответ Эриксона звучит почти старомодно: чем дороже ошибка, тем ближе архитектура должна быть не к магии, а к хорошей старой инженерной дисциплине. И похоже, именно по этой линии в ближайшие годы будут отделяться игрушечные агентные демо от систем, которые реально переживают прод.