Базовая эталонная архитектура чата Azure AI Foundry

Служба Azure OpenAI

Службы ИИ Azure

Служба приложений Azure

Azure Monitor

Корпоративные приложения чата могут предоставлять сотрудникам возможность взаимодействия с агентами искусственного интеллекта. Эта возможность становится все более мощной благодаря текущим улучшениям языковых моделей, таких как модели GPT OpenAI и пакеты SDK оркестрации, такие как семантический ядро. Эти приложения чата обычно состоят из следующих компонентов:

• Пользовательский интерфейс чата, интегрированный в более крупное корпоративное приложение. Он предоставляет пользователям возможность общения вместе с другими бизнес-функциями.

• Репозитории данных, содержащие сведения о домене, относящиеся к запросам пользователей.

• Языковые модели, которые причиняют данные, относящиеся к домену, для получения соответствующих ответов.

• Оркестратор или агент, который контролирует взаимодействие между источниками данных, языковыми моделями и конечным пользователем.

В этой статье представлена базовая архитектура, помогающая создавать и развертывать корпоративные приложения чата с помощью Azure AI Foundry и Azure OpenAI в модели Foundry. В этой архитектуре используется один агент, размещенный в службе агента Azure AI Foundry. Агент получает сообщения пользователей, а затем запрашивает хранилища данных для получения сведений об основе для языковой модели.

Пользовательский интерфейс чата следует базовому руководству веб-приложения службы приложений Azure по развертыванию безопасного, избыточного между зонами и высокодоступного веб-приложения в службе приложений. В этой архитектуре служба приложений взаимодействует с решением Платформы Azure как услуга (PaaS) через интеграцию виртуальной сети с частными конечными точками. В архитектуре пользовательского интерфейса чата служба приложений взаимодействует с агентом через частную конечную точку. Общедоступный доступ к порталу Azure AI Foundry и агентам отключен.

Это важно

В этой статье не описываются компоненты или решения архитектуры из базовой архитектуры веб-приложения службы приложений. Ознакомьтесь с этой статьей по архитектуре по размещению веб-приложения, содержащего пользовательский интерфейс чата.

Эта архитектура использует стандартную настройку агента Foundry Agent Service для обеспечения безопасности, соответствия требованиям и контроля корпоративного уровня. В этой конфигурации вы используете собственную сеть для сетевой изоляции и собственных ресурсов Azure для хранения состояния чата и агента. Все взаимодействие между компонентами приложений и службами Azure происходит через частные конечные точки, что гарантирует, что трафик данных остается в виртуальной сети рабочей нагрузки. Исходящий трафик от агентов строго направляется через брандмауэр Azure, который применяет правила исходящего трафика.

Подсказка

Эталонная реализация службы агента Foundry демонстрирует базовую сквозную реализацию чата в Azure. Он служит основой для разработки пользовательских решений при переходе к рабочей среде.

Архитектура

В правом углу отдельный прямоугольник представляет Azure AI Foundry, который включает учетную запись и проект. Управляемые удостоверения используются для подключения службы агента Foundry к проекту Azure AI Foundry, который, в свою очередь, обращается к модели Azure OpenAI. На схеме используются нумерованные зеленые круги для указания логического потока, показывающее, как запросы пользователей проходят по сети, взаимодействуют с различными конечными точками и в конечном итоге подключаются к службам ИИ Azure и хранилищу с четко сгруппированы и помечены зависимостями.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

1. Пользователь приложения взаимодействует с пользовательским интерфейсом чата. Запросы направляются через шлюз приложений Azure. Брандмауэр веб-приложений Azure проверяет эти запросы, прежде чем пересылать их в серверную службу приложений.

2. Когда веб-приложение получает запрос пользователя или инструкцию, он вызывает созданный с целью агент. Веб-приложение взаимодействует с агентом с помощью пакета SDK агента ИИ Azure. Веб-приложение вызывает агент через частную конечную точку и проходит проверку подлинности в Azure AI Foundry с помощью управляемого удостоверения.

3. Агент обрабатывает запрос пользователя на основе инструкций в системном запросе. Для выполнения намерения пользователя агент использует настроенную языковую модель и подключенные средства и хранилища знаний.

4. Агент подключается к хранилищу знаний (Поиск ИИ Azure) в частной сети через частную конечную точку.

5. Запросы к внешним хранилищам знаний или средствам, таким как Википедия или Bing, проходят через Брандмауэр Azure для проверки и принудительного применения политики исходящего трафика.

6. Агент подключается к настроенной языковой модели и передает соответствующий контекст.

7. Прежде чем агент возвращает ответ на пользовательский интерфейс, он сохраняет запрос, созданный ответ и список хранилищ знаний, которые содержатся в выделенной базе данных памяти . Эта база данных поддерживает полный журнал бесед, который позволяет взаимодействовать с контекстом и позволяет пользователям возобновлять беседы с агентом без потери предыдущего контекста.

   API-интерфейсы Azure AI Foundry поддерживают разработку пользовательских интерфейсов, которые управляют несколькими параллельными, изолированными от контекста беседами.

Компоненты

Эта архитектура основана на базовой эталонной архитектуре чата Azure AI Foundry. Эта архитектура представляет больше служб Azure для решения корпоративных требований к надежности, безопасности и операционному управлению. Каждый из следующих компонентов играет определенную роль в рабочем решении корпоративного чата:

• Служба агента Foundry предоставляет уровень оркестрации для взаимодействия чата. Он размещает агенты и управляет ими, выполняющими следующие задачи:

  • Обработка запросов пользователей
  • Координация вызовов средств и других агентов
  • Принудительное обеспечение безопасности содержимого
  • Интеграция с корпоративным удостоверением, сетью и наблюдаемостью

  Стандартная настройка агента обеспечивает сетевую изоляцию и обеспечивает контроль над хранилищем данных. Вы предоставляете выделенные ресурсы Azure для состояния агента, журнала чата и хранилища файлов, которым служба агента Foundry управляет исключительно. Другие компоненты приложения в рабочей нагрузке не должны использовать эти необходимые ресурсы.

  • Azure Cosmos DB для NoSQL размещает базу данных памяти этой рабочей нагрузки, вызываемую enterprise_memoryв подписке. Эта база данных хранит рабочее состояние агента, включая потоки чата и определения агента. Эта конструкция гарантирует, что журнал чата и конфигурация агента изолированы, аудит и управление ими в соответствии с требованиями к управлению данными. Служба агента Foundry управляет базой данных, ее коллекциями и данными.

  • Выделенная учетная запись хранения Azure хранит файлы, отправленные во время сеансов чата. Размещение этой учетной записи в подписке обеспечивает детализированный контроль доступа, возможности аудита и соответствие политикам расположения данных или хранения. Служба агента Foundry управляет контейнерами и жизненным циклом данных в этих контейнерах.

  • Выделенный экземпляр поиска ИИ сохраняет доступный для поиска фрагментируемый индекс отправленных файлов из бесед с агентом. Он также сохраняет статические файлы, добавляемые в качестве источников знаний при создании агента. Служба агента Foundry управляет индексом, схемой и данными и использует собственную стратегию блокирования и логику запросов.

• Шлюз приложений служит безопасной масштабируемой точкой входа для всего трафика HTTP и HTTPS в пользовательский интерфейс чата. Он обеспечивает завершение работы протокола TLS и маршрутизацию на основе пути. Он также распределяет запросы между зонами доступности, которые поддерживают высокий уровень доступности и производительность для уровня веб-приложений. Его серверная часть — это служба приложений, в которую размещается код приложения.

  • Брандмауэр веб-приложений Azure интегрируется с Шлюзом приложений для защиты пользовательского интерфейса чата от распространенных веб-уязвимостей и атак. Он проверяет и фильтрует HTTP-запросы, предоставляющие уровень безопасности для общедоступных приложений.

  • Azure Key Vault безопасно хранит сертификаты TLS, необходимые шлюзу приложений, и управляет ими. Централизованное управление сертификатами в Key Vault поддерживает автоматическую смену, аудит и соответствие стандартам безопасности организации. Эта архитектура не требует хранимых ключей или других секретов.

• Виртуальная сеть Azure обеспечивает сетевую изоляцию для всех компонентов. При расположении ресурсов в частной виртуальной сети вы управляете трафиком на востоке и на северо-юге, применяете сегментацию, храните трафик в частном режиме и обеспечивает проверку потоков входящего трафика и исходящего трафика. Эта настройка помогает соответствовать требованиям к безопасности и соответствию требованиям.

• Приватный канал Azure подключает все службы PaaS, такие как Azure Cosmos DB, хранилище, поиск ИИ и служба агента Foundry, к виртуальной сети через частные конечные точки. Этот подход гарантирует, что весь трафик данных остается в магистрали Azure, что устраняет воздействие на общедоступный Интернет и уменьшает область атаки.

• Брандмауэр Azure проверяет и контролирует весь исходящий (исходящий) трафик из виртуальной сети. Он применяет правила на основе полного доменного имени (FQDN), что гарантирует, что доступны только утвержденные назначения. Эта конфигурация помогает предотвратить утечку данных и соответствовать требованиям к безопасности сети.

• Azure DNS предоставляет частные зоны доменных имен (DNS), связанные с виртуальной сетью. Эта функция обеспечивает разрешение имен для частных конечных точек, что гарантирует, что все обмен данными между службами использует частные IP-адреса и остается в пределах границы сети.

• Хранилище размещает код веб-приложения в виде ZIP-файла для развертывания в Службе приложений. Этот метод поддерживает безопасные, автоматизированные рабочие процессы развертывания и отделяет артефакты приложений от вычислительных ресурсов.

Альтернативы

Эта архитектура включает несколько компонентов, которые можно заменить другими службами Azure или подходами в зависимости от функциональных и нефункциональных требований рабочей нагрузки. Рассмотрим следующие варианты и компромиссы.

Оркестрация чата

Текущий подход: Эта архитектура использует службу агента Foundry для оркестрации потоков чата, включая получение данных об основе из хранилищ знаний и вызов моделей Azure OpenAI. Служба агента Foundry предоставляет бессерверную недетерминированную оркестрацию. Он обрабатывает запросы чата, управление потоками, вызов инструментов, безопасность содержимого и интеграцию с удостоверениями, сетью и наблюдаемостью. Он предоставляет собственное решение для базы данных памяти.

Альтернативный подход: Вы можете самостоятельно разместить уровень оркестрации с помощью таких платформ, как семантический ядро или LangChain. Используйте эти платформы для реализации детерминированных потоков чата на основе кода и пользовательской логики оркестрации.

Рассмотрите эту альтернативу, если для рабочей нагрузки требуются следующие возможности:

• Точное, детерминированное управление последовательностью оркестрации, вызовом инструментов или проектированием запросов

• Интеграция с пользовательской бизнес-логикой или внешними системами, которые служба агента Foundry не поддерживает изначально

• Расширенная маршрутизация запросов клиента для экспериментов или безопасных методов развертывания

• Пользовательское решение базы данных памяти, которое отличается от собственного решения службы агента Foundry

Локальная оркестрация повышает операционную сложность и требует управления вычислительными ресурсами, масштабированием и безопасностью.

Компоненты уровня приложений

Текущий подход: Интерфейсный веб-сайт пользовательского интерфейса чата размещается в функции веб-приложений службы приложений, которая предоставляет управляемую масштабируемую платформу для веб-приложений. Веб-приложения интегрируются изначально с сетевыми функциями и функциями безопасности Azure.

Альтернативный подход: Вы можете использовать другие вычислительные платформы, управляемые Azure, такие как приложения контейнеров Azure или служба Azure Kubernetes (AKS), для размещения уровня приложений.

Рассмотрите эту альтернативу, если рабочая нагрузка соответствует любому из следующих условий:

• Другая платформа вычислений лучше поддерживает определенные варианты использования и совместное размещение служб на этой платформе может повысить эффективность затрат и упростить операции.

• Приложению требуется более сложное масштабирование, оркестрация или настраиваемая сеть

Служба приложений остается предпочтительным вариантом для простоты размещения веб-приложений и их API.

Хранилище данных на базе данных (знаний)

Текущий подход: Эта архитектура использует поиск ИИ в качестве основного хранилища данных для создания знаний. Он использует возможности поиска векторов ИИ и семантического ранжирования.

Альтернативный подход: Вы можете использовать другие платформы данных для обнаружения знаний, таких как Azure Cosmos DB, База данных SQL Azure или другие хранилища данных для обработки транзакций (OLTP). Платформа данных зависит от имеющихся ресурсов данных, требований к свежести данных и требований к запросу.

Рассмотрите эту альтернативу, если рабочая нагрузка соответствует любому из следующих условий:

• Вы уже управляете знаниями о основе в существующей транзакционной или операционной базе данных.

• Требуется поддержка нескольких моделей или пакета SDK, недоступная в поиске ИИ

• Необходимо интегрировать с специализированными источниками данных или устаревшими системами

Поиск векторов часто используется для создания дополненного вектора, но не всегда требуется. Дополнительные сведения см. в разделе "Выбор службы Azure" для поиска векторов. Перед выбором хранилища данных оцените шаблоны доступа к данным, задержку и масштабируемость рабочей нагрузки.

Предопределенный агент или динамически созданный агент

Текущий подход: Эталонная реализация использует статически определенный агент, который развертывается как микрослужба в Azure AI Foundry. Логика агента и источники данных настраиваются при развертывании и остаются неизменными до следующего выпуска приложения. Этот подход хорошо работает, когда поведение агента и источники данных стабильны и управляются с помощью процессов DevOps.

Альтернативный подход: Вы можете динамически создавать или изменять агенты во время выполнения с помощью пакета SDK агента ИИ Azure. Такой подход позволяет приложению создавать экземпляры агентов по запросу, настраивать системные запросы или перенастраивать подключения на основе контекста пользователя или бизнес-логики.

Рассмотрите возможность динамических агентов, если для рабочей нагрузки требуются следующие возможности:

• Персонализированное поведение агента или источники данных для каждого пользователя или сеанса

• Частые или программные изменения конфигурации агента

• Эфемерная поддержка агента для конкретных контекстов для расширенных возможностей пользователей

Динамическое управление агентами повышает гибкость, но также представляет бремя управления жизненным циклом. Убедитесь, что у вас есть соответствующие элементы управления для создания, изменения и очистки агента.

Выберите подход агента, который соответствует требованиям к пользовательскому интерфейсу рабочей нагрузки.

Соображения

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Примените эту архитектуру и рабочие нагрузки ИИ в руководстве по проектированию Azure на этапе разработки рабочей нагрузки.

Надежность

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. Контрольный список проверки конструкции на надежность.

Базовая архитектура веб-приложения службы приложений посвящена зональной избыточности для ключевых региональных служб. Зоны доступности физически отделяются в пределах региона, обеспечивающие избыточность при развертывании двух или более экземпляров между ними. Если время простоя одной зоны возникает, другие в регионе могут оставаться не затронутыми. Архитектура также распределяет экземпляры и конфигурации служб Azure между зонами доступности. Дополнительные сведения см. в разделе "Базовые высокодоступные веб-приложения с высоким уровнем доступности".

