Архитектура данных для агентов ИИ

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

Схема горизонтального рабочего процесса с четырьмя связанными этапами: план для агентов (подэтапы — бизнес-план, технологический план, готовность организации и архитектура данных). Управление и защита агентов (подэтапы — ответственный ИИ, управление и безопасность, а также подготовка среды). Создание агентов (подэтапы — системы с одним и несколькими агентами, а также процесс создания агентов). Управление интеграцией агентов (подпроцессы — интеграция агентов и управление агентами). Рис. 1. Процесс внедрения агента ИИ Майкрософт.

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

Объединение платформы данных

Единая платформа данных предоставляет архитектуру, на которую полагаются агенты ИИ. Microsoft Fabric OneLake служит центральным озером данных, где домены данных создают управляемые продукты данных. Эти продукты данных становятся основными входными данными для ИИ в организации. Агенты ИИ используют эти продукты данных через Fabric IQ, Foundry IQ в Microsoft Foundry и Microsoft Copilot Studio. Эта модель потребления обеспечивает управление, сохраняет границы безопасности и гарантирует, что агенты работают с высококачественными входными данными. Эта архитектура устанавливает единый доверенный фундамент для аналитики и искусственного интеллекта. Полные рекомендации см. в разделе "Объединение платформы данных".

Диаграмма, демонстрирующая поток данных из источников, не связанных с Azure, в службы Microsoft. В основании внешние данные поступают и перемещаются вверх в несколько доменов данных, представляющих бизнес-организации. Каждый домен подключается к рабочим областям Microsoft Fabric OneLake для унифицированных бизнес-данных. Обработка происходит с использованием Fabric IQ и агентов данных Fabric, которые затем передаются агенты в Microsoft Foundry в Azure или Copilot Studio в экосистеме Microsoft. В верхней части агенты интегрируются с целевыми зонами Azure: целевые зоны платформы с группами управления и подписками, целевые зоны приложений, где размещены области Foundry, и целевые зоны управления данными, где расположена емкость Fabric. Azure Databricks расположен в целевой зоне данных для расширенной аналитики, обеспечивая получение аналитических сведений для команд. Рис. 2. Архитектура: унифицированная платформа данных для искусственного интеллекта и аналитики.

Подготовка данных Microsoft 365

После объединения платформы данных подготовьте данные Microsoft 365 для использования агентом. Агенты Microsoft 365 Copilot используют информацию, доступную через Microsoft Graph. Эти сведения содержат содержимое из SharePoint, OneDrive, Exchange и Teams. Агенты извлекают содержимое, обеспечивая соблюдение существующих разрешений, меток конфиденциальности и политик арендатора. Они не обходят элементы управления безопасностью Microsoft 365.

Агенты в Foundry (SharePoint) и Copilot Studio также могут подключаться к данным в приложениях Microsoft 365. Используйте руководство по внедрению Microsoft 365 для подготовки данных. Дополнительные сведения об архитектуре см. в статье об архитектуре Microsoft 365 Copilot.

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

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

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

Начните со встроенных параметров извлечения

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

План для агентивного извлечения

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

Планирование создания серверов MCP

Когда следует использовать MCP? Выберите MCP, когда агенты должны выполнять действия или получать доступ к данным в режиме реального времени. Например: "Сколько единиц SKU123 находится на складе прямо сейчас?" или "Создайте билет на инцидент." MCP предоставляет агентам стандартный способ вызова средств, размещенных на удалённых серверах, с удостоверением личности, политиками и элементами управления аудитом.

  1. Определите потенциальные системы. Системы, которым следует уделить приоритет, где динамические запросы или транзакции добавляют ценность: CRM для обновлений процесса продаж, ERP для инвентаризации и заказов, ITSM для заявок, телеметрия IoT для считывания данных с датчиков и внутренние API для специализированных процессов.

  2. Создание или подключение серверов MCP. Используйте доступные и встроенные серверы MCP в Foundry и Copilot Studio. Если они недоступны, необходимо создать их. Уточняйте тип взаимодействия, необходимый агенту ИИ. В некоторых системах требуется доступ только для чтения для запросов, а другие требуют возможности чтения и записи для создания или обновления записей. Это различие влияет на элементы управления безопасностью и требования к соответствию требованиям. Определите эти роли рано, чтобы избежать ненужных рисков и обеспечить соответствие системы управления потребностям в работе. См. "Подключение к серверам MCP" или "Сборка и регистрация сервера MCP".

  3. Обеспечьте безопасность и соответствие требованиям для MCP. Требовать проверку подлинности для каждого вызова инструмента. Foundry поддерживает доступ на основе ключей, удостоверение Microsoft Entra Agent, управляемое удостоверение проекта и сквозную передачу удостоверений OAuth. Он обеспечивает подробный аудит вызовов и потоков данных средства. Используйте RBAC как в проекте Foundry, так и в целевой службе, и предпочитайте передачу удостоверений, если права доступа на уровне пользователя должны сохраняться. См. сведения о поддержке проверки подлинности для средства MCP.

Решения по извлечению документов

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

  • Часто задаваемые вопросы о продукте: поиск с помощью индекса знаний
  • Отслеживание заказов: вызов API к системе управления заказами
  • Создание возвращаемой метки: вызов API к системе доставки

Эта документация обеспечивает прозрачность для заинтересованных лиц и разработчиков. Он также поддерживает аудиты и проверки соответствия, показывая, как данные передаются через экосистему агента. Если стратегии извлечения объединяют RAG и MCP, обратите внимание, какой подход применяется к каждому домену и почему. Например, RAG может обрабатывать статические документы политики, а MCP управляет запросами инвентаризации в режиме реального времени. Включите сведения об управлении в ту же запись. Укажите, какие источники данных сертифицированы, какие API требуют проверки подлинности и какие разрешения применяются. На этом шаге гарантируется, что получение соответствует политикам безопасности организации и нормативным требованиям.

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

Управление и защита агентов

  • Last updated on