Клинические исследования редко заканчиваются вопросами, определенными в протоколе испытания. Медицинские эксперты также изучают данные с новых точек зрения: проверяют гипотезу, сравнивают популяции пациентов, визуализируют тренды или определяют перспективные направления для дальнейших исследований.
В рамках проекта по внедрению инженерных решений совместная команда разработчиков из Microsoft и Novo Nordisk создала агента, который помогает медицинским экспертам выполнять такой вторичный анализ данных клинических испытаний. Мы описали оригинальный проект в истории клиента Microsoft. Совсем недавно мы пересоздали это решение в виде размещенного агента в Microsoft Foundry.
Этот шаг дал нам более простую модель работы, более надежную изоляцию сеансов и прямой путь к возможностям трассировки, оценки, экспериментирования, оптимизации и управления в Foundry. Он также преподал нам практические уроки относительно планирования инфраструктуры, наблюдаемости и сохранения цикла обучения, который уже со временем улучшал работу агента.
Вот что изменилось, что мы измерили и что мы порекомендуем командам, планирующим аналогичный переход.
Агент для задач без фиксированного рабочего процесса
Вторичный анализ клинических данных — отличная задача для агента, поскольку путь выполнения сильно зависит от самого вопроса. Агент интерпретирует запрос, изучает доступные данные, пишет и выполняет код анализа, проверяет результат и часто пересматривает свой подход перед возвратом сводки и визуализации.
«Реархитектура решения помогла нам сосредоточиться на главном: предоставлении медицинским экспертам возможности исследовать клинические данные и получать аналитические выводы, поддерживающие разработку фармацевтических препаратов. Благодаря управляемому масштабированию и изолированным сеансам анализа мы смогли быстрее предоставить надежный и безопасный агентский опыт тысячам исследователей без необходимости самостоятельно создавать и эксплуатировать всю инфраструктуру».
Это не просто привязка интерфейса чата к одному API. Агенту необходим цикл логического вывода, доступ к доменным навыкам и инструменты для работы с данными. В нашей реализации центральным инструментом является выполнение кода. Агент может генерировать код анализа и визуализации в контролируемой среде, в то время как окружающее приложение управляет беседой и представляет результат пользователю.
Наша первая производственная архитектура запускала агента в Azure Container Apps. Мы использовали PostgreSQL для хранения бесед и динамические сеансы Azure Container Apps для выполнения кода в изолированной среде. Такая архитектура дала нам прямой контроль над каждым компонентом и доказала ценность этого сценария использования.
Это также означало, что наша команда управляла большей частью платформы вокруг агента: масштабированием контейнеров, жизненным циклом сеансов, сохранением бесед, изоляцией выполнения, сетевыми подключениями, телеметрией и интеграцией между ними. Размещенные агенты в Foundry предложили более простое разделение ответственности.
Перенос границы среды выполнения в Foundry
Размещенный агент — это наш код, упакованный в виде контейнера и работающий на инфраструктуре, управляемой Foundry Agent Service. Мы сохраняем контроль над логикой оркестрации, моделями, инструментами и поведением среды выполнения. Foundry управляет конечной точкой, идентификатором агента, вычислительными ресурсами сеанса, персистентностью состояний, масштабированием и жизненным циклом.
Во время выполнения каждый сеанс получает собственную изолированную на уровне виртуальной машины песочницу. Foundry подготавливает вычислительные ресурсы по запросу, поддерживает их в активном состоянии во время использования сеанса и удаляет после настроенного периода бездействия. Файлы сеанса могут сохраняться и восстанавливаться при возобновлении работы. Масштабирование зависит от активных сеансов, а не от количества реплик, которое нам приходится прогнозировать и настраивать.
Для рабочей нагрузки Novo эта модель хорошо совпала с единицей работы, под которую мы все создавали: один эксперт, проводящий один сеанс анализа. Она также изменила архитектуру четырьмя важными способами:
- Масштабирование стало привязанным к сеансам. Нам больше не нужно было подключать создание сеансов на уровне приложения к отдельно масштабируемому пулу сред выполнения. Платформа сама управляет этим жизненным циклом.
- Изоляция стала стандартной единицей выполнения. Каждый сеанс запускается в изолированной на уровне виртуальной машины песочнице, а не делит процесс или универсальный контейнер приложения с другими сеансами. Это важно, когда рабочая нагрузка включает в себя код, сгенерированный моделью и работающий с конфиденциальными клиническими данными.
- Сетевая изоляция стала частью архитектуры сервиса. Foundry Agent Service поддерживает частные сети, включая интеграцию с виртуальной сетью и частный доступ к зависимым ресурсам Azure. Это позволяет нам проектировать элементы управления как для входящего, так и для исходящего трафика вокруг среды агента. Эти средства контроля особенно важны для данных, которые должны оставаться внутри утвержденной сетевой границы.
- Агент присоединился к более широкому жизненному циклу разработки. Трассировки, оценки, эксперименты, мониторинг и оптимизация теперь могут быть связаны через одну и ту же платформу. Microsoft Agent 365 integration также предоставляет путь к корпоративной инвентаризации, управлению идентификацией, доступом и жизненным циклом.
Использование размещенных агентов Foundry не снимает с нас ответственность за безопасность или качество. Нам по-прежнему нужно было определять элементы управления доступом, минимизировать и защищать телеметрию, тестировать агента для нашего сценария использования и проверять каждую систему, которую он может вызывать. Изменилось то, что несколько элементов контроля, которые мы раньше собирали самостоятельно, теперь являются возможностями платформы, которые мы можем настраивать и эксплуатировать единообразно.
«Для нас качество агента имеет первостепенное значение и должно поддаваться измерению. Теперь мы можем объединить трассировку и оценку, чтобы диагностировать сбои, измерять качество по сравнению с ответами, проверенными экспертами, и постоянно совершенствовать агента. Защита данных имеет не менее фундаментальное значение: изоляция сеансов и частные сети обеспечивают ключевые элементы контроля. Вместе эти возможности дают нам более систематический способ продолжать улучшение агента на основе наших внутренних знаний при одновременном использовании наших существующих надежных средств контроля данных».
Извлеченные уроки
Вот главные уроки, которые мы извлекли в ходе этого проекта, а также несколько практических советов для ваших собственных проектов размещенных агентов в Foundry:
Урок 1: Относитесь к выбору инфраструктуры как к продуктовым решениям
Частная сеть должна быть решением на ранней стадии проектирования, а не задачей по обеспечению безопасности в рабочей среде, отложенной на самый конец.
Размещенные агенты потребляют сетевую емкость в соответствии с сеансами. Учетная запись Foundry, ее проекты, размещенные агенты, одновременные сеансы и версии агентов — все это влияет на использование IP-адресов. Поскольку назначенная подсеть является неизменяемой ссылкой на уровне учетной записи, неподходящий диапазон может превратить корректировку емкости в более масштабную миграцию инфраструктуры.
Мы советуем оценить пиковое количество одновременных сеансов в учетной записи, заложить запас на развертывание и рост, а также привлечь сетевую команду до создания ресурса Foundry. Текущие рекомендации по работе с сетями рекомендуют подсеть /24 для развертывания размещенных агентов в рабочей среде и указывают /27 в качестве поддерживаемого минимума для небольших развертываний.
Мы использовали модули Azure Verified Modules в качестве основы для создания воспроизводимых сред. Это дало нам отличную отправную точку, однако инфраструктура как код не отменяет необходимость проверки создаваемых зависимостей. Пропускная способность для таких ресурсов, как Azure Cosmos DB, должна отражать ожидаемый уровень параллелизма и шаблоны доступа к данным. Если какой-то параметр требует изменения в процессе работы, зафиксируйте это в процессе развертывания или руководстве оператора, вместо того чтобы оставлять это в виде недокументированных знаний о рабочей среде.
Размер подсетей, пропускная способность баз данных, частные конечные точки, DNS и параллелизм не являются изолированными деталями инфраструктуры. В совокупности они определяют предел масштабирования и надежность продукта.
Урок 2: Упростите навигацию по трассировкам
Трассировка в Foundry использует OpenTelemetry и сохраняет телеметрию в Azure Monitor Application Insights. Она позволяет фиксировать пользовательский ввод, вывод агентов, вызовы моделей, активность инструментов, использование токенов и задержку. Это дает нам исходный материал для понимания как надежности, так и поведения агента.
Во время миграции мы отправляли трассировки агентов как в Application Insights, так и в Langfuse. Сохранение доступности существующего пути телеметрии обеспечило команде непрерывность работы, пока мы подключали агента к возможностям наблюдаемости Foundry.
Инженеру необходимо иметь возможность быстро переходить от зарегистрированной проблемы к соответствующему взаимодействию: что запросил пользователь, что вернул агент, сколько операций было выполнено за один запуск, сколько времени это заняло и сколько токенов было потрачено. Стабильные идентификаторы пользователей, сеансов, бесед, версий агентов и трассировок делают такие представления доступными для поиска и связывают активность между фронтендом, бэкендом, агентом и инструментами.
Подойдите с такой же тщательностью к тому, что записывать не следует. Руководство по трассировке Foundry отмечает, что трассировки могут содержать промпты, выходные данные, аргументы и результаты работы инструментов. Для клинических рабочих нагрузок телеметрия требует такого же контроля доступа, минимизации, маскирования и соблюдения сроков хранения, как и любые другие конфиденциальные производственные данные.
Урок 3: Сохраняйте цикл обучения во время миграции
Мы сохранили контракты бэкенда стабильными, что значительно упростило миграцию. Наша система оценки могла вызывать развернутую в Foundry реализацию через тот же интерфейс, который использовался ранее, поэтому перенос среды выполнения не потребовал перестройки системы контроля качества вокруг нее.
Мы могли продолжать запускать тот же набор тестов для агента и применять те же оценщики к его результатам. Эти оценщики включали сравнение с эталонными ответами, предоставленными профильными экспертами. Полученные баллы обеспечили нам базовый уровень для миграции, защитили от регрессий и указали на области, где изменения в инструкциях, инструментах или оркестрации улучшили систему.
Именно здесь более широкий жизненный цикл Foundry становится особенно полезным. Трассировки объясняют, что произошло во время запуска. Оценки измеряют результат. Эксперименты сравнивают альтернативные варианты. Оптимизация превращает эти данные в потенциальные улучшения. Сближение этих возможностей создает более короткий путь от наблюдения в рабочей среде до протестированного изменения.
НЕПРЕРЫВНЫЙ ЦИКЛ ОБУЧЕНИЯ
Выводы
Наша исходная архитектура предоставила Novo работающего агента для ценного и сложного исследовательского сценария. Перенос его на управляемые агенты позволил нам сохранить контроль над логикой агента, переложив при этом большую часть стандартной работы среды выполнения на Foundry. Результатом стало не просто новое место для запуска контейнера. Это более четкая граница платформы: изолированные вычисления для каждого сеанса, управляемое масштабирование и идентификация, частная сеть, постоянное состояние и интегрированный путь от трассировки к оценке и оптимизации.
Командам, которые решают, как перевести агента из прототипа в продакшн, стоит оценить эту границу на раннем этапе. Создавайте ту часть, которая делает вашего агента уникальным. Позвольте платформе взять на себя больше того, что необходимо любому агенту в продакшене.