В этом разделе описывается надежность компонентов, которые не рассматриваются в базовой архитектуре службы приложений, в частности Azure AI Foundry и ai Search.

Избыточность зоны на уровне оркестрации

Корпоративные развертывания обычно требуют зональной избыточности, чтобы свести к минимуму риск сбоя службы от сбоев на уровне зоны. В Azure зональная избыточность означает использование ресурсов, поддерживающих зоны доступности и развертывание по крайней мере трех экземпляров, или включение избыточности на уровне платформы, где прямой элемент управления экземплярами недоступен.

В этой архитектуре Azure AI Foundry размещается возможность службы агента Foundry. Надежность агента зависит от доступности зависимостей службы агента Foundry, которые являются Azure Cosmos DB, storage и AI Search. Служба агента Foundry управляет данными в этих службах, но настраивает их надежность в подписке.

Чтобы обеспечить зональную избыточность для уровня оркестрации, выполните следующие рекомендации:

• Включите избыточность зоны в учетной записи Azure Cosmos DB для NoSQL . Эта конфигурация обеспечивает синхронную репликацию данных в нескольких зонах, что снижает риск потери данных или простоя из-за сбоя в одной зоне.

  Кроме того, рассмотрите возможность глобального распределения для устранения региональных сбоев в Azure Cosmos DB.

• Используйте избыточное между зонами хранилище (ZRS) для учетной записи хранения. Для повышения устойчивости используйте геоизбыточное хранилище (GZRS), которое объединяет зональную и региональную избыточность.

• Настройте экземпляр поиска ИИ по крайней мере с тремя репликами. Эта конфигурация гарантирует, что служба распределяет реплики между уникальными зонами в вашем регионе.

Если агент интегрируется с другими зависимостями, зависящими от рабочей нагрузки, например подключения к пользовательским инструментам или внешним хранилищам знаний, убедитесь, что эти зависимости соответствуют вашим требованиям к доступности и избыточности. Любая однозонная или нередредантная зависимость может подорвать общую надежность слоя оркестрации.

Портал AI Foundry, api-интерфейсы плоскости данных и служба агента Foundry не предоставляют прямые элементы управления избыточностью зоны.

Надежность в размещении модели Azure AI Foundry

Azure AI Foundry предоставляет модели как услуга (MaaS) с несколькими вариантами развертывания. Эти варианты в основном поддерживают управление квотами и пропускной способностью, а не традиционные высокий уровень доступности в регионе. Развертывания стандартной модели работают в одном регионе и не поддерживают зоны доступности. Чтобы обеспечить доступность нескольких центров обработки данных, необходимо использовать развертывание глобальной или зоны данных.

В сценариях корпоративного чата разверните подготовленную зону данных и стандартную модель зоны данных . Настройте переключение для обработки избыточного трафика или сбоев. Если рабочая нагрузка не требует низкой задержки или строгого географического расположения и обработки данных, используйте глобальные развертывания для максимальной устойчивости.

Azure AI Foundry не поддерживает расширенные механизмы балансировки нагрузки или отработки отказа, такие как маршрутизация с циклическим перебором или прерывание цепи для развертываний моделей. Если требуется детализированный контроль избыточности и отработки отказа в регионе, разместите логику доступа к модели за пределами управляемой службы. Например, можно создать пользовательский шлюз с помощью службы "Управление API Azure". Этот подход позволяет реализовать пользовательские стратегии маршрутизации, проверки работоспособности и отработки отказа. Но она также увеличивает операционную сложность и переключает ответственность за надежность этого компонента в вашу команду.

Вы также можете предоставлять внешние модели шлюза в виде пользовательских средств на основе API или хранилищ знаний для агента. Дополнительные сведения см. в статье "Использование шлюза перед несколькими развертываниями Или экземплярами Azure OpenAI".

Надежность в поиске ИИ для корпоративных знаний

Разверните поиск ИИ с помощью ценовой категории "Стандартный" или выше в регионе, поддерживающем зоны доступности. Настройте по крайней мере три реплики, чтобы служба распределяла экземпляры между отдельными зонами доступности. Эта конфигурация обеспечивает устойчивость к сбоям уровня зоны и поддерживает высокий уровень доступности для операций поиска.

Чтобы определить оптимальное количество реплик и секций для рабочей нагрузки, используйте следующие методы:

• Мониторинг поиска ИИ с помощью встроенных метрик и журналов. Отслеживание задержки запросов, регулирования и использования ресурсов.

• Используйте метрики мониторинга и журналы и анализ производительности, чтобы определить соответствующее количество реплик. Этот подход помогает избежать регулирования из большого объема запросов, недостаточно секций или ограничений индекса.

• Обеспечение надежности индексирования путем предотвращения нарушений периодического индексирования или индексирования ошибок. Рассмотрите возможность индексирования в автономный индекс и переключение из динамического индекса на перестроенный индекс после проверки целостности данных.

Надежность в брандмауэре Azure

Брандмауэр Azure является критической точкой управления исходящим трафиком в этой архитектуре, но представляет собой одну точку сбоя для всего исходящего трафика. Чтобы устранить этот риск, разверните брандмауэр Azure во всех зонах доступности в вашем регионе. Эта конфигурация помогает поддерживать исходящее подключение, если зона становится недоступной.

Если для рабочей нагрузки требуется большой объем одновременных исходящих подключений, настройте брандмауэр Azure с несколькими общедоступными IP-адресами. Этот подход распределяет подключения преобразования сетевых адресов источника (SNAT) между несколькими префиксами IP-адресов, что снижает риск исчерпания портов SNAT. Исчерпание SNAT может привести к периодическим или полной потере исходящего подключения для агентов и других компонентов рабочей нагрузки, что может привести к простою функции или снижению производительности.

Мониторинг использования портов SNAT и работоспособности брандмауэра. Если вы наблюдаете сбои подключения или проблемы пропускной способности, просмотрите метрики и журналы брандмауэра для выявления и устранения нехватки SNAT или других узких мест.

Изоляция зависимостей службы агента Foundry от аналогичных компонентов рабочей нагрузки

Чтобы максимально повысить надежность и свести к минимуму радиус сбоя, строго изолируйте зависимости службы агента Foundry от других компонентов рабочей нагрузки, использующих те же службы Azure. В частности, не совместно использовать службы поиска ИИ, Azure Cosmos DB или хранилища между службой агентов и другими компонентами приложения. Вместо этого подготовьте выделенные экземпляры для необходимых зависимостей службы агента.

Это разделение обеспечивает два ключевых преимущества:

• Он содержит сбои или снижение производительности до одного сегмента рабочей нагрузки, что предотвращает каскадное влияние на несвязанные функции приложения.

• Он позволяет применять целевые операционные процессы, такие как резервное копирование, восстановление и отработка отказа. Эти процессы настраиваются на конкретные требования к доступности и восстановлению потока рабочей нагрузки, использующего эти ресурсы.

Например, если приложение пользовательского интерфейса чата должно хранить состояние транзакций в Azure Cosmos DB, подготовьте отдельную учетную запись и базу данных Azure Cosmos DB для этой цели, а не повторное использование учетной записи или базы данных, которым управляет служба агента Foundry. Даже если затраты или операционная простота мотивируют общий доступ к ресурсам, риск возникновения события надежности, затрагивающего несвязанные функции рабочей нагрузки, перевешивает потенциальную экономию в большинстве корпоративных сценариев.

Это важно

Если данные, зависящие от рабочей нагрузки, зависят от зависимостей агента по затратам или рабочим причинам, никогда не взаимодействуют напрямую с данными, управляемыми системой, такими как коллекции, контейнеры или индексы, создаваемые службой агентов Foundry. Эти внутренние сведения о реализации не являются незадокументированы и подлежат изменению без уведомления. Прямой доступ может нарушить службу агента или привести к потере данных. Всегда используйте API плоскости данных службы агента Foundry для обработки данных и обрабатывать базовые данные как непрозрачные и отслеживаемые.

Структура с несколькими регионами

Эта архитектура использует зоны доступности для обеспечения высокой доступности в одном регионе Azure. Это не решение для нескольких регионов. В нем отсутствуют следующие критически важные элементы, необходимые для региональной устойчивости и аварийного восстановления (аварийного восстановления).

• Глобальный трафик и маршрутизация трафика
• Управление DNS для отработки отказа
• Стратегии репликации или изоляции данных в разных регионах
• Обозначение "активный-активный", "активный-пассивный" или "активный-холодный"
• Региональные процессы отработки отказа и восстановления для удовлетворения целей времени восстановления (ОСРВ) и точек восстановления (RPOS)
• Рассмотрение доступности регионов для разработчиков, включая портал Azure AI Foundry и API плоскости данных

Если для рабочей нагрузки требуется непрерывность бизнес-процессов при возникновении регионального сбоя, необходимо разработать и реализовать дополнительные компоненты и операционные процессы за пределами этой архитектуры. В частности, необходимо устранить балансировку нагрузки и отработку отказа на каждом уровне архитектуры, включая следующие области:

• Приземление данных (хранилища знаний)
• Размещение и вывод конечных точек модели
• Уровень оркестрации или агента
• Трафик пользовательского интерфейса и точки входа DNS

Кроме того, необходимо обеспечить работоспособность, мониторинг и контроль безопасности содержимого в разных регионах.

Эта базовая архитектура не имеет возможностей с несколькими регионами, поэтому региональные сбои могут привести к потере службы в рабочей нагрузке.

Восстановление после катастрофы

Архитектура чата содержит компоненты с отслеживанием состояния, поэтому планирование аварийного восстановления является важным. Обычно для этих рабочих нагрузок требуется хранилище памяти для активных или приостановленных сеансов чата. Они также требуют хранения дополнительных данных, таких как документы или изображения, добавленные в потоки чата. Уровень оркестрации агента также может поддерживать состояние, относящееся к потокам беседы. В этой архитектуре служба агента Foundry использует Azure Cosmos DB, хранилище и поиск искусственного интеллекта для сохранения рабочего и транзакционного состояния. Жизненный цикл и связь этого состояния между компонентами определяет стратегию аварийного восстановления и операции восстановления.

Для службы агента Foundry убедитесь, что все зависимости можно восстановить до согласованной точки во времени. Этот подход помогает поддерживать целостность транзакций в трех внешних зависимостях.

Следующие рекомендации по устранению аварийного восстановления для каждой службы:

• Azure Cosmos DB: Включите непрерывную резервную копию для enterprise_memory базы данных. Эта настройка обеспечивает восстановление на определенный момент времени (PITR) с семидневным RPO, включающее определения агентов и потоки чата. Регулярно тестируйте процесс восстановления, чтобы убедиться, что он соответствует RTO и что восстановленные данные остаются доступными для службы агента. Всегда восстанавливайте одну и ту же учетную запись и базу данных.

• Поиск ИИ: В поиске ИИ отсутствуют встроенные возможности восстановления и не поддерживаются прямые манипуляции с индексами. Если происходит потеря или повреждение данных, обратитесь в службу поддержки Майкрософт за помощью по восстановлению индекса. Это ограничение может значительно повлиять на RTO. Если пользовательский интерфейс чата не поддерживает отправку файлов и у вас нет агентов, использующих статические файлы в качестве знаний, возможно, вам не потребуется план аварийного восстановления для поиска ИИ.

  Сохраняйте отдельный, регулярно обновляемый источник истины для ваших корпоративных знаний об основах. Эта практика гарантирует, что при необходимости можно перестроить индексы.

• Хранение: Если у вас есть геоизбыточная учетная запись хранения, используйте отработку отказа, управляемой клиентом , для контейнеров BLOB-объектов, используемых службой агента Foundry. Эта настройка позволяет инициировать отработку отказа во время регионального сбоя. Если вы используете только хранилище, избыточное между зонами, обратитесь в службу поддержки Майкрософт для восстановления данных. Этот процесс может расширить RTO. Как и при поиске ИИ, если пользовательский интерфейс чата не поддерживает отправку файлов и у вас нет агентов, использующих статические файлы в качестве знаний, возможно, вам не потребуется план аварийного восстановления для контейнеров BLOB-объектов.

• Согласованность транзакций: Если хранилище состояний в рабочей нагрузке ссылается на идентификаторы агента ИИ Azure, например идентификаторы потоков или идентификаторы агентов, координируйте восстановление во всех соответствующих хранилищах данных. Восстановление только подмножества зависимостей может привести к потерянным или несогласованным данным. Проектирование процессов аварийного восстановления для обеспечения целостности ссылок между рабочей нагрузкой и состоянием службы агента.

• Определения и конфигурация агента: Определите агенты как код. Хранение определений агентов, подключений, системных запросов и параметров в системе управления версиями. Эта практика позволяет повторно развертывать агенты из известной хорошей конфигурации, если вы потеряете уровень оркестрации. Избегайте внесения незаслеченных изменений в конфигурацию агента с помощью портала ИИ Foundry или API плоскости данных. Этот подход гарантирует, что развернутые агенты остаются воспроизводимыми.

Прежде чем перейти в рабочую среду, создайте модуль Runbook восстановления, который устраняет сбои как в состоянии, принадлежаемом приложению, так и в состоянии агента.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

Эта архитектура расширяет основу безопасности, созданную в базовой эталонной архитектуре чата Azure AI Foundry. Основное различие заключается в добавлении периметра безопасности сети вместе с периметром удостоверений из базовой архитектуры. С точки зрения сети шлюз приложений является единственным ресурсом, предоставляемым интернетом. Это делает приложение пользовательского интерфейса чата доступным для пользователей. С точки зрения идентификации пользовательский интерфейс чата должен проходить проверку подлинности и авторизовать запросы. Используйте управляемые удостоверения, если это возможно для проверки подлинности приложений в службах Azure.

В этом разделе описываются рекомендации по настройке сети и безопасности для смены ключей и модели Azure OpenAI.

Управление удостоверениями и доступом

Эта архитектура в основном использует управляемые удостоверения, назначаемые системой, для проверки подлинности между службами. Вы также можете использовать управляемые удостоверения, назначаемые пользователем. В любом случае примените следующие принципы:

• Изоляция удостоверений по ресурсам и функциям. Подготовка отдельных управляемых удостоверений для следующих компонентов:

  • Учетная запись Azure AI Foundry
  • Каждый проект Azure AI Foundry
  • Веб-приложение
  • Любой пользовательский код оркестратора или интеграции

• Назначьте удостоверение ресурсу Azure только в том случае, если этот ресурс должен пройти проверку подлинности в качестве клиента в другой службе Azure.

• Используйте типы удостоверений, подходящие для назначения. По возможности используйте удостоверения рабочей нагрузки для приложений и автоматизации и используйте удостоверения агента для агентов ИИ.

Доступ к сотруднику портала Azure AI Foundry

