Модели LLM и Azure OpenAI в шаблоне дополнения ответа результатами поиска (Retrieval Augmented Generation, RAG) (предварительная версия)

Важно

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

В этой статье представлен наглядный пример использования больших языковых моделей (LLM) и Azure OpenAI в контексте шаблона дополнения ответа результатами поиска (Retrieval Augmented Generation, RAG). В частности, в нем исследуется, как можно применять эти технологии в суверенных целевых зонах, и рассматриваются важные ограждения.

Сценарий

Распространенным сценарием является использование моделей LLM для участия в беседах с использованием ваших собственных данных через Шаблон дополнения ответа результатами поиска (Retrieval Augmented Generation, RAG). Этот шаблон позволяет вам использовать логические способности моделей LLM, чтобы генерировать ответы на основе ваших конкретных данных без тонкой настройки модели. Это облегчает плавную интеграцию моделей LLM в существующие бизнес-процессы или решения.

Cloud for Sovereignty — эталонная архитектура искусственного интеллекта и LLM

Microsoft Cloud for Sovereignty предоставляет эталонную архитектуру, которая иллюстрирует типичную архитектуру дополнения ответа результатами поиска (Retrieval Augmented Generation, RAG) в суверенной целевой зоне (SLZ). В нем представлен обзор распространенных и рекомендуемых вариантов технологий реализации, терминологии, технологических принципов, общих сред конфигурации и состава применимых сервисов.

Скачайте PDF-файл для печати этой схемы эталонной архитектуры.

Ключевые этапы/поток данных следующие:

Целевые зоны приложений

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

Источники данных и конвейеры преобразования

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

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

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

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

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

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

Компоненты, связанные с ИИ и моделями LLM

Компоненты, связанные с ИИ и LLM, должны размещаться как рабочие нагрузки в отдельной подписке в группе управления Corp или Online (в зависимости от того, требуется или нет публичный доступ). Это следующие компоненты:

Служба Azure OpenAI инкапсулирует операции моделей LLM, таких как GPT, и внедрения текста, такие как Ada, делая их доступными через стандартные API-интерфейсы, предоставляемые OpenAI приложению оркестратора.

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

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

Приложение оркестратора ведет историю отправленных запросов и полученных ответов, чтобы обеспечить обоснование службы Azure OpenAI на основе предыдущих взаимодействий. Например, в чате, таком как ChatGPT или Bing Chat, приложение-оркестратор сохраняет или кэширует историю разговорного сеанса, чтобы она учитывалась в потоке разговора серверной частью службы LLM.

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

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

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

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

Компоненты инфраструктуры

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

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

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

• Цепи ExpressRoute или VPN-шлюзы для подключения к корпоративной сети компании, агентства или организации.

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

• Компоненты защиты от DDoS для защиты рабочих нагрузок от распределенных атак типа «отказ в обслуживании».

• Частные DNS-зоны для всех типов служб, используемых во всем виртуальном центре обработки данных, реализованном с помощью целевых зон.

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

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

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

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

Соответствие принципам Well-Architected Framework и Cloud Adoption Framework

В предыдущих разделах были кратко упомянуты некоторые аспекты согласования, связанные с Well-Architected Framework (WAF) и Cloud Adoption Framework (CAF). Важно отметить, что все архитектурные решения должны полностью соответствовать основным принципам CAF и целевых зон Azure, облачной аналитики CAF и WAF, в том числе перспективе WAF на Azure OpenAI.

Аспекты проектирования инфраструктуры, связанные с ограждениями

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

Основные соображения, на которые следует обратить внимание в отношении приложений LLM на основе RAG из этих стандартов, следующие:

Местонахождение данных и выбор региона

Суверенитет накладывает строгие требования к местонахождению данных и, следовательно, может ограничить развертывания определенными регионами Azure в SLZ. Выбор региона для рабочих нагрузок LLM ограничен наличием необходимых служб:

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

• Во-вторых, при рассмотрении Azure OpenAI важна доступность соответствующих моделей LLM, поскольку не все модели одинаково доступны во всех регионах.

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

Сеть

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

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

Шифрование хранящихся и передаваемых данных

Большинство служб в Azure поддерживают как шифрование при передаче, так и при хранении. Включите шифрование при хранении и передаче во всех службах, если они доступны. Включите последнюю версию TLS, в настоящее время TLS 1.2, для шифрования при передаче.

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

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

Ротация ключей в Key Vault

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

Группы безопасности сети и приложений

В суверенной, безопасной среде обязательно использование групп безопасности сети (NSG) и групп безопасности приложений (ASG). Отсутствие групп безопасности приводит к несоответствию развертываний. Обычные порты SSL полезны для большинства служб, от которых зависят рабочие нагрузки LLM/RAG, поскольку они основаны на HTTPS. Для приема данных из источников в поисковые и векторные базы данных требуются определенные порты. Общедоступные API-интерфейсы не допускаются в целевых зонах Корп. Все службы должны быть доступны только в виртуальной сети, что требует использования конечных точек службы приватного канала или виртуальной сети для PaaS-служб.

Больше мер безопасности и суверенитета

Наиболее важные и очевидные барьеры, описанные в предыдущих разделах для проектирования вашей инфраструктуры и приложений, можно повторно использовать даже за пределами суверенных целевых зон или целевых зон Azure. Другие глобальные политики привязаны к централизованно управляемым ресурсам, таким как рабочие области Log Analytics или развертывания Microsoft Sentinel в целевых зонах корпоративного масштаба. В процессе проектирования инфраструктуры и приложений крайне важно учитывать эти централизованно управляемые ресурсы. Пренебрежение этим может привести к дополнительным усилиям и затратам времени после развертывания. К счастью, функция соответствия политике Azure может выявить несоответствующие ресурсы после развертывания. Более того, как суверенные, так и целевые зоны Azure предоставляют политики DeployIfNotExists для многочисленных ресурсов, что еще больше упрощает процесс.

Вот несколько примеров таких ограждений:

• Активация входа в централизованно управляемые рабочие области Log Analytics.

• Интеграция с Центром безопасности Azure или Microsoft Defender для облака.

• Интеграция с пакетами управления информационной безопасностью и событиями безопасности (SIEM), такими как Microsoft Sentinel.

• Интеграция с централизованно управляемыми брандмауэрами, брандмауэрами веб-приложений или защитой от DDoS.

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

Развертывание следующего сценария

Чтобы воспользоваться преимуществами больших языковых моделей (LLM) и Azure OpenAI на основе шаблона дополнения ответа результатами поиска (Retrieval Augmented Generation, RAG) в пределах суверенных целевых зон, вам следует сначала развернуть и настроить суверенную целевую зону (SLZ) и применить инициативы базовой политики суверенитета. Подробный обзор SLZ и всех ее возможностей см. в документации по суверенной целевой зоне на GitHub.

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

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

Ускоритель информационного помощника

Информационный помощник — это ускоритель решений, который обеспечивает организациям отправную точку для создания собственных возможностей генеративного искусственного интеллекта для расширения возможностей Azure OpenAI для пользователей организации и данных их частных доменов. Его можно развернуть в Cloud for Sovereignty и согласовать с эталонной архитектурой и рекомендациями, представленными в этой статье. Мы рекомендуем развернуть акселератор в рамках целевой зоны Корпорация для внутренних рабочих нагрузок и следовать инструкциям по обеспечению безопасности развертываний для целевой зоны Интернет для публичного доступа.

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

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