Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта статья дополняет рабочие процессы MLOps в Databricks , добавляя сведения, относящиеся к рабочим процессам LLMOps. Дополнительные сведения см. в "Большая книга MLOps".
Как изменяется рабочий процесс MLOps для LLM?
LLMs — это класс моделей обработки естественного языка (NLP), которые значительно превзошли своих предшественников в размерах и производительности в различных задачах, таких как открытый ответ на вопросы, сводка и выполнение инструкций.
Разработка и оценка LLM отличаются некоторыми важными способами от традиционных моделей машинного обучения. В этом разделе кратко описаны некоторые ключевые свойства LLM и последствия для MLOps.
| Ключевые свойства LLM | Последствия для MLOps |
|---|---|
LLM доступны во многих формах.
|
Процесс разработки: Проекты часто разрабатываются постепенно, начиная с существующих, сторонних или моделей с открытым исходным кодом и заканчивая пользовательскими точно настроенными моделями. |
| Многие LLM принимают общие запросы естественного языка и инструкции в качестве входных данных. Эти запросы могут содержать тщательно разработанные запросы, чтобы вызвать нужные ответы. |
Процесс разработки: проектирование текстовых шаблонов для запроса LLM часто является важной частью разработки новых конвейеров LLM. Упаковка артефактов машинного обучения: Многие LLM-пайплайны используют существующие LLM или конечные точки обслуживания LLM. Логика машинного обучения, разработанная для этих конвейеров, может сосредоточиться на шаблонах запросов, агентах или цепочках вместо самой модели. Артефакты машинного обучения, упакованные и продвигаемые в рабочую среду, могут представлять собой именно эти конвейеры, а не модели. |
| Многим моделям LLM можно дать подсказки с примерами, контекстом или другими сведениями, чтобы помочь ответить на вопрос. | Инфраструктура обслуживания: При дополнении запросов LLM контекстом можно использовать дополнительные инструменты, такие как векторные индексы для поиска соответствующего контекста. |
| Сторонние API предоставляют собственные и открытые модели. | управление API: Использование централизованного управления API обеспечивает возможность легко переключаться между поставщиками API. |
| LLM — это очень большие модели глубокого обучения, часто начиная от гигабайтов до сотен гигабайтов. |
Инфраструктура обеспечения: LLMs могут требовать GPUs для работы моделей в режиме реального времени, а также быстрое хранилище для моделей, которые должны быть загружены динамически. Компромиссы по затратам и производительности: поскольку для более крупных моделей требуется больше вычислений и более дорогих для обслуживания, могут потребоваться методы сокращения размера модели и вычислений. |
| LLM трудно оценить с помощью традиционных метрик машинного обучения, так как часто нет единого "правильного" ответа. | Человеческая обратная связь: человеческая обратная связь важна для оценки и тестирования LLM. Вы должны включить отзывы пользователей непосредственно в процесс MLOps, в том числе для тестирования, мониторинга и последующей тонкой настройки. |
Общие сходства между MLOps и LLMOps
Многие аспекты процессов MLOps не изменяются для LLM. Например, следующие рекомендации также применяются к LLM:
- Используйте отдельные среды для разработки, тестирования и рабочей.
- Использовать Git для управления версиями.
- Управление разработкой моделей с помощью MLflow и использование моделей в каталоге Unity для управления жизненным циклом модели.
- Храните данные в архитектуре lakehouse, используя таблицы Delta.
- Существующая инфраструктура CI/CD не должна требовать никаких изменений.
- Модульная структура MLOps остается той же, с такими же потоками данных для создания признаков, обучения моделей, инференции моделей и т. д.
Эталонные схемы архитектуры
В этом разделе используются два приложения на основе LLM, чтобы проиллюстрировать некоторые корректировки эталонной архитектуры традиционных MLOps. На схемах показана рабочая архитектура для 1) приложения с дополненной генерацией данных (RAG) с использованием стороннего API, и 2) приложения RAG с использованием самостоятельно размещенной точно настроенной модели. На обеих схемах показана необязательная векторная база данных. Этот элемент можно заменить, напрямую запрашивая LLM через конечную точку обслуживания модели.
RAG со сторонним API LLM
На схеме показана рабочая архитектура для приложения RAG, подключающегося к стороннему API LLM с помощью Databricks External Models.
RAG с моделью с тонкой настройкой и открытым исходным кодом
На схеме показана производственная архитектура для приложения RAG, которое настраивает модель с открытым исходным кодом.
Изменения LLMOps в производственной архитектуре MLOps
В этом разделе рассматриваются основные изменения эталонной архитектуры MLOps для приложений LLMOps.
Центр моделей
Приложения LLM часто используют существующие предварительно обученные модели, выбранные из внутреннего или внешнего концентратора моделей. Модель можно использовать как есть или точно настроить.
Databricks включает в себя выбор высококачественных предварительно обученных базовых моделей в каталоге Unity и в Databricks Marketplace. Эти предварительно обученные модели можно использовать для доступа к возможностям искусственного интеллекта, что позволяет сэкономить время и затраты на создание собственных пользовательских моделей. Дополнительные сведения см. в статье Get generative AI and LLM models from Unity Catalog and Marketplace.
Векторный индекс
Некоторые приложения LLM используют векторные индексы для быстрого поиска сходства, например для предоставления контекста или знаний о домене в запросах LLM. Databricks предоставляет встроенную функцию поиска векторов, которая позволяет использовать любую таблицу Delta в каталоге Unity в качестве векторного индекса. Индекс векторного поиска автоматически синхронизируется с таблицей Delta. Дополнительные сведения см. в разделе "Векторный поиск".
Вы можете создать артефакт модели, который объединяет логику извлечения информации из векторного индекса и предоставляет полученные данные в качестве контекста для LLM. Затем вы можете сохранить модель, используя тип модели MLflow LangChain или PyFunc.
Точная настройка LLM
Так как модели LLM являются дорогостоящими и трудоемкими для создания с нуля, приложения LLM часто настраивают существующую модель для повышения производительности в определенном сценарии. В эталонной архитектуре точная настройка и развертывание модели представлены как отдельные задания Lakeflow. Проверка точно настроенной модели перед развертыванием часто является ручным процессом.
Databricks предоставляет базовую настройку модели, которая позволяет использовать собственные данные для настройки существующего LLM для оптимизации производительности для конкретного приложения. Дополнительные сведения см. в разделе «Тонкая настройка модели Foundation».
Обслуживание модели
В RAG с помощью сценария сторонних API важное изменение архитектуры заключается в том, что конвейер LLM выполняет внешние вызовы API, от конечной точки обслуживания модели до внутренних или сторонних API LLM. Это повышает сложность, потенциальную задержку и дополнительное управление учетными данными.
Databricks предоставляет Mosaic AI Model Serving, объединенный интерфейс для развертывания, управления и запросов моделей ИИ. Для получения подробной информации см. Обслуживание мозаичной модели ИИ.
Человеческая обратная связь в мониторинге и оценке
Циклы обратной связи человека важны в большинстве приложений LLM. Обратная связь от людей должна управляться, как и другие данные, и в идеале интегрироваться в мониторинг на основе потоковой передачи, близкой к режиму реального времени.
Приложение для обзора фреймворка Mosaic AI Agent помогает вам собирать отзывы от рецензентов. Для получения подробной информации см. раздел «Использование приложения для проверки людьми генеративных приложений ИИ» (MLflow 2).