Проектирование приложений для рабочих нагрузок ИИ в Azure

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

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

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

• Источники каталога: Изучите репозитории, такие как Хаб моделей Hugging Face, TensorFlow Hub и каталог моделей портала Microsoft Foundry для поиска предварительно обученных моделей. Эти платформы предоставляют обширный каталог моделей для различных задач.

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

• Ключевые компоненты: Ознакомьтесь с архитектурой модели, данными обучения и производительностью, чтобы определить, настроена ли она для вашей задачи или домена.

Рекомендации по выбору платформы размещения см. в разделе "Рекомендации" для платформы размещения и вывода модели.

Архитектура уровня приложений

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

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

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

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

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

• Уровень инструментов: Бизнес-API, внешние службы и возможности действий, которые может вызывать уровень аналитики. Этот уровень должен использовать стандартизированные интерфейсы и применять собственные политики безопасности.

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

Рекомендации

В следующей таблице приведены рекомендации, приведенные в этой статье.

Различие между выводом и интеллектуальными приложениями

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

Приложения для выведения

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

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

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

Интеллектуальные приложения

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

Типичная архитектура: Клиент запрашивает агента или оркестратора агента. На основе дизайнерских возможностей или возможностей автономной работы этот уровень вызывает инструментальный уровень, например, серверы протокола Model Context Protocol (MCP) или пользовательские API. Агенту может потребоваться обратиться к основополагающим службам знаний, таким как индекс поиска, база данных или граф. Модели могут вызываться в нескольких точках во время этого процесса. Кэширование также может выполняться на нескольких уровнях для оптимизации процесса.

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

Основные рекомендации по проектированию приложений ИИ

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

Начните с определения бизнес-результатов

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

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

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

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

Нужно проектировать безопасность с первого дня

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

Проектируйте для наблюдаемости с самого начала

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

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

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

• Анализ взаимодействия с пользователем: Узнайте, как пользователи взаимодействуют с функциями ИИ для выявления возможностей улучшения.

Планирование абстракции и гибкости в будущем

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

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

• Стандартные протоколы: Предпочитайте открытые, документированные интерфейсы и форматы, такие как OpenAPI для инструментов, ONNX для переносимости модели и OpenTelemetry для телеметрии.

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

Внешние запросы и конфигурация

Трактуйте подсказки как конфигурацию, которая должна быть вынесена наружу согласно принципам проектирования Twelve-Factor App.

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

• Разделение ролей: Разрешить бизнес-аналитикам и экспертам по доменам настраивать запросы без изменений кода.

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

План прекращения использования модели

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

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

• Управление версиями: Реализуйте стратегии управления версиями, поддерживающие постепенную миграцию между версиями модели.

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

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

Контейнеризация компонентов

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

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

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

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

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

Реализация стратегий кэширования с несколькими слоями

Подход к кэшированию с несколькими слоями может помочь повысить производительность и сократить затраты в приложениях ИИ. Рассмотрите возможность реализации кэширования на нескольких уровнях стека приложений:

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

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

• Кэширование выходных данных модели: Кэшируйте выходные данные промежуточной модели, которые можно повторно использовать в запросах.

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

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

• Политики времени жизни (TTL): Задайте соответствующее время окончания срока действия на основе требований к свежести данных и чувствительности содержимого.

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

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

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

Оценка использования оркестрации и агентов в решениях для создания искусственного интеллекта

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

Когда следует использовать оркестрацию

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

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

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

• Критически важные для производительности пути: Рабочие процессы, в которых задержка и использование ресурсов должны жестко контролироваться.

• Простая координация: Простое делегирование задач, не требующее динамической рассудки.

Когда следует использовать совместную работу агента

Агент — это способ упаковки, извлечения и определения интеллектуального поведения в приложении. Агенты предоставляют функциональные возможности, связанные с контекстом, и могут работать с платформами оркестрации, такими как Semantic Kernel, Autogen или Microsoft Agent Framework.

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

• Многошаговое рассуждение: Задачи, требующие планирования и принятия решений в несколько этапов

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

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

• Управление контекстом: Приложения, которые должны поддерживать состояние беседы и контекст пользователя во время взаимодействия

Рекомендации по проектированию агента

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

Сохраняемость состояния агента

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

Гибридные подходы

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

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

• Шаблоны эскалации: Начните с детерминированной оркестрации и перейдите к основанному на агентах рассуждению, когда предопределенной логики недостаточно.

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

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

Реализация шлюзов искусственного интеллекта для применения политик

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

Основные возможности шлюза искусственного интеллекта

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

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

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

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

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

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

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

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

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

Сценарии с несколькими поставщиками

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

• Унифицированный интерфейс: Укажите одну область API, которая абстрагирует несколько внутренних поставщиков.

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

• Оптимизация затрат: Перенаправите запросы к наиболее эффективному поставщику на основе характеристик запросов.

Использование шаблонов проектирования приложений ИИ

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

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

• Архитектура микрослужб: Этот шаблон проектирования отделяет компоненты в независимых развернутых службах для повышения масштабируемости и удобства обслуживания. Она позволяет командам одновременно работать над различными частями приложения.

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

Шаблоны заземления и интеграции знаний

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

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

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

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

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

Более глубокое понимание разработки специально созданного векторного индекса, который поддерживает специфические данные по рабочей нагрузке для семантического извлечения, см. в разделе Проектирование и разработка решения с расширенным извлечением (RAG).

Шаблоны мультимодельной маршрутизации

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

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

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

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

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

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

Когда следует использовать шаблоны проектирования

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

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

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

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

Выбор правильных платформ, библиотек и протоколов

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

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

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

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

• Сообщество и поддержка: Рассмотрим зрелость и поддержку экосистемы платформы. Активные сообщества и комплексная документация снижают риски реализации.

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

Внедрение стандартных протоколов инструментов для улучшения управления и обеспечения гибкости:

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

• Используйте спецификации, имеющие широкую поддержку пакета SDK. Например, определите средства с помощью спецификаций OpenAPI для согласованной документации по интерфейсу и проверки.

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

Параметры протокола

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

Разработка стратегии безопасности для компонентов ИИ рабочей нагрузки

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

Основные принципы безопасности

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

• Стандартная проверка подлинности и авторизация: Используйте установленные поставщики удостоверений и системы управления доступом на основе ролей (RBAC).

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

• Следы аудита: Реализуйте подробное ведение журнала взаимодействия искусственного интеллекта для мониторинга соответствия требованиям и безопасности.

Меры безопасности, относящиеся к искусственному интеллекту

Устранение проблем безопасности, уникальных для приложений ИИ:

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

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

• Мониторинг поведения агента: Отслеживайте действия и решения агента для обнаружения необычных или потенциально опасных шаблонов поведения.

• Управление доступом модели: Реализуйте подробные разрешения для различных моделей и возможностей в системе ИИ.

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

Заземление с обрезкой безопасности

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

• Распространение удостоверений: Передайте утверждения группы Microsoft Entra или эквивалентную информацию об удостоверениях в вызовы средства знаний, чтобы службы приземления никогда не извлекли несанкционированные данные или носители.

• Отсечение на основе групп безопасности и списков контроля доступа (ACL): Реализуйте фильтрацию на основе групп безопасности и списков контроля доступа на уровне системы.

• Проверяемые отказы: Фиксация и аудит отказов в выполнении запросов, вызванных недостаточными разрешениями.

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

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

Рассмотрите нефункциональные требования

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

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

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

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

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

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

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

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