При подключении сотрудников к проектам Azure AI Foundry назначьте минимальные разрешения, необходимые для их роли. Используйте группы идентификаторов Microsoft Entra и управление доступом на основе ролей (RBAC), чтобы обеспечить разделение обязанностей. Например, различает разработчиков агентов от специалистов по обработке и анализу данных, которые обрабатывают задачи точной настройки. Однако помните об ограничениях и рисках.

Портал Azure AI Foundry выполняет множество действий с помощью удостоверения службы, а не удостоверения сотрудника. В результате сотрудники, имеющие ограниченные роли RBAC, могут иметь видимость конфиденциальных данных, таких как потоки чата, определения агентов и конфигурация. Этот дизайн портала AI Foundry может случайно обойти требуемые ограничения доступа и предоставить больше информации, чем это было запланировано.

Чтобы снизить риск несанкционированного доступа, ограничьте использование портала в рабочих средах сотрудникам, у которых есть четкая операционная потребность. Для большинства сотрудников отключите или заблокируйте доступ к порталу Azure AI Foundry в рабочей среде. Вместо этого используйте конвейеры автоматического развертывания и инфраструктуру в качестве кода (IaC) для управления конфигурацией агента и проекта.

Рассматривайте создание новых проектов в учетной записи Azure AI Foundry как привилегированное действие. Проекты, созданные на портале, не наследуют установленные элементы управления безопасностью сети, такие как частные конечные точки или группы безопасности сети (NSG). И новые агенты в этих проектах обходят предполагаемый периметр безопасности. Принудительное создание проекта исключительно с помощью управляемых, проверяемых процессов IaC.

Назначения ролей и подключений проекта Azure AI Foundry

Чтобы использовать службу агента Foundry в стандартном режиме, проект должен иметь административные разрешения на зависимости службы агента Foundry. В частности, управляемое удостоверение проекта должно иметь повышенные назначения ролей в учетной записи хранения, поиске ИИ и учетной записи Azure Cosmos DB. Эти разрешения обеспечивают почти полный доступ к этим ресурсам, включая возможность чтения, записи, изменения или удаления данных. Чтобы обеспечить минимальный доступ к привилегиям, изолируйте ресурсы рабочей нагрузки от зависимостей службы агентов Foundry.

Все агенты в одном проекте AI Foundry используют одно управляемое удостоверение. Если рабочая нагрузка использует несколько агентов, которым требуется доступ к разным наборам ресурсов, принцип наименьшей привилегии требует создания отдельного проекта Azure AI Foundry для каждого отдельного шаблона доступа агента. Это разделение позволяет назначать только минимальные необходимые разрешения управляемому удостоверению каждого проекта, что снижает риск чрезмерного или непреднамеренного доступа.

При установке подключений к внешним ресурсам из Azure AI Foundry используйте проверку подлинности на основе идентификаторов Microsoft Entra, если она доступна. Этот подход устраняет необходимость в обслуживании предварительно общих секретов. Область каждого подключения, чтобы использовать его можно только для собственного проекта. Если для нескольких проектов требуется доступ к одному ресурсу, создайте отдельное соединение в каждом проекте, а не совместное использование одного подключения между проектами. Эта практика применяет строгие границы доступа и предотвращает наследование будущих проектов, которым они не требуются.

Избегайте создания подключений на уровне учетной записи Azure AI Foundry. Эти подключения применяются ко всем текущим и будущим проектам в учетной записи. Они могут непреднамеренно предоставлять широкий доступ к ресурсам, нарушать принципы наименьших привилегий и увеличивать риск несанкционированного доступа к данным. Предпочитайте только подключения на уровне проекта.

Нетворкинг

Помимо доступа на основе удостоверений, эта архитектура требует конфиденциальности сети.

Сетевая конструкция включает следующие меры защиты:

• Единая безопасная точка входа для всего трафика пользовательского интерфейса чата, который сводит к минимуму область атаки.

• Отфильтрованный сетевой трафик и исходящий трафик с помощью сочетания групп безопасности сети, брандмауэра веб-приложения, определяемых пользователем маршрутов (UDR) и правил брандмауэра Azure

• Сквозное шифрование данных при передаче с помощью TLS

• Конфиденциальность сети с помощью приватного канала для всех подключений к службе PaaS Azure

• Логическая сегментация и изоляция сетевых ресурсов с выделенными подсетями для каждой основной группы компонентов для поддержки детальных политик безопасности

Сетевые потоки

Схема напоминает базовую архитектуру сквозного чата. Она включает архитектуру Azure OpenAI и три нумерованных сетевых потока. Поток входящего трафика и поток из службы приложений в службы PaaS Azure копируются из базовой веб-архитектуры службы приложений. Поток службы агента Foundry отображает стрелку из частной конечной точки Azure AI Foundry в частной виртуальной сети, которая указывает на службу агента Foundry. Вторая нумерованная стрелка в потоке службы агента Foundry отображает вызовы из виртуального интерфейса агента ИИ Azure в частной сети, которая проходит через частные конечные точки. Третья нумерованная стрелка показывает стрелку из виртуального интерфейса в поле брандмауэра Azure, которое указывает, что все вызовы в интернет-поток через этот брандмауэр.

Базовая архитектура веб-приложения службы приложений описывает поток входящего трафика от пользователя к пользовательскому интерфейсу чата и поток из службы приложений в службы PaaS Azure. В этом разделе основное внимание уделяется взаимодействию с агентом.

Когда пользовательский интерфейс чата взаимодействует с агентом, развернутым в Azure AI Foundry, возникают следующие сетевые потоки:

1. Пользовательский интерфейс чата, размещенный в службе приложений, инициирует HTTPS-запросы через частную конечную точку API плоскости данных Azure AI Foundry.

2. Когда агент обращается к службам Azure PaaS, таким как зависимости служб, пользовательские хранилища знаний или пользовательские средства, он отправляет HTTPS-запросы из делегированной подсети в частные конечные точки этих служб.

3. Когда агент обращается к ресурсам за пределами виртуальной сети, включая ИНТЕРФЕЙСы API на основе Интернета или внешние службы, он вынужден направлять эти HTTPS-запросы из делегированной подсети через брандмауэр Azure.

Частные конечные точки служат критически важным элементом управления безопасностью в этой архитектуре, дополняя безопасность на основе удостоверений.

Вход в Azure AI Foundry

Эта архитектура отключает общедоступный доступ к плоскости данных Azure AI Foundry, разрешая трафик только через приватный канал для Azure AI Foundry. Вы можете получить доступ к большей части портала Azure AI Foundry с помощью веб-сайта портала, но для всех функциональных возможностей уровня проекта требуется доступ к сети. На портале используются API плоскости данных учетной записи AI Foundry, доступные только через частные конечные точки. В результате разработчики и специалисты по обработке и анализу данных должны получить доступ к порталу через окно перехода, одноранговую виртуальную сеть или VPN-подключение ExpressRoute или VPN типа "сеть — сеть".

Все программные взаимодействия с плоскостем данных агента, например из веб-приложения или из внешнего кода оркестрации при вызове вывода модели, также должны использовать эти частные конечные точки. Частные конечные точки определяются на уровне учетной записи, а не на уровне проекта. Поэтому все проекты в учетной записи используют одинаковый набор конечных точек. Вы не можете сегментирование сетевого доступа на уровне проекта, а все проекты совместно используют одинаковый сетевой доступ.

Чтобы поддерживать эту конфигурацию, настройте DNS для следующих конечных точек API Azure AI Foundry FQDN:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

На следующей схеме показано, как разработчик ИИ подключается через Бастион Azure к прямоугольнику перехода виртуальной машины. В этом поле перехода автор может получить доступ к проекту на портале Azure AI Foundry через частную конечную точку в той же сети.

Стрелка от автора агента до Бастиона Azure, в поле прыжка, в частную конечную точку Azure AI Foundry (портал), а затем в проект Azure AI Foundry, содержащий службу агента Foundry. В проекте Azure AI Foundry стрелка указывает на виртуальный интерфейс в подсети интеграции агента ИИ Azure. Конечные стрелки из виртуального интерфейса в три частные конечные точки службы агента Foundry. Эти зависимости : поиск ИИ, Azure Cosmos DB и хранилище.

Управление трафиком из подсети агента Azure AI Foundry

Эта архитектура направляет весь исходящий сетевой трафик из возможности службы агента Foundry через делегированную подсеть в виртуальной сети. Эта подсеть служит единственной точкой исходящего трафика как для необходимых трех зависимостей службы агента, так и для всех внешних источников знаний или подключений инструментов, которые использует агент. Эта конструкция помогает сократить попытки кражи данных из логики оркестрации.

Принудив этот путь исходящего трафика, вы получаете полный контроль над исходящим трафиком. Вы можете применить детализированные правила NSG, настраиваемую маршрутизацию и управление DNS ко всему трафику агента, который покидает службу.

Служба агента использует конфигурацию DNS виртуальной сети для разрешения записей частной конечной точки и необходимых внешних полных доменных имен. Эта настройка гарантирует, что запросы агента создают журналы DNS, которые поддерживают аудит и устранение неполадок.

Группа безопасности сети, подключенная к подсети агента, блокирует весь входящий трафик, так как входящий трафик не должен возникать. Правила NSG исходящего трафика разрешают доступ только к подсетям частной конечной точки в виртуальной сети и через TCP-порт 443 для трафика, привязанного к Интернету. Группа безопасности сети отрицает весь остальной трафик.

Чтобы дополнительно ограничить интернет-трафик, эта архитектура применяет UDR к подсети, которая направляет весь трафик HTTPS через брандмауэр Azure. Брандмауэр управляет полными доменными именами, которые агент может получить через подключения HTTPS. Например, если агенту необходимо получить доступ только к общедоступным API-интерфейсам Bing , настройте брандмауэр Azure, чтобы разрешить трафик api.bing.microsoft.com через порт 443 из этой подсети. Все остальные исходящие назначения запрещены.

Сегментация виртуальной сети и безопасность

Эта архитектура сегментирует виртуальную сеть, назначив каждой основной группе компонентов собственную подсеть. Каждая подсеть имеет выделенную группу безопасности сети, которая ограничивает входящий и исходящий трафик только тем, что требует компонент.

В следующей таблице приведены сведения о конфигурации группы безопасности сети и брандмауэра для каждой подсети.

Имя использования или подсети	Входящий трафик (NSG)	Исходящий трафик (NSG)	UDR для брандмауэра	Правила исходящего трафика брандмауэра
Частные конечные точки snet-privateEndpoints	Виртуальная сеть	Нет разрешенного трафика	Да	Нет разрешенного трафика
Шлюз приложений snet-appGateway	IP-адреса источника пользовательского интерфейса чата, такие как общедоступный Интернет и необходимые источники для службы	Подсеть частной конечной точки и необходимые элементы для службы	нет	-
Служба приложений snet-appServicePlan	Нет разрешенного трафика	Частные конечные точки и Azure Monitor	Да	To Azure Monitor
Служба агента Foundry snet-agentsEgress	Нет разрешенного трафика	Частные конечные точки и Интернет	Да	Только общедоступные полные доменные имена, которые позволяют агентам использовать
Виртуальные машины с полем перехода snet-jumpBoxes	Подсеть Бастиона Azure	Частные конечные точки и Интернет	Да	По мере необходимости виртуальной машины
Агенты сборки snet-buildAgents	Подсеть Бастиона Azure	Частные конечные точки и Интернет	Да	По мере необходимости виртуальной машины
Бастион Azure AzureBastionSubnet	Ознакомьтесь с доступом nSG и Бастионом Azure	Ознакомьтесь с доступом nSG и Бастионом Azure	нет	-
Брандмауэр Azure AzureFirewallSubnet AzureFirewallManagementSubnet	Нет группы безопасности сети	Нет группы безопасности сети	нет	-

Эта конструкция явно запрещает весь остальной трафик через правила NSG или по умолчанию в брандмауэре Azure.

При реализации сегментации сети и безопасности в этой архитектуре следуйте приведенным ниже рекомендациям.

• Разверните план защиты от атак DDoS Azure на общедоступном IP-адресе шлюза приложений, чтобы устранить проблемы с объемными атаками.

• Подключите группу безопасности сети к каждой подсети, поддерживающей ее. Применяйте самые строгие правила, не нарушая необходимые функциональные возможности.

• Примените принудительное туннелирование ко всем поддерживаемым подсетям, чтобы брандмауэр исходящего трафика может проверить весь исходящий трафик. Используйте принудительное туннелирование даже в подсетях, где вы не ожидаете исходящий трафик. Этот метод добавляет глубинную меру защиты, которая защищает от преднамеренного или случайного неправильного использования подсети.

Управление с помощью политики

Чтобы соответствовать базовым параметрам безопасности рабочей нагрузки, используйте политику Azure и политики сети, чтобы убедиться, что все ресурсы рабочей нагрузки соответствуют вашим требованиям. Автоматизация платформы с помощью политики снижает риск смещения конфигурации безопасности и помогает сократить действия проверки вручную.

Рекомендуется реализовать следующие типы политик безопасности для укрепления архитектуры:

• Отключите ключи или другие локальные методы проверки подлинности в службах, таких как службы ИИ Azure и Key Vault.

• Требуется явная настройка правил доступа к сети, частных конечных точек и групп безопасности сети.

• Требуется шифрование, например ключи, управляемые клиентом.

• Ограничить создание ресурсов, например ограничение регионов или типов ресурсов.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

Эта оценка цен Azure предоставляет пример ценообразования для этой архитектуры. В этом примере содержатся только компоненты в этой архитектуре, поэтому настройте его в соответствии с вашим использованием. Наиболее дорогими компонентами в сценарии являются Azure Cosmos DB, поиск ИИ и защита от атак DDoS. Другие важные затраты включают вычисление пользовательского интерфейса чата и шлюз приложений. Оптимизируйте эти ресурсы, чтобы сократить затраты.

Служба агента Foundry

При использовании стандартного развертывания необходимо подготовить зависимости службы и управлять ими в собственной подписке Azure.

В следующих рекомендациях объясняется, как оптимизировать затраты на эти необходимые службы:

• Служба агента Foundry управляет выделением единицы запроса (ЕЗ) в Azure Cosmos DB. Чтобы сократить долгосрочные затраты, приобретите зарезервированную емкость для Azure Cosmos DB. Выравнивать резервирования с ожидаемым сроком использования и объемом. Помните, что зарезервированная емкость требует предварительных обязательств и не имеет гибкости, если шаблоны использования рабочей нагрузки изменяются значительно.

• Если сценарий чата не требует отправки файлов, исключите эту функцию в приложении. В этом случае примените следующие изменения конфигурации:

  • Используйте уровень локально избыточного хранилища (LRS) для учетной записи хранения.
  • Настройте поиск ИИ с одной репликой вместо рекомендуемых трех реплик.

• Регулярно удалять неиспользуемые агенты и связанные с ними потоки с помощью пакета SDK или REST API. Устаревшие агенты и потоки продолжают использовать хранилище и могут увеличивать затраты на Azure Cosmos DB, хранилище и поиск ИИ.

