ML-пайплайны

Что делает ML-пайплайн: путь модели от данных до работы в процессе

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

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

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

Данные: сбор и подготовка — шаг, который не пропускают ради скорости

До первой строки кода заказчик и Dzeta AI договариваются, что считать успехом: какую величину смотрим и какое значение устроит. Без этого готовую модель не с чем сравнить.

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

Обучение и валидация на данных заказчика

Учится модель на истории самой компании: на её номенклатуре, документах, измерениях. Пайплайн пишут на Python: для табличных задач берут scikit-learn и CatBoost, где нужна нейросеть — PyTorch.

Вместе с обучением задают процедуру проверки: на каком наборе сверяемся и какая ошибка дороже. Процент точности до работы с данными Dzeta AI не называет: величина с чужого набора о ваших данных не говорит ничего.

Приёмка: целевое качество согласовано до старта

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

Документные задачи Dzeta AI проверяет на 10⁠–⁠20 реальных документах заказчика — тех, на которых спотыкается разбор.

Задачи, под которые собирают пайплайн

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

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

Прогноз спроса и закупок может быть устроен так же — проектов по нему у Dzeta AI пока нет: на истории продаж и остатков модель считает ожидаемую потребность.

Откуда пайплайн берёт данные и куда возвращает результат

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

Учётная система в проектах Dzeta AI — 1С, остальные источники разбирают на аудите. От типа данных пайплайн не зависит, меняется подготовка: что происходит, когда входом становится изображение.

Что происходит с моделью после запуска

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

Поэтому сопровождение ML-модели в Dzeta AI устроено как повторяющийся цикл:

• за качеством работающей модели следят по тем же метрикам, по которым систему принимали;
• при падении точности или изменении данных приходит алерт;
• команда Dzeta AI разбирает причину алерта и переобучает модель на свежих данных;
• переобученная модель выходит новым релизом — через ту же процедуру проверки, что и при первой приёмке.

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

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

Эксперименты и версии моделей ведут в MLflow и DVC. По ним видно, на каких данных обучена каждая версия и с какими параметрами получилась. Свежая версия ведёт себя хуже предыдущей — это заметно по тем же метрикам, и есть куда вернуться: предыдущая вместе со своим набором данных никуда не делась.

Проект Dzeta AI: путь от прототипа до промышленной эксплуатации

Проект для производителя авиационной техники — единственный, где Dzeta AI прошла весь путь: от исследовательской части до модуля в промышленной эксплуатации. Контроль конструктивных элементов там идёт по многоканальным измерениям, и с ростом выпуска ручной анализ перестал успевать за потоком.

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

Путь целиком этот проект и прошёл — от исследовательского прототипа до ежедневной работы под нагрузкой. Цифры собраны на отраслевой странице: результаты проекта у производителя авиационной техники.

Реализованных проектов у Dzeta AI 50+, отраслей — восемь. Развёрнуто показан один — тот, где видны все шаги этой страницы.

Как проходит внедрение: аудит, пилот, приёмка

Внедрение ML-пайплайна идёт этапами, и на каждом заранее понятно, что считается результатом.

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

Где работает система и кто видит данные

Пайплайн разворачивают в контуре заказчика на открытых моделях. Обучающие выборки и результаты остаются внутри компании, персональные данные её не покидают (152-ФЗ «О персональных данных»), подтверждения пишутся в журнал. В ChatGPT и другие внешние сервисы данные не уходят, если заказчик этого не хочет. Модель в пайплайне сменная: её заменяют без переделки системы.

Собрано всё это на понятных вещах: сервисы едут в Docker и живут в Kubernetes, ответ отдаёт FastAPI, данные и очереди держат PostgreSQL и Redis, новая версия выкладывается через CI/CD. Собственный IT-отдел заказчику не нужен: хватает человека, который понимает процесс и может сказать, где система ошиблась.

Когда ML-пайплайн не окупится

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

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