Приложениям искусственного интеллекта, основанным на агентах, требуется иной дизайн, чем традиционным веб-интерфейсам, и не обязательно из-за нового протокола, а потому, что сам характер трафика отличается. Один разговор может растянуться на десятки независимых запросов, тогда как агент продолжает работать с машинной скоростью, без пауз на размышления пользователя, которые могли бы снизить нагрузку на инфраструктуру.
В материале, опубликованном в The New Stack в рамках спонсируемого Oracle материала, предлагается повторно использовать устоявшиеся принципы микросервисов для создания совместимых с OpenAI и масштабируемых интерфейсов, опираясь в модели проверки концепции на Oracle AI Database Free.
Почему трафик агентов отличается от веб-приложений?
Браузер может сохранять сеанс на одном сервере благодаря закреплению маршрутизации и паузам на размышления пользователя. Агент же может выполнить 40 последовательных циклов, причём каждый цикл поступает как отдельный HTTP-запрос, и протокол не гарантирует его маршрутизацию на тот же сервер. Если история разговора хранится в локальной памяти процесса, следующий запрос может потерять контекст сразу после его перенаправления на другой экземпляр службы.
Кроме того, вызовы инструментов могут неожиданно разветвляться: один запрос может не привести ни к одному дополнительному вызову службы или вызвать несколько таких вызовов, включая векторный поиск, который может занимать 400 миллисекунд. Агенты усиливают нагрузку собственными политиками повторных попыток, тогда как трафик поступает непрерывными пакетами, параметры которых в большей степени определяются ограничениями параллелизма и оборудованием, чем поведением пользователя.
Скрытая проблема первоначального дизайна
Автор представляет прототип, который хранит историю разговора в словаре внутри процесса, использует один набор для управления параллелизмом и выполняет вызовы инструментов в рамках самого пути обработки запроса. Такая конструкция работает в тестах, но на практике зависит от того, что все роли разговора будут обращаться к одному и тому же устройству.
При распределении 200 разговоров, в каждом из которых по четыре роли, по очереди между несколькими экземплярами серверы могут продолжать возвращать коды HTTP 200, тогда как модель отвечает без правильной истории разговора. Поэтому сбой не обязательно проявляется как очевидная техническая неисправность: с точки зрения пользователя он выглядит как некорректное поведение.
Три принципа устранения проблемы
- Вынос состояния за пределы процесса: состояние разговора и журнал вызовов инструментов хранятся в общем хранилище, чтобы любой экземпляр мог обслуживать любую роль разговора.
- Изоляция или защитные барьеры: различным путям и зависимостям, например завершению разговора и выполнению инструментов, назначаются независимые ограничения параллелизма и тайм-ауты, чтобы отказ одного компонента не истощал всю систему.
- Интеллектуальные конечные точки и простые конвейеры: протокол OpenAI-compatible остаётся стабильным транспортным уровнем, тогда как логика маршрутизации, управления бюджетом и памятью, а также политики вызова инструментов размещаются поверх него.
Что меняется на практике?
Модель проверки концепции разделяет систему на шлюз, взаимодействующий по протоколу OpenAI и не хранящий состояние, службу памяти, владеющую журналом разговоров и аудитом, независимую службу инструментов с собственными ограничениями параллелизма и тайм-аутами, а также Oracle AI Database Free в качестве общего хранилища. В конструкции используются независимые сигналы управления, например 24 слота для параллелизма разговоров и 8 — для вызовов инструментов.
Такое разделение позволяет выполнять горизонтальное масштабирование без зависимости от локальной файловой системы или закрепления маршрутизации запросов. Официальный клиент OpenAI также может использовать интерфейс без изменения SDK, пока протокол остаётся совместимым.
Редакционный вывод заключается в том, что масштабируемость ИИ-агентов не обеспечивается одним лишь увеличением числа экземпляров. Настоящая проверка — это сохранение состояния, контроль медленных зависимостей и предотвращение превращения повторных попыток или вызовов инструментов в каскадный отказ из-за пакетов агентов. При этом материал, поскольку является спонсируемым контентом Oracle, представляет архитектурный подход и модель проверки концепции, а не независимое сравнение баз данных и не гарантию определённой производительности в любой среде.