• Отключите функции для зависимых ресурсов, для которых не требуется рабочая нагрузка, например следующие функции:

  • Семантический рангер в поиске ИИ
  • Возможности записи шлюза и нескольких регионов в Azure Cosmos DB

• Чтобы избежать расходов на пропускную способность между регионами, разверните Azure Cosmos DB, хранилище и поиск ИИ в том же регионе Azure, что и служба агента Foundry.

• Избегайте совместного размещения данных, относящихся к рабочей нагрузке, в одних и том же ресурсах Azure Cosmos DB или поиска ИИ, которые использует служба агента Foundry. В некоторых случаях эти ресурсы можно совместно использовать для уменьшения неиспользуемой емкости в единицах ЕЗ или единиц поиска, что снижает затраты. Только рассмотрите возможность совместного использования ресурсов после тщательной оценки риска для надежности, безопасности и компромиссов производительности.

Знания и инструменты агента

Служба агента Foundry выполняет логику агента недетерминированным образом. Он может вызывать любое подключенное хранилище знаний, инструмент или другой агент для каждого запроса, даже если этот ресурс не относится к запросу пользователя. Это может привести к ненужным вызовам внешних API или источников данных, увеличению затрат для каждой транзакции и внедрению непредсказуемых шаблонов использования, которые усложняют прогнозирование бюджета.

Чтобы управлять затратами и поддерживать прогнозируемость поведения, выполните следующие стратегии:

• Подключите только хранилища знаний, инструменты или агенты, которые, скорее всего, будут использоваться с большинством вызовов агента. Избегайте подключения ресурсов, которые редко требуются или что влечет за собой высокие затраты на каждый вызов, если они не являются важными.

• Тщательно проектируйте и уточняйте системный запрос, чтобы указать агенту свести к минимуму ненужные или избыточные внешние вызовы. Системный запрос должен помочь агенту использовать только наиболее релевантные подключения для каждого запроса.

• Используйте данные телеметрии Azure AI Foundry для отслеживания того, какие внешние API, хранилища знаний или инструменты, к которым обращается агент, как часто он обращается к ним, а также связанные с ними затраты. Регулярно просматривайте эти данные телеметрии, чтобы определить непредвиденные шаблоны использования или пики затрат и настроить системный запрос по мере необходимости.

• Помните, что недетерминированное вызов может затруднить прогнозирование затрат, особенно при интеграции с лимитными API. Если требуется прогнозируемая стоимость, рассмотрите возможность самостоятельного размещения оркестратора с помощью детерминированного кода.

Модели Azure OpenAI

Развертывания моделей в Azure AI Foundry используют подход MaaS. Затраты зависят в первую очередь от использования или предварительно подготовленного выделения.

Чтобы управлять затратами на модель потребления в этой архитектуре, используйте сочетание следующих подходов:

• Управление клиентами. Клиентские запросы управляют большинством затрат в модели потребления, поэтому управление поведением агента имеет решающее значение.

  Чтобы уменьшить ненужное использование, выполните следующие действия:

  • Утвердить всех потребителей модели. Не предоставляйте модели таким образом, чтобы разрешить неограниченный доступ.

  • Применение ограничений на ограничение маркеров, таких как max_tokens логика агента и max_completions их использование. Этот элемент управления доступен только в локальной оркестрации. Служба агента Foundry не поддерживает эту функцию.

  • Оптимизируйте входные данные запроса и длину ответа. Более длинные запросы потребляют больше маркеров, что увеличивает затраты. Запросы, которые не имеют достаточной эффективности модели контекста. Создайте краткие запросы, которые предоставляют достаточно контекста, чтобы позволить модели создавать полезный ответ. Убедитесь, что вы оптимизируете ограничение длины ответа.

    Этот уровень управления доступен только в локальной оркестрации. Служба агента Foundry не предоставляет достаточно конфигурации для поддержки этой функции.

• Выберите подходящую модель для агента. Выберите наименьшую затратную модель, которая соответствует требованиям агента. Избегайте использования моделей с более высокими затратами, если они не являются важными. Например, эталонная реализация использует GPT-4o вместо более дорогой модели и достигает достаточных результатов.

• Мониторинг использования и управление ими. Используйте данные телеметрии управления затратами Майкрософт для отслеживания использования маркеров, задания бюджетов и создания оповещений об аномалиях. Регулярно просматривайте шаблоны использования и корректируйте квоты или клиентский доступ по мере необходимости. Дополнительные сведения см. в статье "Планирование затрат и управление затратами на Azure AI Foundry".

• Используйте правильный тип развертывания. Используйте цены на оплату по мере использования для непредсказуемых рабочих нагрузок и переключитесь на подготовленную пропускную способность при стабильном и предсказуемом использовании. Объединяйте оба варианта при создании надежной базовой базы.

• Ограничение использования игровой площадки. Чтобы предотвратить незапланированные производственные затраты, ограничьте использование детской площадки Azure AI Foundry только для предварительной подготовки сред.

• Тщательно запланируйте настройку и создание образов. Эти функции имеют разные модели выставления счетов. Плата взимается в час или за пакет. Планирование использования для выравнивания интервалов выставления счетов и предотвращения отходов.

Ресурсы безопасности сети

Для этой архитектуры требуется брандмауэр Azure в качестве точки управления исходящим трафиком. Чтобы оптимизировать затраты, используйте базовый уровень брандмауэра Azure, если остальные компоненты рабочей нагрузки не требуют дополнительных функций. Более высокие уровни добавляют затраты, поэтому используйте их только в том случае, если вам нужны их возможности.

Если ваша организация использует целевые зоны Azure, рассмотрите возможность использования общего брандмауэра и распределенных ресурсов типа "отказ в обслуживании" (DDoS), чтобы отложить или сократить затраты. Рабочие нагрузки, имеющие аналогичные требования к безопасности и производительности, могут воспользоваться общими ресурсами. Убедитесь, что общие ресурсы не представляют рисков безопасности или эксплуатации. Эта архитектура, развернутая в целевой зоне Azure, использует общие ресурсы.

Операционное превосходство

Операционное превосходство охватывает процессы, которые развертывают приложение и продолжают работать в рабочей среде. Для получения дополнительной информации см. Контрольный список для оценки проектирования с точки зрения операционной эффективности.

Следующие рекомендации по операционному превосходству не включают интерфейсные элементы приложения, которые остаются такими же, как и базовая архитектура высокоизбыточного веб-приложения с высоким уровнем доступности.

При планировании экспериментов, тестирования и рабочих сред создайте отдельные и изолированные ресурсы ИИ Foundry, включая зависимости.

Вычисление агента

Корпорация Майкрософт полностью управляет бессерверной вычислительной платформой для REST API агента ИИ Azure и логикой реализации оркестрации. Локальная оркестрация обеспечивает более широкий контроль над характеристиками среды выполнения и емкостью, но необходимо напрямую управлять операциями дня 2 для этой платформы. Оцените ограничения и обязанности вашего подхода, чтобы понять, какие операции день-2 необходимо реализовать для поддержки уровня оркестрации.

В обоих подходах необходимо управлять хранилищем состояний, например журналом чата и конфигурацией агента для устойчивости, резервного копирования и восстановления.

Контроль

Как и в базовой архитектуре, данные диагностики из всех служб настроены для отправки в рабочую область Log Analytics рабочей нагрузки. Все службы, кроме службы приложений, фиксируют все журналы. В рабочей среде может не потребоваться записать все журналы. Например, для приложения пользовательского интерфейса чата может потребоваться AppServiceHTTPLogsтолько , AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogsи AppServiceAuthenticationLogs. Настройте потоки журналов в соответствии с вашими потребностями в работе.

Оцените пользовательские оповещения, такие как пользовательские оповещения в базовых оповещениях Azure Monitor, для ресурсов в этой архитектуре. Рассмотрим следующие оповещения:

• Оповещения поиска ИИ
• Оповещения служб ИИ
• Оповещения веб-приложений

Отслеживайте использование маркеров в развертываниях модели. В этой архитектуре Azure AI Foundry отслеживает использование маркеров через интеграцию с Application Insights.

Все виртуальные машины агента сборки находятся в высоко привилегированном расположении, которое предоставляет эти виртуальные машины сетевой линии видимости для плоскости данных всех компонентов в архитектуре. Убедитесь, что эти виртуальные машины выдают достаточно журналов, чтобы понять, когда они используются, кто использует их и какие действия они выполняют.

Управление версиями агента и жизненный цикл

Обрабатывать каждый агент как независимо развертываемый модуль в рабочей нагрузке чата, если только вы не разрабатываете приложение для динамического создания и удаления агентов во время выполнения. Эти агенты имеют требования к управлению жизненным циклом, аналогичные другим микрослужбам в рабочей нагрузке.

Чтобы предотвратить нарушения работы служб, убедитесь в безопасном и управляемом развертывании агента, реализуя следующие подходы:

• Определите агенты как код. Всегда хранить определения агента, подключения, системные запросы и параметры конфигурации в системе управления версиями. Эта практика обеспечивает трассировку и воспроизводимость. Избегайте неустраченных изменений на портале Azure AI Foundry.

• Автоматизация развертывания агента. Используйте конвейеры непрерывной интеграции и непрерывного развертывания рабочей нагрузки (CI/CD). Используйте пакет SDK агента ИИ Azure для создания, тестирования и развертывания изменений агента из агентов сборки, подключенных к сети.

  Предпочитайте конвейеры агента, которые можно развертывать независимо для небольших добавочных изменений. Но убедитесь, что конвейеры обеспечивают достаточную гибкость для их развертывания вместе с кодом приложения, если требуется координированные обновления. Чтобы обеспечить поддержку этого метода, слабо сочетайте код пользовательского интерфейса чата и агенты чата, чтобы изменения одного компонента не требовали одновременных изменений в другой.

• Тестирование перед рабочей средой. Проверьте поведение агента, запросы и подключения в предварительных средах. Используйте сочетание автоматических и ручных тестов для перехвата регрессий, проблем безопасности и непредвиденных изменений в поведении агента.

  Агенты, определенные в службе агентов Foundry, ведут себя недетерминированно, поэтому необходимо определить, как измерять и поддерживать требуемый уровень качества. Создайте и запустите набор тестов, который проверяет идеальные ответы на реалистичные вопросы и сценарии пользователя.

• Версия и отслеживание агентов. Назначьте каждому агенту четкие идентификаторы версий. Сохраняйте записи о том, какие версии агента активны, а также их зависимости, такие как модели, источники данных и средства. Предпочитайте развертывание новых версий агента вместе с существующими, чтобы обеспечить постепенное развертывание, откат и контролируемый перенос пользователей или сеансов.

• Планирование восстановления размещения. Azure AI Foundry не обеспечивает встроенную поддержку сине-зеленого или канарского развертывания агентов. Если вам нужны эти шаблоны развертывания, реализуйте уровень маршрутизации, например шлюз API или пользовательский маршрутизатор, перед API агента. Этот уровень маршрутизации позволяет постепенно перемещать трафик между версиями агента, отслеживать влияние и выполнять полную переключение при готовности.

• Удаление агента координат. При удалении агентов обратитесь к процессу с требованиями к управлению состоянием приложения и взаимодействию с пользователем. Правильно обработайте активные сеансы чата. В зависимости от функциональных требований рабочей нагрузки можно перенести сеансы, закрепить пользователей на старую версию агента или требовать от пользователей запуска новых сеансов.

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки конструкции для эффективности производительности.

В этом разделе рассматривается эффективность поиска ИИ, развертывания моделей и Azure AI Foundry.

Эффективность производительности в поиске ИИ

В службе агентов Foundry вы не управляете конкретными запросами, отправленными в индексы, так как агенты без кода. Чтобы оптимизировать производительность, сосредоточьтесь на том, что можно контролировать в индексе. Узнайте, как агент обычно запрашивает индекс и применяет рекомендации для анализа и оптимизации производительности в поиске ИИ.

Если только настройка сервера индекса не устраняет все узкие места, рассмотрите следующие варианты:

• Замените прямое подключение к поиску ИИ подключением к API, которому вы владеете. Этот API может реализовать код, оптимизированный для шаблонов извлечения агента.

• Измените уровень оркестрации, чтобы использовать локальную альтернативу , чтобы можно было определить и оптимизировать запросы в собственном коде оркестратора.

Эффективность производительности в развертываниях моделей

• Определите, требуется ли приложению подготовленная пропускная способность или можно ли использовать общую модель (потребление). Подготовленная пропускная способность обеспечивает зарезервированную емкость и прогнозируемую задержку, которая важна для рабочих нагрузок с строгими целями уровня обслуживания. Модель потребления обеспечивает лучшие усилия и может страдать от шумных последствий соседей.

• Отслеживайте использование, управляемое подготовкой , чтобы избежать чрезмерной подготовки или недооказания.

• Выберите модель беседы, которая соответствует вашим требованиям к задержке вывода.

• Разверните модели в том же регионе данных, что и агенты, чтобы свести к минимуму задержку в сети.

Производительность агента ИИ Azure

Агенты ИИ Azure выполняются в серверной части бессерверных вычислений, которая не поддерживает настраиваемую настройку производительности. Однако вы по-прежнему можете повысить производительность с помощью разработки агента:

• Свести к минимуму количество хранилищ знаний и инструментов, подключенных к агенту чата. Каждое дополнительное подключение потенциально увеличивает общую среду выполнения для вызова агента, так как агент может вызывать все настроенные ресурсы для каждого запроса.

• Используйте Azure Monitor и Application Insights для отслеживания времени вызова агента, задержки и задержки хранилища знаний и частоты ошибок. Регулярно просматривайте эти данные телеметрии для выявления медленных знаний или подключений к инструментам.

• Система конструктора предлагает агенту эффективно использовать подключения. Например, указать агенту запрашивать внешние хранилища знаний только при необходимости или избегать избыточных вызовов средства.

• Отслеживайте ограничения или квоты служб, которые могут повлиять на производительность во время пикового использования. Следите за индикаторами регулирования, такими как ответы HTTP 429 или 503, даже если бессерверные вычисления масштабируется автоматически.

Развертывание этого сценария

Чтобы развернуть и запустить эту эталонную реализацию, следуйте руководству по развертыванию в базовой реализации службы агента Foundry.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Роб Багби | Разработчик основного содержимого — шаблоны и практики Azure
• Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure

Другие участники:

• Рауф Алиуат | Старший инженер по программному обеспечению
• Фредди Айала | Архитектор облачных решений
• Prabal Deb | Главный инженер программного обеспечения
• Ritesh Modi | Главный инженер программного обеспечения
• Райан Пфальц | Старший технический руководитель программы

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Следующий шаг

• Базовая архитектура чата Azure AI Foundry в целевой зоне Azure

Связанные ресурсы

• Перспектива Azure Well-Architected Framework для рабочих нагрузок ИИ в Azure
• Azure OpenAI
• Модели Azure OpenAI
• Фильтрование содержимого

