ИИ-агенты постепенно перестают быть экспериментом с большой языковой моделью. Чтобы такой системе доверить реальную задачу, одной сильной нейросети недостаточно: нужны отдельная инфраструктура, инструменты, система оценки качества и механизм восстановления после сбоев.
В рамках конференции Deep tech night «Компьютерра» выяснила, как «Яндекс» перестраивает ИИ-ассистента под агентскую модель и почему главным вызовом для разработчиков становится уже не сама нейросеть, а вся система вокруг нее. Подробнее — читайте в материале.
Просто хорошо отвечать недостаточно
Слово «агент» за последний год стало одним из самых популярных в ИИ-индустрии. При этом единого понимания того, что именно считать агентом, до сих пор нет. В «Яндексе» для этого используют подход компании Anthropic и разделяют агентские системы на два класса.
Первый — заранее заданные цепочки действий. Разработчик определяет последовательность шагов: вызвать модель, получить ответ, передать его следующему инструменту, классифицировать результат и так далее.
Второй — системы, в которых последовательность действий заранее неизвестна. Модель сама решает, какие инструменты использовать, в каком порядке и когда задача считается выполненной.
Именно второй вариант в команде Алисы считают полноценными агентами. Такая система может не только сформировать ответ, но и действовать во внешнем мире — например, найти нужную услугу и записать пользователя. На этом привычная архитектура сервисов начинает ломаться.
По словам Павла Капли, руководителя продуктовой разработки Алисы в «Яндексе», обычный поиск или голосовой ассистент должен ответить за доли секунды или несколько секунд. Агент может работать десятки секунд и даже несколько минут. Все это время соединение должно оставаться устойчивым, а система — сохранять промежуточное состояние.
Кроме того, агент работает с GPU, а вычисления на них стоят дорого. Если обычный запрос завершился ошибкой, его относительно просто запустить заново. В случае агента за несколько минут до сбоя уже могли быть потрачены значительные вычислительные ресурсы, а сама система могла успеть совершить действия во внешних сервисах.
Поэтому для агентских продуктов нужны другие принципы архитектуры: потоковая передача данных, устойчивость к сбоям, сохранение состояния и возможность повторно пройти уже выполненную часть сценария.
«Агенты работают долго. Если раньше нужно давать ответ за сотни миллисекунд, секунду, что-то очень быстрое, то агенты работают десятки секунд и даже минуты. Это значит, что вся система должна выдерживать такое время. Стриминг становится ключевой технологией, пронизывающей всю архитектуру».
Павел Капля, руководитель продуктовой разработки Алисы в «Яндексе»
«Рельсы» для агентов
Когда команда Алисы начала заниматься агентами, готового набора решений для массового продукта не существовало. Были отдельные протоколы и инструменты, но они не решали всех задач, а многие поддерживали только отдельные языки программирования. В «Яндексе» основные серверные команды используют Python, C++, Java и Go. Переводить всех на один язык было нерационально. В итоге создали собственную агентскую транспортную систему — AgTS. Она связывает агентов, инструменты и модели, превращая их в отдельные сервисы.
Главный принцип — компонентам больше не нужно напрямую знать, где находится другой компонент и на каком языке он написан. Агент может быть написан на одном языке, инструмент — на другом, а адаптер к модели — на третьем. Такой подход оказался важен не только для разработки, но и для отказоустойчивости. AgTS фиксирует взаимодействия между компонентами и сохраняет запросы и ответы. Если во время выполнения задачи происходит сбой, система понимает, какие действия уже были выполнены, повторно использует сохраненные результаты и продолжает работу с того места, на котором остановилась. В агентской системе ошибка не должна автоматически означать потерю нескольких минут вычислений и уже проделанной работы.
Код все же важен
Одним из первых экспериментов команды Алисы стал агент исследования. Пользователь задает вопрос, после чего система строит план, ищет информацию, использует дополнительные инструменты и формирует итоговый ответ.
На практике выяснилось, что между прототипом и массовым продуктом лежит большой слой инфраструктуры. Появились ограничители нагрузки, классификаторы запросов, блок планирования, управление контекстом, поиск и оценка его результатов, работа с файлами и интерпретатором кода.
Отдельно пришлось продумывать пользовательский интерфейс, так как агент может работать долго, поэтому человеку нужно понимать, что происходит внутри системы. При этом улучшить работу агента удалось без доработки самой модели — за счет изменений в его архитектуре и инструментах.
В одном из тестов команда обнаружила, что обработка результатов поиска до передачи их основной модели позволила увеличить качество примерно на девять процентных пунктов. Добавление работы с файлами, мультимодальности (способов обработки информации) и взаимодействия с операционной системой дало еще около 8,5 пункта на другом тесте.
Получается, что улучшение ИИ-продукта больше не сводится к выбору самой новой и мощной модели. Значительную часть результата дает то, что разработчики строят вокруг нее.
При этом новые модели способны сделать ненужными уже созданные элементы этой обвязки. Поэтому агент приходится постоянно измерять: часть компонентов добавляется, другие, наоборот, приходится удалять.
«Мы запретили себе учить модель и сказали: давайте из моделей, которые нам доступны без дообучения, попробуем собрать продукт и будем учиться растить его качество за счет обвязки. И это сработало».
Павел Капля, руководитель продуктовой разработки Алисы в «Яндексе»
Второй эксперимент — бронирование: запись в рестораны, салоны красоты. Сначала сделали мультиагентную архитектуру, но модель начала путаться между похожими сценариями. Выяснилось, что если часть задачи можно надежно решить кодом, лучше сделать это кодом. В следующей версии универсальные инструменты скрыли конкретную реализацию.
Это снизило количество решений, которые модель должна принимать самостоятельно. Особенно важно там, где ошибка приводит к реальным последствиям: если агент ошибся в тексте — результат можно переделать, но если ошибся при бронировании — действие уже совершено.
Виртуальная среда и проблема интерфейсов
Еще одна проблема появилась при обучении и проверке качества. Разработчикам недостаточно просто отправлять агенту заранее подготовленные запросы. Пользователь может отвечать по-разному, менять требования, сообщать дополнительные данные. Поэтому команда Алисы создала «железных пользователей» (Iron User) — виртуальных собеседников с собственными целями, профилями и другими параметрами. Такой пользователь может вести себя как настоящий человек и взаимодействовать с агентом в заданных рамках.
Параллельно пришлось эмулировать и внешнюю среду. Причем выяснилось, что имитации самих инструментов недостаточно. Они не воспроизводят всю бизнес-логику настоящих сервисов и реальные ошибки. Поэтому в проекте сделали единый код, который может работать как в настоящей системе, так и в эмуляции. Это позволяет использовать одну и ту же логику для разработки, обучения и проверки качества.
Так постепенно вокруг агента появляется целая система тестирования. Саму модель в ней уже нельзя рассматривать отдельно от инструментов, среды, пользователя и конечного результата.
Еще одна проблема проявилась на уровне интерфейса. Большинство современных агентских систем по-прежнему общаются с человеком преимущественно текстом. Но если агент ищет ресторан, строит маршрут или подбирает товар, пользователю удобнее увидеть карточку, изображение или другой элемент интерфейса.
В «Яндексе» решили, что интерфейс становится частью ответа модели: она фактически определяет, где должна появиться карточка ресторана, изображение или другой элемент, а система уже преобразует это описание в настоящий интерфейс.
Такой подход сложнее и оставляет модели больше свободы, зато она понимает, какой визуальный контекст получает пользователь. Это особенно важно для агентских продуктов. Если раньше интерфейс можно было жестко запрограммировать под заранее известный сценарий, то теперь сам сценарий определяется в процессе работы модели.
Другие вызовы для агентов
Отдельного внимания заслуживает вопрос переноса агентской логики на устройства без экрана — колонки и наушники, где взаимодействие происходит исключительно через голос, а требования к скорости реакции значительно выше.
Как пояснил «Компьютерре» Павел Капля, классические сценарии Алисы на этих устройствах рассчитаны на ответ в доли секунды. Агент же может работать десятки секунд и даже минуты, что делает его использование в чисто голосовом формате непростой задачей. Пользователь не видит, что происходит внутри системы, не может отследить прогресс — а это критически важно для долгих операций.
Тем не менее в «Яндексе» смотрят в эту сторону. Унификация архитектуры ассистента — один из ключевых треков развития. Однако на данный момент полноценный перенос агентов на голосовые устройства остается скорее стратегической целью, чем ближайшим релизом.
«В ближайшее время это не будет реализовано — пока что это скорее план, чем готовое решение».
Павел Капля, руководитель продуктовой разработки Алисы в «Яндексе»
Пока что агенты остаются преимущественно сценарием для устройств с экраном и визуальной обратной связью. Но тенденция очевидна: с развитием самих моделей и оптимизацией времени ответа голосовые интерфейсы неизбежно станут следующей целью для агентских систем.
«Сегодня я многое понял»
За год работы с агентами команда Алисы сформулировала несколько выводов. Первый и главный — качество необходимо постоянно измерять.
Новая модель, новый инструмент или изменение архитектуры могут улучшить один сценарий и ухудшить другой. Поэтому недостаточно один раз провести бенчмарк и решить, что система стала лучше.
Нужны постоянные проверки в продакшене и офлайн-тестах, а наборы данных должны оставаться репрезентативными. Если меняется поведение реального сервиса, эмулятор тоже необходимо обновлять.
Отдельного внимания требуют сами системы оценки — так называемые джаджи. По словам Капли, они должны фактически существовать как отдельный продукт: команда должна следить за их качеством и регулярно проверять их на разных моделях и версиях системы.
Иначе есть риск начать оптимизировать не то, что действительно важно пользователю, а то, что лучше всего измеряется выбранной метрикой.
Выводы
Опыт «Яндекса» показывает, что главный барьер на пути агентских систем сейчас находится уже не столько внутри языковых моделей, сколько вокруг них. Чтобы агент стал массовым продуктом, нужны вычислительная инфраструктура, инструменты интеграции, отказоустойчивость, эмуляция, система оценки качества и интерфейс. Причем все эти компоненты должны работать вместе в условиях, когда поведение системы заранее полностью не известно. При этом сама модель остается лишь одним из элементов конструкции.
«Человечество научилось сейчас делать во фронтовых лабораториях сильные модели. Продукты делать пока не научилось».
Павел Капля, руководитель продуктовой разработки Алисы в «Яндексе»
Похоже, именно это и становится следующим этапом развития ИИ. Гонка постепенно смещается от вопроса «Какая модель умнее?» к гораздо более практичному «Как превратить ее возможности в надежный продукт, который можно запускать для миллионов пользователей?».
И здесь преимущество может оказаться не у того, кто первым получит самую мощную модель, а у того, кто быстрее построит вокруг нее работающую инженерную систему.