Персоны команды для рабочих нагрузок ИИ

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

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

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

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

Что такое персоны?

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

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

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

• Определение пробелов в ресурсах. Определение пробелов помогает решить, следует ли набирать или обучать ресурсы или изменять решение. Если ваша группа рабочей нагрузки не имеет отдельных лиц, которые соответствуют необходимой персоне, может потребоваться изменить архитектуру, изменить процесс или подключить новый персонал. Например, если отсутствует старший человек по обработке и анализу данных, вы можете перепроектировать архитектуру, чтобы использовать больше программного обеспечения общего назначения как услуги (SaaS) ИИ или включить решения, отличные от Майкрософт.
• Расширенные навыки. Сопоставление лиц с конкретными архитектурными компонентами также упрощает образовательные возможности, такие как сеансы и онлайн-курсы для улучшения навыков.
• Обеспечение соответствующих уровней доступа. Необходимо использовать «персоны» для определения потребностей в безопасности и доступе путем сопоставления персонажей с процессами, архитектурами и службами. Это сопоставление помогает обеспечить соответствующие уровни доступа.
• Упрощение планирования и коммуникации проектов. При планировании проектов персоны помогают определить ключевые взаимодействия, чтобы облегчить организацию встреч по синхронизации и общему планированию. Как правило, пользователи интегрируются в иерархию отслеживания пользовательских историй, функций и требований для упрощения управления проектами.

Агентные персоны

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

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

• Многооблачное и межсистемное определение личности. Настройте систему управления persona, которая работает на разных облачных платформах, службах SaaS и серверах протокола MCP, а не только в одной облачной среде. Это означает определение лиц агента с правильными разрешениями на доступ, динамическими методами проверки подлинности, такими как агент — агент (A2A), и четкими правилами взаимодействия между различными платформами.

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

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

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

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

Определение лиц

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

Ниже приведен пример шаблона базовых показателей.

Инструменты

Вы можете использовать таблицу для упорядочивания и визуализации информации для каждого человека. Одним из преимуществ этого метода является создание и связывание с другими таблицами, которые предоставляют более конкретные сведения. Например, можно связать компоненты архитектуры с другой таблицей, в которой для каждой службы и среды указывается управление доступом на основе удостоверений (Dev, Stage, Production).

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

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

В некоторых случаях можно использовать сочетание инструментов. Например, каждый компонент архитектуры в карточке persona может открыть файл Markdown, содержащий таблицу, которая сопоставляет безопасность и управление доступом на основе ролей для каждой службы и среды. Пример см. в статье акселератор MLOps: Identity RBAC.

Примеры персон

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

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

Специалисты по разработке

Персоны операций

Вариант использования: Персоны для процессов ИИ

Эти основные процессы используются в рабочих нагрузках ИИ:

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

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

На изображении показан рабочий процесс для DataOps, MLOps и GenAIOps в рабочей среде. Потоки данных идут от приема к развертыванию модели и оценке. Рабочий процесс использует методики непрерывной интеграции и непрерывной доставки (CI/CD). К ключевым задачам относятся уточнение моделей данных, оценка пакетов, развертывание конечных точек, оценка моделей в режиме реального времени и тонкая настройка моделей. Примерные персонажи участвуют во всем рабочем процессе.

Вариант использования: Образы пользователей для проектирования архитектуры

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

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

На следующем рисунке показана лямбда-архитектура для современной аналитики в Azure.

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

Затем перейдите к средству оценки, чтобы оценить проект.