Корпоративные приложения чата могут предоставлять сотрудникам возможность взаимодействия с агентами искусственного интеллекта. Эта возможность становится все более мощной благодаря текущим улучшениям языковых моделей, таких как модели GPT OpenAI и пакеты SDK оркестрации, такие как семантический ядро. Эти приложения чата обычно состоят из следующих компонентов:

• Пользовательский интерфейс чата, интегрированный в более крупное корпоративное приложение. Он предоставляет пользователям возможность общения вместе с другими бизнес-функциями.

• Репозитории данных, содержащие сведения о домене, относящиеся к запросам пользователей.

• Языковые модели, которые причиняют данные, относящиеся к домену, для получения соответствующих ответов.

• Оркестратор или агент, который контролирует взаимодействие между источниками данных, языковыми моделями и конечным пользователем.

В этой статье представлена базовая архитектура, помогающая создавать и развертывать корпоративные приложения чата с помощью Azure AI Foundry и Azure OpenAI в модели Foundry. В этой архитектуре используется один агент, размещенный в службе агента Azure AI Foundry. Агент получает сообщения пользователей, а затем запрашивает хранилища данных для получения сведений об основе для языковой модели.

Пользовательский интерфейс чата следует базовому руководству веб-приложения службы приложений Azure по развертыванию безопасного, избыточного между зонами и высокодоступного веб-приложения в службе приложений. В этой архитектуре служба приложений взаимодействует с решением Платформы Azure как услуга (PaaS) через интеграцию виртуальной сети с частными конечными точками. В архитектуре пользовательского интерфейса чата служба приложений взаимодействует с агентом через частную конечную точку. Общедоступный доступ к порталу Azure AI Foundry и агентам отключен.

Это важно

В этой статье не описываются компоненты или решения архитектуры из базовой архитектуры веб-приложения службы приложений. Ознакомьтесь с этой статьей по архитектуре по размещению веб-приложения, содержащего пользовательский интерфейс чата.

Эта архитектура использует стандартную настройку агента Foundry Agent Service для обеспечения безопасности, соответствия требованиям и контроля корпоративного уровня. В этой конфигурации вы используете собственную сеть для сетевой изоляции и собственных ресурсов Azure для хранения состояния чата и агента. Все взаимодействие между компонентами приложений и службами Azure происходит через частные конечные точки, что гарантирует, что трафик данных остается в виртуальной сети рабочей нагрузки. Исходящий трафик от агентов строго направляется через брандмауэр Azure, который применяет правила исходящего трафика.

Подсказка

Эталонная реализация службы агента Foundry демонстрирует базовую сквозную реализацию чата в Azure. Он служит основой для разработки пользовательских решений при переходе к рабочей среде.

Архитектура

В правом углу отдельный прямоугольник представляет Azure AI Foundry, который включает учетную запись и проект. Управляемые удостоверения используются для подключения службы агента Foundry к проекту Azure AI Foundry, который, в свою очередь, обращается к модели Azure OpenAI. На схеме используются нумерованные зеленые круги для указания логического потока, показывающее, как запросы пользователей проходят по сети, взаимодействуют с различными конечными точками и в конечном итоге подключаются к службам ИИ Azure и хранилищу с четко сгруппированы и помечены зависимостями.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

1. Пользователь приложения взаимодействует с пользовательским интерфейсом чата. Запросы направляются через шлюз приложений Azure. Брандмауэр веб-приложений Azure проверяет эти запросы, прежде чем пересылать их в серверную службу приложений.

2. Когда веб-приложение получает запрос пользователя или инструкцию, он вызывает созданный с целью агент. Веб-приложение взаимодействует с агентом с помощью пакета SDK агента ИИ Azure. Веб-приложение вызывает агент через частную конечную точку и проходит проверку подлинности в Azure AI Foundry с помощью управляемого удостоверения.

3. Агент обрабатывает запрос пользователя на основе инструкций в системном запросе. Для выполнения намерения пользователя агент использует настроенную языковую модель и подключенные средства и хранилища знаний.

4. Агент подключается к хранилищу знаний (Поиск ИИ Azure) в частной сети через частную конечную точку.

5. Запросы к внешним хранилищам знаний или средствам, таким как Википедия или Bing, проходят через Брандмауэр Azure для проверки и принудительного применения политики исходящего трафика.

6. Агент подключается к настроенной языковой модели и передает соответствующий контекст.

7. Прежде чем агент возвращает ответ на пользовательский интерфейс, он сохраняет запрос, созданный ответ и список хранилищ знаний, которые содержатся в выделенной базе данных памяти . Эта база данных поддерживает полный журнал бесед, который позволяет взаимодействовать с контекстом и позволяет пользователям возобновлять беседы с агентом без потери предыдущего контекста.

   API-интерфейсы Azure AI Foundry поддерживают разработку пользовательских интерфейсов, которые управляют несколькими параллельными, изолированными от контекста беседами.

Компоненты

Эта архитектура основана на базовой эталонной архитектуре чата Azure AI Foundry. Эта архитектура представляет больше служб Azure для решения корпоративных требований к надежности, безопасности и операционному управлению. Каждый из следующих компонентов играет определенную роль в рабочем решении корпоративного чата:

• Служба агента Foundry предоставляет уровень оркестрации для взаимодействия чата. Он размещает агенты и управляет ими, выполняющими следующие задачи:

  • Обработка запросов пользователей
  • Координация вызовов средств и других агентов
  • Принудительное обеспечение безопасности содержимого
  • Интеграция с корпоративным удостоверением, сетью и наблюдаемостью

  Стандартная настройка агента обеспечивает сетевую изоляцию и обеспечивает контроль над хранилищем данных. Вы предоставляете выделенные ресурсы Azure для состояния агента, журнала чата и хранилища файлов, которым служба агента Foundry управляет исключительно. Другие компоненты приложения в рабочей нагрузке не должны использовать эти необходимые ресурсы.

  • Azure Cosmos DB для NoSQL размещает базу данных памяти этой рабочей нагрузки, вызываемую enterprise_memoryв подписке. Эта база данных хранит рабочее состояние агента, включая потоки чата и определения агента. Эта конструкция гарантирует, что журнал чата и конфигурация агента изолированы, аудит и управление ими в соответствии с требованиями к управлению данными. Служба агента Foundry управляет базой данных, ее коллекциями и данными.

  • Выделенная учетная запись хранения Azure хранит файлы, отправленные во время сеансов чата. Размещение этой учетной записи в подписке обеспечивает детализированный контроль доступа, возможности аудита и соответствие политикам расположения данных или хранения. Служба агента Foundry управляет контейнерами и жизненным циклом данных в этих контейнерах.

  • Выделенный экземпляр поиска ИИ сохраняет доступный для поиска фрагментируемый индекс отправленных файлов из бесед с агентом. Он также сохраняет статические файлы, добавляемые в качестве источников знаний при создании агента. Служба агента Foundry управляет индексом, схемой и данными и использует собственную стратегию блокирования и логику запросов.

• Шлюз приложений служит безопасной масштабируемой точкой входа для всего трафика HTTP и HTTPS в пользовательский интерфейс чата. Он обеспечивает завершение работы протокола TLS и маршрутизацию на основе пути. Он также распределяет запросы между зонами доступности, которые поддерживают высокий уровень доступности и производительность для уровня веб-приложений. Его серверная часть — это служба приложений, в которую размещается код приложения.

  • Брандмауэр веб-приложений Azure интегрируется с Шлюзом приложений для защиты пользовательского интерфейса чата от распространенных веб-уязвимостей и атак. Он проверяет и фильтрует HTTP-запросы, предоставляющие уровень безопасности для общедоступных приложений.

  • Azure Key Vault безопасно хранит сертификаты TLS, необходимые шлюзу приложений, и управляет ими. Централизованное управление сертификатами в Key Vault поддерживает автоматическую смену, аудит и соответствие стандартам безопасности организации. Эта архитектура не требует хранимых ключей или других секретов.

• Виртуальная сеть Azure обеспечивает сетевую изоляцию для всех компонентов. При расположении ресурсов в частной виртуальной сети вы управляете трафиком на востоке и на северо-юге, применяете сегментацию, храните трафик в частном режиме и обеспечивает проверку потоков входящего трафика и исходящего трафика. Эта настройка помогает соответствовать требованиям к безопасности и соответствию требованиям.

• Приватный канал Azure подключает все службы PaaS, такие как Azure Cosmos DB, хранилище, поиск ИИ и служба агента Foundry, к виртуальной сети через частные конечные точки. Этот подход гарантирует, что весь трафик данных остается в магистрали Azure, что устраняет воздействие на общедоступный Интернет и уменьшает область атаки.

• Брандмауэр Azure проверяет и контролирует весь исходящий (исходящий) трафик из виртуальной сети. Он применяет правила на основе полного доменного имени (FQDN), что гарантирует, что доступны только утвержденные назначения. Эта конфигурация помогает предотвратить утечку данных и соответствовать требованиям к безопасности сети.

• Azure DNS предоставляет частные зоны доменных имен (DNS), связанные с виртуальной сетью. Эта функция обеспечивает разрешение имен для частных конечных точек, что гарантирует, что все обмен данными между службами использует частные IP-адреса и остается в пределах границы сети.

• Хранилище размещает код веб-приложения в виде ZIP-файла для развертывания в Службе приложений. Этот метод поддерживает безопасные, автоматизированные рабочие процессы развертывания и отделяет артефакты приложений от вычислительных ресурсов.

Альтернативы

Эта архитектура включает несколько компонентов, которые можно заменить другими службами Azure или подходами в зависимости от функциональных и нефункциональных требований рабочей нагрузки. Рассмотрим следующие варианты и компромиссы.

Оркестрация чата

Текущий подход: Эта архитектура использует службу агента Foundry для оркестрации потоков чата, включая получение данных об основе из хранилищ знаний и вызов моделей Azure OpenAI. Служба агента Foundry предоставляет бессерверную недетерминированную оркестрацию. Он обрабатывает запросы чата, управление потоками, вызов инструментов, безопасность содержимого и интеграцию с удостоверениями, сетью и наблюдаемостью. Он предоставляет собственное решение для базы данных памяти.

Альтернативный подход: Вы можете самостоятельно разместить уровень оркестрации с помощью таких платформ, как семантический ядро или LangChain. Используйте эти платформы для реализации детерминированных потоков чата на основе кода и пользовательской логики оркестрации.

Рассмотрите эту альтернативу, если для рабочей нагрузки требуются следующие возможности:

• Точное, детерминированное управление последовательностью оркестрации, вызовом инструментов или проектированием запросов

• Интеграция с пользовательской бизнес-логикой или внешними системами, которые служба агента Foundry не поддерживает изначально

• Расширенная маршрутизация запросов клиента для экспериментов или безопасных методов развертывания

• Пользовательское решение базы данных памяти, которое отличается от собственного решения службы агента Foundry

Локальная оркестрация повышает операционную сложность и требует управления вычислительными ресурсами, масштабированием и безопасностью.

Компоненты уровня приложений

Текущий подход: Интерфейсный веб-сайт пользовательского интерфейса чата размещается в функции веб-приложений службы приложений, которая предоставляет управляемую масштабируемую платформу для веб-приложений. Веб-приложения интегрируются изначально с сетевыми функциями и функциями безопасности Azure.

Альтернативный подход: Вы можете использовать другие вычислительные платформы, управляемые Azure, такие как приложения контейнеров Azure или служба Azure Kubernetes (AKS), для размещения уровня приложений.

Рассмотрите эту альтернативу, если рабочая нагрузка соответствует любому из следующих условий:

• Другая платформа вычислений лучше поддерживает определенные варианты использования и совместное размещение служб на этой платформе может повысить эффективность затрат и упростить операции.

• Приложению требуется более сложное масштабирование, оркестрация или настраиваемая сеть

Служба приложений остается предпочтительным вариантом для простоты размещения веб-приложений и их API.

Хранилище данных на базе данных (знаний)

Текущий подход: Эта архитектура использует поиск ИИ в качестве основного хранилища данных для создания знаний. Он использует возможности поиска векторов ИИ и семантического ранжирования.

Альтернативный подход: Вы можете использовать другие платформы данных для обнаружения знаний, таких как Azure Cosmos DB, База данных SQL Azure или другие хранилища данных для обработки транзакций (OLTP). Платформа данных зависит от имеющихся ресурсов данных, требований к свежести данных и требований к запросу.

Рассмотрите эту альтернативу, если рабочая нагрузка соответствует любому из следующих условий:

• Вы уже управляете знаниями о основе в существующей транзакционной или операционной базе данных.

• Требуется поддержка нескольких моделей или пакета SDK, недоступная в поиске ИИ

• Необходимо интегрировать с специализированными источниками данных или устаревшими системами

Поиск векторов часто используется для создания дополненного вектора, но не всегда требуется. Дополнительные сведения см. в разделе "Выбор службы Azure" для поиска векторов. Перед выбором хранилища данных оцените шаблоны доступа к данным, задержку и масштабируемость рабочей нагрузки.

Предопределенный агент или динамически созданный агент

Текущий подход: Эталонная реализация использует статически определенный агент, который развертывается как микрослужба в Azure AI Foundry. Логика агента и источники данных настраиваются при развертывании и остаются неизменными до следующего выпуска приложения. Этот подход хорошо работает, когда поведение агента и источники данных стабильны и управляются с помощью процессов DevOps.

Альтернативный подход: Вы можете динамически создавать или изменять агенты во время выполнения с помощью пакета SDK агента ИИ Azure. Такой подход позволяет приложению создавать экземпляры агентов по запросу, настраивать системные запросы или перенастраивать подключения на основе контекста пользователя или бизнес-логики.

Рассмотрите возможность динамических агентов, если для рабочей нагрузки требуются следующие возможности:

• Персонализированное поведение агента или источники данных для каждого пользователя или сеанса

• Частые или программные изменения конфигурации агента

• Эфемерная поддержка агента для конкретных контекстов для расширенных возможностей пользователей

Динамическое управление агентами повышает гибкость, но также представляет бремя управления жизненным циклом. Убедитесь, что у вас есть соответствующие элементы управления для создания, изменения и очистки агента.

Выберите подход агента, который соответствует требованиям к пользовательскому интерфейсу рабочей нагрузки.

Соображения

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Примените эту архитектуру и рабочие нагрузки ИИ в руководстве по проектированию Azure на этапе разработки рабочей нагрузки.

Надежность

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. Контрольный список проверки конструкции на надежность.

Базовая архитектура веб-приложения службы приложений посвящена зональной избыточности для ключевых региональных служб. Зоны доступности физически отделяются в пределах региона, обеспечивающие избыточность при развертывании двух или более экземпляров между ними. Если время простоя одной зоны возникает, другие в регионе могут оставаться не затронутыми. Архитектура также распределяет экземпляры и конфигурации служб Azure между зонами доступности. Дополнительные сведения см. в разделе "Базовые высокодоступные веб-приложения с высоким уровнем доступности".

