Разработка ML-решений на заказ: от прототипа до production

Разработка ML решений: где ломаются пилоты

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

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

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

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

Что меняется после внедрения модели в работу

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

Время вывода новой версии сокращается с недель до нескольких дней: переобучение, проверка на отложенной выборке и публикация идут одним конвейером. Доля ручных операций падает с 80% до 15–20% — вручную остаются только спорные случаи, которые уходят в очередь на дообучение, а не разбираются потоком.

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

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

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

Формат поставки определяет, где живут веса модели, обучающие выборки и журналы запросов, — от этого зависят требования к инфраструктуре и уровень контроля над результатом. Один и тот же алгоритм можно отдать сетевым сервисом, развернуть в частном контуре заказчика или собрать гибридно: чувствительные данные обрабатываются локально, а тяжёлые вычисления уходят на выделенные мощности.

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

Что уточняем до выбора

Формат фиксируем до начала разработки, вместе с требованиями к данным и процедурой отката версии модели. Если меняются условия — переводим решение между форматами без переписывания логики: контур обработки отделён от кода модели.

Этапы работы: от разбора данных до передачи команде

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

1. Разбор данных. Смотрим, что реально лежит в учётных системах, выгрузках и файлах: объём, разметку, пропуски, дубли, расхождения в справочниках. На выходе — отчёт о пригодности: каких полей хватает, какие признаки придётся собирать заново.

2. Схема решения. Определяем границу между жёсткими правилами и моделью, формат ответа для потребителя и поведение при неуверенном результате. Схему согласуем до кода — диаграммой и описанием потоков данных.

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

4. Проверка на исторических данных. Прогоняем модель на периоде, которого она не видела, и сравниваем с текущим способом решения. Отдельно считаем ошибки на редких случаях — именно они чаще всего подрывают доверие к системе.

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

6. Передача и сопровождение. Отдаём регламент переобучения, набор проверок, инструкции для смены и точки контроля метрик. Договариваемся о ритме обновления на новых данных — иначе качество проседает в первые же недели после запуска.

Что остаётся у вас: код, схемы, регламенты, доступы

Передача решения — это не «дали доступ к репозиторию и созвон на прощание», а комплект, по которому ваша команда поднимает, эксплуатирует и дообучает модель без нашего участия. Поэтому документация и конфигурации собираются по ходу проекта, а не восстанавливаются по памяти в последнюю неделю.

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

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

Кейс: прогноз оттока для сервисной компании

До: выборка раз в месяц и решения вручную

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

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

После: признаки по расписанию и приоритет по риску

Подготовку данных перенесли в регулярный контур: витрина признаков пересчитывается по расписанию в Airflow, источники — биллинг, история платежей, обращения и активность в личном кабинете. Разметка «ушёл / остался» строится на скользящем окне, поэтому модель обучается в тех же условиях, в которых потом работает. Тот же набор признаков, что собирался три дня, теперь обновляется за 40 минут без участия аналитика.

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

Доля решений, принимаемых вручную, снизилась со 100% до 15% — остальное закрывает автоматическое продление для клиентов с низким риском. Точность срабатываний на удержание — 7 из 10, отток в целевом сегменте за два квартала сократился примерно на треть. Качество отслеживается по дрейфу признаков, переобучение идёт по регламенту, поэтому эффект не размывается со временем.

Чем отличаются данные для обучения и для работы модели?

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

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

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

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

Технические сомнения заказчиков: данные и качество

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

Как понять, что качество просело?

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

Что будет, если модель придётся заменить?

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

Зачем нужна ваша команда после запуска?

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

Обсудим задачу и вернёмся с оценкой и планом

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

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

Дальше мы разбираем требования вместе с инженерами, которые поведут проект, — без передачи задачи «через посредника». На выходе вы получаете документ: состав работ по этапам, сроки каждого этапа, что требуется с вашей стороны и какие риски видим заранее. Опишите задачу в удобном виде — вернёмся с оценкой и планом, по которому можно принимать решение.