Ежедневно в мире появляются сотни новых проектов, которые пытаются упростить жизнь и работу других компаний с помощью решений на основе машинного обучения (ML), обработки естественного языка (NLP) и других технологий. К сожалению, их разработчики продолжают допускать одни и те же ошибки.
Разберем самые распространенных из них. Первые три пункта относятся к ошибкам в организации бизнеса и постановки стратегических целей, остальные — к технической стороне вопроса.
1. Едим слона целиком
Цель отдельно взятого проекта бывает очень амбициозна — настолько, что она фактически недостижима. Вместо того, чтобы декомпозировать ее на отдельные и реализуемые задачи, стартапы часто пытаются решить всю проблему сразу.
На выходе они получают тысячи потраченных человеко-часов и неудовлетворительный результат. Казалось бы, минимально жизнеспособный продукт (MVP), который обладает достаточными для удовлетворения первых потребителей функциями, — это очевидная вещь. Но в состоянии драйва люди об этом совершенно забывают.
2. Отсутствие фидбека от пользователей
Никто не любит демонстрировать «сырой» продукт, но это ошибка. MVP — лучшее, что можно сделать, еще и потому, что это единственная возможность собрать обратную связь о своем продукте с пользователей на раннем этапе.
Так стартап может получить информацию, важную для создания действительно хорошего решения. И сделать это в самом начале, когда в проект еще не вложено большое количество ресурсов. В качестве бонуса компания получает возможность изучить спрос на похожие решения и скорректирует свое видение проблемы.
3. Отказ от тестирования
Тестирование моделей, на основе которых работает интеллектуальная система — одна из самых важных стадий процесса разработки. К сожалению, многие инженеры ей пренебрегают. Часто причиной становится сложность процесса или отсутствие данных.
Тестирование — базовая часть разработки решения, и если ее игнорировать, результаты становятся непредсказуемыми. При таком подходе разработчик теряет возможность оценивать модель автоматически — с помощью метрик. Просматривать результат вручную можно, но со временем этому вопросу уделяется все меньше внимания. Корень проблемы лежит в отсутствии разметки данных — это именно то, на что стоит тратить время, силы и средства.
4. Отсутствие контроля версий и новые пайплайны
Как правило, разработчики машинного обучения не сохраняют достаточно информации о модели. Это приводит к тому, что со временем они забывают, какие именно файлы с кодом использовались на том или ином этапе построения модели. Инженерам, которые не участвовали в разработке модели, разобраться в этих файлах почти невозможно.
Избавиться от проблемы можно с помощью системы контроля версий DVC — аналога Git Large File Storage, который способен хранить сотни гигабайт данных, сохранять пайплайны обучения и воспроизводить их.
5. SOTA c ходу
Некоторые инженеры при появлении нового проекта пытаются использовать непроверенные SOTA-пайплайны. Итог у этого обычно плачевный — разработчики тратят месяцы на воспроизведение результатов из статей-гайдов и подбор параметров, а получившаяся модель не демонстрирует ожидаемого качества.
Это не значит, что экспериментировать не надо, но начинать с SOTA-моделей точно не стоит. Сначала лучше попробовать простые модели, которые можно импортировать из привычного фреймворка машинного обучения, обучить и за несколько дней получить результат. При таком подходе заказчик быстро получает демо новой функции, а инженер может заняться обучением более продвинутых моделей, которые можно сравнивать с базовым решением.