В этом разделе описывается надежность компонентов, которые не рассматриваются в базовой архитектуре службы приложений, в частности Azure AI Foundry и ai Search.

Избыточность зоны на уровне оркестрации

Корпоративные развертывания обычно требуют зональной избыточности, чтобы свести к минимуму риск сбоя службы от сбоев на уровне зоны. В Azure зональная избыточность означает использование ресурсов, поддерживающих зоны доступности и развертывание по крайней мере трех экземпляров, или включение избыточности на уровне платформы, где прямой элемент управления экземплярами недоступен.

В этой архитектуре Azure AI Foundry размещается возможность службы агента Foundry. Надежность агента зависит от доступности зависимостей службы агента Foundry, которые являются Azure Cosmos DB, storage и AI Search. Служба агента Foundry управляет данными в этих службах, но настраивает их надежность в подписке.

Чтобы обеспечить зональную избыточность для уровня оркестрации, выполните следующие рекомендации:

• Включите избыточность зоны в учетной записи Azure Cosmos DB для NoSQL . Эта конфигурация обеспечивает синхронную репликацию данных в нескольких зонах, что снижает риск потери данных или простоя из-за сбоя в одной зоне.

  Кроме того, рассмотрите возможность глобального распределения для устранения региональных сбоев в Azure Cosmos DB.

• Используйте избыточное между зонами хранилище (ZRS) для учетной записи хранения. Для повышения устойчивости используйте геоизбыточное хранилище (GZRS), которое объединяет зональную и региональную избыточность.

• Настройте экземпляр поиска ИИ по крайней мере с тремя репликами. Эта конфигурация гарантирует, что служба распределяет реплики между уникальными зонами в вашем регионе.

Если агент интегрируется с другими зависимостями, зависящими от рабочей нагрузки, например подключения к пользовательским инструментам или внешним хранилищам знаний, убедитесь, что эти зависимости соответствуют вашим требованиям к доступности и избыточности. Любая однозонная или нередредантная зависимость может подорвать общую надежность слоя оркестрации.

Портал AI Foundry, api-интерфейсы плоскости данных и служба агента Foundry не предоставляют прямые элементы управления избыточностью зоны.

Надежность в размещении модели Azure AI Foundry

Azure AI Foundry предоставляет модели как услуга (MaaS) с несколькими вариантами развертывания. Эти варианты в основном поддерживают управление квотами и пропускной способностью, а не традиционные высокий уровень доступности в регионе. Развертывания стандартной модели работают в одном регионе и не поддерживают зоны доступности. Чтобы обеспечить доступность нескольких центров обработки данных, необходимо использовать развертывание глобальной или зоны данных.

В сценариях корпоративного чата разверните подготовленную зону данных и стандартную модель зоны данных . Настройте переключение для обработки избыточного трафика или сбоев. Если рабочая нагрузка не требует низкой задержки или строгого географического расположения и обработки данных, используйте глобальные развертывания для максимальной устойчивости.

Azure AI Foundry не поддерживает расширенные механизмы балансировки нагрузки или отработки отказа, такие как маршрутизация с циклическим перебором или прерывание цепи для развертываний моделей. Если требуется детализированный контроль избыточности и отработки отказа в регионе, разместите логику доступа к модели за пределами управляемой службы. Например, можно создать пользовательский шлюз с помощью службы "Управление API Azure". Этот подход позволяет реализовать пользовательские стратегии маршрутизации, проверки работоспособности и отработки отказа. Но она также увеличивает операционную сложность и переключает ответственность за надежность этого компонента в вашу команду.

Вы также можете предоставлять внешние модели шлюза в виде пользовательских средств на основе API или хранилищ знаний для агента. Дополнительные сведения см. в статье "Использование шлюза перед несколькими развертываниями Или экземплярами Azure OpenAI".

Надежность в поиске ИИ для корпоративных знаний

Разверните поиск ИИ с помощью ценовой категории "Стандартный" или выше в регионе, поддерживающем зоны доступности. Настройте по крайней мере три реплики, чтобы служба распределяла экземпляры между отдельными зонами доступности. Эта конфигурация обеспечивает устойчивость к сбоям уровня зоны и поддерживает высокий уровень доступности для операций поиска.

Чтобы определить оптимальное количество реплик и секций для рабочей нагрузки, используйте следующие методы:

• Мониторинг поиска ИИ с помощью встроенных метрик и журналов. Отслеживание задержки запросов, регулирования и использования ресурсов.

• Используйте метрики мониторинга и журналы и анализ производительности, чтобы определить соответствующее количество реплик. Этот подход помогает избежать регулирования из большого объема запросов, недостаточно секций или ограничений индекса.

• Обеспечение надежности индексирования путем предотвращения нарушений периодического индексирования или индексирования ошибок. Рассмотрите возможность индексирования в автономный индекс и переключение из динамического индекса на перестроенный индекс после проверки целостности данных.

Надежность в брандмауэре Azure

Брандмауэр Azure является критической точкой управления исходящим трафиком в этой архитектуре, но представляет собой одну точку сбоя для всего исходящего трафика. Чтобы устранить этот риск, разверните брандмауэр Azure во всех зонах доступности в вашем регионе. Эта конфигурация помогает поддерживать исходящее подключение, если зона становится недоступной.

Если для рабочей нагрузки требуется большой объем одновременных исходящих подключений, настройте брандмауэр Azure с несколькими общедоступными IP-адресами. Этот подход распределяет подключения преобразования сетевых адресов источника (SNAT) между несколькими префиксами IP-адресов, что снижает риск исчерпания портов SNAT. Исчерпание SNAT может привести к периодическим или полной потере исходящего подключения для агентов и других компонентов рабочей нагрузки, что может привести к простою функции или снижению производительности.

Мониторинг использования портов SNAT и работоспособности брандмауэра. Если вы наблюдаете сбои подключения или проблемы пропускной способности, просмотрите метрики и журналы брандмауэра для выявления и устранения нехватки SNAT или других узких мест.

Изоляция зависимостей службы агента Foundry от аналогичных компонентов рабочей нагрузки

Чтобы максимально повысить надежность и свести к минимуму радиус сбоя, строго изолируйте зависимости службы агента Foundry от других компонентов рабочей нагрузки, использующих те же службы Azure. В частности, не совместно использовать службы поиска ИИ, Azure Cosmos DB или хранилища между службой агентов и другими компонентами приложения. Вместо этого подготовьте выделенные экземпляры для необходимых зависимостей службы агента.

Это разделение обеспечивает два ключевых преимущества:

• Он содержит сбои или снижение производительности до одного сегмента рабочей нагрузки, что предотвращает каскадное влияние на несвязанные функции приложения.

• Он позволяет применять целевые операционные процессы, такие как резервное копирование, восстановление и отработка отказа. Эти процессы настраиваются на конкретные требования к доступности и восстановлению потока рабочей нагрузки, использующего эти ресурсы.

Например, если приложение пользовательского интерфейса чата должно хранить состояние транзакций в Azure Cosmos DB, подготовьте отдельную учетную запись и базу данных Azure Cosmos DB для этой цели, а не повторное использование учетной записи или базы данных, которым управляет служба агента Foundry. Даже если затраты или операционная простота мотивируют общий доступ к ресурсам, риск возникновения события надежности, затрагивающего несвязанные функции рабочей нагрузки, перевешивает потенциальную экономию в большинстве корпоративных сценариев.

Это важно

Если данные, зависящие от рабочей нагрузки, зависят от зависимостей агента по затратам или рабочим причинам, никогда не взаимодействуют напрямую с данными, управляемыми системой, такими как коллекции, контейнеры или индексы, создаваемые службой агентов Foundry. Эти внутренние сведения о реализации не являются незадокументированы и подлежат изменению без уведомления. Прямой доступ может нарушить службу агента или привести к потере данных. Всегда используйте API плоскости данных службы агента Foundry для обработки данных и обрабатывать базовые данные как непрозрачные и отслеживаемые.

Структура с несколькими регионами

Эта архитектура использует зоны доступности для обеспечения высокой доступности в одном регионе Azure. Это не решение для нескольких регионов. В нем отсутствуют следующие критически важные элементы, необходимые для региональной устойчивости и аварийного восстановления (аварийного восстановления).

• Глобальный трафик и маршрутизация трафика
• Управление DNS для отработки отказа
• Стратегии репликации или изоляции данных в разных регионах
• Обозначение "активный-активный", "активный-пассивный" или "активный-холодный"
• Региональные процессы отработки отказа и восстановления для удовлетворения целей времени восстановления (ОСРВ) и точек восстановления (RPOS)
• Рассмотрение доступности регионов для разработчиков, включая портал Azure AI Foundry и API плоскости данных

Если для рабочей нагрузки требуется непрерывность бизнес-процессов при возникновении регионального сбоя, необходимо разработать и реализовать дополнительные компоненты и операционные процессы за пределами этой архитектуры. В частности, необходимо устранить балансировку нагрузки и отработку отказа на каждом уровне архитектуры, включая следующие области:

• Приземление данных (хранилища знаний)
• Размещение и вывод конечных точек модели
• Уровень оркестрации или агента
• Трафик пользовательского интерфейса и точки входа DNS

Кроме того, необходимо обеспечить работоспособность, мониторинг и контроль безопасности содержимого в разных регионах.

Эта базовая архитектура не имеет возможностей с несколькими регионами, поэтому региональные сбои могут привести к потере службы в рабочей нагрузке.

Восстановление после катастрофы

Архитектура чата содержит компоненты с отслеживанием состояния, поэтому планирование аварийного восстановления является важным. Обычно для этих рабочих нагрузок требуется хранилище памяти для активных или приостановленных сеансов чата. Они также требуют хранения дополнительных данных, таких как документы или изображения, добавленные в потоки чата. Уровень оркестрации агента также может поддерживать состояние, относящееся к потокам беседы. В этой архитектуре служба агента Foundry использует Azure Cosmos DB, хранилище и поиск искусственного интеллекта для сохранения рабочего и транзакционного состояния. Жизненный цикл и связь этого состояния между компонентами определяет стратегию аварийного восстановления и операции восстановления.

Для службы агента Foundry убедитесь, что все зависимости можно восстановить до согласованной точки во времени. Этот подход помогает поддерживать целостность транзакций в трех внешних зависимостях.

Следующие рекомендации по устранению аварийного восстановления для каждой службы:

• Azure Cosmos DB: Включите непрерывную резервную копию для enterprise_memory базы данных. Эта настройка обеспечивает восстановление на определенный момент времени (PITR) с семидневным RPO, включающее определения агентов и потоки чата. Регулярно тестируйте процесс восстановления, чтобы убедиться, что он соответствует RTO и что восстановленные данные остаются доступными для службы агента. Всегда восстанавливайте одну и ту же учетную запись и базу данных.

• Поиск ИИ: В поиске ИИ отсутствуют встроенные возможности восстановления и не поддерживаются прямые манипуляции с индексами. Если происходит потеря или повреждение данных, обратитесь в службу поддержки Майкрософт за помощью по восстановлению индекса. Это ограничение может значительно повлиять на RTO. Если пользовательский интерфейс чата не поддерживает отправку файлов и у вас нет агентов, использующих статические файлы в качестве знаний, возможно, вам не потребуется план аварийного восстановления для поиска ИИ.

  Сохраняйте отдельный, регулярно обновляемый источник истины для ваших корпоративных знаний об основах. Эта практика гарантирует, что при необходимости можно перестроить индексы.

• Хранение: Если у вас есть геоизбыточная учетная запись хранения, используйте отработку отказа, управляемой клиентом , для контейнеров BLOB-объектов, используемых службой агента Foundry. Эта настройка позволяет инициировать отработку отказа во время регионального сбоя. Если вы используете только хранилище, избыточное между зонами, обратитесь в службу поддержки Майкрософт для восстановления данных. Этот процесс может расширить RTO. Как и при поиске ИИ, если пользовательский интерфейс чата не поддерживает отправку файлов и у вас нет агентов, использующих статические файлы в качестве знаний, возможно, вам не потребуется план аварийного восстановления для контейнеров BLOB-объектов.

• Согласованность транзакций: Если хранилище состояний в рабочей нагрузке ссылается на идентификаторы агента ИИ Azure, например идентификаторы потоков или идентификаторы агентов, координируйте восстановление во всех соответствующих хранилищах данных. Восстановление только подмножества зависимостей может привести к потерянным или несогласованным данным. Проектирование процессов аварийного восстановления для обеспечения целостности ссылок между рабочей нагрузкой и состоянием службы агента.

• Определения и конфигурация агента: Определите агенты как код. Хранение определений агентов, подключений, системных запросов и параметров в системе управления версиями. Эта практика позволяет повторно развертывать агенты из известной хорошей конфигурации, если вы потеряете уровень оркестрации. Избегайте внесения незаслеченных изменений в конфигурацию агента с помощью портала ИИ Foundry или API плоскости данных. Этот подход гарантирует, что развернутые агенты остаются воспроизводимыми.

Прежде чем перейти в рабочую среду, создайте модуль Runbook восстановления, который устраняет сбои как в состоянии, принадлежаемом приложению, так и в состоянии агента.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

Эта архитектура расширяет основу безопасности, созданную в базовой эталонной архитектуре чата Azure AI Foundry. Основное различие заключается в добавлении периметра безопасности сети вместе с периметром удостоверений из базовой архитектуры. С точки зрения сети шлюз приложений является единственным ресурсом, предоставляемым интернетом. Это делает приложение пользовательского интерфейса чата доступным для пользователей. С точки зрения идентификации пользовательский интерфейс чата должен проходить проверку подлинности и авторизовать запросы. Используйте управляемые удостоверения, если это возможно для проверки подлинности приложений в службах Azure.

В этом разделе описываются рекомендации по настройке сети и безопасности для смены ключей и модели Azure OpenAI.

Управление удостоверениями и доступом

Эта архитектура в основном использует управляемые удостоверения, назначаемые системой, для проверки подлинности между службами. Вы также можете использовать управляемые удостоверения, назначаемые пользователем. В любом случае примените следующие принципы:

• Изоляция удостоверений по ресурсам и функциям. Подготовка отдельных управляемых удостоверений для следующих компонентов:

  • Учетная запись Azure AI Foundry
  • Каждый проект Azure AI Foundry
  • Веб-приложение
  • Любой пользовательский код оркестратора или интеграции

• Назначьте удостоверение ресурсу Azure только в том случае, если этот ресурс должен пройти проверку подлинности в качестве клиента в другой службе Azure.

• Используйте типы удостоверений, подходящие для назначения. По возможности используйте удостоверения рабочей нагрузки для приложений и автоматизации и используйте удостоверения агента для агентов ИИ.

Доступ к сотруднику портала Azure AI Foundry

