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

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

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

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

Типы обновлений модели

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

Область изменения	Преимущества обновления модели	Пример
Обновление незначительной версии	Обеспечивает улучшенную производительность и улучшенные возможности, обычно не требуя значительных изменений в существующей реализации.	Переход с GPT-4o v2024-08-06 на GPT-4o v2024-11-20
Обновление промежуточной версии	Обеспечивает существенные улучшения производительности, новые возможности и повышенную надежность, сохраняя большую обратную совместимость и требуя только умеренной корректировки реализации.	Переход с GPT-3 на GPT-3.5
Обновление основной версии	Обеспечивает трансформационные улучшения в области анализа, возможностей, объёма контекста и производительности, которые обосновывают значительные изменения реализации и корректировку запросов.	Переход с GPT-3 на GPT-4
Обновление вариантов	Предоставляет специализированные оптимизации, такие как увеличение скорости обработки и снижение задержки, при сохранении основной архитектуры и обычно обеспечении обратной совместимости с базовой моделью	Переход с GPT-4 на GPT-4-Turbo
Обновление версий по поколениям	Обеспечивает значительные улучшения в рассуждении, мультимодальных возможностях и производительности, которые существенно расширяют полезность модели, при этом потенциально требуют полного переосмысления стратегий реализации.	Переход с GPT-4 на GPT-4o
Изменение общей модели	Предоставляет доступ к специализированным возможностям, разным соотношениям цены и производительности и потенциально лучшему соответствию конкретным вариантам использования.	Переход с GPT-4 на DeepSeek
Изменение специализированной модели	Обеспечивает оптимизацию, улучшенную производительность для конкретных задач и потенциально низкую стоимость по сравнению с использованием моделей общего назначения для специализированных приложений	Переход с GPT-4 на Prizedata
Изменение параметра развертывания	Обеспечивает более широкий контроль над инфраструктурой, параметрами настройки и потенциальной экономией затрат, позволяя специализированной оптимизации и расширенной конфиденциальности данных за счет повышенной ответственности по управлению	Переход от LLaMa-1, размещенной как управляемая конечная точка в Интернете в Azure AI Foundry, к самостоятельному размещению LLaMa-1 на виртуальной машине

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

• Производительность, например скорость и задержка

• Емкость, например пропускная способность, измеряемая в транзакциях в минуту

• Доступность квоты

• Рентабельность

• Региональная доступность

• Многомодальные возможности

• Обновленные знания об обучении

• Исправления ошибок

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

• Предотвращение сбоев в рабочих нагрузках из-за правил жизненного цикла хоста модели

Модель поведения выхода на пенсию

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

• Решения MaaS (модель как услуга) — это предварительно обученные модели, предоставляемые в виде API, которые обеспечивают масштабируемость и простоту интеграции. У них есть баланс между потенциально более высокими затратами и сниженным контролем над моделями. Примеры решений MaaS включают модели, развернутые в Azure OpenAI в модели Foundry и модели из каталога моделей, развернутых как бессерверные API.

• Решения MaaP (модель как платформа) — это модели, развернутые и управляемые в более крупной платформе, такие как модели из каталога моделей Azure, развернутые в управляемых вычислениях. Обычно это решение обеспечивает больший контроль над моделями, но требует больше управления, чем решения MaaS.

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

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

Предупреждение

Для служб MaaS, включая развернутые в Azure OpenAI модели и модели, развернутые с помощью бессерверной модели API, важно понимать, что существующие развертывания для устаревших моделей возвращают ошибки HTTP. Если вы не обновляете поддерживаемую модель, приложение больше не работает должным образом. Для устаревших моделей нельзя создавать новые развертывания для этих моделей, но существующие развертывания продолжают работать до тех пор, пока они не будут прекращены. Дополнительные сведения см. в статьях об устаревших версиях моделей бессерверных API и прекращении их использования, а также о прекращении использования моделей Azure OpenAI.

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

Широта изменений для обновлений модели

На схеме показано подключение, которое переходит от пользователя к интеллектуальному приложению, а затем к оркестратору. Три блока указывают на оркестратор с пунктирными линиями: Конфигурация, Запрос и Логика оркестрации. Оркестратор имеет твердые линии, указывающие на три различных модели ИИ: model-x-v1, model-x-v1.1 и model-y-v1. Оркестратор также имеет стрелку, которая указывает на блок с надписью API или агент. Поле API или агента имеет сплошную линию, указывающую на поле с меткой "база данных знаний." Конвейер с четырьмя шагами указывает на базу данных знаний с пунктирной линией. Четыре этапа: документные фрагменты, обогащение фрагментов, встраивание фрагментов и сохранение фрагментов. Нумерованные круги обозначают несколько частей диаграммы. Первый круг находится рядом с моделями. Второй круг находится рядом с настройками. Третий круг рядом с подсказкой. Четвертый круг находится рядом с логикой оркестрации. Пятый круг находится рядом с пунктирной линией от трубопровода к базе данных знаний. Шестой круг ниже моделей.

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

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

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

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

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

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

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

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

   Например, если вы обновите модель до GPT-4, чтобы использовать вызов функций, вам необходимо изменить логику управления. Старая модель вернула результат, который можно вернуть вызывающему. При вызове функции вызов модели возвращает функцию, которую должна вызывать логика оркестрации. В Azure обычно реализуют логику оркестрации в службе агента Azure AI Foundry или с помощью решений на основе кода, таких как семантическое ядро или LangChain, размещённых в Azure.

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

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

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

