Запуск большой языковой модели в производственной среде больше не ограничивается обучением, тестированием и развертыванием модели, а также мониторингом информационных панелей. Современная система может связывать промпты, векторные базы данных и источники знаний, а затем генерировать открытые тексты, которые оцениваются по тону, безопасности и достоверности наряду с точностью. Поэтому Даниэль Брайант в материале, опубликованном в блоге CNCF, задаёт практический вопрос: кому следует принадлежать конвейеру искусственного интеллекта?
Автор считает, что ответ заключается не в создании для LLMOps отдельного королевства, а в её интеграции в хорошо организованную инженерную платформу, которая предоставляет необходимые возможности через те же интерфейсы, которыми команды разработки пользуются для остальных рабочих нагрузок.
Что такое LLMOps?
LLMOps обозначает совокупность практик, инструментов и рабочих процессов, необходимых для разработки, развертывания и управления большими языковыми моделями на протяжении их производственного жизненного цикла. Этот цикл включает управление данными, разработку промптов, дообучение, развертывание и предоставление сервиса инференса, мониторинг и оценку, а также безопасность и управление.
Согласно анализу, LLMOps — это не просто новое название MLOps. Большие языковые модели дороже в дообучении и обслуживании, а оценивать их результаты сложнее, чем сводить производительность к одному понятному показателю точности. Недостаточно, чтобы модель была точной: она также должна быть безопасной и заслуживающей доверия, а измерить эти свойства сложнее.
Кроме того, работа модели не заканчивается после первоначального развертывания. Модели могут отклоняться от прежнего поведения, расходы — расти, промпты — переставать работать привычным образом, а интеграции с системами управления взаимоотношениями с клиентами или внутренними базами знаний требуют постоянного сопровождения.
Жизненный цикл, пересекающийся с инженерией платформ
Жизненный цикл LLMOps простирается от подготовки данных и разработки промптов, при этом промпты рассматриваются как версионируемые артефакты, а не временные тексты, до дообучения открытых базовых моделей с использованием таких библиотек, как Hugging Face Transformers. Он также включает версионирование моделей и промптов и отслеживание их происхождения, предоставление инференса через конечные точки с поддержкой графических процессоров, а также мониторинг на основе обратной связи от людей для выявления отклонений и контроля затрат.
Каждая часть этого цикла требует инфраструктуры, средств контроля доступа и среды выполнения — областей, которые уже входят в сферу инженерии платформ. Однако автор различает природу этих двух направлений: инженерия платформ сосредоточена на инфраструктуре, тогда как MLOps — на моделях. Поэтому он считает, что полезный вопрос звучит не как «кому принадлежит конвейер?», а как «кому принадлежит каждый слой и существует ли структура, которая действительно координирует их между собой?».
Риск создания параллельного стека
В анализе ландшафт поставки программного обеспечения разделён между командами DevOps, которые могут быть перегружены запросами на развертывание, командами инженерии платформ, создающими стандартные маршруты самообслуживания, и командами MLOps, сформировавшими параллельные стеки, поскольку инструменты DevOps не были предназначены для управления версиями данных или мониторинга отклонений. С добавлением LLMOps может появиться третий независимый стек для промптов, векторных баз данных и конвейеров RAG — вдали от структуры, отвечающей за управление.
Автор связывает такую возможность с проблемой «скрытых операций с искусственным интеллектом». Одна из команд может создать собственный конвейер RAG, подключённый к векторной базе данных, которая не проходила проверку, и при этом ответственная структура не будет ясно понимать, что именно фактически работает. Согласно анализу, наибольшая операционная опасность заключается не только в чат-боте, создающем галлюцинации, а в распространении таких возможностей за пределы платформы и последующем их пребывании вне зоны видимости и контроля.
Автор не предлагает замедлять команды, чтобы предотвратить это, а призывает сделать платформу способной быстро удовлетворять запросы, встроив управление непосредственно в процесс использования. Отсутствие готового маршрута может подтолкнуть команды к созданию возможностей за пределами платформы, тогда как предоставление стандартного маршрута помогает вернуть эти возможности в управляемую среду.
LLMOps внутри слоёв платформы
Брайант опирается на представление о платформах из технического документа, выпущенного группой TAG App Delivery при CNCF. В нём среда разделена на три слоя: продукты сверху, платформы посередине как минимально необходимый интеграционный слой и поставщики возможностей снизу.
Согласно этому представлению, такие функции, как задачи дообучения, векторные базы данных, журналы промптов и конечные точки инференса, можно рассматривать как ещё одну возможность платформы. Как и другим возможностям, им требуются API, версионирование и чётко определённая ответственность. Автор указывает на инструменты экосистемы CNCF, способные поддержать эту модель: Backstage представляет стандартные маршруты на уровне продукта, Crossplane монтирует инфраструктуру на нижнем уровне, а такие фреймворки, как Kratix, KusionStack и KubeVela, работают в среднем слое, предоставляя конвейер LLM через интерфейс самообслуживания, аналогичный интерфейсу остальных сервисов.
Практические средства управления конвейером
В анализе предлагается, чтобы команды платформ внедрили ряд практических средств контроля:
- Управляемые API вместо неофициальных скриптов: задачи дообучения, развертывание промптов и конечные точки инференса следует запрашивать через тот же интерфейс самообслуживания, который используется для остальных потребностей разработчиков.
- Применение политик во время запроса: ограничения затрат, правила локализации данных и средства контроля доступа к моделям необходимо проверять до начала задачи, а не после получения счёта за облачные сервисы.
- Одобрение человеком, пропорциональное масштабу воздействия: не каждому промпту требуется предварительное утверждение, но модели, работающей с персональными данными клиентов или принимающей самостоятельные решения, оно может понадобиться.
- Понятный журнал аудита: журнал должен отвечать на такие вопросы, как что изменилось и почему, независимо от того, касалось ли изменение модели, промпта или данных, а также кто одобрил изменение или что именно было одобрено.
Автор приходит к выводу, что конвейер LLM — это ещё один автоматизированный потребитель возможностей платформы, которому нужны те же гарантии, что и человеку-разработчику или автономному агенту. Команды, добивающиеся успеха в этой модели, не выбирают сторону в споре между DevOps, платформой и MLOps, а рассматривают весь конвейер как продукт, подлежащий версионированию, мониторингу и контролю затрат, с непрерывными циклами обратной связи.
В этом смысле Брайант не считает, что LLMOps отменяет вопрос ответственности или изобретает его заново. Напротив, она усиливает давление на существующие платформы из-за масштаба и высокой стоимости моделей, а также сложности их оценки. По его мнению, решение заключается в том, чтобы один раз создать стандартный маршрут, а затем предоставлять его как управляемую возможность разработчику, специалисту по данным и интеллектуальному агенту через общий API или пользовательский интерфейс. Он отмечает, что это обсуждение продолжается внутри CNCF, особенно в Platforms Working Group при TAG App Delivery, которая открыта для всех желающих внести свой вклад.