При подключении сотрудников к проектам Azure AI Foundry назначьте минимальные разрешения, необходимые для их роли. Используйте группы идентификаторов Microsoft Entra и управление доступом на основе ролей (RBAC), чтобы обеспечить разделение обязанностей. Например, различает разработчиков агентов от специалистов по обработке и анализу данных, которые обрабатывают задачи точной настройки. Однако помните об ограничениях и рисках.

Портал Azure AI Foundry выполняет множество действий с помощью удостоверения службы, а не удостоверения сотрудника. В результате сотрудники, имеющие ограниченные роли RBAC, могут иметь видимость конфиденциальных данных, таких как потоки чата, определения агентов и конфигурация. Этот дизайн портала AI Foundry может случайно обойти требуемые ограничения доступа и предоставить больше информации, чем это было запланировано.

Чтобы снизить риск несанкционированного доступа, ограничьте использование портала в рабочих средах сотрудникам, у которых есть четкая операционная потребность. Для большинства сотрудников отключите или заблокируйте доступ к порталу Azure AI Foundry в рабочей среде. Вместо этого используйте конвейеры автоматического развертывания и инфраструктуру в качестве кода (IaC) для управления конфигурацией агента и проекта.

Рассматривайте создание новых проектов в учетной записи Azure AI Foundry как привилегированное действие. Проекты, созданные на портале, не наследуют установленные элементы управления безопасностью сети, такие как частные конечные точки или группы безопасности сети (NSG). И новые агенты в этих проектах обходят предполагаемый периметр безопасности. Принудительное создание проекта исключительно с помощью управляемых, проверяемых процессов IaC.

Назначения ролей и подключений проекта Azure AI Foundry

Чтобы использовать службу агента Foundry в стандартном режиме, проект должен иметь административные разрешения на зависимости службы агента Foundry. В частности, управляемое удостоверение проекта должно иметь повышенные назначения ролей в учетной записи хранения, поиске ИИ и учетной записи Azure Cosmos DB. Эти разрешения обеспечивают почти полный доступ к этим ресурсам, включая возможность чтения, записи, изменения или удаления данных. Чтобы обеспечить минимальный доступ к привилегиям, изолируйте ресурсы рабочей нагрузки от зависимостей службы агентов Foundry.

Все агенты в одном проекте AI Foundry используют одно управляемое удостоверение. Если рабочая нагрузка использует несколько агентов, которым требуется доступ к разным наборам ресурсов, принцип наименьшей привилегии требует создания отдельного проекта Azure AI Foundry для каждого отдельного шаблона доступа агента. Это разделение позволяет назначать только минимальные необходимые разрешения управляемому удостоверению каждого проекта, что снижает риск чрезмерного или непреднамеренного доступа.

При установке подключений к внешним ресурсам из Azure AI Foundry используйте проверку подлинности на основе идентификаторов Microsoft Entra, если она доступна. Этот подход устраняет необходимость в обслуживании предварительно общих секретов. Область каждого подключения, чтобы использовать его можно только для собственного проекта. Если для нескольких проектов требуется доступ к одному ресурсу, создайте отдельное соединение в каждом проекте, а не совместное использование одного подключения между проектами. Эта практика применяет строгие границы доступа и предотвращает наследование будущих проектов, которым они не требуются.

Избегайте создания подключений на уровне учетной записи Azure AI Foundry. Эти подключения применяются ко всем текущим и будущим проектам в учетной записи. Они могут непреднамеренно предоставлять широкий доступ к ресурсам, нарушать принципы наименьших привилегий и увеличивать риск несанкционированного доступа к данным. Предпочитайте только подключения на уровне проекта.

Нетворкинг

Помимо доступа на основе удостоверений, эта архитектура требует конфиденциальности сети.

Сетевая конструкция включает следующие меры защиты:

• Единая безопасная точка входа для всего трафика пользовательского интерфейса чата, который сводит к минимуму область атаки.

• Отфильтрованный сетевой трафик и исходящий трафик с помощью сочетания групп безопасности сети, брандмауэра веб-приложения, определяемых пользователем маршрутов (UDR) и правил брандмауэра Azure

• Сквозное шифрование данных при передаче с помощью TLS

• Конфиденциальность сети с помощью приватного канала для всех подключений к службе PaaS Azure

• Логическая сегментация и изоляция сетевых ресурсов с выделенными подсетями для каждой основной группы компонентов для поддержки детальных политик безопасности

Сетевые потоки

Схема напоминает базовую архитектуру сквозного чата. Она включает архитектуру Azure OpenAI и три нумерованных сетевых потока. Поток входящего трафика и поток из службы приложений в службы PaaS Azure копируются из базовой веб-архитектуры службы приложений. Поток службы агента Foundry отображает стрелку из частной конечной точки Azure AI Foundry в частной виртуальной сети, которая указывает на службу агента Foundry. Вторая нумерованная стрелка в потоке службы агента Foundry отображает вызовы из виртуального интерфейса агента ИИ Azure в частной сети, которая проходит через частные конечные точки. Третья нумерованная стрелка показывает стрелку из виртуального интерфейса в поле брандмауэра Azure, которое указывает, что все вызовы в интернет-поток через этот брандмауэр.

Базовая архитектура веб-приложения службы приложений описывает поток входящего трафика от пользователя к пользовательскому интерфейсу чата и поток из службы приложений в службы PaaS Azure. В этом разделе основное внимание уделяется взаимодействию с агентом.

Когда пользовательский интерфейс чата взаимодействует с агентом, развернутым в Azure AI Foundry, возникают следующие сетевые потоки:

1. Пользовательский интерфейс чата, размещенный в службе приложений, инициирует HTTPS-запросы через частную конечную точку API плоскости данных Azure AI Foundry.

2. Когда агент обращается к службам Azure PaaS, таким как зависимости служб, пользовательские хранилища знаний или пользовательские средства, он отправляет HTTPS-запросы из делегированной подсети в частные конечные точки этих служб.

3. Когда агент обращается к ресурсам за пределами виртуальной сети, включая ИНТЕРФЕЙСы API на основе Интернета или внешние службы, он вынужден направлять эти HTTPS-запросы из делегированной подсети через брандмауэр Azure.

Частные конечные точки служат критически важным элементом управления безопасностью в этой архитектуре, дополняя безопасность на основе удостоверений.

Вход в Azure AI Foundry

Эта архитектура отключает общедоступный доступ к плоскости данных Azure AI Foundry, разрешая трафик только через приватный канал для Azure AI Foundry. Вы можете получить доступ к большей части портала Azure AI Foundry с помощью веб-сайта портала, но для всех функциональных возможностей уровня проекта требуется доступ к сети. На портале используются API плоскости данных учетной записи AI Foundry, доступные только через частные конечные точки. В результате разработчики и специалисты по обработке и анализу данных должны получить доступ к порталу через окно перехода, одноранговую виртуальную сеть или VPN-подключение ExpressRoute или VPN типа "сеть — сеть".

Все программные взаимодействия с плоскостем данных агента, например из веб-приложения или из внешнего кода оркестрации при вызове вывода модели, также должны использовать эти частные конечные точки. Частные конечные точки определяются на уровне учетной записи, а не на уровне проекта. Поэтому все проекты в учетной записи используют одинаковый набор конечных точек. Вы не можете сегментирование сетевого доступа на уровне проекта, а все проекты совместно используют одинаковый сетевой доступ.

Чтобы поддерживать эту конфигурацию, настройте DNS для следующих конечных точек API Azure AI Foundry FQDN:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

На следующей схеме показано, как разработчик ИИ подключается через Бастион Azure к прямоугольнику перехода виртуальной машины. В этом поле перехода автор может получить доступ к проекту на портале Azure AI Foundry через частную конечную точку в той же сети.

Стрелка от автора агента до Бастиона Azure, в поле прыжка, в частную конечную точку Azure AI Foundry (портал), а затем в проект Azure AI Foundry, содержащий службу агента Foundry. В проекте Azure AI Foundry стрелка указывает на виртуальный интерфейс в подсети интеграции агента ИИ Azure. Конечные стрелки из виртуального интерфейса в три частные конечные точки службы агента Foundry. Эти зависимости : поиск ИИ, Azure Cosmos DB и хранилище.

Управление трафиком из подсети агента Azure AI Foundry

Эта архитектура направляет весь исходящий сетевой трафик из возможности службы агента Foundry через делегированную подсеть в виртуальной сети. Эта подсеть служит единственной точкой исходящего трафика как для необходимых трех зависимостей службы агента, так и для всех внешних источников знаний или подключений инструментов, которые использует агент. Эта конструкция помогает сократить попытки кражи данных из логики оркестрации.

Принудив этот путь исходящего трафика, вы получаете полный контроль над исходящим трафиком. Вы можете применить детализированные правила NSG, настраиваемую маршрутизацию и управление DNS ко всему трафику агента, который покидает службу.

Служба агента использует конфигурацию DNS виртуальной сети для разрешения записей частной конечной точки и необходимых внешних полных доменных имен. Эта настройка гарантирует, что запросы агента создают журналы DNS, которые поддерживают аудит и устранение неполадок.

Группа безопасности сети, подключенная к подсети агента, блокирует весь входящий трафик, так как входящий трафик не должен возникать. Правила NSG исходящего трафика разрешают доступ только к подсетям частной конечной точки в виртуальной сети и через TCP-порт 443 для трафика, привязанного к Интернету. Группа безопасности сети отрицает весь остальной трафик.

Чтобы дополнительно ограничить интернет-трафик, эта архитектура применяет UDR к подсети, которая направляет весь трафик HTTPS через брандмауэр Azure. Брандмауэр управляет полными доменными именами, которые агент может получить через подключения HTTPS. Например, если агенту необходимо получить доступ только к общедоступным API-интерфейсам Bing , настройте брандмауэр Azure, чтобы разрешить трафик api.bing.microsoft.com через порт 443 из этой подсети. Все остальные исходящие назначения запрещены.

Сегментация виртуальной сети и безопасность

Эта архитектура сегментирует виртуальную сеть, назначив каждой основной группе компонентов собственную подсеть. Каждая подсеть имеет выделенную группу безопасности сети, которая ограничивает входящий и исходящий трафик только тем, что требует компонент.

В следующей таблице приведены сведения о конфигурации группы безопасности сети и брандмауэра для каждой подсети.

Имя использования или подсети	Входящий трафик (NSG)	Исходящий трафик (NSG)	UDR для брандмауэра	Правила исходящего трафика брандмауэра
Частные конечные точки snet-privateEndpoints	Виртуальная сеть	Нет разрешенного трафика	Да	Нет разрешенного трафика
Шлюз приложений snet-appGateway	IP-адреса источника пользовательского интерфейса чата, такие как общедоступный Интернет и необходимые источники для службы	Подсеть частной конечной точки и необходимые элементы для службы	нет	-
Служба приложений snet-appServicePlan	Нет разрешенного трафика	Частные конечные точки и Azure Monitor	Да	To Azure Monitor
Служба агента Foundry snet-agentsEgress	Нет разрешенного трафика	Частные конечные точки и Интернет	Да	Только общедоступные полные доменные имена, которые позволяют агентам использовать
Виртуальные машины с полем перехода snet-jumpBoxes	Подсеть Бастиона Azure	Частные конечные точки и Интернет	Да	По мере необходимости виртуальной машины
Агенты сборки snet-buildAgents	Подсеть Бастиона Azure	Частные конечные точки и Интернет	Да	По мере необходимости виртуальной машины
Бастион Azure AzureBastionSubnet	Ознакомьтесь с доступом nSG и Бастионом Azure	Ознакомьтесь с доступом nSG и Бастионом Azure	нет	-
Брандмауэр Azure AzureFirewallSubnet AzureFirewallManagementSubnet	Нет группы безопасности сети	Нет группы безопасности сети	нет	-

Эта конструкция явно запрещает весь остальной трафик через правила NSG или по умолчанию в брандмауэре Azure.

При реализации сегментации сети и безопасности в этой архитектуре следуйте приведенным ниже рекомендациям.

• Разверните план защиты от атак DDoS Azure на общедоступном IP-адресе шлюза приложений, чтобы устранить проблемы с объемными атаками.

• Подключите группу безопасности сети к каждой подсети, поддерживающей ее. Применяйте самые строгие правила, не нарушая необходимые функциональные возможности.

• Примените принудительное туннелирование ко всем поддерживаемым подсетям, чтобы брандмауэр исходящего трафика может проверить весь исходящий трафик. Используйте принудительное туннелирование даже в подсетях, где вы не ожидаете исходящий трафик. Этот метод добавляет глубинную меру защиты, которая защищает от преднамеренного или случайного неправильного использования подсети.

Управление с помощью политики

Чтобы соответствовать базовым параметрам безопасности рабочей нагрузки, используйте политику Azure и политики сети, чтобы убедиться, что все ресурсы рабочей нагрузки соответствуют вашим требованиям. Автоматизация платформы с помощью политики снижает риск смещения конфигурации безопасности и помогает сократить действия проверки вручную.

Рекомендуется реализовать следующие типы политик безопасности для укрепления архитектуры:

• Отключите ключи или другие локальные методы проверки подлинности в службах, таких как службы ИИ Azure и Key Vault.

• Требуется явная настройка правил доступа к сети, частных конечных точек и групп безопасности сети.

• Требуется шифрование, например ключи, управляемые клиентом.

• Ограничить создание ресурсов, например ограничение регионов или типов ресурсов.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

Эта оценка цен Azure предоставляет пример ценообразования для этой архитектуры. В этом примере содержатся только компоненты в этой архитектуре, поэтому настройте его в соответствии с вашим использованием. Наиболее дорогими компонентами в сценарии являются Azure Cosmos DB, поиск ИИ и защита от атак DDoS. Другие важные затраты включают вычисление пользовательского интерфейса чата и шлюз приложений. Оптимизируйте эти ресурсы, чтобы сократить затраты.

Служба агента Foundry

При использовании стандартного развертывания необходимо подготовить зависимости службы и управлять ими в собственной подписке Azure.

В следующих рекомендациях объясняется, как оптимизировать затраты на эти необходимые службы:

• Служба агента Foundry управляет выделением единицы запроса (ЕЗ) в Azure Cosmos DB. Чтобы сократить долгосрочные затраты, приобретите зарезервированную емкость для Azure Cosmos DB. Выравнивать резервирования с ожидаемым сроком использования и объемом. Помните, что зарезервированная емкость требует предварительных обязательств и не имеет гибкости, если шаблоны использования рабочей нагрузки изменяются значительно.

• Если сценарий чата не требует отправки файлов, исключите эту функцию в приложении. В этом случае примените следующие изменения конфигурации:

  • Используйте уровень локально избыточного хранилища (LRS) для учетной записи хранения.
  • Настройте поиск ИИ с одной репликой вместо рекомендуемых трех реплик.

• Регулярно удалять неиспользуемые агенты и связанные с ними потоки с помощью пакета SDK или REST API. Устаревшие агенты и потоки продолжают использовать хранилище и могут увеличивать затраты на Azure Cosmos DB, хранилище и поиск ИИ.