Разработка с учетом изменений

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

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

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

Автоматизированные конвейеры

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

• MLOps: Следуйте инструкциям Azure MLOps , чтобы создать конвейеры для точной настройки модели, если это применимо.

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

• DataOps: Реализуйте проводки DataOps для тестирования и оценки изменений основополагающих данных RAG.

По следующим причинам следует реализовать конвейеры:

• Чтобы помочь вам в итеративной разработке и экспериментации (внутренний цикл)
• Выполнение безопасного развертывания и эксплуатации создаваемого решения искусственного интеллекта (внешний цикл)

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

Рекомендации по архитектуре

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

На схеме показан пользователь, подключающийся к интеллектуальному приложению, который подключается непосредственно к model-x-v1. Три элемента указывают на интеллектуальное приложение с дефисными строками, которые указывают на то, что приложение содержит эти элементы. Элементы — это логика конфигурации, запроса и оркестрации.

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

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

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

На схеме показан пользователь, подключающийся к интеллектуальному приложению, которое подключается к маршрутизатору. Маршрутизатор подключается к двум развертываниям в оркестраторе. Каждое развертывание подключается к шлюзу. Шлюз подключается к трем различным моделям: model-x-v1, model-x-v1.1 и model-y-v1. Оркестратор также подключается к API или агенту, который подключается к базе данных знаний. Стрелки указывают на маршрутизатор и шлюз с меткой, которая гласит: Общие слои абстракции в задачах генеративного ИИ.

В связи с многоуровневым косвенным взаимодействием архитектура должна быть разработана для поддержки отправки конкретных версий запросов в определенные модели или версии моделей. Например, в рабочей среде у вас может быть такой запрос, как запрос1, предназначенный для такой модели, как model1. При обновлении до model1.1 может потребоваться обновить запрос1 на запрос2. В этом примере архитектура должна всегда использовать запрос1 с моделью 1 и запрос2 с моделью 1.1.

Маршрутизатор

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

На схеме показан пользователь, подключающийся к интеллектуальному приложению, которое подключается к маршрутизатору (помечено 1). Маршрутизатор подключается к двум развертываниям в Orchestrator (помечено 2). Каждое развертывание содержит конфигурацию, запрос (помеченный 3) и логику оркестрации (помеченную 4). Каждое развертывание подключается к определенной модели (помеченной как 5). Внедрение 1 подключено к model-x-v1, а внедрение 2 подключено к model-x-v1.1. Оркестратор также подключается к API или агенту, который подключается к базе данных знаний.

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

1. Пользователь выдает запрос от интеллектуального приложения, и этот запрос отправляется маршрутизатору.

2. Маршрутизатор направляет трафик в Развертывание 1 или Развертывание 2 оркестратора в зависимости от его логики.

3. Каждое развертывание имеет собственную версию запроса и конфигурации.

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

5. Поскольку конкретная версия запроса развертывается вместе с оркестратором, настроенным с конкретной моделью и версией, правильный запрос отправляется в соответствующую версию модели.

Шлюз

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

На схеме показан пользователь, подключающийся к интеллектуальному приложению, которое подключается к маршрутизатору (помечено 1). Маршрутизатор подключается к двум развертываниям в Orchestrator (помечено 2). Каждое развертывание содержит конфигурацию, запрос (помеченный 3) и логику оркестрации (помеченную 4). Каждое развертывание подключается к шлюзу, пронумерованному 5. Каждая строка соединителя имеет метку, отображающую заголовок HTTP, который указывает модель и версию. Развертывание 1 указывает на model-x-v1, а Развертывание 2 указывает на model-x-v1.1. Шлюз подключается к model-x-v1 и model-x-v1.1 (помечено 6). Оркестратор подключается к API или агенту, который подключается к базе данных знаний.

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

1. Пользователь выдает запрос от интеллектуального приложения, и этот запрос отправляется маршрутизатору.

2. Маршрутизатор направляет трафик на Развертывание 1 или 2 в зависимости от своей логики.

3. Каждое развертывание имеет собственную версию подсказки.

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

5. Оркестратор вызывает шлюз. Запрос содержит заголовок HTTP, указывающий имя и версию используемой модели.

6. Шлюз использует заголовок HTTP для маршрутизации запроса в соответствующую модель и версию. Он также может применять конфигурацию, определенную на шлюзе.

Вынести конфигурацию наружу

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

Выбор вычислений

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

Пример объявления о завершении жизненного цикла — серия вычислительных устройств NC A100 версии 4. Если вы размещаете модели на этом оборудовании, необходимо перейти на другой поддерживаемый номер SKU, который не является конечным и имеет больше доступности. Этот переход также может потребовать одновременного изменения модели, если новый номер SKU не поддерживает текущую модель.

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

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

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

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

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

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

Сводка

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

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

Соавторы

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

• Ritesh Modi | Главный инженер программного обеспечения

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

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

• Отклонение и вывод из эксплуатации моделей Azure OpenAI

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

• Эталонная архитектура чата Ai Foundry
• MLOps
• GenAIOps для практиков MLOps