ML-разработка для бизнеса: зачем нужна и как проходит проект

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

Зачем бизнесу ML-разработка и машинное обучение

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

Типичные задачи:

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

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

Какие подходы используются в ML-проектах

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

Подход	Что делает	Типичные задачи	Что нужно на входе
Классический ML	Обучается на исторических данных, чаще всего табличных	Прогноз спроса, оценка риска, классификация, поиск аномалий, рекомендации	Исторические данные достаточного объёма и качества; для классификации и прогноза нужна целевая переменная, для кластеризации и поиска аномалий она может отсутствовать
Генеративный ИИ и языковые модели (LLM)	Создают новое содержание: текст, изображения, код; работают с неструктурированными данными	Ответы по документам, резюмирование, извлечение данных	Документы, правила, примеры
Распознавание изображений, звука и сигналов (Computer Vision, Speech/Audio, Signal ML)	Находит закономерности в изображениях, аудио, видео и показаниях датчиков и переводит их в классы, текст или числовые оценки	Выявление дефектов на производстве, распознавание документов и лиц, распознавание речи, поиск аномалий и контроль оборудования по вибрации	Изображения, аудио, видео или временные ряды с датчиков; для обучения с учителем — размеченные примеры («дефект / нет дефекта»), для поиска аномалий разметка может не потребоваться; данные предварительно очищают и подготавливают

Распознавание и генерация чаще всего строятся на глубоком обучении, то есть на нейронных сетях, а классический ML обходится без них; при этом в распознавании нередко применяют и классические методы на заранее подготовленных признаках. Выбор подхода определяется задачей, объёмом данных и требованиями к качеству, стоимости и скорости: для классификации текстов могут применяться как классические методы, так и языковые модели, а для работы с документами — сочетание распознавания, правил и ML. Не каждая задача требует ML. Чтобы показать, что произошло, достаточно аналитики и BI: отчётов и панелей. ML нужен для прогноза и классификации, когда закономерности трудно записать правилами. Он оправдан и там, где правила возможны, но их слишком много, они быстро устаревают или обходятся дороже модели. Подходы часто сочетаются: например, языковая модель извлекает данные из писем, а классическая модель принимает решение. Как выбрать направление ИИ в бизнесе, разобрано в статье «Консалтинг по внедрению ИИ в бизнес-процессы».

Этапы ML-разработки: составляющие проекта и результат

В таблице описан стандартный проект, состав этапов зависит от задачи.

Этап	Что происходит на этапе	Результат
1. Постановка задачи	Формулируется задача в терминах данных и метрик, определяется, как будет измеряться успех	Описание задачи, метрики успеха, критерии приёмки
2. Аудит данных	Оцениваются полнота, качество, разметка, ограничения доступа	Отчёт о данных: что пригодно, чего не хватает, риски
3. Прототип	Строится простая базовая модель (baseline) и проверяется гипотеза	Прототип и оценка: стоит ли идти дальше
4. Разработка модели	Подбираются признаки и (или) архитектура, готовятся данные, обучаются и сравниваются варианты с базовым решением	Обученная модель, отчёт о качестве, воспроизводимый код обучения
5. Интеграция	Модель оформляется как API-сервис, пакетный процесс или встроенный модуль в зависимости от требований к задержке и нагрузке и подключается к системам заказчика	Работающее решение в согласованном виде (API, пакетный процесс, модуль), документация
6. Эксплуатация и сопровождение	Настраиваются мониторинг качества, входных данных, задержки, нагрузки и стоимости, а также дообучение, передаются знания	Мониторинг качества модели, план обновлений, обученная команда

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

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

Самая частая причина остановки ML-проекта на любом этапе — не алгоритм, а данные. На старте — их недостаток и некачественное обучение, а после запуска — отсутствие мониторинга динамики, которое приводит к деградации модели. — эксперт «Пруфтек ИТ»

Как принимать результат ML-разработки

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