• Отключите функции для зависимых ресурсов, для которых не требуется рабочая нагрузка, например следующие функции:

  • Семантический рангер в поиске ИИ
  • Возможности записи шлюза и нескольких регионов в Azure Cosmos DB

• Чтобы избежать расходов на пропускную способность между регионами, разверните Azure Cosmos DB, хранилище и поиск ИИ в том же регионе Azure, что и служба агента Foundry.

• Избегайте совместного размещения данных, относящихся к рабочей нагрузке, в одних и том же ресурсах Azure Cosmos DB или поиска ИИ, которые использует служба агента Foundry. В некоторых случаях эти ресурсы можно совместно использовать для уменьшения неиспользуемой емкости в единицах ЕЗ или единиц поиска, что снижает затраты. Только рассмотрите возможность совместного использования ресурсов после тщательной оценки риска для надежности, безопасности и компромиссов производительности.

Знания и инструменты агента

Служба агента Foundry выполняет логику агента недетерминированным образом. Он может вызывать любое подключенное хранилище знаний, инструмент или другой агент для каждого запроса, даже если этот ресурс не относится к запросу пользователя. Это может привести к ненужным вызовам внешних API или источников данных, увеличению затрат для каждой транзакции и внедрению непредсказуемых шаблонов использования, которые усложняют прогнозирование бюджета.

Чтобы управлять затратами и поддерживать прогнозируемость поведения, выполните следующие стратегии:

• Подключите только хранилища знаний, инструменты или агенты, которые, скорее всего, будут использоваться с большинством вызовов агента. Избегайте подключения ресурсов, которые редко требуются или что влечет за собой высокие затраты на каждый вызов, если они не являются важными.

• Тщательно проектируйте и уточняйте системный запрос, чтобы указать агенту свести к минимуму ненужные или избыточные внешние вызовы. Системный запрос должен помочь агенту использовать только наиболее релевантные подключения для каждого запроса.

• Используйте данные телеметрии Azure AI Foundry для отслеживания того, какие внешние API, хранилища знаний или инструменты, к которым обращается агент, как часто он обращается к ним, а также связанные с ними затраты. Регулярно просматривайте эти данные телеметрии, чтобы определить непредвиденные шаблоны использования или пики затрат и настроить системный запрос по мере необходимости.

• Помните, что недетерминированное вызов может затруднить прогнозирование затрат, особенно при интеграции с лимитными API. Если требуется прогнозируемая стоимость, рассмотрите возможность самостоятельного размещения оркестратора с помощью детерминированного кода.

Модели Azure OpenAI

Развертывания моделей в Azure AI Foundry используют подход MaaS. Затраты зависят в первую очередь от использования или предварительно подготовленного выделения.

Чтобы управлять затратами на модель потребления в этой архитектуре, используйте сочетание следующих подходов:

• Управление клиентами. Клиентские запросы управляют большинством затрат в модели потребления, поэтому управление поведением агента имеет решающее значение.

  Чтобы уменьшить ненужное использование, выполните следующие действия:

  • Утвердить всех потребителей модели. Не предоставляйте модели таким образом, чтобы разрешить неограниченный доступ.

  • Применение ограничений на ограничение маркеров, таких как max_tokens логика агента и max_completions их использование. Этот элемент управления доступен только в локальной оркестрации. Служба агента Foundry не поддерживает эту функцию.

  • Оптимизируйте входные данные запроса и длину ответа. Более длинные запросы потребляют больше маркеров, что увеличивает затраты. Запросы, которые не имеют достаточной эффективности модели контекста. Создайте краткие запросы, которые предоставляют достаточно контекста, чтобы позволить модели создавать полезный ответ. Убедитесь, что вы оптимизируете ограничение длины ответа.

    Этот уровень управления доступен только в локальной оркестрации. Служба агента Foundry не предоставляет достаточно конфигурации для поддержки этой функции.

• Выберите подходящую модель для агента. Выберите наименьшую затратную модель, которая соответствует требованиям агента. Избегайте использования моделей с более высокими затратами, если они не являются важными. Например, эталонная реализация использует GPT-4o вместо более дорогой модели и достигает достаточных результатов.

• Мониторинг использования и управление ими. Используйте данные телеметрии управления затратами Майкрософт для отслеживания использования маркеров, задания бюджетов и создания оповещений об аномалиях. Регулярно просматривайте шаблоны использования и корректируйте квоты или клиентский доступ по мере необходимости. Дополнительные сведения см. в статье "Планирование затрат и управление затратами на Azure AI Foundry".

• Используйте правильный тип развертывания. Используйте цены на оплату по мере использования для непредсказуемых рабочих нагрузок и переключитесь на подготовленную пропускную способность при стабильном и предсказуемом использовании. Объединяйте оба варианта при создании надежной базовой базы.

• Ограничение использования игровой площадки. Чтобы предотвратить незапланированные производственные затраты, ограничьте использование детской площадки Azure AI Foundry только для предварительной подготовки сред.

• Тщательно запланируйте настройку и создание образов. Эти функции имеют разные модели выставления счетов. Плата взимается в час или за пакет. Планирование использования для выравнивания интервалов выставления счетов и предотвращения отходов.

Ресурсы безопасности сети

Для этой архитектуры требуется брандмауэр Azure в качестве точки управления исходящим трафиком. Чтобы оптимизировать затраты, используйте базовый уровень брандмауэра Azure, если остальные компоненты рабочей нагрузки не требуют дополнительных функций. Более высокие уровни добавляют затраты, поэтому используйте их только в том случае, если вам нужны их возможности.

Если ваша организация использует целевые зоны Azure, рассмотрите возможность использования общего брандмауэра и распределенных ресурсов типа "отказ в обслуживании" (DDoS), чтобы отложить или сократить затраты. Рабочие нагрузки, имеющие аналогичные требования к безопасности и производительности, могут воспользоваться общими ресурсами. Убедитесь, что общие ресурсы не представляют рисков безопасности или эксплуатации. Эта архитектура, развернутая в целевой зоне Azure, использует общие ресурсы.

Операционное превосходство

Операционное превосходство охватывает процессы, которые развертывают приложение и продолжают работать в рабочей среде. Для получения дополнительной информации см. Контрольный список для оценки проектирования с точки зрения операционной эффективности.

Следующие рекомендации по операционному превосходству не включают интерфейсные элементы приложения, которые остаются такими же, как и базовая архитектура высокоизбыточного веб-приложения с высоким уровнем доступности.

При планировании экспериментов, тестирования и рабочих сред создайте отдельные и изолированные ресурсы ИИ Foundry, включая зависимости.

Вычисление агента

Корпорация Майкрософт полностью управляет бессерверной вычислительной платформой для REST API агента ИИ Azure и логикой реализации оркестрации. Локальная оркестрация обеспечивает более широкий контроль над характеристиками среды выполнения и емкостью, но необходимо напрямую управлять операциями дня 2 для этой платформы. Оцените ограничения и обязанности вашего подхода, чтобы понять, какие операции день-2 необходимо реализовать для поддержки уровня оркестрации.

В обоих подходах необходимо управлять хранилищем состояний, например журналом чата и конфигурацией агента для устойчивости, резервного копирования и восстановления.

Контроль

Как и в базовой архитектуре, данные диагностики из всех служб настроены для отправки в рабочую область Log Analytics рабочей нагрузки. Все службы, кроме службы приложений, фиксируют все журналы. В рабочей среде может не потребоваться записать все журналы. Например, для приложения пользовательского интерфейса чата может потребоваться AppServiceHTTPLogsтолько , AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogsи AppServiceAuthenticationLogs. Настройте потоки журналов в соответствии с вашими потребностями в работе.

Оцените пользовательские оповещения, такие как пользовательские оповещения в базовых оповещениях Azure Monitor, для ресурсов в этой архитектуре. Рассмотрим следующие оповещения:

• Оповещения поиска ИИ
• Оповещения служб ИИ
• Оповещения веб-приложений

Отслеживайте использование маркеров в развертываниях модели. В этой архитектуре Azure AI Foundry отслеживает использование маркеров через интеграцию с Application Insights.

Все виртуальные машины агента сборки находятся в высоко привилегированном расположении, которое предоставляет эти виртуальные машины сетевой линии видимости для плоскости данных всех компонентов в архитектуре. Убедитесь, что эти виртуальные машины выдают достаточно журналов, чтобы понять, когда они используются, кто использует их и какие действия они выполняют.

Управление версиями агента и жизненный цикл

Обрабатывать каждый агент как независимо развертываемый модуль в рабочей нагрузке чата, если только вы не разрабатываете приложение для динамического создания и удаления агентов во время выполнения. Эти агенты имеют требования к управлению жизненным циклом, аналогичные другим микрослужбам в рабочей нагрузке.

Чтобы предотвратить нарушения работы служб, убедитесь в безопасном и управляемом развертывании агента, реализуя следующие подходы:

• Определите агенты как код. Всегда хранить определения агента, подключения, системные запросы и параметры конфигурации в системе управления версиями. Эта практика обеспечивает трассировку и воспроизводимость. Избегайте неустраченных изменений на портале Azure AI Foundry.

• Автоматизация развертывания агента. Используйте конвейеры непрерывной интеграции и непрерывного развертывания рабочей нагрузки (CI/CD). Используйте пакет SDK агента ИИ Azure для создания, тестирования и развертывания изменений агента из агентов сборки, подключенных к сети.

  Предпочитайте конвейеры агента, которые можно развертывать независимо для небольших добавочных изменений. Но убедитесь, что конвейеры обеспечивают достаточную гибкость для их развертывания вместе с кодом приложения, если требуется координированные обновления. Чтобы обеспечить поддержку этого метода, слабо сочетайте код пользовательского интерфейса чата и агенты чата, чтобы изменения одного компонента не требовали одновременных изменений в другой.

• Тестирование перед рабочей средой. Проверьте поведение агента, запросы и подключения в предварительных средах. Используйте сочетание автоматических и ручных тестов для перехвата регрессий, проблем безопасности и непредвиденных изменений в поведении агента.

  Агенты, определенные в службе агентов Foundry, ведут себя недетерминированно, поэтому необходимо определить, как измерять и поддерживать требуемый уровень качества. Создайте и запустите набор тестов, который проверяет идеальные ответы на реалистичные вопросы и сценарии пользователя.

• Версия и отслеживание агентов. Назначьте каждому агенту четкие идентификаторы версий. Сохраняйте записи о том, какие версии агента активны, а также их зависимости, такие как модели, источники данных и средства. Предпочитайте развертывание новых версий агента вместе с существующими, чтобы обеспечить постепенное развертывание, откат и контролируемый перенос пользователей или сеансов.

• Планирование восстановления размещения. Azure AI Foundry не обеспечивает встроенную поддержку сине-зеленого или канарского развертывания агентов. Если вам нужны эти шаблоны развертывания, реализуйте уровень маршрутизации, например шлюз API или пользовательский маршрутизатор, перед API агента. Этот уровень маршрутизации позволяет постепенно перемещать трафик между версиями агента, отслеживать влияние и выполнять полную переключение при готовности.

• Удаление агента координат. При удалении агентов обратитесь к процессу с требованиями к управлению состоянием приложения и взаимодействию с пользователем. Правильно обработайте активные сеансы чата. В зависимости от функциональных требований рабочей нагрузки можно перенести сеансы, закрепить пользователей на старую версию агента или требовать от пользователей запуска новых сеансов.

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки конструкции для эффективности производительности.

В этом разделе рассматривается эффективность поиска ИИ, развертывания моделей и Azure AI Foundry.

Эффективность производительности в поиске ИИ

В службе агентов Foundry вы не управляете конкретными запросами, отправленными в индексы, так как агенты без кода. Чтобы оптимизировать производительность, сосредоточьтесь на том, что можно контролировать в индексе. Узнайте, как агент обычно запрашивает индекс и применяет рекомендации для анализа и оптимизации производительности в поиске ИИ.

Если только настройка сервера индекса не устраняет все узкие места, рассмотрите следующие варианты:

• Замените прямое подключение к поиску ИИ подключением к API, которому вы владеете. Этот API может реализовать код, оптимизированный для шаблонов извлечения агента.

• Измените уровень оркестрации, чтобы использовать локальную альтернативу , чтобы можно было определить и оптимизировать запросы в собственном коде оркестратора.

Эффективность производительности в развертываниях моделей

• Определите, требуется ли приложению подготовленная пропускная способность или можно ли использовать общую модель (потребление). Подготовленная пропускная способность обеспечивает зарезервированную емкость и прогнозируемую задержку, которая важна для рабочих нагрузок с строгими целями уровня обслуживания. Модель потребления обеспечивает лучшие усилия и может страдать от шумных последствий соседей.

• Отслеживайте использование, управляемое подготовкой , чтобы избежать чрезмерной подготовки или недооказания.

• Выберите модель беседы, которая соответствует вашим требованиям к задержке вывода.

• Разверните модели в том же регионе данных, что и агенты, чтобы свести к минимуму задержку в сети.

Производительность агента ИИ Azure

Агенты ИИ Azure выполняются в серверной части бессерверных вычислений, которая не поддерживает настраиваемую настройку производительности. Однако вы по-прежнему можете повысить производительность с помощью разработки агента:

• Свести к минимуму количество хранилищ знаний и инструментов, подключенных к агенту чата. Каждое дополнительное подключение потенциально увеличивает общую среду выполнения для вызова агента, так как агент может вызывать все настроенные ресурсы для каждого запроса.

• Используйте Azure Monitor и Application Insights для отслеживания времени вызова агента, задержки и задержки хранилища знаний и частоты ошибок. Регулярно просматривайте эти данные телеметрии для выявления медленных знаний или подключений к инструментам.

• Система конструктора предлагает агенту эффективно использовать подключения. Например, указать агенту запрашивать внешние хранилища знаний только при необходимости или избегать избыточных вызовов средства.

• Отслеживайте ограничения или квоты служб, которые могут повлиять на производительность во время пикового использования. Следите за индикаторами регулирования, такими как ответы HTTP 429 или 503, даже если бессерверные вычисления масштабируется автоматически.

Развертывание этого сценария

Чтобы развернуть и запустить эту эталонную реализацию, следуйте руководству по развертыванию в базовой реализации службы агента Foundry.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Роб Багби | Разработчик основного содержимого — шаблоны и практики Azure
• Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure

Другие участники:

• Рауф Алиуат | Старший инженер по программному обеспечению
• Фредди Айала | Архитектор облачных решений
• Prabal Deb | Главный инженер программного обеспечения
• Ritesh Modi | Главный инженер программного обеспечения
• Райан Пфальц | Старший технический руководитель программы

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Следующий шаг

• Базовая архитектура чата Azure AI Foundry в целевой зоне Azure

Связанные ресурсы

• Перспектива Azure Well-Architected Framework для рабочих нагрузок ИИ в Azure
• Azure OpenAI
• Модели Azure OpenAI
• Фильтрование содержимого