Екатерина Цаплина, «Норникель»: Конкуренция в ИИ смещается от моделей к инженерным системам

«Ценность для компании создает не сама модель»

CNews: За последние два года внимание рынка было сосредоточено на качестве и возможностях больших языковых моделей. Почему при переходе от ИИ-пилотов к промышленной эксплуатации главным ограничением часто становится не качество модели, а зрелость инфраструктуры и процессов машинного обучения (MLOps)?

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

Ценность для компании создает не сама модель, а ИИ-сервис, который способен надежно, безопасно и экономически эффективно работать в промышленной эксплуатации. Именно на этом этапе ИИ перестает быть задачей специалистов по данным (Data Science) и становится задачей инженерии. На первый план выходят вопросы масштабируемости, интеграции с корпоративными системами, наблюдаемости, безопасности и стоимости эксплуатации. Решить их без зрелой инфраструктуры и выстроенных процессов машинного обучения невозможно.

С распространением генеративного ИИ роль инфраструктуры стала еще важнее. Стоимость эксплуатации сегодня во многом определяется архитектурой всей системы. Компаниям приходится выбирать между облачными интерфейсами прикладного программирования (API), собственными моделями и гибридными подходами, принимать решения о маршрутизации запросов, оптимизации вывода, использовании графических процессоров и распределении вычислительной нагрузки.

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

Эту тенденцию подтверждают и исследования рынка. Согласно исследованию «Google Cloud» State of AI Infrastructure, 98% организаций уже изучают или внедряют генеративный ИИ, а 39% используют его в промышленной эксплуатации. При этом среди ключевых факторов успешного масштабирования компании называют готовность инфраструктуры, качество и безопасность данных, а также экономическую эффективность эксплуатации ИИ-систем.

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

«Самая недооцененная статья расходов — работа инженерных команд»

CNews: Из чего на самом деле складывается стоимость промышленной эксплуатации современных ИИ-систем и какие расходы компании чаще всего недооценивают?

Екатерина Цаплина: Многие компании воспринимают запуск ИИ-продукта как завершение основного этапа инвестиций. На практике именно после выхода в промышленную эксплуатацию начинает формироваться основная часть совокупной стоимости владения системой (Total Cost of Ownership). Чаще всего на старте проекта недооценивают пять категорий расходов: вычислительную инфраструктуру, ежедневную эксплуатацию (Run), постоянное развитие (Change), работу инженерных команд и организационные издержки.

Первая статья затрат — вычислительная инфраструктура. Это не только графические процессоры или оплата интерфейсов прикладного программирования (API) внешних моделей, но и серверы, системы хранения данных, сеть, резервирование, мониторинг и обеспечение отказоустойчивости.

Вторая — эксплуатация. ИИ-систему необходимо постоянно контролировать: отслеживать качество модели, собирать логи, обеспечивать безопасность, управлять доступами и поддерживать работоспособность всей инфраструктуры.

Третья — развитие. Модели приходится регулярно переобучать, тестировать новые версии, контролировать деградацию качества и безопасно обновлять их в рабочей среде (production).

И, пожалуй, самая недооцененная статья расходов — работа инженерных команд. По мере масштабирования ИИ в процесс вовлекаются специалисты по данным (Data Scientists), инженеры по машинному обучению (MLOps-инженеры), специалисты по разработке и эксплуатации (DevOps), платформенные команды, специалисты по информационной безопасности и архитекторы. Если процессы между ними не выстроены, стоимость проекта начинает расти гораздо быстрее, чем вычислительные расходы.

CNews: Какие ошибки компании чаще всего совершают при проектировании платформы для машинного обучения (ML-платформы) и процессов MLOps, из-за которых возникают сложности с внедрением и дальнейшей эксплуатацией ИИ-систем?

Екатерина Цаплина: Из своего опыта я бы выделила две основные ошибки.

Первая — проектировать платформу, исходя из текущего набора технологий, а не из того, какие ИИ-сценарии бизнес планирует развивать в перспективе. Архитектура должна отвечать не на вопрос «какой стек мы используем сегодня», а «какие задачи нам предстоит решать через несколько лет». Для одной компании оптимальной будет единая ИИ-платформа, для другой — несколько специализированных контуров. Универсального решения здесь нет.

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

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

Вторая ошибка — воспринимать MLOps только как автоматизацию развертывания моделей. На практике не менее важна наблюдаемость (observability). Недостаточно понимать, что сервис доступен. Нужно видеть, какая версия модели работает, как меняется качество её ответов, не возник ли дрейф данных, где увеличилось время отклика и как меняется стоимость вывода (инференса).

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

«Эксплуатация больших языковых моделей обычно требует больше вычислительных ресурсов»

CNews: Как изменились задачи MLOps с распространением генеративного искусственного интеллекта и больших языковых моделей? Какие новые требования появились к мониторингу, доступам, качеству ответов, базам знаний (knowledge bases) и инфраструктуре вывода (inference)?

Екатерина Цаплина: С появлением генеративного ИИ роль MLOps стала значительно шире. Если раньше основной задачей было управлять жизненным циклом модели, то сегодня инженерным объектом становится вся ИИ-система.

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

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

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

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

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

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

CNews: Если бы вам нужно было дать три рекомендации руководителю ИТ-службы (CIO) или техническому директору (CTO), которые планируют масштабировать ИИ в компании, на что вы бы посоветовали обратить внимание в первую очередь, чтобы проект оказался не только технологически успешным, но и экономически эффективным?

Екатерина Цаплина: Я бы выделила три ключевые рекомендации.

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

Вторая — инвестировать в компетенции, а не только в инфраструктуру. Закупить графические процессоры или внедрить современные модели недостаточно. Для масштабирования ИИ нужны специалисты по MLOps, платформенной инженерии, ИИ-архитектуре, а главное — эффективное взаимодействие специалистов по данным (Data Science), разработке и эксплуатации (DevOps), эксплуатации, информационной безопасности и архитекторов. По данным отчета World Economic Forum Future of Jobs Report 2025, 63% работодателей называют дефицит навыков главным барьером цифровой трансформации. Это справедливо и для ИИ: технологии развиваются быстрее, чем компетенции команд.

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

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