1. Метрика и порог. Какая метрика соответствует задаче и какое значение считается достаточным: для классификации — precision (доля верных срабатываний среди всех срабатываний), recall (доля найденных случаев среди всех реальных) и F1 (баланс этих двух показателей) либо доля ошибок, для прогноза числовых значений — MAE, RMSE и MAPE (разные способы измерить среднюю ошибку прогноза).
2. Сравнение с текущим процессом. Модель сопоставляется с ручной работой, правилами или простой эвристикой по согласованным метрикам. Требование «не хуже» не универсально: допустим согласованный компромисс, например немного ниже качество при существенно большей скорости и передаче сомнительных случаев человеку. Без такого сравнения значение метрики не информативно.
3. Проверка на данных заказчика. Тест на отложенной выборке (части данных, которую модель не видела при обучении и подборе параметров), желательно на данных за самый свежий период; для временных данных применяется разбиение по времени, исключающее попадание в обучение информации из будущего.
4. Цена ошибок. Разные ошибки имеют разную цену: пропущенное мошенничество и ложное срабатывание не равноценны. Метрика выбирается с учётом этого.
5. Устойчивость. Как модель ведёт себя на редких и нестандартных случаях.
6. Воспроизводимость. Код обучения, версии данных, параметры, зависимости, среда выполнения и версия обученной модели позволяют повторить результат.
7. Эксплуатация. Скорость ответа, нагрузка, мониторинг и порядок обновления.
8. Проверка интеграции и отказоустойчивости. Помимо качества модели проверяются корректность API и обмена данными, время ответа под нагрузкой, поведение при ошибках внешних сервисов, журналирование, права доступа, мониторинг деградации и возможность отката на предыдущую версию.
9. Права и документация. Кому принадлежат модель и код, что передаётся (включая данные для дообучения, конвейер подготовки данных, тесты и инструкцию по эксплуатации), какая документация.

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

Пример критериев приёмки: маршрутизация обращений

Типовая задача: модель относит входящие обращения к одной из тематик для автоматической маршрутизации.

Критерий	Формулировка для примера	Как проверяется
Качество классификации	Доля верно определённых тематик на отложенной выборке не ниже согласованного порога	Выборка, не использовавшаяся при обучении, за самый свежий период
Сравнение с текущим процессом	Доля ошибочно направленных обращений не выше согласованного уровня либо согласованный компромисс по качеству и скорости	Сопоставление на одном и том же наборе обращений
Доля автоматической обработки	Доля обращений, обрабатываемых автоматически при допустимом уровне ошибок; сомнительные случаи передаются человеку	Отчёт по выборке и по очереди ручной проверки
Редкие тематики	Для редких категорий качество не ниже согласованного минимума	Отдельный отчёт по каждой категории
Скорость ответа	Время обработки одного обращения укладывается в требование интеграции	Нагрузочная проверка в среде заказчика
Воспроизводимость	Результат обучения повторяется по документации и сохранённым версиям данных	Повторный запуск силами заказчика
Передача	Код, модель, документация и инструкция по дообучению переданы	Акт приёма-передачи

Значения порогов неуниверсальны и зависят от задачи и цены ошибки, но есть ориентиры. Для прогнозов числовых величин часто используют шкалу Льюиса (1982) по метрике MAPE: до 10% — высокая точность, 10–20% — хорошая, 20–50% — приемлемая, выше 50% — неточный прогноз (Statology). Для классификации обращений ориентиром служит точность около 90%: в руководстве Anthropic по маршрутизации обращений с помощью языковых моделей целью названа точность 90% и выше по одному заголовку и краткому описанию (документация), а в магистерской работе Университета Аалто по маршрутизации ИТ-обращений модель показала F1 около 90% на тестовой выборке и 86% в двухнедельной эксплуатации (работа).

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

От чего зависят сроки и стоимость ML-разработки

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

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

Частые вопросы